Когда говорят “DDoS”, обычно представляют себе один сценарий: “кто-то забил канал и сайт лёг”. Это бывает, но далеко не всегда. В последние годы всё чаще встречается другой вариант: трафика может быть не так уж много, зато запросы бьют в те места, где сайту больнее всего. Логин, поиск, фильтры, API, страницы с тяжелой авторизацией, генерацией отчётов, запросами в базу — всё это превращается в прекрасную мишень. И вот сайт начинает вести себя “странно”: то грузится, то нет, а мониторинг по сети не показывает апокалипсиса.
Поэтому адекватная защита всегда строится слоями. Сначала нужно убрать грубую сетевую грязь ещё на входе в датацентр. Потом — поставить периметр, который понимает веб-уровень (Cloudflare). И наконец — сделать так, чтобы сам сервер и приложение не умирали от десятков тысяч одновременных соединений и повторяющихся запросов.
Какой Anti-DDoS мы даём клиентам “по умолчанию”
Наша базовая защита — это сетевой Anti-DDoS на уровне инфраструктуры датацентра Hetzner. Для клиента это означает простую вещь: вы запускаете VPS или выделенный сервер и уже получаете сетевой слой, который отслеживает аномалии и включается автоматически, когда трафик становится похож на атаку.
Ключевая ценность такого подхода в том, что он работает до вашего сервера. Если атака объёмная, пытаться отбить её “на самой машине” обычно поздно: канал будет забит раньше, чем nginx успеет отдать страницу ошибки. Сетевой слой как раз и нужен, чтобы трафик “почистили” до того, как он станет вашей проблемой.
В реальности это выглядит так: система замечает резкий рост пакетов, нетипичные профили соединений, всплески UDP или SYN и дальше включает фильтры под конкретный вектор. В большинстве случаев это отлично гасит классические L3/L4 атаки: UDP flood, amplification, SYN-штормы и прочий шум, который рассчитан на грубую силу.
Но важно честно понимать границу. Если атака идёт в виде корректных HTTPS-запросов, сеть не всегда сможет “угадать”, что это бот, потому что для сети это просто обычный трафик. Тут начинается история про L7.
Почему L7 — самая неприятная часть
L7-атака коварна тем, что она часто выглядит как нормальные пользователи. Представь, что вместо ста посетителей у тебя внезапно “пять тысяч посетителей”, и каждый второй открывает страницу поиска или логина. По объёму это не обязательно гигабиты, но по стоимости — огромная нагрузка: PHP воркеры заняты, CPU горячий, база получает лавину запросов, кэш промахивается, очереди растут. И что хуже всего — такой трафик может проходить через HTTPS, то есть снаружи он не выглядит подозрительно.
Лечится это не одной кнопкой, а комбинацией: Cloudflare (WAF/правила/челлендж), ограничения на уровне nginx и здравые оптимизации приложения, чтобы дорогие операции не были доступны без ограничений.
Cloudflare: как настроить так, чтобы он реально защищал
Самая частая ошибка — подключить Cloudflare, но оставить origin открытым. Тогда атакующий просто обойдёт Cloudflare и начнёт долбить IP сервера напрямую. Поэтому первое, что мы рекомендуем клиентам: закрыть origin.
Практически это означает:
-
проксировать DNS-записи сайта через Cloudflare (чтобы наружу “светился” Cloudflare, а не ваш IP);
-
на сервере/фаерволе разрешить 80/443 только из IP Cloudflare;
-
служебные доступы (SSH, панель, админка) ограничить по IP, а лучше — вынести за VPN.
Дальше подключаем “умный” слой: WAF и правила. Здесь важно не ставить защиту топором по всему сайту, иначе вы сами убьёте конверсию. Лучше защищать точки риска: логин, API, поиск, формы, “дорогие” страницы. На них работает rate limiting: обычный человек физически не делает десятки логинов в минуту, а бот делает. И вот эту разницу надо превращать в правила.
Ещё одна полезная вещь — режим challenge/усиленной проверки на время инцидента. Это не история “навсегда”, но как аварийный рычаг он позволяет быстро отсеять значительную часть мусора, пока вы собираете статистику и докручиваете правила тонко.
Что делать на сервере: Nginx и “живучесть” под нагрузкой
Даже если Cloudflare настроен идеально, часть трафика всё равно будет доходить до origin. Поэтому задача nginx — не дать одному источнику или группе источников занять все соединения и все воркеры.
Самый разумный подход — ограничивать не весь сайт, а конкретные дорогие места. На логин и API ставятся лимиты на частоту запросов и лимиты на параллельные соединения. Это почти всегда даёт мгновенный эффект: нормальный пользователь не замечает, а автоматизация начинает упираться в потолок.
Вторая важная вещь — таймауты и дисциплина соединений. Под атаками часто умирают не от “запросов”, а от того, что соединения висят и удерживают ресурсы. Поэтому корректные таймауты и ограничения тела запроса — не “косметика”, а реальная защита.
Третье — кеширование. Если вы можете кешировать контентные страницы или ответы API хотя бы на короткое время, вы снижаете нагрузку кратно. Во время L7-флуда это может быть разницей между “сайт живой” и “сайт умер”.
На уровне приложения полезно иметь возможность включить “режим шторма”: временно упростить самые тяжёлые страницы, отключить сверхдорогие фильтры, включить дополнительные проверки на логин, вынести часть операций в очереди. Да, это компромисс, но он позволяет сохранить доступность.
План действий, когда атака уже идёт
Под атакой главное — действовать спокойно и последовательно:
Сначала усиливаем периметр в Cloudflare и включаем проверки на целевых маршрутах. Затем убеждаемся, что origin не доступен напрямую. Дальше быстро ставим лимиты в nginx именно там, куда идёт поток, и включаем кеш на всё, что может кешироваться. И только после этого уже “допиливаем” правила по логам: какие URI бьют, откуда, с каким user-agent, повторяются ли подсети/ASN.
Как разные атаки ощущаются “в поле”
Часто DDoS путают с обычной перегрузкой — и наоборот. Поэтому полезно понимать, какие симптомы типичны.
SYN flood обычно выглядит как нестабильность: сайт то отвечает, то начинает “висеть”, иногда даже при не запредельном CPU. На практике вы чувствуете дефицит соединений: нормальным пользователям не хватает “окон” для установления коннекта. В логах может быть много таймаутов, а в сетевой статистике — всплески попыток соединения.
UDP flood / amplification чаще всего заметнее по сети. Если атака крупная, резко растёт входящий трафик, деградируют любые соединения (включая SSH), мониторинг может показывать скачки. Если сетевой слой очищает трафик успешно, то для клиента это иногда выглядит как короткий провал и быстрое восстановление — именно поэтому инфраструктурная фильтрация так важна.
L7 HTTP flood самый коварный: канал может быть не забит, но “умирает” приложение. Время ответа растёт, воркеры заняты, база получает лавину однотипных запросов, кэш не успевает. Почти всегда есть “мишени” — конкретные URI: /login, /wp-login.php, /xmlrpc.php, /search, /api/*, фильтры, чекаут. Если в access-логах видно, что основной поток долбит один-два маршрута, — это типичный L7-сценарий.
Cloudflare: три нормальных сценария настройки
WordPress.
В WordPress “любимые” цели ботов известны: wp-login.php и xmlrpc.php. Практический подход — не устраивать капчу всему сайту, а защищать вход и потенциальные точки злоупотребления. xmlrpc.php часто вообще не нужен — тогда его лучше закрыть. Логин — ограничить по частоте, а в момент атаки включать более жёсткую проверку.
Также стоит помнить про AJAX-эндпойнты и тяжелые плагины: во время атаки именно они могут “съедать” сервер. Поэтому грамотная схема — посмотреть, какие URI реально перегружают систему, и поставить правила именно на них.
Laravel / сайты с авторизацией и сессиями.
Здесь атакуют не только логин, но и регистрацию, восстановление пароля, а также “дорогие” страницы личного кабинета и API. Cloudflare должен работать как периметр: не пускать мусор к вашему приложению.
В таких проектах особенно важно не выполнять дорогие операции до того, как запрос прошел минимальные фильтры. На практике это означает rate limiting на логин/регистрацию, отдельные правила на API и обязательно закрытый origin. Дальше уже приложение: прогрессивная защита, задержки/блокировки при аномалиях, кеширование тяжелых ответов.
Чистое API (SPA/мобайл).
Для API ключевое — чтобы один клиент не мог “выстрелять” сервис в ноль. Cloudflare удобно использовать как шлюз с лимитами по маршрутам и методам. Но ещё важнее — внутренние ограничения на стороне API: лимиты по токену/ключу, валидация тела, ограничения размеров, защита от повторов, отдельные правила для “дорогих” эндпойнтов.
Nginx и L7: как защищать, не ломая UX
Nginx лучше всего работает, когда он не “режет весь сайт”, а ставит забор там, где реально опасно. Логин и API ограничиваются по частоте запросов и по числу одновременных соединений. Поиск и фильтры — тоже. Статика и контент — наоборот, должны отдаваться быстро, желательно с кешем.
Отдельный класс проблем — “медленные” соединения, которые удерживают ресурсы. Во время атак это превращается в тихий убийцу: воркеры заняты, а реальным людям некуда подключиться. Поэтому в шторм имеет смысл ужесточать таймауты и держать соединения дисциплинированно.