Coreruleset und mod_security -> kein JSON Support!

browsingman · 17. Februar 2021

Mit 0.375 wurde als Neuerung coreruleset mit aufgeführt.

Gleichwohl ist in den Templates dazu keine Konfiguration in der pdadmin SE-Umgebung zu finden.

Ich vermute mal, das hier noch weitere Anpassungen / Konfiguration von Herrn Bradler für Folge-Releases geplant sind.

Aus meiner Sicht müsste hier auch eine .conf Datei für mod_security beigefügt werden.

Ich habe testhalber mal eine Datei modsecurity.conf erstellt:

Code

SecRuleEngine On
SecRequestBodyAccess On
SecRule REQUEST_HEADERS:Content-Type "(?:application(?:/soap\+|/)|text/)xml" \
     "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
SecRule REQUEST_HEADERS:Content-Type "application/json" \
     "id:'200001',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072
SecRequestBodyLimitAction Reject
SecRule REQBODY_ERROR "!@eq 0" \
"id:'200002', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2"
SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
"id:'200003',phase:2,t:none,log,deny,status:400, \
msg:'Multipart request body failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_MISSING_SEMICOLON}, \
IQ %{MULTIPART_INVALID_QUOTING}, \
IP %{MULTIPART_INVALID_PART}, \
IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"
SecRule MULTIPART_UNMATCHED_BOUNDARY "@eq 1" \
    "id:'200004',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"
SecPcreMatchLimit 500000
SecPcreMatchLimitRecursion 500000
SecRule TX:/^MSC_/ "!@streq 0" \
        "id:'200005',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"
SecResponseBodyAccess On
SecResponseBodyMimeType text/plain text/html text/xml
SecResponseBodyLimit 524288
SecResponseBodyLimitAction ProcessPartial
SecTmpDir /tmp/
SecDataDir /tmp/
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIJDEFHZ
SecAuditLogType Serial
SecAuditLog /usr/local/pd-admin2/logs/modsec_audit.log
SecArgumentSeparator &
SecCookieFormat 0
#SecUnicodeMapFile unicode.mapping 20127
SecStatusEngine On

Alles anzeigen

Ergänzend habe ich dann noch folgende Zeilen in der httpd24.conf-template eingefügt:

Code

include /usr/local/pd-admin2/httpd-2.4/conf/modsecurity.conf
include /usr/local/pd-admin2/httpd-2.4/conf/coreruleset-3.3.0/crs-setup.conf
include /usr/local/pd-admin2/httpd-2.4/conf/coreruleset-3.3.0/rules/*.conf

Im Ordner coreruleset-3.3.0 sowie im Ordner coreuleset-3.3.0/rules habe ich die *.example in *.conf umbenannt und in der Konfigurationsdatei crs-setup.conf noch folgende Regel aktiviert, damit die gängigen Produkte wie nextcloud und wordpress nicht pauschal geblockt werden.

Code

SecAction \
 "id:900130,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_exclusions_drupal=1,\
  setvar:tx.crs_exclusions_dokuwiki=1,\
  setvar:tx.crs_exclusions_nextcloud=1,\
  setvar:tx.crs_exclusions_wordpress=1

Grundsätzlich würde das nach einem Neustart des Apache Webservers so gut funktionieren, ABER es muss noch eine weitere Voraussetzung erfüllt sein:

Das mod_security Modul müsste mit JSON Support kompiliert werden. Aktuell ist es das nicht.

Es wäre schön, wenn man diesen "Bug" noch mit dem nächsten SE-Update lösen würde