Почему одного WAF недостаточно. Роль эшелонированной защиты при DDoS-атаках

Почему одного WAF недостаточно. Роль эшелонированной защиты при DDoS-атаках

Атаки на веб-приложения становятся мощнее и сложнее, а их последствия — разрушительнее. В 2024 году на платформе NGENIX было отражено 70 000 атак — 90% на уровне приложений. А максимальная интенсивность DDoS-атаки на уровне L7 составила 518 400 RPS (Requests Per Second).

В условиях нарастающих угроз многие компании всё ещё рассматривают WAF (Web Application Firewall) как единственный инструмент для защиты веб-приложений. Но в современных условиях WAF может стать слабым звеном, когда подвергается высокой нагрузке из-за нелегитимного трафика, который не был отфильтрован раньше.

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

WAF — не панацея

WAF (Web Application Firewall) — это система анализа и фильтрации веб-трафика на прикладном уровне модели OSI (L7), предназначенная для блокировки вредоносных HTTP-запросов. WAF анализирует содержимое запросов и выявляет такие атаки, как SQL- и PHP-инъекции, межсайтовый скриптинг (XSS) и другие угрозы из списка OWASP Top-10 и не только.

Важно понимать, что WAF функционирует исключительно на уровне приложений (L7) и не обеспечивает защиту на более низких уровнях модели OSI — сетевом (L3) и транспортном (L4). Следовательно, он не способен противостоять DDoS-атакам, нацеленным на исчерпание сетевых ресурсов или пропускной способности каналов передачи данных, таким как UDP / ICMP / DNS Amplification или SYN / TCP flood. В таких сценариях WAF просто «не видит» атаку.

Однако и при защите L7 неверно полагаться только на WAF. В последние несколько лет атаки на уровне приложений исчисляются сотнями тысяч RPS. Одним из факторов, способствующих росту мощности таких атак, стала эксплуатация уязвимостей основополагающих протоколов веба. Например, атака Rapid Reset позволяет злоумышленникам значительно увеличить интенсивность генерации запросов. Эти атаки способны создать нагрузку такого уровня, при котором WAF может оказаться неэффективным. Дополнительные сложности создают атаки на протоколы TLS/SSL, связанные с ресурсоёмкими с точки зрения вычислительной инфраструктуры рукопожатиями (handshake), многочисленными открытиями соединений и повторными согласованиями TLS. Медленные запросы, такие как Slowloris или Slow POST, заставляют WAF удерживать сотни или тысячи открытых сессий, что приводит к истощению оперативной памяти и лимитов соединений. В таких условиях кластеры WAF могут перегружаться, что проявляется в виде ошибок, тайм-аутов и критической деградации производительности. 

WAF in-house vs облачный WAF

Желание ряда организаций развёртывать ПО WAF по модели on-premise (на собственной инфраструктуре) обусловлено стремлением к полному контролю над работой систем защиты либо необходимостью выполнять регуляторные требования. Однако эксплуатация on-premise WAF, обслуживающего нагрузку порядка 10 000 RPS, требует значительных инвестиций в закупку оборудования, лицензий и сопутствующей инфраструктуры, что, по оценкам рынка, может достигать десятков миллионов рублей в год. Конкретные расходы, как капитальные (CAPEX), так и операционные (OPEX), зависят от архитектурных особенностей, требований к масштабируемости и уровню обслуживания. 

Современный уровень DDoS-атак на L7, достигающий сотен тысяч RPS, уже выходит за рамки возможностей классических on-premise-решений и требует дополнительного масштабирования для обработки такой нагрузки. Для обеспечения работоспособности ПО WAF по модели on-premise необходимы: резервирование каналов с высокой пропускной способностью, развёртывание мощных кластеров с «запасом» на пиковые нагрузки, высокая производительность SSL/TLS-обработки и частое обновление правил, адаптация к новым типам атак, непрерывный мониторинг, инцидент-менеджмент и штат высококвалифицированных специалистов. 

