WAF pro vývojáře: jak funguje web application firewall a jak ji nastavit

Webový aplikační firewall (WAF) zachytí velkou část útoků na web dřív, než se dostanou k vaší aplikaci. V článku vysvětlujeme, co WAF dělá a co od ní naopak čekat nemůžete, porovnáme cloudové, serverové a aplikační varianty a krok za krokem projdeme nasazení ModSecurity s pravidly OWASP Core Rule Set na VPS s Nginx.

Článek je určený vývojářům a agenturám, které provozují weby klientů na vlastním serveru.

Co je WAF a čím se liší od síťového firewallu

Web Application Firewall (WAF) funguje jako inteligentní štít vložený mezi návštěvníka a vaši webovou aplikaci. Operuje přímo na 7. aplikační vrstvě modelu OSI, díky čemž rozumí samotnému obsahu komunikace. Vidí detailně do adres URL, hlaviček, formulářových parametrů, cookies i do těla POST požadavků. Jakmile zachytí známý vzorec útoku, nekompromisně ho zablokuje, nebo alespoň zaznamená do bezpečnostního logu. 

Klasický síťový firewall (např. iptables či nftables) naproti tomu pracuje o několik vrstev níže. Rozhoduje výhradně podle IP adres, portů a protokolů. Dokáže sice striktně určit, že na port 3306 smí pouze aplikační server, ale do obsahu HTTP požadavků už nevidí. Útočný dotaz typu GET /produkt?id=1 OR 1=1 tak proběhne bez povšimnutí jako běžný, legitimní provoz na portu 443.

Oba nástroje se doplňují, nenahrazují:

• Síťový firewall: říká, kdo se smí připojit a kam (IP adresy, porty).
• WAF: zase co smí připojený klient poslat aplikaci (obsah HTTP komunikace).

Freelo - Nástroj na řízení úkolů a projektů

Přidej se, pozvi svůj tým a klienty, rozděl práci a sleduj, jak se úkoly dají do pohybu.

Před čím WAF chrání a co neřeší

Kvalitní sada pravidel pokrývá podstatnou část útoků ze seznamu OWASP Top 10, tedy nejčastějších zranitelností webových aplikací:

• SQL injection: útočník podstrčí do parametru SQL kód a čte nebo mění data v databázi.
• Cross-site scripting (XSS): do stránky se vloží cizí JavaScript, který krade session nebo přesměrovává návštěvníky.
• Path traversal a local file inclusion: čtení souborů mimo webový adresář, typicky přes sekvence ../ v parametru.
• Vzdálené spuštění kódu (RCE) a command injection: vložení systémových příkazů do vstupů aplikace.
• Útoky na protokol HTTP: request smuggling, neplatné hlavičky, podezřelé metody.
• Skenery a boti: WAF pozná typické signatury nástrojů, které automatizovaně hledají zranitelnosti.

Stejně důležité je vědět, co WAF neřeší:

• Chyby v aplikační logice. Pokud e-shop dovolí objednat zboží se zápornou cenou, WAF to nepozná. Požadavek vypadá legitimně.
• Ukradené přihlašovací údaje. Přihlášení platným heslem projde, i když ho zadává útočník.
• Objemové DDoS útoky. Zahlcení linky na síťové vrstvě musí řešit infrastruktura před serverem, ne modul ve webserveru.
• Zranitelnosti nezáplatovaného softwaru. WAF zachytí známé vzory útoků, ale není zárukou u nových zranitelností. Aktualizace nenahradí.

Tři varianty WAF: cloud, server, aplikace

Cloudový WAF

Provoz webu směrujete přes infrastrukturu poskytovatele (typicky změnou DNS), který požadavky filtruje dřív, než dorazí na váš server. Známým příkladem je Cloudflare, který v bezplatném tarifu nabízí základní sadu spravovaných pravidel a v placených tarifech plné spravované sady s vlastními pravidly.

