Trumpai: CMS keitimas po įsilaužimo padeda tik tuomet, kai pati sena sistema buvo priežastis, pavyzdžiui, kai gamintojas nebeteikia saugumo atnaujinimų arba svarbūs plėtiniai nebeprižiūrimi. Jei priežastis buvo pasenę papildiniai, silpnos prieigos ar spraga, kaip PHP2Shell, po apačia esančiame PHP, keitimas tik perkelia darbą. Bet kuriuo atveju galioja: turinį pirmiausia patikrinti, tik tada perkelti, kitaip kenkėjiškas kodas keliauja kartu.
Kai pasitikėjimas dingęs
Po įsilaužimo nuotaika dažnai vienareikšmė: „su šia sistema daugiau niekada.“ Tai suprantama. Svetainė nukreipė lankytojus į svetimus puslapius, „Google“ įspėjo, klientai teiravosi. Naujas CMS atrodo kaip naujas pradžia.
Tačiau situacija aplink PHP2Shell parodo, kodėl šis refleksas gali klaidinti. Spraga yra PHP interpretatoriuje, o ne WordPress, TYPO3, Shopware ar kitoje sistemoje. Todėl, pasak drweb.de, WordPress.org neplanuoja savo atnaujinimo prieš ją. Kas dabar iš vieno PHP CMS pereina į kitą PHP CMS, galiausiai turi tą pačią priklausomybę, tik su kitu logotipu. Kurios sistemos veikia su PHP, parodo apžvalga Kurios CMS ir parduotuvių sistemos veikia su PHP.
Lemia priežastis
Prieš galvodami apie keitimą, turite išsiaiškinti įsilaužimo priežastį. Tipinės įėjimo durys yra pasenę plėtiniai, pakartotinai naudojami ar silpni slaptažodžiai, trūkstamas dviejų veiksnių prisijungimas, nepataisytas serveris ar užmirštos bandomosios diegimo kopijos. Nė viena iš šių priežasčių nėra susieta su konkrečiu CMS.
Kas priežasties nežino, rizikuoja ją pasiimti į naują sistemą. Komanda, kuri iki šiol atidėdavo atnaujinimus, tą patį darys ir naujame CMS. Agentūra, naudojusi bendras administratoriaus paskyras, tai pakartos, jei niekas nepakeis eigos. Taigi klausimas ne „kuris CMS?“, o „koks procesas?“.
CMS keitimas po įsilaužimo: svarstymas
| Kriterijus | Likti prie esamo CMS ir sustiprinti | Pereiti prie kito CMS |
|---|---|---|
| Įsilaužimo priežastis | Žinoma ir pašalinama, pavyzdžiui, pasenęs papildinys | Slypi pačioje sistemoje, pavyzdžiui, trūksta gamintojo atnaujinimų |
| Gamintojo priežiūra | Saugumo atnaujinimai teikiami | Gamintojas nutraukė priežiūrą |
| Priklausomybė nuo plėtinių | Keli, prižiūrimi plėtiniai | Daug plėtinių be aktyvios priežiūros |
| Darbo sąnaudos | Valymas, sustiprinimas, proceso pakeitimas | Perkūrimas, migracija, mokymas, dažnai naujas dizainas |
| Laikas iki saugios svetainės | Trumpesnis | Ilgesnis, reikia pereinamojo sprendimo |
| Apsauga nuo PHP spragų | Jokių pokyčių, PHP turi būti pataisytas | Jokių pokyčių, kol naujoji sistema naudoja PHP |
| Ilgalaikė nauda | Didelė, jei patobulinami procesai | Didelė, jei sena sistema ir taip buvo pasiekusi pabaigą |
Jei daugelis eilučių jūsų situacijoje patenka į kairę, keitimas vargu ar verta. Likti, išvalyti, sustiprinti ir pagerinti priežiūros eigą duoda daugiau saugumo už mažiau pinigų. WordPress eksploatuotojams svarbiausius žingsnius apibendrina WordPress ir PHP2Shell.
Paslaugų teikėjo šiam sprendimui ne visada reikia. Jei priežastis buvo aiški, pavyzdžiui, žinomas papildinys su paskelbta spraga, o jūsų agentūra ar administratorius svetainę švariai sukūrė iš naujo, galite spręsti patys. Išorinė pagalba verta, kai priežastis lieka neaiški arba gali būti paveikti asmens duomenys.
Jei keičiate: kenkėjiško kodo neperkelti
Jei nusprendžiama keisti, pati migracija yra saugumo rizika. Užpuolikai pėdsakų palieka ne tik failuose, bet ir duomenų bazėje. Šie žingsniai padeda perkelti švariai:
- Seną sistemą išsaugoti ir izoliuoti: pilna kopija kaip įrodymas, tada seną sistemą atjungti nuo tinklo arba palikti pasiekiamą tik viduje.
- Turinį eksportuoti tikslingai: tekstus, puslapių struktūrą ir mediją, o ne visą duomenų bazę. Naudotojų paskyrų neperimti, o sukurti iš naujo.
- Patikrinti turinį: peržiūrėti tekstus dėl įterptų skriptų, paslėptų nuorodų ir svetimų nukreipimų. Kaip tai daroma, aprašo Duomenų bazės patikra dėl įterpto kodo.
- Filtruoti mediją: perimti tik numatytų tipų failus, failus su dvigubais plėtiniais ar skripto turiniu atmesti.
- Naują sistemą sukurti švariai: iš gamintojo originalaus šaltinio, serveryje su pataisytu PHP, su naujais prisijungimo duomenimis ir dviejų veiksnių prisijungimu.
- Suplanuoti nukreipimus: senus adresus nukreipti į naujus, kad paieškos sistemos ir lankytojai pasiektų tikslą, o seni keliai neliktų atviri.
CMS keitimas nepakeičia seno serverio valymo. Jei sena sistema toliau veikia, pavyzdžiui, kaip užmiršta kopija subdomene, užpakalinės durys lieka atviros.
Alternatyva, kuri dažnai nepastebima
Kai kurios įmonės po įsilaužimo supranta, kad didelio CMS funkcijų jiems apskritai nereikia. Įmonės svetainė su keliais puslapiais, retai keičiama, apsieina ir be PHP serveryje. Statinių puslapių generatorius sukuria paruoštus HTML failus, kuriems nebereikia serverio programinės logikos. Kokie to privalumai ir trūkumai, aprašo Statinės svetainės: mažiau PHP, mažesnis atakos paviršius.
Atvirkščiai, parduotuvėms, portalams ar svetainėms su daug redaktorių tai dažniausiai nėra variantas. Čia prasmingas lieka dinaminis sistema, o saugumas kyla iš priežiūros, sustiprinimo ir stebėsenos.
Kas netikras, ar senajame WordPress dar slypi paslėptų prieigų, tipines radimo vietas ras skyriuje Užpakalinių durų WordPress rasti. Tai padeda ir sprendžiant, ar valymas realistiškas.
Kaip PHP SOS padeda konkrečiai?
- Pirmiausia išsiaiškiname įsilaužimo priežastį ir pasakome, ar ji slypi CMS, ar procese ir serveryje.
- Esamą sistemą išvalome kenkėjiškos programinės įrangos šalinimo rėmuose arba paruošiame ją kaip įrodymą perkūrimui.
- Keičiant patikriname perimamą turinį ir mediją dėl kenkėjiško kodo, kol jie nepatenka į naują sistemą.
- Naują serverį sukuriame su pataisytu PHP ir sustiprinta konfigūracija.
Išvada
CMS keitimas po įsilaužimo retai yra sprendimas, bet kartais teisinga proga. Jei sena sistema nebeprižiūrima, naujas pradžia verta. Jei priežastis slypėjo procesuose ar serveryje, darbas su procesu duoda daugiau nei naujas logotipas. Abiem atvejais galioja: pirmiausia patikrinti, tik tada perkelti.
Dažni klausimai
Ar CMS keitimas padeda nuo PHP2Shell?
Ne, jei naujasis CMS taip pat veikia su PHP. PHP2Shell slypi PHP interpretatoriuje, o ne CMS. Lemia PHP pataisų būsena serveryje, o ne jos viršuje esanti sistema.
Ar WordPress mažiau saugus nei kiti CMS?
Apskritai to pasakyti negalima. Daug įsilaužimų atsiranda dėl pasenusių plėtinių, silpnų prieigų ar trūkstamų atnaujinimų, o šios priežastys būna kiekvienoje sistemoje. Tačiau paplitimas CMS paverčia dažnesniu automatizuotų skenavimų taikiniu.
Ar galiu tiesiog eksportuoti turinį iš įsilaužto CMS?
Tik po patikros. Duomenų bazėje gali būti įterptų skriptų, paslėptų nuorodų ar svetimų administratoriaus paskyrų. Įkelti failai gali maskuoti kenkėjišką kodą. Eksportuokite turinį tikslingai ir prieš importuodami jį patikrinkite.
Kada CMS keitimas iš tikrųjų prasmingas?
Kai gamintojas nebeteikia saugumo atnaujinimų, kai svetainė priklauso nuo plėtinių, kurie nebeprižiūrimi, arba kai sistema šiandieniniams reikalavimams tiesiog nebetinka. Tada įsilaužimas yra proga, o ne priežastis.