DDoS защита для сайта: фильтрация трафика и правила на периметре

DDoS защита для сайта начинается с трезвого разделения целей. Атакующий обычно стремится не «сломать сервер навсегда», а вывести конкретный слой из строя: исчерпать пропускную способность, перегрузить соединения, забить пул воркеров или заставить приложение тратить ресурсы на каждый запрос.

По практическим задачам обычно выделяют три группы векторов:

• L3/L4: ICMP/UDP/fragmented traffic, SYN floods, flood по TCP/UDP. Узкое место часто на стороне сети и сетевого стека.
• L7: HTTP(S) flood, обход кеша, атаки на поиск, пагинации, формы, авторизацию, загрузку. Узкое место — приложение, WAF-логика, базы данных.
• Приложения и зависимости: когда сайт сам по себе «держится», а падают очереди, кэши, внешние API, БД или DNS.

От этого зависит, где именно должна жить фильтрация трафика и какие правила на периметре вы сможете безопасно применять. Например, на уровне сети вы не отличите человека от бота по «смыслам запроса», но на уровне HTTP это уже возможно через поведение, заголовки, сессию и частоты по ключам.

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

Фильтрация трафика: где и как принимать решения

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

На практике архитектуру удобно мыслить как уровни:

• Edge: входная точка до вашего балансировщика или до приложений. Здесь эффективны сети anycast/CDN и специализированные scrubbing-центры.
• Perimeter/LB: балансировщик, фронтовые прокси, firewall’ы и L4/L7-терминаторы. Здесь полезны rate limiting, ограничение соединений, правила для сервисов и протофильтры.
• Application/WAF: распознавание L7, проверка протокольной корректности, сигнатуры, аномалии, поведенческие проверки.
• Backend: защита зависимостей. Даже при успешной фильтрации нельзя допустить лавину запросов, которая «разнесёт» БД или очередь.

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

Классификация трафика и признаки аномалий

Для фильтрации трафика нужны признаки. Универсального списка нет, но типовые сигналы, которые реально применяются, выглядят так:

• Превышение частоты по IP/подсети/ASN: рост запросов, соединений, новых сессий.
• Несоответствие профилю протокола: необычные комбинации заголовков, неправильные последовательности, странные тайминги.
• Ненормальное соотношение статусов: резкий рост 4xx/5xx может указывать на ботов, неверные форматы или попытки эксплуатации.
• Разрыв «нормальной» структуры нагрузки: атака часто бьёт по конкретным путям или параметрам, а не по всему сайту равномерно.

Важно не превращать фильтрацию в «черный ящик». Если правила не объясняются данными (логи, метрики, распределения), вы рано или поздно получите ложные срабатывания и потерю трафика.

Технические механизмы на уровне L4

На L4 полезны меры, которые уменьшают стоимость для вас и увеличивают стоимость для атакующего:

• Ограничение числа одновременных соединений и темпа новых соединений.
• Защита от SYN flood на сетевых уровнях (через инфраструктуру балансировщика/ОС/edge, где это поддерживается).
• Фильтрация по гео/ASN и сегментам сети — как дополнительный слой, а не единственная защита.
• Терминация TCP и контроль keep-alive: боты часто злоупотребляют долгими соединениями.

Если у вас есть несколько публичных сервисов (например, API и публичный сайт), не объединяйте общие лимиты «на всё». Дайте каждому сервису отдельный набор правил на периметре, иначе вы либо перегрузите API, либо случайно ограничите нормальный веб.

Механизмы на уровне L7: от простого к сложному

L7-фильтрация обычно строится вокруг двух вещей: ограничение частоты и верификация поведения.

Подходы, которые хорошо работают в реальной эксплуатации:

• Rate limiting по ключу: IP, user-agent, токену сессии, идентификатору API-ключа, комбинациям. Чем точнее ключ, тем меньше ложных банов.
• Нормализация запросов: контроль длины, допустимых методов, корректности Content-Type, схемы URL.
• WAF-правила по общим классам атак: внедрение, обходы, аномальные payload’ы, массовые ошибки парсинга.
• Challenge/verification: когда вы видите сомнительное поведение, требуете дополнительный шаг (капча, токен, JavaScript-верификация). Это повышает цену атаки на вашей стороне.

Самая частая ошибка на L7 — давить слишком рано и слишком широко. Например, если вы ограничите «по IP» для публичной страницы логина, вы рискуете заблокировать нормальных пользователей за NAT или мобильные сети. Лучше сочетать лимиты с поведенческими признаками: частота по пути, успешность сессий, согласованность cookie.

Правила на периметре: ACL, allow/deny и управление сервисами

Правила на периметре — это то, что вы настраиваете до того, как трафик попадет в приложение. Здесь важны две цели: снизить нагрузку и сделать управление предсказуемым во время инцидента.

