Mod security szabályrendszer?

Security-all

Apache verzióváltás után a mod_security modul rengeteg alapértelmezett szabállyal települt. (2.4-es apache)
Mivel a régi verzióban csak néhány saját fejlesztésű szabályom volt, örömmel megtartottam az újakat, remélve, nagyban növelik majd a szerver biztonságát.
Hát, tényleg. Túlságosan is. Már egy mezei Wordpress mentést is képesek blokkolni.
Tudtok ajánlani valamilyen jó szabályrendszert? Nem kell full-paranoid, de azért jó lenne, ha adna érdemi védelmet. A legfontosabb azonban, hogy feleslegesen ne blokkoljon kérelmeket.
Jelenleg egyesével ölöm ki a túl paranoid szabályokat, vagy emelem a ponthatárokat, de ez nem tűnik túl célravezető megoldásnak.

( airween v | 2019. 10. 17., cs – 14:02 )

Gondolom CRS-t telepített (rengeteg alapértelmezett szabály).

A megoldás nem feltétlen a szabályok kiírtása, vagy a ponthatár emelése. Ha tényleg CRS van fent, akkor a /etc/modsecurity/crs/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf fájlba vehetsz fel kivételeket (lásd a példákat 

ctl:ruleRemoveByID

, 

ctl:ruleRemoveByTag

, ill 

ctl:ruleRemoveByMsg

, ill nagyobb segítség lehet a 

ctl:ruleRemoveTargetById

. Mindegyikhez van elég jó példa.

Ha csak WP-hez kell, akkor érdemes megnézni ezt:

https://github.com/theMiddleBlue/wordpress-modsecurity-ruleset

Igen a CRS-t telepítette alapból.

Kiírtás alatt a ruleRemoveByID kizárásokat értettem. Ez volt a legegyszerűbb. Igazából azt nem értem, mit ér egy ennyire erős szabályrendszer, ha már a normál folyamatokat is megfogja, vagyis úgyis ki fogják kapcsolni?

Nemcsak WP-hez kell, de köszönöm a linket, mert lassan úgy érzem, a CRS maradéka már túl sokat nem véd. :O

Igazából azt nem értem, mit ér egy ennyire erős szabályrendszer, ha már a normál folyamatokat is megfogja, vagyis úgyis ki fogják kapcsolni?

A kérdés részben jogos, a szabályrendszer elég szigorú, elég sokat foglalkozik a csapat a false pozitív hibák redukálásával (CRS fejlesztő vagyok, vagy mi :)).

Szerintem érdemes lenne megnézni a konkrét esetet - most épp sehol nincs WP+ModSec+CRS környezet telepítve, nem tudom kipróbálni. Ha elküldöd a logokat (privátban), megpróbálom megnézni, mi lehet a gond. Szerintem inkább valami helyi megoldás miatt van ez. Az is lehet, hogy nem a CRS fogja meg a kérést, hanem maga az engine. Én pár hete telepítettem legutoljára egy helyre CRS+ModSec konfigot, ott Tomcat van valami saját API-val, és alig volt FP (false pozitív) találat. És azon belül is volt, ami az engine váltott ki (tehát maga a ModSec).

Nehéz olyan produktumot előállítani, ami mindenkinek megfelel. Ha a normál folyamatokon túli támadásokat nem fogja meg, akkor bizonyára annak is lenne visszhangja. A ModSecurity egy első generációs WAF, szerintem (és ez csak magánvélemény) a CRS-en keresztül nehéz lesz többet kihozni. Ezen kívül az üzemeltetéshez is egyre több ismeret kell (lásd a te eseted).

Nemcsak WP-hez kell, de köszönöm a linket, mert lassan úgy érzem, a CRS maradéka már túl sokat nem véd. :O

Ezt kicsit ellentmondásosnak érzem :).

