WAF и фаервол: как выбрать защиту сайта без самообмана

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

Чем сетевой фаервол отличается от WAF

Я разделяю два вопроса: кто может установить соединение с сервером и что разрешено передать веб-приложению внутри этого соединения. Обычные правила сетевого фаервола отвечают на первый: учитывают адреса, порты, протоколы и состояние соединений. В рамках защиты серверов и сайтов я сначала проверяю именно доступность служб. Открытая наружу панель управления или база данных не становятся безопаснее от наличия фильтра перед публичным сайтом.

Под словом «фаервол» продают разные средства. Современные комплексы могут совмещать сетевую фильтрацию, анализ приложений и другие проверки. Поэтому утверждение «любой фаервол видит только порт» неверно. Здесь я сравниваю обычную сетевую политику и специализированный WAF. Например, iptables — средство настройки фильтрации в Linux, а firewalld и ufw помогают управлять правилами; перечисление этих названий ещё не описывает фактическую защиту конкретного сервера.

Разрешённое веб-соединение может нести как нормальную заявку, так и попытку SQL-инъекции. Правило, которое разрешает соединение к веб-службе, не проверяет, как приложение построит запрос к базе. WAF добавляет проверку HTTP: разбирает доступные ему части запроса и ищет нарушения заданной политики. Разрешить доставку конверта и проверить его содержимое — разные операции. Штамп «порт открыт правильно» не служит санитарным сертификатом вложения.

У сетевой политики остаётся собственная работа: закрыть ненужные службы, отделить административный доступ от публичного сайта, разрешить только необходимые связи. Я отдельно проверяю правила у хостинга и на самом сервере: ограничения в одном месте не доказывают, что остальные входы закрыты. Владелец сайта должен получить список разрешённых соединений с назначением каждого. Если назначение неизвестно, вопрос остаётся открытым до выяснения, а не превращается в вечное исключение.

• Сетевой экран: разрешённые соединения и доступ к службам.
• WAF: проверка веб-запросов по правилам.
• Приложение: права пользователей и безопасная обработка данных.

Что именно проверяет WAF в HTTP и HTTPS

WAF может анализировать адрес запроса, параметры, заголовки и тело, если это поддерживает выбранное решение и разрешает настройка. Он сопоставляет данные с правилами: например, с признаками SQL-инъекций или XSS. Это дополнительная преграда перед приложением. Она полезна против распознаваемых атак, но не означает, что фильтр понимает назначение каждой формы и все допустимые действия сотрудника. Эту часть приходится описывать и проверять нам.

Первый важный факт из экспертной базы: HTTPS сам по себе не мешает проверке, если WAF получает расшифрованный HTTP. При установке перед сайтом я выясняю, где завершается TLS и как дальше идёт запрос. Проверка содержимого зашифрованного потока без доступа к расшифрованным данным невозможна. Затем отдельно проверяю защиту соединения до исходного сервера. Сертификат в браузере подтверждает только свою часть схемы, а не правильность всех последующих переходов.

Дальше я проверяю полноту подключения: какие домены и точки входа обслуживает WAF, где находится API, как приходят запросы от внешних систем. Если часть обращений попадает прямо на исходный сервер вне этой схемы, правила WAF к ним не применяются. Ограничения прямого доступа к серверу настраиваю с учётом выбранного сервиса и служебных проверок. Нарисованная на схеме стрелка не заставляет настоящий трафик двигаться по ней — у схемы пока нет административных прав.

Нормализация в WAF нужна для сопоставления разных представлений данных при анализе. Она не превращает опасный запрос в безопасный код приложения. Также нельзя обещать отсутствие задержек: обработка запросов и дополнительные сетевые переходы расходуют ресурсы. Я сравниваю отклик на одинаковых операциях до подключения и после него, отдельно смотрю отправку форм и загрузку файлов. Средняя скорость главной страницы не показывает, работает ли обмен документами под обычной нагрузкой.

• Проверить точку завершения TLS и доступ WAF к HTTP.
• Составить перечень защищаемых доменов и операций.
• Проверить фактический маршрут запросов к серверу.
• Сравнить отклик и ошибки на рабочих сценариях.

От каких атак WAF помогает, а где нужны другие меры

