Как защитить веб‑приложения с помощью Coraza и ModSecurity
Публичные веб‑сервисы постоянно подвергаются автоматизированным атакам. Злоумышленники используют сканеры уязвимостей, перебор параметров, вредоносные боты и готовые инструменты для SQL-инъекций, XSS, попыток удалённого выполнения кода и обхода авторизации. Поэтому межсетевой экран уровня приложений, или WAF, давно стал стандартным элементом защиты интернет‑ресурсов.
В отличие от классических сетевых экранов, работающих на уровнях L3-L4 модели OSI, WAF анализирует HTTP‑трафик на прикладном уровне L7. Он видит URI, заголовки, cookies, параметры запросов, содержимое JSON, XML и форм, а затем сравнивает их с набором правил безопасности. Благодаря этому подозрительный запрос можно остановить ещё до того, как он попадёт в бизнес‑логику приложения.
Одним из современных открытых решений этого класса является OWASP Coraza.
Что такое Coraza
Исторически наиболее известным свободным WAF был ModSecurity. Проект появился в 2002 году как модуль для Apache, а позже получил поддержку Nginx и IIS. Он стал основой для большого количества защитных конфигураций и правил, включая OWASP Core Rule Set.
В 2024 году активная разработка ModSecurity была фактически завершена. Для него продолжают выпускать исправления критических проблем, а правила поддерживаются сообществом, однако архитектура проекта уже не соответствует всем требованиям современной инфраструктуры.
Coraza стал самостоятельным продолжением этой идеи. Это высокопроизводительный WAF с открытым кодом, написанный на Go. Он не является прямым форком ModSecurity, а представляет собой движок, созданный с нуля. При этом Coraza поддерживает синтаксис SecLang и совместим с основными правилами OWASP CRS версии 4.
К преимуществам Coraza относятся:
- отсутствие типичных для небезопасного управления памятью ошибок, характерных для C и C++;
- возможность встраивания в приложения на Go;
- интеграция с Caddy и Traefik;
- запуск через WebAssembly в связке с Envoy и Istio;
- поддержка привычных правил ModSecurity;
- удобное масштабирование в контейнерных средах.
Главная задача Coraza - остановить вредоносный HTTP‑запрос на периметре, не допуская его до приложения, базы данных или внутренних API.
Как Coraza анализирует запросы
Обработка HTTP‑сообщения разбита на несколько последовательных фаз.
Фаза 1. Заголовки запроса
Сначала проверяются HTTP‑метод, URI, cookies и заголовки. На этом этапе можно обнаружить подозрительные User-Agent, нестандартные методы, признаки автоматизированного сканирования и попытки манипуляции заголовками.
Фаза 2. Тело запроса
Затем анализируется тело сообщения. WAF проверяет параметры форм, JSON, XML, multipart‑данные и другие значения. Здесь выявляются SQL‑инъекции, XSS‑конструкции, попытки обхода фильтров и вредоносные команды.
Фаза 3. Заголовки ответа
После обработки приложения Coraza может проверить заголовки ответа. Это позволяет выявлять небезопасные настройки, контролировать служебные заголовки и реагировать на подозрительные ответы сервера.
Фаза 4. Тело ответа
При необходимости WAF анализирует содержимое ответа. Такой режим применяют для обнаружения утечек данных, диагностических сообщений, фрагментов исходного кода и других нежелательных сведений. Однако глубокий анализ ответов увеличивает нагрузку, поэтому его следует включать выборочно.
Варианты развертывания
Coraza можно разместить в нескольких архитектурах.
Docker Compose
Подходит для лабораторных стендов, небольших сервисов и локального тестирования. Обычно в отдельном контейнере запускают приложение, а перед ним размещают Caddy с подключённым Coraza. Внешний трафик попадает на прокси, проверяется WAF и только после этого передаётся целевому сервису.
Docker Swarm
Такой вариант удобен для распределённого запуска нескольких экземпляров. Контейнеры можно масштабировать, а входящий трафик направлять через общий reverse proxy. Важно заранее продумать хранение конфигураций, правил и журналов.
Kubernetes
В Kubernetes Coraza размещают внутри ingress‑компонента или отдельного прокси‑слоя. Такой подход позволяет централизованно защищать несколько приложений, управлять политиками через ConfigMap и автоматически масштабировать защитный контур.
Лабораторный стенд на Docker Compose
Для безопасного изучения WAF удобно использовать намеренно уязвимое приложение OWASP Juice Shop. Оно позволяет проверять правила без риска повредить реальные сервисы.
Шаг 1. Подготовка сервера
На тестовой машине обновляют операционную систему и устанавливают Docker вместе с Docker Compose. Для экспериментов лучше использовать отдельный виртуальный сервер или изолированную локальную среду.
Шаг 2. Структура проекта
Рекомендуется создать отдельные каталоги для конфигурации прокси, правил Coraza, журналов и файла Compose. Разделение упрощает резервное копирование и последующее обновление компонентов.
Пример логической структуры:
```text
waf-lab/
├── compose.yml
├── Caddyfile
├── rules/
├── logs/
└── data/
```
Шаг 3. Образы контейнеров
В Compose описывают два основных сервиса: Juice Shop как защищаемое приложение и Caddy с Coraza в роли reverse proxy. Приложение не должно быть доступно напрямую из внешней сети - наружу публикуются только порты прокси.
Шаг 4. Подключение правил
Базой защиты обычно служит OWASP Core Rule Set. Его необходимо разместить в каталоге правил и подключить в конфигурации WAF. Правила CRS регулярно обновляются, поэтому при эксплуатации важно контролировать их версии и проверять совместимость с текущим движком.
Шаг 5. Настройка Docker Compose
Прокси должен обращаться к приложению по имени сервиса во внутренней сети Docker. Публикация порта Juice Shop наружу нежелательна: иначе атакующий сможет обойти Coraza и отправлять запросы непосредственно к приложению.
Шаг 6. Настройка Caddyfile
В конфигурации Caddy задают домен или тестовый адрес, обратное проксирование и подключение Coraza. Также следует определить режим работы: сначала лучше использовать обнаружение угроз без блокировки, а после анализа журналов перейти к активному отказу.
Шаг 7. Запуск
После проверки синтаксиса запускают контейнеры в фоновом режиме. Затем проверяют состояние сервисов, наличие внутренних сетей и корректность монтирования файлов с правилами.
Шаг 8. Проверка портов
Нужно убедиться, что доступен только публичный порт Caddy, а порт приложения закрыт от внешнего интерфейса. Дополнительно проверяют журналы прокси и WAF: в них должны отображаться входящие запросы, срабатывания правил и причины блокировок.
Режим обнаружения и режим блокировки
Практически всегда безопаснее начинать с режима DetectionOnly. В нём Coraza регистрирует нарушения, но не прерывает запросы. Такой запуск помогает понять, какие правила срабатывают на нормальном трафике.
После анализа журналов можно включать блокировку. При этом важно исключить ложные срабатывания: легитимные JSON‑поля, специальные символы, сложные поисковые запросы и нестандартные API‑методы иногда ошибочно выглядят как атака.
Не следует отключать всё правило целиком из-за одного проблемного запроса. Гораздо правильнее ограничить исключение конкретным URL, параметром, методом или идентификатором правила.
Создание собственных правил
SecLang позволяет описывать условия, при которых запрос должен быть зарегистрирован или заблокирован. Простое пользовательское правило может проверять наличие запрещённого значения в параметре, подозрительного заголовка или определённого шаблона в URI.
При написании правил важно:
- указывать понятное описание события;
- назначать уникальный идентификатор;
- выбирать подходящий уровень серьёзности;
- ограничивать область проверки;
- не использовать чрезмерно широкие регулярные выражения;
- сначала тестировать правило в режиме журналирования.
Слишком общие шаблоны часто приводят к блокировке обычных запросов. Поэтому правило должно быть максимально конкретным и учитывать контекст приложения.
Тестирование защиты
Проверять WAF следует только на собственном стенде или при наличии разрешения владельца системы. Для тестов используют безопасные запросы, имитирующие типовые атаки: подозрительные SQL‑конструкции, XSS‑фрагменты, необычные HTTP‑методы, некорректные заголовки и чрезмерно длинные параметры.
Во время проверки нужно смотреть не только на HTTP‑код ответа, но и на журналы. В них должны быть видны:
- адрес клиента;
- URI и метод;
- идентификатор сработавшего правила;
- категория нарушения;
- действие WAF;
- оценка риска;
- время обработки запроса.
Полагаться только на WAF нельзя. Он не заменяет безопасную разработку, обновление зависимостей, контроль доступа, настройку cookies, ограничение частоты запросов и мониторинг инфраструктуры.
Производительность и эксплуатация
Глубокий разбор тела запроса и ответа увеличивает потребление CPU и памяти. Поэтому лимиты на размер загружаемых данных, допустимые типы содержимого и время обработки следует задавать заранее.
Для рабочих систем полезно:
- отправлять журналы в централизованное хранилище;
- отслеживать рост количества блокировок;
- разделять события безопасности и технические ошибки;
- регулярно обновлять CRS;
- тестировать новые правила до внедрения;
- иметь возможность быстро отключить проблемную политику;
- защищать административные интерфейсы отдельными правилами.
Особое внимание требуется уделить TLS. Если шифрование завершается перед WAF, прокси должен получать корректную информацию об исходном клиенте и протоколе. Неправильная передача заголовков может нарушить логику приложения и аудит событий.
Итоги
Coraza - современный открытый WAF, совместимый с экосистемой ModSecurity и OWASP CRS. Он позволяет вынести фильтрацию HTTP‑трафика на отдельный защитный слой, интегрировать её с Caddy, Traefik, Kubernetes и другими инфраструктурными компонентами.
Оптимальная стратегия внедрения выглядит так: сначала развернуть изолированный тестовый стенд, подключить базовые правила в режиме обнаружения, изучить журналы, устранить ложные срабатывания и только после этого включать блокировку. При грамотной настройке Coraza существенно снижает риск эксплуатации типовых веб‑уязвимостей, но должен использоваться вместе с безопасной архитектурой, регулярными обновлениями и контролем доступа.