Lyhyesti: CMS:n vaihto hakkeroinnin jälkeen auttaa vain, jos vanha järjestelmä itse oli syy, esimerkiksi koska valmistaja ei enää toimita tietoturvapäivityksiä tai tärkeitä laajennuksia ei enää ylläpidetä. Jos syy oli vanhentuneissa lisäosissa, heikoissa käyttöoikeuksissa tai PHP2Shellin kaltaisessa aukossa alla olevassa PHP:ssä, vaihto vain siirtää vaivaa. Joka tapauksessa pätee: tarkistakaa sisällöt ensin, siirtäkää sitten, muuten haittakoodi muuttaa mukana.
Kun luottamus on mennyt
Tunkeutumisen jälkeen tunnelma on usein yksiselitteinen: ”Tätä järjestelmää en enää koskaan.” Se on ymmärrettävää. Verkkosivusto on ohjannut kävijöitä vierailla sivuille, Google on varoittanut, asiakkaat ovat kysyneet. Uusi CMS tuntuu uudelta alulta.
PHP2Shellin ympärillä oleva tilanne osoittaa kuitenkin, miksi tämä refleksi voi johtaa harhaan. Aukko on PHP-tulkissa, ei WordPressissä, TYPO3:ssa, Shopwaressa tai muussa järjestelmässä. WordPress.org ei drweb.den mukaan siksi suunnittele omaa päivitystä sitä vastaan. Joka nyt vaihtaa PHP-CMS:stä toiseen PHP-CMS:ään, saa lopulta saman riippuvuuden, vain eri logolla. Mitkä järjestelmät toimivat PHP:llä, näyttää yleiskatsaus Mitkä CMS- ja verkkokauppajärjestelmät toimivat PHP:llä.
Syy ratkaisee
Ennen kuin harkitsette vaihtoa, tunkeutumisen syy on selvitettävä. Tyypillisiä sisäänkäyntejä ovat vanhentuneet laajennukset, monessa paikassa käytetyt tai heikot salasanat, puuttuva kaksivaiheinen tunnistautuminen, päivittämätön palvelin tai unohtuneet testiasennukset. Mikään näistä syistä ei ole sidottu tiettyyn CMS:ään.
Joka ei tiedä syytä, riskeeraa viedä sen mukanaan uuteen järjestelmään. Tiimi, joka on aiemmin lykännyt päivityksiä, tekee saman uudessa CMS:ssä. Toimisto, joka käytti yhteisiä ylläpitäjätilejä, toistaa sen, ellei kukaan muuta toimintatapaa. Kysymys ei siis ole niinkään ”mikä CMS?” vaan ”mikä prosessi?”.
CMS:n vaihto hakkeroinnin jälkeen: punninta
| Kriteeri | Pysy nykyisessä CMS:ssä ja koventakaa | Vaihda toiseen CMS:ään |
|---|---|---|
| Tunkeutumisen syy | Tunnettu ja korjattavissa, esim. vanhentunut lisäosa | On järjestelmässä itsessään, esim. valmistajan päivitykset puuttuvat |
| Valmistajan ylläpito | Tietoturvapäivityksiä toimitetaan | Valmistaja on lopettanut ylläpidon |
| Riippuvuus laajennuksista | Vähän, ylläpidettyjä laajennuksia | Monta laajennusta ilman aktiivista ylläpitoa |
| Vaiva | Puhdistus, koventaminen, prosessin muutos | Uudelleenrakennus, siirto, koulutus, usein uusi ulkoasu |
| Aika turvalliseen verkkosivustoon | Lyhyempi | Pidempi, välivaiheen ratkaisu tarpeen |
| Suoja PHP-aukoilta | Ei muutosta, PHP on päivitettävä | Ei muutosta, niin kauan kuin uusi järjestelmä käyttää PHP:tä |
| Pitkän aikavälin hyöty | Korkea, jos prosessit paranevat | Korkea, jos vanha järjestelmä oli muutenkin lopussa |
Jos useimmat rivit osuvat tilanteessanne vasemmalle, vaihto ei juuri kannata. Pysyminen, puhdistus, koventaminen ja huoltokulun parantaminen tuo enemmän turvaa pienemmällä rahalla. WordPressin ylläpitäjille tärkeimmät vaiheet tiivistää sivu WordPress ja PHP2Shell.
Palveluntarjoajaa ette tarvitse tähän päätökseen aina. Jos syy oli selvä, esimerkiksi tunnettu lisäosa julkaistulla aukolla, ja toimistonne tai ylläpitäjänne on asentanut verkkosivuston siististi uudelleen, voitte päättää itse. Ulkopuolinen apu kannattaa, jos syy jää epäselväksi tai henkilötietoja voi olla vaarantunut.
Jos vaihdatte: älkää ottako haittakoodia mukaan
Jos päätätte vaihtaa, siirto itsessään on tietoturvariski. Hyökkääjät jättävät jälkiä paitsi tiedostoihin myös tietokantaan. Nämä vaiheet auttavat siirtämään siististi:
- Turvaa ja eristä vanha järjestelmä: Täydellinen varmuuskopio todisteeksi, sitten vanha järjestelmä pois verkosta tai vain sisäisesti tavoitettavaksi.
- Vie sisällöt kohdennetusti: Tekstit, sivurakenne ja media, ei koko tietokantaa. Käyttäjätilejä ei siirretä vaan luodaan uudelleen.
- Tarkista sisällöt: Käykää tekstit läpi sisään tuotujen komentosarjojen, piilolinkkien ja vieraiden uudelleenohjausten varalta. Miten se tehdään, kuvaa sivu Tietokannan tarkistus sisään tuodun koodin varalta.
- Suodata media: Ottakaa mukaan vain odotetut tiedostotyypit, poistakaa tiedostot kaksoispäätteillä tai komentosarjasisällöllä.
- Asenna uusi järjestelmä siististi: Valmistajan alkuperäisestä lähteestä, palvelimelle jolla on päivitetty PHP, uusin käyttöoikeuksin ja kaksivaiheisella tunnistautumisella.
- Suunnittele uudelleenohjaukset: Ohjatkaa vanhat osoitteet uusiin, jotta hakukoneet ja kävijät pääsevät perille eikä vanhoja polkuja jää auki.
CMS:n vaihto ei korvaa vanhan palvelimen puhdistusta. Jos vanha järjestelmä jää toimimaan, esimerkiksi unohtuneena kopiona aliverkkotunnuksella, takaovi pysyy auki.
Vaihtoehto, joka usein jää huomaamatta
Jotkin yritykset huomaavat hakkeroinnin jälkeen, etteivät tarvitse ison CMS:n toimintoja lainkaan. Yrityksen verkkosivusto, jossa on vain muutama harvoin muuttuva sivu, tulee toimeen ilman PHP:tä palvelimella. Staattisten sivujen generaattori tuottaa valmiita HTML-tiedostoja, jotka eivät enää tarvitse palvelinpuolen ohjelmalogiikkaa. Mitä hyviä ja huonoja puolia sillä on, kuvaa sivu Staattiset verkkosivustot: vähemmän PHP:tä, vähemmän hyökkäyspinta-alaa.
Päinvastoin verkkokaupoille, portaaleille tai useiden toimittajien verkkosivustoille se ei yleensä ole vaihtoehto. Niissä dynaaminen järjestelmä pysyy järkevänä, ja turvallisuus syntyy ylläpidosta, koventamisesta ja valvonnasta.
Joka epäilee, piileekö vanhassa WordPressissä yhä piilotettuja käyttöoikeuksia, löytää tyypilliset löytöpaikat sivulta WordPressin takaovien löytäminen. Se auttaa myös päättämään, onko puhdistus realistinen.
Miten PHP SOS auttaa konkreettisesti?
- Selvitämme ensin tunkeutumisen syyn ja kerromme, onko se CMS:ssä vai prosessissa ja palvelimessa.
- Puhdistamme nykyisen järjestelmän haittaohjelmien poiston puitteissa tai valmistelemme sen todisteeksi uudelleenrakennusta varten.
- Vaihdon yhteydessä tarkistamme siirrettävät sisällöt ja mediat haittakoodin varalta ennen kuin ne päätyvät uuteen järjestelmään.
- Asennamme uuden palvelimen päivitetyllä PHP:llä ja kovennetulla konfiguraatiolla.
Yhteenveto
CMS:n vaihto hakkeroinnin jälkeen on harvoin ratkaisu, mutta joskus oikea tilaisuus. Jos vanhaa järjestelmää ei enää ylläpidetä, uusi alku kannattaa. Jos syy oli prosesseissa tai palvelimessa, prosessin parantaminen tuo enemmän kuin uusi logo. Molemmissa tapauksissa pätee: tarkista ensin, siirrä sitten.
Usein kysytyt kysymykset
Auttaako CMS:n vaihto PHP2Shelliä vastaan?
Ei, niin kauan kuin uusi CMS toimii myös PHP:llä. PHP2Shell on PHP-tulkissa, ei CMS:ssä. Ratkaisevaa on PHP:n korjaustila palvelimella, ei sen päällä oleva järjestelmä.
Onko WordPress turvattomampi kuin muut CMS:t?
Sitä ei voi sanoa yleisesti. Monet tunkeutumiset syntyvät vanhentuneista laajennuksista, heikoista käyttöoikeuksista tai puuttuvista päivityksistä, ja nämä syyt ovat olemassa jokaisessa järjestelmässä. Yleisyys tekee CMS:stä kuitenkin useammin automatisoitujen skannausten kohteen.
Voinko vain viedä sisällöt hakkeroidusta CMS:stä?
Vasta tarkistuksen jälkeen. Tietokanta voi sisältää sisään tuotuja komentosarjoja, piilolinkkejä tai vieraita ylläpitäjätilejä. Ladatut tiedostot voivat peitellä haittakoodia. Viekää sisällöt kohdennetusti ja tarkistakaa ne ennen tuontia.
Milloin CMS:n vaihto on todella järkevä?
Kun valmistaja ei enää toimita tietoturvapäivityksiä, kun verkkosivusto riippuu laajennuksista, joita ei enää ylläpidetä, tai kun järjestelmä ei yksinkertaisesti enää sovellu nykyisiin vaatimuksiin. Hakkerointi on silloin syy ryhtyä toimeen, ei peruste.