Průnik málokdy vypadá jako ve filmu. Nikdo nic nepíše do terminálu a na obrazovce se neobjevují lebky. Obvyklý průběh je nudnější: server zpomalí, poskytovatel hostingu pošle dopis o odchozím spamu, nebo web začne posílat návštěvníky na cizí adresu.

Níže je sedm kontrol v pořadí, v jakém má smysl je dělat. Dohromady zaberou asi deset minut.

1. Co žere procesor

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

Hledá se proces s nesmyslným názvem, který drží procesor na téměř sto procentech. Těžba kryptoměn je nejčastější důsledek průniku prostě proto, že je to nejrychlejší způsob, jak vydělat na cizím serveru.

Dvě věci stojí za bližší pohled. Procesy spouštěné z /tmp, /dev/shm nebo /var/tmp — odtud se normálně nespouští nic. A názvy, které připomínají systémové procesy, ale nesedí úplně: kswapd0 s vysokou zátěží procesoru spuštěný ze špatného adresáře, nebo crond s velkým C.

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

První příkaz ukáže skutečnou cestu ke spustitelnému souboru, druhý adresář, v němž proces pracuje. To obvykle stačí k pochopení, o co jde.

2. Odchozí spojení

sudo ss -tupn
sudo ss -tupn state established

Běžný webový server se ven připojuje zřídka: k zrcadlům správce balíčků, k platební bráně, ke službě rozesílání e-mailů. Trvalá spojení na neznámé adresy na vysokých portech jsou buď těžební pool, nebo kontakt s řídicím serverem.

Nezapomeňte, že tato kontrola je sama o sobě slabá: škodlivý kód se často připojuje jen podle rozvrhu. To, že právě teď nic nevidíte, neznamená, že nic není.

3. Cronové úlohy všech uživatelů

Právě tady se zakotvuje tak, aby se uklizené vrátilo.

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

Podezřelé je: řádky s @reboot, dlouhé zakódované příkazy, volání curl nebo wget předávané do shellu, cokoli, co se spouští z dočasných adresářů.

4. Klíče SSH a uživatelé

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

Každý řádek v authorized_keys je něčí trvalý přístup, který přežije změnu hesla i restart. Pokud nedokážete říct, čí klíč to je, považujte ho za cizí — komentář na konci řádku je volný text a nedokazuje nic.

Druhý příkaz vypíše všechny účty s uid 0. Má tam být jen root.

5. Logy přihlášení

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

Důležitá jsou úspěšná přihlášení, ne neúspěšná. Neúspěšné pokusy jsou šum na pozadí, který má každý server na internetu. Úspěšné přihlášení z neznámé adresy v době, kdy nikdo nepracoval, je konkrétní odpověď.

Na Debianu 12 a Ubuntu 24.04 soubor /var/log/auth.log často vůbec neexistuje — rsyslog se už standardně neinstaluje. Čtěte místo toho žurnál:

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

6. Změněné systémové soubory

Na Debianu a Ubuntu existuje hotový vzor: každý balíček s sebou nese kontrolní součty svých souborů.

sudo apt install debsums
sudo debsums -c

Změněné konfigurační soubory v /etc jsou normální — ty jste měnili sami. Změněné spustitelné soubory v /usr/bin, /bin nebo /usr/sbin jsou přesně to, co jste hledali.

7. Neobvyklé soubory v kořeni webu

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

Druhý příkaz je důležitější než první. PHP soubor v adresáři nahraných souborů nemá žádný legitimní důvod tam být a je to nejčastější místo pro webshell.

Když se skutečně něco najde

První impulz je nález hned smazat. To je chyba: spolu se souborem zmizí informace o tom, jak se tam dostal, a bez odpovědi na tuto otázku se za pár dní všechno zopakuje.

  1. Uložte kopii souboru a čas jeho změny.
  2. Vyhledejte v logech webového serveru, co se dělo ve stejnou dobu — tam bývá vstup.
  3. Projděte všech sedm bodů, ne jen ten, kde se něco našlo. Zadní vrátka se téměř nikdy nenechávají v jediném exempláři.
  4. Teprve potom ukliďte a zavřete samotnou zranitelnost.

A poctivé vymezení: pokud útočník získal root, žádné kontrole zevnitř nelze plně věřit — samotné nástroje mohou být vyměněné. Při hlubokém průniku je jedinou spolehlivou cestou nový server a prověřená obnova ze zálohy.

Co dělá kontrolu obtížnou

Největší potíž zde nejsou příkazy, ale to, že neznámý řádek nevypadá podezřele, když si člověk nepamatuje, jak seznam vypadal minulý týden. Na serveru, který nastavoval někdo jiný, je téměř nemožné odlišit vlastní od cizího.

Proto je závěr praktický: udělejte snímek stavu, dokud je server v pořádku. Seznam procesů, portů, cronových úloh a klíčů na zdravém stroji je vzor, s nímž budete později porovnávat — a hodiny hledání se promění v porovnání dvou seznamů. Jak to vypadá shromážděné na jedné stránce, ukazuje ukázka níže.