# Nemrég módosított fájlok keresése a webszerveren

> Módosított fájlok keresése Linuxon: időablak a findda, az mtime és a ctime helyes értelmezése, összevetés csomagokkal és mentésekkel, téves riasztások kiszűrése.

Forrás: https://phpsos.de/hu/blog/geaenderte-dateien-finden/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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](https://phpsos.de/hu/ratgeber/webshell-erkennen/) í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.

```bash
# 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.

```bash
# 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.

1. **Csomagkezelő:** A rendszerfájlokat a `dpkg --verify` (Debian/Ubuntu) vagy az `rpm -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.
2. **Git:** Ha az alkalmazás egy repositoryban van, a `git -C /var/www/projekt status --porcelain` minden, az utolsó committól való eltérést megmutat.
3. **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](https://phpsos.de/hu/blog/cms-kerndateien-vergleichen/).
4. **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.

```bash
# 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](https://phpsos.de/hu/ratgeber/backups-3-2-1/) magyarázza.

> **Tipp:**
> 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/shm` vagy 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](https://phpsos.de/hu/blog/zeitleiste-eines-vorfalls/) 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](https://phpsos.de/hu/leistungen/malware-entfernung/) 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.

## Források

- [BSI: a német szövetségi információbiztonsági hivatal](https://www.bsi.bund.de/)
- [Debian Security Tracker](https://security-tracker.debian.org/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)