Периметр обычно включает firewall/ACL, security groups, правила балансировщика, настройки reverse proxy и любые «ворота», через которые проходит внешний трафик.

Базовая структура правил

Хорошие правила на периметре строятся по приоритету:

1. Запретить заведомо лишнее. Это не обязательно «банить весь мир», но исключить то, что вашему сервису не нужно.
2. Разрешить необходимое по портам/протоколам/путям (если доступно).
3. Применить лимиты и контрольные проверки для каждого класса трафика.
4. Отдельно обработать админ-доступ и служебные эндпойнты.

Отдельная рекомендация по админке: не оставляйте админ-доступ в общей зоне. Allowlist по статичным IP администраторов или через VPN/бастион. Если админка общая и «строгих» правил нет, атакующий часто пытается не только перегрузить, но и получить доступ к инфраструктуре.

Где использовать allowlist, а где лучше обойтись лимитами

Allowlist работает хорошо в двух случаях:

• Интерфейс используется ограниченной группой и у вас есть стабильные источники (IP корпоративной сети, VPN, bastion).
• Сервис закрыт от большинства клиентов и действительно предназначен для ограниченного круга.

Для массового публичного трафика allowlist почти всегда плохо масштабируется: вы либо забаните легитимных пользователей, либо усложните сопровождение так, что правила станут «мертвым грузом».

Поэтому типичный компромисс выглядит так:

• Для публичного сайта: deny по явному мусору и аномалиям, затем rate limiting и проверка поведения.
• Для API: жесткие правила на методы, схемы, формат запросов, лимиты по ключам (API-ключам, user-id при наличии).
• Для админки/внутренних сервисов: allowlist или закрытие через VPN и отдельные каналы.

Сегментация периметра по сервисам и доменам

Если у вас один домен, один балансировщик и «единый набор правил», вы неизбежно будете балансировать между риском и удобством. В условиях атаки это приводит к тому, что лимиты либо слишком мягкие для атакуемого сервиса, либо слишком жесткие для всего остального.

Лучше заранее разнести правила по сегментам:

• Отдельные правила для фронта и для API.
• Отдельные лимиты для эндпойнтов, где высокая вычислительная стоимость (поиск, генерация отчётов, загрузка больших данных).
• Отдельные настройки для загрузки статических файлов и для динамики.

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

Пороговые значения и политика деградации

Правила на периметре должны учитывать не только «высокий» поток, но и вашу желаемую политику деградации. В бою вы хотите не угадывать, а снижать ущерб.

Практичный принцип: вводите не только блокировки, но и уровни «замедления»:

• Сначала ограничить темп и новые соединения.
• Затем ужесточить проверку поведения для подозрительных классов.
• В крайнем случае — отключить тяжёлые пути или отдать упрощенные ответы (например, вернуть кэш вместо пересчёта).

Так вы сохраняете доступность ключевой функции сайта, даже если второстепенные операции страдают.

Настройка политик под L4/L7: WAF, rate limit и поведенческие сигналы

Переход от общей защиты к прикладным политикам обычно упирается в то, как вы применяете лимиты и где проводите границы между «плохими» и «хорошими» запросами.

Ниже — рабочий каркас, который помогает настроить DDoS защита для сайта без хаоса.

Rate limiting: выбор ключа и направление ограничений

Rate limiting почти всегда главный инструмент фильтрации трафика. Но он почти всегда же становится источником ложных блокировок, если ключ выбран неверно.

Частые варианты ключей:

• IP (или подсеть): проще всего, но хуже для мобильных и корпоративных NAT.
• По сессии: лучше, если есть устойчивый идентификатор, например cookie с ранним получением токена.
• По API-ключу: идеально для B2B и интеграций.
• По сочетаниям признаков: например, IP + путь, токен + user-agent, ASN + endpoint.

Направление ограничений тоже важно:

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

WAF: что включать и как не перегрузить его в атаке

WAF полезен для L7, но он же может стать мишенью: атакующий заставляет вас прогонять дорогостоящую логику на каждом запросе. Поэтому настройка должна быть «устойчивой по затратам».

Практический порядок:

• Сначала включите базовые проверки протокола: допустимые методы, корректность формата, длины.
• Затем — правила по наиболее частым классам атак на вашу поверхность.
• Далее — правила по аномалиям (скорость ошибок, несоответствия шаблонов).

Если ваш WAF позволяет раздельно управлять весом правил (например, «легкие» проверки и «тяжелые»), переводите тяжёлые проверки в режим, который включается только для подозрительных запросов или для конкретных путей.

Поведенческие сигналы: как повышать точность без банов по IP

