VDS взломали или хостер прислал абузу: практический поиск скрытых майнеров, веб-шеллов и rootkit на Linux

Самый тревожный кошмар любого инженера и вебмастера начинается с лаконичного письма от технической поддержки хостинг-провайдера: «С вашего IP-адреса зафиксирована аномальная исходящая сетевая активность (DDoS-атака, сканирование портов) или 100% утилизация CPU майнингом криптовалют. У вас есть 24 часа на устранение угрозы, иначе сервер будет заблокирован».

Вы подключаетесь по SSH, запускаете привычный htop — но в терминале подозрительная тишина: суммарная нагрузка вроде бы не превышает 5%, подозрительных процессов нет, а при перезагрузке сервера через пару минут процессор снова раскаляется до предела. Злоумышленники давно научились маскировать активность: современные майнеры перехватывают системные вызовы ядра, скрывают свои PID из каталога /proc, маскируются под системные потоки [kworker/0:1] и восстанавливаются через скрытые таймеры.

В этом руководстве мы разберём пошаговый алгоритм расследования инцидента (Security Forensics) на Linux: от экстренной изоляции сетевого интерфейса до обнаружения скрытых процессов, чистки веб-шеллов и правильной эвакуации данных на чистый VDS без повторного заражения.

1. Первая помощь при абузе: изоляция сервера без потери доступа по SSH

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

Действовать необходимо хладнокровно: в первую очередь нужно остановить исходящую сетевую атаку, сохранив при этом входящее SSH-управление сервером. Если хостер видит, что паразитный трафик прекратился, риск блокировки порта сводится к нулю.

Выполним экстренную блокировку исходящего сетевого мусора на уровне iptables. Запретим исходящие соединения на типовые порты пулов майнинга (Monero/Stratum) и спам-рассылок, оставив только доверенные DNS-резолверы и веб-трафик:

# Сбрасываем исходящие соединения к известным пулам майнинга (Stratum TCP)
sudo iptables -A OUTPUT -p tcp -m multiport --dports 3333,4444,5555,7777,8888,9999,14433,14444 -j DROP

# Блокируем исходящий спам через SMTP (если сервер не почтовый)
sudo iptables -A OUTPUT -p tcp -m multiport --dports 25,465,587 -j DROP

# Запрещаем исходящие ICMP flood пакеты
sudo iptables -A OUTPUT -p icmp -j DROP

После применения правил немедленно отправьте короткий ответ в тикет хостинга: «Здравствуйте! Исходящий подозрительный трафик локализован правилами фаервола. Проводится аудит безопасности и выявление скомпрометированного процесса». Это даст вам спокойные 24–48 часов на детальный анализ.

2. Охота за невидимыми процессами: почему top врет и как найти скрытый PID

Почему утилиты top, htop и ps aux часто не показывают майнер, пожирающий 100% ресурсов vCPU?

В Linux все утилиты мониторинга считывают информацию о процессах из виртуальной файловой системы /proc. Хакеры используют три основных трюка сокрытия:

• Перехват libc через /etc/ld.so.preload: вредоносная динамическая библиотека перехватывает функции readdir() и stat(), вычеркивая определенные строки из выдачи.
• Монтирование пустых каталогов поверх /proc/[PID]: утилита монтирует временную файловую систему tmpfs прямо поверх директории процесса.
• Подмена системных бинарников: файлы /bin/ps, /usr/bin/top или /usr/bin/lsof заменяются на модифицированные скрипты или бинарники.

Проверим наличие перехватчика библиотек ld.so.preload — это самый популярный вектор в современных троянах (например, Kinnod, Sysupdate или XMRig-дропперах):

# Проверяем файл предзагрузки динамических библиотек
cat /etc/ld.so.preload

# Если файл существует и содержит пути к неизвестным .so библиотекам, нейтрализуем его:
sudo cp /etc/ld.so.preload /root/ld.so.preload.bak
sudo truncate -s 0 /etc/ld.so.preload
sudo chattr +i /etc/ld.so.preload

