Финансовый риск
От 50 000 до 300 000 рублей в час из-за недоступности сайта для клиентов при атаке на прикладном уровне (L7), перерасхода ресурсов CPU/RAM хостинга.
Влияние на KPI
Снижение конверсии заказов. Медленный отклик сайта (TTFB) ухудшает поведенческие факторы и пессимизирует поисковый трафик из Google и Яндекса.
Уровень критичности
Высокий
Кому поручить
DevOps-инженер / Бэкенд-разработчик
TL;DR: DDoS похож на обычный сбой: сайт лежит, клиенты пишут, метрики красные. Отличие — в форме нагрузки. Если растут входящий трафик, количество соединений, RPS, однотипные URL и география/IP-разброс, это атака. Если упирается база, диск, релиз или один backend — это чаще внутренний инцидент.
Ниже — быстрый 15-минутный алгоритм диагностики, который помогает не блокировать живых пользователей и не чинить не тот слой.
Главная мысль
Когда сайт недоступен, первая ошибка — сразу считать это атакой. На практике нужно ответить на один вопрос: сайт лежит из-за внешнего трафика или из-за внутренней поломки?
Сайт лежит из-за внешнего трафика или из-за внутренней поломки?
Это решается не «на глаз», а по нескольким признакам: трафик, соединения, URL, статусы, backend, база и недавние изменения.
Проверьте: сервер жив или канал забит
Начните с самого грубого уровня: доступен ли сервер вообще и отвечает ли приложение локально.
ping -c 4 your-server-ip
ssh user@your-server "uptime"
ssh user@your-server "curl -I --max-time 3 http://127.0.0.1/"Как читать результат:
- ping и SSH не отвечают — возможно, забит канал или провайдер уже фильтрует трафик.
- SSH работает, но сайт снаружи не открывается — вероятнее проблема на HTTP, reverse proxy, DNS или L7-уровне.
- локальный curl быстрый, публичный домен лежит — смотрите edge, DNS, CDN/WAF и публичный вход.
- локальный curl тоже медленный — ищите backend, базу, диск, CPU.
Посмотрите соединения: есть ли всплеск
Количество соединений и SYN-RECV быстро показывает, похоже ли это на сетевую атаку или на обычную backend-проблему.
ss -s
ss -tan state established | wc -l
ss -tan state syn-recv | wc -l
# Топ IP по соединениям
ss -tan | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20Проверьте nginx/access logs
L7 DDoS часто видно не по одному IP, а по форме запросов: повторяющиеся URL, дорогие POST, странные User-Agent, всплеск 499/502/503/504.
tail -50000 /var/log/nginx/access.log \
| awk '{print $7}' \
| sort | uniq -c | sort -rn | head -20
# Топ User-Agent
tail -50000 /var/log/nginx/access.log \
| awk -F'"' '{print $6}' \
| sort | uniq -c | sort -rn | head -20
# Топ HTTP-статусы
tail -50000 /var/log/nginx/access.log \
| awk '{print $9}' \
| sort | uniq -c | sort -rnПризнаки L7 DDoS:
- много запросов на
/login,/search,/api/*,/wp-login.php,/xmlrpc.php; - много
499,502,503,504; - одинаковые User-Agent или наоборот полностью случайные;
- всплеск
POSTна дорогие endpoint'ы; - RPS растёт, но реальные бизнес-события не растут.
Отличите DDoS от проблем базы данных
Если HTTP-трафик не выглядит аномально, проверьте базу. Очень часто сайт «лежит как при атаке», но причина — lock, slow query или исчерпанный пул соединений.
-- PostgreSQL
SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state;
SELECT now() - query_start AS duration, state, query
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY duration DESC
LIMIT 10;SHOW FULL PROCESSLIST;
SHOW ENGINE INNODB STATUS\GСкорее внутренний сбой, если есть lock/wait, один медленный запрос держит очередь, rollback помогает или после отключения конкретной функции сайт оживает.
Скорее DDoS, если база не перегружена, но edge/nginx забит однотипными запросами и соединениями.
Проверьте недавние изменения
Иногда «атака» совпадает с релизом, миграцией или изменением DNS. Это особенно часто происходит после рекламной рассылки, переезда CDN/WAF или обновления backend.
git log --oneline -5
systemctl list-timers --all | head
journalctl -u nginx --since "30 minutes ago" --no-pager | tail -100
journalctl -u your-app --since "30 minutes ago" --no-pager | tail -100
df -h
free -m
dmesg | tail -50
systemctl status nginx --no-pagerМини-алгоритм на 15 минут
Минута 0–3: доступность
- Проверить ping/SSH.
- Проверить локальный
curl 127.0.0.1. - Проверить публичный
curl -I https://domain.ru.
Минута 3–6: нагрузка
uptime,top,ss -s.- Количество established/syn-recv соединений.
- Входящий трафик на интерфейсе.
Минута 6–10: HTTP-форма атаки
- Топ URL.
- Топ IP.
- Топ User-Agent.
- Топ HTTP status.
Минута 10–15: решение
- Если атака на L7 — включить challenge/WAF/rate-limit на конкретные пути.
- Если SYN/UDP flood — эскалировать на провайдера или anti-DDoS, потому что серверный firewall может не помочь при забитом канале.
- Если backend/DB — rollback, отключение тяжёлой функции, восстановление внутреннего инцидента.
Что делать, если это DDoS
Не блокируйте всё подряд. Лучше действовать слоями.
- Зафиксируйте симптомы: время начала, RPS, трафик, топ URL, топ IP, статусы.
- Включите защиту на edge/CDN/WAF, если она есть.
- Ограничьте самые дорогие endpoint'ы:
/login,/search,/api, корзина, checkout. - Оставьте публичные статические страницы доступными, если бизнесу важны SEO и доверие.
- Не закрывайте бездумно Googlebot/Bingbot — проверяйте верификацию поисковых ботов.
- Если канал забит — переносите трафик за anti-DDoS/POP/scrubbing, локальные правила уже поздно применять.
Что делать, если это не DDoS
Если признаки указывают на внутренний сбой: откатите последний релиз, отключите проблемную задачу или cron, временно упростите дорогой endpoint, включите maintenance/статическую страницу и сохраните логи для postmortem.
Важно: даже внутренний сбой может стать внешней проблемой. Когда сайт начинает отвечать медленно, клиенты и боты ретраят запросы, нагрузка растёт, и обычный инцидент превращается в self-DDoS.
Частые ошибки
Блокировать по User-Agent
Фальшивый Googlebot легко подделать, а настоящий поисковый бот можно случайно закрыть. Проверяйте IP/rDNS или используйте провайдера, который умеет верифицировать crawler'ов.
Ставить challenge на весь сайт
Challenge на /login может быть нормальным. Challenge на публичные SEO-страницы, оплату или API мобильного приложения может сломать бизнес.
Лечить L3/L4 атаку nginx-правилами
Если забит канал, nginx уже не увидит трафик. Нужна фильтрация до вашего сервера: провайдер, scrubbing, anycast/POP.
Считать любой всплеск DDoS-ом
Реклама, рассылка, новость в СМИ, индексация поисковиком — тоже дают всплески. Отличайте плохой трафик от хорошего.
Нет. User-Agent легко подделать. Смотрите IP, ASN, частоту запросов, URL, cookie/session behavior и верификацию поисковых ботов.
Не обязательно. 502/504 могут быть следствием перегруженного backend, ошибки деплоя, базы данных или настоящей L7-атаки. Поэтому сначала проверяем upstream и логи приложения.
Обычно нет. Challenge на публичные SEO-страницы, оплату или API может сломать бизнес. Лучше включать защиту слоями и на конкретные дорогие endpoint'ы.
Что читать дальше
Скопируйте эти вопросы и отправьте вашему техническому директору (CTO) или руководителю разработки:
- Настроена ли WAF-фильтрация для отсечения ботов с помощью JS-челленджей без показа капчи реальным пользователям?
- Защищен ли веб-сервер от атак типа Slowloris путем оптимизации HTTP Keep-Alive таймаутов?
- Проверено ли наше приложение на защиту от атак типа HTTP Request Smuggling и отравления кэша?
Словарь по теме
Reverse Proxy
Сервер-посредник между клиентами и backend-серверами. Скрывает реальные серверы, кэширует контент, фильтрует трафик.
Rate Limiting
Ограничение количества запросов с одного IP-адреса за определённый период времени. Первая линия защиты от ботов, брутфорса и простых DDoS-атак.
User-Agent
HTTP-заголовок, идентифицирующий браузер или программу. Боты часто имеют пустой или подозрительный User-Agent.
UDP Flood
Атака, при которой на сервер отправляется огромное количество UDP-пакетов на случайные порты, перегружая сетевой канал.
SYN Flood
Атака на сетевом уровне (L4), при которой атакующий отправляет множество SYN-пакетов, не завершая TCP-рукопожатие. Исчерпывает таблицу соединений сервера.
L7 атака
Атака на прикладном уровне (HTTP). Атакующий отправляет валидные HTTP-запросы, которые выглядят как обычные пользователи, но нагружают тяжёлые endpoint'ы.
Endpoint
URL-адрес, по которому доступен определённый ресурс или функция API. Например: /api/users, /login.
Anycast
Метод маршрутизации, при котором один IP-адрес ведёт к ближайшему из множества серверов. Используется CDN для распределения нагрузки.