ModSecurity для Nginx на Ubuntu — установка и настройка

Введение

ModSecurity — это модуль уровня приложения (WAF, Web Application Firewall) с открытым исходным кодом, разработанный командой SpiderLabs (Trustwave) и распространяемый по Apache License 2.0. Он фильтрует HTTP-трафик с помощью правил, ведёт логирование, обеспечивает анализ в реальном времени и обнаружение атак (SQL Injection, XSS, LFI, RFI и др.). В распространившихся правилах OWASP CRS доступно более 16 000 сигнатур для типичных атак.

Ниже показан практический сценарий установки ModSecurity как standalone-модуля и сборка Nginx из исходников с включением этого модуля.

Важно: в оригинальном руководстве использовалась Ubuntu 15.04. Эта версия устарела — на продакшене рекомендуется использовать LTS-релизы (например, Ubuntu 20.04 или 22.04) и соответствующие пакеты/ядро.

Требования

Сервер с Ubuntu (в примере 15.04; для безопасности используйте LTS).
Привилегии root или эквивалент sudo.
Доступ в интернет для скачивания исходников и репозиториев.

Совет: если вы на сервере с ограничениями, заранее проверьте наличие компилятора, свободного места и сетевых правил (firewall/NAT).

Что мы сделаем

Обновим ОС и репозитории.
Установим зависимости для сборки.
Скачаем ModSecurity и Nginx.
Соберём и установим ModSecurity и Nginx.
Настроим Nginx и ModSecurity.
Подключим OWASP Core Rule Set (CRS).
Протестируем работу и разберём типовые ошибки.

Все команды, требующие прав, выполняйте под root (sudo -i).

1. Обновление системы

Перед началом убедитесь, что система обновлена:

apt-get update
apt-get upgrade -y

2. Установка зависимостей для сборки

Установим пакеты, необходимые для компиляции Nginx и ModSecurity:

apt-get install -y git build-essential libpcre3 libpcre3-dev libssl-dev libtool autoconf apache2-prefork-dev libxml2-dev libcurl4-openssl-dev

Пояснение: build-essential обеспечивает компилятор и make; libpcre нужен для регулярных выражений; libssl для TLS; libxml/libcurl — для некоторых возможностей ModSecurity.

3. Скачивание ModSecurity и Nginx

Перейдите в /usr/src и клонируйте репозиторий ModSecurity:

cd /usr/src/
git clone https://github.com/SpiderLabs/ModSecurity.git modsecurity

Скачайте исходники Nginx (в примере использована версия 1.8.0 — при необходимости возьмите современную стабильную версию):

wget http://nginx.org/download/nginx-1.8.0.tar.gz

Распакуйте архив (если необходимо):

tar zxvf nginx-1.8.0.tar.gz

4. Сборка и установка ModSecurity и Nginx

Соберём ModSecurity как standalone-модуль, чтобы потом подключить его к Nginx.

cd /usr/src/modsecurity/
./autogen.sh
./configure --enable-standalone-module --disable-mlogc
make

Затем соберём Nginx и укажем путь к модулю ModSecurity:

cd ../nginx-1.8.0
./configure \
  --user=www-data \
  --group=www-data \
  --with-debug \
  --with-ipv6 \
  --with-http_ssl_module \
  --add-module=/usr/src/modsecurity/nginx/modsecurity

make
make install

После установки Nginx обычно оказывается в /usr/local/nginx:

cd /usr/local/nginx/
ll

Вы увидите набор каталогов: conf, html, logs, sbin и т.д.

5. Настройка Nginx

Отредактируйте конфигурацию и укажите пользователя, под которым будет работать процесс Nginx:

cd /usr/local/nginx/
vi conf/nginx.conf

В начале файла раскомментируйте строку user и укажите www-data:

user  www-data;

Создайте символьную ссылку на бинарник nginx, чтобы вызывать его напрямую:

ln -s /usr/local/nginx/sbin/nginx /bin/nginx

