Плейбук: отказ в обслуживании своего сайта (DDoS)

Снимите отказ в обслуживании со своего сайта: подтвердите, что это наводнение запросов, включите ограничения, позовите провайдера. Взлом с чужими файлами — другой сценарий: веб-оболочка. Сутки: первые 24 часа. Каталог: каталог плейбуков.

Статья опирается на логику направления «Управление инцидентами» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. CIS Control 17: cisecurity.org/controls. Это не российский закон. Нагружать чужие и «тестовые мишени» нельзя.

Признаки и что не делать

Сайт не открывается у многих, процессор и сеть на пределе, в журнале пачки однотипных запросов. Не перезагружайте сервер «чтобы помогло»: сотрёте картину. Не отвечайте атакующему. Не включайте контрнагрузку.

Первые шаги

На своём фронте, если nginx пишет access.log:

sudo tail -n 100 /var/log/nginx/access.log

Ожидаемо: повторяющиеся адреса или пути, коды 200/429/499, не обязательно 404. Дальше ограничения и заглушка — в уже написанном материале, не второй WAF: WAF и защита от DDoS. Риск: слишком жёсткий лимит отрежет офис за одним NAT. Сообщите провайдеру канала и, если есть, услуге очистки. Приложение и базу с публичного IP уберите, если ещё торчат.

Приоритет: высокий, если недоступен клиентский сервис; средний для визитки. Эскалация: хостинг, директор, если простой бьёт по выручке. Данные пользователей при «просто недоступно» обычно не утекли — не путайте с утечкой.

Диагностика

Где это в модели зрелости

Материал относится к направлению «Управление инцидентами» (хаб: инциденты, карта: карта зрелости). WAF — мера сети. Плейбук — что делать, когда мера уже не справляется.

Как проверить

1. Контакты хостинга и услуги очистки записаны вне почты на том же сервере.
2. Заглушка и лимиты описаны до инцидента.
3. Нет сценария «ответить атакой».

Источники

• CIS Control 17: cisecurity.org/controls.