Röviden: A módosított fájlokat Linuxon a find paranccsal és egy időablakkal találja meg, például 2026. október 17-től, a sajtóbeszámolók szerint az első megfigyelt PHP2Shell-támadási kísérlet napjától. Ne csak a tartalom módosítási idejét (mtime) ellenőrizze, hanem a metaadatokét (ctime) is, mert az előbbi könnyen hamisítható. Az eredmény csak a csomagok ellenőrző összegeivel, a Gittel vagy egy mentéssel való összevetéssel válik megbízhatóvá.
Miért jó kiindulópont az időbélyeg, de nem bizonyíték
Aki kódot juttat egy szerverre, fájlokat módosít. Új webshellek, módosított konfigurációs fájlok, meglévő szkriptekbe beírt sorok: mindez időbélyeget hagy maga után. A módosítások keresése a megfelelő időablakban ezért az első leletekhez vezető egyik leggyorsabb út.
A PHP2Shellnél az ablak kezdetének 2026. október 17. kínálkozik, a sajtóbeszámolók szerint az első megfigyelt támadási kísérlet napja. A javítások október 21-én jelentek meg. Aki a szerverét csak ezután frissítette, a saját frissítése napjáig és azon túl is keres. Hogyan ismeri fel a webshelleket a leletek között, azt a Webshell felismerése és eltávolítása írja le. Itt magáról a keresési módszerről van szó.
Egy fájl három időbélyege
A Linux minden fájlhoz több időpontot tárol. A módosítások keresésénél kettő a döntő.
| Időbélyeg | Jelentés | Hamisítható? |
|---|---|---|
| mtime | a tartalom utolsó módosítása | igen, pl. a touch paranccsal, bárki által, aki a fájlt írhatja |
| ctime | a tartalom vagy a metaadatok, például jogosultságok utolsó módosítása | egyszerű eszközökkel nem |
| atime | az utolsó olvasási hozzáférés | gyakran kikapcsolt vagy pontatlan, a kereséshez kevéssé alkalmas |
A támadók szívesen visszadátumozzák az mtime-ot a szomszédos fájlok dátumára, hogy egy új fájl ne tűnjön fel. A ctime ilyenkor azonban vele együtt változik. A régi mtime-mal és friss ctime-mal rendelkező fájl ezért a manipuláció erős jele.
Az összehasonlításnál figyeljen az időzónákra. A find és az ls a szerver helyi idejét mutatja, sok naplófájl és szolgáltatás viszont UTC-ben dolgozik. Aki a fájlrendszer és a naplók leleteit egymás mellé teszi, számítson át minden adatot ugyanabba az időzónába, különben az események látszólag nem illenek össze. A javítások nagyjából október 21-én 14:00 UTC-kor jelentek meg, vagyis német idő szerint 16 órakor.
Módosított fájlok keresése Linuxon a finddal
Minden parancs csak olvas. Igazítsa az útvonalat és a dátumot.
# A tartalom 2026.10.17. óta módosult, rendezve, mtime-mal, ctime-mal és tulajdonossal
find /var/www -type f -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM %CY-%Cm-%Cd %CH:%CM %u %p\n' | sort
# A metaadatok 2026.10.17. óta módosultak (a visszadátumozott fájlokat is megtalálja)
find /var/www -type f -newerct "2026-10-17" -printf '%C+ %T+ %p\n' | sort
# Az ismert zaj kiszűrése: gyorsítótár, naplók, munkamenetek
find /var/www -type f -newerct "2026-10-17" \
-not -path "*/cache/*" -not -path "*/logs/*" -not -path "*/sessions/*" -printf '%C+ %p\n' | sort
# A webkönyvtáron kívül is nézzen körül
find /etc /usr/local/bin /tmp /var/tmp /dev/shm -xdev -type f -newerct "2026-10-17" -printf '%C+ %p\n' 2>/dev/null | sort
Minden találatnál vesse össze mindkét időbélyeget. Ha a ctime észrevehetően fiatalabb az mtime-nál, és ebben az időben senki sem módosított jogosultságokat vagy másolt fájlokat, a fájl a listára kerül. Figyeljen a tulajdonosra is: egy webszerver-felhasználó fájlja a deploy-felhasználó fájljai között feltűnő.
Ne feledkezzen meg a rejtett fájlokról és könyvtárakról. A ponttal kezdődő neveket sok fájlkezelő és egy egyszerű ls nem mutatja. A támadók szívesen használják ezt, ahogyan az igazi fájlokhoz összetéveszthetően hasonló neveket is.
# Rejtett fájlok és mappák a webkönyvtárban, az ismertek, például .htaccess és .git nélkül
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+ %u %p\n' | sort
Összevetés egy megbízható forrással
Az időbélyegek megmutatják, hol mozdult meg valami. Hogy jogos módosítás volt-e, azt csak egy olyan forrással való összevetés mutatja meg, amelyben megbízik.
- Csomagkezelő: A rendszerfájlokat a
dpkg --verify(Debian/Ubuntu) vagy azrpm -Va(RHEL-család) ellenőrzi a telepített csomagok ellenőrző összegei alapján. A konfigurációs fájlok jogosan eltérnek, a programfájlok nem. - Git: Ha az alkalmazás egy repositoryban van, a
git -C /var/www/projekt status --porcelainminden, az utolsó committól való eltérést megmutat. - CMS-ellenőrző összegek: Sok rendszer képes a magfájljait összevetni a hivatalos ellenőrző összegekkel, lásd CMS-magfájlok összevetése az eredetivel.
- Az incidens előtti mentés: A próbafuttatásos összehasonlítás kilistázza a különbségeket, anélkül hogy bármit másolna.
# A mentés és az éles rendszer közötti különbségek kilistázása (próbafuttatás, nem másol semmit)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
A mentéssel való összevetés feltételezi, hogy a mentés az incidens előtt keletkezett, és maga nem módosult. Hogy miért döntőek itt az elkülönítve őrzött mentések, azt a Mentések a 3-2-1 szabály szerint magyarázza.
Minden keresés eredményét mentse dátummal egy, a szerveren kívüli fájlba. Ezekből a listákból készül később az incidens idővonala, és igazolják, mit mikor ellenőrzött.
Ha nincs sem mentés, sem repository
Sok kisebb weboldalnál nincs tiszta összehasonlítási alap: nincs Git, nincs az incidens előtti mentés, a pluginokat évek óta kézzel frissítik. Teljesen támpont nélkül mégsem marad.
Töltse le a gyártótól a CMS-t és a bővítményeket pontosan a telepített verziókban, és vesse össze ezeket a fájlokat a szerverrel. Ami ott eltér vagy hiányzik, megér egy pillantást. Megmaradnak a saját módosításai, a feltöltések és a konfiguráció; ott az időbélyeges keresés segít, kiegészítve a tulajdonos és a jogosultságok vizsgálatával. A listára kerülnek azok a fájlok, amelyek egy könyvtárban egyedül más csoporttal, más jogosultságokkal vagy a szomszédaiknál észrevehetően fiatalabb ctime-mal rendelkeznek.
Őszintén szólva: összehasonlítási alap nélkül marad egy maradék bizonytalanság. Érzékeny adatokat kezelő rendszereknél ilyenkor gyakran megbízhatóbb a tiszta forrásokból való újjáépítés, mint minden egyes módosított fájl keresése. A jövőre nézve a tanulság egyszerű: egy repository a kódnak, és rendszeres, elkülönítve őrzött mentések.
Tipikus hibaforrások a keresésnél
- Túl bőkezű kizárások: A gyorsítótár- és feltöltési mappák népszerű búvóhelyek.
- Csak az mtime ellenőrzése: A visszadátumozott fájlok átcsúsznak.
- Telepítés az időablakban: Egy szokásos kiadás több száz fájlt módosít, és elfedi az egyes leleteket. Vesse össze a repositoryval.
- Már megnyitott vagy lemásolt fájlok: Az időbélyegek megőrzése nélküli másolatok nyomokat semmisítenek meg. Olyan eszközökkel mentsen, amelyek megőrzik az időbélyegeket.
- Csak a webkönyvtár átvizsgálása: A támadók eszközöket a
/tmp, a/dev/shmvagy a webszerver-felhasználó saját könyvtárában is elhelyeznek. - Jogosultságmódosítások figyelmen kívül hagyása: Az a fájl, amelynek jogosultságai hirtelen mindenkinek írási hozzáférést engednek, lelet, még ha a tartalma változatlan is.
Hogyan áll össze a leletekből egy lefolyás, azt a Egy incidens idővonalának elkészítése mutatja.
Hogyan segít konkrétan a PHP SOS?
- Rendszeres keresés: Átvizsgáljuk a webkönyvtárakat és a rendszerútvonalakat a releváns időablak módosításaira, és az mtime-ot és a ctime-ot együtt értékeljük.
- Összevetés az eredetivel: Összevetjük csomagokkal, repositoryval, CMS-ellenőrző összegekkel és a mentéseivel.
- A leletek értékelése: Elválasztjuk a szokásos módosításokat a manipulációktól, és mentjük a bizonyítékokat.
- Tisztítás: A kártevő-eltávolítással tiszta állapotot állítunk elő és dokumentáljuk.
Gyakori kérdések
Hogyan találom meg az összes fájlt, amelyet egy bizonyos dátum óta módosítottak?
A find paranccsal és a -newermt opcióval, például find /var/www -type f -newermt "2026-10-17". A metaadatok módosításához használja a -newerct opciót. Mindkét parancs csak olvas, és semmit sem változtat.
Mi a különbség az mtime és a ctime között?
Az mtime a tartalom utolsó módosításának időpontja, és egyszerű eszközökkel visszadátumozható. A ctime a tartalom vagy a metaadatok utolsó módosításának időpontja, és nem hamisítható ilyen egyszerűen. Ha a kettő erősen eltér egymástól, érdemes alaposan megnézni.
Hogyan zárom ki a gyorsítótár-fájlokat a keresésből?
A -not -path opcióval az ismert gyorsítótár-, napló- és munkamenet-mappákra. Ne zárjon ki azonban túl bőkezűen, mert a támadók szívesen éppen oda helyeznek fájlokat, ahol sok módosítás normális.
Melyik ellenőrzés a legmegbízhatóbb?
Az összevetés egy megbízható forrással: a csomagkezelő ellenőrző összegeivel, egy Git-repositoryval vagy az incidens előtti mentéssel. Az időbélyegek jó kiindulópont, de nem bizonyíték.