Stručně: Změněné soubory v Linuxu najdete pomocí find a časového okna, například od 17. října 2026, podle médií prvního pozorovaného pokusu o útok na PHP2Shell. Kontrolujte přitom nejen čas změny obsahu (mtime), ale i čas změny metadat (ctime), protože první lze snadno zfalšovat. Spolehlivým se výsledek stane až porovnáním s kontrolními součty balíčků, Gitem nebo zálohou.
Proč jsou časová razítka dobrým začátkem, ale ne důkazem
Kdo dostane kód na server, mění soubory. Nové webshelly, upravené konfigurační soubory, doplněné řádky ve stávajících skriptech: to vše zanechává časová razítka. Hledání změn ve správném časovém okně je proto jednou z nejrychlejších cest k prvním nálezům.
Pro PHP2Shell se jako začátek okna nabízí 17. říjen 2026, den prvního pozorovaného pokusu o útok podle zpráv médií. Záplaty vyšly 21. října. Kdo server aktualizoval až poté, hledá do dne vlastní aktualizace a dál. Jak mezi nálezy poznat webshelly, popisuje článek Rozpoznání a odstranění webshellu. Zde jde o samotnou metodu hledání.
Tři časová razítka souboru
Linux ukládá ke každému souboru několik časových okamžiků. Pro hledání změn jsou rozhodující dva.
| Časové razítko | Význam | Lze zfalšovat? |
|---|---|---|
| mtime | poslední změna obsahu | ano, např. pomocí touch, kýmkoli, kdo smí do souboru zapisovat |
| ctime | poslední změna obsahu nebo metadat jako oprávnění | ne jednoduchými prostředky |
| atime | poslední čtecí přístup | často vypnuto nebo nepřesné, pro hledání málo vhodné |
Útočníci rádi nastavují mtime zpětně na datum sousedních souborů, aby nový soubor nevyčníval. ctime se při tom ale změní také. Soubor se starým mtime a čerstvým ctime je proto silným náznakem manipulace.
Při porovnávání dejte pozor na časová pásma. find a ls ukazují místní čas serveru, mnoho logů a služeb však pracuje v UTC. Kdo klade vedle sebe nálezy ze souborového systému a z logů, měl by všechny údaje převést do téhož pásma, jinak k sobě události zdánlivě nesedí. Záplaty vyšly přibližně 21. října ve 14:00 UTC, tedy v 16:00 německého času.
Změněné soubory v Linuxu najít pomocí find
Všechny příkazy jen čtou. Cestu a datum upravte.
# Obsah změněn od 17. 10. 2026, seřazeno, s mtime, ctime a vlastníkem
find /var/www -type f -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM %CY-%Cm-%Cd %CH:%CM %u %p\n' | sort
# Metadata změněna od 17. 10. 2026 (najde i soubory nastavené zpětně)
find /var/www -type f -newerct "2026-10-17" -printf '%C+ %T+ %p\n' | sort
# Vyřadit známý šum: cache, logy, relace
find /var/www -type f -newerct "2026-10-17" \
-not -path "*/cache/*" -not -path "*/logs/*" -not -path "*/sessions/*" -printf '%C+ %p\n' | sort
# Podívat se i mimo webový adresář
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
U každého nálezu porovnejte obě časová razítka. Je-li ctime výrazně mladší než mtime a nikdo v té době neměnil oprávnění ani nekopíroval soubory, patří soubor na seznam. Všímejte si také vlastníka: soubor uživatele webového serveru mezi soubory uživatele nasazení nápadně vyčnívá.
Nezapomeňte na skryté soubory a adresáře. Názvy začínající tečkou mnoho správců souborů a jednoduché ls nezobrazí. Útočníci to rádi využívají, stejně jako názvy, které se snadno zaměňují se skutečnými soubory.
# Skryté soubory a složky ve webovém adresáři, bez známých jako .htaccess a .git
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+ %u %p\n' | sort
Porovnat s důvěryhodným zdrojem
Časová razítka ukazují, kde se něco pohnulo. Zda šlo o legitimní změnu, ukáže teprve porovnání se zdrojem, kterému důvěřujete.
- Správa balíčků: Systémové soubory kontrolují
dpkg --verify(Debian/Ubuntu) neborpm -Va(rodina RHEL) proti kontrolním součtům nainstalovaných balíčků. Konfigurační soubory se legitimně liší, programové soubory ne. - Git: Je-li aplikace v repozitáři,
git -C /var/www/projekt status --porcelainukáže každou odchylku od posledního commitu. - Kontrolní součty CMS: Mnoho systémů umí porovnat svá jádra souborů s oficiálními kontrolními součty, viz Porovnání jádra souborů CMS s originálem.
- Záloha z doby před incidentem: Porovnání nanečisto vypíše rozdíly, aniž by cokoli kopírovalo.
# Jen vypsat rozdíly mezi stavem zálohy a živým systémem (nanečisto, nic nekopíruje)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
Porovnání se zálohou předpokládá, že záloha vznikla před incidentem a sama nebyla změněna. Proč jsou zde rozhodující odděleně uchovávané zálohy, vysvětluje Zálohy podle pravidla 3-2-1.
Výsledky každého hledání ukládejte s datem do souboru mimo server. Z těchto seznamů později vznikne časová osa incidentu a dokládají, co jste kdy zkontrolovali.
Když není záloha ani repozitář
U mnoha menších webů neexistuje čistý základ pro porovnání: žádný Git, žádná záloha z doby před incidentem, pluginy roky aktualizované ručně. Zcela bez opory však přesto nejste.
Stáhněte si od výrobce CMS a rozšíření přesně v nainstalovaných verzích a porovnejte tyto soubory se serverem. Co se tam liší nebo chybí, zaslouží pohled. Zbydou vaše vlastní úpravy, uploady a konfigurace; tam pomáhá hledání podle časových razítek, doplněné pohledem na vlastníky a oprávnění. Soubory, které jsou jako jediné v adresáři s jinou skupinou, jinými oprávněními nebo výrazně mladším ctime než jejich sousedé, patří na seznam.
Upřímně řečeno: Bez základu pro porovnání zůstává zbytková nejistota. U systémů s citlivými daty je pak nová výstavba z čistých zdrojů často spolehlivější než hledání každého jednotlivého změněného souboru. Pro budoucnost je poučení jednoduché: repozitář pro kód a pravidelné, odděleně uchovávané zálohy.
Typické zdroje chyb při hledání
- Příliš velkorysá vyloučení: Složky cache a uploadu jsou oblíbenými skrýšemi.
- Zkontrolováno jen mtime: Zpětně nastavené soubory proklouznou.
- Nasazení v časovém okně: Řádné nasazení změní stovky souborů a zakryje jednotlivé nálezy. Porovnejte s repozitářem.
- Soubory už otevřené nebo zkopírované: Kopie bez zachování časových razítek ničí stopy. Zálohujte nástroji, které časová razítka zachovávají.
- Prohledán jen webový adresář: Útočníci ukládají nástroje i do
/tmp,/dev/shmnebo do domovského adresáře uživatele webového serveru. - Přehlédnuté změny oprávnění: Soubor, jehož oprávnění náhle dovolují zápis všem, je nález, i když se jeho obsah nezměnil.
Jak se nálezy skládají do průběhu, ukazuje Sestavení časové osy incidentu.
Jak konkrétně pomáhá PHP SOS?
- Hledat systematicky: Prohledáváme webové adresáře a systémové cesty na změny v relevantním časovém okně a hodnotíme mtime a ctime společně.
- Kontrolovat proti originálům: Porovnáváme s balíčky, repozitářem, kontrolními součty CMS a vašimi zálohami.
- Posoudit nálezy: Oddělujeme řádné změny od manipulací a zajišťujeme důkazy.
- Vyčistit: S odstraněním malwaru obnovíme čistý stav a zdokumentujeme jej.
Časté dotazy
Jak najdu všechny soubory změněné od určitého data?
Pomocí find a volby -newermt, například find /var/www -type f -newermt "2026-10-17". Pro změny metadat použijte -newerct. Oba příkazy jen čtou a nic nemění.
Jaký je rozdíl mezi mtime a ctime?
mtime je okamžik poslední změny obsahu a lze jej jednoduchými prostředky zpětně přenastavit. ctime je okamžik poslední změny obsahu nebo metadat a nelze jej tak snadno zfalšovat. Liší-li se obě silně, vyplatí se bližší pohled.
Jak vyloučit soubory cache z hledání?
Pomocí -not -path pro známé složky cache, logů a relací. Nevylučujte ale příliš velkoryse, protože útočníci soubory rádi ukládají právě tam, kde jsou časté změny normální.
Která kontrola je nejspolehlivější?
Porovnání s důvěryhodným zdrojem: kontrolními součty správy balíčků, repozitářem Git nebo zálohou z doby před incidentem. Časová razítka jsou dobrý začátek, ale ne důkaz.