Názory k článku Hardening: webový aplikační firewall – modul ModSecurity

Docela šikovné jsou rulesety od Atomicu: https://atomicorp.com/atomic-modsecurity-rules/,
a taky od Comoda: https://waf.comodo.com/. V praxi vyžadují méně péče, údržby a produkují méně false-positives (což spoustu adminů zajímá, aby se neupravidlovali). Doporučuji vyzkoušet.

Dobrý den,

bylo by možné v příštích článcích o modsecurity nějak změřit jaký má použití modsecurity vliv na výkon aplikace a serveru?

Děkuji

Také jsem to nenašel.

V praxi jsem došel k tomu, že je potřeba segregovat služby, které je potřeba chránit od těch, kde mohou být pravidla volnější. Např. u formulářů je vhodné kontrolovat obsah dotazu i odpovědi. Na druhou stranu nemá smysl provádět sofistikované kontroly tam, kde odesíláte downloadované soubory, obrázky atp. (Na uploadovaných zase většinou ano). To v praxi naráží na jednoduchý vývoj aplikací, kdy v jednom document rootu je vše, upload, download, obsah, texty atd. - ale u těchto aplikací se zase nepočítá s vysokou zátěží a hledisko výkonu není tak důležité.

Celkově modsecurity funguje dobře, žádný drastický úbytek výkonu se nekoná.

Já jsem i našel, ale nestudoval jsem jak se to měřilo a podobně a trošku mne ta čísla vystrašila třeba tady https://github.com/defanator/modsecurity-performance/wiki a viděl jsem i u dalších grafy který mi připadali ještě horší

latence (přeložil jsem si jako doba zprcování požadavku) bez ~7.4ms s plným setem pravidel ~778ms, úplně jsem si vzpoměl jak mi naposledy marketák říkal, "Co se nenačte do vteřiny, odtamtud lidi odcházejí" a pak vlezl na FB a čekal 5 vteřin než se mu načetl :-D. Z ~100 000 requestů na ~800

To mi přijde jako slušnej zabiják výkonu :-D Asi se to pak musí komezovat nějakou předřazenou cache,..

Záleží na rulesetech, na tom, jestli zkoumáte data jen jedním směrem nebo oběma a kolik dat necháváte projet. Dával jsem nahoře odkazy na docela dobré rulesety. Taky proto jsem mluvil o segregaci obsahu, protože se hodí mít důkladnější kontrolu např. na formulářích a méně důkladnou u posílání binárních (a už prověřených) dat.

Bude asi zalezet na tom, kolik pravidel mas, a jak je vlastne modsecurity uchovava a prochazi (to sem nikde nenasel)...

Správně fungující webový aplikační firewall nemá na výkon aplikace žádný vliv – můžete ho mít klidně na samostatném zařízení, které může třeba zároveň fungovat jako loadbalancer, tj. k aplikaci se dostanou jen čisté požadavky. Samozřejmě pokud bude WAF nad každým požadavkem vteřinu dumat, na odezvě aplikace to hned poznáte.

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)...