Создайте systemd unit-файл для управления сервисом:

cd /lib/systemd/system/
vi nginx.service

Вставьте (пример):

[Service]
Type=forking
ExecStartPre=/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf
ExecStart=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
ExecReload=/usr/local/nginx/sbin/nginx -s reload
KillStop=/usr/local/nginx/sbin/nginx -s stop

KillMode=process
Restart=on-failure
RestartSec=42s

PrivateTmp=true
LimitNOFILE=200000

[Install]
WantedBy=multi-user.target

Перезагрузите systemd и запустите nginx:

systemctl daemon-reload
nginx -t
systemctl start nginx

6. Настройка ModSecurity

Скопируйте рекомендованный конфиг ModSecurity в конфигурационный каталог Nginx и файл unicode.mapping:

cp /usr/src/modsecurity/modsecurity.conf-recommended /usr/local/nginx/conf/modsecurity.conf
cp /usr/src/modsecurity/unicode.mapping /usr/local/nginx/conf/

Откройте файл конфигурации:

cd /usr/local/nginx/conf/
vi modsecurity.conf

Рекомендуемые изменения:

Включите движок правил (по умолчанию в режиме DetectionOnly):

SecRuleEngine On

Увеличьте лимит тела запроса (если ожидаете большие POST/файлы):

SecRequestBodyLimit 100000000

Для аудита выберите concurrent режим и настройте каталог хранения:

SecAuditLogType Concurrent
#SecAuditLog /var/log/modsec_audit.log
SecAuditLogStorageDir /opt/modsecurity/var/audit/

Создайте каталог для аудита и измените владельца на www-data:

mkdir -p /opt/modsecurity/var/audit/
chown -R www-data:www-data /opt/modsecurity/var/audit/

7. Подключение OWASP Core Rule Set

Склонируйте репозиторий CRS:

cd /usr/src/
git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git

Скопируйте базовые правила в каталог конфигураций Nginx:

cd owasp-modsecurity-crs
cp -R base_rules/ /usr/local/nginx/conf/

Добавьте в конец modsecurity.conf загрузку правил и при необходимости удалите конфликтные правила по ID:

#DefaultAction
SecDefaultAction "log,deny,phase:1"

