Защита от DDoS-атак: разбор по слоям

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

Поэтому честный ответ — не один продукт и не одно правило в межсетевом экране. Разные атаки расходуют разные ресурсы, и каждый слой закрывает свой вид отказа. Ниже — слои в порядке, в котором они действительно останавливают трафик, и регламент на случай, когда атака уже началась.

Если сайт лежит прямо сейчас, переходите к разделу о действиях во время атаки: остальное можно прочитать позже.

Что именно истощает атака

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

Семейство атак	Примеры	Что заканчивается	Где останавливать
Объёмные	UDP-флуд, усиление через DNS и NTP, «ковровые» бомбардировки	Канал связи	У провайдера или в сети фильтрации
Протокольные	SYN-флуд, флуд установленных соединений	Таблицы соединений на серверах и балансировщиках	Лимиты на периметре и настройки ядра
Прикладные	HTTP-флуд, медленные запросы, обход кэша, злоупотребление API	Процессор, воркеры, соединения с базой	CDN и WAF, кэш, лимиты по маршрутам

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

Почему защита начинается выше вашего сервера

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

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

Первый слой: фильтрация до источника

Публичный трафик идёт через CDN или обратный прокси со встроенной защитой от DDoS: Cloudflare, CloudFront, Azure Front Door, Gcore, Fastly.
У провайдера стоит уточнить ёмкость фильтрации, порог срабатывания и режим работы — постоянный или по детекту.
Предпочтительнее anycast: он разносит объёмную атаку географически, а не заставляет один дата-центр её впитывать.
Считать CDN достаточной защитой — самая распространённая ошибка. Это первый слой из восьми.

Второй слой: спрятать настоящий адрес

Этот шаг пропускают чаще всего, и он молча обнуляет первый слой. Если злоумышленник узнал реальный адрес сервера, он просто обходит CDN и бьёт напрямую — схема, известная как обращение в обход прокси.

Где утекает адрес источника

Архивы DNS. Старые записи, оставшиеся с тех пор, как сервис ещё не был за прокси.
Журналы прозрачности сертификатов. Выпущенные сертификаты на имя хоста источника.
Поддомены. Почтовый шлюз, VPN, тестовый стенд часто указывают на тот же сервер.
Заголовки писем. Исходящая почта может нести адрес источника в служебных строках.
Устаревшие записи. Почтовые, SPF и текстовые записи, ведущие на инфраструктуру вне CDN.

Что делать: сменить адрес источника после включения прокси, разрешить на портах 80 и 443 только опубликованные диапазоны CDN и раз в квартал перепроверять видимость снаружи. Отдельно проверяют, отвечает ли сервер на прямой запрос по адресу, минуя домен.

Третий слой: WAF для прикладного уровня

Сетевой экран видит корректно установленное соединение и пропускает его. WAF читает сам запрос — а прикладные атаки живут именно там: искажённые заголовки, попытки эксплуатации, боты на формах входа и поиска.

Начинают с управляемых наборов правил: базовый набор OWASP плюс аналитика вендора. Затем добавляют своё: предел размера тела на загрузке файлов, проверку административных путей, лимиты для дорогих маршрутов. Включать правила стоит в режиме наблюдения на неделю, иначе первое ложное срабатывание отрежет живых клиентов.

Четвёртый слой: ограничения скорости

Это самый дешёвый контроль и самый часто настроенный неправильно. Правила только на веб-сервере бесполезны против трафика, который забивает канал раньше. Правила только по адресу источника почти не мешают ботнету с тысячами адресов.

Лимиты ставят на трёх уровнях:

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

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

Пятый слой: настройки TCP-стека

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

включить SYN-cookies;
поднять очередь ожидания и согласовать её с реальной конкурентностью;
сократить время удержания полуоткрытых соединений;
ограничить число одновременных подключений с одного адреса на периметре.

Значения из чужой статьи без измерения собственной базовой линии обычно делают хуже. Менять их стоит по одному, с замером до и после.

Шестой слой: кэш вместо вычислительных ресурсов

Запрос, отданный из кэша, не доходит до сервера — значит, не занимает воркер и не открывает соединение с базой. Всё, что может быть статикой, должно быть статикой: изображения, стили, скрипты и HTML для неавторизованных посетителей.

