Zugschlusbeobachtungen

Die erste Idee ist, dem Webmenschen auf der Shell des Servers ein Script bereitzustellen, dass den virtuellen Host für die Utilities per sudo aktiviert und ihn aus dem cron regelmäßig wieder zu deaktivieren. Dann kommt mir die Idee, das ganze beim Login aus dem ~/.profile zu automatisieren. Und wenn wir schon dabei sind, sollen die Utilities auch nur für den Host freigegeben werden, von dem sich der Benutzer gerade eingelogged hat.

Das #!/usr/bin/perl -w, use strict ist schon geschrieben und ich mache mir gerade Gedanken darüber, wie ich das auth.log zur Gewinnung der Quell-IP-Adresse des Logins am besten durchforsten kann (denn dieses File kann potenziell groß sein), da kommt mir der Geistesblitz. Wir haben doch schon einen Daemon, der beim (gehäuften) Auftreten eines bestimmten Logeintrags eine Aktion durchführen kann und diese nach einiger Zeit auch automatisch wieder rückgängig macht: fail2ban macht dies, mit der Intention, eine IP-Adresse zu blockieren, sobald von dieser Adresse zu oft fehlerhafte Loginversuche ausgehen.

Diesmal wollen wir es gerade umgekehrt: Wir wollen einen Dienst für eine IP-Adresse temporär freigeben_, sobald _ein _erfolgreicher_ Login von dieser Adresse verzeichnet werden konnte. fail2ban widersetzt sich dieser, seiner eigentlichen Intention diametral entgegengesetzten Aufgabe kaum, so dass mit der folgenden Konfiguration das Ziel erreicht wird:

/etc/fail2ban/jail.local:

[ssh-success]

enabled = true
port    = https
filter  = sshd-success
logpath  = /var/log/syslog/auth.log
maxretry = 1
action = iptables-allow[name=%(__name__)s]
bantime = 7200

/etc/fail2ban/action.d/iptables-allow.conf:

[Definition]
actionstart = iptables --new-chain fail2ban-<name>
              iptables --append fail2ban-<name> -j DROP
              iptables --insert INPUT -m state --state NEW --protocol   --dport <port> -j fail2ban-<name>
actionstop = iptables --delete INPUT -m state --state NEW -p <protocol> --dport
<port> -j fail2ban-<name>
             iptables --flush fail2ban-<name>
             iptables --delete-chain fail2ban-<name>
actioncheck = iptables --list INPUT | grep -q fail2ban-<name>
actionban = iptables -I fail2ban-<name> 1 -s <ip> -j ACCEPT
actionunban = iptables -D fail2ban-<name> -s <ip> -j ACCEPT

[Init]
name = default
port = https
protocol = tcp

/etc/fail2ban/filter.d/sshd-success.conf:

[Definition]
failregex = Accepted publickey for \\w+ from  port \\d+ ssh2$
ignoreregex =

Dabei kommt mir zu gute, dass ich die Utilities als einzige https-Dienste auf dem System angeboten werden und ich somit radikal mit dem Port arbeiten kann. Theoretisch könnte ich mir aber vorstellen, dass das Verfahren auch dazu geeignet ist, eine .htaccess-Datei mit den entsprechenden allow-Klauseln zu füllen bzw. diese nach einiger Zeit wieder zu entfernen.

Das einzige, was etwas verwirrend ist, ist die Terminologie von fail2ban, das in Konfigurationsdateien und Logs natürlich davon ausgeht, nach fehlgeschlagenen Zugriffen eine Sperre durchzuführen und nach dem Ablauf der Zeit wieder aufzuheben, während es in der Praxis auf einen erfolgreichen Zugriff mit einer Freigabe reagiert:

2008-08-30 11:46:01,544 fail2ban.actions: WARNING [ssh-success] Ban 85.214.68.41
2008-08-30 11:46:08,553 fail2ban.actions: WARNING [ssh-success] Ban 92.227.69.188
2008-08-30 13:46:02,041 fail2ban.actions: WARNING [ssh-success] Unban 85.214.68.41
2008-08-30 13:46:09,049 fail2ban.actions: WARNING [ssh-success] Unban 92.227.69.188

Wenn man sich einmal an die verwirrende Sprache gewöhnt hat, macht fail2ban auch seinen umgekehrten Job ganz gut.