Na kratko: Spremenjene datoteke v Linuxu najdete z find in časovnim oknom, na primer od 17. oktobra 2026, po poročilih medijev prvega opaženega poskusa napada na PHP2Shell. Preverjajte ne samo čas spremembe vsebine (mtime), temveč tudi čas metapodatkov (ctime), ker je prvega lahko ponarediti. Rezultat postane zanesljiv šele s primerjavo s kontrolnimi vsotami paketov, Gitom ali varnostno kopijo.
Zakaj so časovni žigi dober začetek, a ne dokaz
Kdor spravi kodo na strežnik, spreminja datoteke. Novi webshelli, prilagojene konfiguracijske datoteke, dodane vrstice v obstoječih skriptih: vse to pušča časovne žige. Iskanje sprememb v pravem časovnem oknu je zato ena najhitrejših poti do prvih najdb.
Za PHP2Shell se za začetek okna ponuja 17. oktober 2026, dan po poročilih medijev prvega opaženega poskusa napada. Popravki so izšli 21. oktobra. Kdor je strežnik posodobil šele po tem, išče do dne lastne posodobitve in čez. Kako med najdbami prepoznate webshelle, opisuje Prepoznavanje in odstranjevanje webshellov. Tukaj gre za metodo iskanja same.
Trije časovni žigi datoteke
Linux za vsako datoteko hrani več časov. Za iskanje sprememb sta odločilna dva.
| Časovni žig | Pomen | Ali ga je mogoče ponarediti? |
|---|---|---|
| mtime | zadnja sprememba vsebine | da, npr. s touch, vsak, ki sme datoteko pisati |
| ctime | zadnja sprememba vsebine ali metapodatkov, kot so pravice | ne z enostavnimi sredstvi |
| atime | zadnji dostop za branje | pogosto izklopljen ali netočen, za iskanje malo primeren |
Napadalci mtime radi nastavijo nazaj na datum sosednjih datotek, da nova datoteka ne izstopa. ctime se pri tem vendarle spremeni. Datoteka s starim mtime in svežim ctime je zato močan znak manipulacije.
Pri primerjavi pazite na časovne pasove. find in ls kažeta lokalni čas strežnika, številne datoteke dnevnikov in storitve pa delajo v UTC. Kdor najdbe iz datotečnega sistema in dnevnikov polaga eno ob drugo, naj vse podatke preračuna v isti časovni pas, sicer dogodki navidezno ne sovpadajo. Popravki so izšli približno 21. oktobra ob 14:00 UTC, torej ob 16. uri po nemškem času.
Iskanje spremenjenih datotek v Linuxu s find
Vsi ukazi samo berejo. Prilagodite pot in datum.
# Vsebina spremenjena od 17. 10. 2026, urejeno, z mtime, ctime in lastnikom
find /var/www -type f -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM %CY-%Cm-%Cd %CH:%CM %u %p\n' | sort
# Metapodatki spremenjeni od 17. 10. 2026 (najde tudi nazaj nastavljene datoteke)
find /var/www -type f -newerct "2026-10-17" -printf '%C+ %T+ %p\n' | sort
# Izločite znani šum: predpomnilnik, dnevniki, seje
find /var/www -type f -newerct "2026-10-17" \
-not -path "*/cache/*" -not -path "*/logs/*" -not -path "*/sessions/*" -printf '%C+ %p\n' | sort
# Poglejte tudi zunaj spletnega imenika
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 vsakem zadetku primerjajte oba časovna žiga. Če je ctime bistveno mlajši od mtime in v tem času nihče ni spreminjal pravic ali kopiral datotek, sodi datoteka na seznam. Bodite pozorni tudi na lastnika: datoteka uporabnika spletnega strežnika med datotekami uporabnika za uvajanje izstopa.
Ne pozabite skritih datotek in imenikov. Imena, ki se začnejo s piko, številni upravljalniki datotek in preprost ls ne prikažejo. Napadalci to radi izkoriščajo, enako kot imena, ki so pristnim datotekam zamenljivo podobna.
# Skrite datoteke in imeniki v spletnem imeniku, brez znanih, kot sta .htaccess in .git
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+ %u %p\n' | sort
Primerjava z zaupanja vrednim virom
Časovni žigi kažejo, kje se je nekaj premaknilo. Ali je šlo za legitimno spremembo, pokaže šele primerjava z virom, ki mu zaupate.
- Upravljanje paketov: Za sistemske datoteke
dpkg --verify(Debian/Ubuntu) alirpm -Va(družina RHEL) preverita datoteke s kontrolnimi vsotami nameščenih paketov. Konfiguracijske datoteke legitimno odstopajo, programske datoteke ne. - Git: Če aplikacija leži v repozitoriju,
git -C /var/www/projekt status --porcelainpokaže vsako odstopanje od zadnjega commita. - Kontrolne vsote CMS: Številni sistemi svoje jedrne datoteke lahko primerjajo z uradnimi kontrolnimi vsotami, glejte Primerjava jedrnih datotek CMS z izvirnikom.
- Varnostna kopija izpred incidenta: Primerjava v poskusnem teku našteje razlike, ne da bi karkoli kopirala.
# Samo naštejte razlike med stanjem varnostne kopije in živim sistemom (poskusni tek, ničesar ne kopira)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
Primerjava z varnostno kopijo predpostavlja, da je kopija nastala pred incidentom in sama ni bila spremenjena. Zakaj so tu odločilne ločeno hranjene kopije, pojasnjuje Varnostne kopije po pravilu 3-2-1.
Rezultate vsakega iskanja shranite z datumom v datoteko zunaj strežnika. Iz teh seznamov pozneje nastane časovnica incidenta in dokazujejo, kaj ste kdaj preverili.
Če ni niti varnostne kopije niti repozitorija
Pri mnogih manjših spletnih straneh čiste primerjalne osnove ni: ni Gita, ni kopije izpred incidenta, vtičniki leta ročno posodobljeni. Brez opore pa vseeno niste.
Prenesite CMS in razširitve pri proizvajalcu natanko v nameščenih različicah ter te datoteke primerjajte s strežnikom. Kar tam odstopa ali manjka, zasluži pogled. Ostanejo vaše lastne prilagoditve, nalaganja in konfiguracija; tam pomaga iskanje po časovnih žigih, dopolnjeno s pogledom na lastnika in pravice. Datoteke, ki so v imeniku edine z drugo skupino, drugimi pravicami ali bistveno mlajšim ctime od sosed, sodijo na seznam.
Pošteno rečeno: brez primerjalne osnove ostane preostala negotovost. Pri sistemih z občutljivimi podatki je potem nova postavitev iz čistih virov pogosto zanesljivejša od iskanja vsake posamezne spremenjene datoteke. Za prihodnost je lekcija preprosta: repozitorij za kodo in redne, ločeno hranjene varnostne kopije.
Tipični viri napak pri iskanju
- Preveč radodarna izločanja: Imeniki predpomnilnika in nalaganja so priljubljena skrivališča.
- Preverjen samo mtime: Nazaj nastavljene datoteke zdrsnejo mimo.
- Uvedba v časovnem oknu: Redna uvedba spremeni na stotine datotek in zakrije posamezne najdbe. Primerjajte z repozitorijem.
- Datoteke že odprte ali kopirane: Kopije brez ohranitve časovnih žigov uničijo sledi. Zavarujte z orodji, ki žige ohranijo.
- Preiskan samo spletni imenik: Napadalci orodja odložijo tudi v
/tmp,/dev/shmali v domači imenik uporabnika spletnega strežnika. - Spregledane spremembe pravic: Datoteka, katere pravice nenadoma dovoljujejo pisanje vsem, je najdba, tudi če je vsebina nespremenjena.
Kako najdbe sestavite v potek, kaže Izdelava časovnice incidenta.
Kako PHP SOS pomaga konkretno?
- Sistematično iskanje: Spletne imenike in sistemske poti preiščemo glede sprememb v ustreznem časovnem oknu in mtime ter ctime vrednotimo skupaj.
- Preverjanje z izvirniki: Primerjamo s paketi, repozitorijem, kontrolnimi vsotami CMS in vašimi varnostnimi kopijami.
- Ocena najdb: Redne spremembe ločimo od manipulacij in zavarujemo dokaze.
- Čiščenje: Z odstranjevanjem škodljive programske opreme vzpostavimo čisto stanje in ga dokumentiramo.
Pogosta vprašanja
Kako najdem vse datoteke, spremenjene od določenega datuma?
S find in možnostjo -newermt, na primer find /var/www -type f -newermt "2026-10-17". Za spremembe metapodatkov uporabite -newerct. Oba ukaza samo bereta in ničesar ne spremenita.
Kakšna je razlika med mtime in ctime?
mtime je čas zadnje spremembe vsebine in ga je mogoče z enostavnimi sredstvi nastaviti nazaj. ctime je čas zadnje spremembe vsebine ali metapodatkov in ga ni tako lahko ponarediti. Če se močno razlikujeta, se splača natančen pogled.
Kako iz iskanja izločim datoteke predpomnilnika?
Z -not -path za znane imenike predpomnilnika, dnevnikov in sej. Vendar ne izločajte preveč radodarno, saj napadalci datoteke radi odložijo ravno tja, kjer so številne spremembe običajne.
Katero preverjanje je najzanesljivejše?
Primerjava z zaupanja vrednim virom: kontrolne vsote upravljanja paketov, repozitorij Git ali varnostna kopija izpred incidenta. Časovni žigi so dober začetek, a ne dokaz.