Lühidalt: CMS-i vahetamine pärast häkkimist aitab ainult siis, kui vana süsteem ise oli põhjus, näiteks sellepärast, et tootja ei tarni enam turvauuendusi või olulisi laiendusi ei hooldata enam. Kui põhjus oli vananenud pistikprogrammides, nõrkades ligipääsudes või turvaaugus nagu PHP2Shell aluseks olevas PHP-s, nihutab vahetus ainult vaeva. Igal juhul kehtib: sisu esmalt kontrollida, siis üle viia, muidu rändab kahjulik kood kaasa.
Kui usaldus on kadunud
Pärast sissemurdmist on meeleolu sageli ühene: „Selle süsteemiga enam mitte kunagi.“ See on mõistetav. Veebisait on suunanud külastajaid võõrastele lehtedele, Google on hoiatanud, kliendid on järele küsinud. Uus CMS tundub nagu uus algus.
PHP2Shelli olukord näitab aga, miks see refleks võib eksiteele viia. Turvaauk asub PHP interpretaatoris, mitte WordPressis, TYPO3-s, Shopware'is ega muus süsteemis. WordPress.org ei plaani drweb.de andmetel seetõttu selle vastu oma uuendust. Kes nüüd ühelt PHP-põhiselt CMS-ilt teisele PHP-põhisele CMS-ile vahetab, saab lõpuks sama sõltuvuse, ainult teise logoga. Millised süsteemid PHP peal töötavad, näitab ülevaade Millised CMS-id ja poesüsteemid PHP peal töötavad.
Otsustab see, mis oli põhjus
Enne kui vahetust kaalute, tuleb sissemurdmise põhjus selgitada. Tüüpilised sissepääsuvärav on vananenud laiendused, mitmekordselt kasutatud või nõrgad paroolid, puuduv kaheastmeline sisselogimine, paigata server või unustatud testpaigaldused. Ükski neist põhjustest ei ole seotud kindla CMS-iga.
Kes põhjust ei tea, riskib selle uude süsteemi kaasa võtmisega. Meeskond, kes on seni uuendusi edasi lükanud, teeb seda ka uues CMS-is. Agentuur, kes kasutas ühiseid administraatorikontosid, kordab seda, kui keegi kulgu ei muuda. Küsimus ei ole seega niivõrd „milline CMS?“, vaid „milline protsess?“.
CMS-i vahetus pärast häkkimist: kaalutlus
| Kriteerium | Jääda olemasoleva CMS-i juurde ja karastada | Vahetada teisele CMS-ile |
|---|---|---|
| Sissemurdmise põhjus | Teada ja kõrvaldatav, näiteks vananenud pistikprogramm | Asub süsteemis endas, näiteks puuduvad tootja uuendused |
| Tootja hooldus | Turvauuendused tarnitakse | Tootja on hoolduse lõpetanud |
| Sõltuvus laiendustest | Vähe, hooldatud laiendused | Palju laiendusi ilma aktiivse hoolduseta |
| Vaev | Puhastamine, karastamine, protsessi muutmine | Uuesti ülesehitamine, migratsioon, koolitus, sageli uus kujundus |
| Aeg turvalise veebisaidini | Lühem | Pikem, vaja on üleminekulahendust |
| Kaitse PHP turvaaukude eest | Muutust ei ole, PHP tuleb paigata | Muutust ei ole, kui uus süsteem kasutab PHP-d |
| Pikaajaline kasu | Kõrge, kui protsesse parandatakse | Kõrge, kui vana süsteem oli niikuinii lõppemas |
Kui enamik ridu teie olukorras satub vasakule, ei tasu vahetus end peaaegu ära. Jäämine, puhastamine, karastamine ja hooldusprotsessi parandamine annab rohkem turvalisust väiksema rahaga. WordPressi käitajatele võtab olulisemad sammud kokku WordPress ja PHP2Shell.
Teenusepakkujat selle otsuse jaoks ei vaja alati. Kui põhjus oli selge, näiteks teada pistikprogramm avaldatud turvaauguga, ja teie agentuur või administraator on veebisaidi puhtalt uuesti üles seadnud, saate ise otsustada. Väline abi tasub, kui põhjus jääb ebaselgeks või isikuandmed võivad olla mõjutatud.
Kui vahetate: ärge võtke kahjulikku koodi kaasa
Kui otsus langeb vahetuse kasuks, on migratsioon ise turvarisk. Ründajad jätavad jälgi mitte ainult failidesse, vaid ka andmebaasi. Need sammud aitavad puhtalt üle kolida:
- Vana süsteem kindlustada ja isoleerida: Täielik koopia tõendina, seejärel vana süsteem võrgust maha võtta või teha see ainult sisemiselt ligipääsetavaks.
- Eksportida sisu sihipäraselt: Tekstid, lehestruktuur ja meedia, mitte kogu andmebaas. Kasutajakontosid mitte üle võtta, vaid luua uuesti.
- Kontrollida sisu: Vaadata tekstid läbi sisse toodud skriptide, peidetud linkide ja võõraste ümbersuunamiste suhtes. Kuidas see käib, kirjeldab Andmebaasi kontroll sisse toodud koodi suhtes.
- Filtreerida meediat: Üle võtta ainult oodatud failitüübid, sorteerida välja topeltlaiendiga või skriptisisuga failid.
- Seada uus süsteem puhtalt üles: Tootja originaalallikast, paigatud PHP-ga serveril, uute sisselogimisandmete ja kaheastmelise sisselogimisega.
- Planeerida ümbersuunamised: Suunata vanad aadressid uutele, et otsingumootorid ja külastajad kohale jõuaksid, ilma et vanad teed lahti jääksid.
CMS-i vahetus ei asenda vana serveri puhastamist. Kui vana süsteem töötab edasi, näiteks unustatud koopiana alamdomeenil, jääb tagauks lahti.
Alternatiiv, mis sageli tähelepanuta jääb
Mõned ettevõtted tõdevad pärast häkkimist, et nad ei vajagi suure CMS-i funktsioone. Ettevõtte veebisait mõne harva muudetava lehega saab hakkama ka ilma PHP-ta serveris. Staatiliste lehtede generaator loob valmis HTML-faile, mis ei vaja serveripoolset programmiloogikat. Millised on selle plussid ja miinused, kirjeldab artikkel Staatilised veebisaidid: vähem PHP-d, väiksem ründepind.
Vastupidi, poodide, portaalide või paljude toimetajatega veebisaitide jaoks ei ole see enamasti valik. Siin jääb dünaamiline süsteem mõistlikuks ja turvalisus tekib hoolduse, karastamise ja jälgimisega.
Kes ei ole kindel, kas vanas WordPressis varitseb veel peidetud ligipääse, leiab artiklist Tagauste leidmine WordPressis tüüpilised leiukohad. See aitab ka otsustada, kas puhastamine on realistlik.
Kuidas PHP SOS konkreetselt aitab?
- Selgitame kõigepealt sissemurdmise põhjuse ja ütleme teile, kas see asub CMS-is või protsessis ja serveris.
- Puhastame olemasoleva süsteemi pahavara eemaldamise raames või valmistame selle ette tõendina uuesti ülesehitamiseks.
- Vahetuse korral kontrollime üle võetavat sisu ja meediat kahjuliku koodi suhtes enne, kui see uude süsteemi jõuab.
- Seadistame uue serveri paigatud PHP ja karastatud konfiguratsiooniga.
Kokkuvõte
CMS-i vahetus pärast häkkimist on harva lahendus, kuid vahel õige põhjus. Kui vana süsteemi enam ei hooldata, tasub uus algus. Kui põhjus oli protsessides või serveris, annab töö protsessiga rohkem kui uus logo. Mõlemal juhul kehtib: esmalt kontrollida, siis üle kolida.
Korduma kippuvad küsimused
Kas CMS-i vahetus aitab PHP2Shelli vastu?
Ei, kui uus CMS töötab samuti PHP peal. PHP2Shell asub PHP interpretaatoris, mitte CMS-is. Otsustav on PHP paigaseis serveril, mitte süsteem selle peal.
Kas WordPress on ebaturvalisem kui teised CMS-id?
Üldiselt seda öelda ei saa. Paljud sissemurdmised tekivad vananenud laienduste, nõrkade ligipääsude või puuduvate uuenduste tõttu ja need põhjused esinevad igas süsteemis. Levik teeb CMS-ist siiski sagedasema automatiseeritud skannimiste sihtmärgi.
Kas ma saan sisu häkitud CMS-ist lihtsalt eksportida?
Ainult pärast kontrolli. Andmebaas võib sisaldada sisse toodud skripte, peidetud linke või võõraid administraatorikontosid. Üleslaaditud failid võivad kahjulikku koodi varjata. Eksportige sisu sihipäraselt ja kontrollige seda enne importi.
Millal on CMS-i vahetus tõesti mõistlik?
Kui tootja ei tarni enam turvauuendusi, kui veebisait sõltub laiendustest, mida enam ei hooldata, või kui süsteem lihtsalt ei sobi enam tänapäevaste nõuetega. Häkkimine on siis põhjus, mitte põhjendus.