Doba čtení: 9 minut
Pokud provozujete webové aplikace na NGINX a řešíte jejich bezpečnost alespoň na základní úrovni, ModSecurity je nástroj, který byste neměli přehlížet. Platí to i v případě, kdy NGINX funguje pouze jako reverzní proxy před aplikačním serverem.
ModSecurity není náhradou bezpečného vývoje ani správně nastavené aplikace. Je to však velmi účinná další ochranná vrstva, která dokáže zachytit velké množství běžných útoků ještě dříve, než se dostanou k backendu.
Tento článek se zaměřuje na jednoduché, funkční a bezpečné minimum, které lze nasadit na Debianu bez zbytečné složitosti a bez rizika rozbití produkčního provozu.
Co je ModSecurity a k čemu slouží
ModSecurity je Web Application Firewall (WAF). Sleduje HTTP a HTTPS provoz a porovnává jednotlivé požadavky s pravidly, která dokážou detekovat například:
-
SQL injection
-
XSS (Cross-Site Scripting)
-
pokusy o upload škodlivých souborů
-
útoky na přihlašovací formuláře
-
automatizované skenery a boty
Na rozdíl od klasického firewallu pracuje na aplikační vrstvě (L7) – rozumí URL adresám, hlavičkám, parametrům i obsahu požadavků.
Proč má ModSecurity smysl i na NGINX reverzní proxy
Často se lze setkat s názorem, že pokud je NGINX pouze proxy a samotná aplikace běží jinde, WAF není potřeba. V praxi je to přesně naopak.
NGINX jako reverzní proxy je pro nasazení ModSecurity ideální místo, protože:
-
zachytí útok ještě předtím, než zasáhne backend
-
chrání více aplikací z jednoho centrálního bodu
-
snižuje zátěž aplikační vrstvy
-
filtruje škodlivý provoz bez nutnosti zásahu do aplikace
-
funguje i pro starší nebo cizí aplikace, které nemáte plně pod kontrolou
Z bezpečnostního pohledu je WAF na proxy první obranná linie, nikoli poslední.
ModSecurity a NGINX: důležitý technický kontext
NGINX nepodporuje původní ModSecurity v2 jako Apache. Používá se:
-
ModSecurity v3 (libmodsecurity)
-
NGINX konektor pro ModSecurity
Tento přístup je dnes standardní, stabilní a běžně používaný v produkci.
Správný přístup: nezačínat blokováním
Jednou z nejčastějších chyb je okamžité zapnutí ModSecurity v režimu blokování. Správný postup je opačný:
-
zapnout detekční režim (DetectionOnly)
-
sledovat auditní logy
-
vyhodnotit falešné poplachy
-
nastavit výjimky
-
teprve poté zvážit blokování vybraných pravidel
Cílem není zastavit veškerý provoz, ale odfiltrovat skutečně nebezpečné požadavky bez dopadu na legitimní uživatele.
Typická architektura na Debianu
Běžné nasazení vypadá následovně:
-
Debian 11 nebo 12
-
NGINX jako reverzní proxy a terminace TLS
-
ModSecurity v3
-
OWASP Core Rule Set (CRS)
Tok provozu:
klient → NGINX + ModSecurity → aplikační backend
Backendem může být Apache, PHP-FPM, Node.js, Docker nebo jiná aplikační vrstva.
Základní koncepce konfigurace
Bez zabíhání do detailních direktiv je důležité dodržet několik zásad:
-
ModSecurity je zapnutý globálně v NGINX
-
konfigurace WAF je oddělena od konfigurace webů
-
weby pouze deklarují, že mají ModSecurity aktivní
-
kontrola request body je zapnutá
-
velikost požadavků a uploadů je rozumně omezená
Tento přístup zajišťuje přehlednost a snadnou správu.
OWASP Core Rule Set: používat, ale s rozumem
OWASP CRS je standardní sada pravidel, která pokrývá většinu běžných útoků. Zároveň je potřeba počítat s tím, že:
-
bez úprav může generovat falešné poplachy
-
některé aplikace (např. API, WordPress, JSON payloady) vyžadují výjimky
-
ne všechna pravidla jsou vhodná pro každý typ provozu
Doporučený postup je začít s Paranoia Level 1, logovat a postupně ladit podle reálného provozu.
Logování je klíčové
Bez správného logování nemá ModSecurity praktický přínos. Sledujte zejména:
-
auditní log ModSecurity
-
ID pravidla, které se spustilo
-
URL a parametry požadavku
-
čas a frekvenci výskytu
Po několika dnech provozu získáte jasný přehled o tom, co jsou skutečné útoky a co jen falešné poplachy.
Dopad na výkon
Při rozumném nastavení je výkonový dopad minimální. NGINX zvládá ModSecurity velmi efektivně a u běžných webů není rozdíl znatelný.
Problémy mohou nastat pouze při:
-
extrémně vysokých limitech uploadů
-
příliš agresivních pravidlech
-
špatně navržených výjimkách
Na standardním VPS je však ModSecurity bez problémů použitelný.
Co od ModSecurity neočekávat…
Je důležité mít realistická očekávání:
-
neřeší chyby v aplikačním kódu
-
nenahrazuje aktualizace systému
-
neochrání proti slabým heslům
-
neřeší logické chyby aplikace
ModSecurity je doplněk bezpečnosti, nikoli náhrada správné správy systému.–
—
Pokud provozujete NGINX na Debianu jako reverzní proxy, ModSecurity:
-
dává technický i bezpečnostní smysl
-
lze jej nasadit postupně a bezpečně
-
funguje jako první ochranná vrstva
-
chrání více aplikací najednou
-
výrazně zvyšuje základní úroveň zabezpečení
Začněte jednoduše, v detekčním režimu, s OWASP CRS a sledujte reálná data z provozu. Právě takto se ModSecurity používá v profesionálním prostředí – kontrolovaně, postupně a s rozumem.
Má to smysl jak pro hostingové společnosti, tak pro firemní weby – a přesně v tom základním (detekčním) módu, o kterém je řeč.
Stručně a věcně:
Pro hostingové společnosti má tento způsob nasazení velký význam:
-
chrání více zákazníků najednou na úrovni proxy
-
funguje jako centrální bezpečnostní filtr
-
nezasahuje do aplikací klientů
-
snižuje objem útoků, které by jinak řešil backend
-
v detekčním režimu nerozbíjí provoz a nevytváří support zátěž
-
umožňuje sbírat data o útocích napříč hostingem
Pro hosting je detekční mód ideální jako:
-
výchozí stav
-
bezpečnostní baseline
-
podklad pro pozdější zpřísnění (per klient / per službu)
Pro firemní weby a interní aplikace to dává smysl stejně:
-
chrání web bez zásahů do kódu
-
zachytí běžné automatizované útoky
-
funguje i pro starší nebo externě vyvíjené systémy
-
poskytne přehled o tom, co na web reálně útočí
-
je vhodný i pro weby s nízkou návštěvností
U firemních webů je detekční mód často:
-
trvalé řešení (monitoring)
-
nebo přechodový krok před částečným blokováním
.—–.-.–..-.-.—->
-
Ano, má to smysl
-
Ano, je to správný mód pro začátek
-
Ano, je vhodný pro hosting i firemní prostředí
-
Ne, není to zbytečné ani „jen hračka“
-
Ne, nemusí se hned blokovat
Tento přístup se používá přesně proto, že:
-
je bezpečný
-
neinvazivní
-
škálovatelný
-
profesionální
Má smysl přejít z DetectionOnly na blokování ve chvíli, kdy už máte z logů ověřené, že pravidla trefují převážně reálné útoky a ne legitimní provoz. Prakticky:…
-
Cíl
Zablokovat skutečně škodlivé požadavky bez toho, abyste si rozbil produkci (false positives). -
Předpoklady
– Běží DetectionOnly minimálně několik dní až týdnů (u hostingu spíš 2–4 týdny, u jednoho firemního webu často stačí 7–14 dní).
– Máte audit logy a umíte z nich vytáhnout: top rule IDs, top URL, top klienty/IP, opakovanost.
– Máte nastavené základní výjimky pro legitimní části aplikace (typicky login, admin, API endpointy, uploady, JSON).
– Znáte “normální” baseline provozu (co je běžné a co je útok). -
Kroky (minimum)
A) Nejdřív blokujte jen “jistoty”
Začněte blokováním jen těch pravidel / tříd útoků, které máte v logu opakovaně a zároveň u nich nevidíte legitimní použití. Typicky:
– očividné SQLi payloady, path traversal, RCE patterny, skenery
– velmi vysoké anomaly skóre u jasných botů
B) Přechod dělejte po krocích, ne “zapnout vše”
– Nejprve “block” jen pro 1–2 virtuální hosty / 1 aplikaci (canary).
– Teprve pak rozšiřujte.
U hostingu ideálně per-customer/per-vhost.
C) Použijte prahování (anomaly scoring), ne tvrdé “deny on first match”
OWASP CRS je stavěný na skórování. Blokovat má smysl až při překročení prahu (nižší riziko false positives).
D) Nejprve blokujte Request, ne Response
Základ je inbound ochrana. Outbound kontrolu (response body) často ani nepotřebujete pro “základ”.
-
Ověření
– Sledujte počet 403/den a korelujte se supportem (reálné stížnosti).
– V logu vyhodnoťte: které rule IDs blokují nejvíc a na jakých URL.
– Kontrolujte, že blokování se netýká kritických flow (checkout, login, API).
– Po nasazení blokování musí být jasně vidět “pokles šumu” na backendu (méně 404/500 z útoků, méně bot trafficu). -
Rollback
– Okamžitý návrat do DetectionOnly (globálně nebo per vhost).
– Dočasné vypnutí konkrétních rule IDs, které dělají problémy (rychlejší než vypnout vše).
– Zvednutí prahu anomaly score, pokud blokujete příliš agresivně. -
Rizika
– False positives (největší riziko), typicky u: API, JSON, uploadů, admin částí, WordPress editoru, search parametru.
– “Tichá degradace”: uživatelům se začne něco failovat a vy to uvidíte až podle stížností, pokud nemáte monitoring.
– Na hostingu právní/obchodní dopad: blokování musí být předvídatelné a auditovatelné.
Kdy konkrétně je to “ready” na blokování (praktická pravidla)
– Jedno rule ID pálí často, ale 95–99 % zásahů jsou očividné útoky (ne běžní uživatelé).
– Opakuje se to na více webech a stejných patternů.
– Máte vyřešené výjimky pro legitimní endpointy.
– Máte monitoring a rychlou možnost rollbacku.
– U firemního webu: máte otestované klíčové user flow.
– U hostingu: máte to aspoň týden ověřené na canary skupině.
.. „Rozšířená ochrana webu s aktivním blokováním nebezpečných požadavků. Aktivace probíhá na základě analýzy provozu.“, nebo „Naše infrastruktura obsahuje základní bezpečnostní monitoring webových útoků, který běží bez zásahu do provozu.“ i to vše může být vás sec.mode.
