Krótko: ModSecurity to Web Application Firewall działająca w serwerze WWW; OWASP Core Rule Set (CRS) dostarcza do niej swobodnie dostępne reguły przeciw rozpowszechnionym rodzajom ataków. Dla Apache projekt CRS zaleca ModSecurity v2, dla Nginx wchodzą w grę konektor v3 lub Coraza. Proszę zacząć w trybie blokowania z bardzo wysokimi progami anomalii, obniżać je stopniowo, a fałszywe alarmy obsługiwać celowymi wyjątkami. Aktualizacji PHP to nie zastępuje.
Własna WAF jako dodatkowa warstwa
Od PHP2Shell wiele firm pyta, czy potrzebuje Web Application Firewall. Kto udostępnia swoje strony przez Cloudflare, ma według Cloudflare od 21 października 2026 automatycznie aktywne reguły ochronne. Kto tego nie robi lub nie chce kierować ruchu przez osobę trzecią, może uruchomić WAF bezpośrednio na własnym serwerze.
Najbardziej znaną kombinacją jest ModSecurity z OWASP Core Rule Set. Jedno i drugie ma otwarte źródła i jest bezpłatne. CRS to zbiór ogólnych reguł wykrywania, na przykład przeciw SQL injection, Cross-Site Scripting czy wstrzykiwaniu plików. Projekt sam opisuje swój cel jako ogólne wykrywanie ataków z jak najmniejszą liczbą fałszywych alarmów, jako element spośród kilku.
Tym samym wskazana jest też granica. WAF sprawdza żądania i odpowiedzi, nie naprawia luki w interpreterze PHP. Dlaczego potrzebne jest jedno i drugie, opisuje artykuł WAF albo aktualizacja: dlaczego potrzebne jest jedno i drugie.
Jaki silnik pasuje do Państwa serwera WWW
Zestaw reguł potrzebuje silnika, który go wykonuje. Według dokumentacji CRS istnieją trzy zgodne opcje:
| Silnik | Serwer WWW | Ocena według projektu CRS |
|---|---|---|
| ModSecurity v2 | Apache (moduł) | implementacja referencyjna, zalecana dla Apache |
| ModSecurity v3 (libModSecurity) | głównie Nginx przez konektor | naprawdę produkcyjnie nadaje się tylko konektor Nginx; nie przechodzi 2 do 4 procent testów CRS |
| Coraza | proxy i integracje oparte na Go | w pełni przechodzi zestaw testów CRS v4 |
Tło: ModSecurity był przez długi czas rozwijany przez Trustwave. Trustwave zapowiedział w 2021 roku zakończenie rozwoju w 2024. 25 stycznia 2024 projekt przeszedł do OWASP Foundation. Przy nowych instalacjach proszę sprawdzić, jaką wersję dostarcza Państwa dystrybucja i jak jest aktualna.
Jak działa Core Rule Set
CRS w ustawieniu domyślnym nie blokuje przy pierwszej podejrzanej nieprawidłowości. Pracuje z punktami anomalii: każda uruchomiona reguła dodaje punkty zgodnie ze swoim stopniem ważności i dopiero gdy suma przekroczy próg, żądanie jest odrzucane.
- Stopnie ważności: krytyczny 5 punktów, błąd 4, ostrzeżenie 3, wskazówka 2.
- Próg dla żądań:
tx.inbound_anomaly_score_threshold, domyślnie 5. - Próg dla odpowiedzi:
tx.outbound_anomaly_score_threshold, domyślnie 4. - Poziom paranoi od 1 do 4 w
crs-setup.conf: poziom 1 to zabezpieczenie podstawowe dla każdego serwera w internecie, poziom 2 pasuje według projektu do aplikacji z prawdziwymi danymi użytkowników, takich jak sklepy internetowe, poziomy 3 i 4 przynoszą wyraźnie więcej fałszywych alarmów.
Wyższy poziom paranoi wykrywa więcej, ale także generuje więcej fałszywych alarmów. Dla większości firmowych stron startem jest poziom 1, a późniejszym celem poziom 2.
Wdrażanie ModSecurity z OWASP CRS bez paraliżowania strony
Projekt CRS zaleca dla nowych instalacji włączenie trybu blokowania od początku, ale z bardzo wysokimi progami, do 10000, a następnie stopniowe ich obniżanie. W ten sposób zbierają Państwo doświadczenia z prawdziwymi wywołaniami bez wykluczania użytkowników. Progi ustawia się w crs-setup.conf:
# crs-setup.conf: faza startowa z bardzo wysokimi progami
SecAction \
"id:900110,\
phase:1,\
pass,\
t:none,\
nolog,\
setvar:tx.inbound_anomaly_score_threshold=10000,\
setvar:tx.outbound_anomaly_score_threshold=10000"
Włączenie w Apache następuje w kolejności, którą dokumentacja CRS podaje dla wtyczek. Ścieżki różnią się zależnie od dystrybucji:
<IfModule security2_module>
SecRuleEngine On
Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/plugins/*-config.conf
Include /etc/modsecurity/crs/plugins/*-before.conf
Include /etc/modsecurity/crs/rules/*.conf
Include /etc/modsecurity/crs/plugins/*-after.conf
</IfModule>
Następnie analizują Państwo log audytu, określony w SecAuditLog. Jak systematycznie przeszukiwać dzienniki, opisuje poradnik Analiza logów serwera WWW po ataku. Progi proszę obniżać stopniami, na przykład przez kilka tygodni, aż osiągną Państwo wartość domyślną.
Celowa obsługa fałszywych alarmów
Fałszywe alarmy są normalne, zwłaszcza w panelach CMS z edytorami zapisującymi HTML. Najgorszą reakcją jest wyłączenie WAF. Lepsze są dwa narzędzia.
Po pierwsze wtyczki: projekt CRS utrzymuje wtyczki z regułami wyjątków dla popularnych aplikacji, na przykład dla WordPress. Kopiuje się je do katalogu wtyczek i ładuje przez pokazane wyżej wiersze Include. Oficjalną listę prowadzi projekt w swoim katalogu wtyczek.
Po drugie własne, wąsko ujęte wyjątki. Zamiast wyłączać regułę wszędzie, usuwają ją Państwo tylko dla ścieżki, w której przeszkadza:
# Własny wyjątek, ładować PRZED regułami CRS (np. w pliku *-before.conf)
SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \
"id:1000010,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=941100"
Identyfikator reguły odczytują Państwo z logu audytu fałszywego alarmu. Każdy wyjątek proszę udokumentować z powodem i datą, aby można go było później zweryfikować.
Po każdej zmianie progów lub wyjątków proszę przetestować krytyczne ścieżki aplikacji: logowanie, zamówienie, płatność, formularz kontaktowy i redakcję. WAF, która blokuje zamówienia, szybko zostaje ponownie wyłączona.
W serwerach Apache warto zająć się WAF razem z resztą konfiguracji; podstawy opisuje artykuł Bezpieczna konfiguracja Apache dla PHP. Jak porównać reguły Cloudflare, pokazuje artykuł Reguły ochronne Cloudflare przeciw PHP2Shell. Środki przejściowe na samym serwerze znajdują się na stronie Środki doraźne, gdy nie mogą Państwo jeszcze załatać.
Wniosek: WAF wymaga pielęgnacji
ModSecurity z OWASP Core Rule Set daje Państwu wydajną Web Application Firewall bez kosztów licencji i bez zależności od zewnętrznej usługi. Ceną jest praca: wybrać silnik odpowiedni do serwera WWW, zacząć od wysokich progów, analizować fałszywe alarmy, utrzymywać wyjątki i aktualizować reguły.
Kto nie może zapewnić tego nakładu, często lepiej wychodzi na dobrze skonfigurowanej chmurowej WAF. Kto go zapewni, otrzymuje warstwę, która wychwytuje wiele standardowych ataków i dostarcza w logach audytu cennych wskazówek. W żadnym razie nie zastępuje aktualizacji: przed PHP2Shell chronią wyłącznie PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 lub potwierdzony backport, a następnie restart wszystkich procesów PHP.
Jak konkretnie pomaga PHP SOS?
- Wybór silnika: sprawdzamy serwer WWW, dystrybucję i dostępne pakiety oraz zalecamy odpowiednią kombinację.
- Wdrożenie: instalujemy CRS z wysokimi progami startowymi, włączamy odpowiednie wtyczki i konfigurujemy rejestrowanie.
- Dostrojenie: przez kilka tygodni analizujemy fałszywe alarmy, zakładamy celowe wyjątki i obniżamy progi.
- Ocena: w ramach WAF i wirtualnego łatania łączymy WAF ze środkami przejściowymi i drogą do regularnej poprawki.
Częste pytania
Czy OWASP CRS chroni przed PHP2Shell?
Nie powinni Państwo tego zakładać. Core Rule Set rozpoznaje ogólne wzorce ataków i nie jest dopasowany do konkretnej luki. Cloudflare zwraca ponadto uwagę, że w przypadku PHP2Shell same reguły oparte na danych żądania nie wystarczają. Aktualizacja PHP pozostaje obowiązkowa.
Jakiego silnika użyć dla Nginx?
Według projektu CRS przy ModSecurity v3 naprawdę produkcyjnie nadaje się tylko konektor Nginx, a v3 nie przechodzi niewielkiej części testów CRS. Alternatywą jest Coraza, która według informacji projektu w pełni przechodzi zestaw testów CRS v4. Dla Apache projekt zaleca ModSecurity v2.
Czy ModSecurity jest nadal rozwijany?
Według dokumentacji CRS Trustwave zapowiedział zakończenie rozwoju w 2024 roku. 25 stycznia 2024 projekt został przekazany OWASP Foundation i od tego czasu jest tam kontynuowany.
Jak zapobiec temu, by WAF nie sparaliżowała mojego sklepu?
Proszę zacząć od bardzo wysokich progów anomalii, jak zaleca projekt CRS, i obniżać je stopniowo. Przy tym analizować dzienniki i zakładać celowe wyjątki dla Państwa aplikacji, zamiast zbiorczo wyłączać reguły.