Сайт может перестать отвечать не только из-за взлома или неудачного обновления. Иногда на него направляют столько обращений, что нормальные пользователи перестают попадать внутрь: страницы открываются через раз, корзина не оформляет заказ, API отвечает с задержкой, а админка висит на самом неприятном месте. Для владельца результат простой: сервис недоступен, поддержка получает жалобы, бизнес теряет заявки и деньги.
DDoS расшифровывается как distributed denial of service, по-русски распределенный отказ в обслуживании. Распределенный означает, что запросы идут не с одного компьютера, а с множества устройств. В атаке могут участвовать зараженные роутеры, камеры видеонаблюдения, серверы, домашние компьютеры, прокси-сети и арендованные облачные машины. Один адрес заблокировали, поток через минуту пришел из других сетей.
Важно не путать DDoS со взломом. Злоумышленникам не обязательно входить в панель управления или красть базу, чтобы причинить ущерб. Достаточно перегрузить канал, соединения, веб-сервер, приложение или базу данных.
Как работает перегрузка: от канала до базы данных
Любой запрос проходит несколько участков. Клиент узнает IP-адрес через DNS, отправляет трафик к серверу или CDN, устанавливает соединение, передает HTTP-запрос, ждет работу приложения и получает ответ. На каждом шаге есть ограниченный ресурс: канал, таблица соединений, процессы веб-сервера, память, процессор, пул подключений к базе.
Атакующий выбирает место, где нагрузка даст максимум вреда. Если канал узкий, его забивают UDP- или ICMP-трафиком. Если сервер плохо держит соединения, давят SYN Flood или медленными подключениями. Если приложение выполняет тяжелые операции, бьют по поиску, фильтрам каталога, GraphQL, восстановлению пароля, экспорту CSV или генерации PDF.
Пример с интернет-магазином показывает механику без лишней теории. Главная страница может отдаваться из кэша, а поиск по каталогу каждый раз дергает базу, пересчитывает фильтры и сортирует товары. Если боты отправляют тысячи запросов именно в поиск, CDN пропускает обращения дальше, а база начинает отвечать медленно.
Отсюда главный вывод для настройки: сетевые атаки нужно фильтровать до вашей инфраструктуры, а атаки на приложение надо гасить правилами ближе к HTTP. Локальный firewall полезен, но он получает проблему поздно, если мусорный трафик уже занял канал.
Уровни L3, L4 и L7 без лишней теории
В описаниях DDoS-защиты часто встречаются L3, L4 и L7. Это не названия атак, а уровни, на которых работает сеть. Если совсем просто: L3 отвечает за доставку пакетов по IP-адресам, L4 за соединения и порты, а L7 за то, что происходит уже внутри сайта или приложения. Деление нужно не для красоты, а для выбора защиты: сетевой мусор фильтруют у провайдера или анти-DDoS-сервиса, а вредные HTTP-запросы разбирают через WAF и правила для сайта.
L3, или сетевой уровень, ближе всего к IP-адресам и маршрутам. На этом уровне атакующий пытается забить канал большим количеством пакетов. Например, при ICMP Flood на адрес летит поток служебных сетевых сообщений, а при UDP Flood сервер получает массу UDP-пакетов на разные порты. Сайт может быть исправен, но нормальный трафик до него просто не добирается, потому что канал занят мусором.
L4, или транспортный уровень, связан с TCP и UDP. TCP нужен для обычных веб-соединений, где клиент и сервер договариваются о передаче данных. При SYN Flood сервер получает много запросов на начало TCP-соединения и тратит ресурсы на ожидание продолжения. При ACK Flood атакующий шлет поток TCP-пакетов, которые заставляют сетевое оборудование и защитные системы проверять состояние соединений. Такие атаки бьют не по странице сайта, а по способности сервера и сети принимать подключения.
Отдельный тип сетевых атак связан с усилением трафика. При DNS amplification или NTP amplification злоумышленник использует сторонние серверы, которые отвечают на маленький запрос большим ответом. В итоге жертва получает поток данных, который намного крупнее исходных запросов атакующего. WAF почти не помогает в таких случаях, потому что полноценного HTTP-запроса к сайту еще нет. Нужны Anycast, центры очистки трафика, фильтрация у провайдера, механизм SYN cookies и закрытые лишние UDP-сервисы.
L7, или прикладной уровень, находится ближе всего к сайту. Здесь уже есть HTTP и HTTPS, страницы, формы, личный кабинет, корзина, API и админка. HTTP Flood отправляет много GET- или POST-запросов к конкретным адресам: /login, /api/search, /cart, /graphql, /wp-login.php, /xmlrpc.php. Для сервера такие обращения могут выглядеть почти как действия обычных пользователей, особенно если запросы идут через HTTPS и содержат нормальные заголовки браузера.
Главная сложность L7-атак в том, что блокировка по одному признаку часто бьет по нормальным посетителям. За одним IP-адресом могут сидеть пользователи мобильного оператора, офисная сеть, VPN или корпоративный прокси. Поэтому на прикладном уровне смотрят не только на IP, но и на адрес страницы, метод GET или POST, частоту запросов, cookie, заголовки, страну, автономную систему, сессию, токен или ключ API. Здесь уже помогают WAF, rate limiting, challenge-проверки, кэширование и отдельные правила для тяжелых функций сайта.
| Тип атаки | Куда давит | Что видно | Где фильтровать |
|---|---|---|---|
| UDP Flood | Канал и UDP-порты | Растет входящий трафик | Провайдер, анти-DDoS-сеть, Anycast |
| SYN Flood | TCP-соединения | Много незавершенных подключений | Периметр, балансировщик, защита L4 |
| HTTP Flood | Сайт, формы, API | Много запросов к отдельным URL | WAF, CDN, rate limiting |
| Slowloris | Веб-сервер | Много долгих соединений | Прокси, тайм-ауты, limit_conn |
Сервисы защиты в 2026 году
Cloudflare удобен для сайта, который нужно быстро поставить за CDN и WAF. В одной панели есть DNS, CDN, DDoS protection, WAF, Security Events и Rate limiting rules. Для HTTP DDoS в новой панели используется путь Security rules → DDoS protection → HTTP DDoS attack protection → Create override. В правиле задают Override name, Ruleset action и Ruleset sensitivity.
Сильная сторона Cloudflare в простом подключении через DNS и большом наборе готовых правил. Слабое место появляется при открытом исходном сервере. Если старый IP остался в DNS-истории, поддоменах или письмах, атакующий может обойти прокси. После подключения нужно разрешить входящие 80 и 443 только от IP-адресов Cloudflare или другого защитного сервиса.
Yandex Smart Web Security подходит проектам внутри Yandex Cloud. Сетевая DDoS Protection в Virtual Private Cloud защищает публичные IP-адреса на L3/L4, а Smart Web Security работает с HTTP-уровнем через Application Load Balancer, Security profiles, WAF profile и rules. Плюс в связке с облачной сетью, журналами и SmartCaptcha. Минус: для HTTP Flood, логина и API нужны отдельные правила.
AWS Shield логичен для инфраструктуры в AWS. Shield Standard входит в защиту ряда сервисов, Shield Advanced дает видимость атак и интеграцию с AWS WAF, CloudFront и Route 53. Google Cloud Armor раскрывается рядом с Google Cloud Load Balancing, security policies, WAF-правилами и Adaptive Protection. Для обычного VPS оба варианта часто избыточны.
| Решение | Подходит для | Сильные стороны | Ограничения |
|---|---|---|---|
| CDN и анти-DDoS-прокси | Сайтов, блогов, СМИ, магазинов | Кэш, WAF, защита HTTP, быстрое подключение | Нужно скрыть исходный сервер |
| Провайдерская L3/L4-защита | VPS, выделенных серверов, сетевых сервисов | Фильтрация до сервера, защита канала | Не исправляет тяжелые запросы к приложению |
| AWS Shield Advanced | Проектов в AWS | AWS WAF, CloudFront, Route 53 | Неудобен для маленького сайта вне AWS |
| Google Cloud Armor | Проектов за Google Cloud Load Balancing | Security policies, WAF, Adaptive Protection | Требует архитектуры Google Cloud |
Что настроить до атаки
Подготовка начинается с инвентаризации. Нужно понять, где живет сайт, какие домены и поддомены ведут на сервер, какие порты открыты, где находится админка, какие URL создают нагрузку и кто должен иметь доступ к служебным панелям. Без этого защита часто работает только на главной странице.
После этого настраивают маршрут трафика: домен направляют на CDN или анти-DDoS-прокси, исходный сервер закрывают от прямых обращений, служебные интерфейсы уводят за VPN, bastion host или список разрешенных IP. Redis, Elasticsearch, база данных и тестовые стенды не должны быть доступны всему интернету.
- В DNS проверить, что рабочие A- и CNAME-записи идут через защитный сервис, а старые поддомены не раскрывают IP сервера.
- В firewall разрешить 80 и 443 только от IP-адресов CDN, анти-DDoS-сервиса или балансировщика.
- В WAF создать правила для /login, /admin, /api, /graphql, /wp-login.php и /xmlrpc.php.
- В rate limiting ограничить POST-запросы к входу, восстановлению пароля, поиску, экспорту и отправке форм.
- В приложении добавить кэш, очереди, лимиты на размер запросов и ограничения для дорогих операций без авторизации.
Для NGINX полезны limit_req, limit_conn, короткие тайм-ауты для медленных клиентов и корректное определение IP за прокси. Если сайт работает за Cloudflare, веб-сервер должен получать реальный адрес клиента из CF-Connecting-IP.
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/m;
location = /login {
limit_req zone=login_limit burst=10 nodelay;
proxy_pass http://backend;
}Что делать во время атаки
Во время атаки сначала отделяют сетевую перегрузку от атаки на приложение. Если растет входящий трафик в битах или пакетах, нужен провайдер или анти-DDoS-сеть. Если канал свободен, но растут HTTP-запросы, смотрят WAF, access.log, Security Events, топ URL, методы, страны, автономные системы, user-agent и частоту обращений.
В Cloudflare можно временно включить Under Attack Mode, но держать сайт в таком режиме постоянно неудобно для посетителей. Точнее работают WAF Custom rules и Rate limiting rules для конкретных адресов: страницы входа, поиска, корзины, GraphQL, API и восстановления пароля. Для сомнительных правил сначала выбирают Log или Managed Challenge, для явного мусора используют Block.
Во время инцидента не стоит менять все DNS-записи без проверки TTL, отключать журналы, открывать панель сервера наружу, блокировать целые страны без понимания аудитории и удалять правила WAF наугад. Лучше быстро ограничить дорогие функции, усилить лимиты и сохранить данные для разбора.
Частые вопросы
Можно ли защититься бесплатно? Можно снизить риск: включить CDN, кэш, доступный WAF, лимиты в NGINX и закрыть прямой доступ к исходному серверу. От крупной сетевой атаки локальные правила не спасут.
Что важнее, WAF или анти-DDoS? Сетевая анти-DDoS-защита нужна против L3/L4, WAF нужен против вредных HTTP-запросов и атак на приложение. Для нормального сайта нужны оба слоя.
Какой минимум нужен WordPress? CDN или анти-DDoS-прокси, закрытый исходный сервер, защита /wp-login.php, ограничение или отключение /xmlrpc.php, обновленные плагины, кэш страниц, резервные копии и WAF.