Поведенческие сигналы помогают отличать «сканера» от обычного пользователя. Для этого используются:

• Логическая последовательность запросов: например, сначала получение страницы и только потом POST на форму.
• Согласованность cookie или заголовков (если они реально используются вашим фронтом).
• Соответствие rate-профилю: нормальный пользователь редко делает тысячи повторов одного и того же запроса с одинаковыми параметрами.

Важный момент: не полагайтесь на один признак. Комбинация «частота + путь + тип ошибки + несоответствие сессии» обычно точнее, чем «частота по IP».

Управление кешем и обход атаки через кэш

Неочевидная часть DDoS защиты для сайта — это кэширование. Атака может быть построена так, чтобы «убить» динамику: повторять запросы, которые всегда считаются заново.

Если у вас есть CDN или reverse proxy с кешем, продумайте:

• Какие пути и заголовки кэшируются.
• Как защищается origin при ошибках.
• Как реагировать на всплески, когда кэш отсутствует (например, временно увеличить TTL для отдельных безопасных ресурсов или отдавать статический fallback для части страниц).

Кэш снижает нагрузку даже в сценариях, когда фильтрация трафика работает неидеально, потому что часть запросов не доходит до приложения.

Процесс реагирования: мониторинг, триггеры и воронка в бою

Даже идеальные правила не спасают, если вы не знаете, что именно происходит и как быстро переключиться на «боевой режим». Поэтому DDoS защита для сайта должна включать процесс реагирования, а не только настройки.

Какие метрики собирать в первую очередь

Для инцидента с DDoS важны метрики не «в целом», а с привязкой к слоям:

• Сетевой уровень: входящий трафик по интерфейсу/edge, доля ошибок на уровне подключения, рост соединений.
• Балансировщик/LB: новые соединения, очередь, таймауты, распределение по статусам.
• Приложение: рост времени ответа, количество ошибок приложения, загрузка пула воркеров.
• База данных/очереди: рост запросов, блокировки, задержки, деградация индексов.

Добавьте метрики по конкретным классам запросов: top endpoints, top status codes, top error signatures. Это ускоряет выбор правильных правил на периметре.

Триггеры: как понять, что пора ужесточать

Триггеры должны переводить вас от наблюдения к действию. Например:

• Рост входящего трафика выше ожиданий + стабильный процент 200 — возможно, атака пока «давит» на сетевой слой, но приложение ещё живо. Тогда сначала смотрите edge/L4.
• Рост 4xx/5xx на конкретных путях + рост времени ответа — вероятна L7 атака на эндпойнты. Здесь включайте L7-лимиты и WAF-профили.
• Рост ошибок в БД при относительно стабильном количестве запросов — возможно, это не «flood», а попытка дорогих запросов (search/report). Тогда приоритизируйте правила по этим путям и добавьте ограничение вычислительных операций.

Хорошая практика — заранее согласовать сценарии: какие признаки ведут к каким действиям. Иначе в момент атаки вы будете принимать решения «по ощущениям», а это почти всегда медленнее.

Воронка действий: от мягкого к жесткому

В бою нужна предсказуемая воронка:

1. Подтвердить класс атаки по метрикам и логам (L3/L4 или L7).
2. Включить быстрые меры, которые меньше рискуют легитимным пользователем: временные лимиты, фильтрация по путям, ограничение новых соединений.
3. Перевести тяжёлые проверки в режим точности: активировать challenge/verification только для подозрительных классов.
4. Защитить origin: уменьшить нагрузку через кеш, ограничить вычислительные операции.
5. Если атака не прекращается: перейти к более жёсткой блокировке или перенастройке маршрутизации через специализированную защиту.

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

Runbook: что именно менять и в каком порядке

Соберите runbook заранее и привяжите его к конкретным параметрам ваших систем. В runbook должны быть:

• Ссылки на дашборды и логи.
• Перечень команд или настроек, которые можно быстро включить/выключить.
• Диапазоны допустимого ужесточения (какой лимит увеличиваем, какой уменьшаем, какие правила не трогать).
• Критерии окончания атаки и шаги отката.

Откат — отдельная часть процесса. После инцидента некоторые администраторы «оставляют на всякий случай» усиленные ограничения, и сайт постепенно начинает терять пользователей.

Тестирование и постоянная настройка: как добиться стабильности

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

Что тестировать до запуска защиты

Перед тем как применять правила на периметре в проде, проверьте:

• Логи: сможете ли вы понять, сработало ли правило и почему.
• Нагрузка: не станет ли ваша фильтрация дороже самого нападения.
• Ложные срабатывания: на тестовой группе, с типичными сценариями пользователя.
• Деградация: что будет, если лимит выбран слишком жёсткий. Увидите ли вы «тихий» рост ошибок или резкий спад доступности.

