Взлом сервера интернет-магазина: расследование инцидента и восстановление за 48 часов

Интернет-магазин «ШопЭкспресс» обратился к нам после странного инцидента: их штатный администратор подключился к серверу по SSH для настройки почтового сервера и обнаружил чужую активную screen-сессию. В терминале были видны команды загрузки файлов с внешнего хоста и компиляция чего-то в /tmp.

Первое, что он сделал — позвонил нам. Мы попросили его не перезагружать сервер и не закрывать сессию — это критически важно для форензики. Перезагрузка уничтожает содержимое /proc, сетевые соединения и временные файлы в памяти.

Параметры сервера: Debian 10, VPS у хостинг-провайдера, 4 ядра, 8 ГБ RAM. На сервере работали nginx, PHP-FPM, MySQL, Exim4. Последнее обновление системы — 8 месяцев назад.

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

Шаг 1 — активные соединения:

# Ищем подозрительные SSH-соединения
lsof -ni | grep ssh
# sshd  14523  root  3u  IPv4  ... TCP 10.0.0.5:22->172.190.125.14:44832 (ESTABLISHED)
# Чужое соединение с IP 172.190.125.14

# Проверяем все установленные TCP-соединения
ss -tupan | grep ESTAB
# Обнаружен ещё один подозрительный коннект на порт 4443 (reverse shell)

Шаг 2 — подозрительные процессы:

# Процессы с нестандартными именами
ps auxf | grep -v '\[' | sort -k3 -rn | head -20
# Обнаружен процесс /usr/bin/.sshd (точка перед именем!)
# PID 14201, запущен от root, CPU 0.1%, работает 3 дня

# Проверяем, что за файл
file /usr/bin/.sshd
# ELF 64-bit LSB executable — это не настоящий sshd

ls -la /usr/bin/.sshd
# -rwxr-xr-x 1 root root 1847296 Mar 15 03:14 /usr/bin/.sshd

Шаг 3 — проверяем целостность системных бинарников:

# Сравниваем хеши SSH с пакетными
dpkg -V openssh-server
# ??5?????? /usr/sbin/sshd
# Хеш не совпадает — файл модифицирован!

# Проверяем атрибуты
lsattr /usr/sbin/sshd
# -u--ia-------e-- /usr/sbin/sshd
# Атрибуты 'i' (immutable) и 'a' (append-only) — защита от перезаписи

Модифицированный sshd с атрибутом immutable — классический приём: даже apt upgrade не сможет заменить файл.

Логи — главный источник информации. К счастью, злоумышленник не успел полностью их подчистить (syslog-файлы за последние 3 дня были частично перезаписаны, но auth.log ротировался и сжимался cron-ом).

# Ищем успешные входы в auth.log и его архивах
zgrep 'Accepted' /var/log/auth.log* | sort -t: -k1,1 | tail -30

# Результат — ключевые записи:
# auth.log.3.gz: Mar 12 03:14:22 shop sshd[8821]: Accepted password for root from 172.190.125.14
# auth.log.3.gz: Mar 12 03:14:22 shop sshd[8821]: pam_unix(sshd:session): session opened for user root

# Проверяем wtmp — журнал входов
last -i -f /var/log/wtmp | head -20
# root     pts/2   172.190.125.14  Mar 12 03:14   still logged in
# root     pts/1   93.184.216.34   Mar 14 10:22   still logged in  ← наш админ

# Ищем неудачные попытки перед взломом
zgrep 'Failed password' /var/log/auth.log.4.gz | grep '172.190' | wc -l
# 0 — ни одной неудачной попытки! Пароль был известен заранее.

Хронология инцидента:

1. 12 марта, 03:14 — первый вход с IP 172.190.125.14 по паролю root. Пароль был скомпрометирован (по нашей оценке — утёк через старый phpMyAdmin без аутентификации).
2. 12 марта, 03:15–03:42 — установка руткита: подмена sshd, ssh, установка кейлоггера, создание скрытого бэкдора /usr/bin/.sshd на порту 4443.
3. 12 марта, 03:43 — установка криптомайнера в /tmp/.X11-unix/ (маскировка под X11-сокет).
4. 14 марта, 10:22 — наш админ подключается и обнаруживает чужую сессию.

Для глубокой проверки использовали несколько инструментов:

# 1. chkrootkit — быстрая проверка на известные руткиты
apt install chkrootkit
chkrootkit
# INFECTED: /usr/sbin/sshd
# INFECTED: /usr/bin/ssh
# Searching for Linux.RST.B... INFECTED

# 2. rkhunter — более детальная проверка
apt install rkhunter
rkhunter --check --sk
# Warning: /usr/sbin/sshd has been replaced by a script
# Warning: Hidden file found: /usr/bin/.sshd
# Warning: Hidden directory found: /tmp/.X11-unix/.cache/

# 3. ClamAV — антивирусное сканирование
apt install clamav
freshclam
clamscan -ri / --exclude-dir=/proc --exclude-dir=/sys 2>/dev/null
# /usr/sbin/sshd: Linux.RST.B-1 FOUND
# /usr/bin/.sshd: Linux.Backdoor.Agent FOUND
# /tmp/.X11-unix/.cache/kworker: Linux.CoinMiner FOUND

Linux.RST.B — это ELF-вирус 2001 года, который заражает бинарники, добавляя код в секцию .text. Старый, но всё ещё эффективный против серверов без антивируса.

Полный список скомпрометированных файлов:

• /usr/sbin/sshd — модифицированный SSH-демон с кейлоггером паролей
• /usr/bin/ssh — модифицированный SSH-клиент (логирует пароли при исходящих соединениях)
• /usr/bin/.sshd — бэкдор на порту 4443 с reverse shell
• /tmp/.X11-unix/.cache/kworker — криптомайнер XMRig, замаскированный под системный процесс
• /root/.bashrc — добавлена строка автозапуска бэкдора

