Что делать если ваш сервер взломали: пошаговый план реакции

Звонок в три ночи. На ваш VPS зашли по SSH из странного IP, web-сайт показывает редиректы на казино, а в почте — письмо с требованием выкупа. Что делать в первые минуты, как не наделать ошибок, как восстановить контроль и не потерять данные. Готовый план реакции с командами и порядком действий.

Я Евгений Семёнов, владелец ITfresh, в IT-инфраструктуре с 2010 года. За 15 лет мне приходилось разбирать десятки взломов — от веб-шеллов на сайтах визиток до полноценных компрометаций корпоративных серверов с шифровальщиками и эксфильтрацией. Этот текст — выжимка моего регулярного брифа для технических директоров клиентов.

Признаки взлома, которые часто игнорируют

"Сервер тормозит" — типовая жалоба, которая в 9 случаях из 10 списывается на нагрузку или диск. На самом деле это может быть процесс майнера или DDoS-агента. Список признаков, после которых нужно расследовать, а не закрывать глаза:

• Резкие скачки CPU/сетевого трафика без объяснений в графиках бизнес-нагрузки.
• Неизвестные процессы с подозрительными именами (kdevtmpfsi, xmrig, kinsing, perfctl, случайные хеши).
• Соединения с публичными IP стран, с которыми вы не работаете, особенно по нестандартным портам.
• Новые пользователи в /etc/passwd или в AD без записи в журнале.
• Изменённые или удалённые логи в /var/log, особенно auth.log, secure, btmp, wtmp.
• Незнакомые crontab у root или www-data, scheduled tasks с подозрительными командами.
• Файлы со временем модификации, отличающимся от первоначальной установки системы.
• SSL-сертификаты для доменов, которые вы не запрашивали (Certificate Transparency Log проверяется через crt.sh).
• Уведомления от Yandex Webmaster или Google Search Console об инфицированных страницах.
• Жалобы хостинг-провайдера на исходящий спам или DDoS с вашего IP.

Шаг 1. Изоляция, а не выключение

# Linux: разрешить только себя
iptables -I INPUT 1 -s YOUR_HOME_IP -j ACCEPT
iptables -I INPUT 2 -j DROP
iptables -I OUTPUT 1 -d YOUR_HOME_IP -j ACCEPT
iptables -I OUTPUT 2 -j DROP

# Сохранить, чтобы пережили рестарт
iptables-save > /etc/iptables/rules.v4

New-NetFirewallRule -DisplayName "EMERGENCY-block-all-in" `
  -Direction Inbound -Action Block -RemoteAddress Any -Enabled True `
  -Profile Any -Priority 1
New-NetFirewallRule -DisplayName "EMERGENCY-allow-admin-in" `
  -Direction Inbound -Action Allow -RemoteAddress YOUR_HOME_IP `
  -Enabled True -Profile Any -Priority 0

Шаг 2. Снимок памяти и диска

wget https://github.com/microsoft/avml/releases/download/v0.13.0/avml
chmod +x avml
./avml /mnt/external/memory_dump_$(date +%Y%m%d_%H%M).lime

# Подключаем внешний диск, например /dev/sdb
dd if=/dev/sda of=/mnt/external/disk.img bs=4M status=progress
sha256sum /mnt/external/disk.img > /mnt/external/disk.img.sha256

Шаг 3. Идентификация вектора и масштаба

Снимки сделаны, теперь думаем. Цель — ответить на пять вопросов:

1. Когда зашли? (timeline)
2. Откуда зашли? (вектор: SSH, веб-уязвимость, RDP, фишинг)
3. Под каким аккаунтом? (root, www-data, конкретный пользователь)
4. Что сделали? (загрузили файлы, добавили users, запустили процесс, эксфильтрировали данные)
5. Где они ещё могут быть? (другие серверы, рабочие станции, бэкапы)

Linux: что смотреть

# История shell-команд root и пользователей
cat /root/.bash_history
find /home -name '.bash_history' -exec ls -la {} \; -exec cat {} \;

# Кто и когда логинился
last -F | head -50
lastb | head -50         # неудачные попытки
who                      # активные сессии прямо сейчас

# Аутентификация (ищем подозрительные SSH-сессии)
grep -E "Accepted|Failed" /var/log/auth.log | tail -100
grep "Accepted" /var/log/auth.log | awk '{print $11}' | sort -u

# Активные процессы и сетевые соединения
ps auxf
ss -tunap | grep ESTAB
netstat -tunap | grep LISTEN

# Файлы, изменённые за последние 7 дней
find / -type f -mtime -7 -not -path '/proc/*' -not -path '/sys/*' \
  -not -path '/var/log/*' 2>/dev/null | head -100

# Подозрительные SUID-бинарники (часто следы)
find / -perm -4000 -type f 2>/dev/null