Тестирование лучше проводить по моделям сценариев, а не «по одному запросу». В реальной атаке ключевые проблемы появляются при высокой параллельности, повторах и устойчивой аномалии.

Режимы тренировок и имитация атак

Обычно используют имитацию нагрузки и сценариев, чтобы проверить реакцию системы:

• L4 flood по соединениям и темпу (на тестовом окружении или через безопасные каналы).
• L7 flood по конкретным путям (поиск, авторизация, API).
• Смешанные сценарии: часть трафика «нормальная», часть — аномальная.

Цель — не «победить» симулятор, а проверить, что ваши триггеры и правила срабатывают в нужной последовательности. Если воронка действий не собирается, инциденты будут превращаться в ручную настройку «на горячую».

Непрерывное улучшение правил по данным

После каждого события обновляйте базу знаний:

• Какие признаки были ранними и полезными.
• Какие правила сработали корректно, а какие дали много ложных срабатываний.
• Какие лимиты оказались слишком мягкими, чтобы остановить деградацию.

В хорошей настройке каждое правило имеет происхождение: проблема в логах и метриках, затем изменение параметров, затем подтверждение результатом.

Типичные ошибки при DDoS защите для сайта

Ниже список ошибок, которые чаще всего встречаются в проектах, где DDoS защита для сайта внедряется «по чеклисту», без привязки к архитектуре и поведению приложения.

1. Ставить одинаковые лимиты на весь сайт

Публичные страницы, поиск, API и авторизация живут разной жизнью. Одинаковая политика ломает либо безопасность, либо доступность.

2. Опора только на блокировку по IP

NAT, мобильные операторы и прокси делают IP ненадёжным ключом. Лучше комбинировать IP с путями, сессией и типом запроса.

3. Игнорировать дорогие эндпойнты

Можно защитить «сетевой поток», но проиграть на вычислениях: поиск без ограничений, отчёты, генерация контента, тяжёлые запросы к БД.

4. Не готовить откат

Правила на периметре часто включают временно, но в реальности остаются надолго. В итоге вы получаете длительную деградацию, которую списывают на рост аудитории.

5. Перегружать WAF в атаке

Если WAF вынужден разбирать каждый запрос одинаково тяжело, вы фактически усиливаете эффект атаки. Тяжёлые проверки должны включаться селективно.

6. Отсутствие runbook и триггеров

Без заранее согласованных действий вы теряете минуты на выяснение «что происходит», а в DDoS это критично.

7. Никаких проверок на ложные срабатывания

Даже одна ошибка в allow/deny логике может закрыть легитимный сегмент пользователей. Тестирование сценариев и наблюдаемость обязательны.

8. Не разделять уровни защиты по слоям

Проблема на L7 требует L7-подходов, но нередко включают только L4 лимиты. Или наоборот: на сетевом floods включают WAF-правила и остаются без эффекта.

Как построить рабочую схему защиты: практический план

Если нужно действовать по шагам, можно собрать план внедрения фильтрации трафика и правил на периметре так, чтобы результат был воспроизводимым.

1. Зафиксируйте поверхность атаки

Составьте список критичных эндпойнтов, методов и сценариев. Отметьте, где ответы дорогие и где есть кэш.

2. Определите, где будете фильтровать

Выберите точки: edge, периметр/LB, WAF, backend. Решите, какие типы атак закрываются на каждом слое.

3. Настройте базовые правила на периметре

Включите запреты на лишнее, разделите сервисы и домены, закройте админку через allowlist/VPN. Добавьте ограничения соединений и темпа для публичных зон.

4. Введите rate limiting с правильными ключами

Начните с ключей, которые реально стабильны для легитимных клиентов: сессии или API-ключи. Для публичных страниц используйте комбинации признаков, чтобы снизить риск банов.

5. Настройте WAF и L7 политики по принципу селективности

Проверьте базовую протокольную корректность, затем расширяйте правила на основе реальных сигнатур атак. Тяжёлые проверки — только для подозрительных классов.

6. Подготовьте воронку реагирования

Создайте триггеры, runbook и критерии отката. Проверьте, что вы знаете, какой слой усиливаете первым и какой шаг делает следующий.

7. Проведите тренировки и улучшайте правила

Сделайте тестовые прогонки, имитируйте аномалии, измерьте реакцию системы. По итогам — корректируйте параметры лимитов и условия challenge.

Заключение: фильтрация трафика и правила на периметре как основа устойчивости

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

Если вы сейчас настраиваете защиту впервые, начните с периметра и базовых лимитов по сервисам, затем добавьте L7 политики и селективные проверки. Параллельно подготовьте runbook и откат: это часто определяет, сколько пользователей вы сохраните в реальной атаке.