# Palvelimen uudelleenasennus vai puhdistus? Päätös tartunnan jälkeen

> Palvelin hakkeroinnin jälkeen: asennetaanko uudelleen vai puhdistetaanko? Perusteet, oikea järjestys ja tyypilliset virheet uudelleenrakennuksessa selitettynä.

Lähde: https://phpsos.de/fi/blog/neu-aufsetzen-oder-bereinigen/  
Tilanne: 25.10.2026  
Palveluntarjoaja: PHP SOS, PHP-hätäapu ja palvelimen tietoturva. Pikaapu WhatsAppilla: https://wa.me/491736494914?text=Hei%20PHP%20SOS%2C%20tarvitsemme%20apua%20PHP-palvelimemme%20kanssa.%20Yritys%3A%20%E2%80%A6%20Verkkosivusto%3A%20%E2%80%A6

**Lyhyesti:** Se, asennatteko palvelimen hakkeroinnin jälkeen uudelleen vai puhdistatteko sen, riippuu siitä, kuinka varmasti tunnette tunkeutumisen laajuuden. Jos hyökkääjällä on voinut olla root-oikeudet, tunkeutumisen ajankohta on epäselvä tai lokit puuttuvat, uudelleenrakennus luotettavista lähteistä on varmempi valinta. Puhdistus tulee kyseeseen vain tiukasti rajatussa, hyvin todistetussa tartunnassa. Molemmissa tapauksissa pätee: ensin todisteet talteen ja aukko kiinni, sitten siivous.

## Miksi tätä kysymystä esitetään PHP2Shellin jälkeen erityisen usein

PHP2Shell sallii php.netin mukaan haittakoodin suorittamisen etänä ilman kirjautumista. Joka on ylläpitänyt päivittämätöntä palvelinta, joutuu siksi kysymään, onko 17.10.2026 alkaneena aikana, mediaraporttien mukaan ensimmäisen havaitun hyökkäysyrityksen jälkeen, tapahtunut jotain. Korjaus ei vastaa tähän kysymykseen, eikä julkaistuja, vahvistettuja Indicators of Compromise -tunnisteita ole.

Kun sitten löytyy epäilyttävä tiedosto, tuntematon prosessi tai vieras cron-työ, päätös on edessä. Vaisto on usein poistaa nopeasti tai asentaa heti uudelleen. Kumpikin voi olla oikein, mutta ei ensimmäisenä vaiheena.

## Järjestys ennen päätöstä

Ennen kuin valitsette puhdistuksen ja uudelleenasennuksen välillä, kolme asiaa on tehtävä. Ne pätevät molempiin teihin.