При этом необходимо осознавать, что пиковая нагрузка — как легитимная, так и нелегитимная — явление непостоянное. Легитимная нагрузка возникает в зависимости от специфики бизнес-сегмента — например, в электронной коммерции это могут быть сезонные распродажи, Black Friday, Cyber Monday или другие праздничные кампании; для вузов — периоды публикации результатов ЕГЭ и новости о поступлении. 

Нелегитимная нагрузка представлена DDoS-атаками, которые могут принимать различные формы: от объёмных сетевых атак (UDP Flood, ICMP Flood) до высокоинтенсивных (HTTP Flood) с использованием ботнетов, создающих потоки ложных запросов, нацеленных на истощение ресурсов сервера и нарушение доступности веб-ресурса. 

Такой контраст легитимного и нелегитимного пикового трафика требует эластичных и масштабируемых решений, способных одновременно фильтровать вредоносные атаки и безошибочно обрабатывать легитимные запросы. 

Однако при отсутствии пиковой нагрузки избыточная инфраструктура, зарезервированная под неё, может простаивать большую часть времени, продолжая требовать ресурсов для поддержки и обновления. Таким образом, компания может оказаться перед выбором: постоянно переплачивать за «запас прочности» или рискнуть, недооценив пиковую нагрузку, и столкнуться с простоем в критически важный для бизнеса момент. 

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

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

Эшелонированная защита: как снизить нагрузку на WAF

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

Этот принцип особенно актуален в 2025 году, когда атаки становятся мультивекторными: злоумышленники комбинируют сетевые и прикладные методы, чтобы обойти одиночные средства защиты.

В NGENIX эшелонированная защита включает пять уровней.

Описание эшелонов защиты на платформе NGENIX (рис.)

Рисунок. Эшелоны защиты на платформе NGENIX

Эшелон 1. Защита от DDoS на каналах оператора

Первый уровень фильтрует масштабные атаки, направленные на пропускную способность сети: DNS Amplification, ICMP flood, UDP flood, SYN flood и другие разновидности объёмных атак. Эти DDoS блокируются на уровне канала у оператора, не доходя до инфраструктуры клиента.

Эшелон 2. Защита от DDoS на L3/L4 за счёт маскировки IP-адреса

Второй эшелон также защищает от DDoS-атак на уровне L3/L4 путём маскировки IP-адреса. Платформа NGENIX в этом случае выполняет функцию реверс-прокси: IP-адрес инфраструктуры заказчика изменяется на IP-адрес платформы. Если злоумышленник не знает реальный IP-адрес цели атаки, он будет атаковать серверы NGENIX — благодаря высокопроизводительной инфраструктуре в 7 Тбит/с мы сможем отразить такую атаку.

Эшелон 3. Защита от DDoS на L7

Система NGENIX анализирует HTTP(S)-трафик по 50+ метрикам, распознаёт аномалии и применяет различные меры митигации в зависимости от выявленной аномалии: от дополнительных проверок запроса до блокировок источника. Проверка происходит без отправки данных в центры очистки трафика — каждая нода является фильтрующей.

Эшелон 4. Защита от ботов

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

Благодаря такой схеме защиты можно блокировать нежелательный автоматизированный трафики атаки на бизнес-логику: парсинг, брутфорс, скальпинг, SMS-бомбинг.

Эшелон 5. Облачный WAF — защита от эксплуатации уязвимостей и атак на API

Только после прохождения всех предыдущих эшелонов предварительно очищенный трафик поступает на WAF — финальный уровень эшелонированной защиты. Здесь выполняется глубокий анализ запросов для предотвращения целевых атак: SQL-инъекций, XSS, CSRF, Remote File Inclusion, SSRF, других угроз из OWASP Top-10 и не только.

В чём ценность эшелонированного подхода?

Каждый эшелон фильтрует часть нелегитимного трафика до того, как он достигнет WAF, а значит:

• уменьшается потребность в резервировании мощностей;
• повышается отказоустойчивость и стабильность приложений;
• сокращаются затраты на эксплуатацию и человеческий ресурс;
• появляется возможность выбрать оптимальную лицензию WAF на легитимный трафик.

В заключение

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

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

Реклама. ООО «ССТ», ИНН: 7733546298, Erid: 2Vfnxwjx28H