Я не принимаю таблицы, где напротив любой угрозы стоит уверенная галочка. Срабатывание зависит от правил, режима, доступных данных и самой атаки. Нужны как минимум три ответа: что средство проверяет, что оно может остановить и какая задача остаётся у приложения или инфраструктуры. Иначе в одну строку легко попадают сканирование портов, ошибка прав доступа и перегрузка интернет-канала — хотя устраняются они разными способами.

С SQL-инъекцией я работаю и на стороне кода: пользовательские значения должны передаваться в параметризованные запросы, а не склеиваться с SQL. Подробности разобраны в статье про защиту от SQL-инъекций. Заблокированный тест подтверждает работу определённого правила на конкретном запросе. Он не доказывает отсутствие других уязвимостей. Обновление CMS и исправление опасной обработки данных остаются отдельными задачами.

У CSRF другой механизм: браузер пользователя может отправить нежелательное действие с уже действующей сессией. Для защиты от CSRF-атак я проверяю механизмы самого приложения, включая проверку защитных токенов там, где они нужны. Ошибку доступа к чужому документу тоже нельзя закрыть общей сигнатурой: сервер должен проверять права на запрошенный объект. Специализированные функции WAF могут помогать, но надпись на коробке не подтверждает их наличие и настройку.

С DDoS я сначала уточняю, что исчерпывается: канал связи, возможности сетевой обработки или ресурсы приложения. Локальный фильтр не возвращает пропускную способность канала, уже заполненного атакой. Для такого случая нужна защита до сервера и договорённость с площадкой. Ограничение частоты HTTP-запросов может помогать на уровне приложения, если функция есть и настроена. При этом я проверяю общий выходной адрес офиса и автоматический обмен: грубый лимит способен наказать штатных пользователей.

Как включить WAF и не сломать рабочие формы

Для примера я беру ModSecurity с набором правил OWASP Core Rule Set. ModSecurity — движок WAF; CRS — набор правил к нему. Это не встроенный штатный модуль Apache, описанный в каталоге его собственных модулей. Вариант подключения зависит от веб-сервера и сборки. Поэтому универсальную команду установки я здесь не выдаю: сначала нужно определить окружение, совместимый способ подключения и место, откуда действительно читается конфигурация.

В ModSecurity для начального наблюдения я использую директиву SecRuleEngine DetectionOnly. Правила при этом обрабатываются, но их блокирующие действия не выполняются. После разбора результатов допускается переход к SecRuleEngine On: движок исполняет настроенные правила, включая блокирующие действия при выполнении их условий. Одна эта строка не подключает CRS и не создаёт правила. Режим наблюдения с полным журналом атак всё ещё остаётся режимом наблюдения. Видеорегистратор не научился тормозить машину.

Второй факт из базы — Paranoia Level в CRS определяет строгость набора проверок. Повышение уровня добавляет более строгие правила и увеличивает риск ложных срабатываний. Я выбираю уровень с учётом данных сайта и времени на разбор ошибок. Выкручивать строгость сразу до предела без проверки форм — плохой способ измерять безопасность. Политика, при которой пользователи не могут сохранить документ, быстро заканчивается просьбой отключить весь фильтр.

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

Перед включением блокировки я прогоняю вход, сохранение материалов, отправку заявок, загрузку файлов и обмен с внешними системами. Каждое исключение получает описание причины и проверку, которая воспроизводит штатную операцию. После обновления CMS, её расширений или правил возвращаюсь к этим сценариям. Для отдельного разбора HTML-полей есть статья про настройку WAF против XSS. Здесь моя задача шире: принять всю схему защиты, а не только один фильтр.

• Определить окружение и способ подключения.
• Начать с наблюдения и собрать штатные операции.
• Разобрать срабатывания и оформить узкие исключения.
• Включить блокировку и повторить проверки.
• Закрепить ответственного за журнал и обновления.

Условный разбор: как я принимаю защиту сайта

Разберу ООО «Вертикаль-Сервис» из исходного примера как условную компанию. Это учебный сценарий, а не отчёт о реальном взломе. В нём есть сайт на Apache, CMS, редактор материалов, заявки и обмен с учётной системой. Для приёмки я задаю пять штатных проверок: вход, сохранение текста с HTML, отправку заявки, загрузку файла и обмен данными. Число относится к выбранному набору сценариев, а не к статистике защищённости.

