WAF (Web Application Firewall)

На что WAF реально смотрит

WAF расшифровывается как web application firewall (веб-брандмауэр приложений).

WAF анализирует содержимое HTTP-запросов, а не только то, должно ли соединение быть разрешено, проверяя известные паттерны атак, такие как попытки SQL-инъекции или payload межсайтового скриптинга, прежде чем эти запросы вообще дойдут до приложения.

Почему это дополнение, а не замена

WAF перехватывает многие известные паттерны атак, но реально уязвимое приложение всё равно может быть скомпрометировано через запрос, не совпадающий ни с одним известным плохим паттерном. Исправление первопричины уязвимости всё равно важно, даже при наличии WAF.

Варианты WAF и ограничение частоты для веб-серверов разобраны здесь: руководство по безопасности nginx.

WAF на самом сервере: ModSecurity и OWASP CRS

Самая распространённая самостоятельная связка это ModSecurity с набором правил OWASP Core Rule Set (CRS): общими правилами обнаружения атак, таких как SQL-инъекции, межсайтовый скриптинг и включение локальных файлов. Для nginx нужны ModSecurity v3 (libmodsecurity) и отдельный коннектор ModSecurity-nginx, который собирается как статический или динамический модуль (для динамической сборки нужны исходники, соответствующие версии работающего nginx). После сборки включают его две директивы:

server {
    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/main.conf;
}

Путь приведён для примера. В файле правил начните с SecRuleEngine DetectionOnly. Согласно справочному руководству ModSecurity, значение по умолчанию Off, а DetectionOnly обрабатывает правила, но никогда не выполняет блокирующих действий вроде block или deny. Дайте ему поработать, изучите оповещения и только потом переключайте на On. Это безопасный путь для действующего сайта: ложно сработавшее правило в DetectionOnly стоит строки в журнале, а не клиента. Сборка модуля под точную версию nginx также означает, что WAF добавляет работы при каждом обновлении nginx. Сравните это с облачным WAF перед сервером: модуль не нужен, но ваш трафик проходит через третью сторону.

Оценка аномалий, уровни паранойи и ложные срабатывания

CRS не блокирует запрос по одному совпадению. В режиме оценки аномалий каждое сработавшее правило добавляет баллы по серьёзности (по умолчанию critical 5, error 4, warning 3, notice 2), а запрос отклоняется, только когда сумма достигает входящего порога, по документации CRS равного 5 по умолчанию. Поэтому одного совпадения уровня critical достаточно для блокировки.

Строгость задаётся отдельно уровнем паранойи от 1 до 4. Уровень 1 описан как базовая защита с малым числом ложных срабатываний, уровень 2 подходит сайтам с реальными данными пользователей и требует настройки, а уровни 3 и 4 дают много ложных срабатываний и предназначены для особо ценных целей. Повышайте уровень по одному шагу.

Когда легитимный запрос помечен, найдите в журнале ошибок идентификатор правила и совпавшие данные и добавьте самое узкое исключение, которое работает, вместо правки файлов CRS, потому что обновления их перезаписывают. Исключение на этапе конфигурации, помещённое после подключения CRS, выглядит так:

SecRuleRemoveById 920230

Правило 920230 взято из примера в документации, поэтому подставьте идентификатор из вашего журнала. Помните, что WAF дополняет защиту nginx и своевременные обновления, но не заменяет их.

Связанные термины: nginx, Атака на уровне приложения, Rate limiting, Firewall, Обратный прокси (reverse proxy), SQL-инъекция.