# A ModSecurity és az OWASP Core Rule Set alkalmazása

> A ModSecurity és az OWASP CRS alkalmazása: engine kiválasztása, anomália-küszöbök és paranoia-szintek megértése, a téves riasztások célzott kezelése.

Forrás: https://phpsos.de/hu/blog/modsecurity-owasp-crs/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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ő](https://phpsos.de/hu/blog/waf-oder-update/) í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.

1. Súlyossági fokozatok: kritikus 5 pont, hiba 4, figyelmeztetés 3, megjegyzés 2.
2. A kérések küszöbe: `tx.inbound_anomaly_score_threshold`, alapértelmezés 5.
3. A válaszok küszöbe: `tx.outbound_anomaly_score_threshold`, alapértelmezés 4.
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:

```apache
# 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:

```apache
<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](https://phpsos.de/hu/ratgeber/logfiles-auswerten/) í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:

```apache
# 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.

> **Tipp:**
> 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](https://phpsos.de/hu/blog/apache-fuer-php-absichern/) tartalmazza. Hogyan sorolhatók be a Cloudflare-szabályok összehasonlításban, azt a [Cloudflare védőszabályok a PHP2Shell ellen](https://phpsos.de/hu/blog/cloudflare-waf-php2shell/) mutatja. A szerveren végrehajtható átmeneti intézkedések az [Azonnali intézkedések, ha még nem tud javítani](https://phpsos.de/hu/php2shell/sofortmassnahmen-ohne-patch/) 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](https://phpsos.de/hu/leistungen/waf-virtuelles-patching/) 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.

## Források

- [OWASP CRS: dokumentáció](https://coreruleset.org/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [Cloudflare-blog](https://blog.cloudflare.com/)
- [php.net: biztonsági közlemények](https://www.php.net/)