ModSecurity: Whitelist-Argumente nach Wert

Question

Ich versuche, eine ModSecurity-Whitelist für Argumente mit einem unbekannten Namen einzurichten, aber einen Wert übereinstimmen. Zum Beispiel möchte ich einen beliebigen Parameter, der ein Zeitstempel ist, auf die weiße Liste setzen (z. B. timestamp=2016-01-01 00:00:00). Derzeit löst diese Regel aus 981173 (Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded)

Das folgende funktioniert, aber Überprüfungen auf alle Parameter überspringen, wenn mindestens eins übereinstimmt, so dass es den badvalue-Parameter in https://www.example.com/?timestamp=2016-01-01+00:00:00&badvalue=2016-01-01+00:00:00:00 nicht abfängt.

SecRule ARGS "@rx ^2[0-9]{3}-[0-1][0-9]-[0-3][0-9] [0-2][0-9]:[0-5][0-9]:[0-5][0-9]$" \ 
    "id:'99001', phase:1, nolog, pass, t:none, \ 
    ctl:ruleRemoveTargetByTag=OWASP_CRS/WEB_ATTACK/SQL_INJECTION;ARGS" 

Die folgenden funktioniert, wenn ich den Parameternamen fest codiere.

SecRule ARGS:timestamp "@rx ^2[0-9]{3}-[0-1][0-9]-[0-3][0-9] [0-2][0-9]:[0-5][0-9]:[0-5][0-9]$" \ 
    "id:'99001', phase:1, nolog, pass, t:none, \ 
    ctl:ruleRemoveTargetByTag=OWASP_CRS/WEB_ATTACK/SQL_INJECTION;ARGS:timestamp" 

Ich habe Folgendes versucht, aber sie haben nicht funktioniert.

SecRule ARGS "@rx ^2[0-9]{3}-[0-1][0-9]-[0-3][0-9] [0-2][0-9]:[0-5][0-9]:[0-5][0-9]$" \ 
    "id:'99001', phase:1, nolog, pass, t:none, \ 
    ctl:ruleRemoveTargetByTag=OWASP_CRS/WEB_ATTACK/SQL_INJECTION;/%{MATCHED_VAR_NAME}/" 

SecRule ARGS "@rx ^2[0-9]{3}-[0-1][0-9]-[0-3][0-9] [0-2][0-9]:[0-5][0-9]:[0-5][0-9]$" \ 
    "id:'99001', phase:1, nolog, pass, t:none, \ 
    ctl:ruleRemoveTargetByTag=OWASP_CRS/WEB_ATTACK/SQL_INJECTION;MATCHED_VAR_NAME" 

Ist dies mit ModSecurity möglich? Gibt es eine Möglichkeit, MATCHED_VAR_NAME für diesen Anwendungsfall zu verwenden? Ich würde eher nicht für jeden Argumentnamen, der einen Zeitstempel enthalten könnte, eine Regel hinzufügen müssen.

Answer 1

Leider ist es derzeit nicht möglich, die Makroerweiterung innerhalb des ctl-Aktionsarguments zu verwenden.

Als Beweis beachten Sie die folgenden Beispiele:

SecRule ARGS "@contains bob" "id:1,t:none,pass,ctl:ruleRemoveTargetById=2;ARGS:x" 
SecRule ARGS "@contains hello" "id:2,deny,status:403" 

Wenn die folgende Anforderung bereitstellt: ‚http://localhost/?x=bobhello‘ Wir werden die folgenden im Debug-Protokoll sehen, wenn die zweite Regel Auswertung

[04/Aug/2016: 00: 44: 07 --0400] [localhost/sid # 55e47aa583e0] [rid # 55e47ad7cb10] [/] [4] Rezept: Aufruf der Regel 55e47ab14638; [Datei "/etc/httpd/modsecurity.d/includeOWASP.conf"] [Zeile "12"] [ID "2"]. [04/Aug/2016: 00: 44: 07 --0400] [localhost/sid # 55e47aa583e0] [rid # 55e47ad7cb10] [/] [5] Regel 55e47ab14638: SecRule "ARGS" "@contains hallo" "phase: 2, log, auditlog, id: 2, verweigern, Status: 403 " [04/Aug/2016: 00: 44: 07 --0400] [localhost/sid # 55e47aa583e0] [rid # 55e47ad7cb10] [/] [4 ] Umwandlung in 0 Usec abgeschlossen. [04/Aug/2016: 00: 44: 07 --0400] [localhost/sid # 55e47aa583e0] [los # 55e47ad7cb10] [/] [9] fetch_target_exception: Gefundene Ausnahme Zielliste [ARGS: x] für Regel ID 2 [04/Aug/2016: 00: 44: 07 --0400] [localhost/sid # 55e47aa583e0] [los # 55e47ad7cb10] [/] [9] fetch_target_exception: Ziel ARGS: x wird nicht verarbeitet. [04/Aug/2016: 00: 44: 07 --0400] [localhost/sid # 55e47aa583e0] [rid # 55e47ad7cb10] [/] [4] Ausführungsoperator "contains" mit param "hallo" gegen ARGS: x übersprungen . [04/Aug/2016: 00: 44: 07 --0400] [localhost/sid # 55e47aa583e0] [rid # 55e47ad7cb10] [/] [4] Regel zurückgegeben 0.

Wenn wir jedoch bieten die gleiche Anfrage ('http://localhost/?x=bobhello') Während Makroerweiterung innerhalb unserer ctl Wirkung haben (wie folgt):

SecRule ARGS "@contains bob" "id:1,t:none,pass,ctl:ruleRemoveTargetById=2;%{MATCHED_VAR_NAME}" 
SecRule ARGS "@contains hello" "id:2,deny,status:403" 

unsere Debug-Log erscheint wie folgt:

[04/Aug/2016: 00 : 44: 41 --0400] [localhost/sid # 559f82a0b3e0] [rid # 559f82d2fb50] [/] [5] Regel 559f82ac76e8: SecRule "ARGS" "@ enthält hallo "" phase: 2, log, auditlog, id: 2, verweigern, status: 403 " [04/Aug. 2016: 00: 44: 41 --0400] [localhost/sid # 559f82a0b3e0] [los # 559f82d2fb50 ] [/] [4] Umwandlung in 0 Usec abgeschlossen. [04/Aug. 2016: 00: 44: 41 --0400] [localhost/sid # 559f82a0b3e0] [rid # 559f82d2fb50] [/] [9] fetch_target_exception: Gefundene Ausnahmeliste [% {MATCHED_VAR_NAME}] für Regel-ID 2 [04/Aug/2016: 00: 44: 41 --0400] [localhost/sid # 559f82a0b3e0] [rid # 559f82d2fb50] [/] [4] Ausführungsoperator "enthält" mit param "Hallo" gegen ARGS : x. [04/Aug/2016: 00: 44: 41 --0400] [localhost/sid # 559f82a0b3e0] [rid # 559f82d2fb50] [/] [9] Zielwert: "bobhello" [04/Aug/2016: 00 : 44: 41 --0400] [localhost/sid # 559f82a0b3e0] [rid # 559f82d2fb50] [/] [4] Operator in 2 Usec abgeschlossen. [04/Aug/2016: 00: 44: 41 --0400] [localhost/sid # 559f82a0b3e0] [rid # 559f82d2fb50] [/] [4] Regel zurück 1.

Ich kann nicht glauben, der ein Methode zur Erreichung dieses Ziels ohne übermäßigen Aufwand. An diesem Punkt wäre es wahrscheinlich die beste Lösung, jedes beleidigende Argument manuell auf die weiße Liste zu setzen.