Výhody: nasazení bez zásahu do serveru, pravidla spravuje poskytovatel, součástí bývá i ochrana proti DDoS. Nevýhody: provoz webu (včetně dešifrovaného HTTPS) prochází třetí stranou, možnosti ladění jsou omezené na to, co poskytovatel dovolí.

WAF na serveru

Modul webserveru nebo samostatná proxy na vašem VPS. Standardem je zde dvojice: WAF engine plus sada pravidel OWASP Core Rule Set (CRS). U enginů je stav k září 2026 následující:

• ModSecurity je nejrozšířenější serverový WAF. Firma Trustwave ukončila komerční vývoj v roce 2024 a projekt převzala nadace OWASP, kde ho dál udržuje komunita. Projekt je v režimu údržby: opravy chyb a bezpečnostní záplaty vycházejí, velké nové funkce už ne. Pro produkční nasazení s Nginx je to stále funkční a podporovaná cesta.
• Coraza je nástupce psaný v jazyce Go, rovněž projekt OWASP. Je kompatibilní s jazykem pravidel SecLang i s CRS. Stabilní konektory existují pro Caddy, Envoy, Traefik a HAProxy. Konektor pro Nginx je zatím označený jako experimentální, proto ho pro produkci na Nginx zatím nedoporučujeme.

WAF v aplikaci

Firewall běží jako součást aplikace, typicky plugin CMS. U WordPressu je to například Wordfence, který filtruje požadavky na úrovni PHP. Výhodou je znalost kontextu aplikace (uživatelé, role, známé zranitelnosti pluginů). Nevýhodou je, že požadavek už zpracovává PHP, takže útok na samotný webserver nebo PHP interpret plugin nezachytí a každý požadavek stojí výkon aplikace.

VPS Centrum

Vyzkoušejte zdarma naši aplikaci pro správu serveru a domén. Budete si připadat jako zkušený administrátor.

Praktický postup: ModSecurity + OWASP CRS na Nginx

Postup je odzkoušený na Debianu 12 a Ubuntu 24.04 LTS. Na starších verzích Ubuntu včetně 22.04 LTS balík libnginx-mod-http-modsecurity v repozitářích není, takže tam návod neprojde. Potřebujete VPS s root přístupem a Nginx z distribučních balíků.

1. Instalace modulu

Distribuce obsahují hotový balík s knihovnou libmodsecurity a konektorem pro Nginx:

sudo apt update

sudo apt install libnginx-mod-http-modsecurity

Balík modul rovnou aktivuje v adresáři /etc/nginx/modules-enabled/.

Samotná instalace ale zatím nic nefiltruje a nic neblokuje. Modul je jen načtený: ve virtualhostu není zapnutý, nemá odkud brát pravidla a engine je v doporučené konfiguraci nastavený na DetectionOnly. Server se tedy chová přesně jako předtím. Kontrolovat provoz začne až po krocích 4 a 5 níže, blokovat teprve po přepnutí SecRuleEngine na hodnotu On.

Ověřte si verzi enginu

V červnu 2026 vyšlo ModSecurity 3.0.16, které opravuje dvě zranitelnosti. U té závažnější (CVE-2026-52747) parser multipartních formulářů tiše odstraňoval zalomení řádků z hodnot polí, takže se pravidla dívala na jiný vstup, než jaký ve skutečnosti dorazil na server. Útočník tím dokáže pravidla WAF obejít.

Distribuční balíky opravu zatím nemají. Debian 12 dodává verzi 3.0.9, Debian 13 verzi 3.0.14 a Ubuntu opravu ke dni vydání článku nevydalo. Nainstalovanou verzi zjistíte příkazem:

dpkg -l | grep libmodsecurity

Pokud je nižší než 3.0.16, počítejte s tím, že požadavky posílané jako multipart/form-data mohou pravidla obejít. Proti ostatním typům útoků WAF funguje normálně, ale u formulářů s nahráváním souborů se na něj nespoléhejte jako na jedinou obranu. Sledujte bezpečnostní aktualizace své distribuce a nasaďte je, jakmile vyjdou.

2. Základní konfigurace ModSecurity

