Der Mailserver wurde in den vergangenen Tagen hinsichtlich der Spam-Bekämpfung und des Funktionsumfangs ein wenig modifiziert.

Folgende Änderungen wurden vorgenommen:

Mail Transfer Agent
- DNS-Blacklisting
- Domain-Überprüfung
- DKIM

Mail Delivery Agent
- Lernmodul für SpamAssassin
- Mailsortierung
- Sieve

1. DNS-Blacklisting
Diese Änderung liegt schon 1-2 Wochen zurück. Der ein oder andere mag bemerkt haben, dass das Spam-Aufkommen im eigenen Postfach zurückgegangen ist.

Grund hierfür ist das DNS-Blacklisting, welches den SpamAssassinen und den Postgrey-Filter nun bei der Spam-Bekämpfung unterstützt. Hosts, die auf den Listen zen.spamhaus.org oder auf Heise NiX-Spam eingetragen sind, können fortan keine Mails mehr auf unserem System einliefern.

Die beiden Listen sind recht koservativ, so dass vermutlich noch die ein oder andere Spam-Mail durchrutschen wird - die Gefahr von False Positives ist hier allerdings auch geringer, als bei anderen Listen.

2. Domain-Überprüfung
Der MTA überprüft nun zusätzlich, ob die Domain der Absender-Mailadresse existiert. Ist dies nicht der Fall, so wird die Nachricht abgewiesen.

3. DKIM
eMails von und an Postfächer unter der Domain morloc.info werden auf dem Server mittels DKIM digital signiert beziehungsweise die Signatur eingehender eMails überprüft. Dies verhindert eine unbemerkte Manipulation von Mails auf dem Transportweg und verringert die Wahrscheinlichkeit, dass ausgehende Mails fälschlicherweise als Spam klassifiziert werden.

4. Lernmodul für SpamAssassin
Der Spam-Filter "SpamAssassin" untersucht eingehende Mails anhand verschiedener Merkmale und klassifiziert sie gegebenfalls als Spam. Um die Erkennungsrate zu steigern und False Positives zu verringern, ist die Software auf Lernwerte angewiesen.
Wird eine Mail vom Client manuell in das Mail-Verzeichnis "Junk" verschoben, so wird sie dem SpamAssassinen als Probe für Spam vorgelegt. Analog: Wird eine Mail manuell aus dem Verzeichnis "Junk" in ein anderes Verzeichnis verschoben, so wird sie dem Filter als Probe für "Ham" vorgelegt.

5. Mailsortierung
An den vorherigen Punkt anschließend: Der SpamAssassine markierte Mails bislang im in der Betreff-Zeile und im Header als Spam. Damit konnte ein MUA die Mail anhand einer Filterregel in das Junk-Verzeichnis verschieben. Dies geschieht nun automatisch auf dem Server. Die Markierung im Betreff entfällt.

6. Sieve
Mit Punkt 5. ergibt sich auch Punkt 6. und damit ein kleines Feature: Sieve, eine Skriptsprache für den MDA, erlaubt das Behandeln eingehender Mails. So können etwa Auto-Responder erstellt werden, ebenso wie Regeln für das Verschieben/ Ablehnen/ Kopieren/ Taggen/ Weiterleiten von Mails mit bestimmten Merkmalen (Absender, Betreff, Body, Tags, ...).

Die Erstellung von Sieve-Skripte erfolgt ganz komfortabel über ein UI im Webmail-Client (Einstellungen -> Filter) oder (wahlweise ebenfalls über ein UI oder als Skript) über ein MUA-Plugin, z.B. "Sieve" für Thunderbird. (aktuelle Thunderbird-Version funktioniert nur mit Sieve 0.2.3 als Nightly-Build)

Gestern Abend war es wieder soweit: Etliche Abuse-Meldungen von verschiedenen Firmen und Institutionen trudelten per eMail an. Ursache dafür war die Teilnahme einer Benutzer-VM an Brute Force-Angriffen auf SSH-Daemons der Betroffenen.

Das normale Vorgehen bei Abuse-Meldungen ist wie folgt:
Liegen nur 1-2 Meldungen zu einem Zeitpunkt t vor, so sendet Hetzner die Meldungen per Mail an den Serverbetreiber, bittet um Abstellung des Problems und ein Statement zur Ursache.

