ModSecurity — open-source WAF (Web Application Firewall), работающий как модуль к веб-серверу или reverse-proxy. Анализирует HTTP-запросы и ответы по набору правил и принимает решение: пропустить, заблокировать или залогировать. Изначально создан для Apache, с версии 3.x поддерживает Nginx, IIS и Envoy через libmodsecurity.
Как работает ModSecurity
ModSecurity перехватывает HTTP-трафик на пяти фазах обработки:
- Request Headers — проверка заголовков запроса (User-Agent, Referer, Cookie)
- Request Body — анализ POST-данных, JSON, XML и multipart
- Response Headers — проверка заголовков ответа (утечка версии ПО)
- Response Body — анализ тела ответа (утечка данных карт, номеров SSN)
- Logging — запись событий в audit-лог
Набор правил OWASP ModSecurity Core Rule Set (CRS) — стандартный де-факто. Версия CRS 3.3 содержит более 200 правил, покрывающих OWASP Top 10: SQL-инъекции, XSS, SSRF, Path Traversal, Remote Code Execution. CRS можно настраивать через уровни параноидности (1–4): уровень 1 — минимум ложных срабатываний, уровень 4 — максимальная защита ценой частых блокировок легитимных запросов.
Режимы работы: Detection Only (только логирование, блокировки нет — для начальной настройки) и Prevention (активная блокировка). Рекомендуется запускать в Detection Only 2–4 недели, анализировать ложные срабатывания и только затем переключать в Prevention.
История
ModSecurity создал Иван Ристич (Ivan Ristic) в 2002 году как модуль для Apache. В 2010 году проект перешёл под управление Trustwave SpiderLabs, получив коммерческую поддержку. В 2017 году Trustwave передала ModSecurity в OWASP Foundation. Версия ModSecurity 3.0 (2017) переписала ядро на C++ в виде отдельной библиотеки libmodsecurity, отделив логику от конкретного веб-сервера.
Настройка на Nginx
Для Nginx ModSecurity подключается через динамический модуль ngx_http_modsecurity_module. Основные директивы конфига:
modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main.conf;
В main.conf подключается CRS: Include /etc/nginx/modsec/crs/crs-setup.conf и Include /etc/nginx/modsec/crs/rules/*.conf. После включения CRS важно проверить ложные срабатывания для своего приложения — особенно для WordPress-сайтов и API с нестандартными заголовками.
На что обращать внимание
ModSecurity снижает производительность веб-сервера: при активном CRS задержка обработки запроса увеличивается на 1–5 мс. Для высоконагруженных сайтов (>1000 RPS) это значимо — стоит рассмотреть вынос WAF на отдельный прокси-сервер или использование CDN с встроенным WAF (Cloudflare, AWS WAF). Audit-лог ModSecurity может занимать несколько ГБ в сутки на загруженном сервере — настройте ротацию через logrotate.
Режимы работы ModSecurity
- Detection only — правила проверяются, нарушения логируются, запросы не блокируются. Используется для первоначальной настройки без риска блокировки легитимного трафика.
- Prevention — запросы, нарушающие правила, блокируются (HTTP 403). Основной рабочий режим.
- Self-learning — ModSecurity записывает профили нормального трафика и выявляет аномалии. Требует нескольких дней обучения на продакшн-трафике.
OWASP Core Rule Set (CRS)
OWASP CRS — самый распространённый набор правил для ModSecurity. Версия CRS 4.0, вышедшая в 2023 году, содержит более 200 правил, защищающих от атак OWASP Top 10: SQL injection, XSS, Remote File Inclusion, PHP code injection, Java deserialization. Правила написаны в виде регулярных выражений и парсят тело запроса, заголовки, URL и cookies.
Каждое правило имеет числовой идентификатор (900000-999999 — конфигурационные, 1-99999 — боевые) и уровень аномальной оценки (paranoia level 1-4). При уровне 1 — минимум ложных срабатываний; при уровне 4 — максимальная защита, но высокий риск блокировки легитимных запросов.
ModSecurity 2 vs 3
ModSecurity 2 работает как Apache-модуль (mod_security2.so). ModSecurity 3 (libmodsecurity) — переписанная библиотека на C++, подключаемая к Nginx через модуль ngx_http_modsecurity_module или к Traefik через плагин. Версия 3 быстрее на 25-30% и не привязана к конкретному веб-серверу, но реализует не все функции версии 2.
На что обращать внимание при настройке
Ложные срабатывания (false positives) — главная проблема ModSecurity. Легитимные POST-запросы с большими телами (загрузка файлов), запросы от WAF-сканеров, API-запросы с нестандартными заголовками — всё это может срабатывать на правила CRS. Рабочий процесс: запустить в detection-режиме на 1-2 недели, проанализировать логи в /var/log/apache2/modsec_audit.log, добавить исключения (SecRuleRemoveById) для ложных срабатываний, переключить в prevention-режим.