Stručne: Zmenené súbory nájdete v Linuxe pomocou find a časového okna, napríklad od 17. októbra 2026, teda podľa správ médií od prvého pozorovaného pokusu o útok na PHP2Shell. Kontrolujte pritom nielen čas zmeny obsahu (mtime), ale aj čas zmeny metadát (ctime), pretože prvý sa dá ľahko sfalšovať. Spoľahlivým sa výsledok stane až porovnaním s kontrolnými súčtami balíkov, Gitom alebo zálohou.
Prečo sú časové pečiatky dobrým začiatkom, ale nie dôkazom
Kto dostane kód na server, mení súbory. Nové webshelly, upravené konfiguračné súbory, doplnené riadky v existujúcich skriptoch: to všetko zanecháva časové pečiatky. Hľadanie zmien v správnom časovom okne je preto jednou z najrýchlejších ciest k prvým nálezom.
Pre PHP2Shell sa ako začiatok okna ponúka 17. október 2026, deň podľa správ médií prvého pozorovaného pokusu o útok. Záplaty vyšli 21. októbra. Kto svoj server aktualizoval až potom, hľadá do dňa vlastnej aktualizácie a aj za ním. Ako medzi nálezmi rozpoznať webshelly, opisuje Rozpoznanie a odstránenie webshellu. Tu ide o samotnú metódu hľadania.
Tri časové pečiatky súboru
Linux ukladá ku každému súboru viacero časových bodov. Pri hľadaní zmien sú rozhodujúce dva.
| Časová pečiatka | Význam | Dá sa sfalšovať? |
|---|---|---|
| mtime | posledná zmena obsahu | áno, napr. pomocou touch, kýmkoľvek, kto smie súbor zapisovať |
| ctime | posledná zmena obsahu alebo metadát, ako sú práva | nie jednoduchými prostriedkami |
| atime | posledný prístup na čítanie | často vypnutý alebo nepresný, na hľadanie sa hodí málo |
Útočníci radi predatujú mtime na dátum susedných súborov, aby nový súbor nebudil pozornosť. ctime sa pritom ale mení spolu s tým. Súbor so starým mtime a čerstvým ctime je preto silným náznakom manipulácie.
Pri porovnávaní dávajte pozor na časové pásma. find a ls ukazujú lokálny čas servera, mnohé logy a služby však pracujú v UTC. Kto kladie nálezy zo súborového systému a z logov vedľa seba, mal by všetky údaje prepočítať na rovnaké časové pásmo, inak udalosti zdanlivo nesedia. Záplaty vyšli približne 21. októbra o 14:00 UTC, teda o 16:00 nemeckého času.
Hľadanie zmenených súborov v Linuxe pomocou find
Všetky príkazy len čítajú. Prispôsobte cestu a dátum.
# Obsah zmenený od 17. 10. 2026, zoradené, s mtime, ctime a vlastníkom
find /var/www -type f -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM %CY-%Cm-%Cd %CH:%CM %u %p\n' | sort
# Metadáta zmenené od 17. 10. 2026 (nájde aj predatované súbory)
find /var/www -type f -newerct "2026-10-17" -printf '%C+ %T+ %p\n' | sort
# Skryť známy šum: cache, logy, relácie
find /var/www -type f -newerct "2026-10-17" \
-not -path "*/cache/*" -not -path "*/logs/*" -not -path "*/sessions/*" -printf '%C+ %p\n' | sort
# Pozrieť sa aj mimo webového adresára
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
Pri každom zásahu porovnajte obe časové pečiatky. Ak je ctime výrazne mladší než mtime a v tom čase nikto nemenil práva ani nekopíroval súbory, súbor patrí na zoznam. Všímajte si aj vlastníka: súbor používateľa webového servera medzi súbormi používateľa nasadenia je nápadný.
Nezabudnite na skryté súbory a adresáre. Názvy začínajúce bodkou mnohé správcovia súborov a jednoduchý ls nezobrazujú. Útočníci to radi využívajú, rovnako ako názvy, ktoré sú na zámenu podobné skutočným súborom.
# Skryté súbory a priečinky vo webovom adresári, bez známych ako .htaccess a .git
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+ %u %p\n' | sort
Porovnať s dôveryhodným zdrojom
Časové pečiatky ukazujú, kde sa niečo pohlo. Či išlo o legitímnu zmenu, ukáže až porovnanie so zdrojom, ktorému dôverujete.
- Správa balíkov: Pre systémové súbory kontrolujú
dpkg --verify(Debian/Ubuntu) aleborpm -Va(rodina RHEL) súbory voči kontrolným súčtom nainštalovaných balíkov. Konfiguračné súbory sa legitímne líšia, súbory programov nie. - Git: Ak je aplikácia v repozitári,
git -C /var/www/projekt status --porcelainukáže každú odchýlku od posledného commitu. - Kontrolné súčty CMS: Mnohé systémy dokážu porovnať svoje jadrové súbory s oficiálnymi kontrolnými súčtami, pozri Porovnanie jadrových súborov CMS s originálom.
- Záloha spred incidentu: Porovnanie v skúšobnom behu vypíše rozdiely bez kopírovania.
# Rozdiely medzi stavom zálohy a živým systémom len vypísať (skúšobný beh, nič nekopíruje)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
Porovnanie so zálohou predpokladá, že záloha vznikla pred incidentom a sama nebola zmenená. Prečo sú tu rozhodujúce oddelene uchovávané zálohy, vysvetľuje Zálohy podľa pravidla 3-2-1.
Výsledky každého hľadania ukladajte s dátumom do súboru mimo servera. Z týchto zoznamov neskôr vznikne časová os incidentu a dokazujú, čo ste kedy skontrolovali.
Ak neexistuje záloha ani repozitár
Pri mnohých menších weboch neexistuje čistý základ na porovnanie: žiadny Git, žiadna záloha spred incidentu, pluginy roky aktualizované ručne. Úplne bez opory však nie ste.
Stiahnite CMS a rozšírenia presne v nainštalovaných verziách od výrobcu a porovnajte tieto súbory so serverom. Čo sa tam odlišuje alebo chýba, si zaslúži pohľad. Ostanú vaše vlastné úpravy, nahrávania a konfigurácia; tam pomáha hľadanie podľa časových pečiatok, doplnené pohľadom na vlastníka a práva. Súbory, ktoré majú ako jediné v adresári inú skupinu, iné práva alebo výrazne mladší ctime než ich susedia, patria na zoznam.
Úprimne povedané: bez základu na porovnanie ostáva zvyšná neistota. Pri systémoch s citlivými údajmi je potom nové nasadenie z čistých zdrojov často spoľahlivejšie než hľadanie každého jedného zmeneného súboru. Pre budúcnosť je ponaučenie jednoduché: repozitár pre kód a pravidelné, oddelene uchovávané zálohy.
Typické zdroje chýb pri hľadaní
- Príliš veľkorysé vylúčenia: Priečinky cache a nahrávania sú obľúbené úkryty.
- Kontrolované len mtime: Predatované súbory prekĺznu.
- Nasadenie v časovom okne: Bežné nasadenie zmení stovky súborov a zakryje jednotlivé nálezy. Porovnajte s repozitárom.
- Súbory už otvorené alebo skopírované: Kópie bez zachovania časových pečiatok ničia stopy. Zálohujte nástrojmi, ktoré časové pečiatky zachovávajú.
- Prehľadaný len webový adresár: Útočníci ukladajú nástroje aj do
/tmp,/dev/shmalebo do domovského adresára používateľa webového servera. - Prehliadnuté zmeny práv: Súbor, ktorého práva zrazu povoľujú zápis pre všetkých, je nález, aj keď sa jeho obsah nezmenil.
Ako sa z nálezov poskladá priebeh, ukazuje Vytvorenie časovej osi incidentu.
Ako konkrétne pomáha PHP SOS?
- Hľadať systematicky: Prehľadáme webové adresáre a systémové cesty na zmeny v relevantnom časovom okne a vyhodnotíme mtime a ctime spolu.
- Kontrolovať voči originálom: Porovnávame s balíkmi, repozitárom, kontrolnými súčtami CMS a vašimi zálohami.
- Zhodnotiť nálezy: Oddelíme bežné zmeny od manipulácií a zabezpečíme dôkazy.
- Vyčistiť: Prostredníctvom odstránenia malvéru obnovíme čistý stav a zdokumentujeme ho.
Časté otázky
Ako nájdem všetky súbory zmenené od určitého dátumu?
Pomocou find a voľby -newermt, napríklad find /var/www -type f -newermt "2026-10-17". Pre zmeny metadát použite -newerct. Oba príkazy len čítajú a nič nemenia.
Aký je rozdiel medzi mtime a ctime?
mtime je čas poslednej zmeny obsahu a dá sa jednoduchými prostriedkami predatovať. ctime je čas poslednej zmeny obsahu alebo metadát a dá sa sfalšovať ťažšie. Ak sa oba výrazne líšia, oplatí sa dôkladný pohľad.
Ako vylúčim zo hľadania súbory cache?
Pomocou -not -path pre známe priečinky cache, logov a relácií. Nevylučujte však príliš veľkoryso, pretože útočníci ukladajú súbory radi práve tam, kde sú mnohé zmeny normálne.
Ktorá kontrola je najspoľahlivejšia?
Porovnanie s dôveryhodným zdrojom: kontrolné súčty zo správy balíkov, repozitár Git alebo záloha spred incidentu. Časové pečiatky sú dobrým začiatkom, ale nie dôkazom.