staging.inyokaproject.org

Ich habe gestern auf einem neuen Server modsecurity eingerichtet, zusammen mit ufw und fail2ban. Prima Sache - und laut Logs intensiv und erfolgreich genutzt.

Ich betreibe einen rein administrativen VirtualHost mit Anwendungen wie phpmyadmin, postfixadmin, monit etc. Beim Aufruf von phpmyadmin kam es zu vielen false-positives von modsecurity. Denen bin ich dann wie folgt zu Leibe gerückt:

# /etc/phpmyadmin/apache.conf

Alias /mysecretalias /usr/share/phpmyadmin

<Directory /usr/share/phpmyadmin>
    Options SymLinksIfOwnerMatch
    DirectoryIndex index.php
    <IfModule mod_authz_core.c>
        <IfModule mod_authn_file.c>
            AuthType Basic
            AuthName "Restricted Content"
            AuthUserFile /irgendwie/irgendwo/.irgendwas
        </IfModule>
        Require valid-user
    </IfModule>
    <IfModule security2_module>
        SecRuleRemoveById 950109 981172 981257 981245 981246 981243 981205 970903 981173 981318 981242
    </IfModule>

Nachdem ich diese 11 Rules entfernt hatte, scheint phpmyadmin zu funktionieren (nicht auszuschließen, dass noch das eine oder andere Rule zusätzlich rausfliegen muss).

Jetzt zur Frage: Gehe ich das Problem so (also per phpmyadmin apache.conf) richtig an, oder gibt es bessere Wege? Kann jemand die hohe Zahl an false-positives bei phpmyadmin bestätigen? Postfixadmin z.B. scheint dagegen keinerlei Probleme zu verursachen.

Die 2. Frage: fail2ban überwacht derzeit ssh und diverse apache-jails (u.a. modsecurity). Vor Installation von modsecurity hatte ich unzählige Einträge wie folgt im access.log:

example.com:80 149.56.102.92 - - [20/Nov/2016:14:53:29 +0100] "PROPFIND /webdav/ HTTP/1.1" 302 451 "-" "WEBDAV Client"

Die IP wechselt im Minutentakt, viele IPs kommen aber nach 1-2 Stunden erneut. Manche 6 mal in 10 Stunden. Mit derzeitige Einstellungen für fail2ban (findtime = 600, maxretry = 2 für's modsecurity Jail) wird keine IP gebannt. Macht es hier Sinn, mit wesentlich längeren Einstellungen für findtime zu arbeiten, um das Rattenpack aus den Logs fern zu halten? Dies bläht die iptables Regeln natürlich auf, entlastet aber den Server von ungewünschten Aktivitäten.

Auf welchem Wert steht denn bantime? Für dauerhafte Bans kann mans auf -1 setzen, allerdings finden die Zugriffsversuche auch von dynamisch zugewiesenen IPs aus statt, welche man eher nicht dauerhaft bannen möchte. Bei mir sind auf diese Weise jetzt über 2000 IPs gebannt.

Wegen wird nicht gebannt: Du kannst findtime ja testweise noch höher setzen.

Ich nutze derzeit noch die defaults, also bantime = 600. Es kommt aber aktuell zu keinerlei Bans, da identische IPs grundsätzlich erst nach der findtime (default =600) zurückkehren (von den Chinesen/Koreanern/Ukrainern... sicherlich bewusst so gesteuert). Dauerhaft möchte ich nichts blocken, zudem dann die Tabelle auch gigantisch anwachsen dürfte.

Es kommt ja auch niemand weiter, da modsecurity tut, was es soll. Die Frage ist, ob ein Ausweiten der find- und bantime hier angesagt wäre, um Last vom System zu nehmen.

. EDIT: Nach Korrektur des failregex für apache-modsecurity (ein Space zuviel) klappt die Regel jetzt, und es wird üppig gebannt. Der failregex für apache-auth tut auch, was er soll. Den Rest muss ich noch überprüfen. Schon vor Jahren passten die failregexe aus der Distribution nicht zum Logformat. Daran hat sich offensichtlich nicht viel geändert. Der apache-modsecurity Filter macht einige andere apache Filter überflüssig, sollte aber sorgfältig gegen false positives getestet werden.

NEUE Frage: Gibt es auch legitime Bots, die Anweisungen in der robots.txt ignorieren?

EDIT: Die Filter für dovecot und postfix crashen, da fail2ban von der Existenz eines "mail.warn" Logs ausgeht (anstatt "mail.log"). Nach Setzen des korrekten Logpfads in jail.local klappt der Start, aber der dovecot Filter findet nix. Geänderter failregex im dovecot.conf Filter hingegen klappt:

failregex = ^%(__prefix_line)s(?:%(__pam_auth)s(?:\(dovecot:auth\))?:)?\s+authentication failure; logname=\S* uid=\S* euid=\S* tty=dovecot ruser=\S* rhost=<HOST>(?:\s+user=\S*)?\s*$
            ^%(__prefix_line)s(?:pop3|imap)-login: (?:Info: )?(?:Aborted login|Disconnected)(?::(?: [^ \(]+)+)? \((?:auth failed, \d+ attempts( in \d+ secs)?|tried to use (disabled|disallowed) \S+ auth)\):( user=<[^>]+>,)?( method=\S+,)? rip=<HOST>(?:, lip=\S+)?(?:, TLS(?: handshaking(?:: SSL_accept\(\) failed: error:[\dA-F]+:SSL routines:[TLS\d]+_GET_CLIENT_HELLO:unknown protocol)?)?(: Disconnected)?)?(, session=<\S+>)?\s*$
            ^%(__prefix_line)s(?:Info|dovecot: auth\(default\)|auth-worker\(\d+\)): pam\(\S+,<HOST>\): pam_authenticate\(\) failed: (User not known to the underlying authentication module: \d+ Time\(s\)|Authentication failure \(password mismatch\?\))\s*$
            ^%(__prefix_line)s(?:auth|auth-worker\(\d+\)): (?:pam|passwd-file)\(\S+,<HOST>\): unknown user\s*$
            ^%(__prefix_line)s(?:auth|auth-worker\(\d+\)): Info: ldap\(\S*,<HOST>,\S*\): invalid credentials\s*$

Der Filter für langfristiges Bannen regelmässiger Störer (recidive.conf) klappt ab Werk.

Vielleicht erspart dies ja die eine oder andere frustrierende Fehlersuchstunde. In meinen Logs ist jetzt zumindest entspannte Ruhe eingekehrt ☺