Что останавливает WAF
- Инъекции. SQL, команды операционной системы, шаблоны — в параметрах, заголовках, cookie и теле запроса.
- Межсайтовый скриптинг (XSS). Попытки внедрить JavaScript через формы, комментарии и параметры.
- Обход путей и доступ к служебным файлам. Запросы к .env, .git, архивам резервных копий, конфигурациям.
- Загрузка опасных файлов. Исполняемые скрипты под видом картинок и документов.
- Известные уязвимости CMS. Сигнатуры атак на популярные плагины и модули, которые обновляются по мере публикации уязвимостей.
- Сканеры. Автоматические инструменты поиска уязвимостей узнаются по характерным последовательностям запросов.
Как избежать ложных срабатываний
Главный риск любого WAF — заблокировать нормальный запрос. Например, статья про SQL в блоге содержит строки, похожие на инъекцию. Поэтому новые правила сначала работают в режиме наблюдения: в журнале видно, что было бы заблокировано, и можно добавить исключение для конкретного поля или страницы до включения блокировки.
Виртуальные патчи
Когда в популярной CMS или плагине находят уязвимость, обновление сайта может занять дни: нужен разработчик, тестирование, согласование. Виртуальный патч — правило WAF, которое блокирует конкретный способ эксплуатации уязвимости. Оно не заменяет обновление, но закрывает окно, в котором сайт был бы уязвим.
Отчёт для разработчиков
Если WAF регулярно ловит атаки на один и тот же параметр, это сигнал: возможно, там действительно есть уязвимость. В личном кабинете такие случаи собираются в отчёт по путям и параметрам, который можно передать разработчикам.
Вопросы и ответы
Нужен ли WAF, если сайт на Tilda или другом конструкторе?
Конструкторы сами отвечают за безопасность своей платформы. WAF больше нужен сайтам на собственном коде и CMS, которые вы обновляете сами.
Может ли WAF замедлить сайт?
Разбор обычного запроса правилами занимает очень малую долю времени ответа. Самые тяжёлые проверки, например тела больших запросов, применяются только к тем путям, где они нужны.