Wenn eine bestehende Regel aus dem OWASP Core Ruleset für eine spezielle Applikation verändert werden soll, muss dies über eine eigene Regel erfolgen. Hierbei ist möglich, mehrfache Aktionen in einer Regel auszuführen. Hierfür werden die Aktionen durch ein „,“ getrennt angegeben.

 ctl:ruleRemovebyId=XXXXX,ctl:ruleRemoveTargetById=XXXXX;TARGET

Die IDs der Regeln können auch als Bereich angegeben werden.

10000-10010

möchte man anhand von Dateien Allow/Deny Listen als Basis verwenden kann @pmfromfile / @pmf verwendet werden.

Die originale Beschreibung ist unter Reference Manual (v2.x) · SpiderLabs/ModSecurity Wiki · GitHub zu funden

Hierbei wird in einer Referenzierten Datei nach dem Pattern gesucht.
Jede Zeile muss einen Pattern enthalten.

Als Beispiel soll die Regel 931130 aus OWASP verwendet werden.
Die Regel unterbindet das Einbinden externer Inhalte (Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link)
Erlaubt ist ausschließlich der über die Request Header identifizierte Host.

SecRule ARGS "@rx ^(?i:file|ftps?|https?)://([^/]*).*$" \
    "id:931130,\
    phase:2,\
    block,\
    capture,\
    t:none,\
    msg:'Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link',\
    logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
    tag:'application-multi',\
    tag:'language-multi',\
    tag:'platform-multi',\
    tag:'attack-rfi',\
    tag:'OWASP_CRS',\
    tag:'capec/1000/152/175/253',\
    tag:'paranoia-level/2',\
    ctl:auditLogParts=+E,\
    ver:'OWASP_CRS/3.3.2',\
    severity:'CRITICAL',\
    setvar:'tx.rfi_parameter_%{MATCHED_VAR_NAME}=.%{tx.1}',\
    chain"
    SecRule TX:/rfi_parameter_.*/ "!@endsWith .%{request_headers.host}" \
        "setvar:'tx.rfi_score=+%{tx.critical_anomaly_score}',\
        setvar:'tx.anomaly_score_pl2=+%{tx.critical_anomaly_score}'"

Möchte man nun das Einbinden externer Inhalte erlauben und einen False Positive Alert in den Logs vermeiden, muss die Regel angepasst werden.

Hierfür kann man eine ersetzende Regel einfügen, die eine weitere Regel als chain hinzufügt.

chain"
    SecRule TX:/rfi_parameter_.*/ "!@endsWith .%{request_headers.host}" \
        "chain"
        SecRule TX:/rfi_parameter_.*/ "!@pmf /etc/httpd/crs/rules/whitelist_RFI" \
            "setvar:'tx.rfi_score=+%{tx.critical_anomaly_score}',\
            setvar:'tx.anomaly_score_pl2=+%{tx.critical_anomaly_score}'"

Die zusätzliche chained Regel wird als UND in die Bedingungen der Regeln eingefügt.
Durch den Operator „!“ wird die Bedingung negiert. Dadurch entsteht eine Allow Liste als Ausnahme für die Regel.

Die Datei /etc/httpd/crs/rules/whitelist_RFI wird dann mit den Domainnamen gefüllt, von denen das Einbinden erlaubt werden soll.

www.beispiel.de

Mir ist noch nicht ganz klar nach welchem Prinzip das Matching ausgeführt wird. Aktuell erscheint es ein reiner Vergleich der Strings zu sein und kein regulärer Ausdruck.

Soweit ich es bisher nachvollziehen konnte ist eine Neustart des Webservers notwendig, wenn neue Einträge in die Datei eingefügt wurden.

Achtung: grundsätzlich ist das Einbinden von externen Inhalten nur sehr vorsichtig zu ermöglichen. Die Anpassung der entsprechenden Regeln in ModSecurity dienen dem Reduzieren von False Positives. Wird z.B. ein Content Security Header verwendet, muss die Konfiguration auch hier berücksichtigt werden.

modesecurity protokiliert im Audit Log alle Informationen eines Requests. Das kann auch sensible Informationen betreffen wie z.B. in POST Requests übermitelte Passworte.
Um zu verhindern, dass Passworte im Klartext innerhalb des Audit Logs protokolliert werden, müssen Anwendungsspezifische Regeln erstellt werden, die dafür sorgen, dass die betroffenen Parmeter verschleiert werden. Die Inhalte werden dann im Audit Log * ersetzt.

Die folgenden Actions stehen hierfür zur Verfügung

• sanitiseArg
• sanitiseRequestHeader
• sanitiseResponseHeader
• sanitiseMatched
• sanitiseMatchedBytes

Eine genauere Beschreibung der einzelnen Parameter ist unter Reference Manual (v2.x) Actions · SpiderLabs/ModSecurity Wiki · GitHub zu finden.

Die folgende Regel unterbindet z.B. das Protokollieren des Arguments password

SecAction "id:XXXXX, phase:5, nolog, pass,\
          sanitiseArg:password"

zum Analysieren einzelner Regeln bietet es sich an das Debugging innerhalb der Regel zu aktivieren.

Hierfür kann ein zusätzlicher ctl Parameter in die Regel eingefügt werden.

 ctl:debugLogLevel=9,\

Detail zum Logging sind unter ModSecurity Handbook: Getting Started: Chapter 4. Logging (feistyduck.com) zu finden.