Пробивът рядко изглежда като на кино. Никой не пише нищо в терминала и на екрана не се появяват черепи. Обичайното е по-скучно: сървърът се забавя, хостинг доставчикът изпраща писмо за изходящ спам или сайтът започва да праща посетителите към чужд адрес.

По-долу са седем проверки в реда, в който има смисъл да се правят. Заедно отнемат около десет минути.

1. Какво изяжда процесора

top -c
ps aux --sort=-%cpu | head -20

Търси се процес с безсмислено име, който държи процесора на почти сто процента. Копаенето на криптовалути е най-честата последица от пробив просто защото е най-бързият начин да се печели на чужд сървър.

Две неща заслужават по-внимателен поглед. Процеси, стартирани от /tmp, /dev/shm или /var/tmp — оттам нормално не се стартира нищо. И имена, които приличат на системни процеси, без да съвпадат напълно: kswapd0 с високо натоварване на процесора, стартиран от грешна директория, или crond с главно C.

sudo ls -l /proc/<pid>/exe
sudo ls -l /proc/<pid>/cwd

Първата команда показва истинския път до изпълнимия файл, втората — директорията, в която работи процесът. Обикновено това е достатъчно, за да се разбере за какво става дума.

2. Изходящи връзки

sudo ss -tupn
sudo ss -tupn state established

Обикновеният уеб сървър рядко се свързва навън: към огледалата на пакетния мениджър, към платежния шлюз, към услугата за изпращане на поща. Устойчиви връзки към непознати адреси на високи портове са или майнинг пул, или контакт с управляващ сървър.

Помнете, че тази проверка сама по себе си е слаба: зловредният код често се свързва само по график. Това, че сега не виждате нищо, не означава, че няма нищо.

3. Cron задачи на всички потребители

Точно тук се закрепват така, че почистеното да се върне.

for u in $(cut -f1 -d: /etc/passwd); do echo "== $u"; sudo crontab -u "$u" -l 2>/dev/null; done
sudo ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/
sudo cat /etc/crontab

Подозрително е: редовете с @reboot, дългите кодирани команди, извикванията на curl или wget, подавани към обвивка, всичко, което се стартира от временни директории.

4. SSH ключове и потребители

sudo find /home /root -name authorized_keys -exec ls -l {} \; -exec cat {} \;
sudo awk -F: '$3 == 0 {print $1}' /etc/passwd
sudo lastlog | head -20

Всеки ред в authorized_keys е нечий постоянен достъп, който преживява и смяната на паролата, и рестарта. Ако не можете да кажете чий е ключът, смятайте го за чужд — коментарът в края на реда е свободен текст и не доказва нищо.

Втората команда извежда всички акаунти с uid 0. Там трябва да е само root.

5. Журналите за влизания

sudo grep 'Accepted' /var/log/auth.log | tail -30
sudo last -20
who

Важни са успешните влизания, а не неуспешните. Неуспешните опити са фонов шум, който има всеки сървър в интернет. Успешно влизане от непознат адрес в момент, когато никой не е работил, е конкретен отговор.

На Debian 12 и Ubuntu 24.04 файлът /var/log/auth.log често изобщо липсва — rsyslog вече не се инсталира по подразбиране. Четете вместо това журнала:

sudo journalctl -u ssh --since '7 days ago' | grep Accepted

6. Променени системни файлове

На Debian и Ubuntu има готов еталон: всеки пакет носи със себе си контролните суми на своите файлове.

sudo apt install debsums
sudo debsums -c

Променените конфигурационни файлове в /etc са нормални — тях сте ги променяли вие. Променените изпълними файлове в /usr/bin, /bin или /usr/sbin са точно това, което сте търсили.

7. Необичайни файлове в корена на сайта

sudo find /var/www -name '*.php' -mtime -7 -ls
sudo find /var/www/uploads -name '*.php'

Втората команда е по-важна от първата. PHP файл в директорията за качени файлове няма никакво законно основание да е там, а това е най-честото място за уеб обвивка.

Ако наистина се открие нещо

Първият импулс е находката веднага да се изтрие. Това е грешка: заедно с файла изчезва информацията как е попаднал там, а без отговор на този въпрос всичко се повтаря след няколко дни.

  1. Запазете копие на файла и времето на промяната му.
  2. Потърсете в журналите на уеб сървъра какво се е случило по същото време — там обикновено е входната точка.
  3. Минете през всичките седем точки, не само през тази, в която сте намерили нещо. Задни врати почти никога не се оставят в един-единствен екземпляр.
  4. Едва след това чистете и затваряйте самата уязвимост.

И едно честно ограничение: ако нападателят е получил root, на никоя проверка отвътре не може да се вярва напълно — самите инструменти може да са подменени. При дълбок пробив единственият надежден път е нов сървър и прегледано възстановяване от резервно копие.

Какво прави проверката трудна

Главната трудност тук не са командите, а това, че непознат ред не изглежда подозрителен, когато човек не помни как е изглеждал списъкът миналата седмица. На сървър, настроен от някой друг, е почти невъзможно да се различи своето от чуждото.

Оттук изводът е практичен: направете моментна снимка на състоянието, докато сървърът е наред. Списъкът с процеси, портове, cron задачи и ключове на здрава машина е еталонът, с който после ще сравнявате — и тогава часовете търсене се превръщат в сравнение на два списъка. Как изглежда всичко това, събрано на една страница, показва демонстрацията по-долу.