# План реагирования на инцидент: первые 60 минут

> План реагирования на инцидент описывает первые 60 минут атаки: изоляцию сервера, сбор улик, оценку ущерба и уведомление ответственных лиц.

## Зачем план нужен заранее, а не в момент атаки

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

Цель первых 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](https://www.zevshost.net/ru/kb/wazuh-siem-monitoring/) или [auditd](https://www.zevshost.net/ru/kb/linux-auditd-monitoring/), экспортируйте события за последние 24-48 часов отдельным архивом до отключения сервера.

## Минута 25-40: оценка масштаба

Определите, что именно затронуто:

| Вопрос | Где искать ответ |
| --- | --- |
| Какие учётные записи скомпрометированы | журнал auth.log, история команд, новые SSH-ключи в authorized\_keys |
| Какие данные могли быть скопированы | исходящий трафик в netstat, логи веб-сервера за последние часы |
| Есть ли персистентность атакующего | crontab, systemd-таймеры, новые systemd-юниты, автозагрузка |
| Затронуты ли другие серверы | исходящие SSH-сессии, общие учётные записи, общая база данных |

Не торопитесь с выводами: признак компрометации на одном сервере часто означает, что нужно проверить всю сеть, включая резервные копии, сделанные уже после взлома.

## Минута 40-60: уведомление и первые решения

Сообщите о случившемся по заранее составленному списку контактов: технический руководитель, владелец бизнеса, при утечке персональных данных — ответственный за защиту данных. Шаблон короткого уведомления:

```
Инцидент: [дата, время обнаружения]
Затронутая система: [хост/сервис]
Статус: изолирован / расследуется
Предварительный масштаб: [что известно на этот момент]
Следующий шаг: [например, восстановление из бэкапа N-1]
```

На этом этапе примите решение о дальнейшем пути: восстановление из чистого бэкапа, привлечение внешнего специалиста по реагированию на инциденты, уведомление регулятора при утечке персональных данных. Подробный процесс очистки описан в статье [взломан сайт: диагностика и восстановление](https://www.zevshost.net/ru/kb/sait-vzloman-vosstanovlenie/).

## Чек-лист первого часа

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

После первого часа переходите к полноценному расследованию: используйте [osquery для инвентаризации и расследования](https://www.zevshost.net/ru/kb/osquery-inventarizaciya/), чтобы системно сверить состояние сервера с эталоном.

## Частые вопросы

### Нужно ли выключать сервер, если сетевую изоляцию настроить не удаётся?

Отключение питания оправдано только тогда, когда изолировать сервер на уровне сети совсем не получается: через панель провайдера, файрвол или коммутатор. Выключение сразу стирает содержимое оперативной памяти, где остаются следы процесса атакующего, и усложняет последующее расследование. Поэтому сначала пробуют любой сетевой способ отрезать трафик и только потом, в крайнем случае, идут на полное отключение.

### Как действовать, если инцидент обнаружен ночью и специалиста нет на месте?

План не требует, чтобы специалист сидел у монитора круглосуточно: важно, чтобы мониторинг сам присылал оповещение и чтобы дежурный мог подключиться удалённо хотя бы для первого шага — изоляции сервера. Если доступа совсем нет, счёт отставания идёт на часы, а не минуты, и масштаб ущерба за это время может вырасти заметно, поэтому удалённый доступ стоит готовить заранее.

### Стоит ли сразу сообщать клиентам сайта о взломе?

Уведомление клиентов — отдельное решение, которое принимают уже после первой оценки масштаба, а не в первые минуты: пока неясно, затронуты ли персональные данные, публичное сообщение может оказаться преждевременным или неточным. Обычно сначала уведомляют внутренний круг ответственных лиц, а публичное объявление готовят, когда появляется понимание, что именно случилось и кому это важно знать.

### Можно ли доверять резервным копиям, сделанным уже после обнаружения атаки?

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

---

Источник: https://www.zevshost.net/ru/kb/plan-reagirovaniya-na-incident/