Drupalgeddon a Site Audit: proklepněte si svůj web

Po nedávné bezpečnostní hrozbě v Drupalu jste možná urychleně provedli aktualizaci, možná jste řešili změněné přístupové heslo a napadený web. Možná jste vše uvedli do zdánlivého normálu. Jste si jisti? Zkuste si web proklepnout dvojicí nástrojů pro drush.

Reklama

Před necelými dvěma týdny jsem tu psal o nástroji Drush, který vám umožňuje ovládat Drupal z příkazové řádky. Kromě toho, že lze s jeho pomocí pracovat s jádrem Drupalu a moduly, nabízí vám i další funkce prostřednictvím rozšiřujících nástrojů. Patří mezi ně i bezpečnostní pomůcky Drupalgeddon a Site Audit, které prověří zabezpečení vašeho webu s Drupalem.

Nedávná bezpečnostní hrozba (viz Svět CMS) umožnila vniknout anonymním útočníkům do jakéhokoli webu s Drupalem 7 pomocí SQL injektáže. Vznikly automatizované útoky a aktuální bezpečnostní zpráva Drupalu hovoří o tom, že kdo svůj web neaktualizoval zhruba do sedmi hodin od nahlášení a opravy chyby, hodně riskoval (nebo ještě riskuje).

Já sám jsem to pocítil v jednom případě na vlastní kůži (nikoli ovšem na Maxiorlovi), v několika případech u webů svých klientů, kteří nechtěli provádět aktualizace (důvody nerozebírejme, jsou ve výsledku všechny špatné, jak se bohužel přesvědčili).

Všechny nakažené weby, které jsem v poslední době viděl, měly něco společného – změněný přístup k uživatelskému účtu hlavního administrátora, web byl předělán na stroj k rozesílání spamu a někdy došlo k úpravám některých souborů.

Je nutné si uvědomit, že u nakaženého webu nemusí stačit jeho aktualizace na Drupal 7.32. Útočníci si teoreticky mohli nechat zadní vrátka v databázi nebo v některých dalších souborech, které při aktualizaci nepřepíšete.

Právě s bezpečnostním auditem chce pomoci nástroj Drupalgeddon. Jak jeho tvůrci upozorňují, nejedná se o stoprocentní kontrolu, zda je web skutečně vyléčen, ale minimálně na ty nejtypičtější bezpečnostní problémy vás upozorní. Na stránce Drupalgeddonu najdete i graf s postupem toho, co Drupalgeddon provádí a kontroluje.

Drupalgeddon funguje samostatně, nebo ve spojení s jiným nástrojem – Site Audit. Oba se spouštějí přes příkazový řádek, ani jeden z nich není běžný modul pro Drupal a oba nabízejí výstup do HTML. Pokud spustíte Site Audit s nainstalovaným Drupalgeddonem, jeho výstup se připojí do výstupu Site Auditu.

Instalujeme Drupalgeddon a Site Audit

V první řadě potřebujete mít přístup k příkazovému řádku serveru, na kterém běží váš web. Pozé zde musíte zprovoznit Drush, o kterém jsem psal podrobněji v článku Drush: pomůcka nejenom pro rychlé aktualizace v Drupalu.

Následně ve složce svého webu spusťte tyto jednotlivé příkazy:

  • drush dl site_audit
  • drush dl drupalgeddon
  • drush cache-clear drush
  • drush asec

Poslední uvedený příkaz již spustí základní audit a zobrazí jeho výsledky na obrazovku terminálu.

Drupalgeddon

Výstupy bezpečnostního auditu Drupalu

Základní příkaz pro spuštění auditu, drush asec, zobrazí jen málo informací. Mnohem podrobnější zprávu získáte použitím jiného přepínače. Kompletní dokumentace je popsána v readme k Site Auditu. Tam se rovněž dočtete, že lze výstup lépe zformátovat, zobrazit si více údajů a samozřejmě jej exportovat do HTML souboru.

Výsledný příkaz, který používám já, je následující. Zobrazí maximum informací, které uloží do souboru HTML v domovském adresáři. HTML je zformátováno pomocí Twitter Bootstrapu.

drush aa –html –detail –bootstrap  > ~/report.html

Výstup vypadá nějak takto (je velice dlouhý):

Site Audit

Jak vidíte na reportu z Maxiorla, ne vše zde mám vyladěno, jak by mohlo být. V záhlaví jsou uvedena jednotlivá kritéria hodnocení v auditu, procenty a barvou je naznačeno jejich splnění. Klepnutím na tlačítko se posunete na konkrétní místo reportu.

Ne ve všem má Site Audit pravdu. Například mu vadí, že nemám zapnuté standardní cacheování pro anonymní uživatele, ale už nezjistil, že to řeším modulem Authcache. Zapnout obojí, Drupal by hlásil konflikt.

