Prienik málokedy vyzerá ako vo filme. Nikto nič nepíše do terminálu a na obrazovke sa neobjavujú lebky. Obvyklý priebeh je nudnejší: server spomalí, poskytovateľ hostingu pošle list o odchádzajúcom spame, alebo web začne posielať návštevníkov na cudziu adresu.

Nižšie je sedem kontrol v poradí, v akom má zmysel ich robiť. Dokopy zaberú asi desať minút.

1. Čo žerie procesor

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

Hľadá sa proces s nezmyselným názvom, ktorý drží procesor na takmer sto percentách. Ťažba kryptomien je najčastejší dôsledok prieniku jednoducho preto, že je to najrýchlejší spôsob, ako zarobiť na cudzom serveri.

Dve veci stoja za bližší pohľad. Procesy spúšťané z /tmp, /dev/shm alebo /var/tmp — odtiaľ sa normálne nespúšťa nič. A názvy, ktoré pripomínajú systémové procesy, ale nesedia celkom: kswapd0 s vysokou záťažou procesora spustený z nesprávneho adresára, alebo crond s veľkým C.

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

Prvý príkaz ukáže skutočnú cestu k spustiteľnému súboru, druhý adresár, v ktorom proces pracuje. To zvyčajne stačí na pochopenie, o čo ide.

2. Odchádzajúce spojenia

sudo ss -tupn
sudo ss -tupn state established

Bežný webový server sa von pripája zriedka: k zrkadlám správcu balíkov, k platobnej bráne, k službe rozosielania e-mailov. Trvalé spojenia na neznáme adresy na vysokých portoch sú buď ťažobný pool, alebo kontakt s riadiacim serverom.

Nezabudnite, že táto kontrola je sama osebe slabá: škodlivý kód sa často pripája len podľa rozvrhu. To, že práve teraz nič nevidíte, neznamená, že nič nie je.

3. Cronové úlohy všetkých používateľov

Práve tu sa zakotvuje tak, aby sa upratané 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

Podozrivé je: riadky s @reboot, dlhé zakódované príkazy, volania curl alebo wget odovzdávané do shellu, čokoľvek, čo sa spúšťa z dočasných adresárov.

4. Kľúče SSH a používatelia

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ý riadok v authorized_keys je niečí trvalý prístup, ktorý prežije zmenu hesla aj reštart. Ak neviete povedať, čí kľúč to je, považujte ho za cudzí — komentár na konci riadka je voľný text a nedokazuje nič.

Druhý príkaz vypíše všetky účty s uid 0. Má tam byť len root.

5. Logy prihlásení

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

Dôležité sú úspešné prihlásenia, nie neúspešné. Neúspešné pokusy sú šum na pozadí, ktorý má každý server na internete. Úspešné prihlásenie z neznámej adresy v čase, keď nikto nepracoval, je konkrétna odpoveď.

Na Debiane 12 a Ubuntu 24.04 súbor /var/log/auth.log často vôbec neexistuje — rsyslog sa už štandardne neinštaluje. Čítajte namiesto toho žurnál:

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

6. Zmenené systémové súbory

Na Debiane a Ubuntu existuje hotový vzor: každý balík so sebou nesie kontrolné súčty svojich súborov.

sudo apt install debsums
sudo debsums -c

Zmenené konfiguračné súbory v /etc sú normálne — tie ste menili sami. Zmenené spustiteľné súbory v /usr/bin, /bin alebo /usr/sbin sú presne to, čo ste hľadali.

7. Nezvyčajné súbory v koreni webu

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

Druhý príkaz je dôležitejší než prvý. PHP súbor v adresári nahraných súborov nemá žiadny legitímny dôvod tam byť a je to najčastejšie miesto pre webshell.

Keď sa skutočne niečo nájde

Prvý impulz je nález hneď zmazať. To je chyba: spolu so súborom zmizne informácia o tom, ako sa tam dostal, a bez odpovede na túto otázku sa o pár dní všetko zopakuje.

  1. Uložte kópiu súboru a čas jeho zmeny.
  2. Vyhľadajte v logoch webového servera, čo sa dialo v rovnakom čase — tam býva vstup.
  3. Prejdite všetkých sedem bodov, nielen ten, kde sa niečo našlo. Zadné vrátka sa takmer nikdy nenechávajú v jedinom exemplári.
  4. Až potom upracte a zatvorte samotnú zraniteľnosť.

A poctivé vymedzenie: ak útočník získal root, žiadnej kontrole zvnútra nemožno plne veriť — samotné nástroje môžu byť vymenené. Pri hlbokom prieniku je jedinou spoľahlivou cestou nový server a preverená obnova zo zálohy.

Čo robí kontrolu zložitou

Najväčší problém tu nie sú príkazy, ale to, že neznámy riadok nevyzerá podozrivo, keď si človek nepamätá, ako zoznam vyzeral minulý týždeň. Na serveri, ktorý nastavoval niekto iný, je takmer nemožné odlíšiť vlastné od cudzieho.

Preto je záver praktický: urobte snímku stavu, kým je server v poriadku. Zoznam procesov, portov, cronových úloh a kľúčov na zdravom stroji je vzor, s ktorým budete neskôr porovnávať — a hodiny hľadania sa premenia na porovnanie dvoch zoznamov. Ako to vyzerá zhromaždené na jednej stránke, ukazuje ukážka nižšie.