Lyhyesti: Muuttuneet tiedostot löydätte Linuxissa find-komennolla ja aikaikkunalla, esimerkiksi 17. lokakuuta 2026 alkaen, mediatietojen mukaan ensimmäisestä havaitusta PHP2Shell-hyökkäysyrityksestä. Tarkistakaa tällöin paitsi sisällön muutosaika (mtime) myös metatietojen (ctime), koska edellinen on helppo väärentää. Tulos muuttuu luotettavaksi vasta vertailulla paketin tarkistussummiin, Gitiin tai varmuuskopioon.
Miksi aikaleimat ovat hyvä aloitus mutta eivät todiste
Joka tuo koodia palvelimelle, muuttaa tiedostoja. Uudet web shellit, muokatut asetustiedostot, olemassa oleviin skripteihin lisätyt rivit: kaikki jättää aikaleimoja. Muutosten etsintä oikeasta aikaikkunasta on siksi yksi nopeimmista teistä ensimmäisiin löytöihin.
PHP2Shellin kohdalla ikkunan alkuna sopii 17. lokakuuta 2026, mediatietojen mukaan ensimmäisen havaitun hyökkäysyrityksen päivä. Korjaukset julkaistiin 21. lokakuuta. Jos olette päivittäneet palvelimen vasta sen jälkeen, etsikää oman päivityksenne päivään ja sen yli. Miten web shellit tunnistetaan löytöjen joukosta, kuvaa Web shellin tunnistaminen ja poisto. Tässä käsitellään itse haun menetelmää.
Tiedoston kolme aikaleimaa
Linux tallentaa jokaisesta tiedostosta useita ajankohtia. Muutosten etsinnässä kaksi on ratkaisevaa.
| Aikaleima | Merkitys | Väärennettävissä? |
|---|---|---|
| mtime | sisällön viimeinen muutos | kyllä, esim. touch-komennolla, jokaisen toimesta, joka saa kirjoittaa tiedostoon |
| ctime | sisällön tai metatietojen, kuten oikeuksien, viimeinen muutos | ei yksinkertaisin keinoin |
| atime | viimeinen lukukäyttö | usein poistettu käytöstä tai epätarkka, hakuun huonosti sopiva |
Hyökkääjät päiväävät mtimen mielellään takaperin naapuritiedostojen päivämäärään, jotta uusi tiedosto ei herätä huomiota. ctime kuitenkin muuttuu samalla. Tiedosto, jolla on vanha mtime ja tuore ctime, on siksi vahva merkki manipuloinnista.
Huomatkaa aikavyöhykkeet vertailussa. find ja ls näyttävät palvelimen paikallisen ajan, mutta monet lokitiedostot ja palvelut toimivat UTC-ajassa. Joka asettaa tiedostojärjestelmän ja lokien löydöt rinnakkain, kannattaa muuntaa kaikki tiedot samaan aikavyöhykkeeseen, muuten tapahtumat eivät näennäisesti sovi yhteen. Korjaukset julkaistiin noin 21. lokakuuta klo 14.00 UTC, eli klo 16.00 Saksan aikaa.
Muuttuneiden tiedostojen etsintä Linuxissa find-komennolla
Kaikki komennot vain lukevat. Mukauttakaa polku ja päivämäärä.
# Sisältö muutettu 17.10.2026 jälkeen, lajiteltuna, mtime, ctime ja omistaja mukana
find /var/www -type f -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM %CY-%Cm-%Cd %CH:%CM %u %p\n' | sort
# Metatiedot muutettu 17.10.2026 jälkeen (löytää myös takaperin päivätyt tiedostot)
find /var/www -type f -newerct "2026-10-17" -printf '%C+ %T+ %p\n' | sort
# Piilota tunnettu kohina: välimuisti, lokit, istunnot
find /var/www -type f -newerct "2026-10-17" \
-not -path "*/cache/*" -not -path "*/logs/*" -not -path "*/sessions/*" -printf '%C+ %p\n' | sort
# Katsokaa myös verkkohakemiston ulkopuolelta
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
Verratkaa jokaisessa osumassa molempia aikaleimoja. Jos ctime on selvästi nuorempi kuin mtime eikä kukaan ole tänä aikana muuttanut oikeuksia tai kopioinut tiedostoja, tiedosto kuuluu listalle. Kiinnittäkää huomiota myös omistajaan: verkkopalvelinkäyttäjän tiedosto käyttöönottokäyttäjän tiedostojen joukossa pistää silmään.
Älkää unohtako piilotettuja tiedostoja ja hakemistoja. Pisteellä alkavia nimiä monet tiedostonhallinnat ja yksinkertainen ls eivät näytä. Hyökkääjät käyttävät sitä mielellään, samoin kuin nimiä, jotka muistuttavat aitoja tiedostoja hämäävästi.
# Piilotetut tiedostot ja kansiot verkkohakemistossa, ilman tunnettuja kuten .htaccess ja .git
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+ %u %p\n' | sort
Vertailu luotettavaan lähteeseen
Aikaleimat näyttävät, missä jotain on liikkunut. Se, oliko muutos oikeutettu, selviää vasta vertailulla lähteeseen, johon luotatte.
- Paketinhallinta: Järjestelmätiedostoille
dpkg --verify(Debian/Ubuntu) tairpm -Va(RHEL-perhe) tarkistavat tiedostot asennettujen pakettien tarkistussummia vasten. Asetustiedostot poikkeavat oikeutetusti, ohjelmatiedostot eivät. - Git: Jos sovellus on repositoriossa,
git -C /var/www/projekt status --porcelainnäyttää jokaisen poikkeaman viimeisestä commitista. - CMS-tarkistussummat: Monet järjestelmät voivat verrata ydintiedostonsa virallisiin tarkistussummiin, ks. CMS-ydintiedostojen vertailu alkuperäiseen.
- Varmuuskopio ajalta ennen tapausta: Koeajona tehty vertailu luettelee erot kopioimatta mitään.
# Luettele varmuuskopion ja live-järjestelmän erot vain (koeajo, ei kopioi mitään)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
Varmuuskopiovertailu edellyttää, että varmuuskopio syntyi ennen tapausta eikä sitä ole itse muutettu. Miksi erillään säilytetyt varmuuskopiot ovat tässä ratkaisevia, selittää Varmuuskopiot 3-2-1-säännön mukaan.
Tallentakaa jokaisen haun tulokset päivämäärän kanssa tiedostoon palvelimen ulkopuolelle. Näistä luetteloista syntyy myöhemmin tapauksen aikajana, ja ne todistavat, mitä olette milloinkin tarkistaneet.
Jos varmuuskopiota tai repositoriota ei ole
Monilla pienemmillä verkkosivustoilla ei ole puhdasta vertailupohjaa: ei Gitiä, ei varmuuskopiota ajalta ennen tapausta, liitännäiset päivitetty vuosia käsin. Täysin ilman tukipistettä ette silti ole.
Ladatkaa CMS ja laajennukset valmistajalta täsmälleen asennetuissa versioissa ja verratkaa näitä tiedostoja palvelimeen. Mikä siellä poikkeaa tai puuttuu, ansaitsee katsauksen. Jäljelle jäävät omat muokkauksenne, uploadit ja konfiguraatio; siinä aikaleimahaku auttaa, täydennettynä katseella omistajaan ja oikeuksiin. Tiedostot, joilla on hakemistossa ainoina eri ryhmä, eri oikeudet tai selvästi nuorempi ctime kuin naapureillaan, kuuluvat listalle.
Rehellisesti sanottuna: ilman vertailupohjaa jää jäännösepävarmuus. Järjestelmissä, joissa on arkaluonteisia tietoja, uudelleenrakennus puhtaista lähteistä on silloin usein luotettavampaa kuin jokaisen muuttuneen tiedoston etsintä. Tulevaisuuden oppi on yksinkertainen: repositorio koodille ja säännölliset, erillään säilytettävät varmuuskopiot.
Tyypillisiä virhelähteitä haussa
- Liian laajat poissulkemiset: Välimuisti- ja upload-kansiot ovat suosittuja piilopaikkoja.
- Tarkistettu vain mtime: Takaperin päivätyt tiedostot livahtavat läpi.
- Käyttöönotto aikaikkunassa: Tavallinen julkaisu muuttaa satoja tiedostoja ja peittää yksittäiset löydöt. Verratkaa repositorioon.
- Tiedostot jo avattu tai kopioitu: Kopiot ilman aikaleimojen säilytystä tuhoavat jälkiä. Varmistakaa työkaluilla, jotka säilyttävät aikaleimat.
- Etsitty vain verkkohakemistosta: Hyökkääjät sijoittavat työkaluja myös polkuihin
/tmp,/dev/shmtai verkkopalvelinkäyttäjän kotihakemistoon. - Oikeusmuutokset huomaamatta: Tiedosto, jonka oikeudet sallivat yhtäkkiä kaikille kirjoituksen, on löytö, vaikka sen sisältö olisi muuttumaton.
Miten löydöistä koostetaan kulku, näyttää Tapauksen aikajanan laatiminen.
Miten PHP SOS auttaa konkreettisesti?
- Systemaattinen haku: Käymme läpi verkkohakemistot ja järjestelmäpolut muutosten varalta olennaisessa aikaikkunassa ja arvioimme mtimen ja ctimen yhdessä.
- Vertailu alkuperäisiin: Vertaamme paketteihin, repositorioon, CMS-tarkistussummiin ja varmuuskopioihinne.
- Löydösten arviointi: Erotamme tavalliset muutokset manipuloinnista ja varmistamme todisteet.
- Siivous: Haittaohjelmien poistolla palautamme puhtaan tilan ja dokumentoimme sen.
Usein kysytyt kysymykset
Miten löydän kaikki tiedostot, jotka on muutettu tietyn päivämäärän jälkeen?
Komennolla find ja valinnalla -newermt, esimerkiksi find /var/www -type f -newermt "2026-10-17". Metatietojen muutoksiin käytätte valintaa -newerct. Molemmat komennot vain lukevat eivätkä muuta mitään.
Mitä eroa on mtimella ja ctimella?
mtime on sisällön viimeisen muutoksen ajankohta, ja se voidaan yksinkertaisin keinoin takaperin päivätä. ctime on sisällön tai metatietojen viimeisen muutoksen ajankohta, eikä sitä voi väärentää yhtä helposti. Jos ne poikkeavat toisistaan voimakkaasti, kannattaa katsoa tarkemmin.
Miten suljen välimuistitiedostot pois hausta?
Valinnalla -not -path tunnetuille välimuisti-, loki- ja istuntokansioille. Älkää kuitenkaan sulkeko pois liian laajasti, sillä hyökkääjät sijoittavat tiedostoja mielellään juuri sinne, missä monet muutokset ovat normaaleja.
Mikä tarkistus on luotettavin?
Vertailu luotettavaan lähteeseen: paketinhallinnan tarkistussummat, Git-repositorio tai varmuuskopio ajalta ennen tapausta. Aikaleimat ovat hyvä aloitus mutta eivät todiste.