Как найти процесс, если он скрыт от ps? Воспользуемся расхождением между системным планировщиком ядра и файловой системой /proc с помощью специализированной утилиты unhide:

# Устанавливаем диагностический пакет unhide
sudo apt update && sudo apt install -y unhide

# Сканируем скрытые процессы методом сравнения системных вызовов
sudo unhide proc
sudo unhide sys
sudo unhide brute

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

# Проверяем потребление процессорного времени через systemd-cgls
systemd-cgls --all

# Выводим реальное распределение CPU по службам и пользователям
systemd-cgtop -b -n 1

Если вы видите службу или ветку процессов с аномальным потреблением тактов процессора, выпишите ее PID для дальнейшего анализа.

3. Сетевой аудит: отслеживание соединений с пулами майнинга и C2-серверами

Любой вредоносный софт обязан взаимодействовать с внешним миром: майнеру нужно получать задания и отправлять хеши на пул (обычно по протоколу Stratum), а ботнету — принимать команды с Command & Control (C2) сервера.

Просканируем все активные сетевые сокеты и определим, какие процессы инициировали внешние сессии:

# Выводим все установленные TCP/UDP соединения с номерами процессов
sudo ss -tupn state established

# Ищем сокеты, открытые на нестандартных портах
sudo lsof -i -P -n | grep ESTABLISHED

Если злоумышленник пытается скрыть процесс, утилита lsof может вывести соединение без указания имени команды, либо указать на удаленный файл вида /tmp/x (deleted).

Как только обнаружен подозрительный внешний IP-адрес (например, 198.51.100.24:3333), исследуем владельца инфраструктуры и доменное имя с помощью инструмента DNS Lookup и Резолвер, а также проверим открытые порты хоста через Сканер открытых портов онлайн.

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

# Приостанавливаем выполнение процесса сигналом STOP (он замирает в памяти)
sudo kill -STOP [PID]

# Исследуем его рабочий каталог и окружение
sudo ls -la /proc/[PID]/
sudo cat /proc/[PID]/cmdline
sudo readlink -f /proc/[PID]/exe

4. Точки закрепления зловреда: cron, systemd-таймеры и поддельные сервисы

Даже если вы нашли и удалили бинарник майнера, через 10 минут он вернется, если не зачищены механизмы закрепления (Persistence). В Linux существует более десятка мест, куда вредоносные скрипты прописывают автозапуск.

Проведем тотальную ревизию планировщиков задач:

# Проверяем личные кронтабы всех системных пользователей
for user in $(cut -f1 -d: /etc/passwd); do
  crontab -u $user -l 2>/dev/null | grep -v '^#' && echo "=== Выше крон пользователя: $user ==="
done

# Проверяем системные каталоги cron
ls -la /etc/cron*
ls -la /var/spool/cron/crontabs/

Хакеры обожают добавлять свои задачи с маскировкой под системные утилиты: system-update, apache-check, clean-tmp, либо кодируют пейлоад в Base64 через конструкцию echo ... | base64 -d | sh.

Следующий рубеж — системные службы и таймеры systemd. Проверим недавно добавленные юниты:

# Смотрим все активные таймеры в системе
systemctl list-timers --all

# Ищем службы, файлы которых были изменены за последние 3 дня
find /etc/systemd/system/ /lib/systemd/system/ -type f -mtime -3 -ls

5. Поиск веб-шеллов и бэкдоров в коде сайтов (WordPress, Bitrix, Laravel)

В 90% случаев майнеры попадают на VDS не через взлом SSH-порта, а через уязвимости в веб-приложениях: дырявый плагин в WordPress, старую версию Bitrix, загрузку произвольных файлов (arbitrary file upload) или утекший конфигурационный файл .env.

