ModSecurity WAF — konfiguracja na Apache i Nginx

Czym jest ModSecurity WAF?

ModSecurity to open-source Web Application Firewall (WAF) działający jako moduł Apache lub Nginx. Analizuje ruch HTTP w czasie rzeczywistym i blokuje złośliwe żądania na podstawie reguł. Najczęściej używa się go z OWASP Core Rule Set (CRS) — zestawem reguł chroniących przed OWASP Top 10 (SQL Injection, XSS, RFI, LFI i innymi).

Powiązane tematy: WordPress hardening, UFW firewall, Fail2ban oraz konfiguracja Nginx. Porównaj VPS z ochroną DDoS na stronie serwerów VPS.

Instalacja ModSecurity na Ubuntu/Debian

Apache

# Instalacja modułu
sudo apt update
sudo apt install libapache2-mod-security2

# Włączenie modułu
sudo a2enmod security2

# Kopia konfiguracji domyślnej
sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

# Zmień tryb na Detection (na start)
sudo sed -i 's/SecRuleEngine DetectionOnly/SecRuleEngine DetectionOnly/' /etc/modsecurity/modsecurity.conf

# Restart Apache
sudo systemctl restart apache2

Nginx z ModSecurity v3 (libmodsecurity)

# Instalacja zależności
sudo apt install libmodsecurity3 libmodsecurity-dev

# Instalacja nginx connector
sudo apt install libnginx-mod-security

# Lub kompilacja ze źródeł (jeśli brak pakietu)
git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git
# (wymaga recompilacji Nginx z --add-dynamic-module)

Instalacja OWASP Core Rule Set (CRS)

OWASP CRS to zbiór ~200 reguł blokujących najpopularniejsze ataki. Jest rozwijany niezależnie od ModSecurity — zawsze instaluj CRS oddzielnie, nie używaj starych reguł dołączonych do pakietu.

# Pobierz najnowszy CRS
cd /etc/modsecurity
sudo git clone https://github.com/coreruleset/coreruleset.git owasp-crs

# Konfiguracja CRS
sudo cp owasp-crs/crs-setup.conf.example owasp-crs/crs-setup.conf

# Apache — dodaj do konfiguracji ModSecurity
# Plik: /etc/modsecurity/modsecurity.conf (na końcu)
# IncludeOptional /etc/modsecurity/owasp-crs/crs-setup.conf
# IncludeOptional /etc/modsecurity/owasp-crs/rules/*.conf

Konfiguracja paranoia level

CRS używa poziomów paranoi (PL1-PL4). Wyższy poziom = więcej reguł = więcej false positives. Zacznij od PL1.

# W pliku crs-setup.conf
# Szukaj linii z tx.paranoia_level
# Domyślnie PL1 (najniższy, zalecany na start)
SecAction \
    "id:900000,\
    phase:1,\
    nolog,\
    pass,\
    t:none,\
    setvar:tx.paranoia_level=1"

Włączanie trybu blokowania

Przed przełączeniem na tryb On koniecznie przetestuj reguły przez kilka dni w trybie DetectionOnly. Sprawdź logi pod kątem false positives.

# Zmień w /etc/modsecurity/modsecurity.conf
SecRuleEngine On

# Restart serwera
sudo systemctl restart apache2
# lub: sudo systemctl restart nginx

Analiza logów ModSecurity

# Logi Apache z ModSecurity
sudo tail -f /var/log/apache2/error.log | grep ModSecurity

# Logi audit ModSecurity (szczegółowe)
sudo tail -f /var/log/modsec_audit.log

# Podsumowanie najczęstszych reguł
grep "id \"" /var/log/modsec_audit.log | grep -oP 'id "\K[0-9]+' | sort | uniq -c | sort -rn | head 20

Format logu audit zawiera:

• --A-- Nagłówek transakcji (ID, czas, IP)
• --B-- Nagłówki żądania
• --C-- Ciało żądania (POST body)
• --F-- Nagłówki odpowiedzi
• --H-- Informacja o naruszeniu reguły

Obsługa false positives — wyłączanie reguł

Niektóre aplikacje (WordPress, sklepy, panele admina) generują false positives. Wyłączaj reguły tylko dla konkretnych ścieżek — nie globalnie.

# Plik: /etc/modsecurity/custom-rules.conf

# Wyłącz regułę 941100 dla ścieżki /wp-admin
<LocationMatch "^/wp-admin">
    SecRuleRemoveById 941100
</LocationMatch>

# Wyłącz dla konkretnego IP (np. własne biuro)
SecRule REMOTE_ADDR "@ipMatch 192.168.1.0/24" \
    "id:1000,phase:1,allow,nolog,ctl:ruleEngine=DetectionOnly"

# Wyłącz konkretną regułę globalnie (ostateczność)
SecRuleRemoveById 920350

Dobra praktyka: Twórz osobny plik custom-rules.conf z wykluczeniami. Nie modyfikuj plików CRS bezpośrednio — utrudnia to aktualizacje zestawu reguł.

ModSecurity z WordPress

WordPress generuje wiele false positives (edytor Gutenberg, wtyczki, żądania AJAX). CRS dostarcza gotowe exclusions dla WordPress:

# W pliku crs-setup.conf odkomentuj sekcję WordPress
# lub stwórz exclusions z gotowego szablonu CRS

# Plik: /etc/modsecurity/owasp-crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
# (kopiuj z examples/exclusion-rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf)

# Lub użyj gotowego pluginu Nginx/Apache dla WordPress + ModSecurity
# https://github.com/coreruleset/wordpress-rule-exclusions-plugin

Wydajność ModSecurity

ModSecurity dodaje ~2-10ms latencji per żądanie (zależy od liczby reguł i rozmiaru body). Dla typowych stron WordPress to akceptowalne. Dla API z dużym ruchem — rozważ wyłączenie inspekcji body na wybranych endpoint'ach.

# Wyłącz inspekcję ciała żądania dla konkretnej ścieżki
<LocationMatch "^/api/upload">
    SecRequestBodyAccess Off
</LocationMatch>

# Zwiększ limit rozmiaru body (domyślnie 13 MB)
SecRequestBodyLimit 26214400
SecRequestBodyNoFilesLimit 131072