Modsecurity im Produktiveinsatz – wp-cron.php

Ich bin im Moment gerade dabei, ein wenig mit modsecurity zu kämpfen. Kämpfen, ja das kommt ungefähr hin.

Solange man sich mit seinen FalsePositives in der Phase2 bewegt, kann man problemlos per LocationMatch Ausnahmen erstellen. Wenn jedoch bereits in Phase 1 Falscherkennungen stattfinden, greift LocationMatch nicht mehr.

Beispielsweise hätten wir hier so einen Fall:

 ModSecurity: Access denied with code 403 (phase 1). Operator EQ matched 0 at REQUEST_HEADERS. [file „/usr/share/modsecurity-crs/base_rules/modsecurity_crs_20_protocol_violations.conf“] [line „312“] [id „960012“] [rev „1“] [msg „POST request missing Content-Length Header.“] [data „0“] [severity „WARNING“] [ver „OWASP_CRS/2.2.9“] [maturity „9“] [accuracy „9“] [tag „OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ“] [tag „CAPEC-272“] [hostname „www.example.com“] [uri „/wp-cron.php“] [unique_id „WGUSaFmj4VQAAALcXyYAAAAI“]

Laut Logfile, wird hier in Phase 1 mit einem 403 zurückgeschossen. Bei dem aufgerufenen uri, handelt es sich jedoch um wp-cron.php, welches vom Webserver selbst (WordPress) gestartet wird.

Da wir uns in besagter Phase 1 befinden, kann man nicht per LocationMatch arbeiten.

Ich bin momentan noch auf der Suche nach einer Lösung…