mod_security - Deutsche Umlaute false positive

Sagt mal, wer von euch nutzt mod_security. Ich meine damit die Version 2 bzw. genauer gesagt, die letzte 2.9.X aus der Reihe. Also nicht libmodsecurity aka ModSecurity v3.

Habe das gestern mal aktiviert, zum Glück nur mit Protokollierung und was soll ich sagen? 50% meiner Seiten wurden quasi gesperrt. Grund dafür scheinen deutsche Umlaute, aber auch andere Sonderzeichen zu sein, also im Grunde utf8-Sonderzeichen, wie ö, ü ä oder eben auch aus anderen Sprachen.

Geht das bei euch? Wenn ja, wie schaut denn euer Ruleset für die SecRule 941310 aus? Die löst hier nämlich zu 99% die false-positive aus. Und was sind das für RuleSets, also von wem, wie / von wo installiert?

Ich hatte hier anfangs die Sets von Debian, die waren vom Stand August 2021. Habe nun schon die neuen 3.4.0 von GitHub und weiterhin das Problem. Auch gibt es etliche Bugreports, die aber komischerweise alle als gelöst markiert sind, aber alle das gleiche Thema hatten.

Muss nun noch mal nachfragen, ob einer die Rule-Sets hat .... Scheint aber nun nicht nur deutsche Umlaute zu betreffen, sondern auch andere Daten.

Das hier: Der "Turm"! Hundefreundlich und eingezäunt.

Löst eine Sperre wegen einem angeblichen SQLi-Angriff aus

Genauer gesagt das da:

[msg "Detects MSSQL code execution and information gathering attempts"] [data "Matched Data: \x22! H found within ARGS

Also das "! oben im Text. Naja, so sonderlich selten ist die Kombination an Satzzeichen ja nicht wirklich.

Ausgelöst gleich mehrfach, in:

/usr/share/modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf

/usr/share/modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf

/usr/share/modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf

Also ich bin zu doof dazu, raffe es nicht oder das Modul ist wirklich scheiße, dabei soll es das Beste sein.....

Nächste Sperren, wegen einem BILD!

src="/bilder/kunden/1872/zusatzbilder/gross/essbereich-bora-1342218555.jpg"

Hier löst "ora-1342" die Sperre aus, wegen:

[msg "Oracle SQL Information Leakage"] [data "Matched Data: ora-1342 found within RESPONSE_BODY

Und nachdem die Rule auf alles reagiert, was "ORA-[0-9][0-9][0-9][0-9]" ist, also ora- + Ziffern, wird das sehr häufig sein. Gibt genug Bezeichnungen und Namen, die mit "ora" enden und dann in der URL ein timestamp, Kundennummer, Objektnummer, Datum oder sonstige Ziffern folgen.

Den Eindruck habe ich schon lange. Da das System aber millionenfach eingesetzt wird, scheint das Problem wohl eher hier bei mir zu suchen sein.

Habe ja auch schon viel gefunden, aber das hilft alles nicht weiter. Entweder ist das exakt der gleiche Fehler, aber keine Lösung oder es gibt vermeintlich eine Lösung, aber die ist dann mit meiner Version nicht nutzbar.

Der hier hat z.B. das gleiche Problem mit deutschen Umlauten:

https://github.com/SpiderLabs/owa…crs/issues/1645

Eigentlich ging es da erst um russische, da gab es schon vorher eine Bug-Meldung, aber dann kam er mit deutschen Zeichen. Genau das Gleiche habe ich hier, exakt das Gleiche. Auch so wie er beschreibt.

z.B.

Message: Warning. Pattern match "\\xbc[^\\xbe>]*[\\xbe>]|<[^\\xbe]*\\xbe" at ARGS:action_name. [file "/usr/share/modsecurity-crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "546"] [id "941310"] [msg "US-ASCII Malformed Encoding XSS Filter - Attack Detected"] [data "Matched Data: \xbcneburger heide > found within ARGS:action_name: ferienh\xc3\xa4user mit hund l\xc3\xbcneburger heide > urlaub mit hunden"]

Fehlerhaft und als XSS-Angriff wird hier das \xbc gewertet. Das ist in Kombination mit \xc3, also als \xc3\xbc schlicht ein deutsches "ü" als HEX utf8-kodiert. Mit dem "ä" als "\xc3\xa4" gibt es keine Probleme.

Der oben im Link hat das selbe Problem mit dem Wort Sitzbezüge, also als "sitzbez\xc3\xbcge". Auch hier wird \xbc falsch erkannt und blockiert.

Das andere oben mit dem Bild ist wieder was anderes. Hier erkennt eine Rule für "Oracle SQL" einen Angriff. Ich nutze aber gar kein Oracle, also ist das eigentlich schnuppe. Aber selbst wenn, die Zeichenfolge "ora" ist ja nicht selten. Cora, Kora, Nora etc. So noch kein Problem, aber wenn eine Ziffer danach kommt, zack, Erkennung. Also auch bei "Nora-2022", wenn das irgendwo im Text steht.

Und das mit dem "Turm"! ist ähnlich. Hier ist es eine Erkennung für MSSQL. Habe ich auch nicht in Verwendung. Steht aber irgendwo im Text die Zeichenfolge "!, also kodiert als %22! in einem Link oder JSON-LD oder sonst was, kodiert halt, dann wird gesperrt.

Dann gibt es da etliche gemeldete XSS-Angriffe. Vieles davon direkt von der Webseite, manches in Formularen, anderes durch Piwik. Ok, bei Piwik habe ich nun eine Mitteilung von 2014 gefunden, dass es mit mod_security nicht kompatibel ist. Ja, von 2014 und es zählt immer noch.

https://matomo.org/faq/troubleshooting/faq_100/

Habe ja, wie anfangs gesagt, schon die Rules v3.4.0 getestet. Nun gibt es neue DEV-Rules, die 3.4.2-DEV. In denen ist die Rule für die Umlaute geändert. Die könnte also gehen. Aber, dieses Ruleset 3.4.2 ist für meine Version von mod_secutity nicht kompatibel. Da müsste ich das Modul wechseln, das geht aber auch nicht, weil das neue nicht für Apache 2.4 gedacht ist, sondern für Apache 2.5 bzw. nginx.