Ukratko: Promjena CMS-a nakon hakiranja pomaže samo ako je stari sustav sam bio uzrok, primjerice jer proizvođač više ne isporučuje sigurnosna ažuriranja ili se važna proširenja više ne održavaju. Ako je uzrok bio u zastarjelim dodacima, slabim pristupima ili ranjivosti poput PHP2Shella u PHP-u ispod, promjena samo premješta trud. U svakom slučaju vrijedi: sadržaje najprije provjeriti, tek onda preseliti, inače zlonamjerni kod putuje s njima.
Kad povjerenja više nema
Nakon provale raspoloženje je često jednoznačno: „S ovim sustavom nikad više.“ To je razumljivo. Web-stranica je preusmjeravala posjetitelje na strane stranice, Google je upozorio, klijenti su se raspitivali. Novi CMS djeluje kao novi početak.
Situacija oko PHP2Shella ipak pokazuje zašto taj refleks može zavesti. Ranjivost je u PHP interpreteru, a ne u WordPressu, TYPO3-u, Shopwareu ili drugom sustavu. WordPress.org prema drweb.de zato ne planira vlastito ažuriranje protiv nje. Tko sada prijeđe s jednog PHP CMS-a na drugi PHP CMS, na kraju ima istu ovisnost, samo s drugim logotipom. Koji sustavi rade na PHP-u, pokazuje pregled Koji CMS-ovi i shop sustavi rade na PHP-u.
Uzrok odlučuje
Prije nego što razmislite o promjeni, mora se razjasniti uzrok provale. Tipični ulazi su zastarjela proširenja, lozinke koje se višekratno koriste ili su slabe, nedostatak dvofaktorske prijave, nezakrpan poslužitelj ili zaboravljene testne instalacije. Nijedan od tih uzroka nije vezan uz određeni CMS.
Tko uzrok ne zna, riskira da ga ponese u novi sustav. Tim koji je dosad odgađao ažuriranja činit će to i u novom CMS-u. Agencija koja je koristila zajedničke administratorske račune ponovit će to ako nitko ne promijeni postupak. Pitanje dakle nije toliko „koji CMS?“, nego „koji proces?“.
Promjena CMS-a nakon hakiranja: odvagivanje
| Kriterij | Ostati na postojećem CMS-u i ojačati ga | Prijeći na drugi CMS |
|---|---|---|
| Uzrok provale | Poznat i otklonjiv, primjerice zastarjeli dodatak | Leži u samom sustavu, primjerice nedostatak ažuriranja proizvođača |
| Održavanje proizvođača | Sigurnosna ažuriranja se isporučuju | Proizvođač je obustavio održavanje |
| Ovisnost o proširenjima | Malo, održavanih proširenja | Mnogo proširenja bez aktivnog održavanja |
| Trud | Čišćenje, ojačavanje, promjena procesa | Ponovna izgradnja, migracija, obuka, često novi dizajn |
| Vrijeme do sigurne web-stranice | Kraće | Duže, potrebno prijelazno rješenje |
| Zaštita od PHP ranjivosti | Bez promjene, PHP se mora zakrpati | Bez promjene, dok god novi sustav koristi PHP |
| Dugoročna korist | Velika, ako se procesi poboljšaju | Velika, ako je stari sustav ionako bio na kraju |
Ako većina redaka u Vašoj situaciji završi lijevo, promjena se jedva isplati. Ostati, očistiti, ojačati i poboljšati tijek održavanja donosi više sigurnosti za manje novca. Za operatere WordPressa najvažnije korake sažima WordPress i PHP2Shell.
Za tu odluku pružatelj usluga nije Vam uvijek potreban. Ako je uzrok bio jednoznačan, primjerice poznat dodatak s objavljenom ranjivošću, a Vaša agencija ili administrator uredno su iznova postavili web-stranicu, možete sami odlučiti. Vanjska pomoć isplati se ako uzrok ostane nejasan ili bi mogli biti pogođeni osobni podaci.
Ako mijenjate: zlonamjerni kod ne ponijeti sa sobom
Ako se odluka donese za promjenu, sama je migracija sigurnosni rizik. Napadači tragove ne ostavljaju samo u datotekama, nego i u bazi podataka. Ovi koraci pomažu uredno preseliti:
- Stari sustav osigurati i izolirati: Potpuna sigurnosna kopija kao dokaz, zatim stari sustav skinuti s mreže ili ga učiniti dostupnim samo interno.
- Sadržaje izvesti ciljano: Tekstove, strukturu stranica i medije, a ne cijelu bazu podataka. Korisničke račune ne preuzimati, nego ih iznova izraditi.
- Provjeriti sadržaje: Tekstove pregledati na ubačene skripte, skrivene poveznice i strana preusmjeravanja. Kako, opisuje Provjera baze podataka na ubačeni kod.
- Filtrirati medije: Preuzeti samo očekivane vrste datoteka, odbaciti datoteke s dvostrukim nastavcima ili sadržajem skripte.
- Novi sustav postaviti uredno: Iz izvornog izvora proizvođača, na poslužitelju sa zakrpanim PHP-om, s novim pristupnim podacima i dvofaktorskom prijavom.
- Planirati preusmjeravanja: Stare adrese preusmjeriti na nove da tražilice i posjetitelji stignu, a da stari putovi ne ostanu otvoreni.
Promjena CMS-a ne zamjenjuje čišćenje starog poslužitelja. Ako stari sustav i dalje radi, primjerice kao zaboravljena kopija na poddomeni, stražnja vrata ostaju otvorena.
Alternativa koja se često previđa
Neke tvrtke nakon hakiranja utvrde da funkcije velikog CMS-a uopće ne trebaju. Web-stranica tvrtke s nekoliko stranica koje se rijetko mijenjaju može i bez PHP-a na poslužitelju. Generator statičnih stranica izrađuje gotove HTML datoteke koje više ne trebaju poslužiteljsku programsku logiku. Koje prednosti i nedostatke to ima, opisuje Statične web-stranice: manje PHP-a, manja napadna površina.
Obrnuto, za shopove, portale ili web-stranice s mnogo urednika to najčešće nije opcija. Tu dinamički sustav ostaje smislen, a sigurnost nastaje održavanjem, ojačavanjem i nadzorom.
Tko nije siguran vrebaju li u starom WordPressu još skriveni pristupi, tipična mjesta nalaza pronalazi u članku Pronalaženje stražnjih vrata u WordPressu. To pomaže i pri odluci je li čišćenje realno.
Kako PHP SOS konkretno pomaže?
- Najprije razjašnjavamo uzrok provale i kažemo Vam leži li u CMS-u ili u procesu i poslužitelju.
- Postojeći sustav čistimo u okviru uklanjanja zlonamjernog softvera ili ga pripremamo kao dokaz za ponovnu izgradnju.
- Kod promjene provjeravamo sadržaje i medije koji se preuzimaju na zlonamjerni kod prije nego što dođu u novi sustav.
- Novi poslužitelj postavljamo sa zakrpanim PHP-om i ojačanom konfiguracijom.
Zaključak
Promjena CMS-a nakon hakiranja rijetko je rješenje, ali ponekad pravi povod. Ako se stari sustav više ne održava, novi početak se isplati. Ako je uzrok bio u procesima ili na poslužitelju, rad na procesu donosi više od novog logotipa. U oba slučaja vrijedi: najprije provjeriti, tek onda preseliti.
Česta pitanja
Pomaže li promjena CMS-a protiv PHP2Shella?
Ne, dok god novi CMS također radi na PHP-u. PHP2Shell je u PHP interpreteru, a ne u CMS-u. Odlučujuće je stanje zakrpe PHP-a na poslužitelju, a ne sustav iznad njega.
Je li WordPress nesigurniji od drugih CMS-ova?
Ne može se reći paušalno. Mnoge provale nastaju zbog zastarjelih proširenja, slabih pristupa ili nedostajućih ažuriranja, a ti uzroci postoje u svakom sustavu. Raširenost ipak čini CMS češćom metom automatiziranih skeniranja.
Mogu li sadržaje iz hakiranog CMS-a jednostavno izvesti?
Samo nakon provjere. Baza podataka može sadržavati ubačene skripte, skrivene poveznice ili strane administratorske račune. Učitane datoteke mogu prikrivati zlonamjerni kod. Sadržaje izvozite ciljano i provjerite ih prije uvoza.
Kada je promjena CMS-a doista smislena?
Ako proizvođač više ne isporučuje sigurnosna ažuriranja, ako se web-stranica oslanja na proširenja koja se više ne održavaju ili ako sustav jednostavno više ne odgovara današnjim zahtjevima. Hakiranje je tada povod, a ne razlog.