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

Главный принцип

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

1. Зафиксировать вводные

  • Что случилось: дефейс, спам, вредоносный файл, утечка, странные заказы, звонки мошенников.
  • Кто сообщил и когда.
  • Домен, сервер, часовой пояс сервера.
  • Время события со слов клиента — и сразу сверить с временем на сервере.
  • Какие данные могли утечь: имена, телефоны, адреса, заказы, почта, платёжные данные.
  • У кого есть доступ: root, панель хостинга, админка CMS, FTP/SFTP, база данных, почта, CRM, боты в мессенджерах, подрядчики.

2. Сохранить логи — в первую очередь

Логи ротируются, поэтому копируем их до любых активных действий.

Авторизация и доступ: /var/log/secure или /var/log/auth.log, вывод last и lastb, .bash_history пользователей, файлы authorized_keys, /etc/passwd, /etc/group, /etc/sudoers и sudoers.d.

Веб и CMS: access/error-логи Nginx и Apache, логи PHP-FPM, логи панели управления, логи и журнал действий админки CMS.

FTP и файлы: логи FTP-сервера, список недавно изменённых файлов сайта, stat подозрительных файлов.

Почта: почтовый лог, очередь (mailq), логи SMTP/IMAP при подозрении на почтовую утечку.

База данных: error log, general log (если был включён), список пользователей БД и разрешённых удалённых подключений, дампы в /tmp, /root, каталогах сайта.

3. Снять текущее состояние

Цель — сохранить то, что пропадёт при перезагрузке:

hostnamectl; date; uptime
who -a; w
ss -tulpn          # кто слушает порты
ss -antp           # активные соединения
ps auxww --forest  # дерево процессов
systemctl --type=service --state=running
crontab -l
df -hT; free -m
last -a | head -50
lastb -a | head -100

Вывод каждой команды — в файл с отметкой времени.

4. Проверить закрепление

Как злоумышленник мог остаться в системе после «чистки»:

# Cron
cat /etc/crontab
ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily /var/spool/cron

# Сервисы и автозагрузка
systemctl list-unit-files --type=service | grep enabled
ls -la /etc/systemd/system

# Пользователи с UID 0 и SSH-ключи
awk -F: '($3==0){print}' /etc/passwd
find /root /home -name authorized_keys -type f -exec ls -la {} \;

# Временные каталоги
ls -la /tmp /var/tmp /dev/shm
find /tmp /var/tmp /dev/shm -type f -mtime -14 -ls

5. Понять устройство сайта

Особенно если подозревается утечка данных клиентов, нужна карта: как данные проходят от посетителя до сотрудника.

  • где корень сайта, какая CMS и её версия;
  • где конфиг с доступом к базе;
  • какие таблицы хранят заказы, клиентов и пользователей;
  • как оператор получает заказ: админка, почта, мессенджер, CRM, API, вебхук;
  • какие внешние сервисы подключены: оплата, доставка, SMS;
  • где лежат загрузки и резервные копии.

6. Найти путь утечки

Главный вопрос: откуда злоумышленник узнал данные. Проверяем:

  • входы в админку CMS до и после события;
  • кто открывал страницу заказа;
  • кто имеет доступ к почте, куда приходят уведомления о заказах;
  • токены ботов в мессенджерах и вебхуки, куда уходят заказы;
  • экспорты заказов в CSV/XLS;
  • отладочные логи, в которые могли попадать телефоны;
  • резервные копии базы или сайта в каталогах, доступных из веба;
  • запросы в веб-логах к API заказов, AJAX-обработчикам и разделам админки.

7. Искать веб-шеллы

Начинать с недавно изменённых файлов:

find /var/www/SITE -type f -mtime -14 \
  -printf '%TY-%Tm-%Td %TH:%TM %u %s %p\n' | sort
find /var/www/SITE -type f -name '*.php' -mtime -30 \
  -printf '%TY-%Tm-%Td %TH:%TM %u %s %p\n' | sort

Типичные паттерны вредоносного кода:

grep -RInE "eval\(|base64_decode|gzinflate|str_rot13|shell_exec|passthru|system\(|assert\(|FilesMan|WSO|c99|r57" \
  /var/www/SITE --include='*.php'

Отдельно смотрим index.php, .htaccess, каталоги загрузок и изображений, временные каталоги CMS, файлы с двойным расширением (.php.jpg, .phtml, .phar) и любые PHP-файлы там, где должны быть только картинки.

8. Проверить процессы

ps auxww --forest
ss -antp
lsof -i -P -n

Подозрительно: процессы из /tmp, /var/tmp, /dev/shm; неожиданные perl, python, nc, socat, curl, wget; долгоживущие PHP-процессы не от веб-сервера; исходящие соединения на незнакомые адреса; майнеры и странные systemd-сервисы.

9. Определить вероятный вектор

Не ломая продуктив:

  • версии CMS, модулей, PHP, веб-сервера, панели — и публичные CVE для них;
  • открытые наружу SSH, FTP, панели, phpMyAdmin, веб-почта, админка CMS;
  • слабые места: загрузка файлов, старые бэкапы, открытый .git, .env, phpinfo;
  • права на файлы: может ли веб-пользователь писать туда, где лежит код;
  • есть ли WAF, fail2ban, файрвол.

Активное сканирование — только аккуратно и с разрешением владельца.

10. Построить таймлайн

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

ДД.ММ 09:15  клиент оформил заказ
ДД.ММ 09:16  сайт создал заказ, ушло письмо-уведомление
ДД.ММ 09:17  заказ открыт в админке с IP X
ДД.ММ 12:30  клиенту позвонил мошенник

Источники: слова клиента и оператора, история заказа в CMS, веб-логи, почтовый лог, логи CRM и вебхуков, логи авторизации, время изменения файлов, история команд.

11. Когда можно устранять

Только после сохранения артефактов и первичной оценки:

  • закрыть SSH по IP или за VPN, ограничить или отключить FTP, закрыть БД извне;
  • сменить root-пароль, SSH-ключи, пароли CMS, FTP, БД, почты, API-токены;
  • удалить веб-шеллы — предварительно сохранив копию и хеш;
  • обновить CMS, модули, PHP и панель;
  • включить WAF, fail2ban, правила файрвола;
  • исправить права на файлы;
  • включить аудит входов в админку и уведомления о них.

12. Итоговый отчёт

  • что произошло и какие данные могли быть затронуты;
  • подтверждённый или вероятный вектор;
  • таймлайн;
  • индикаторы компрометации: IP, файлы, URL, user-agent, учётные записи;
  • что сделано для локализации и что осталось для полного устранения;
  • что изменить в процессах, чтобы это не повторилось.

Мини-чеклист

  • Записать вводные и время события
  • Сохранить логи: авторизация, веб, почта, FTP, CMS, панель
  • Снять состояние: date, uptime, who, ss, ps, crontab
  • Проверить входы, пользователей, SSH-ключи, sudo
  • Проверить cron, systemd, временные каталоги
  • Понять устройство сайта и путь данных
  • Найти изменённые файлы и веб-шеллы
  • Проверить почту, CRM, ботов, вебхуки
  • Проверить версии и известные уязвимости
  • Построить таймлайн
  • Локализовать инцидент и сменить все секреты
  • Написать отчёт

Пример того, как такой подход работает на практике, — в разборе взлома корпоративной почты.