Vytvořte adresář pro konfiguraci a stáhněte doporučený konfigurační soubor z oficiálního repozitáře na GitHubu (spolu s mapovacím souborem unicode.mapping):

sudo mkdir -p /etc/nginx/modsec

cd /etc/nginx/modsec

sudo wget https://raw.githubusercontent.com/owasp-modsecurity/ModSecurity/v3/master/modsecurity.conf-recommended -O modsecurity.conf

sudo wget https://raw.githubusercontent.com/owasp-modsecurity/ModSecurity/v3/master/unicode.mapping

3. Stažení OWASP Core Rule Set

CRS je udržovaná sada obecných pravidel proti útokům z OWASP Top 10. Aktuální je řada CRS 4 a vychází ve dvou větvích a volba mezi nimi má praktický dopad:

• Rolling (v době psaní 4.29.0): nová pravidla a detekce zhruba jednou měsíčně.
• LTS (aktuálně 4.25.1): podpora do Q3 2027, backportují se jen bezpečnostní opravy, regrese a kritické falešné poplachy na paranoia level 1. Žádná nová pravidla, tedy ani žádné nové falešné poplachy k ladění.

Pro agentury, které spravují desítky klientských webů, by LTS byla logičtější volba. Háček je v tom, že vydání 4.25.1 vyžaduje libmodsecurity 3.0.16 nebo novější – na starším enginu se konfigurace vůbec nenačte a Nginx neprojde kontrolou nginx -t. Protože distribuční balíky zatím starší jsou, používáme v tomto návodu rolling větev. K LTS se vraťte, až vaše distribuce vydá engine 3.0.16, nebo pokud si ModSecurity překládáte ze zdrojových kódů sami.

Nepoužívejte distribuční balík modsecurity-crs. V repozitářích Debianu i Ubuntu je pořád řada CRS 3.3, ne 4.x, a instaluje se do jiných cest s jinou strukturou souborů. Kdo si ho nainstaluje a pak se řídí tímto článkem, smíchá dvě generace pravidel dohromady a nastavení mu nebude sedět. CRS 4 stáhněte ručně podle postupu níže:

cd /etc/nginx/modsec

sudo wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v4.29.0.tar.gz

sudo tar -xzf v4.29.0.tar.gz

sudo cp coreruleset-4.29.0/crs-setup.conf.example coreruleset-4.29.0/crs-setup.conf

4. Propojení do jednoho souboru

Konektor pro Nginx načítá jeden vstupní soubor. Vytvořte /etc/nginx/modsec/main.conf s tímto obsahem:

Include /etc/nginx/modsec/modsecurity.conf

Include /etc/nginx/modsec/coreruleset-4.29.0/crs-setup.conf