Liegen hingegen mehrere Meldungen vor, so wie im gestrigen Fall, werden betroffene IP-Adresen oder Subnetze am Router von Hetzner gesperrt.
Offenbar waren die Mitarbeiter gestern etwas übereifrig und haben nicht nur die betroffene Einzel-IP gesperrt, sondern kurzerhand den gesamten Server physisch vom Netz getrennt.

Die eMail-Korrespondenz mit dem Support gestaltete sich durch die Verzögerungen des Ticket-Systems als etwas zäh, so dass der Server gestern von ca. 18:00 bis 23:00 vom Netz getrennt war.

Noch einmal die Hinweise zur sicheren Konfiguration der VM:

Die Punkte 1 - 6 des vorherigen Beitrags gelten weiterhin.

Zusätzlich sinnvoll:

-7- SSH Daemon absichern
Das Login - Verbot für den Benutzer root und Fail2Ban wurden bereits beschrieben. Weiterhin sinnvoll ist die Installation eines Port-Knocking Daemons, um Portscans abzuwehren und die Umstellung auf Key Based Authentication, an Stelle von Passwortauthentifizierung.

Wer von seinem ISP eine statische öffentliche IP-Adresse erhält und die VM nur von diesem Anschluss administriert, kann die Firewall auch dahingehend konfigurieren, dass Anfragen an Port 22 nur von eben dieser Quelladresse akzeptiert werden.

-8- Webserver absichern
Nicht minder gefährlich sind schlecht abgesicherte Webserver. Dass in komplexen Webanwendungen immer mal wieder Fehler gefunden werden, die sich dazu eignen schreibenden Zugriff auf den Webspace zu erlangen, ist kein Geheimnis. Hier gilt wieder Punkt 4. Besonders unangenehm ist ein solcher Fall jedoch dann, wenn Laufzeitumgebungen auf dem Webserver nicht abgesichert sind. Berühmtes Beispiel: Die Shell-Funktionen unter PHP.


Bei zukünftigen Abuse-Meldungen werde ich betreffende VMs sofort, bis zur Rückmeldung des administrierenden Nutzers abschalten - Das ist nicht böse gemeint, sondern geschieht zum Schutz aller Nutzer. Das Abschalten einer einzelnen kompromittierten VM ist im Sinne der Schadensminderung wohl sinnvoller als das Fremdabschalten des gesamten Servers.

Aus aktuellem Anlass: Eine virtuelle Maschine auf Morloc.de bringt eine Menge Möglichkeiten, jedoch auch eine nicht zu unterschätzende Verantwortung mit sich.

In den vergangenen Tagen wurde fast zeitgleich in mindestens 2 verschiedene VMs eingebrochen. Die kompromittierten VMs nahmen an DDoS-Angriffen teil, wobei sie ein Volumen von knapp 500GB innerhalb einer Woche (!!) sendeten - davon entfiel ein Volumen von ca. 90GB auf eine einzige Stunde.

Der Server von morloc.de ist derzeit mit 200MBit/s an das Internet angebunden, die bei Bedarf jeder einzelnen VM uneingeschränkt zur Verfügung stehen - dieser Verantwortung sollte sich jeder Nutzer bewusst sein!

Aus diesem Grund noch einmal allgemeine Hinweise zur sicheren Konfiguration einer VM:

-1- Dem Nutzer "root" den Zugriff via SSH verbieten

-2- Firewall so restriktiv wie möglich konfigurieren
Ein-, Aus- und durchgehender Datenverkehr sollte per Policy generell verworfen werden. Für gewünschten Datenverkehr können hiervon abweichende Regeln erstellt werden.

-3- BruteForce- und Portscan-Abwehr
Das Werkzeug Fail2Ban erlaubt die Blockade von Teilnehmern auf Zeit, die wiederholt falsche Zugangsdaten (Brute-Force Angriff) an den Server senden oder Ports scannen. Fail2Ban ist für fast alle Dienste konfigurierbar, etwa SSH, FTP, Mail, ...

