Na kratko: Zamenjava CMS po vdoru pomaga samo, če je bil vzrok sam stari sistem, na primer ker proizvajalec ne dostavlja več varnostnih posodobitev ali pomembne razširitve niso več vzdrževane. Če je vzrok v zastarelih vtičnikih, šibkih dostopih ali vrzeli, kot je PHP2Shell, v spodnjem PHP, zamenjava napor le prestavi. V vsakem primeru velja: vsebine najprej preveriti, nato seliti, sicer se škodljiva koda preseli zraven.
Ko zaupanja ni več
Po vdoru je razpoloženje pogosto nedvoumno: »S tem sistemom nikoli več.« To je razumljivo. Spletna stran je obiskovalce preusmerjala na tuje strani, Google je opozoril, stranke so spraševale. Nov CMS se zdi kot nov začetek.
Razmere okoli PHP2Shell pa kažejo, zakaj ta refleks lahko zavede. Vrzel je v interpreterju PHP, ne v WordPress, TYPO3, Shopware ali drugem sistemu. WordPress.org zato po navedbah drweb.de ne načrtuje lastne posodobitve proti njej. Kdor zdaj z enega CMS PHP preide na drugega, ima na koncu isto odvisnost, le z drugim logotipom. Kateri sistemi tečejo na PHP, kaže pregled Kateri CMS in spletni sistemi tečejo na PHP.
Kaj je bil vzrok, odloča
Preden razmišljate o zamenjavi, mora biti vzrok vdora razjasnjen. Značilna vrata so zastarele razširitve, večkrat uporabljena ali šibka gesla, manjkajoča dvofaktorska prijava, nepopravljen strežnik ali pozabljene testne namestitve. Noben od teh vzrokov ni vezan na določen CMS.
Kdor vzroka ne pozna, tvega, da ga prenese v novi sistem. Ekipa, ki je posodobitve doslej odlagala, jih bo odlagala tudi v novem CMS. Agencija, ki je uporabljala skupne skrbniške račune, bo to ponovila, če nihče ne spremeni postopka. Vprašanje torej ni »kateri CMS?«, ampak »kateri postopek?«.
Zamenjava CMS po vdoru: tehtanje
| Merilo | Ostati pri obstoječem CMS in utrditi | Preiti na drug CMS |
|---|---|---|
| Vzrok vdora | Znan in odpravljiv, na primer zastarel vtičnik | Leži v samem sistemu, na primer manjkajoče posodobitve proizvajalca |
| Oskrba proizvajalca | Varnostne posodobitve se dostavljajo | Proizvajalec je oskrbo ustavil |
| Odvisnost od razširitev | Malo vzdrževanih razširitev | Mnogo razširitev brez aktivne oskrbe |
| Napor | Čiščenje, utrjevanje, sprememba postopka | Nova gradnja, selitev, usposabljanje, pogosto novo oblikovanje |
| Čas do varne spletne strani | Krajši | Daljši, potrebna prehodna rešitev |
| Zaščita pred vrzelmi PHP | Brez spremembe, PHP je treba popraviti | Brez spremembe, dokler novi sistem uporablja PHP |
| Dolgoročna korist | Velika, če se postopki izboljšajo | Velika, če je bil stari sistem tako ali tako na koncu |
Če večina vrstic v vaših razmerah pristane na levi, se zamenjava komaj splača. Ostati, očistiti, utrditi in izboljšati vzdrževalni postopek prinese več varnosti za manj denarja. Za upravljavce WordPress najpomembnejše korake povzema WordPress in PHP2Shell.
Ponudnika za to odločitev ne potrebujete vedno. Če je bil vzrok nedvoumen, na primer znan vtičnik z objavljeno vrzeljo, in je vaša agencija ali skrbnik spletno stran čisto na novo postavil, lahko odločite sami. Zunanja pomoč se splača, če vzrok ostane nejasen ali bi bili lahko prizadeti osebni podatki.
Če zamenjate: škodljive kode ne vzemite s seboj
Če padne odločitev za zamenjavo, je sama selitev varnostno tveganje. Napadalci pustijo sledi ne le v datotekah, ampak tudi v podatkovni bazi. Ti koraki pomagajo čisto seliti:
- Stari sistem zavarovati in izolirati: Popolna varnostna kopija kot dokaz, nato stari sistem odstraniti z omrežja ali ga narediti dosegljivega le interno.
- Vsebine izvoziti ciljno: Besedila, strukturo strani in medije, ne cele podatkovne baze. Uporabniških računov ne prevzeti, ampak jih ustvariti na novo.
- Vsebine preveriti: Besedila pregledati glede vnesenih skriptov, skritih povezav in tujih preusmeritev. Kako, opisuje Preverjanje podatkovne baze za vneseno kodo.
- Medije filtrirati: Prevzeti samo pričakovane vrste datotek, datoteke z dvojnimi končnicami ali vsebino skripta izločiti.
- Nov sistem čisto postaviti: Iz izvornega vira proizvajalca, na strežniku s popravljenim PHP, z novimi dostopnimi podatki in dvofaktorsko prijavo.
- Načrtovati preusmeritve: Stare naslove preusmeriti na nove, da iskalniki in obiskovalci pridejo na cilj, ne da bi stare poti ostale odprte.
Zamenjava CMS ne nadomešča čiščenja starega strežnika. Če stari sistem teče naprej, na primer kot pozabljena kopija na poddomeni, stranska vrata ostanejo odprta.
Alternativa, ki se pogosto spregleda
Nekatera podjetja po vdoru ugotovijo, da funkcij velikega CMS sploh ne potrebujejo. Spletna stran podjetja z nekaj stranmi, ki se redko spreminjajo, shaja tudi brez PHP na strežniku. Generator statičnih strani ustvari gotove datoteke HTML, ki ne potrebujejo več strežniške programske logike. Katere prednosti in slabosti ima to, opisuje Statične spletne strani: manj PHP, manj napadalne površine.
Obratno za trgovine, portale ali spletne strani z mnogimi uredniki to običajno ni možnost. Tu ostaja dinamičen sistem smiseln, varnost pa nastane z oskrbo, utrjevanjem in nadzorom.
Kdor je negotov, ali se v starem WordPress skrivajo še skriti dostopi, najde v Iskanje stranskih vrat v WordPress značilna mesta najdb. To pomaga tudi pri odločitvi, ali je čiščenje realistično.
Kako PHP SOS pomaga konkretno?
- Najprej razjasnimo vzrok vdora in vam povemo, ali tiči v CMS ali v postopku in strežniku.
- Obstoječi sistem očistimo v okviru odstranjevanja škodljive programske opreme ali ga pripravimo kot dokaz za novo gradnjo.
- Ob zamenjavi vsebine in medije, ki se prevzamejo, preverimo glede škodljive kode, preden pridejo v novi sistem.
- Novi strežnik postavimo s popravljenim PHP in utrjeno konfiguracijo.
Sklep
Zamenjava CMS po vdoru je redko rešitev, včasih pa pravi povod. Če stari sistem ni več vzdrževan, se nov začetek splača. Če je vzrok v postopkih ali na strežniku, delo na postopku prinese več kot nov logotip. V obeh primerih velja: najprej preveriti, nato seliti.
Pogosta vprašanja
Ali zamenjava CMS pomaga proti PHP2Shell?
Ne, dokler tudi novi CMS teče na PHP. PHP2Shell je v interpreterju PHP, ne v CMS. Odločilno je stanje popravkov PHP na strežniku, ne sistem nad njim.
Ali je WordPress manj varen od drugih CMS?
Pavšalno tega ni mogoče reči. Mnogi vdori nastanejo zaradi zastarelih razširitev, šibkih dostopov ali manjkajočih posodobitev, ti vzroki pa obstajajo v vsakem sistemu. Razširjenost pa naredi CMS pogostejšo tarčo samodejnih skeniranj.
Ali lahko vsebine iz vdrtega CMS preprosto izvozim?
Samo po preverjanju. Podatkovna baza lahko vsebuje vnesene skripte, skrite povezave ali tuje skrbniške račune. Naložene datoteke lahko prikrivajo škodljivo kodo. Vsebine izvozite ciljno in jih pred uvozom preverite.
Kdaj je zamenjava CMS res smiselna?
Če proizvajalec ne dostavlja več varnostnih posodobitev, če je spletna stran odvisna od razširitev, ki se ne vzdržujejo več, ali če sistem današnjim zahtevam preprosto ne ustreza več. Vdor je tedaj povod, ne razlog.