A CRS egy részét te kapcsolod ki, mert úgy ítéled, hogy hibásan fogja meg a kéréseket - ez ok. De lehet, hogy a többi támadást meg pont a maradék fogná meg :).

Elég sok kérelmet megfogott. A legtöbbet úgy, hogy valamilyen CMS rendszer - általában WP - egy html tartalmat mentene el, és az elmentett kódot ítéli veszélyesnek.

Én ezt a naplóban látható logból tudom beazonosítani, de sokféle ilyen log bejegyzés van, ráadásul a bejegyzés - úgy látom - nem tartalmazza a teljes visszautasított adatot, hanem annak csak az elejét, így én a naplóból nem is látom, hogy konkrétan milyen tartalom miatt blokkolta az adott kérelmet. Pontosabban eddig egy olyan blokkolással sem találkoztam, ahol a felismertem volna, hogy mi volt a kritikus tartalom.

Ezek a naplóbejegyzések segítenének neked? Ezeket küldjem el?

A másik része, hogy webes levelezőfelület alatt is be volt kapcsolva, ahol egyértelműen támadásnak ítélt egyes elküldött e-mailes tartalmakat.

És természetesen igazad van, sok szabály maradt még a rendszerben, biztos védenek azok is, de nincs rálátásom - legalábbis annyira nem mélyedtem bele -, hogy mekkora hányad. Eddig 34 szabályt voltam kénytelen tiltani, de azt sem tudom, ezekből van-e olyan, ami más minták eredményét is értékeli, és így a tiltásával más szabályok is hatástalanok lettek-e.

Ezek a naplóbejegyzések segítenének neked? Ezeket küldjem el?

Igen, ez segítene - elvileg két állomány van, de mindegyik opcionális: a debug.log és az audit.log. Mindkettő tartalmazhat érzékeny adatokat, az audit.log a teljes request-et, szóval azt első körben nem kell küldeni, a debug.log-ban az IP-ket és a többi, általad érzékenynek ítélt adatot kicserélheted (hosztnév, ...).

Ha HTML tartalmat próbálsz menteni, akkor azt elég sok szabály megfogja - nehéz eldönteni egy kérésről, hogy az tényleg valid vagy sem.

A kivételek közé (REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf) fel tudod venni az egyes űrlapokat (akár vhoszt-onként), és hozzá csak az adott űrlap adott mezőjét. Ha tudod, hogy ott tényleg lesz HTML tartalom, akkor a kiemelés "hivatalos" formája ez.

Pl:

SecRule REQUEST_URI "@rx ^/(wp-admin|urlap)?" \ 
    "id:800001,\
    phase:1,\
    log,\
    pass,\
    ctl:ruleRemoveByTag=OWASP_CRS/WEB_ATTACK/XSS,\
    ctl:ruleRemoveTargetById=RULE_ID;ARGS:MEZO_NEVE,\
    ctl:ruleRemoveById=MASIK_RULE_ID,\
    ctl:ruleRemoveById=HARMADIK_RULE_ID,\
    ctl:ruleRemoveById=MEG_TOBB_RULE_ID,\
    ctl:ruleRemoveTargetById=ES_MEG;ARGS:MASIK_MEZO"

Ezt még akár ki is próbálhatod, mielőtt logot küldesz :). Mármint kicserélve tényleges adatokra, tehát megnézed a logot, melyik URI-re milyen szabályok ugrottak, esetleg a TAG-eket megnézni, azon belül jellemzően mely tag-ek fordulnak elő (ezzel vigyázz, csak mint lehetőséget írtam). De szerintem jól látható, hogy elég sok lehetőséged van.

Ha ezt a mintát követed, akkor egy esetleges frissítéskor sem lesz semmi gondod, nem vesznek el a kivételek (bár érdemes átnézni, hogy a szabályok ID-ja nem változott, jött-be új szabály, stb...).

Érdemes megnézni a doksit, melyik mit jelent. Fontos, hogy értsd, mit csinálsz, ez csak egy példa.