Hlavní navigace

Hardening: webový aplikační firewall – modul ModSecurity

Michal Vymazal

V minulém dílu o hardeningu jsem popisoval jednoduchý implementační scénář pro „zodolnění“ konfigurace webového démona Apache v rámci šifrovaného provozu mezi serverem a klientem.

Doba čtení: 8 minut

Sdílet

Tento díl se bude věnovat další části hardeningu samotného web démona, a sice aplikačnímu firewallu.

V odborné literatuře se skutečně setkáte s označením Web Application Firewall (zkráceně WAF) a jedná se o velmi účinný nástroj pro potírání účinků škodlivého kódu jako například SQL injection, cross site scripting, Trojských koní, session hijacking apod. ModSecurity je volně dostupný web aplikační firewall (WAF), který umí pracovat s webovými démony Apache, Nginx a IIS. Jeho jádro umí načíst konfigurační pravidla, která nazýváme Core Rule Set (CRS). V případě Apache se jedná o samostatný modul, jehož instalace, konfigurace a vlastní zprovoznění nejsou nijak komplikované.

Vážné zájemce o podrobný popis ModSecurity si dovolím odkázat na ModSecurity Handbook.

Instalace

Vlastní instalaci můžete provést několika způsoby:

  • z domovské stránky projektu (www.modsecurity.org). Budete muset stáhnout a přeložit tzv. „zdrojové balíčky“
  • stažení a překlad zdrojových balíků z datového úložiště (repository) vaší linuxové distribuce
  • instalace binárních balíků z úložiště vaší linuxové distribuce

Všechny tři výše uvedené způsoby jsou samozřejmě popsány ve výše uvedeném ModSecurity Handbook, dále budu popisovat instalaci z binárních balíčků pro distribuci Ubuntu 18.04 LTS 64bitová verze.

Nejdříve zkontrolujeme, zda náš operační systém má nainstalovány aktuální verze všech balíků:

# sudo apt clean
# sudo apt update
# sudo apt upgrade

Pokud nemáme nainstalován vlastní webový server, provedeme instalaci webového serveru.

# sudo apt install apache2

Možná spíše uvítáte instalaci celého LAMP serveru:

Root obecný tip

# sudo apt install apache2 mysql-server php libapache2-mod-php php-mysql

Nyní spusťte vlastního démona apache:

# sudo systemctl start apache2

Ujistěte se, že apache bude nabíhat vždy po startu systému (boot), což můžete zajistit například takto:

# sudo systemctl enable apache2

Nyní můžeme přikročit k vlastní instalaci modulu ModSecurity:

# sudo apt install libapache2-mod-security2

Zkontrolujeme, že se ModSecurity v pořádku nainstaloval a že běží:

# sudo apachectl -M |grep security

Pokud je vše v pořádku, měli bychom vidět toto:

security2_module (shared)

Vlastní ModSecurity je nainstalován a běží. Zatím však nemá žádná CRS (Core Rule Set) pravidla, takže je vlastně nečinný. Tato pravidla můžeme zadat třemi způsoby:

  • doinstalujeme balíček modsecurity-crs
  • doinstalujeme aktuální CRS pravidla z úložiště projektu (git)
  • vytvoříme pravidla ručně

Pro první „okoukání“ pravděpodobně vystačíte s balíčkem modsecurity-crs, později budete kombinovat všechny tři výše uvedené možnosti.

Balíček modsecurity-crs

Instalace binárního balíčku je jednoduchá:

# sudo apt install modsecurity-crs

Pokud je balík nainstalován, můžete si vyvolat jeho nainstalovanou verzi (a zejména aktuální informace o této verzi) takto:

# sudo dpkg -s modsecurity-crs
Package: modsecurity-crsStatus: install ok installed
Priority: extra
Section: universe/httpd
Installed-Size: 675
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: all
Version: 3.0.2-1
Recommends: libapache2-mod-security2 (>= 2.8.0)
Suggests: lua, geoip-database-contrib, ruby, python
Conffiles:
/etc/modsecurity/crs/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf 51a696f7414b75ab51ad2a9d74724226
/etc/modsecurity/crs/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf d8e87ff1edca68b7131f89bb05afb59e
/etc/modsecurity/crs/crs-setup.conf 6a6b8f6d739d4c09bb7563f960863cd7
…………..
Monitoring.
Original-Maintainer: Alberto Gonzalez Iniesta <agi@inittab.org>
Homepage: http://www.modsecurity.org

a pro vlastní ModSecurity

