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

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.

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ý):

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