Lyhyesti: Jos verkkosivustonne on murrettu, tämä tarkistuslista auttaa pitämään kaiken mielessä: ensin rajaus ja todisteiden varmistus, sitten syyn etsintä ja puhdistus, sen jälkeen kaikkien pääsyjen uusiminen, velvoitteiden tarkistus ja poikkeaman dokumentoitu päättäminen. Järjestys on tärkeä, sillä joka poistaa ensin, menettää jäljet, ja joka vain puhdistaa sulkematta aukkoa, joutuu uuden hyökkäyksen kohteeksi.
Mihin tätä tarkistuslistaa käytetään, kun verkkosivusto on murrettu
Tarkistuslista on tarkoitettu johdolle, omistajille ja IT-vastaaville verkkosivustoon, verkkokauppaan tai PHP-verkkopalvelimeen kohdistuneen vahvistetun tai todennäköisen hyökkäyksen jälkeen. Se sopii myös PHP2Shellin jälkeen, kun palvelin oli ennen päivitystä tavoitettavissa ja on viitteitä vaarantumisesta.
Kaikki kohdat eivät sovi jokaiseen ympäristöön. Käykää lista silti kokonaan läpi ja kirjatkaa jokaisen kohdan kohdalle, onko se tehty, ei sovellu vai avoin. Tämä pöytäkirja on myöhemmin arvokas vakuutukselle, tietosuojalle ja sisäiselle jälkikäsittelylle.
Merkitkää jokaiseen vaiheeseen päivämäärä, kellonaika, vastuuhenkilö ja tulos. Jos mukana on useita henkilöitä, määrätkää yksi, joka pitää listaa ja kirjaa päätökset.
Vaihe 1: Rajaa ja varmista heti
- Rajatkaa vahinko: Siirtäkää verkkosivusto huoltotilaan tai pois verkosta, jos kävijät ovat vaarassa tai tietoja voi vuotaa. BSI (Saksan liittovaltion tietoturvavirasto) suosittelee PHP2Shellin yhteydessä irrottamaan korjaamattomat verkkopalvelimet väliaikaisesti verkosta, jos päivitys ei onnistu heti.
- Älkää poistako mitään: Älkää poistako tiedostoja, asentako palvelinta uudelleen tai tyhjentäkö lokeja, ennen kuin jäljet on varmistettu.
- Varmistakaa lokit: Kopioikaa pääsy-, virhe-, PHP-FPM- ja järjestelmälokit toiseen järjestelmään ja kirjatkaa tarkistussummat. PHP2Shellistä ammattilehdistö neuvoo säilyttämään lokit 20.10.2026 alkaen.
- Varmistakaa levykuva: Luokaa kopio tiedostoista ja tietokannasta, virtuaalipalvelimilla tilannevedos, todistetilaksi, äläkä muuttako sitä.
- Ilmoittakaa vastuuhenkilöille: Ottakaa johto, tietosuojavastaava, hosting-yritys ja mahdollinen kybervakuutus mukaan ajoissa. Monilla vakuutuksilla on ilmoitusvelvoitteita.
Vaihe 2: Etsikää syy ja puhdistakaa
- Selvittäkää sisääntuloreitti: Analysoikaa lokit, tiedostomuutokset ja versiot. Tarkistakaa PHP itse, CMS, teemat, laajennukset, tunnukset ja palvelinpalvelut. Ilman tunnettua syytä uuden hyökkäyksen riski säilyy.
- Sulkekaa aukko: Viekää PHP korjattuun versioon (8.5.12, 8.4.27, 8.3.36 tai 8.2.35 tai palveluntarjoajan vahvistama backport), päivittäkää CMS ja laajennukset ja käynnistäkää kaikki PHP-worker-prosessit uudelleen.
- Rajatkaa ajanjakso: Määrittäkää epäilyttävän toiminnan varhaisin ajankohta. Se ratkaisee, mitkä varmuuskopiot voivat olla puhtaita ja mitkä tiedot voivat olla kosketettuja.
- Poistakaa takaovet: Tarkistakaa ja poistakaa web shellit, vieraat PHP-tiedostot upload- ja välimuistikansioissa, muutetut ydintiedostot, cron-tehtävät, SSH-avaimet ja järjestelmäpalvelut. Korvatkaa ydintiedostot puhtaasta lähteestä.
- Puhdistakaa tietokanta: Poistakaa tuntemattomat ylläpitäjätilit, sisältöihin ja asetuksiin lisätyt skriptit sekä roskapostisisällöt.
- Harkitkaa uudelleenrakennusta: Jos palvelin on vaarantunut perusteellisesti, uudelleenrakennus tuoreelle, korjatulle järjestelmälle tarkistetuin tiedoin on usein luotettavampi tie kuin puhdistus käynnissä olevassa järjestelmässä.
Vaihe 3: Uusikaa pääsyt ja koventakaa
- Vaihtakaa salasanat: CMS:lle, hostingin asiakastilille, paneelille, tietokannalle, FTP:lle, SFTP:lle, SSH:lle ja sähköpostille, puhtaalta laitteelta.
- Vaihtakaa avaimet ja tunnisteet: Luokaa uudelleen API-avaimet, maksu- ja toimituspalveluiden rajapinnat, CMS:n sovellusavaimet, SSH-avaimet ja varmenteet, jotka olivat palvelimella.
- Päättäkää istunnot: Kirjatkaa ulos kaikki aktiiviset kirjautumiset CMS:ssä ja palveluissa ja tarkistakaa rekisteröidyt kaksivaiheiset laitteet.
- Ottakaa kaksivaiheinen tunnistautuminen käyttöön: Kaikille ylläpitopääsyille, myös hostingille, verkkotunnukselle ja DNS:lle.
- Koventakaa palvelin: Tarkistakaa ja dokumentoikaa PHP-asetukset, tiedosto-oikeudet, suoritusestot upload-kansioissa, palomuuri ja tietoturvaotsakkeet.
Vaihe 4: Velvoitteet, viestintä ja päättäminen
- Tarkistakaa ilmoitusvelvollisuudet: Jos henkilötiedot voivat olla vaarantuneet, GDPR:n 33 artiklan mukainen ilmoitus 72 tunnin kuluessa voi olla tarpeen. Arvio kuuluu tietosuojavastaavalle tai asianajajalle. Toimialakohtaiset velvoitteet, esimerkiksi NIS2:n mukaiset, tarkistetaan erikseen.
- Harkitkaa rikosilmoitusta: Poliisin Zentrale Ansprechstellen Cybercrime -yhteyspisteet ottavat vastaan yritysten rikosilmoituksia. Varmistetut lokit ovat siihen tärkeä pohja.
- Tiedottakaa asiakkaille ja Googlelle: Tiedottakaa kosketetuille asiallisesti ja sovitusti. Jos Google näyttää varoituksen, pyytäkää puhdistuksen jälkeen uudelleentarkistusta, kuten kuvataan sivulla Googlen varoituksen poistaminen.
- Dokumentoikaa päättäminen ja valvokaa: Kirjatkaa syy, ajanjakso, toimet ja avoimet kohdat raporttiin, johtakaa opit hätäsuunnitelmaan ja valvokaa järjestelmiä tehostetusti seuraavina viikkoina.
Yleiset virheet jälkikäsittelyssä
Monet poikkeamat venyvät, koska ensimmäisessä kiireessä säästetään väärässä paikassa tai toimitaan liian nopeasti. Nämä virheet kannattaa välttää:
- Poistetaan vain näkyvä: Poistettu roskapostisivu tai poistettu uudelleenohjaus ei todista, että verkkosivusto on puhdas. Takaovet jäävät usein huomaamatta.
- Salasanojen vaihto vaarantuneelta järjestelmältä: Jos tietokoneella tai palvelimella toimii yhä haittaohjelmia, uudet tunnukset voivat vuotaa heti uudelleen.
- Varmuuskopion sokea palautus: Ilman suljettua aukkoa ja tarkistettua varmuuskopiota hyökkääjä on pian taas ovella.
- Korjauksen ymmärtäminen hälytyksen päättymiseksi: Päivitys korjattuun PHP-versioon ei todista, ettei aiemmin ole tapahtunut mitään, eikä se poista lisättyä haittaohjelmaa.
- Velvoitteiden tarkistus liian myöhään: Määräajat alkavat poikkeaman tiedoksi tulosta, ei puhdistuksen päättymisestä.
- Ei dokumentaatiota: Ilman pöytäkirjaa vakuutuksen, viranomaisten tai asiakkaiden kysymyksiin on myöhemmin vaikea vastata.
Tämä tarkistuslista ei korvaa oikeudellista neuvontaa. Ilmoitusvelvollisuuksia, vastuuta tai vakuutusta koskevissa kysymyksissä kääntykää tietosuojavastaavanne, asianajajan tai vakuutusyhtiönne puoleen.
Miten PHP SOS auttaa konkreettisesti?
- Otamme vastuun jäsennellystä poikkeamien hallinnasta ja käymme tarkistuslistan läpi kanssanne kohta kohdalta pöytäkirjan kera.
- Varmistamme lokit ja järjestelmätilat niin, että ne säilyvät käyttökelpoisina vakuutusta, viranomaisia ja mahdollista IT-forensiikkaa varten.
- Suljemme aukon, puhdistamme tai rakennamme uudelleen ja uusimme pääsyt oikeassa järjestyksessä.
- Toimitamme loppuraportin, jossa on syy, toimet ja suositukset, ja valvomme järjestelmiä halutessanne sen jälkeenkin.
Usein kysytyt kysymykset
Mikä on ensimmäinen asia, joka pitäisi tehdä, jos verkkosivustoni on murrettu?
Pitäkää malttinne, älkää poistako mitään ja rajatkaa vahinko. Ottakaa verkkosivusto tarvittaessa pois verkosta tai huoltotilaan ja varmistakaa lokit ja tiedostot, ennen kuin puhdistatte. Sen jälkeen seuraavat syyn etsintä ja puhdistus.
Riittääkö, että verkkosivusto palautetaan varmuuskopiosta?
Yleensä ei. Varmuuskopio voi jo sisältää haittakoodia, ja aukko, jonka kautta hyökkääjä pääsi sisään, on palautuksen jälkeen yhä auki. Sulkekaa ensin syy, ottakaa sitten käyttöön tarkistettu, puhdas tila päivitettyyn järjestelmään.
Onko murrosta ilmoitettava tietosuojaviranomaiselle?
Jos henkilötiedot voivat olla vaarantuneet, GDPR:n 33 artikla edellyttää pääsääntöisesti ilmoitusta 72 tunnin kuluessa tiedon saamisesta, jos riski rekisteröidyille ei ole epätodennäköinen. Arvio kuuluu tietosuojavastaavalle tai asianajajalle.
Milloin poikkeama on todella käsitelty loppuun?
Kun syy on suljettu, kaikki tunnetut takaovet poistettu, pääsyt uusittu, velvoitteet täytetty ja toimet dokumentoitu. Sen jälkeen kuuluu tehostettu valvonta jonkin aikaa, jotta huomaamatta jääneet jäljet havaitaan.