#Load all Rule
Include base_rules/*.conf

#Отключение правил по ID (пример для совместимости с WordPress)
SecRuleRemoveById 981172 981173 960032 960034 960017 960010 950117 981004 960015

Затем включите ModSecurity в конфиг nginx.conf (внутри http или server блока в зависимости от предпочтений):

#Enable ModSecurity
ModSecurityEnabled on;
ModSecurityConfig modsecurity.conf;

Примените изменения:

systemctl restart nginx

8. Тестирование

В примере автор использовал WordPress с уязвимым плагином для проверки XSS и SQLi. Типичный набор шагов для тестирования:

Попробуйте воспроизвести XSS-эксплойт в браузере — ожидается блокировка.
Проверьте записи в логе аудита ModSecurity в /opt/modsecurity/var/audit/ или в системных логах.
Используйте утилиты вроде curl, sqlmap и Burp Suite для моделирования атак.

Примеры результатов:

Блокировка XSS в браузере (пример)

Лог сервера: обнаружение XSS

Попытка SQL-инъекции на странице (браузер)

Лог сервера: попытка SQL-инъекции

Отладка и типичные проблемы

ModSecurity не включается: проверьте путь ModSecurityConfig и права доступа к файлу.
Nginx не стартует после правок: запустите nginx -t для проверки синтаксиса и systemctl status nginx для диагностики.
Правила слишком агрессивны и блокируют легитимный трафик: используйте SecRuleRemoveById и переводите правила в DetectionOnly на этапе тестирования.

Совет: сначала оставляйте SecRuleEngine в режиме DetectionOnly для мониторинга, затем постепенно переводите в On.

Практическое руководство (SOP) для развертывания на проде

Подготовка: резервная копия конфигураций Nginx и приложений.
Установка зависимостей и сборка в тестовом окружении.
Развёртывание CRS в режиме DetectionOnly на тестовом домене.
Наблюдение и настройка правил (исключения по ID).
Плавный перевод в блокирующий режим на реальном трафике.
Организация ротации и архивации аудит-логов.

Чек-листы по ролям

Администратор системы:

Установить зависимости и собрать Nginx/ModSecurity.
Проверить права на каталоги аудита.
Настроить unit-файл systemd и автоматический запуск.

Разработчик/DevOps:

Прогнать тесты на приложение с включённым DetectionOnly.
Идентифицировать ложные срабатывания и предложить исключения.
Обеспечить совместимость с upload/REST API.

Служба мониторинга/инцидентов:

Настроить экспорт логов модулей ModSecurity в SIEM.
Оповещения на критические события и массовые блокировки.

Сценарии тестирования и критерии приёмки

Критерии приёмки:

ModSecurity отвечает на тестовую XSS-атаку блокировкой и записью в лог.
SQLi-эксплойт заблокирован с записью в аудит.
Функциональность приложения не нарушена для обычного пользователя.

Тестовые кейсы:

Отправка простого XSS-пейлоада в форму — ожидается блокировка.
Отправка параметров для SQL-инъекции — ожидается лог и блокировка.
Загрузка больших файлов (>1М) — проверка, что SecRequestBodyLimit корректен.

Альтернативные подходы

Модульный подход: использовать ModSecurity как модуль для Apache, если ваш стек использует Apache.
Проксирование: ставить WAF перед Nginx (например, отдельный reverse proxy с WAF) для централизованной защиты множества сервисов.
Коммерческие WAF: использовать облачные сервисы (Cloudflare, AWS WAF) или аппаратные решения при необходимости SLA и поддержки.

Плюсы сборки из исходников: гибкость, можно подключить нестандартные опции.
Минусы: обязанности по обновлениям, поддержке и безопасности ложатся на вас.

Модели принятия решений и heuristics

Если у вас одно приложение и вы хотите быстро защититься — подключите OWASP CRS и оставьте DetectionOnly на 1–2 недели.
Если ожидается высокий уровень трафика — используйте Concurrent audit logging и настройте ротацию логов.
Для минимизации ложных срабатываний — внедряйте правила постепенно и собирайте телеметрию.

Фактбокс

Проект ModSecurity поддерживает конфигурации для Apache, Nginx и IIS.
В OWASP CRS содержится более 16 000 сигнатур.
Режимы ModSecurity: On (блокирует), DetectionOnly (логирует), Off.

Совместимость и миграция

При миграции с Apache на Nginx проверьте различия в логике и путях конфигурации (правила ModSecurity работают одинаково, но способ подключения отличается).
При переходе на более новые версии Nginx проверьте совместимость сторонних модулей и необходимость пересборки.

Когда ModSecurity может не помочь

Если атака идёт на уровне инфраструктуры (DDoS на сеть) — WAF не решит проблему полностью.
Для бизнес-логики уязвимостей (неочевидные цепочки событий) нужны приложение-ориентированные тесты и фиксы кода.
Если правила устарели — возможны пропуски; регулярно обновляйте CRS.

Безопасность и эксплуатация

Ограничьте права доступа к директории аудита.
Настройте ротацию логов и мониторинг использования диска.
Регулярно обновляйте правила OWASP CRS и ModSecurity.

Краткое резюме

ModSecurity — надёжный инструмент прикладной защиты при правильной настройке. Рекомендуется сначала разворачивать правила в режиме наблюдения, собирать метрики ложных срабатываний и только затем переводить в блокирующий режим. Подходит как для небольших сайтов, так и для крупных инсталляций при должной организации логирования и ротации.

Ссылки и материалы

Глоссарий (одно предложение)

WAF — межсетевой экран уровня приложения для фильтрации/мониторинга HTTP(S)-трафика.

Установка ModSecurity для Nginx на Ubuntu: пошаговое руководство