Vlákno názorů k článku Hardening: webový aplikační firewall – modul ModSecurity od Filip Jirsák - Do budoucna se samozřejmě může stát (a bude...

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:
Chápu, že je to napsané s ohledem na cílové publikum tohoto článku. Nebudu teď řešit, jestli má smysl, aby naprostí laici používali WAF – je to podle mne podobné, jako používat osobní firewall.

Nicméně mělo by zaznít, že v prostředích, kde se skutečně řeší bezpečnost, je nesmysl jen tak vypnout nějaké bezpečnostní pravidlo. Muselo by se analyzovat, co přesně problém způsobilo, tedy zjistit, zda byl problém v pravidle nebo v aplikaci, a pak to na správném místě opravit. V článku se totiž automaticky předpokládá, že chyba je v pravidle WAF – WAF se ale nasazuje proto, že se předpokládá, že chyba může být v aplikaci. Ano, ve skutečnosti chyba bude většinou na straně WAF, ale pokud všechna kolizní pravidla bez analýzy vypnete, nemusíte WAF mít vůbec. (Jen pro jistotu – na tu kolizi obvykle nepřijde správce WAF, ale někdo jiný. Pokud při každé kolizi příslušné pravidlo automaticky vypnete, vypnete ho i v případě, kdy na kolizi v prvním kole narazí útočník.)

Také by bylo dobré zmínit, že WAF je druhá úroveň zabezpečení. Záměrně se tedy na komunikaci dívá úplně jiným způsobem, než aplikace. Takže je pravda, že může odhalit třeba i SQL injection udělanou způsobem, která autory aplikace vůbec nenapadl. Ale zároveň spoustu triviálních chyb vůbec neodhalí. Takže v žádném případě nelze WAF používat způsobem, že máte nebezpečnou aplikaci a před ní postavíte WAF, aby útoky odchytil.

Toto ale asi platí spíše pro aplikace, které jsou psané na míru, kde je povědomí co a jak má fungovat. Jak ale třeba takto ošetřit aplikace, které to potřebují nejvíce, tzn opensource CMS systémy typu Joomla, Wordpress?

Víceméně nijak. Systém děravý jak řešeto (WordPress) se nedá zachránit pomocí WAF. Musí se tam spousta pravidel vypínat, a když to začnete zkoumat, zjistíte, že není problém v modsecurity, ale v blbé aplikaci. Máte pak dvě možnosti: uhánět autora (wordpress, doplňky), nebo jít, a opravit to. Nejhorší možnost je to nechat, a snažit se ohnout pravidla pro modsecurity. Zrovna s wordpressem je to katastrofa, pro něj píší tisíce jelit, kterým vůbec neměla přijít klávesnice do ruky.

Tady je každá rada drahá. Pokud nějaké pravidlo vypnete bez zkoumání, je možné, že jste právě otevřel díru, před kterou vás do té doby ModSecurity chránil. Já bych asi spíš energii věnoval zabezpečení samotného CMS – vybrat jenom nutné pluginy, pokusit se zjistit něco o jejich bezpečnosti, aktualizovat. Bál bych se, že nasazení ModSecurity bude neustále otravovat legitimní uživatele, a vy pak budete jen co nejrychleji vypínat další a další pravila, a celé to bude jen k zlosti.

OWASP CRS3 obsahuje pravidla i pro WordPress a Drupal (nejsem si jist jestli i Joomla)...