# Crontab и systemd-таймеры
crontab -l
ls -la /etc/cron.* /etc/systemd/system/*.timer
systemctl list-timers --all

# LD_PRELOAD-инжекты
cat /etc/ld.so.preload 2>/dev/null
env | grep LD_

# Скрытые процессы (несовпадение между ps и /proc)
for pid in $(ls /proc | grep -E '^[0-9]+$'); do
  ps -p $pid > /dev/null 2>&1 || echo "Hidden process: $pid"
done

Windows: что смотреть

# Активные сессии и подключения
quser
Get-NetTCPConnection -State Established | Select LocalPort, RemoteAddress, RemotePort, OwningProcess

# Журналы безопасности — 4624 (logon), 4625 (failed logon), 4672 (priv assignment)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 100 |
  Where-Object {$_.Properties[8].Value -in 3,10} |  # типы 3 (network), 10 (RemoteInteractive)
  Format-Table TimeCreated, @{n='Account';e={$_.Properties[5].Value}}, @{n='IP';e={$_.Properties[18].Value}}

# Запланированные задачи — частая точка персистенса
Get-ScheduledTask | Where-Object {$_.State -eq 'Ready'} |
  Where-Object {$_.Author -notmatch 'Microsoft|Windows'}

# Автозагрузка
Get-CimInstance Win32_StartupCommand
Get-Service | Where-Object {$_.Status -eq 'Running' -and $_.StartType -eq 'Automatic'}

# WMI-подписки (часто скрытый канал персистенса)
Get-WMIObject -Namespace root\subscription -Class __EventConsumer
Get-WMIObject -Namespace root\subscription -Class __FilterToConsumerBinding

# Локальные пользователи и группа администраторов
Get-LocalUser | Format-Table Name, Enabled, LastLogon
Get-LocalGroupMember -Group "Administrators"

Что показывают типовые находки

Шаг 4. Проверка остальной инфраструктуры

Если зашли на один сервер, велика вероятность бокового движения. Проверьте:

• Логи фаервола на необычные внутренние соединения от скомпрометированной машины.
• Логи AD на использование украденных учёток (event ID 4624 type 3 с подозрительных IP).
• Бэкапные серверы — атакующие в первую очередь идут к ним.
• Хеши IoC — найденные файлы прогоните через VirusTotal, чтобы узнать, не зафиксированы ли они в других кампаниях.
• Учётные записи приложений — все API-ключи, токены, базы данных, к которым имел доступ скомпрометированный сервер, считаем утекшими.

Шаг 5. Восстановление: всегда с нуля

Шаг 6. Превенция: чтобы не повторилось

После каждого инцидента обязательно проводим post-mortem и закрываем дыры. Минимальный пакет для типового сервера:

SSH-харденинг

# /etc/ssh/sshd_config
Port 22                          # можно сменить на нестандарт, но не надейтесь, что это защитит
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers admin deploy
ClientAliveInterval 300
ClientAliveCountMax 2
MaxAuthTries 3
LoginGraceTime 30s
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
UseDNS no
PermitEmptyPasswords no

Fail2ban с агрессивной политикой

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = ssh
filter = sshd
maxretry = 3
findtime = 600
bantime = 86400      # сутки
backend = systemd

[recidive]
enabled = true
filter = recidive
maxretry = 3
findtime = 86400
bantime = 604800     # неделя для повторных нарушителей

Автоматические обновления

# Debian/Ubuntu
apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

# В /etc/apt/apt.conf.d/50unattended-upgrades:
Unattended-Upgrade::Allowed-Origins {
  "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";

Мониторинг и SIEM

Минимально — установка агента Wazuh на все серверы и центральный сервер на отдельной виртуалке. Это даст:

• Централизованный сбор логов
• Файловый интегрити-мониторинг (FIM) — алерт при изменении /etc, /usr/sbin, /usr/bin
• Детект подозрительных процессов и соединений
• Готовые правила для типовых атак (CIS, MITRE ATT&CK, OWASP)

Установка Wazuh agent в одну строку:

curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring \
  --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && \
  chmod 644 /usr/share/keyrings/wazuh.gpg && \
  echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" \
  | tee /etc/apt/sources.list.d/wazuh.list && \
  apt update && WAZUH_MANAGER='siem.example.local' apt install wazuh-agent -y

Бэкапы по правилу 3-2-1-1-0

Современная версия классического правила:

• 3 копии данных,
• 2 разных носителя,
• 1 офсайт-копия,
• 1 оффлайн или иммутабельная копия,
• 0 ошибок при тестовом восстановлении (раз в квартал).

Юридическая часть

Малый бизнес часто не знает, что у него есть юридические обязательства при компрометации:

• ФЗ-152 "О персональных данных" — при утечке персональных данных оператор обязан уведомить Роскомнадзор в течение 24 часов с момента обнаружения и в течение 72 часов предоставить расследование. Шаблон уведомления есть на сайте РКН.
• УК РФ ст. 272-273 — неправомерный доступ к компьютерной информации и распространение вредоносного ПО. Заявление подаётся через сайт МВД или подразделение К.
• Договорные обязательства — у вас могут быть SLA с клиентами, требующие уведомления о компрометации.

Сводный чек-лист первых 4 часов

Главные мысли

1. Не выключайте взломанный сервер — изолируйте его на уровне фаервола. Память это улика.
2. Делайте снапшоты RAM и диска до начала чисток. Без них вы потеряете доказательную базу.
3. Не лечите взломанный сервер — переустанавливайте. Иначе вы оставляете шанс на возврат.
4. Меняйте все пароли и токены, к которым у скомпрометированного сервера был доступ. Считайте их публичными.
5. После инцидента ставьте Wazuh, fail2ban, MFA, иммутабельные бэкапы. Без этого следующий инцидент — вопрос времени.
6. В первый час позвоните в специализированную команду incident response, если сами не уверены. Час экспертной консультации экономит сутки самокопания.

Часто задаваемые вопросы