Trumpai: pakeistus failus Linux sistemoje rasite su find ir laiko langu, pavyzdžiui, nuo 2026 m. spalio 17 d., pagal žiniasklaidos pranešimus pirmojo pastebėto atakos PHP2Shell bandymo dienos. Tikrinkite ne tik turinio pakeitimo laiką (mtime), bet ir metaduomenų (ctime), nes pirmąjį lengva suklastoti. Patikimas rezultatas atsiranda tik palyginus su paketų kontrolinėmis sumomis, Git ar atsargine kopija.
Kodėl laiko žymos yra geras pradžios taškas, bet ne įrodymas
Kas į serverį atneša kodą, keičia failus. Naujos webshell, pakoreguoti konfigūracijos failai, papildytos eilutės esamuose skriptuose: visa tai palieka laiko žymas. Todėl pakeitimų paieška tinkamame laiko lange yra vienas greičiausių kelių prie pirmųjų radinių.
PHP2Shell atveju lango pradžiai tinka 2026 m. spalio 17 d., pagal žiniasklaidos pranešimus pirmojo pastebėto atakos bandymo diena. Pataisos pasirodė spalio 21 d. Kas serverį atnaujino tik po to, ieško iki savo atnaujinimo dienos ir toliau. Kaip tarp radinių atpažinti webshell, aprašo Webshell atpažinimas ir šalinimas. Čia kalbama apie pačią paieškos metodą.
Trys failo laiko žymos
Linux apie kiekvieną failą saugo kelis laiko momentus. Ieškant pakeitimų lemiamos yra dvi.
| Laiko žyma | Reikšmė | Ar galima suklastoti? |
|---|---|---|
| mtime | paskutinis turinio pakeitimas | taip, pvz., su touch, kiekvienas, kuris gali rašyti į failą |
| ctime | paskutinis turinio ar metaduomenų, pavyzdžiui, teisių, pakeitimas | paprastomis priemonėmis ne |
| atime | paskutinė skaitymo prieiga | dažnai išjungta ar netiksli, paieškai mažai tinka |
Užpuolikai mtime mėgsta nustatyti kaimyninių failų data atgaline data, kad naujas failas nekristų į akis. Tačiau ctime tuo pat metu keičiasi. Failas su sena mtime ir šviežia ctime yra stiprus manipuliacijos požymis.
Lygindami atkreipkite dėmesį į laiko juostas. find ir ls rodo vietinį serverio laiką, o daug žurnalų ir tarnybų dirba UTC. Kas greta deda failų sistemos ir žurnalų radinius, visus duomenis turėtų perskaičiuoti į tą pačią laiko juostą, kitaip įvykiai atrodo nesutampantys. Pataisos pasirodė maždaug spalio 21 d. 14:00 UTC, t. y. 16 val. Vokietijos laiku.
Pakeistų failų radimas Linux sistemoje su find
Visos komandos tik skaito. Pritaikykite kelią ir datą.
# Turinys pakeistas nuo 2026-10-17, surikiuota, su mtime, ctime ir savininku
find /var/www -type f -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM %CY-%Cm-%Cd %CH:%CM %u %p\n' | sort
# Metaduomenys pakeisti nuo 2026-10-17 (randa ir atgaline data nustatytus failus)
find /var/www -type f -newerct "2026-10-17" -printf '%C+ %T+ %p\n' | sort
# Paslėpti žinomą triukšmą: talpyklą, žurnalus, sesijas
find /var/www -type f -newerct "2026-10-17" \
-not -path "*/cache/*" -not -path "*/logs/*" -not -path "*/sessions/*" -printf '%C+ %p\n' | sort
# Pažiūrėti ir už žiniatinklio katalogo ribų
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
Prie kiekvieno radinio palyginkite abi laiko žymas. Jei ctime gerokai naujesnė už mtime ir tuo metu niekas nekeitė teisių ar nekopijavo failų, failas patenka į sąrašą. Atkreipkite dėmesį ir į savininką: žiniatinklio serverio naudotojo failas tarp diegimo naudotojo failų krenta į akis.
Nepamirškite paslėptų failų ir katalogų. Pavadinimų, prasidedančių tašku, daugelis failų tvarkyklių ir paprastas ls nerodo. Užpuolikai tuo mėgsta naudotis, kaip ir pavadinimais, kurie painiojami su tikrais failais.
# Paslėpti failai ir aplankai žiniatinklio kataloge, be žinomų, tokių kaip .htaccess ir .git
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+ %u %p\n' | sort
Palyginti su patikimu šaltiniu
Laiko žymos parodo, kur kas nors pajudėjo. Ar tai buvo teisėtas pakeitimas, parodo tik palyginimas su šaltiniu, kuriuo pasitikite.
- Paketų valdymas: sistemos failus
dpkg --verify(Debian/Ubuntu) arrpm -Va(RHEL šeima) tikrina pagal įdiegtų paketų kontrolines sumas. Konfigūracijos failai teisėtai skiriasi, programų failai ne. - Git: jei programa yra saugykloje,
git -C /var/www/projekt status --porcelainparodo kiekvieną nukrypimą nuo paskutinio commit. - CMS kontrolinės sumos: daug sistemų gali savo pagrindinius failus palyginti su oficialiomis kontrolinėmis sumomis, žr. CMS pagrindinių failų palyginimas su originalu.
- Atsarginė kopija iš laiko prieš incidentą: palyginimas bandomuoju režimu išvardija skirtumus, nieko nekopijuodamas.
# Tik išvardyti skirtumus tarp atsarginės kopijos ir gyvos sistemos (bandomasis paleidimas, nieko nekopijuoja)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
Palyginimas su atsargine kopija reikalauja, kad kopija atsirado prieš incidentą ir pati nebuvo pakeista. Kodėl čia lemia atskirai laikomos kopijos, paaiškina Atsarginės kopijos pagal 3-2-1 taisyklę.
Kiekvienos paieškos rezultatus išsaugokite su data faile už serverio ribų. Iš šių sąrašų vėliau susidaro incidento laiko juosta ir jie įrodo, ką ir kada patikrinote.
Kai nėra nei atsarginės kopijos, nei saugyklos
Daugelyje mažesnių svetainių švarios palyginimo bazės nėra: nėra Git, nėra atsarginės kopijos iš laiko prieš incidentą, įskiepiai metų metus atnaujinami rankomis. Vis dėlto visiškai be atspirties taško nesate.
Atsisiųskite CMS ir plėtinius tiksliai įdiegtomis versijomis iš gamintojo ir palyginkite šiuos failus su serveriu. Kas ten skiriasi ar trūksta, vertas dėmesio. Lieka jūsų pačių pritaikymai, įkėlimai ir konfigūracija; ten padeda laiko žymų paieška, papildyta žvilgsniu į savininką ir teises. Failai, kurie vieninteliai kataloge turi kitą grupę, kitas teises ar gerokai naujesnę ctime nei kaimynai, patenka į sąrašą.
Sąžiningai kalbant: be palyginimo bazės lieka likutinis neapibrėžtumas. Sistemų su jautriais duomenimis atveju perkūrimas iš švarių šaltinių tuomet dažnai patikimesnis nei kiekvieno pakeisto failo paieška. Ateičiai pamoka paprasta: saugykla kodui ir reguliarios, atskirai laikomos atsarginės kopijos.
Tipinės paieškos klaidų priežastys
- Per dosnūs pašalinimai: talpyklos ir įkėlimų aplankai yra mėgstamos slėptuvės.
- Tikrinta tik mtime: atgaline data nustatyti failai praslysta.
- Diegimas laiko lange: įprastas diegimas pakeičia šimtus failų ir uždengia atskirus radinius. Palyginkite su saugykla.
- Failai jau atidaryti ar nukopijuoti: kopijos be laiko žymų išsaugojimo naikina pėdsakus. Išsaugokite įrankiais, kurie laiko žymas išlaiko.
- Ieškota tik žiniatinklio kataloge: užpuolikai įrankius deda ir
/tmp,/dev/shmar žiniatinklio serverio naudotojo namų kataloge. - Praleisti teisių pakeitimai: failas, kurio teisės staiga leidžia rašyti visiems, yra radinys, net jei jo turinys nepasikeitė.
Kaip radiniai sudedami į eigą, parodo Incidento laiko juostos sudarymas.
Kaip PHP SOS padeda konkrečiai?
- Ieškoti sistemingai: peržiūrime žiniatinklio katalogus ir sistemos kelius dėl pakeitimų aktualiame laiko lange ir mtime bei ctime vertiname kartu.
- Tikrinti pagal originalus: lyginame su paketais, saugykla, CMS kontrolinėmis sumomis ir jūsų atsarginėmis kopijomis.
- Įvertinti radinius: atskiriame įprastus pakeitimus nuo manipuliacijų ir išsaugome įrodymus.
- Išvalyti: su kenkėjiškos programinės įrangos šalinimu atkuriame švarią būseną ir ją dokumentuojame.
Dažni klausimai
Kaip rasti visus failus, pakeistus nuo tam tikros datos?
Su find ir parinktimi -newermt, pavyzdžiui, find /var/www -type f -newermt "2026-10-17". Metaduomenų pakeitimams naudokite -newerct. Abi komandos tik skaito ir nieko nekeičia.
Kuo skiriasi mtime ir ctime?
mtime yra paskutinio turinio pakeitimo laikas ir paprastomis priemonėmis gali būti nustatytas atgaline data. ctime yra paskutinio turinio ar metaduomenų pakeitimo laikas ir taip lengvai suklastoti jo negalima. Jei abu stipriai skiriasi, verta pažvelgti atidžiau.
Kaip iš paieškos pašalinti talpyklos failus?
Su -not -path žinomiems talpyklos, žurnalų ir sesijų aplankams. Tačiau nepašalinkite per daug, nes užpuolikai failus mėgsta dėti būtent ten, kur daug pakeitimų yra normalu.
Kuri patikra patikimiausia?
Palyginimas su patikimu šaltiniu: paketų valdymo kontrolinėmis sumomis, Git saugykla ar atsargine kopija iš laiko prieš incidentą. Laiko žymos yra geras pradžios taškas, bet ne įrodymas.