# dpkg -s libapache2-mod-security2
Package: libapache2-mod-security2
Status: install ok installed
Priority: optional
Section: universe/httpd
Installed-Size: 1059
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: amd64
Source: modsecurity-apache
Version: 2.9.2-1
Depends: libxml2 (>= 2.9.0), libapr1 (>= 1.2.7), libaprutil1 (>= 1.4.0), libc6 (>= 2.14), libcurl3-gnutls (>= 7.16.2), liblua5.1-0, libpcre3, liby
ajl2 (>= 2.0.4), apache2-api-20120211, apache2-bin (>= 2.4.16)
Recommends: modsecurity-crs
Conffiles:
/etc/apache2/mods-available/security2.conf c54309e1dbaf42fdddbb123e27ffd88c
/etc/apache2/mods-available/security2.load 8c18b901d8cef4c2b8a9834aba5ba224
/etc/modsecurity/modsecurity.conf-recommended 8f54d3a4335870a9b581e8abe5612532
/etc/modsecurity/unicode.mapping 2acb488d5a38983c3dd74a718c78da2e
………………….
Original-Maintainer: Alberto Gonzalez Iniesta <agi@inittab.org>
Homepage: http://www.modsecurity.org/

Konfigurace

Nejprve bude třeba zajistit, aby vlastní ModSecurity uměl „natáhnout“ veškerá pravidla aplikačního firewallu. Do konfiguračního souboru /etc/apache2/mods-enabled/security2.conf tedy přidáme cesty na adresáře s příslušnými CRS, obsah souboru by pak měl vypadat nějak takto:

