Lyhyesti: Koskeeko tämä teitä? Soittakaa. Autamme. Jos epäilette, että palvelimenne on murrettu, ensimmäinen asia on jälkien säilyttäminen. Otamme etänä ensimmäisestä viestistä alkaen vastuun tilannekuvasta, varmistuksesta, rajaamisesta, puhdistuksesta ja dokumentoinnista, kunnes tapaus on käsitelty loppuun.
Älkää nyt poistako mitään äläkä asentako palvelinta uudelleen. Älkää myöskään palauttako varmuuskopiota, ennen kuin varmistus on tehty. Se, joka siivoaa, tuhoaa juuri ne jäljet, jotka kertovat, miten hyökkääjä pääsi sisään. Ilmoittakaa hätätilanne, niin etenemme yhdessä.
Koskeeko tämä teitä? Merkkejä siitä, että palvelin on murrettu
Epäily riittää yhteydenottoon. Teidän ei tarvitse todistaa hyökkäystä. Tyypillisiä vihjeitä ovat:
- Verkkopalvelin tai PHP-FPM käynnistää prosesseja kuten
shtaibash. Se on vahva varoitusmerkki, jonka selitämme sivulla Verkkopalvelin käynnistää shellin. - Upload-, välimuisti- tai temp-kansioissa on uusia tai tuntemattomia PHP-tiedostoja.
- On cron-töitä, joita kukaan ei ole luonut, tai SSH-avaimia, joita kukaan ei osaa yhdistää kehenkään.
- Kuormitus on suuri ilman selvää syytä, tai palvelin muodostaa epätavallisia lähteviä yhteyksiä.
- Palvelimenne sähköpostit päätyvät roskapostiin tai hylätään.
- Hosting-yritys, asiakas tai selaimen varoitus ilmoittaa haittakoodista.
- CMS:ssä on ylläpitäjätilejä, joita kukaan ei ole luonut.
Lisää merkkejä löydätte sivulta Olenko jo vaarantunut?. Jos useampi kohta pitää paikkansa, kohdelkaa palvelinta murrettuna, kunnes toisin todistetaan.
Palvelin murrettu: mitä teette heti
- Pysykää rauhallisina ja älkää muuttako mitään. Ei tiedostojen poistamista, ei ”pikakorjauksia”, ei uudelleenasennusta vanhan tilan päälle.
- Kirjatkaa ajankohta. Merkitkää muistiin, mitä olette havainneet ja milloin, ja kuka viimeksi teki muutoksia järjestelmään.
- Säilyttäkää lokit. Käyttö-, virhe- ja järjestelmälokit eivät saa kiertää eikä niitä saa päällekirjoittaa. PHP2Shellin osalta alan lehdistö neuvoo säilyttämään palvelinlokit 20.10.2026 alkaen.
- Pienentäkää hyökkäyspintaa. Ottakaa palvelin pois julkisesta verkosta tai sulkekaa se palomuurilla, jos tietoja voi vuotaa. Älkää vain sammuttako sitä.
- Kootkaa tunnukset. Kenellä on SSH-, paneeli-, FTP-, CMS- ja tietokantatunnukset? Vaihtakaa salasanat vasta sovittuaan ja vain puhtaalta laitteelta.
- Nimetkää yhteyshenkilö. Päätösvaltaisen henkilön tulee olla tavoitettavissa, myös sammuttamista ja uudelleenkäynnistyksiä varten.
- Ottakaa yhteyttä nyt. Soittakaa tai kirjoittakaa WhatsAppilla. Kaiken muun selvitämme kanssanne vaihe vaiheelta.
Pois verkosta vai käyntiin?
Tämä on ensimmäisten minuuttien yleisin kysymys, eikä siihen ole yleispätevää vastausta. Jos käynnissä on maksuja käsittelevä verkkokauppa tai asiakastietoja sisältävä portaali, tietojen suojaaminen painaa yleensä enemmän. Silloin tilapäinen eristäminen on oikein, esimerkiksi huoltosivun tai palomuurisäännön avulla, joka päästää läpi vain ylläpitäjänne.
Kova sammutus sen sijaan on harvoin paras ensimmäinen toimi, koska muistissa on jälkiä, jotka uudelleenkäynnistys tyhjentää. Parempi on järjestelmän kopio, esimerkiksi hosting-yrityksen tilannevedos (snapshot), ennen kuin mitään muutetaan. PHP2Shell-tilanteessa BSI suosittelee ottamaan verkkopalvelimet tilapäisesti pois verkosta, jos päivitystä ei voi tehdä heti. Se ei tarkoita, että jokainen sammutettu palvelin olisi murrettu.
Eristättekö, hidastatteko vai jätättekö käyntiin omassa tapauksessanne, päätämme kanssanne sen perusteella, mitä järjestelmässä on.
Asennetaanko uudelleen vai puhdistetaanko?
Moni haluaa mieluiten rakentaa palvelimen heti uudelleen. Se ei ole väärin, mutta vasta varmistuksen jälkeen. Muuten jää epäselväksi, miten hyökkääjä pääsi sisään, ja sama reitti on auki myös uudelle järjestelmälle. Punninnan kuvaa sivu Asennetaanko palvelin uudelleen vai puhdistetaanko se? ja varmistuksen ennen uudelleenrakennusta sivu Todisteiden varmistus ennen uudelleenasennusta.
Tärkeää: pelkkä PHP-päivitys ei ratkaise ongelmaa. Se sulkee haavoittuvuuden, mutta ei poista jo lisättyä haittaohjelmaa. Miten jäljet löytyvät lokeista, kerrotaan sivulla Verkkopalvelinlokien analysointi hyökkäyksen jälkeen. Ja olettakaa, että asetustiedostoista on luettu myös tunnuksia: tietokannan, sähköpostin ja API:en tunnukset kuuluvat uusittavien salaisuuksien luetteloon.
Miten PHP SOS auttaa konkreettisesti?
- Tilanteen kartoitus: Selvitämme kanssanne, mitä on havaittu, mitkä järjestelmät voivat olla kohteena ja mitä tietoja niillä on.
- Varmistus ja sulkeminen: Varmistamme tiedostot, tietokannan ja lokit, ennen kuin mitään muutetaan. Sen jälkeen rajaamme hyökkäyksen ja suljemme sisäänkäynnin, PHP2Shellin tapauksessa korjauksella ja kaikkien PHP-prosessien uudelleenkäynnistyksellä.
- Tarkistus ja puhdistus: Etsimme web shellejä, takaovia, cron-töitä ja vieraita pääsyoikeuksia ja poistamme ne. Lisätietoja sivulla Haittaohjelmien ja web shellien poistatus.
- Koventaminen ja raportointi: Saatte dokumentaation, jossa on aikajana, löytökohdat ja suositukset. Jos tapaus ulottuu yhtä palvelinta pidemmälle, siirrymme jäsenneltyyn tietoturvapoikkeamien hallintaan (Incident Response).
Mitä ette saa tehdä
Stressissä sattuu vältettävissä olevia virheitä. Älkää poistako ”epäilyttäviä” tiedostoja epäilyn perusteella varmistamatta niitä ensin. Älkää ajako komentoja foorumeilta, joita ette ymmärrä. Älkää asentako tietoturvalisäosia palvelimelle, joka on mahdollisesti jo vaarantunut: haittakoodi voi huijata skannereita, ja tulos nukuttaa väärään turvallisuudentunteeseen. Varovaisuutta myös neuvoihin estää kaikki pyynnöt tietyllä istuntotunnuksella; asiantuntijakirjoittajat torjuvat tällaiset PHP2Shell-neuvot nimenomaisesti. Oman versionne voitte tarkistaa luotettavasti komennolla php -v ja katsomalla jakelunne paketin muutoslokia, sillä backportit jättävät versionumeron usein ennalleen.
Mitä teidän kannattaa lähettää meille
- lyhyt kuvaus: mitä on huomattu, mistä lähtien ja mitä viimeksi muutettiin
- järjestelmän tyyppi: oma palvelin, vServer, hallinnoitu palvelin tai hosting-paketti
- pääsy SSH:lla tai paneelin kautta tai lupa keskustella hosting-yrityksenne kanssa
- tiedot olemassa olevista varmuuskopioista ja niiden iästä
- hosting-yrityksen, selaimen tai asiakkaiden varoitusviestit sanatarkasti
Jos jokin näistä puuttuu, ottakaa silti yhteyttä. Aukot täytämme keskustelussa.
Miksi PHP SOS
Työmme on Saksassa tehtyä (Made in Germany), ja olemme yli 25 vuoden ajan erikoistuneet tietoturvaan kumppaniverkostomme kyberammattilaisten kanssa. Teillä on yksi yhteyshenkilö, työskentelemme etänä, ilman matkustamista, kaikkialla Saksassa ja Euroopassa. Jokainen vaihe dokumentoidaan, ja erotamme avoimesti toisistaan todennetun, todennäköisen ja tuntemattoman. Lupauksia, joita kukaan ei voi pitää, emme anna. Yleiskuvan jälkityöstä antaa murron jälkeinen tarkistuslista, koko hätäavun löydätte sivulta Verkkosivusto murrettu? Etähätäapu. Tietomurtojen ilmoitusvelvollisuudesta lukekaa 72 tunnin sääntö; oikeudellinen arvio jää tietosuojavastaaville ja lakimiehille.
Koskeeko tämä teitä? Soittakaa. Autamme.
Älkää odottako, että epäilystä kasvaa suurempi vahinko. Otamme tilanteen hoitoon ensimmäisestä viestistä alkaen ja pysymme mukana, kunnes tapaus on käsitelty loppuun ja dokumentoitu. Ilmoittakaa hätätilanne nyt.
Usein kysytyt kysymykset
Palvelin murrettu: pitäisikö se sammuttaa heti?
Ei hätiköiden. Sammuttaminen voi tuhota muistissa olevia katoavia jälkiä. Parempi on irrottaa palvelin verkosta tai eristää se palomuurilla ja varmistaa ensin. Jos olette epävarma, ottakaa ensin yhteyttä meihin.
Miten selvitän, onko palvelimeni todella murrettu?
Vihjeitä antavat verkkopalvelimen käynnistämät prosessit, uudet PHP-tiedostot upload- tai välimuistikansioissa, tuntemattomat cron-työt ja SSH-avaimet sekä epätavalliset lähtevät yhteydet. Varmuuden antaa vasta lokien ja tiedostojen analyysi. Vahvistettuja PHP2Shell-tunnisteita ei ole, havaitseminen perustuu käyttäytymisanalyysiin.
Riittääkö PHP-päivitys, jos palvelin on jo murrettu?
Ei. Korjaus sulkee sisäänkäynnin, mutta ei poista jo lisättyä haittaohjelmaa eikä todista, ettei aiemmin ole tapahtunut mitään. Päivityksen jälkeen kaikki PHP-prosessit on lisäksi käynnistettävä uudelleen.
Onko murretusta palvelimesta ilmoitettava?
Jos henkilötiedot voivat olla vaarantuneet, valvontaviranomaiselle tehtävä ilmoitus voi olla tarpeen 72 tunnin kuluessa. Arvion tekevät tietosuojavastaavanne tai lakimiehenne; me toimitamme siihen tekniset tosiasiat.
Voinko puhdistaa murretun palvelimen itse?
Pienissä järjestelmissä se on mahdollista mutta riskialtista: se, joka poistaa vain näkyvät tiedostot, jättää usein huomaamatta takaovet, cron-työt tai pääsyoikeudet. Tarkistamme, riittääkö puhdistus vai onko järkevämpää rakentaa järjestelmä uudelleen puhtaista lähteistä.