DDoS атака

Почему атакуют даже небольшой бизнес

DDoS атакам не нужна конкретная причина. Многие запускаются автоматизированными ботнетами, проверяющими, какие цели легко "падают", или как отвлечение внимания, пока где-то ещё происходит отдельная попытка вторжения, независимо от размера цели.

Что оператор сервера может и не может сделать сам

Один сервер, каким бы правильно настроенным он ни был, обычно не может выдержать масштабную волюметрическую атаку на собственной пропускной способности. Смягчение серьёзной попытки DDoS обычно требует фильтрации выше по цепочке, у хостинг-провайдера или через выделенный сервис защиты от DDoS перед сервером.

Практичные и недорогие способы защиты описаны здесь: руководство по защите от DDoS-атак для малого бизнеса.

Как отличить атаку от обычного наплыва посетителей

В руководстве CISA по атакам типа «отказ в обслуживании» к видимым признакам отнесены необычно медленная работа сети, недоступность одного сайта или недоступность всех сайтов сразу, и отдельно отмечено, что обычные сбои и плановые работы выглядят точно так же. Поэтому сначала подтвердите догадку данными. На Linux VPS три быстрые проверки обычно разделяют эти случаи:

ss -s
ip -s link show
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Первая команда выводит сводку по сокетам. Вторая показывает счётчики пакетов и байт по каждому интерфейсу: запустите её дважды с интервалом в несколько секунд, чтобы увидеть скорость. Третья ранжирует адреса клиентов в журнале доступа nginx (это обычный путь в Debian и Ubuntu, при необходимости измените его). Если в списке доминирует один адрес, это злоупотребление, которое вы можете заблокировать сами. Если тысячи адресов шлют понемногу или канал забит, а журнал при этом тихий, речь о распределённой атаке, для которой нужна помощь выше по цепочке. Заранее снимите «портрет» обычного дня, как описано в руководстве по мониторингу логов, чтобы понимать, что считать необычным.

Первый час реальной атаки

Действуйте по короткому заранее известному порядку, а не по наитию:

1. Исключите плановые работы и сбой у провайдера, затем свяжитесь с хостинг-провайдером или интернет-провайдером. CISA называет это первым шагом: они могут проверить, не является ли целью их собственная сеть, и отфильтровать трафик до того, как он дойдёт до вас.
2. Скопируйте журналы доступа и ошибок на другую машину, прежде чем до них доберётся ротация логов. Они понадобятся для обращения к провайдеру и для разбора после инцидента.
3. Включите серверные ограничения, подходящие под увиденную картину: лимиты запросов на адрес против злоупотреблений на уровне приложения (см. руководство по защите от DDoS) и бан через fail2ban для повторяющихся нарушителей.
4. Не выпускайте из виду остальную часть машины. CISA предупреждает, что атаку на отказ в обслуживании иногда используют для отвлечения внимания от второго, более тихого вторжения, поэтому проверьте недавние входы и, если что-то настораживает, следуйте руководству по реагированию на взлом.

Храните контакт эскалации провайдера и данные веб-консоли там, где до них можно добраться, даже если SSH к серверу не работает. О масштабах атак по всему интернету читайте в разборе отчёта Cloudflare за первое полугодие 2026.

Не каждый крупный сбой это атака: в разборе инцидентов в дата-центрах Яндекса показано, как различать DDoS, внутренние отказы и физические удары.

Связанные термины: Волюметрическая атака, Протокольная атака, Атака на уровне приложения, Rate limiting, SYN flood (SYN-флуд), Ботнет (botnet).

В новостях: отчёт Cloudflare за первое полугодие 2026 зафиксировал атаку на 31,4 Тбит/с, хотя типичная атака на небольшой сервер выглядит совсем иначе.