Навіщо план потрібен заздалегідь, а не в момент атаки
У момент злому адміністратор втрачає третину ефективності через стрес і ухвалює рішення, які знищують докази: перезавантажує сервер, видаляє підозрілі файли, змінює паролі до аналізу логів. План реагування на інцидент — це заздалегідь написана послідовність дій на першу годину, коли рішення ухвалюються швидко, але без права на помилку.
Мета перших 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 для інвентаризації та розслідування, щоб системно звірити стан сервера з еталоном.
Часті питання
Чи потрібно вимикати сервер, якщо мережеву ізоляцію налаштувати не вдається?
Вимкнення живлення виправдане лише тоді, коли ізолювати сервер на рівні мережі зовсім не вдається: через панель провайдера, файрвол чи комутатор. Вимкнення одразу стирає вміст оперативної пам'яті, де лишаються сліди процесу зловмисника, і ускладнює подальше розслідування. Тому спершу пробують будь-який мережевий спосіб відрізати трафік і лише потім, у крайньому випадку, йдуть на повне вимкнення.
Як діяти, якщо інцидент виявлено вночі і фахівця немає на місці?
План не вимагає, щоб фахівець сидів біля монітора цілодобово: важливо, щоб моніторинг сам надсилав сповіщення і щоб черговий міг під'єднатися віддалено хоча б для першого кроку — ізоляції сервера. Якщо доступу зовсім немає, відставання рахують годинами, а не хвилинами, і масштаб збитків за цей час може зрости помітно, тому віддалений доступ варто готувати заздалегідь.
Чи варто одразу повідомляти клієнтів сайту про злом?
Повідомлення клієнтів — окреме рішення, яке ухвалюють вже після первинної оцінки масштабу, а не в перші хвилини: поки незрозуміло, чи зачеплені персональні дані, публічне повідомлення може виявитися передчасним або неточним. Зазвичай спершу інформують внутрішнє коло відповідальних осіб, а публічну заяву готують, коли з'являється розуміння, що саме сталося і кому це важливо знати.
Чи можна довіряти резервним копіям, зробленим вже після виявлення атаки?
Бекапи, зроблені після виявлення атаки, не варто вважати чистими за замовчуванням: якщо зловмисник уже перебував у системі якийсь час, резервна копія могла успадкувати змінені файли або приховані точки входу. Перед відновленням таку копію варто перевірити окремо, а для відкату краще орієнтуватися на версію, створену свідомо до появи перших ознак компрометації.