Под атакой важны две детали. Обход кэша — это приём атаки: случайные параметры в ссылке заставляют каждый запрос идти на источник, поэтому CDN настраивают игнорировать незначащие параметры. И доля попаданий в кэш — метрика безопасности: если в инциденте она падает с 85% до 20%, вы платите ресурсами источника за трафик атаки.

Седьмой слой: метрики и оповещения

Защищаться от того, чего не видно, невозможно. До инцидента фиксируют, как выглядит норма: запросы в секунду, входящий и исходящий трафик, доля ошибок 4xx и 5xx, задержка 95-го процентиля, число соединений, самые нагруженные адреса.

Оповещения ставят на отклонение от нормы, а не на абсолютные числа. Рост запросов в пять раз при стабильной доле ошибок — скорее удачная публикация, чем атака. Ровный поток при растущей задержке и числе соединений — признак истощения состояния. Данные о потоках на сетевом уровне вместе с журналами приложения дают обе картины.

Восьмой слой: регламент и типичные ошибки

Регламент пишут до инцидента, а не в момент, когда сайт уже недоступен: под давлением люди первым делом делают не то.

Порядок действий, когда атака уже идёт

Убедиться, что это атака. Посмотреть источники, характер запросов, адреса и географию, сравнить с легальной кампанией.
Определить уровень. Забитый канал указывает выше по течению, истощение соединений — на сетевой уровень, рост процессора на конкретных маршрутах — на прикладной.
Сразу открыть обращение провайдеру. Фильтрация включается не мгновенно, поэтому заявку подают параллельно с диагностикой.
Включить периметровые средства. Режим повышенной защиты, управляемые правила WAF, ужесточённые лимиты, проверка браузера на самых атакуемых маршрутах.
Закрыть источник. Убедиться, что он принимает трафик только от CDN, и заблокировать прямые обращения по адресу.
Сказать клиентам. Сначала страница состояния, потом каналы поддержки: молчание вредит сильнее самой атаки.
Сохранить доказательства. Журналы, дампы трафика и метки времени нужны провайдеру, страховой и для возможного разбирательства.

Что чаще всего ломает защиту

Блокировка диапазонов самого CDN — сайт падает полностью.
Лимиты только по адресу источника: ботнет меняет адреса, смотреть нужно и на поведение.
Защищённая главная и открытое API: атакующие находят дорогой маршрут.
Игнорирование сетевого уровня: SYN-флуд не виден в журналах HTTP.
Отсутствие защиты источника: CDN впитывает поток, а реальный адрес добивают напрямую.
Регламент, который никто не читал: под давлением выбирают неверное действие первым.

Сколько это стоит

Вариант	Порядок цен	Кому подходит
Начальный тариф CDN	От нуля до нескольких тысяч рублей в месяц	Блоги, сайты услуг, небольшие сервисы
Защита облачного провайдера	Обычно входит в инфраструктуру	Проекты, уже живущие в этом облаке
Управляемый WAF с защитой от DDoS	От нескольких десятков тысяч рублей в месяц	Сервисы, где простой стоит выручки
Выделенная сеть фильтрации	Корпоративные договоры	Высокорисковые отрасли, игры, финансы

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

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

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

Можно ли полностью предотвратить DDoS-атаку? Нет. Отправить трафик на публичный сервис может кто угодно. Реалистичная цель — впитать и отфильтровать поток, сохранив доступность для обычных пользователей, и именно это даёт многослойная защита.

Достаточно ли одного CDN? CDN закрывает объёмные атаки и часть прикладного мусора, но не решает проблему открытого адреса источника, злоупотребления дорогими маршрутами и истощения соединений. Это один слой.

Как отличить атаку от всплеска трафика? Смотрят на состав, а не на объём. Всплеск из одной географии или на один адрес, с необычными клиентами, растущей задержкой и нулевой конверсией — атака. Всплеск по обычным источникам чаще означает, что сработала публикация.

Что делать небольшой компании в первую очередь? Вывести трафик за CDN с фильтрацией, закрыть адрес источника, включить управляемые правила WAF и написать регламент на страницу. Такой порядок закрывает частые атаки за минимальные деньги.

Нужен ли отдельный провайдер защиты? Только если простой стоит дороже договора. Начинают с тарифа CDN, измеряют реальный риск и переходят выше, когда экономика это оправдывает.

Защита от DDoS: слои обороны на практике