Прежде чем восстанавливать, нужно понять масштаб проблемы. Мы проверили:

База данных MySQL:

# Проверяем, обращался ли злоумышленник к MySQL
grep -i 'connect\|login' /var/log/mysql/error.log
# Нет записей о подключениях извне — MySQL слушал только localhost

# Проверяем дампы — не выгружал ли данные
find / -name '*.sql' -o -name '*.dump' -newer /usr/bin/.sshd -mtime -5 2>/dev/null
# Пусто — дампов не обнаружено

# Но проверяем history root
cat /root/.bash_history | grep -i 'mysql\|dump\|select'
# mysql -u root -p shopexpress
# Злоумышленник подключался к БД! Но дамп не делал (или удалил следы)

Файлы сайта:

# Ищем PHP-файлы, изменённые после взлома
find /var/www -name '*.php' -newer /usr/bin/.sshd -mtime -5
# /var/www/shop/includes/footer.php — модифицирован 12 марта

# Проверяем diff с бэкапом
diff /var/www/shop/includes/footer.php /backup/shop/includes/footer.php
# В footer.php добавлен обфусцированный JavaScript — скорее всего, web shell или редирект

Итоговая оценка:

• Доступ к root с полным контролем сервера — 3 дня
• Подменены системные бинарники SSH — возможна компрометация паролей
• Был доступ к MySQL с данными клиентов — утечка возможна, но не подтверждена
• Модифицирован PHP-файл сайта — посетители могли быть перенаправлены
• Установлен криптомайнер — дополнительная нагрузка на CPU, деньги за электричество

Золотое правило incident response: скомпрометированный сервер нельзя «почистить» — его нужно пересобрать с нуля. Вы никогда не можете быть уверены, что нашли все бэкдоры. Мы следовали этому правилу.

План восстановления:

# 1. Сохраняем образ диска для дальнейшего анализа
dd if=/dev/vda bs=4M | gzip > /mnt/external/shop-compromised-20260312.img.gz

# 2. Делаем дамп базы данных
mysqldump --all-databases --single-transaction > /mnt/external/shop-db-20260314.sql

# 3. Копируем файлы сайта (проверим потом на чистой машине)
rsync -a /var/www/shop/ /mnt/external/shop-files/

# 4. Копируем конфиги (nginx, php-fpm, mysql)
tar czf /mnt/external/configs.tar.gz /etc/nginx /etc/php /etc/mysql

Далее заказали новый VPS и начали установку с нуля:

# Свежая Ubuntu 22.04 LTS
# Базовая настройка
apt update && apt upgrade -y

# Создаём пользователя, запрещаем root
adduser deploy
usermod -aG sudo deploy

# Устанавливаем стек
apt install nginx php8.1-fpm php8.1-mysql mysql-server certbot

# Восстанавливаем базу данных
mysql < shop-db-20260314.sql

# Восстанавливаем файлы сайта после проверки
# Каждый PHP-файл проверяем diff-ом с последним чистым бэкапом
rsync -a --checksum /mnt/external/shop-files/ /var/www/shop/

Файлы сайта мы не копировали вслепую — каждый PHP-файл был проверен на изменения относительно бэкапа трёхдневной давности. Модифицированный footer.php восстановили из бэкапа.

После восстановления мы внедрили комплекс мер, чтобы подобный инцидент не повторился:

SSH-hardening:

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 20
AllowUsers deploy
Port 2222

# Только ED25519 ключи
HostKeyAlgorithms ssh-ed25519
PubkeyAcceptedAlgorithms ssh-ed25519

Firewall (nftables):

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        iif lo accept
        tcp dport 2222 ip saddr { 93.184.216.0/24 } accept  # SSH только с нашей сети
        tcp dport { 80, 443 } accept  # HTTP/HTTPS
        drop
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
    }
    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Мониторинг целостности файлов (AIDE):

# Установка и инициализация AIDE
apt install aide

# Настраиваем контроль критичных директорий
cat >> /etc/aide/aide.conf << 'EOF'
/usr/sbin Full
/usr/bin Full
/etc/ssh Full
/var/www/shop Full
EOF

# Создаём начальную базу
aideinit
cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Ежедневная проверка в cron
0 4 * * * /usr/bin/aide --check | mail -s "AIDE report" admin@shopexpress.ru

Fail2ban для защиты от brute force:

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2222
maxretry = 3
bantime = 3600
findtime = 600
action = %(action_mwl)s

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

apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Этот инцидент стоил «ШопЭкспресс» двух дней простоя, репутационных рисков и расходов на восстановление. Причина оказалась банальной: пароль root, утёкший через открытый phpMyAdmin, и 8 месяцев без обновлений.

Ключевые уроки:

• Никогда не используйте пароль для SSH — только ключи ED25519. Даже сложный пароль может утечь через скомпрометированный сервис.
• Запрещайте root-логин по SSH — работайте через обычного пользователя с sudo.
• Обновляйте систему регулярно — unattended-upgrades для security-патчей стоит включать на любом продакшен-сервере.
• Делайте бэкапы и проверяйте их — без бэкапа файлов сайта мы бы не смогли обнаружить модифицированный footer.php.
• Мониторьте целостность файлов — AIDE или OSSEC обнаружат подмену бинарников в течение суток.
• При взломе — не чистите, а пересобирайте — только полная переустановка гарантирует, что сервер чист.

После внедрения всех мер мы настроили ежемесячный аудит безопасности: автоматический запуск Lynis с отправкой отчёта и ручная проверка открытых портов через nmap с внешнего хоста.