Накратко: Подозрителни процеси на Linux сървъри разпознавате по малко признаци: файлът на програмата е изтрит или е в /tmp, /dev/shm или уеб директория, името имитира системен процес, необичаен потребител, трайни мрежови връзки или голямо натоварване без причина. Проверете с команди само за четене дали файлът на програмата принадлежи към инсталиран пакет и запазете находките, преди да прекратите нещо.
Какво значи „подозрителен“ при един процес
На уеб сървър работят стотици процеси. Повечето принадлежат на операционната система, на уеб сървъра, на базата данни или на PHP. Нападател, който е могъл да изпълни код през уязвимост като PHP2Shell, се стреми да не се набива на очи между тях. Той избира неугледни имена и поставя програми там, където потребителят на уеб сървъра може да пише.
За проверката помага познаването на нормалното състояние. Който знае кои услуги трябва да работят на сървъра, под кои потребители и с какво натоварване, разпознава отклоненията много по-бързо. Ако това знание липсва, си заслужава да се вземе за сравнение списъкът с процесите на подобен, неподозрителен сървър.
Отделен признак още не е доказателство. Решаващо е съчетанието. Процес с името на нишка на ядрото, който работи под www-data, стартиран е от /dev/shm и държи връзка в чужбина, е ясен случай. Как да проверите особения случай на shell под уеб сървъра, описва Предупредителен сигнал: уеб сървърът стартира shell.
Първи преглед с пет команди
Всички команди само четат. Изпълнете ги като root, за да виждате всички процеси, и запишете изходите във файл извън уеб директорията.
# 1. Всички процеси с потребител, PID на родителя, време на стартиране, CPU и команден ред
ps -eo user,pid,ppid,lstart,%cpu,%mem,cmd --sort=-%cpu | head -40
# 2. Процеси, чийто файл на програмата е изтрит
ls -l /proc/[0-9]*/exe 2>/dev/null | grep "(deleted)"
# 3. Процеси, които работят от временни или уеб директории
ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E " -> (/tmp|/var/tmp|/dev/shm|/var/www)"
# 4. Процеси с мрежови връзки
ss -tunap
# 5. Преглед на процесите на потребителите на уеб сървъра
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) "
Потребителските имена се различават според дистрибуцията и панела; Plesk и други панели често изпълняват PHP под потребителя на съответния клиент. Пригодете списъка към Вашата среда.
Четете изходите с поглед към времето на стартиране. Процеси, които работят от последния рестарт на сървъра, обикновено принадлежат към системата. Процеси, стартирани посред нощ или в дните след 17 октомври и неподхождащи на никоя услуга, заслужават внимание. Сравнете и броя на PHP процесите с онова, което позволява конфигурацията на пула; значително повече процеси под потребител на уеб сървъра са указание.
Подозрителни процеси под Linux: типични признаци
| Признак | Защо прави впечатление | Възможно ли е безобидно обяснение? |
|---|---|---|
| Файл на програмата „(deleted)“ | Нападателите изтриват файлове след стартирането | да, след актуализации на пакети до рестарта |
Място на стартиране /tmp, /dev/shm, директория за качване |
там всеки или уеб сървърът може да пише | рядко |
Име в квадратни скоби като [kworker] |
имитира нишки на ядрото | не, ако зад него стои файл на програма |
| Трайно високо натоварване на CPU без повод | типично за криптоминъри | да, при batch задачи или индексиране |
| Родителски процес 1 и потребител на уеб сървъра | откъснат от уеб сървъра, продължава да работи самостоятелно | рядко |
| Връзка към неизвестна цел | управление или изтичане на данни | да, при актуализации и API |
Истинските нишки на ядрото нямат файл на програмата; ls -l /proc/PID/exe не връща за тях път. Ако процес с име на ядро сочи към файл, той е маскиран. При голямо натоварване без видима причина помага статията Криптоминър на уеб сървъра.
Насрещна проверка: принадлежи ли файлът на програмата към пакет?
Почти всички легитимни програми на един сървър идват от управлението на пакетите. Файл на програма, който не принадлежи на никой пакет, не е автоматично злонамерен, но заслужава внимателен поглед.
PID=12345
EXE=$(readlink /proc/$PID/exe); echo "$EXE"
dpkg -S "$EXE" # Debian/Ubuntu: към кой пакет принадлежи файлът?
rpm -qf "$EXE" # RHEL семейство
sha256sum /proc/$PID/exe # контролна сума, работи и при изтрит файл
tr '\0' ' ' < /proc/$PID/environ | head -c 600; echo # променливи на средата
Ако файлът на програмата е изтрит, sha256sum /proc/$PID/exe все пак го чете от работещия процес. Тази контролна сума принадлежи в документацията. Копие на файла бива да създава само който знае как да го съхрани безопасно.
Граници на проверката върху работещата система
Всички команди по-горе се доверяват на системата, която проверявате в момента. При обикновено проникване през уебсайта с правата на потребителя на уеб сървъра това е допустимо. Ако нападателят е получил права на root, той може да крие процеси и да фалшифицира изходите. Тогава сървърът показва само онова, което нападателят допуска.
Указание за това са противоречията: натоварване без видим процес, връзки, които защитната стена вижда, а ss не, или променени системни програми. В такива случаи проверката принадлежи върху обезопасен образ. При работещи системи често се добавя запазване на оперативната памет, защото някои злонамерени програми съществуват само там и оставят на диска малко следи. Това запазване трябва да стане преди рестарт и изисква подходящи инструменти и опит. Защо трябва да го направите преди преинсталиране, обяснява Запазете доказателствата, преди да инсталирате наново.
Не прекратявайте подозрителните процеси като първа стъпка. Често cron задача или услуга ги стартира наново, а с процеса от паметта изчезват командният ред, връзките и изтритият файл на програмата.
Проверка на автоматичните стартирания и следващи стъпки
Злонамерен процес, който би изчезнал след рестарт, би бил безполезен за нападателите. Затова към всяка находка на процес принадлежи въпросът какво го стартира. Освен cron задачите на преден план идват най-вече услугите на systemd, които нападател с права на root може да създаде. Правят впечатление услуги с общи имена, чийто файл на програма стои в необичайна директория, и unit файлове, възникнали след 17 октомври.
# Работещи услуги и наскоро променени unit файлове
systemctl list-units --type=service --state=running --no-pager
find /etc/systemd /usr/lib/systemd /lib/systemd -type f -newerct "2026-10-17" -ls 2>/dev/null
# Внедрява ли се библиотека във всеки процес? Файлът обикновено не съществува.
ls -l /etc/ld.so.preload 2>/dev/null && cat /etc/ld.so.preload
Запис в /etc/ld.so.preload е рядкост на нормални уеб сървъри и силен признак за манипулация с права на root. Как да проверите планираните задачи изцяло, описва Разпознаване на скрити cron задачи като задна вратичка.
След това следващите стъпки са в този ред:
- Запазете изходите и контролните суми с час.
- Потърсете постоянство: cron задачи, услуги и таймери на systemd, SSH ключове.
- Изяснете произхода: логове от 20 октомври, нови файлове в уеб директорията.
- Изолирайте сървъра и планирайте почистване или ново изграждане.
Преглед на всички типични признаци след PHP2Shell дава Компрометиран ли съм вече?.
Как помага PHP SOS конкретно?
- Оценка на процесите: Проверяваме списъка с процеси, файловете на програмите и връзките и класифицираме всяка находка.
- Запазване, годно за съд: С ИТ форензика запазваме оперативната памет и носителите на данни, преди нещо да бъде променено.
- Намиране на постоянството: Търсим механизми, които стартират наново злонамерените процеси.
- Приключване: Почистваме или изграждаме наново и документираме инцидента до приключването.
Често задавани въпроси
По какво разпознавам подозрителен процес под Linux?
Типични признаци са изтрит файл на програмата, място на стартиране в /tmp или /dev/shm, име, което имитира системен процес, необичаен потребител и трайни мрежови връзки. Отделните признаци са указания, няколко заедно - сериозно подозрение.
Какво значи „(deleted)“ при /proc/PID/exe?
Файлът на програмата на процеса е бил изтрит след стартирането. Това е легитимно след актуализации на пакети, докато услугата не се рестартира. При процеси от временни директории или под потребителя на уеб сървъра е типично поведение на маскиране.
Мога ли да се доверя на изхода на ps?
При обикновено проникване най-често да. Ако нападателят е получил права на root, обаче може да манипулира инструментите и изходите. Тогава проверка отвън, например върху обезопасен образ, е по-надеждна.
Трябва ли да прекратя подозрителен процес с kill?
Не като първа стъпка. Първо запазете командния ред, файла на програмата, връзките и времето на стартиране. Прекратеният процес вече не разкрива нищо, а често cron задача или услуга така или иначе го стартира наново.