Jak opravit nakažený Drupal? Uzdravení nejenom po Drupalgeddon 2

Letos vyšly hned dvě po sobě následující kritické bezpečnostní aktualizace pro Drupal umožňující jeho napadení zvenčí. Automatizované útoky probíhají a pokud jste včas neaktualizovali, pravděpodobně nyní řešíte, jak web uzdravit. Zde jsou moje tipy.

Celé řadě klientů, kterým jsem vyrobil web, se starám i o pravidelné bezpečnostní aktualizace. Weby kontroluji, instaluji aktualizace, opravuji potřebné. Ale pak jsou klienti, kteří po mě tuto službu nechtějí.

Důvody jsou různé. Někdy je to prostě cena, byť je to zlomek ceny celého webu. Jindy jakási podivná laxnost. Uznávám, že někdy i moje neschopnost jim jako laikům takovou investici do pravidelné kontroly webu vysvětlit a obhájit. Nejčastěji zmiňuji aktualizace v telefonech a operačních systémech jako příklad, že se tomu člověk dnes nevyhne nikde. Vlastně ani u webu napsaného na míru, pokud používá knihovny třetích stran.

Po aktualizacích na Drupal 7.58 a 7.59, resp. poté, co je někteří klienti nechtěli ani přes moje důrazné varování, je samozřejmě většina neošetřených webů nakažena. Řadu napadených webů jsem v minulosti léčil, ale tady mě zaráží, jak moc je to lidem jedno. Ona vlastně těžba kryptoměny nebo posílání spamu není bezprostřední projev a není při návštěvě webu na očích, takže asi proč se tím zabývat.

Nicméně dnes jsme na jednom takovém firemním webu „vyhráli“ v neexistující soutěži mobilní telefon. To už by mohl být projev nákazy, který klienta chladným nenechá. Žel bohu oprava je o dost pracnější a tím pádem dražší než prevence. Jako u člověka se špatnou životosprávou.

Léčíme nakažený Drupal

Jestliže jste se také dostali, možná ne svou vinou, do situace, kdy je váš Drupal nakažený, mohly by vám pomoci následující řádky. Chtěl bych se podělit o postup opravy napadeného Drupalu, který obvykle praktikuji. Budiž inspirací pro ty z vás, kdo se do toho chtějí pustit svépomocí.

Jak poznáte napadený Drupal? Nejčastěji je změněn index.php, často se objeví v kořenové složce a jednotlivých podsložkách řada PHP souborů navíc, které tam nepatří. Někdy mají nesmyslný název, jindy naopak dostatečně nenápadný (admin.php, users.php). Vždy ale obsahují škodlivý kód, nejčastěji zakomponovaný pomocí funkce base64_decode().

index.php napadeného Drupalu 7

Když se musím s takovou nákazou poprat, volím následující postup:

Poctivě zkontrolujte a projděte všechny body. Stačí jeden zapomenutý PHP soubor s nenápadným názvem a útočník si pro sebe opět otevře cestičku.

Možná vás napadne, proč všechno zbytečně mažu a přepisuji, místo toho, abychom jenom odstranil nepatřičné či změněné soubory. Smazání je prostě jednodušší a rychlejší cesta. A pozor. Nestačí jen přepis. Některé programy pro přenos souborů totiž při přepisu složky nesmažou její původní obsah, ale jenom jednotlivé soubory, přičemž v cílovém umístění ponechávají ty nepřepisované. A obvykle nakažené.

A jak se léčí Drupal 8?

Zasvěcení asi pochopili, že výše popsaný postup se týká hlavně Drupalu 7. S jeho nákazou kvůli nepravidelným aktualizacím se setkávám nejčastěji. Pro Drupal 8 platí podobná pravidla. Jen samozřejmě složky jsou jiné.

Moduly a témata vzhledu máme přímo v kořenové složce. Věci z jádra jsou ve složce core. Navíc je tu složka vendor, která obsahuje doplňkové PHP knihovny. Tu byste rovněž měli zkontrolovat, resp. smazat stávající a nakopírovat pro jistotu znovu stažené projekty. Ručně, či přes composer.

Nezapomínejte na server

Držím vám palce, aby výše uvedený postup pomohl. Pokud přijdete na něco, co by bylo ještě dobré provést, přidejte tip i pro ostatní do komentářů pod článkem. Napadá mě například kontrola webu nějaký nástrojem typu Sucuri SiteCheck.

Při léčbě webu s Drupalem nezapomínejte ani na další vlivy. Někdo se může urputně věnovat opravě webu, ale přitom má na serveru řadu bezpečnostních trhlin v jeho programovém vybavení.

Párkrát se mi stalo, že jsme opakovaně opravovali napadený Drupal a nákaza se vždy objevila znovu. Na vině nakonec byla chyba v PHP na Debianu. Stačilo spustit aktualizaci systému, web znovu vyléčit a tentokrát byla léčba definitivní.

Je to přitom poměrně častá záležitost. Spousta serverů má z různých důvodů neaktualizované verze PHP (a bez záplat). Schválně, znáte tabulku životnosti jednotlivých verzí PHP? Jak je na tom ta vaše?

Buďme ve spojení, přihlaste se k newsletteru

Odesláním formuláře souhlasíte s podmínkami zpracováním osobních údajů. 
Více informací v Ochrana osobních údajů.

Autor článku: Jan Polzer

Tvůrce webů z Brna se specializací na Drupal, WordPress a Symfony. Acquia Certified Developer & Site Builder. Autor několika knih o Drupalu.
Web Development Director v Lesensky.cz. Ve volných chvílích podnikám výlety na souši i po vodě. Více se dozvíte na polzer.cz a mém LinkedIn profilu.

Komentáře k článku

návštěvník

Doporučil bych pro kontrolu modul Hacked a Diff, u vlastních modulů pak jednoduše přes GIT porovnat se zálohou.

Profile picture for user Jan Polzer

Dík, dobrý nápad, který by mohl zrychlit kontrolu modulů a ušetřit tak čas strávený přepisováním všeho. Sleduje to jenom změněné nebo i přidané soubory? Podle screenshotu jsou vidět jenom změny o changed a deleted, nic o tom, že by byl zmíněn přidaný soubor.

návštěvník

Databázi tedy vůbec neřešíte?

Přidat komentář

Odesláním komentáře souhlasíte s podmínkami Ochrany osobních údajů

reklama
Moje kniha o CMS Drupal

 

Kniha 333 tipů a triků pro Drupal 9


Více na KnihyPolzer.cz

Sledujte Maxiorla na Facebooku

Maxiorel na Facebooku

Poslední komentáře
Hosting pro Drupal a WordPress

Hledáte český webhosting vhodný nejenom pro redakční systém Drupal? Tak vyzkoušejte Webhosting C4 za 1200 Kč na rok s doménou v ceně, 20 GB prostoru a automatické navyšováním o 2 GB každý rok. Podrobnosti zde.

@maxiorel na Twitteru

Maxiorel na Twitteru