Ale vidím, že používám asi příliš mnoho doplňkových modulů, byť to je docela relativní pojmem. U databáze najdu informace o tabulkách, které nemají správné řazení s UTF-8. V analýze logu mohu například zjistit, že je zde 48 případů s nenalezenou stránkou. U některých Views jsem pro změnu nezapnul cacheování, ale nemyslím si, že by to mělo dopad, jelikož používám zmíněný Authcache.

Co se týče bezpečnosti, Drupalgeddon nalezl několik podezřelých souborů, což je ostatně vidět i na prvním screenshotu v tomto článku. Není tedy od věci je prověřit. V mém případě jsou zde tyto PHP soubory záměrně a neškodí, ale podobným způsobem se mohou ve vaší instalaci objevit nic neříkající PHP soubory se škodlivým kódem.

Site Audit i Drupalgeddon je tedy potřeba používat s rozmyslem, ale minimálně je dobré si jej občas spustit a popřemýšlet nad tím, co na svém webu můžete z hlediska výkonu a především zabezpečení udělat lépe.

Poznámka: Drupalgeddon můžete spustit i na webu, na kterém nemáte Drush, a to díky českému vývojáři Martinu Klímovi a jeho projektu Drupageddon Tester. Projekt je v sandboxu a stáhnout si jej můžete následujícím příkazem. Za upozornění díky Ivo Grossovi.

git clone –branch 7.x-1.x http://git.drupal.org/sandbox/martin_klima/test_drupageddon.git test_drupageddon

Reklama

Komentáře

Zdravím Vás pán Polzer!
Mne webhosting nepovoluje Drush. Skontroloval som web pomocou modulov Hacked!, MD5 Check, Security Review. Ešte som vymazal, a nahral nové moduly. Našiel som dva súbory v module ctools ktoré tam v originály neboli.Avšak neviem či to je dostačujúce. Umňa sa to chovalo tak, že my vytvaral falošných uživateľov a rozosielal poštu. Tak mi webhosting vypol php mail. Teraz to nerobi.

TOTO MY NAPISAL WEBHOSTING:
"A funkciu mail sme Vam museli znova zablokovat kedze ste zaplnili frontu na webovom serveri.

173.243.112.148 – – [25/Oct/2014:18:09­:55 +0200] „GET /node/2052 HTTP/1.1“ 404 7912 173.243­.112.148 – – [25/Oct/2014:18:09­:56 +0200] „GET /?q=user HTTP/1.1“ 200 27266 173­.243.112.148 – – [25/Oct/2014:18:09­:57 +0200] „GET /?q=user HTTP/1.1“ 200 27266

146.185.239.52 – – [25/Oct/2014:18:13­:19 +0200] „POST /sites/all/mo­dules/ctools/pa­ge_manager/the­me/stats.php HTTP/1.1“ 200 –

toto mate v access logoch vyzera koa kebyze nieto registruje novych uzivatelov a spamuje z daneho scriptu."

TOTO MY PORADILI NA DRUPAL.SK:
ses hacknutej… souvisi to s tim proc je vydana verze 7.32. Vybodnul ses na zaplatovani tak mas problem. musis to zaplatovat. Soubor smazat. pomoci „git status“ prikazu najdi soubory ktere tam jsou navic. pak projdi tabulku menu_router hledej access_callback = file_put_contents. vice viz clanek tady nma homepage a jeho diskuse.

------------------------------------

Tabulku menu_router som pozrel, ale spomínaný príkaz som nenašiel.

Myslíte že by to bolo ok? Ako by ste ešte skontrolovali databázu?
Ďakujem za odpoveď.

Tak pokud to tam už není, tak snad OK. Jistotu Vám samozřejmě dá až to, jak se bude web dále chovat. Pokud už byl hacknutý, je to vždycky problém.

Tvořím weby. Nabízím poradenství pro Drupal. Jsem na Twitteru.

Ja mám malý web. Bude najlepšie ak sformátujem ftp a vymžem db. Potom, je tiež ešte web v ohrození? Eliminujem takto tento problém na najmenšiu hodnotu?
Ďakujem za Váš názor a čas.

No, když smažete FTP a databázi, tak zrušíte celý web, nebude tedy nic, v čem by mohla zůstat jeho nákaza :) (Co je na serveru jako takovém je jiná věc)

Tvořím weby. Nabízím poradenství pro Drupal. Jsem na Twitteru.

A s tym servrom ste to ako mysleli? Mohol sa tam niekde skrit skriatok? Dakujem

Jo, skřítci žijí v městečku s polovodičů, tišťáku a kondenzátorů ;-) Ne vážně, myslel jsem to tak, že případně by se při špatnmém zabezpečení serveru mohl někdo dostat mimo složku webové aplikace a tam páchat škody, ale tipuju, že máte web na hostingu, kde si to ošetřili.

Tvořím weby. Nabízím poradenství pro Drupal. Jsem na Twitteru.

Přidat komentář