403 nach SQLmap attack

    Moin in die Runde! Ich oute mich mal direkt als absoluter Noob und freu mich wirklich sehr auf Unterstützung :)

    Kurz zum Hintergrund:

    Ich habe nun ziemlich frisch seit 3 Tagen einen vserver (notgedrungen) und habe auf diesem diverse Domains eingerichtet, was soweit alles fein funktioniert.


    Anschließend habe ich in einzelnen Domains WordPress sowie WooCommerce installiert und komme direkt nach der Installation weder auf die Homepage noch in die WP-Admin quittiert mit Fehler 403.


    Nach einiger Recherche habe ich das Problem eventuell in der WAF identifizieren können:


    [client XXXXXXXXXXX] ModSecurity: Access denied with code 403 (phase 2). Pattern match "[\\\\[\\\\]\\\\x22',()\\\\.]{10}$|\\\\b(?:union\\\\sall\\\\sselect\\\\s(?:(?:null|\\\\d+),?)+|order\\\\sby\\\\s\\\\d{1,4}|(?:and|or)\\\\s\\\\d{4}=\\\\d{4}|waitfor\\\\sdelay\\\\s'\\\\d+:\\\\d+:\\\\d+'|(?:select|and|or)\\\\s(?:(?:pg_)?sleep\\\\(\\\\d+\\\\)|\\\\d+\\\\s?=\\\\s?(?:dbms_pipe\\\\.receive_message\\\\ ..." at REQUEST_COOKIES:sbjs_first. [file "/etc/apache2/modsecurity.d/rules/comodo_free/22_SQL_SQLi.conf"] [line "64"] [id "218500"] [rev "18"] [msg "COMODO WAF: SQLmap attack detected||hyggeyule.com|F|2"] [data "Matched Data: |||tct=(none) found within REQUEST_COOKIES:sbjs_first: typ=typein|||src=(direct)|||mdm=(none)|||cmp=(none)|||cnt=(none)|||trm=(none)|||id=(none)|||plt=(none)|||fmt=(none)|||tct=(none)"] [severity "CRITICAL"] [tag "CWAF"] [tag "SQLi"] [hostname "hyggeyule.com"] [uri "/wp-json/wp/v2/users/me"] [unique_id "Zwah3KDA8lAdvywPXSLE4QAAAEo"], referer: https://hyggeyule.com/wp-admin/plugins.php


    Deaktiviere ich nun die Regel "218500" im WAF, komme ich auf die Homepage und in die WP Administration. So eine Ausnahme kann und soll keine Dauerlösung bleiben, daher die Frage, wo nun tatsächlich das Problem liegt?


    Freue mich auf Ideen und Ratschläge.


    Grüße

    Naja, eine WAF ist kein festes Regelwerk, das für alle Applikation immer gleich sein muss. Das muss individuell angepasst werden. Einfach nur blind alle Regel zu aktivieren wird meist nicht zum Ziel führen. Eine vorkonfigurierte Regel in der WAF zu deaktivieren, damit die Applikation läuft, ist eigentlich völlig in Ordnung. Daher kann das durchaus eine Dauerlösung sein. Mit anderen Security Tool (z.B. ist es ähnlich). Auch da dauert es gerade zu Beginn einige Zeit, bis man die Fehler identifiziert und Ausnahmen konfiguriert hat.

    Wenn man nach Comodo Free und Woocommerce googelt, findent man schnell, dass die beiden (leicht übertrieben) so ca alle 5 Minuten Probleme miteinander haben. Ein "false positive" nach dem Anderen. Wie Paul schon geschrieben hat... Die Regel in der WAF deaktivieren, sofern es keinen anderen Lösungsvorschlag von WooCommerce gibt. Hier könnte man alternativ das im obigen Link von NaN beschriebene Tracking Feature deaktivieren. Musst du dann eben entscheiden, ob das für dich wichtig ist oder (zumindest vorübergehend) deaktiviert werden kann.

    Ja, eine WAF wird zwangsläufig auch "false positives" produzieren.

    (Zitat: "Any WAF produces false positives. If it does not produce false positives, then it’s probably dead" ^^ )

    Man muss die WAF halt nach und nach anpassen und Ausnahmeregeln erstellen.


    Regeln zu deaktivieren ist völlig OK. Es ist aber oft besser, nicht die ganze Regel abzuschalten, sondern nur selektiv für bestimmte Apps oder Unterseiten. In deinem Fall:

    Code
    SecRule REQUEST_URI "@beginsWith /WORDPRESSPATH/" "id:UNIQUEID,phase:2,pass,nolog,t:none,ctl:ruleRemoveById=218500"

    Dann bleibt sie für den Rest weiterhin aktiv.


    Für Wordpress gibt es sogar eine vordefiniertes Ausnahmepaket, das man aktivieren kann:

    Code
    SecRule REQUEST_URI "@beginsWith /WORDPRESSPATH/" "id:UNIQUEID2,phase:1,pass,nolog,t:none,setvar:tx.crs_exclusions_wordpress=1"


    Manchmal schalte ich in CMSystemen auch für das Backend die Engine für POST komplett ab. (Da ist man ja eingeloggt und GETs von außerhalb werden weiter geblockt) z.B.:

    Code
    SecRule REQUEST_URI "@beginsWith /CMS/administrator/" "id:ANOTHERID,phase:2,allow,nolog,t:none,chain"
SeCRule REQUEST_METHOD "POST" "ctl:ruleEngine=off"


    Im Übrigen kann das Finetuning von Modsecurity durchaus aufwändig werden, wenn man nicht zuviel durchlassen will.

    Ich hatte mir dafür mal ein Hilfstool gestrickt:

    https://github.com/aranemac/pamsel


    Und Lob dafür, dass du eine WAF einsetzt. :thumbup:

    Die meisten machen sich nicht diese Mühe und geben sich mit ufw und fail2ban zufrieden.

    Server werden allerdings häufiger über den Webserver gekapert, als über ssh.

    Leute, 1000 Dank für die weiterführenden Tipps. Offenbar wurde das Problem von WooCommerce nicht wie angekündigt gefixt? Wie auch immer, nun läuft's erstmal. Hinsichtlich der WAF Konfiguration werde ich eure Anregungen und Hinweise weiter verfolgen.


    Echt super, vor allem so schnelle Reaktion :)