Получив права пользователя www-data, атакующий заливает небольшой PHP веб-шелл (WSO, c99, b374k или крошечный однострочник <?php @eval($_POST['cmd']); ?>), через который уже загружает скомпилированный ELF-майнер в каталог /tmp или /dev/shm.

Организуем скоростной поиск опасных сигнатур в директориях веб-сервера:

# Ищем вызовы системных функций и eval в недавно измененных PHP-файлах (за 7 дней)
find /var/www/ -type f -name "*.php" -mtime -7 -exec grep -lE '(eval|passthru|shell_exec|system|base64_decode|gzinflate)s*(' {} ;

# Ищем скрытые PHP-скрипты в каталогах для загрузки медиафайлов (uploads/images)
find /var/www/*/wp-content/uploads/ -type f -name "*.php*"
find /var/www/*/upload/ -type f -name "*.php*"

Для автоматизированного сканирования кода сайтов отлично подходит утилита Linux Malware Detect (LMD / Maldet) с базой сигнатур веб-угроз:

# Быстрая установка LMD из официального репозитория
cd /usr/local/src/
sudo wget http://www.rfxn.com/downloads/maldetect-current.tar.gz
sudo tar -xzf maldetect-current.tar.gz
cd maldetect-* && sudo ./install.sh

# Обновляем сигнатуры и сканируем веб-директорию
sudo maldet -u
sudo maldet -a /var/www/

Все обнаруженные шеллы будут помещены в безопасный карантин без риска случайного исполнения.

6. Проверка целостности системных бинарников и обнаружение rootkit

Если злоумышленник повысил привилегии до root, обычного поиска файлов недостаточно: в системе мог быть установлен LKM rootkit (модуль ядра Linux) или подменены базовые исполняемые файлы операционной системы.

В дистрибутивах Ubuntu и Debian предусмотрен мощнейший механизм валидации целостности пакетов — утилита debsums. Она сверяет криптографические контрольные суммы каждого бинарника на диске с эталонной базой apt-репозитория:

# Устанавливаем утилиту проверки целостности
sudo apt install -y debsums

# Проверяем все бинарники в системе и выводим только сбойные (измененные)
sudo debsums -c 2>&1 | grep -v 'missing file'

Если команда выдает предупреждение для файлов вроде /bin/ps, /bin/login, /usr/sbin/sshd или /usr/bin/top — системные команды скомпрометированы. Вы больше не можете доверять выводу консоли текущего сервера.

Для глубокого анализа модулей ядра и скрытых перехватчиков прерываний запустим специализированный сканер rkhunter:

# Установка rkhunter
sudo apt install -y rkhunter

# Обновление баз данных и запуск полной проверки без интерактивных пауз
sudo rkhunter --update
sudo rkhunter --check --sk

Внимательно изучите лог-файл /var/log/rkhunter.log. Особое внимание уделите разделам Rootkit checks и Kernel modules.

7. Лечить или переустанавливать? Безопасная эвакуация данных на чистый VDS

В профессиональном системном администрировании существует железное правило E-E-A-T безопасности:

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

1. Разверните чистый VDS: создайте новую виртуальную машину с актуальной версией Ubuntu 24.04 LTS у надежного провайдера.
2. Выполните базовый харденинг: сразу настройте авторизацию только по ключам, отключите root-логин, установите UFW и Fail2ban.
3. Сделайте дамп базы данных: выгрузите SQL-дамп со старого сервера через mysqldump или pg_dump. Текстовый дамп SQL безопасен, его легко проверить на вредоносные вставки <script> или скрытых администраторов CMS.
4. Скопируйте только пользовательский контент: переносите только директории картинок и документов (например, wp-content/uploads). Ни в коем случае не переносите старые бинарники, системные каталоги и ядро CMS целиком!
5. Разверните свежий стек CMS/приложения: установите ядро сайта и проверенные плагины из чистых официальных репозиториев разработчиков.
6. Переключите DNS: привяжите домен к новому IP-адресу и удалите зараженный старый сервер.