1. **Rajaa:** Ottakaa palvelin pois verkosta tai rajatkaa pääsy välttämättömään sammuttamatta sitä, jos työmuisti halutaan vielä turvata.
2. **Turvaa todisteet:** Turvatkaa lokit, tiedostot, tietokanta ja mahdollisuuksien mukaan järjestelmän levykuva, päivämäärällä ja tarkistussummalla. Miksi tämä on tarpeen ennen jokaista uudelleenasennusta, selittää [Todisteiden turvaaminen ennen uudelleenasennusta](https://phpsos.de/fi/blog/beweise-sichern-vor-neuinstallation/).
3. **Ota vakuutusyhtiö ja tietosuoja mukaan:** Monet kybervakuutukset odottavat, että olennaiset vaiheet sovitaan. Ohjeita löytyy sivulta [Kyberturvallisuusvakuutus: mikä merkitsee vahinkotilanteessa](https://phpsos.de/fi/compliance/cyberversicherung/). Se, onko GDPR:n mukainen ilmoitusvelvollisuus olemassa, arvioivat tietosuojavastaava tai asianajaja.

Vasta sen jälkeen varsinainen punninta kannattaa.

## Palvelin uudelleen hakkeroinnin jälkeen vai puhdistus: perusteet

| Kriteeri | Puhdista | Asenna uudelleen |
|---|---|---|
| Tunkeutumisen laajuus | Tiukasti rajattu, todistettu, esimerkiksi yksi tiedosto upload-kansiossa ilman muita jälkiä | Epäselvä tai viitteitä järjestelmäpääsystä |
| Hyökkääjän mahdolliset root-oikeudet | Pois suljettu hyvin perustein | Ei suljettavissa pois |
| Lokien saatavuus | Täydelliset olennaiselta ajalta | Puutteelliset, ylikirjoitetut tai manipuloitavissa |
| Vaiva | Pienempi, jos löydös on selvä | Suurempi, mutta paremmin suunniteltavissa |
| Jäljellä oleva epävarmuus | Suurempi, piilotettuja takaovia on vaikea sulkea pois | Pienempi, jos rakennettu siististi luotettavista lähteistä |
| Käyttökatko | Yleensä lyhyempi | Yleensä pidempi, valmistelulla hyvin hallittavissa |
| Soveltuvuus vanhoille järjestelmille | Ongelmallinen, jos järjestelmä on muutenkin vanhentunut | Hyvä tilaisuus siirtyä tuettuun PHP-versioon |

Nyrkkisääntö: mitä vähemmän tiedätte, sitä enemmän uudelleenrakennus puoltaa. PHP-tulkin aukossa, joka suorittaa koodia verkkopalvelinkäyttäjän yhteydessä, hyökkääjä voi hyödyntää muita heikkouksia saadakseen lisää oikeuksia. Sitä on vaikea sulkea pois ilman perusteellista tutkintaa.

## Molemmat tiet käytännössä

### Mitä ”asenna uudelleen” todella tarkoittaa

Uudelleenasennus ei tarkoita vanhan varmuuskopion kopioimista tuoreelle palvelimelle. Uudelleenrakennus alkaa puhtaalla käyttöjärjestelmällä virallisesta lähteestä, ajantasaisilla paketeilla ja päivitetyllä PHP-versiolla. Sovellus asennetaan valmistajan alkuperäisestä, lisäosat ja teemat samoin.

Vasta sitten tulevat omat sisällöt mukaan, ja tarkistettuina. Ladatut tiedostot eivät saa sisältää suoritettavia komentosarjoja, tietokanta voi sisältää sisään tuotua sisältöä, esimerkiksi piilotettuja ylläpitäjätilejä tai komentosarjoja artikkeleissa. Asetustiedostot kirjoitetaan uudelleen kopioimisen sijaan. Kaikki tunnukset uusitaan: tietokanta, CMS-ylläpitäjät, SSH-avaimet, API-avaimet, hosting-paneeli.

Varmuuskopioilla on tässä tärkeä rooli, mutta vain jos niiden tila on ennen tunkeutumista eikä niitä ole itse muutettu. Useat sukupolvet erillisissä paikoissa tekevät sen tarkistettavaksi; lisää sivulla [Varmuuskopiot 3-2-1-säännön mukaan](https://phpsos.de/fi/ratgeber/backups-3-2-1/).

### Kun puhdistus on perusteltua

Puhdistus voi olla järkevää, jos tartunta on havaittu aikaisin, täydelliset lokit ovat saatavilla eikä tutkinta anna viitteitä muista pääsyistä. Silloin löydetyt tiedostot poistetaan varmuuskopioinnin jälkeen, cron-työt, käyttäjätilit ja SSH-avaimet tarkistetaan ja ydintiedostot verrataan valmistajan alkuperäiseen.

Tärkeää on realistinen arvio: web shellit ovat usein huomaamattomia ja piilossa useassa paikassa. Miten ne löydetään, kuvaa sivu [Web shellien tunnistaminen ja poistaminen](https://phpsos.de/fi/ratgeber/webshell-erkennen/). Puhdistuksen jälkeen palvelinta pitäisi tarkkailla tiiviisti, jotta huomaamatta jäänyt takaovi paljastuu.

> **Toimi heti:**
> Älkää poistako mitään ennen kuin lokit ja tiedostot on turvattu, ja sulkekaa aukko ennen kuin palvelin palaa verkkoon. Muuten menetätte jäljet ja kutsutte seuraavan tunkeutumisen.

## Milloin ette tarvitse palveluntarjoajaa

Yksinkertaisella verkkosivustolla jaetussa hostingissa, jossa hosting-yritys hallinnoi järjestelmää ja vahvistaa PHP-korjauksen, päätös ei usein edes ole teidän. Voitte asentaa sovelluksen alkuperäisestä uudelleen, tarkistaa sisällöt ja uusia tunnukset hosting-yrityksen tukemana. Myös kokenut sisäinen tiimi voi tehdä uudelleenrakennuksen itse, jos todisteiden turvaaminen ja dokumentointi ovat kunnossa.

Ulkopuolinen apu kannattaa, jos root-oikeuksia ei voi sulkea pois, henkilötietoja voi olla vaarantunut, vakuutusyhtiö on mukana tai useat järjestelmät liittyvät toisiinsa.

## Miten PHP SOS auttaa konkreettisesti?

1. Turvaamme lokit, tiedostot ja tietokannan todisteiksi kelpaavasti ennen kuin mitään muutetaan.
2. Arvioimme tunkeutumisen laajuuden ja suosittelemme puhdistusta tai uudelleenrakennusta perusteluineen, erotellen todistetun, todennäköisen ja tuntemattoman.
3. Rakennamme palvelimen tarvittaessa uudelleen luotettavista lähteistä, päivitetyllä PHP-versiolla ja uusituilla käyttöoikeuksilla.
4. Hoidamme [haittaohjelmien poiston](https://phpsos.de/fi/leistungen/malware-entfernung/) siellä, missä puhdistus on perusteltua, ja dokumentoimme jokaisen vaiheen.

## Yhteenveto

Kysymykseen ”asennetaanko uudelleen vai puhdistetaanko?” vastataan tunkeutumisen tuntemuksella. Joka ei tunne laajuutta varmasti, rakentaa uudelleen. Joka voi rajata sen hyvin todistetusti, saa puhdistaa. Molemmissa tapauksissa pätee sama järjestys: rajaa, turvaa, sulje aukko, sitten siivoa.


## Usein kysytyt kysymykset

**Onko uudelleenasennus hakkeroinnin jälkeen aina parempi?**  
Ei aina, mutta usein. Jos on epäselvää, kuinka pitkälle hyökkääjä pääsi, uudelleenrakennus luotettavista lähteistä on yleensä varmempi valinta. Tiukasti rajatussa, hyvin todistetussa tartunnassa puhdistus voi riittää.

**Voinko vain palauttaa vanhan varmuuskopion?**  
Vain, jos on varmaa, että varmuuskopio on tehty ennen tunkeutumista eikä sisällä takaovea. Lisäksi aukon on oltava suljettu ennen sitä, muuten palvelin on heti taas haavoittuva. Uudemmat tiedot on tarkistettava erikseen.

**Mitä minun on turvattava ennen uudelleenasennusta?**  
Lokit, kopio tiedostoista ja tietokannasta sekä mahdollisuuksien mukaan järjestelmän levykuva. Näitä todisteita tarvitaan syyanalyysiin, vakuutukseen ja mahdolliseen ilmoitukseen. Poistamisen jälkeen ne ovat poissa.

**Riittääkö löydetyn web shellin poistaminen?**  
Harvoin. Hyökkääjät perustavat usein useita takaovia, esimerkiksi cron-töitä, käyttäjätilejä tai SSH-avaimia. Joka poistaa vain näkyvän tiedoston, jättää muut pääsyt auki.

## Lähteet

- [BSI: tietoa tietoturvahäiriöistä](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: tietoturvatiedotteet](https://www.php.net/)