A behatolás ritkán néz ki úgy, mint a filmekben. Senki nem gépel a terminálba, és nem jelennek meg koponyák a képernyőn. A szokásos eset unalmasabb: a szerver lelassul, a tárhelyszolgáltató levelet küld a kimenő spamről, vagy a webhely idegen címre kezdi küldeni a látogatókat.

Alább hét ellenőrzés abban a sorrendben, ahogy érdemes elvégezni őket. Összesen körülbelül tíz percet vesznek igénybe.

1. Mi eszi a processzort

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

Olyan folyamatot keresel, amelynek értelmetlen a neve, és közel száz százalékon tartja a processzort. A kriptobányászat a behatolás leggyakoribb következménye, egyszerűen azért, mert ez a leggyorsabb módja a pénzszerzésnek más szerverén.

Két dolog érdemel közelebbi pillantást. A /tmp, /dev/shm vagy /var/tmp könyvtárból induló folyamatok — onnan normális esetben semmi nem indul. És a rendszerfolyamatokra emlékeztető, de nem egészen stimmelő nevek: kswapd0 magas processzorterheléssel, rossz könyvtárból futtatva, vagy crond nagy C-vel.

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

Az első parancs a végrehajtható fájl valódi útvonalát mutatja, a második azt a könyvtárat, amelyben a folyamat dolgozik. Ez általában elég annak megértéséhez, miről van szó.

2. Kimenő kapcsolatok

sudo ss -tupn
sudo ss -tupn state established

Egy szokásos webszerver ritkán kapcsolódik kifelé: a csomagkezelő tükreihez, a fizetési átjáróhoz, az e-mail-küldő szolgáltatáshoz. Tartós kapcsolatok ismeretlen címekre, magas portokon, vagy bányászmedencét jelentenek, vagy kapcsolatot egy vezérlőszerverrel.

Ne feledd, hogy ez az ellenőrzés önmagában gyenge: a kártékony kód gyakran csak ütemezés szerint kapcsolódik. Az, hogy most nem látsz semmit, nem jelenti azt, hogy nincs semmi.

3. Az összes felhasználó cron-feladatai

Itt horgonyoznak le úgy, hogy a kitakarított visszatérjen.

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

Gyanús: a @reboot sorok, a hosszú kódolt parancsok, a shellbe továbbított curl- vagy wget-hívások, minden, ami ideiglenes könyvtárból indul.

4. SSH-kulcsok és felhasználók

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

Az authorized_keys minden sora valakinek az állandó hozzáférése, amely túléli a jelszóváltást és az újraindítást is. Ha nem tudod megmondani, kié a kulcs, tekintsd idegennek — a sor végi megjegyzés szabad szöveg, és semmit nem bizonyít.

A második parancs kilistázza az összes 0 uid-ű fiókot. Ott csak a root szerepelhet.

5. A bejelentkezési naplók

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

A sikeres bejelentkezések a fontosak, nem a sikertelenek. A sikertelen próbálkozások háttérzaj, amely az internet minden szerverén megvan. Egy sikeres bejelentkezés ismeretlen címről olyan időpontban, amikor senki nem dolgozott, konkrét válasz.

Debian 12-n és Ubuntu 24.04-en a /var/log/auth.log fájl gyakran egyáltalán nem létezik — az rsyslog már nem települ alapértelmezetten. Olvasd helyette a naplózót:

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

6. Módosult rendszerfájlok

Debianon és Ubuntun van kész referencia: minden csomag magával hozza a fájljai ellenőrzőösszegeit.

sudo apt install debsums
sudo debsums -c

A /etc könyvtárban módosult konfigurációs fájlok normálisak — azokat te módosítottad. A /usr/bin, /bin vagy /usr/sbin könyvtárban módosult végrehajtható fájlok pontosan azok, amiket kerestél.

7. Szokatlan fájlok a webgyökérben

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

A második parancs fontosabb az elsőnél. Egy PHP-fájlnak semmi jogos oka nincs a feltöltött fájlok könyvtárában lenni, és ez a webshellek leggyakoribb helye.

Ha tényleg találsz valamit

Az első ösztön az, hogy azonnal töröld a leletet. Ez hiba: a fájllal együtt eltűnik az információ arról, hogyan került oda, és e kérdés megválaszolása nélkül néhány nap múlva minden megismétlődik.

  1. Ments másolatot a fájlról és a módosítási idejéről.
  2. Keresd meg a webszerver naplóiban, mi történt ugyanabban az időpontban — általában ott van a belépési pont.
  3. Menj végig mind a hét ponton, ne csak azon, ahol találtál valamit. Hátsó ajtót szinte soha nem hagynak egyetlen példányban.
  4. Csak ezután takaríts, és zárd be magát a sebezhetőséget.

És egy őszinte határ: ha a támadó rootot szerzett, egyetlen belülről végzett ellenőrzésben sem lehet teljesen megbízni — maguk az eszközök is kicserélhetők. Mély behatolás esetén az egyetlen megbízható út az új szerver és az átnézett visszaállítás mentésből.

Ami nehézzé teszi az ellenőrzést

A legnagyobb nehézség itt nem a parancsok, hanem az, hogy egy ismeretlen sor nem tűnik gyanúsnak, ha az ember nem emlékszik, hogyan nézett ki a lista múlt héten. Egy olyan szerveren, amelyet más állított be, szinte lehetetlen megkülönböztetni a sajátot az idegentől.

Ezért a következtetés gyakorlati: készíts pillanatképet az állapotról, amíg a szerver rendben van. A folyamatok, portok, cron-feladatok és kulcsok listája egy egészséges gépen az a referencia, amellyel később összehasonlítasz — és akkor az órákig tartó keresésből két lista összevetése lesz. Hogy néz ki mindez egyetlen oldalra gyűjtve, azt az alábbi bemutató mutatja.