Īsi sakot: CMS maiņa pēc uzlaušanas palīdz tikai tad, ja pati vecā sistēma bija cēlonis, piemēram, ja ražotājs vairs nepiegādā drošības atjauninājumus vai svarīgi paplašinājumi netiek uzturēti. Ja cēlonis bija novecojuši spraudņi, vājas piekļuves vai nepilnība, kāda ir PHP2Shell, apakšā esošajā PHP, maiņa tikai pārbīda darbu. Jebkurā gadījumā ir spēkā: saturu vispirms pārbaudīt, tad pārcelt, citādi līdzi pārceļas ļaunprātīgais kods.
Kad uzticība ir zudusi
Pēc ielaušanās noskaņojums bieži ir viennozīmīgs: „Ar šo sistēmu nekad vairs.” Tas ir saprotami. Vietne ir pāradresējusi apmeklētājus uz svešām lapām, Google ir brīdinājis, klienti ir jautājuši. Jauns CMS šķiet kā jauns sākums.
Situācija ap PHP2Shell tomēr parāda, kāpēc šis refleks var maldināt. Nepilnība ir PHP interpretatorā, nevis WordPress, TYPO3, Shopware vai citā sistēmā. WordPress.org saskaņā ar drweb.de tāpēc neplāno savu atjauninājumu pret to. Kas tagad no viena PHP CMS pāriet uz citu PHP CMS, tam beigās ir tā pati atkarība, tikai ar citu logotipu. Kuras sistēmas darbojas uz PHP, parāda pārskats Kuri CMS un veikalu sistēmas darbojas uz PHP.
Kas bija cēlonis, to izšķir
Pirms domājat par maiņu, jāparedz ielaušanās cēlonis. Tipiskas ieejas vietas ir novecojuši paplašinājumi, atkārtoti izmantotas vai vājas paroles, trūkstoša divfaktoru pieteikšanās, neielāpots serveris vai aizmirstas testa instalācijas. Neviens no šiem cēloņiem nav piesaistīts konkrētam CMS.
Kas cēloni nezina, riskē to paņemt līdzi uz jauno sistēmu. Komanda, kas atjauninājumus līdz šim atlika, to darīs arī jaunajā CMS. Aģentūra, kas izmantoja kopīgus administratora kontus, to atkārtos, ja neviens nemaina norisi. Jautājums tātad ir mazāk „kurš CMS?”, bet „kurš process?”.
CMS maiņa pēc uzlaušanas: svēršana
| Kritērijs | Palikt pie esošā CMS un nostiprināt | Mainīt uz citu CMS |
|---|---|---|
| Ielaušanās cēlonis | Zināms un novēršams, piemēram, novecojis spraudnis | Atrodas pašā sistēmā, piemēram, trūkst ražotāja atjauninājumu |
| Ražotāja uzturēšana | Drošības atjauninājumi tiek piegādāti | Ražotājs uzturēšanu pārtraucis |
| Atkarība no paplašinājumiem | Daži, uzturēti paplašinājumi | Daudzi paplašinājumi bez aktīvas uzturēšanas |
| Pūles | Tīrīšana, nostiprināšana, procesa maiņa | Pārbūve, migrācija, apmācība, bieži jauns dizains |
| Laiks līdz drošai vietnei | Īsāks | Ilgāks, nepieciešams pagaidu risinājums |
| Aizsardzība pret PHP nepilnībām | Nekādu izmaiņu, PHP jāielāpo | Nekādu izmaiņu, kamēr jaunā sistēma izmanto PHP |
| Ilgtermiņa ieguvums | Augsts, ja procesi tiek uzlaboti | Augsts, ja vecā sistēma tāpat bija galā |
Ja jūsu situācijā lielākā daļa rindu iekrīt kreisajā pusē, maiņa gandrīz neatmaksājas. Palikt, iztīrīt, nostiprināt un uzlabot apkopes norisi dod vairāk drošības par mazāku naudu. WordPress uzturētājiem svarīgākos soļus apkopo WordPress un PHP2Shell.
Pakalpojumu sniedzējs šim lēmumam vajadzīgs ne vienmēr. Ja cēlonis bija viennozīmīgs, piemēram, zināms spraudnis ar publicētu nepilnību, un jūsu aģentūra vai administrators vietni ir kārtīgi uzstādījis no jauna, varat lemt paši. Ārēja palīdzība atmaksājas, ja cēlonis paliek neskaidrs vai varētu būt skarti personas dati.
Ja mainiet: neņemiet līdzi ļaunprātīgo kodu
Ja lēmums par maiņu ir pieņemts, pati migrācija ir drošības risks. Uzbrucēji atstāj pēdas ne tikai failos, bet arī datubāzē. Šie soļi palīdz pārcelt tīri:
- Veco sistēmu nodrošināt un izolēt: pilna rezerves kopija kā pierādījums, tad veco sistēmu atslēgt no tīkla vai padarīt sasniedzamu tikai iekšēji.
- Saturu eksportēt mērķtiecīgi: teksti, lapu struktūra un mediji, nevis visa datubāze. Lietotāju kontus nepārņemt, bet izveidot no jauna.
- Pārbaudīt saturu: pārskatīt tekstus uz ievadītiem skriptiem, slēptām saitēm un svešām pāradresācijām. Kā to darīt, apraksta Datubāzes pārbaude uz ievadītu kodu.
- Filtrēt medijus: pārņemt tikai gaidītos failu veidus, atlasīt failus ar dubultiem paplašinājumiem vai skriptu saturu.
- Jauno sistēmu uzstādīt tīri: no ražotāja oriģinālavota, serverī ar ielāpotu PHP, ar jauniem piekļuves datiem un divfaktoru pieteikšanos.
- Plānot pāradresācijas: vecās adreses pāradresēt uz jaunajām, lai meklētājprogrammas un apmeklētāji nonāk galā, neatstājot atvērtus vecos ceļus.
CMS maiņa neaizstāj vecā servera tīrīšanu. Ja vecā sistēma darbojas tālāk, piemēram, kā aizmirsta kopija apakšdomēnā, slēptā piekļuve paliek atvērta.
Alternatīva, ko bieži palaiž garām
Daži uzņēmumi pēc uzlaušanas konstatē, ka lielā CMS funkcijas viņiem vispār nav vajadzīgas. Uzņēmuma vietne ar dažām lapām, kas reti mainās, iztiek arī bez PHP serverī. Statisko lapu ģenerators veido gatavus HTML failus, kuriem vairs nav vajadzīga servera puses programmu loģika. Kādas ir priekšrocības un trūkumi, apraksta Statiskas vietnes: mazāk PHP, mazāka uzbrukuma virsma.
Un otrādi, veikaliem, portāliem vai vietnēm ar daudziem redaktoriem tā parasti nav iespēja. Šeit dinamiska sistēma paliek lietderīga, un drošība rodas no uzturēšanas, nostiprināšanas un uzraudzības.
Kas ir nedrošs, vai vecajā WordPress nav slēptu piekļuvju, tipiskas atrašanās vietas atradīs sadaļā Slēpto piekļuvju (backdoor) atrašana WordPress. Tas palīdz arī lēmumā, vai tīrīšana ir reālistiska.
Kā PHP SOS palīdz konkrēti?
- Mēs vispirms noskaidrojam ielaušanās cēloni un sakām jums, vai tas ir CMS, vai process un serveris.
- Mēs iztīrām esošo sistēmu ar ļaunprogrammatūras noņemšanu vai sagatavojam to kā pierādījumu pārbūvei.
- Maiņas gadījumā mēs pārbaudām pārņemamo saturu un medijus uz ļaunprātīgu kodu, pirms tie nonāk jaunajā sistēmā.
- Mēs uzstādām jauno serveri ar ielāpotu PHP un nostiprinātu konfigurāciju.
Secinājums
CMS maiņa pēc uzlaušanas reti ir risinājums, bet dažkārt pareizais iemesls. Ja vecā sistēma vairs netiek uzturēta, jaunais sākums atmaksājas. Ja cēlonis bija procesos vai serverī, darbs pie procesa dod vairāk nekā jauns logotips. Abos gadījumos ir spēkā: vispirms pārbaudīt, tad pārcelt.
Biežāk uzdotie jautājumi
Vai CMS maiņa palīdz pret PHP2Shell?
Nē, kamēr arī jaunais CMS darbojas uz PHP. PHP2Shell ir PHP interpretatorā, nevis CMS. Izšķirošs ir PHP ielāpa stāvoklis serverī, nevis sistēma virs tā.
Vai WordPress ir mazāk drošs nekā citi CMS?
Vispārīgi to nevar teikt. Daudzas ielaušanās rodas dēļ novecojušiem paplašinājumiem, vājām piekļuvēm vai trūkstošiem atjauninājumiem, un šie cēloņi ir katrā sistēmā. Izplatība tomēr padara CMS par biežāku automatizētas skenēšanas mērķi.
Vai varu saturu no uzlauztā CMS vienkārši eksportēt?
Tikai pēc pārbaudes. Datubāze var saturēt ievadītus skriptus, slēptas saites vai svešus administratora kontus. Augšupielādēti faili var maskēt ļaunprātīgu kodu. Eksportējiet saturu mērķtiecīgi un pirms importa pārbaudiet to.
Kad CMS maiņa tiešām ir lietderīga?
Ja ražotājs vairs nepiegādā drošības atjauninājumus, ja vietne ir atkarīga no paplašinājumiem, kas vairs netiek uzturēti, vai ja sistēma mūsdienu prasībām vienkārši vairs neder. Uzlaušana tad ir iemesls, nevis pamats.