# cat /etc/apache2/mods-enabled/security2.conf
<IfModule security2_module>
        # Default Debian dir for modsecurity's persistent data
        SecDataDir /var/cache/modsecurity

        # Include all the *.conf files in /etc/modsecurity.
        # Keeping your local configuration in that directory
        # will allow for an easy upgrade of THIS file and
        # make your life easier
        IncludeOptional /etc/modsecurity/*.conf

        # Include OWASP ModSecurity CRS rules if installed
        IncludeOptional /usr/share/modsecurity-crs/owasp-crs.load
</IfModule>

A ještě upravíme soubor  /etc/modsecurity/modsecurity.conf, kde upravíme parametr SecRuleEngine  na hodnotu

SecRuleEngine DetectionOnly

Později tento parametr přepíšeme na hodnotu

SecRuleEngine On

Nyní ale potřebujeme ModSecurity vyladit tak, aby „nezadrhával“ činnost našich vlastních aplikací a k tomu se napřed potřebujeme podívat, zda některá CRS pravidla nejsou v kolizi s činností našich aplikací, tyto kolize budeme řešit později.

Povolení pravidel (modsecurity-crs)

Instalaci balíčku modsecurity-crs jsme si popsali již výše. Pokud chcete používat skutečně ta nejaktuálnější pravidla, pak je můžete stahovat přímo z git (vepište celý příkaz na jeden řádek)

# git clone https://github.com/SpiderLabs/owasp-modsecurity-crs

Tušíte správně, že jednotlivá CRS pravidla jsou navržena tak, aby splňovala požadavky OWASP Application Security Verification Standard Project, jehož stránky naleznete na owasp.org.

Nezapomeňte „zapnout“ konfigurační soubor pro modsecurity-crs

#cd /usr/share/modsecurity-crs
#cp crs-setup.conf.example crs-setup.conf

V adresáři /usr/share/modsecurity-crs naleznete tuto adresářovou a souborovou strukturu:

  • activated_rules – adresář s aktivními pravidly, zpočátku je prázdný a je potřeba jej naplnit konfiguračními soubory s jednotlivými CRS
  • rules – adresář se základními CRS
  • experimental_rules – adresář s eperimentálními CRS
  • lua – adresář s lua skripty. lua je minimalistický jazyk umožňující přístup k určitým knihovnám a kódu. Rovněž umožňuje přístup ke všem interním proměnným ModSecurity
  • owasp-crs.load – konfigurační soubor se základními CRS
  • optional_rules – adresář s dalšími CRS
  • slr_rules – adresář s CRS od SpiderLabs – SLR – Spider Labs Research
  • util – adresář obsahující nástroje/skripty, které je možné použít ve spolupráci s OWASP ModSecurity CRS

Poznámka

Struktura adresáře /usr/share/modsecurity-crs se může lišit (záleží na použité instalační metodě). Každopádně by se zde ale měly nacházet podadresáře activated_rules, rules a util a konfigurační soubor  owasp-crs.load.

Do adresáře /usr/share/modsecurity-crs/activated_rules nyní nakopírujte (nebo zde vytvořte odkaz) na CRS pravidla, která chcete používat. Nejčastěji asi použijete pravidla z adresářů rules, experimental_rules nebo  optional_rules.

Nezapomeňte doplnit konfigurační soubor /usr/share/modsecurity-crs/owasp-crs.load o řádek

Include /usr/share/modsecurity-crs/activated-rules/*.conf

Jinak ModSecurity vaše vlastní pravidla nenačte.

Mějte na paměti, že adresář activated_rules je jediný, který se neaktualizuje aktualizací binárního balíčku modsecurity-crs. Stejné je to i s aktualizací pravidel z git. Pokud tedy v adresáři activated_rules vytvoříte pouze odkazy na pravidla v ostatních adresářích a tato pravidla si posléze „upravíte“, pak následující update vaše úpravy přemaže obsahem, který je v balíčku modsecurity-crs balíčku nebo v git.

Pokud opravdu musíte některá pravidla upravovat, pak změněné soubory raději nakopírujte z ostatních adresářů do adresáře activated_rules a zde proveďte úpravy. Další možností (a rozhodně doporučovanou) je využití patřičných direktiv, např. SecRuleRemoveById. Tyto direktivy zapíšete do samostatného konfiguračního souboru (obvykle do /etc/modsecurity/modsecurity.conf) a ModSecurity je pak již „nezapomene“.

Start démona

Nyní můžeme restartovat webového démona

# sudo systemctl restart apache2

Veškerá chybová hlášení (zejména ta, která vygeneroval náš ModSecurity) by se měla nacházet v souborech /var/log/apache2/error.log/var/log/apache2/modsec_audit.log.

V prvním výše uvedeném logu budeme hledat zejména výskyt takovýchto hlášení:

[Mon Apr 24 10:05:50.672853 2017] [:error] [pid 4084] [client xx.xx.xx.xx] ModSecurity: Rule 7f781ac2f5f0 [id "973302"][file "/usr/share/modsecurity-crs/activated_rules/m
odsecurity_crs_41_xss_attacks.conf"][line "309"] - Execution error - PCRE limits exceeded (-8): (null). [hostname "xxxx"] [uri "xxxxx"]

Je zřejmé, že pravidlo s id „973302“ z kontejneru modsecurity_crs_41_xss_attacks.conf koliduje s činností aplikace. Je třeba buď upravit (nebo zakomentovat) dané pravidlo, nebo opravit kód dané aplikace. V konfiguračním souboru /etc/modsecurity/modsecurity.conf můžeme pravidlo s id "973302"  zakázat třeba takto:

<LocationMatch '^/'>
SecRuleRemoveById 973302
</LocationMatch>

Výše uvedeným způsobem můžete „odhalit“ veškerá CRS pravidla, která kolidují s činností vašich aplikací a tato pravidla pak vyřadit z činnosti do té doby, než opravíte kód aplikace.

Po úpravě konfiguračního souboru (a jeho uložení) nezapomeňte restartovat démona

# sudo systemctl restart apache2

Zkontrolujte „běh“ démona apache

# sudo systemctl status apache2

Přepnutí do plného režimu

Máme-li „odladěno“, můžeme přistoupit k přepnutí ModSecurity do plného režimu, tedy direktivu SecRuleEngine přepneme do režimu On

SecRuleEngine On

Do budoucna se samozřejmě může stát (a bude se stávat, věřte mi), že se aplikace opět s ModSecurity „nepohodne“ a vy se setkáte s oznámením Access denied (nebo podobným hlášením). V takovém případě nepropadejte panice a použijte následující postup:

  1. ve webovém prohlížeči stiskněte tlačítko zpět (prohlížeč ze své vyrovnávací paměti „vrátí zpět“ na obrazovku kód, který způsobil kolizi s CRS pravidlem
  2. přihlašte se do konzole serveru, který provozuje kód aplikace. Budete potřebovat dvě konzole, ve kterých budete přihlášeni jako uživatel s právy uživatele (root)
  3. v logu vyhledejte id všech CRS, která způsobila odepření přístupu webové aplikace k příslušnému obsahující
  4. přidejte tato id do parametrů direktivy SecRuleRemoveById
  5. uložte příslušný konfigurační soubor a restartujte démona
  6. zavolejte znovu kód (stránku) webové aplikace, která původně skončila nezdarem

Zde se dnes rozloučíme a v jednom z příštích dílů seriálu se podíváme na kouzla, která se do dnešního dílu nevešla – tedy na strukturu a tvorbu vlastních CRS pravidel. Podíváme se i na logování a strukturu jednotlivých záznamů v logu.