Защита сайта через CDN и WAF: когда она действительно нужна

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

Что умеет и чего не умеет WAF

OWASP определяет WAF как прикладной firewall для HTTP-приложений [1]. Он может находить характерные признаки SQL-инъекций, межсайтового выполнения сценариев, обхода путей, вредоносных загрузок и других запросов, описанных правилами. WAF также применяют для ограничения частоты, временной блокировки известного вектора атаки и защиты устаревшего компонента до выхода исправления.

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

Когда защита оправдана

• Публичный сайт выполняет операции, а не только показывает страницы. Формы, личный кабинет, поиск, загрузка файлов, API, корзина и платежный сценарий увеличивают поверхность атаки.
• У сайта есть заметные всплески или атаки. Распределённая граница и anti-DDoS помогают не доводить весь нежелательный объём до одного VPS.
• Исходный сервер нельзя быстро масштабировать. CDN отдаёт подходящий статический контент из кеша и снижает число обращений к origin, но правила кеширования должны исключать персонализированные ответы.
• Нужно закрыть прямой доступ к origin. Внешняя защита мало полезна, если атакующий может обратиться к реальному IP в обход неё.
• Есть обязательства отраслевого стандарта. Например, PCI DSS 6.4.2 требует для применимых публичных веб-приложений автоматизированное техническое решение, которое постоянно обнаруживает и предотвращает веб-атаки, активно работает, обновляется и ведёт журнал [2]. Это требование относится к области применимости PCI DSS и не означает универсальную обязанность поставить WAF каждому сайту.

Для небольшого статического сайта без форм отдельный WAF может быть избыточен. Но базовая защита DNS, TLS, панели управления и origin всё равно нужна. Решение принимают по цене простоя, чувствительности операций, истории атак и способности команды сопровождать правила.

Архитектура без очевидных обходов

Типовой путь выглядит так: DNS направляет посетителя на edge-площадку, там завершается TLS, применяются сетевые ограничения и WAF, после чего разрешённый запрос передаётся на origin. Кешируемый ответ может быть сохранён на границе. Такая схема требует нескольких отдельных решений.

Защитить origin

Исходный сервер должен принимать веб-трафик только от доверенной инфраструктуры провайдера либо проверять дополнительную аутентификацию между edge и origin. Списки адресов нужно обновлять безопасно. Реальный IP не следует раскрывать через старые DNS-записи, служебные поддомены и прямые ссылки. При этом административный доступ организуют отдельным каналом, чтобы авария внешней защиты не лишила команду управления.

Корректно передавать адрес клиента

После проксирования сервер видит адрес edge-узла. Приложение и журналы должны доверять заголовку реального клиента только от известных прокси. Без этого атакующий способен подставить заголовок самостоятельно, а слишком простое ограничение по IP начнёт блокировать всех посетителей как один источник.

Не кешировать персональные ответы

Кабинет, корзина, B2B-цены и ответы API нельзя помещать в общий кеш без корректного ключа и явных правил. Проверяйте cookies, заголовки авторизации, параметры языка и региона. Ошибка CDN здесь опаснее отсутствия ускорения: один пользователь может получить данные другого.

Как подключать WAF по этапам

1. Составьте карту маршрутов. Перечислите страницы, формы, API, webhook, загрузки, административные адреса, поисковых роботов и интеграции. Для каждого укажите методы, размер тела, авторизацию и ожидаемую частоту.
2. Зафиксируйте исходные показатели. Сохраните распределение кодов ответа, задержки, объём трафика, частые адреса и бизнес-конверсию. Иначе после включения будет трудно доказать влияние защиты.
3. Настройте DNS и TLS с планом отката. Уменьшение TTL заранее может ускорить контролируемое переключение, но конкретные значения выбирают по текущей зоне и провайдеру. Не удаляйте прежний маршрут до проверки нового.
4. Включите правила в режиме наблюдения. Официальные рекомендации Google Cloud Armor советуют сначала проверять правила на приложении и устранять нерелевантные срабатывания до выхода из preview mode [3]. Такой подход применим и к другим WAF, если они поддерживают логирование без блокировки.
5. Настройте исключения узко. Не отключайте весь класс защиты из-за одной формы. Ограничьте исключение конкретным маршрутом, параметром или идентификатором правила и добавьте тест.
6. Переводите в блокировку постепенно. Начните с наиболее точных сигнатур и явно вредных сценариев. Следите за входом, заказом, оплатой, поиском, загрузкой и API.
7. Закройте обход origin. Только после подтверждения стабильного трафика ограничьте прямой доступ и проверьте аварийный административный канал.
8. Настройте оповещения и регламент. Владелец должен понимать, кто разбирает всплеск блокировок, как временно ослабить точное правило и как сохранить доказательства атаки.

OWASP ModSecurity и Core Rule Set дают распространённую основу для правил, но сам движок не является готовой политикой конкретного сайта [4]. Набор нужно обновлять, тестировать после релизов и сопоставлять с изменениями API.

Отдельно о DDoS и CDN

WAF не обязан выдерживать объёмную сетевую атаку сам по себе. Для такого риска важны пропускная способность распределённой сети, фильтрация до origin и процедура взаимодействия с провайдером. В руководстве CISA по объёмным DDoS-атакам отмечается, что правильно подготовленный CDN способен смягчить объёмную атаку на веб-сервисы [5]. Слово «правильно» существенно: если origin открыт напрямую или динамический маршрут обходит edge, защита останется неполной.

CDN также не гарантирует ускорение каждой страницы. Динамический запрос всё равно идёт к приложению и получает дополнительный сетевой участок. Эффект проверяют отдельно для кеш-хитов, кеш-промахов и персонализированных ответов, а не по одной синтетической цифре.

Проверка результата

До включения блокировки подготовьте контрольную матрицу:

• обычный посетитель открывает страницы, отправляет форму и проходит ключевой сценарий;
• авторизованные пользователи не видят чужие кешированные данные;
• служебные webhook и API проходят с ожидаемой аутентификацией;
• Googlebot и Яндекс Робот получают публичные страницы, robots.txt, Sitemap и ресурсы;
• заведомо вредный запрос из согласованного безопасного теста фиксируется, а затем блокируется;
• лимиты не мешают нескольким пользователям за общим NAT;
• обращение к origin в обход edge невозможно с публичной сети;
• журнал содержит правило, действие, маршрут и идентификатор запроса без избыточной записи чувствительных данных;
• откат DNS и правил описан и проверен ответственным.

Повторяйте матрицу после изменений формы, API, авторизации, кеша и набора WAF. Рост блокировок может означать атаку, новую ложную сигнатуру или поломку клиента — решение принимают по журналам и бизнес-метрикам.

Источники

[1] OWASP — Web Application Firewall.

[2] PCI Security Standards Council — PCI DSS v4.0 SAQ A-EP, requirement 6.4.2.

[3] Google Cloud — Cloud Armor best practices.

[4] OWASP — ModSecurity и WAF Projects.

[5] CISA — Capacity Enhancement Guide: Volumetric DDoS Mitigations.