Include /etc/nginx/modsec/coreruleset-4.29.0/rules/*.conf

5. Zapnutí ve virtualhostu

Do bloku server webu, který chcete chránit, přidejte dvě direktivy:

server {

    listen 443 ssl;

    server_name www.priklad.cz;

    modsecurity on;

    modsecurity_rules_file /etc/nginx/modsec/main.conf;

    # ... zbytek konfigurace webu

}

Ověřte konfiguraci a načtěte ji:

sudo nginx -t

sudo systemctl reload nginx

Od této chvíle WAF v detekčním režimu zapisuje nálezy do auditního logu /var/log/modsec_audit.log.

Režim detekce vs. blokace a paranoia levels

Nejdřív detekce, pak blokace

Nikdy nezapínejte blokaci první den. Nechte WAF běžet v režimu DetectionOnly alespoň jeden až dva týdny běžného provozu, u e-shopu včetně objednávkového procesu a administrace. Pak projděte auditní log a vylaďte falešné poplachy (viz níže). Teprve potom v souboru modsecurity.conf změňte:

SecRuleEngine On

a znovu načtěte Nginx. Od té chvíle server odpovídá na zachycené útoky stavovým kódem 403.

Jak funguje skórování

CRS nepracuje stylem „jedno pravidlo, jedna blokace“. Používá anomální skórování: každé shodnuté pravidlo přičte požadavku body podle závažnosti (kritické pravidlo 5 bodů, chyba 4, varování 3, poznámka 2). Zablokuje se až požadavek, jehož součet překročí práh, ve výchozím stavu 5 bodů pro příchozí požadavky. Jedno kritické pravidlo tedy stačí, jedno varování (3 body) samo o sobě ne.

Paranoia levels

Pravidla CRS jsou rozdělená do čtyř úrovní přísnosti, tzv. paranoia levels 1 až 4:

• Level 1 (výchozí): základní ochrana s minimem falešných poplachů. Vhodná pro většinu webů.
• Level 2: přísnější pravidla, občasné falešné poplachy. Rozumná volba pro weby s citlivými daty, počítejte s laděním.
• Level 3: falešné poplachy jsou běžné, vyžaduje průběžnou správu výjimek.
• Level 4: maximální přísnost pro vysoce citlivé aplikace. Bez vyhrazeného času na ladění nepoužitelná.

Úroveň změníte v souboru crs-setup.conf: najděte zakomentovanou direktivu SecAction s proměnnou tx.blocking_paranoia_level, odkomentujte ji a upravte hodnotu, například setvar:tx.blocking_paranoia_level=2. Pro agenturní weby doporučujeme začít na úrovni 1 a zvyšovat jen tam, kde to riziko odůvodňuje.

Ladění falešných poplachů

Falešný poplach (false positive) znamená, že WAF blokuje legitimní požadavek. Typicky jde o formuláře, kam uživatelé vkládají HTML, úryvky kódu nebo dlouhé texty, a o redakční systémy.

Postup ladění:

1. V auditním logu najděte záznam blokovaného požadavku. Každé shodnuté pravidlo má číselné ID a pole msg s popisem.
2. Rozhodněte, zda jde skutečně o legitimní provoz. Pomůže URL, parametr a hodnota, která pravidlo spustila.
3. Výjimku zapište do souborů, které CRS pro tento účel připravuje: REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example a RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example v adresáři rules. Odstraněním přípony .example je aktivujete. Aktualizace CRS je pak nepřepíšou.

Nejjednodušší výjimkou je vypnutí konkrétního pravidla podle ID v souboru 999 (platí po načtení CRS):

SecRuleRemoveById 942100

Plošné vypnutí pravidla je ale hrubý nástroj. Přesnější je omezit výjimku na konkrétní parametr nebo URL, k čemuž slouží direktiva SecRuleUpdateTargetById a podmíněné výjimky pomocí ctl akcí.

Jak WAF otestovat a číst logy

Testujte výhradně vlastní web nebo web, k jehož testování máte písemné svolení. Skenování cizích serverů je v ČR trestné.

Základní ověření zvládnete pomocí curl s neškodnými testovacími vzory (URL kódování zajistí, že příkaz projde shellem bez úprav):

# vzor SQL injection v parametru

curl -i https://www.priklad.cz/?id=1%27%20OR%20%271%27%3D%271

# vzor XSS v parametru

curl -i https://www.priklad.cz/?q=%3Cscript%3Ealert%281%29%3C%2Fscript%3E

# vzor path traversal

curl -i https://www.priklad.cz/?file=..%2F..%2F..%2Fetc%2Fpasswd

V detekčním režimu se vrátí normální odpověď a v auditním logu přibude záznam. V blokačním režimu očekávejte stavový kód 403. Pro důkladnější test poslouží open source skenery zranitelností spuštěné proti vlastnímu webu, ideálně na testovacím prostředí.

Auditní log sledujte příkazem:

sudo tail -f /var/log/modsec_audit.log

Záznam v nativním formátu je rozdělený do sekcí, ve výchozím nastavení se zapisují sekce ABIJDEFHZ. Nejčastěji vás budou zajímat čtyři:

1. A obsahuje čas a IP adresy,
2. B hlavičky požadavku,
3. F hlavičky odpovědi
4. a H souhrn shodnutých pravidel včetně celkového anomálního skóre.

Pro strojové zpracování (například odesílání do centrálního logovacího systému) přepněte v modsecurity.conf formát na JSON direktivou SecAuditLogFormat JSON. Funguje to jen tehdy, pokud je knihovna přeložená s podporou YAJL – pokud se po restartu Nginx v logu nic neobjeví, podpora chybí a musíte zůstat u nativního formátu. Logy pravidelně rotujte, auditní log na rušném webu rychle roste.

Kdy WAF nestačí

WAF je doplněk, ne základ zabezpečení. Bez následujících opatření vás neochrání:

• Aktualizace. Záplatujte CMS, pluginy, frameworky, PHP i operační systém. WAF u nové zranitelnosti pouze zvyšuje šanci, že útok zachytí obecné pravidlo.
• Validace vstupů a bezpečný kód. Parametrizované SQL dotazy, escapování výstupu a kontrola nahrávaných souborů patří do aplikace. WAF je pojistka pro případ, že něco přehlédnete.
• Zálohy mimo server. Když ochrana selže, rozhoduje o škodách funkční záloha uložená jinde než na napadeném stroji. Zálohy pravidelně testujte obnovou.
• Princip nejmenších oprávnění. Databázový účet aplikace nemá mít práva DROP, PHP nemá zapisovat tam, kde to není nutné, SSH patří na klíče.
• Monitoring. WAF logy mají smysl, jen když je někdo čte. Nastavte si alespoň upozornění na nezvyklý počet blokací.

Často kladené otázky

Nahradí WAF aktualizace a bezpečný kód?

Ne. WAF filtruje známé vzory útoků, ale zranitelnost v aplikaci trvá dál. Berte ho jako airbag: snižuje následky, ale nezbavuje vás povinnosti řídit bezpečně.

Zpomalí WAF můj web?

Každý požadavek prochází kontrolou proti stovkám pravidel, režie tedy existuje. Na běžném webu s paranoia level 1 je zpomalení v řádu jednotek milisekund na požadavek. Vyšší paranoia levels a kontrola těla odpovědí režii zvyšují. Změřte si rozdíl v detekčním režimu před ostrým nasazením.

Mám na Nginx nasadit ModSecurity, nebo Corazu?

K září 2026 platí: pro Nginx použijte ModSecurity v3 s konektorem z distribučních balíků, protože konektor Corazy pro Nginx je stále experimentální. Coraza je správná volba pro Caddy, Envoy, Traefik nebo HAProxy. Sada pravidel OWASP CRS funguje s oběma enginy.

Co je paranoia level?

Úroveň přísnosti pravidel OWASP CRS v rozsahu 1 až 4. Vyšší úroveň zachytí více útoků, ale přináší více falešných poplachů a vyžaduje průběžné ladění výjimek. Výchozí úroveň 1 je vhodná pro většinu webů.

Ochrání mě WAF před DDoS útokem?

Jen částečně. Serverový WAF pomůže proti některým útokům na aplikační vrstvě, ale objemový útok, který zahltí linku serveru, musí odfiltrovat infrastruktura před serverem, typicky cloudová anti-DDoS služba nebo ochrana poskytovatele hostingu.

Závěrem

WAF je vrstva obrany, kterou na server přidáte za jedno odpoledne:

• na VPS s Nginx nainstalujte modul ModSecurity,
• načtete pravidla OWASP Core Rule Set,
• několik týdnů sledujte detekční režim,
• vylaďte výjimky a zapněte blokaci.

Počítejte ale s tím, že ladění výjimek není jednorázová práce a že WAF nenahrazuje aktualizace, bezpečný kód ani zálohy.

Celý postup stojí na serveru s root přístupem. Virtuální servery od Váš Hosting běží v českých datacentrech, staráme se o víc než 2 100 serverů a technickou podporu máte nonstop. Základní ochranu navíc nemusíte stavět ručně: ve VPS Centru zapnete automatické bany IP, geoblokaci HTTP provozu po jednotlivých zemích i firewall, který drží otevřené jen nutné porty. ModSecurity pak stavíte až nad tím, ne od nuly.