Чем опасен нефильтрованный трафик: настройка AWS WAF
Нефильтрованный трафик почти никогда не выглядит как атака — он выглядит как рост задержек. Пул обработчиков занимают однотипные запросы к формам, поиску и авторизации, свободные соединения заканчиваются, и приложение перестаёт принимать новые обращения. Очередь растёт, личный кабинет отвечает заметно медленнее, а часть запросов отваливается по времени ожидания ещё до того, как попадёт в бизнес-логику.
Отказ под нагрузкой наступает раньше, чем успевает помочь автомасштабирование: новый экземпляр поднимается дольше, чем длится всплеск, а сам трафик распределён по сотням адресов, поэтому блокировки внутри приложения не дают эффекта. Штатные средства защиты такой перегрузки веб-приложения не видят: подозрительные запросы синтаксически корректны, обращаются к существующим адресам и отличаются только плотностью и разбросом источников.
Настройка AWS WAF переносит фильтрацию на периметр — до того, как запрос займёт обработчик. Управляемые наборы правил отсекают известные классы атак, правила ограничения частоты временно блокируют источник, превысивший порог, а проверка признаков автоматизации отделяет ботов от живых пользователей. Все решения попадают в журнал, поэтому видно, какое правило сработало и не задело ли оно реальных клиентов.
Дальше разбираем, как выстраивается такая защита: где проходит граница фильтрации, как подбираются пороги под профиль вашего трафика и что делать с ложными срабатываниями, чтобы не потерять заказы.
Что даёт управляемая фильтрация запросов на периметре
Фильтрация запросов на периметре решает одну задачу: мусорный трафик не должен доходить до приложения и базы. Без неё поток сканеров, ботов и переборов учётных данных занимает соединения, греет шаблоны и нагружает базу запросами, которые никогда не станут заказом. Нагрузочный профиль становится рваным: полезные пользователи ждут в очереди за теми, кто просто перебирает адреса.
AWS WAF ставится перед приложением и работает на уровне отдельного запроса, а не соединения. Правила описывают, что считать нормой: частота обращений с одного адреса, характерные сигнатуры типовых атак, недопустимые методы и размеры тела. Управляемые наборы правил закрывают распространённые классы автоматизированных атак, а собственные правила добавляют специфику конкретного продукта — например, ограничение на частые обращения к формам входа или к поиску.
Ключевой риск здесь — ложные срабатывания: заблокированный живой пользователь дороже пропущенного бота. Поэтому новые правила сначала включаются в режиме подсчёта и не блокируют трафик, а только пишут события. По журналу отсечённых запросов видно, какие пути и заголовки попали под правило, после чего пороги подкручиваются до включения блокировки.
Результат измеряется тремя числами: доля запросов, отсечённых до приложения, время ответа под пиковой нагрузкой и количество обращений к базе. На типовом вебе доля отсечённого мусора — десятки процентов, и именно она уходит из очереди к приложению. Приложение получает ровный поток, стабильность под нагрузкой перестаёт зависеть от того, кто сегодня сканирует периметр, а журнал остаётся рабочим инструментом, а не архивом.
Варианты защиты периметра: что выбирают и почему
Выбор подхода зависит от предсказуемости легитимного трафика и от того, где приложение принимает запросы. Готовые наборы правил закрывают типовые классы атак почти сразу после подключения, но пороги в них усреднённые и на нестандартных сценариях дают ложные срабатывания. Поэтому старт — режим наблюдения: правила считают совпадения и не блокируют, а логи показывают, какие пути и параметры попадают под подозрение.
Собственные правила фильтрации описывают логику конкретного приложения: частоту обращений к форме входа, допустимые значения параметров, порядок вызовов API. Они точнее, но требуют сопровождения — изменение сценария может потребовать правки условий. Ограничения фильтрации на периметре тоже стоит учитывать: содержимое защищённого канала разбирается не полностью, а распределённый подбор учётных данных виден только в приложении.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Готовые наборы правил | Стандартный веб-проект, нужен базовый барьер быстро | Усреднённые пороги, ложные срабатывания на нестандартных сценариях |
| Собственные правила фильтрации | Нестандартные формы, публичный API, много автоматизированных обращений | Нужны тестовый контур и регулярный пересмотр условий |
| Режим наблюдения | Первый этап внедрения или смена схемы трафика | Не защищает: запросы доходят до приложения |
| Защита только на стороне приложения | Внутренние сервисы, трафик которых не идёт через периметр | Нагрузка на приложение, ресурсы расходуются до проверки |
На практике варианты комбинируют: наблюдение на готовых наборах, затем собственные правила под логику приложения и перевод в блокировку по подтверждённым срабатываниям.
Этапы внедрения: от аудита трафика до передачи регламентов
Настройка AWS WAF, начатая сразу с блокирующих правил, почти всегда задевает живой трафик: под фильтр попадают интеграции, платёжные сценарии и мобильные клиенты. Поэтому мы идём от наблюдения к ограничению — сначала снимаем картину запросов, затем собираем схему правил и только после этого включаем блокировки. Порядок этапов фиксирован: на каждом шаге виден эффект, а откат занимает одну операцию.
- Аудит трафика и точек входа. Собираем статистику по адресам, методам, заголовкам и доле автоматизированных клиентов — получаем базовую линию, с которой сверяем всё дальнейшее.
- Схема правил. Раскладываем угрозы по приоритетам: что блокируем жёстко, что ограничиваем по частоте запросов, что пока только пишем в журнал.
- Включение в режиме наблюдения. Правила считают совпадения, но не мешают посетителям: видно, кого задела бы блокировка, без влияния на конверсию и доступность.
- Разбор ложных срабатываний. По журналам выводим из-под фильтра служебные адреса, обмен с внешними системами и возвраты от платёжных провайдеров.
- Переход в блокировку. Правила включаем по одному, с планом отката и порогом, после которого автоматически возвращаемся в наблюдение.
- Проверка на боевом трафике. Следим за долей отказов, временем ответа и прохождением ключевых сценариев под нагрузкой и в часы пик.
- Передача регламентов. Отдаём карту правил, порядок добавления исключений, дежурные сценарии и точки эскалации.
Конфигурации правил, схема трафика и регламенты реагирования
Настройка AWS WAF не заканчивается включением фильтра — она заканчивается комплектом артефактов, который ваша команда может открыть, прочитать и применить без нас. Ниже — что остаётся у вас после работ: файлы конфигурации, схема прохождения трафика, политики доступа и инструкции на случай инцидента.
- Конфигурация правил — описание каждого набора: что блокирует, что только считает, в каком порядке срабатывает. Хранится декларативно, чтобы правило откатывалось одним изменением.
- Схема прохождения трафика — путь запроса от входной точки до приложения с отмеченными местами проверки и поведением при срабатывании: блокировка, проверка или пропуск с записью.
- Политики доступа — разрешённые источники, служебные диапазоны адресов, порядок исключений для внутренних проверок и партнёрских интеграций.
- Регламент реагирования — кто получает уведомление о всплеске блокировок, как отличить атаку от ошибки в самом правиле и когда правило переводится в режим наблюдения.
- Инструкция по аварийному режиму — пошаговое снятие ограничений, если защита начала отсекать живых пользователей, с указанием ответственного.
- Документация по защите — паспорт конфигурации: дата последнего изменения, кто внёс и зачем, какие маршруты это затрагивает.
- Чек-лист после релиза приложения — условия, по которым новая версия считается корректно защищённой, и порядок проверки на копии окружения.
Правила пересматриваются по расписанию, а не по факту аварии: раз в квартал сверяем конфигурацию с текущей схемой приложения — новые маршруты и формы легко выпадают из-под защиты.
Внедрение на боевом проекте: метрики до и после
Сервис с высокой долей внешнего трафика — каталог с личными кабинетами и формами — держал всю фильтрацию внутри приложения. При всплеске автоматических запросов (парсеры, перебор форм, частые обращения к поиску) пул приложений уходил в перегрузку: очередь росла, часть живых пользователей видела ошибки, а дежурный инженер до получаса искал источник и перезапускал узлы.
Что изменили и что получилось
Фильтрацию подняли на периметр — на AWS WAF. Сначала правила работали в режиме наблюдения: считали, какую долю трафика отсекли бы, и сверяли с логами, чтобы не задеть легитимных роботов. Затем включили блокировки: сигнатурные правила для типовых атак, лимиты по частоте запросов на адрес и на сессию, отдельные наборы для форм и программных интерфейсов, списки исключений для поисковых систем.
Доля запросов, отсечённых на периметре, в часы всплесков доходила до трети входящего потока — приложения перестали видеть этот трафик вовсе. Время реакции на инцидент сократилось с часов до минут: новое правило вводится правкой конфигурации, а не релизом кода. Отдельно настроили оповещения по росту блокировок, чтобы смена шаблона атаки была видна сразу.
Устранённый класс отказов — переполнение пула приложений под автоматическим всплеском и ошибки у живых пользователей следом. Откат — перевод правила в режим счёта или его выключение, без сборки и выката: неверная настройка не роняет сервис.
Чем WAF отличается от защиты от массовых атак и сетевого экрана?
Это три разных слоя, которые смотрят на трафик с разной глубиной. Сетевой экран и правила групп безопасности работают с пакетами: адрес источника, порт, протокол. Для них попытка инъекции в параметре формы или подделка cookie — обычный разрешённый запрос к веб-серверу. Защита от массовых атак включается ещё раньше и оценивает профиль потока: всплеск однотипных обращений отсекается на периметре, до того как он дойдёт до балансировщика и приложений.
AWS WAF разбирает содержимое запроса прикладного уровня: метод, путь, заголовки, параметры строки запроса, тело и cookie. Здесь работают управляемые наборы правил под распространённые классы атак, собственные условия по конкретным формам и адресам, а также правила ограничения частоты обращений по адресу или сессии. Поэтому фильтр запросов ловит то, что для сетевого экрана неотличимо от живого пользователя: эксплуатацию форм, подбор учётных данных, автоматизированный обход каталога.
Граница ответственности проходит по логике приложения. WAF не проверяет права доступа, не валидирует бизнес-правила и не мешает оформить заказ на чужой счёт — это задачи кода. Но и приложение не должно быть единственной линией обороны: без фильтрации на периметре каждая попытка перебора доходит до сервера и расходует его ресурсы наравне с полезным трафиком.
Рабочая схема — сочетание уровней с понятным порядком прохождения. Массовые атаки гасит защита периметра, сетевые правила оставляют открытыми только нужные порты, фильтр запросов ограничивает частоту и отсекает вредное содержимое, приложение проверяет авторизацию и целостность данных. Если слой убрать, нагрузка перераспределяется на следующий — и отказ проявляется там, где его сложнее заметить.
Частые технические возражения перед стартом работ
Возражения перед стартом почти всегда одни и те же, и касаются они не выбора правил, а риска уронить живой трафик. Фильтр стоит между пользователем и приложением, поэтому ошибка в настройке видна сразу — в отличие от задач, которые можно выкатить и починить по ходу. Ниже собрали сомнения, которые инженерные команды поднимают на первой же встрече.
Включение фильтра остановит сервис на время настройки?
Нет. Первый этап разворачиваем в режиме наблюдения: правила считают совпадения и пишут их в журнал, но не блокируют запросы. Трафик идёт как обычно, а мы получаем реальную картину — какие запросы приложение принимает и кто из легитимных клиентов попадает под подозрение. Перевод в блокирующий режим — отдельный шаг, уже после разбора журнала.
Ложные блокировки отрежут живых клиентов?
Ради этого и нужен режим наблюдения. По журналу видно, какие правила срабатывают на живых пользователях, и для них настраиваются исключения — точечно, по пути запроса или признаку клиента, а не отключением правила целиком. Порог поднимаем там, где правило шумит, и оставляем жёстким там, где оно ловит реальные попытки обхода.
Нужен ли доступ к коду и репозиторию?
Нет. Работаем с конфигурацией фильтра и точками входа: достаточно знать домены, маршруты и заголовки, которые приложение ожидает. Доступ к исходникам и базам данных не требуется — правки в коде в задачу не входят.
Кто разбирает срабатывания после запуска?
Разбор ведём по журналу: смотрим, что именно сработало, отделяем автоматические сканеры от живых сессий и решаем — оставить правило, сузить его или внести адрес в исключения. После запуска отдаём регламент: какие отчёты смотреть, с какой периодичностью и по каким признакам понимать, что правило пора править.
Обсудим задачу и вернёмся с планом внедрения
Чтобы вернуться с оценкой работ, а не с общими словами, нам нужны исходные данные по трафику и точки входа приложения. Опишите задачу в свободной форме — что защищаете, с какими инцидентами уже столкнулись и какой результат считаете успешным; остальное соберём сами в ходе разговора.
На созвоне уточним и попросим прислать:
- схему точек входа — домены, балансировщики, CDN и цепочка запроса до самого приложения;
- выгрузку логов за типовые сутки и за пиковый интервал: по ним видно профиль запросов и долю служебного шума;
- перечень известных инцидентов — сканирование, подбор учётных данных, всплески однотипных запросов;
- список легитимных ботов, партнёрских интеграций и мониторинга, которые блокировать нельзя;
- текущие правила ограничения частоты и то, где они сейчас настроены — на балансировщике, в приложении или нигде;
- требования к режиму работы: начинаем с наблюдения или сразу с блокировки;
- регламент доступа и согласования изменений — кто держит панель и как утверждаются правила.
По этим данным мы понимаем объём работ и порядок этапов. Вернёмся с планом внедрения: что настраиваем в режиме наблюдения, за какой срок собираем статистику по ложным срабатываниям, в какой момент переключаем правила в блокирующий режим и как откатываемся, если какое-то правило задело реальных пользователей.
Обсудим задачу — присылайте логи и схему, и мы вернёмся с оценкой и планом внедрения по этапам.
