Es ist vollbracht!
Nach der aufreibenden Schlacht der Virtualisierung, bei der schon mehrere Kämpfe verloren gingen, und einer weiteren Meldung:
The VM could not be imported; is the file corrupt?
habe ich den Lizenzserver soeben endlich kleingekriegt.
Ab sofort versieht auch er seinen Dienst nur noch virtuell in unserer XEN-Server-Farm.
Frohe Ostern 
Es hätte ein so schöner Tag werden sollen.
Endlich stand am Dienstag der schon lange geplante Schritt der Servervirtualisierung bei uns im Krankenhaus an.
Folgende Maschinen, jeweils auf grundverschiedener Hardware lagen zur Virtualisierung auf Xen-Server an:
- 4 Maschinen mit Debian Etch (Schnittstellen-Server und Rechner mit Diensten für die Benutzer im Netz)
- 1 Maschine mit Windows 2000 Prof. (Schnittstellen-Rechner)
- 2 Maschinen mit Windows Server 2003 (ein MSSQL-Server, ein Lizenz- und Printserver)
- 2 Maschinen mit Windows Server 2000 (Domain-Controller)
Alles war fertig vorbereitet, der Zeitplan war erstellt, die Downzeiten im Haus bekannt gemacht, es konnte also losgehen.
9:00 Uhr
Zwei HP DL-380 standen bereit, die in jeweils 15 Minuten mit der aktuellen Citrix-Xen-Server Version 4.0.1 bestückt wurden. Als Speicherort für die virtuellen Maschinen dient das iSCSI-Storage PS-100e von Dell (ehemals Equallogic), das mittlerweile seit Januar zuverlässig seinen Dienst bei uns versieht.
10:00 Uhr
Nach weiteren Vorbereitungen ging es dann los.
Die vier ersten Migrationen, bei der die Debian-Installationen teils über partimage, teils über dd in ihre neue Heimat übertragen wurden, liefen fehlerfrei durch. Nach dem Anpassen der Grub-Konfiguration, der fstab und der Benennungsregeln für die Netzwerkinterfaces von udev fuhren die Kisten einwandfrei hoch.
13:30 Uhr
Jetzt sollten die Windows-Rechner an die Reihe kommen …
… und da fing das Martyrium an …
Gerade als Heise-News entdeckt: komplette Stromberg-Folgen online gucken auf myspass.de
So sollte man Werbung nun echt nicht in den Fließtext einbetten:
Und so sieht’s dann aus, wenn fail2ban in Aktion tritt:
In der auth.log stehen dann Einträge in der Art
Mar 4 13:57:18 localhost sshd[27578]: Invalid user webmaster from 124.109.52.58
Mar 4 13:57:23 localhost sshd[27584]: Invalid user sales from 124.109.52.58
Mar 4 13:57:26 localhost sshd[27586]: Invalid user admin from 124.109.52.58
Mar 4 13:57:28 localhost sshd[27589]: Invalid user andrea from 124.109.52.58
Mar 4 13:57:35 localhost sshd[27596]: Invalid user guest from 124.109.52.58
Mar 4 13:57:36 localhost sshd[27598]: Invalid user guest1 from 124.109.52.58
Mar 4 13:59:37 localhost sshd[27600]: fatal: Timeout before authentication for 124.109.52.58
[...]
Mar 4 14:00:46 localhost sshd[27667]: Invalid user test from 200.68.75.149
Mar 4 14:00:47 localhost sshd[27657]: Invalid user test from 200.68.75.149
Mar 4 14:00:47 localhost sshd[27669]: Invalid user test from 200.68.75.149
Mar 4 14:00:47 localhost sshd[27670]: Invalid user test from 200.68.75.149
Mar 4 14:00:47 localhost sshd[27671]: Invalid user test from 200.68.75.149
Mar 4 14:00:47 localhost sshd[27672]: Invalid user test from 200.68.75.149
Mar 4 14:02:47 localhost sshd[27677]: fatal: Timeout before authentication for 200.68.75.149
Iptables verwirft also erfolgreich:
# iptables -L fail2ban-ssh
Chain fail2ban-ssh (1 references)
target prot opt source destination
DROP 0 -- mail.forvis.com.ar anywhere
DROP 0 -- mbl-109-52-58.dsl.net.pk anywhere
RETURN 0 -- anywhere anywhere
Nach nur knapp 3 Jahren seit der offiziellen Indienststellung als Stable-Release wurde Debian Sarge nun ehrenhaft aus den Reihen der Update-Empfänger entlassen.
Ab Ende März werden für Debian 3.1 keine Sicherheits-Updates mehr veröffentlicht, nach Möglichkeit sollte bis dahin eine Migration der betroffenen Systeme auf die seit ca. einem Jahr als stabil gekennzeichnete Debian-Version 4.0 (aka Etch) erfolgen.
Bei der Dursicht der Serverlogs fiel mir heute morgen ein Bruteforce-Versuch gegen meinen sshd auf:
$ grep -c "sshd.*Invalid user" /var/log/auth.log
brachte 1255 fehlgeschlagene Anmeldeversuche am SSH-Service an’s Licht.
Nicht dass das weiter schlimm wäre, schütze ich diesen Service doch von vornherein, indem ich nur Anmeldungen mit digitalen Schlüsseln zulasse.
Aber nervig ist das schon. Außerdem gibt es ja noch andere Dienste, die sich auf diese Weise nicht absichern lassen.
Ich habe daher reagiert, und auf dem betroffenen System fail2ban eingerichtet.
Fail2ban protokolliert fehlgeschlagene Anmeldeversuche und blockiert die Angreifer-IP per iptables, wenn dieser zu oft versucht, Zugriff auf den Dienst zu bekommen.
Da das Programm Log-Dateien per Regular Expressions filtert, lässt sich jede Anwendung schützen, die einen Dienst über das Netzwerk anbietet und Anmeldeversuche mitprotokolliert.
Vorkonfiguriert gibt es beim Debian-Paket Filter für sshd, apache, vsftpd, proftpd, wuftpd, postfix, couriersmtp oder sasl.
Die Konfigurationsdateien unter /etc/fail2ban sind eigentlich leicht verständlich, wer trotzdem eine Anleitung zum Thema sucht, klicke auf: http://www.howtoforge.com/fail2ban_debian_etch