-4- Regelmäßig Updates ausführen
Eine unsichere Softwareversion ist ein Einfallstor für Angreifer - Debian bietet mit "aptitude safe-upgrade" ein einfaches Werkzeug an, welches regelmäßig genutzt werden sollte.
Selbstkompilierte Software muss manuell überwacht werden. Es empfiehlt sich Software-Versionen nicht öffentlich auszugeben, etwa beim Apache-Webserver.

-5- Monitoring
Um über Unregelmäßigkeiten im Betrieb zeitnah informiert zu werden sollte die VM durch einen Monitoring-Dienst überwacht werden.

-6- Testinstallationen
Experimente mit Software sollten im Idealfall auf einer VM auf dem lokalen Rechner stattfinden. Eine fehlerhaft konfigurierte Software ist ein nicht minder gefährliches Einfallstor für Angreifer.


Für die Webspace-Nutzer gilt: Webanwendungen sind regelmäßig auf bekannte Sicherheitslücken und Softwareaktualisierungen zu prüfen. Potentiell unsichere Scripte oder Scripte für den Testgebrauch sollten hinter einer Nutzerauthentifizierung versteckt werden (z.B. AuthBasic - htaccess)

Wie vermutlich die meisten Nutzer mitbekamen, liefen die Wartungsarbeiten vergangene Nacht alles andere als reibungslos.

Zu den Ursachen in aller Kürze: Die Virtualisierungssoftware XEN hat nach dem Update wild mit kryptischen Stacktraces um sich geworfen (u.A. wg. im Debian-Package fehlenden Scripten) und das Routing vollkommen durcheinander gehauen. Zuvor weigerte sich der Bootloader mit dem RAID zusammenzuarbeiten, was eine weitere Verzögerung bedeutete, bis der Hetzner-Support eine KVM-Konsole zur Verfügung stellte.

Der Server war somit gestern von 0:30 bis 4:00 und von 14:00 bis etwa 0:30 nicht erreichbar.
Für die Unannehmlichkeiten bitte ich um Entschuldigung.

Ein Hinweis für die VM-Nutzer: Es wurde ein neuer Kernel installiert. Damit die Kernel-Module geladen werden können, führt bitte ein "depmod -a" aus.

Die Ziele, ein Distributions- und Kernel-Upgrade, wurden erreicht.

In der Nacht vom 22. auf den 23. Februar wird der Morloc - Server für einige Zeit nicht erreichbar sein. Der Umfang der geplanten Arbeit bedingt eine Ausfallzeit von ca. 3 - 4 Stunden.

Anstehende Arbeiten:
* Hardware - Tests (insb. Arbeitsspeicher)
* Filesystem - Tests
* Update auf Debian 6
* Kernel - Updates

Für die Dauer der Wartung werden sämtliche Dienste nicht verfügbar sein. Dies betrifft ebenfalls den Mailserver.

Wie im Twitter-Channel bereits angekündigt, wurde der GreyListing-Filter des Mailservers nach der Installation von SpamAssassin wieder aktiviert.

Um die lokalen Zustellzeiten nicht unnötig hoch zu halten, wurde die Konfiguration dahingehend verändert, dass nur noch Mails von "verdächtigen" Hosts (v.A. Hosts mit Dialup-Verbindungen; etwa mit Malware infizierte PCs) gefiltert werden.
Alle anderen Nachrichten werden ohne Greylisting angenommen, wobei der vor einigen Tagen installierte Spam-Filter "SpamAssassin" anhang diverser Merkmale prüft.

Wird eine Mail als SPAM erkannt, wird sie durch SpamAssassin mit einer Markierung versehen. Thunderbird (und weitere Mail-Clients) sind in der Lage, Mails anhand dieser Markierung auszusortieren.

Falls eine Nachricht fälschlicherweise als SPAM klassifiziert wurde, bitte ich um eine kurze Mitteilung mit Anhang an postmaster [ätt] morloc [dot] de, um die Filterregeln anpassen zu können.

Derzeit werden folgende Funktionen erprobt:

Server-Monitoring

Neben dem Monitoring durch die Hetzner Online AG, welche im Intervall von 3 Minuten den Server auf Erreichbarkeit (Ping) und Verfügbarkeit der Web- (HTTP) und SMTP-Server prüft, wird der Server durch den Dienst livewatch.de überwacht. Die Grafik auf der rechten Seite zeigt die gemessenen Werte im Durchschnitt an.


