Как защитить веб-приложения с помощью Coraza и ModSecurity
Защита публичных веб-сервисов давно перестала быть дополнительной опцией. Современные инструменты для анализа уязвимостей доступны не только специалистам по информационной безопасности, поэтому веб-приложение необходимо защищать еще до того, как подозрительный запрос достигнет его бизнес-логики. Одним из ключевых средств такой защиты остается WAF - межсетевой экран для веб-приложений.
В отличие от классических сетевых экранов, работающих на уровнях L3-L4 модели OSI, WAF анализирует трафик прикладного уровня L7. Он понимает структуру HTTP-запросов и способен обнаруживать SQL-инъекции, межсайтовый скриптинг, попытки удаленного выполнения кода, обход авторизации и другие типовые атаки. Подробно разобраться в практической защите веб-сервисов помогает материал о [защите веб-приложений WAF](https://habr.com/ru/companies/selectel/articles/1079984/?utm_campaign=1079984&utm_source=habrahabr&utm_medium=rss).
Что такое Coraza
Исторически одним из самых известных открытых WAF был ModSecurity. Проект появился в 2002 году как модуль для Apache, а затем получил поддержку Nginx и IIS. На его базе сформировалась развитая экосистема правил, включая OWASP Core Rule Set. Однако в 2024 году активное развитие самого ModSecurity завершилось: теперь преимущественно выпускаются исправления критических проблем, а новые детектирующие правила поддерживаются сообществом.
Продолжением этой идеи стал OWASP Coraza - производительный WAF с открытым исходным кодом, написанный на Go. Это не прямой форк ModSecurity, а созданный с нуля движок, совместимый с синтаксисом SecLang и базовыми правилами CRS v4. Реализация на Go снижает риски ошибок управления памятью, характерных для проектов на C и C++.
Coraza можно использовать в разных сценариях: встроить как библиотеку в приложение на Go, подключить к Caddy или Traefik, а также запускать через WebAssembly в инфраструктуре Envoy и Istio. Благодаря этому решение подходит как для небольшого тестового стенда, так и для распределенной production-среды.
Как обрабатывается запрос
Работа WAF разделена на несколько последовательных фаз. Сначала анализируются HTTP-метод, URI, cookie и заголовки. Уже на этом этапе можно заблокировать сканер уязвимостей, подозрительного бота или запрос с нестандартными параметрами.
Затем Coraza проверяет тело запроса: JSON, XML, multipart-формы и другие данные. Здесь обнаруживаются SQL-инъекции, XSS-нагрузки и попытки передать вредоносные конструкции в параметры приложения.
После этого анализируются заголовки ответа и его содержимое. Такая проверка позволяет выявить утечку чувствительной информации, признаки ошибки конфигурации или нежелательные данные, которые приложение возвращает клиенту. Для каждой фазы можно задавать собственные правила, действия и уровень журналирования.
Развертывание стенда
Практичный способ познакомиться с Coraza - собрать изолированный стенд в Docker Compose. В качестве уязвимого приложения удобно использовать OWASP Juice Shop, а перед ним разместить прокси с Coraza и Caddy. В такой схеме весь входящий трафик сначала проходит через WAF, после чего разрешенные запросы маршрутизируются к Juice Shop.
Подготовка обычно включает обновление операционной системы, установку Docker и Docker Compose, создание каталогов для конфигурации, журналов и правил. Далее загружаются образы приложения и WAF, а также скачивается OWASP Core Rule Set. В файле Compose описываются контейнеры, сети, проброс портов, переменные окружения и тома с конфигурацией.
Отдельно настраивается Caddyfile: в нем указываются адрес защищаемого сервиса, подключение Coraza и политика обработки заблокированных запросов. После запуска контейнеров полезно проверить состояние сервисов, просмотреть журналы и убедиться, что внешний порт занят именно прокси, а не самим приложением.
В более сложной инфраструктуре аналогичный принцип можно реализовать в Docker Swarm или Kubernetes. В Kubernetes WAF размещают как ingress-компонент, sidecar-контейнер либо отдельный прокси-слой. Выбор зависит от требований к масштабированию, отказоустойчивости и способу управления сертификатами.
Настройка правил
Базовый набор CRS обеспечивает защиту от распространенных классов атак, но не заменяет адаптацию под конкретное приложение. Универсальные правила иногда реагируют на легитимные данные: поисковые запросы, фрагменты HTML, специальные символы или нестандартные API-параметры. Поэтому после включения режима блокировки необходимо изучить журналы и определить ложные срабатывания.
Для собственных проверок используются директивы SecLang. Они позволяют анализировать заголовки, параметры, cookie и тело запроса, задавать пороги срабатывания, присваивать рейтинг аномальности и выбирать действие - от записи события до немедленной блокировки. Практика показывает, что безопаснее начинать с режима обнаружения, а затем постепенно переводить проверенные правила в blocking mode.
Настройка ModSecurity и перенос совместимых правил в Coraza требуют проверки синтаксиса и поведения директив: несмотря на высокую совместимость, отдельные модули и расширения могут работать по-разному.
Проверка защиты
Тестировать конфигурацию следует на контролируемом стенде, например на Juice Shop. В него можно отправлять заведомо безопасные тестовые запросы, имитирующие SQL-инъекции, XSS и попытки обращения к служебным файлам. Важно анализировать не только HTTP-код ответа, но и журналы Coraza: в них отображаются сработавшее правило, фаза обработки, оценка аномальности и причина блокировки.
Полезно проверять и устойчивость к обходу: менять кодировку символов, использовать альтернативные форматы параметров, добавлять пробелы и повторяющиеся заголовки. Однако такие эксперименты допустимы только в собственной лаборатории или при наличии официального разрешения на тестирование.
Практические ограничения
WAF не устраняет уязвимости в коде и не заменяет безопасную разработку. Если приложение неправильно проверяет права доступа, хранит секреты в открытом виде или использует устаревшие библиотеки, один фильтр HTTP-трафика не решит проблему. Coraza должен быть частью многоуровневой защиты, включающей обновления, сегментацию сети, контроль доступа, резервное копирование и мониторинг.
Нужно учитывать и производительность. Глубокий разбор больших тел запросов, большое количество правил и подробное журналирование увеличивают нагрузку на CPU и память. Конфигурацию следует тестировать под реальными профилями трафика, ограничивать размер принимаемых данных и заранее продумывать ротацию логов.
В результате Coraza становится современным вариантом для тех, кому нужна гибкая защита веб-приложения от атак без привязки к закрытой платформе. Он сохраняет совместимость с экосистемой ModSecurity, поддерживает OWASP CRS и предлагает удобные варианты интеграции с современными прокси и оркестраторами. При грамотной настройке это эффективный межсетевой экран для веб-приложений, который помогает обнаруживать угрозы до того, как они попадут в приложение.
