Зачем план нужен заранее, а не в момент атаки
В момент взлома администратор теряет треть эффективности из-за стресса и принимает решения, которые уничтожают улики: перезагружает сервер, удаляет подозрительные файлы, меняет пароли до анализа логов. План реагирования на инцидент — это заранее написанная последовательность действий на первый час, когда решения принимаются быстро, но без права на ошибку.
Цель первых 60 минут — не расследовать инцидент полностью, а остановить дальнейший ущерб и сохранить всё, что понадобится для расследования и восстановления. Полное расследование займёт дни, а решение об изоляции сервера нужно принять за минуты.
Минута 0-10: обнаружение и изоляция
Первый шаг — подтвердить, что это действительно инцидент, а не ложное срабатывание мониторинга. После подтверждения:
- Изолируйте сервер на уровне сети: отключите публичный интерфейс через панель провайдера или правило файрвола, но не выключайте сам сервер — оперативная память хранит следы процесса атакующего.
- Не удаляйте и не перезаписывайте файлы — любое изменение уничтожает улики для последующего разбора.
- Зафиксируйте точное время обнаружения и первые наблюдения текстом — по памяти через час детали забудутся.
iptables -I INPUT 1 -j DROP
iptables -I OUTPUT 1 -j DROP
Эти два правила блокируют весь новый трафик, сохраняя существующие сессии для последующего анализа памяти.
Минута 10-25: сбор первичных улик
Пока сервер изолирован, но ещё включён, снимите снимки состояния для дальнейшего разбора:
ps auxf > /mnt/evidence/ps.txt
netstat -tulpn > /mnt/evidence/netstat.txt
who -a > /mnt/evidence/who.txt
last -50 > /mnt/evidence/last.txt
cp /var/log/auth.log /mnt/evidence/
Копируйте улики на внешний примонтированный том, а не на тот же диск — атакующий мог оставить скрипт очистки логов при перезагрузке. Если развёрнут Wazuh SIEM или auditd, экспортируйте события за последние 24-48 часов отдельным архивом до отключения сервера.
Минута 25-40: оценка масштаба
Определите, что именно затронуто:
| Вопрос | Где искать ответ |
|---|---|
| Какие учётные записи скомпрометированы | журнал auth.log, история команд, новые SSH-ключи в authorized_keys |
| Какие данные могли быть скопированы | исходящий трафик в netstat, логи веб-сервера за последние часы |
| Есть ли персистентность атакующего | crontab, systemd-таймеры, новые systemd-юниты, автозагрузка |
| Затронуты ли другие серверы | исходящие SSH-сессии, общие учётные записи, общая база данных |
Не торопитесь с выводами: признак компрометации на одном сервере часто означает, что нужно проверить всю сеть, включая резервные копии, сделанные уже после взлома.
Минута 40-60: уведомление и первые решения
Сообщите о случившемся по заранее составленному списку контактов: технический руководитель, владелец бизнеса, при утечке персональных данных — ответственный за защиту данных. Шаблон короткого уведомления:
Инцидент: [дата, время обнаружения]
Затронутая система: [хост/сервис]
Статус: изолирован / расследуется
Предварительный масштаб: [что известно на этот момент]
Следующий шаг: [например, восстановление из бэкапа N-1]
На этом этапе примите решение о дальнейшем пути: восстановление из чистого бэкапа, привлечение внешнего специалиста по реагированию на инциденты, уведомление регулятора при утечке персональных данных. Подробный процесс очистки описан в статье взломан сайт: диагностика и восстановление.
Чек-лист первого часа
- Сервер изолирован по сети, но не выключен — память сохранена для анализа.
- Улики скопированы на внешний том до любых изменений на сервере.
- Зафиксировано точное время и первые наблюдения.
- Масштаб инцидента оценён хотя бы предварительно: затронутые учётки, данные, другие серверы.
- Ответственные лица уведомлены по заранее известному списку контактов.
После первого часа переходите к полноценному расследованию: используйте osquery для инвентаризации и расследования, чтобы системно сверить состояние сервера с эталоном.