Начинаю с фиксации исходного состояния: какие службы доступны, какие компоненты нужно обновить, как выполняется каждая из пяти операций без новых правил. Отдельно готовлю возврат конфигурации и проверенную копию сайта. Если есть признаки уже случившегося взлома, сначала разбираюсь с ними. Подключение WAF не удаляет посторонние файлы и не отменяет последствия утечки. Для поиска таких проблем нужен аудит безопасности сайта, а не соревнование по количеству новых запретов.

Дальше в сценарии прохожу два режима: наблюдение и блокировку. Допустим, сохранение HTML вызвало событие правила XSS. Я сопоставляю время, операцию, идентификатор правила и проверяемое поле, воспроизвожу сохранение на стенде и проверяю причину. Только после этого добавляю ограниченное исключение и повторяю операцию. Утверждение «в логах стало чисто» меня не устраивает: так же выглядит журнал, который перестал получать события. Тишина бывает и после выключения сигнализации.

Приёмка состоит из проверяемых результатов. Все пять штатных сценариев должны завершаться успешно в режиме блокировки. Безопасная синтетическая проверка под выбранное тестовое правило должна давать ожидаемое событие WAF; если правило блокирующее, запрос должен отклоняться. Я связываю событие с конкретным запросом и подтверждаю результат на стороне приложения. Ещё проверяю маршрут трафика и порядок возврата конфигурации. Ни один из этих пунктов не заменяет соседний.

Срок пилота я привязываю к полному рабочему циклу сайта: нужно дождаться операций редактора и предусмотренного расписанием обмена. Обещать одинаковые три дня для любой системы до её осмотра нечестно. Итог условного разбора — протокол пяти проверок, подтверждённое тестовое срабатывание, перечень исключений и назначенный ответственный. Это критерии готовности, а не выдуманный результат работ. Обещания «любая инъекция остановлена» в таком протоколе не будет.

• Пять штатных операций проходят после включения блокировки.
• Тестовое правило срабатывает ожидаемым образом.
• Запросы идут через предусмотренную точку проверки.
• Для исключений указаны причина и область действия.
• Возврат конфигурации и ответственность описаны.

Когда нужен WAF и на что тратить деньги сначала

Я ставлю WAF выше в списке приоритетов, когда сайт принимает данные, работает на CMS с расширениями, содержит личный кабинет или публичный API. Особенно полезен дополнительный фильтр, когда исправление приложения требует времени и уже есть подходящее проверенное правило. Но наличие формы само по себе не означает неизбежный взлом без WAF. Решение зависит от доступных функций, качества кода, ценности данных и того, кто будет поддерживать защиту.

У статического сайта без серверной обработки меньше прикладных точек входа, но остаются веб-сервер, учётная запись размещения, публикация файлов и доступность площадки. Если форма на странице отправляет данные во внешний сервис, обработчик существует — просто находится в другом месте. Я выясняю, кто за него отвечает. Установка дополнительных средств без понятной задачи не заменяет эту проверку. Даже очень строгий фильтр на пустой странице не защищает пароль от панели хостинга.

При ограниченном бюджете я сначала закрываю ненужный сетевой доступ, проверяю обновления, административные учётные записи и восстановление из резервной копии. Затем определяю прикладные риски и требования к WAF. Формат выбираю по устройству сайта: внешний сервис, модуль перед приложением или реализация внутри CMS. Плагин тоже может содержать WAF; решают место выполнения и возможности, а не способ установки. При любом варианте я заранее назначаю человека, который разберёт заблокированную рабочую операцию.

У подрядчика я прошу перечень защищаемых точек входа, список проверок, правила обновления, порядок реакции на ложное срабатывание и условия поддержки. Стоимость лицензии, настройки и обслуживания сервера нужно разделять в предложении. В опубликованном прайсе «АйТи-Фреш» обслуживание сервера начинается от 7 000 ₽/мес; это цена этой услуги. Стоимость самого WAF и работ по его внедрению определяем после оценки сайта. Приравнивать их к цене серверного обслуживания было бы той же ошибкой, что обещать весь ремонт по цене одной детали.

Частые вопросы