Коротко. Защита от DDoS строится слоями: фильтрующий прокси или CDN с анти-DDoS принимает трафик на себя и отсекает мусор до вашего сервера; WAF режет вредоносные запросы к приложению; ограничение частоты (rate limiting) гасит флуд; скрытый реальный IP не даёт бить в обход защиты. Один приём не спасает — работает именно комбинация. Объёмные атаки (забитый канал) фильтруются только снаружи, у кого канал толще; прикладные (нагрузка на приложение) можно частично гасить и на своём сервере. Главное правило: подключать защиту нужно до атаки, а не во время — под обстрелом это часы простоя. Ниже — из чего складывается оборона и как её выстроить.
Что значит «защититься от DDoS»
Цель защиты — не «победить ботнет», а сделать вас невыгодной целью: чтобы атака стоила нападающему дороже, чем приносит. DDoS не взламывает сайт, он исчерпывает ресурс — канал, процессор, память, лимит соединений, пул базы, — и легитимные пользователи перестают получать ответ. Значит, защита — это про то, чтобы мусорный трафик не доходил до дефицитного ресурса.
Защита от DDoS — не одна кнопка, а эшелон. Задача каждого слоя — отсеять как можно больше мусора как можно раньше, чтобы до вашего сервера долетали только настоящие пользователи.
Что делать, если атака уже идёт прямо сейчас, — отдельная тема; здесь речь о подготовке. Разбор действий под атакой — в статье «DDoS-атака: что делать в первый час».
Слои защиты
1. Фильтрующий прокси / CDN с анти-DDoS
Базовый и самый важный слой. Трафик идёт не напрямую на сервер, а через сеть защиты (Cloudflare, Qrator, DDoS-Guard, StormWall и аналоги): она фильтрует запросы своей ёмкостью и отдаёт вашему серверу только чистый трафик. Только этот слой спасает от объёмных атак — свой канал в 1 Гбит/с не отфильтрует десять гигабит, это должен делать тот, у кого канал магистральный. Как работает раздача через сеть узлов — в статье про CDN.
2. WAF — файрвол приложений
Отсекает вредоносные и подозрительные запросы к самому приложению по правилам: аномальные заголовки, инъекции, ботов. Против прикладных (L7) атак это ключевой инструмент, попутно закрывающий и попытки взлома. Как устроен — в разборе WAF.
3. Ограничение частоты запросов (rate limiting)
Простое правило «не больше N запросов в секунду с одного IP» срезает значительную часть флуда ещё на входе. Настраивается и на веб-сервере, и на уровне защиты. Подробнее — в статье про rate limiting.
4. Скрытый реальный IP
Если настоящий адрес сервера засветился (в истории DNS, почтовых заголовках, на поддоменах), защиту обходят прямым ударом мимо прокси. После подключения фильтрации реальный IP меняют и нигде не публикуют — иначе все предыдущие слои бесполезны.
5. Запас ёмкости и деградация
Кэш для отдачи статики, готовая «лёгкая» версия сайта, автоматическое масштабирование — всё, что позволяет пережить всплеск, а не упасть от первого же гигабита. Пусть под нагрузкой работает витрина, но работает.
Объёмные и прикладные атаки защищаются по-разному
| Тип атаки | Что бьют | Чем защищаться |
|---|---|---|
| L3/L4 — объёмные | Канал и сетевой стек (UDP/SYN-flood, амплификация) | Только внешняя фильтрация: анти-DDoS-провайдер / CDN с толстым каналом |
| L7 — прикладные | Приложение (HTTP-flood на тяжёлые страницы) | WAF + rate limiting + кэш; частично гасится на своём сервере |
Частые ошибки
- Подключать защиту во время атаки. Онбординг под обстрелом — часы простоя. Фильтрующий прокси ставят заранее.
- Оставить реальный IP на виду. Самая частая причина, почему «защита не помогла» — атакующий бьёт мимо неё по прямому адресу.
- Полагаться на один слой. Только rate limiting не спасёт от объёмной атаки; только CDN без WAF пропустит прикладную. Нужна комбинация.
- Не иметь плана и мониторинга. Половина ущерба — время, пока никто не заметил. Об этом ниже.
Свой или управляемый: что выбрать
Малому и среднему сайту почти всегда выгоднее управляемая защита — облачный анти-DDoS/CDN, где фильтрацией занимается провайдер. Своя защита (железо, настройка, дежурство) оправдана у крупных площадок с постоянной угрозой. Начинать разумно с облачного прокси + WAF + rate limiting — это закрывает подавляющее большинство атак на типичный сайт.
Лучшая защита от DDoS — та, что уже включена до атаки. Подключённый заранее фильтр превращает атаку из аварии в строчку в логах.
Мониторинг: узнать об атаке первым
Даже с защитой важно знать, что началась атака или деградация. Мониторинг доступности проверяет сайт из нескольких точек каждые 30–60 секунд и шлёт алерт при первом же сбое или росте времени ответа — по графику видно начало атаки ещё до отказа. Настроить можно в enterno.io; заодно проверьте свою текущую защиту и заголовки сканером безопасности.
Частые вопросы
Cloudflare/бесплатный CDN защитит от любой атаки?
От большинства объёмных — да, в этом сила облачной фильтрации. Но бесплатные тарифы имеют пределы, а прикладные (L7) атаки на тяжёлые страницы требуют ещё и WAF с правилами и rate limiting. И всё это бесполезно, если реальный IP сервера открыт — его обойдут напрямую.
Можно ли защититься совсем бесплатно?
Частично: бесплатный CDN-прокси + rate limiting на nginx + скрытый реальный IP закрывают значительную часть угроз для небольшого сайта. Для серьёзной или целевой атаки бесплатных лимитов не хватит — понадобится платный анти-DDoS.
Нужна ли защита маленькому сайту?
Да. Заказ атаки на небольшой сайт стоит дешевле подписки на кино, поэтому под ударом регулярно оказываются региональные магазины, клиники и сервисы — чаще всего в сезон и по заказу конкурентов. Базовый эшелон (прокси + rate limiting + скрытый IP) стоит настроить заранее.
Чеклист на память
- Защита — это слои: фильтрующий прокси/CDN → WAF → rate limiting → скрытый IP → запас ёмкости.
- Объёмные атаки фильтруются только снаружи; прикладные — можно гасить и на сервере.
- Скрытый реальный IP обязателен, иначе защиту обойдут напрямую.
- Подключать защиту нужно до атаки, а не во время.
- Даже с защитой держите мониторинг — чтобы узнать об атаке первым.