Финансовый риск
От 50 000 до 300 000 рублей в час из-за недоступности сайта для клиентов при атаке на прикладном уровне (L7), перерасхода ресурсов CPU/RAM хостинга.
Влияние на KPI
Снижение конверсии заказов. Медленный отклик сайта (TTFB) ухудшает поведенческие факторы и пессимизирует поисковый трафик из Google и Яндекса.
Уровень критичности
Высокий
Кому поручить
DevOps-инженер / Бэкенд-разработчик
TL;DR: DDoS похож на обычный сбой: сайт лежит, клиенты пишут, метрики красные. Отличие — в форме нагрузки. Если растут входящий трафик, количество соединений, RPS, однотипные URL и география/IP-разброс, это атака. Если упирается база, диск, релиз или один backend — это чаще внутренний инцидент. Ниже — быстрый 15-минутный алгоритм диагностики.
Время чтения: 9 мин | Уровень: Начинающий/средний | Категория: SOS
Главная мысль
Когда сайт недоступен, первая ошибка — сразу включать все защиты подряд. Так можно случайно заблокировать живых пользователей, поисковых ботов, платежи или API-клиентов.
Сначала нужно ответить на один вопрос:
Сайт лежит из-за внешнего трафика или из-за внутренней поломки?
Это решается не «на глаз», а по 7 признакам.
Быстрая матрица: DDoS или обычный сбой
1. Проверьте: сервер жив или канал забит
Начните с самого грубого уровня.
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/edge/backend уровне.
curl 127.0.0.1быстрый, а публичный домен лежит — смотрите сеть, DNS, reverse proxy, L7-атаку.curl 127.0.0.1тоже медленный — ищите backend, БД, диск, CPU.
2. Посмотрите соединения: есть ли всплеск
ss -s
ss -tan state established | wc -l
ss -tan state syn-recv | wc -lЕсли syn-recv резко высокий — это признак SYN flood или проблем с завершением TCP handshake.
Топ IP по соединениям:
ss -tan | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20Важно: один IP с большим числом соединений — не всегда DDoS. Это может быть NAT корпоративного клиента, балансировщик, мониторинг или поисковый бот. Смотрите не только IP, но и URL, User-Agent, ASN и поведение.
3. Проверьте nginx/access logs: что именно запрашивают
Топ URL за последние строки лога:
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Топ статусы:
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 растёт, но конверсия/реальные события не растут.
4. Отличите DDoS от проблем базы данных
Если сайт лежит, но HTTP-трафик не выглядит аномально, проверьте базу.
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;MySQL:
SHOW FULL PROCESSLIST;
SHOW ENGINE INNODB STATUS\GСкорее внутренний сбой, если:
- много lock/wait;
- один медленный запрос держит очередь;
- после отключения конкретной функции сайт оживает;
- rollback релиза снижает ошибку.
Скорее DDoS, если:
- база не перегружена, но edge/nginx забит запросами;
- растёт входящий трафик и соединения;
- backend получает слишком много однотипных запросов.
5. Проверьте недавние изменения
Иногда «атака» совпадает с релизом, миграцией или изменением DNS.
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Спросите команду:
- был ли релиз за последний час;
- меняли ли DNS/CDN/WAF;
- запускали ли рассылку или рекламу;
- не истёк ли сертификат;
- не закончился ли диск.
Быстрые проверки:
df -h
free -m
dmesg | tail -50
systemctl status nginx --no-pager6. Мини-алгоритм на 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
Не блокируйте всё подряд. Лучше действовать слоями.
1. Зафиксируйте симптомы: время начала, RPS, трафик, топ URL, топ IP, статусы.
2. Включите защиту на edge/CDN/WAF, если она есть.
3. Ограничьте самые дорогие endpoint'ы: /login, /search, /api, корзина, checkout.
4. Оставьте публичные статические страницы доступными, если бизнесу важны SEO и доверие.
5. Не закрывайте бездумно Googlebot/Bingbot — проверьте верификацию поисковых ботов.
6. Если канал забит — переносите трафик за anti-DDoS/POP/скраббинг, локальные правила уже поздно применять.
Что делать, если это не DDoS
Если признаки указывают на внутренний сбой:
- откатите последний релиз;
- отключите проблемную задачу/cron;
- временно упростите дорогой endpoint;
- включите maintenance/статическую страницу;
- сохраните логи и метрики для postmortem.
Важно: даже внутренний сбой может стать внешней проблемой. Когда сайт начинает отвечать медленно, клиенты и боты ретраят запросы, нагрузка растёт, и обычный инцидент превращается в self-DDoS.
Чек-лист диагностики
Частые ошибки
Ошибка 1: блокировать по User-Agent
Фальшивый Googlebot легко подделать, а настоящий поисковый бот можно случайно закрыть. Проверяйте IP/rDNS или используйте провайдера, который умеет верифицировать crawler'ов.
Ошибка 2: ставить challenge на весь сайт
Challenge на /login может быть нормальным. Challenge на публичные SEO-страницы, оплату или API мобильного приложения может сломать бизнес.
Ошибка 3: лечить L3/L4 атаку nginx-правилами
Если забит канал, nginx уже не увидит трафик. Нужна фильтрация до вашего сервера: провайдер, scrubbing, anycast/POP.
Ошибка 4: считать любой всплеск DDoS-ом
Реклама, рассылка, новость в СМИ, индексация поисковиком — тоже дают всплески. Отличайте плохой трафик от хорошего.
Когда звать anti-DDoS провайдера
Зовите внешнюю защиту, если:
- канал забит и сервер недоступен;
- атака повторяется несколько раз в неделю;
- атакуют login/API/checkout;
- приходится блокировать целые страны или ASN;
- WAF/CDN не отличает клиентов от ботов;
- команда тратит часы на ручные iptables/nginx-правила.
AntiDDoS.su помогает быстро понять слой атаки, поставить фильтрацию перед origin и не ломать нормальных пользователей. Если сайт уже лежит — начните с диагностики: что атакуют, на каком уровне и какой минимальный безопасный шаг вернёт доступность.
Практическая экспертиза AntiDDoS.su
Практическая экспертиза AntiDDoS.su Этот материал подготовлен инженерами безопасности AntiDDoS.su. Мы специализируемся на отражении распределенных атак любой сложности, аудите безопасности инфраструктуры и настройке отказоустойчивых систем. 🛡️ Важная информация: Если ваш ресурс находится под атакой или нуждается в профессиональном аудите защиты — обратитесь к экспертам AntiDDoS.su для оперативной помощи.
Что читать дальше
- Вас атакуют прямо сейчас: пошаговый план действий
- HTTP Flood: как отличить от легитимного трафика
- Rate Limiting: защита API от перегрузки
- SYN Flood: анатомия атаки и защита
Нужна быстрая диагностика? Опишите симптомы и домен — мы подскажем, это DDoS, внутренний сбой или смешанный инцидент.
Скопируйте эти вопросы и отправьте вашему техническому директору (CTO) или руководителю разработки:
- Настроена ли WAF-фильтрация для отсечения ботов с помощью JS-челленджей без показа капчи реальным пользователям?
- Защищен ли веб-сервер от атак типа Slowloris путем оптимизации HTTP Keep-Alive таймаутов?
- Проверено ли наше приложение на защиту от атак типа HTTP Request Smuggling и отравления кэша?
Словарь по теме
Reverse Proxy
Сервер-посредник между клиентами и backend-серверами. Скрывает реальные серверы, кэширует контент, фильтрует трафик.
Origin Server
Основной сервер, где хранится и обрабатывается контент. CDN кэширует контент с origin и раздаёт его пользователям.
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.