Log-File Rotation

Die Log-Dateien in den Benutzerverzeichnissen werden nun täglich "rotiert". Die Log-Datei des Vortages wird archiviert und für 14 Tage aufbewahrt, bevor sie automatisch entfernt wird.


Sicherungen von eMail-Postfächern und mySQL-Datenbanken

Sämtliche eMail-Postfächer und mySQL-Datenbanken werden wöchentlich gesichert und für ein halbes Jahr archiviert. Die Speicherung der Snapshots erfolgt dabei auf einem durch die Hetzner Online AG bereitgestellten Backup-Server.

Ich möchte noch einmal darauf hinweisen, dass die hier vorgestellten Features experimentell sind!

Jeder Benutzer ist auch weiterhin für die Sicherung seiner Daten selbst verantwortlich. - Für Verluste wird keine Haftung übernommen.

Wie bereits über die Statusmeldungen angekündigt, wurden in den letzten 3 Stunden Arbeiten am Webserver vorgenommen.

Grund für die Änderungen war die fehlende Unterstützung von Server Name Indication (SNI) des Apache2 - Webservers aus den Debian Repositories.

Im Zuge der nun notwendig gewordenen Neukompilierung aus den Quellen von Apache und PHP, wurde in beiden Fällen auf eine neuere Version gewechselt.

Apache 2.2.9-10 ⇒ 2.2.14
PHP 5.2.6 ⇒ 5.3.1

PHP 5.3.1 wurde dabei erst gestern released - man könnte es also ein perfektes Timing nennen. ;-)

Bitte beachten: PHP hat in der Version 5.3.0 eine Reihe Neuerungen erfahren. Unter anderem wurden jedoch auch einige Funktionen als "deprecated" markiert - Eventuell auftauchende Fehlermeldungen, die auf solche Funktionen hinweisen, sind also nicht auf eine Fehlkonfiguration des Webservers zurückzuführen.


Sollten dennoch anderweitige Störungen auftreten, bitte ich um eine kurze Mail mit aussagekräftiger Fehlermeldung.

Die Arbeiten am Mailserver wurden soeben nach mehreren Tagen Arbeitszeit erfolgreich beendet.

Der Auslöser der Umstellung war eine Inkompatibilität zwischen Microsoft's Outlook 200x und dem vormals verwendeten Courier-Mailserver.
Outlook verweigerte den Abruf von Mails aus dem Postfach, wenn es via POP3 mit obligatorischer SSL/TLS-Verschlüsselung mit dem Server verbunden war.

Courier-POP3 und -IMAP wurden in Folge der Arbeiten durch Dovecot ersetzt. Die Migration der Courier-Postfächer zu Dovecot verlief ohne Probleme.

Ebenfalls wurde die Tabellenstruktur des Mailservers massiv überarbeitet. So soll eine Redundanz und Inkonsistenz der Daten vermieden, und die Datenintegrität gesichert werden.

Die eMail-Verwaltungs-Komponente musste auf Grund der vorgenommenen Änderungen komplett neu geschrieben werden. - Neben der nun (hoffentlich) übersichtlicheren Gestaltung der eMail-Übersicht wurde ein kleines, aber feines neues Feature implementiert.

Sollten Fehler auftreten, bitte ich um eine kurze Nachricht.

Die Scripte zur Erstellung von Apache-Konfigurationsdateien und zur Messung des freien Speicherplatzes in den Benutzer-Verzeichnissen wurden überarbeitet.

Die Verbesserungen kommen in erster Linie der Performance und der Ausfallsicherheit zu Gute.

Das vHost-Script hat nun eine wesentlich kürzere Laufzeit und benötigt nur einen Bruchteil der zuvor in Anspruch genommenen Ressourcen.

Zudem wurde eine Ausnahmebehandlung implementiert, die im Fehlerfall die letzte als funktionierend bekannte Konfiguration lädt und den Betreiber via Mail über den Vorfall informiert.

Die Neuerungen beim Speicher-Script betreffen vor allem die Performance. Zudem wird der Speicherplatz nun nicht mehr stündlich, sondern im 6-Stunden-Takt überprüft.