Röviden: A ModSecurity egy Web Application Firewall, amely a webszerverben fut; az OWASP Core Rule Set (CRS) hozzá szabadon elérhető szabályokat ad az elterjedt támadástípusok ellen. Az Apache-hoz a CRS-projekt a ModSecurity v2-t javasolja, az Nginxhez a v3-connector vagy a Coraza jöhet szóba. Blokkoló módban induljon nagyon magas anomália-küszöbökkel, csökkentse őket fokozatosan, és a téves riasztásokat célzott kivételekkel kezelje. Egy PHP-frissítést ez nem pótol.
Egy saját WAF kiegészítő rétegként
A PHP2Shell óta sok vállalkozás kérdezi, kell-e Web Application Firewall. Aki a weboldalait a Cloudflare-en keresztül szolgálja ki, annál a Cloudflare szerint 2026. október 21. óta automatikusan aktívak a védőszabályok. Aki ezt nem teszi, vagy nem akarja harmadik félen keresztül vezetni az adatforgalmat, a WAF-ot közvetlenül a saját szerverén is működtetheti.
Erre a legismertebb kombináció a ModSecurity az OWASP Core Rule Settel. Mindkettő nyílt forráskódú és ingyenes. A CRS általános felismerési szabályok gyűjteménye, például az SQL-injection, a cross-site scripting vagy a fájlok bejuttatása ellen. A projekt maga úgy írja le a célját, hogy általános támadásfelismerés a lehető legkevesebb téves riasztással, egy építőelem a több közül.
Ezzel a határ is meg van nevezve. Egy WAF a kéréseket és a válaszokat ellenőrzi, a PHP-értelmezőben lévő rést nem javítja ki. Hogy miért kell mindkettő, azt a WAF vagy frissítés: miért kell mindkettő írja le.
Melyik engine illik a webszerveréhez
A szabályrendszerhez szükség van egy engine-re, amely végrehajtja. A CRS dokumentációja szerint három kompatibilis lehetőség van:
| Engine | Webszerver | Besorolás a CRS-projekt szerint |
|---|---|---|
| ModSecurity v2 | Apache (modul) | referencia-implementáció, az Apache-hoz ajánlott |
| ModSecurity v3 (libModSecurity) | főként Nginx connectoron át | csak az Nginx-connector használható valóban éles üzemben; a CRS-tesztek 2-4 százalékán megbukik |
| Coraza | Go-alapú proxyk és integrációk | teljesen megfelel a CRS v4 tesztkészletének |
A háttérhez: a ModSecurityt sokáig a Trustwave fejlesztette. A Trustwave 2021-ben bejelentette, hogy 2024-ben megszünteti a fejlesztést. 2024. január 25-én a projekt átkerült az OWASP Foundationhöz. Új telepítéseknél ellenőrizze, melyik verziót szállítja a disztribúciója, és mennyire aktuális.
Így működik a Core Rule Set
A CRS alapbeállításban nem az első gyanús feltűnőségnél blokkol. Anomália-pontokkal dolgozik: minden kiváltott szabály a súlyossága szerint pontokat ad hozzá, és csak ha az összeg átlép egy küszöböt, utasítják el a kérést.
- Súlyossági fokozatok: kritikus 5 pont, hiba 4, figyelmeztetés 3, megjegyzés 2.
- A kérések küszöbe:
tx.inbound_anomaly_score_threshold, alapértelmezés 5. - A válaszok küszöbe:
tx.outbound_anomaly_score_threshold, alapértelmezés 4. - Paranoia-szint 1-től 4-ig a
crs-setup.conf-ban: az 1. szint az alapvédelem az interneten lévő minden szerverhez, a 2. szint a projekt szerint valódi felhasználói adatokat kezelő alkalmazásokhoz illik, mint a webshopok, a 3. és 4. szint lényegesen több téves riasztást hoz.
Egy magasabb paranoia-szint többet ismer fel, de több téves riasztást is okoz. A legtöbb vállalati weboldalnál az 1. szint a kiindulópont, a 2. egy későbbi cél.
A ModSecurity és az OWASP CRS bevezetése a weboldal megbénítása nélkül
A CRS-projekt új telepítésekhez azt javasolja, hogy a blokkoló módot már az elejétől kapcsolják be, de nagyon magas küszöbökkel, akár 10000-ig, és ezeket fokozatosan csökkentsék. Így valódi hozzáférésekkel gyűjthet tapasztalatot a felhasználók kizárása nélkül. A küszöböket a crs-setup.conf-ban állítsa be:
# crs-setup.conf: kezdő fázis nagyon magas küszöbökkel
SecAction \
"id:900110,\
phase:1,\
pass,\
t:none,\
nolog,\
setvar:tx.inbound_anomaly_score_threshold=10000,\
setvar:tx.outbound_anomaly_score_threshold=10000"
Az Apache alatti beágyazás a CRS dokumentációja által a pluginokra előírt sorrendet követi. Az útvonalak disztribúciónként eltérnek:
<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>
Ezután értékelje ki az audit-naplót, amelyet a SecAuditLog határoz meg. Hogyan kutassa át rendszeresen a naplókat, azt a Webszerver-naplók kiértékelése támadás után írja le. A küszöböket fokozatosan csökkentse, például több héten át, amíg el nem éri az alapértéket.
A téves riasztások célzott kezelése
A téves riasztások normálisak, különösen a HTML-t mentő szerkesztőkkel rendelkező CMS-háttérrendszerekben. A legrosszabb reakció a WAF kikapcsolása. Jobb két eszköz.
Először a pluginok: a CRS-projekt olyan pluginokat gondoz, amelyek kivételszabályokat tartalmaznak elterjedt alkalmazásokhoz, például a WordPresshez. Ezeket a plugin-mappába kell másolni, és a fent mutatott Include sorokon át betölteni. A hivatalos listát a projekt a plugin-jegyzékében vezeti.
Másodszor saját, szűken meghatározott kivételek. Ahelyett hogy egy szabályt mindenhol kikapcsolna, csak azon az útvonalon veszi ki, ahol zavar:
# Saját kivétel, a CRS-szabályok ELŐTT betölteni (pl. egy *-before.conf-ban)
SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \
"id:1000010,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=941100"
A szabályazonosítót a téves riasztás audit-naplójából veszi. Dokumentáljon minden kivételt okkal és dátummal, hogy később felülvizsgálható legyen.
A küszöbök vagy kivételek minden módosítása után tesztelje az alkalmazás kritikus útjait: bejelentkezés, rendelés, fizetés, kapcsolatfelvételi űrlap és szerkesztőség. Egy rendeléseket blokkoló WAF-ot gyorsan újra kikapcsolnak.
Az Apache-szervereknél megéri a WAF-ot a többi konfigurációval együtt megközelíteni; az alapokat az Az Apache biztonságos konfigurálása PHP-hez tartalmazza. Hogyan sorolhatók be a Cloudflare-szabályok összehasonlításban, azt a Cloudflare védőszabályok a PHP2Shell ellen mutatja. A szerveren végrehajtható átmeneti intézkedések az Azonnali intézkedések, ha még nem tud javítani oldalon találhatók.
Összegzés: a WAF-nak gondozás kell
A ModSecurity az OWASP Core Rule Settel licencköltség és külső szolgáltatástól való függés nélkül ad Önnek egy hatékony Web Application Firewallt. Az ára a munka: az engine kiválasztása a webszervernek megfelelően, kezdés magas küszöbökkel, a téves riasztások kiértékelése, a kivételek gondozása és a szabályok naprakészen tartása.
Aki ezt a ráfordítást nem tudja vállalni, gyakran jobban jár egy jól konfigurált felhő-WAF-fal. Aki vállalja, olyan réteget kap, amely sok szokásos támadást elfog, és az audit-naplókban értékes jelzéseket szolgáltat. Egyik esetben sem pótolja a frissítést: a PHP2Shell ellen csak a PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 vagy egy megerősített backport véd, amelyet az összes PHP-folyamat újraindítása követ.
Hogyan segít konkrétan a PHP SOS?
- Engine kiválasztása: Ellenőrizzük a webszervert, a disztribúciót és a meglévő csomagokat, és javaslunk megfelelő kombinációt.
- Bevezetés: Telepítjük a CRS-t magas kezdőküszöbökkel, beágyazzuk a megfelelő pluginokat, és beállítjuk a naplózást.
- Hangolás: Több héten át kiértékeljük a téves riasztásokat, célzott kivételeket hozunk létre, és csökkentjük a küszöböket.
- Besorolás: A WAF és virtuális javítás keretében összekötjük a WAF-ot az átmeneti intézkedésekkel és a rendes javításhoz vezető úttal.
Gyakori kérdések
Véd az OWASP CRS a PHP2Shell ellen?
Ebből ne induljon ki. A Core Rule Set általános támadási mintákat ismer fel, és nincs egy konkrét résre szabva. A Cloudflare emellett rámutat, hogy a PHP2Shellnél a kérésadatok alapján felállított szabályok önmagukban nem elegendők. A PHP-frissítés kötelező marad.
Melyik engine-t válasszam Nginxhez?
A CRS-projekt szerint a ModSecurity v3-nál csak az Nginx-connector használható valóban éles üzemben, és a v3 a CRS-tesztek egy kis részén megbukik. Alternatíva a Coraza, amely a projekt adatai szerint teljesen megfelel a CRS v4 tesztkészletének. Az Apache-hoz a projekt a ModSecurity v2-t javasolja.
Gondozzák még a ModSecurityt?
A CRS dokumentációja szerint a Trustwave bejelentette, hogy 2024-ben megszünteti a fejlesztést. 2024. január 25-én a projektet átadták az OWASP Foundationnek, és azóta ott viszik tovább.
Hogyan akadályozom meg, hogy a WAF megbénítsa a webshopomat?
Induljon nagyon magas anomália-küszöbökkel, ahogyan a CRS-projekt javasolja, és csökkentse őket fokozatosan. Közben értékelje ki a naplókat, és célzott kivételeket hozzon létre az alkalmazásához, ahelyett hogy átalányban kikapcsolna szabályokat.