Monat: September 2016

Bald ist Wochenende! Und es hat sich auch in dieser Woche wieder einiges getan, das wir euch nicht vorenthalten wollen.

Beim E-Mail-Server ist einiges passiert. Wir haben in den Statistiken des Virus-Filters entdeckt, dass einige Viren durchgerutscht sind und E-Mails mit Viren zugestellt wurden. Mit einem Update haben wir die Erkennungsrate des Viren-Filters verbessert, unsere Test-Dateien wurden danach korrekt abgelehnt (wir nehmen E-Mail mit Viren gar nicht erst an sondern lehnen sie direkt ab).

Zudem haben wir die E-Mail-Zustellung verbessert. Einige Provider, die eingehende E-Mail besonders scharf prüfen, hatten E-Mails von unserem Server vorher abgelehnt. Nach einem Hinweis eines Kunden auf diese Nichtzustellbarkeit haben wir einige Punkte der Konfiguration überarbeitet und dabei unter anderem die E-Mail-Zustellungsrate verbessert, auch in dem wir über mehrere ausgehende IP-Adressen (natürlich IPv6 und IPv4) versenden. Zudem bereiten wir die DKIM-Signierung von ausgehenden Mails vor, wenn die Domains bei uns registriert sind.

Auch für das Webmail Roundcube gab es ein Update auf die Version 1.2.2 (von 1.2.1). Es gibt eine Liste der Änderungen in dem Update. Zusätzlich haben wir den „Abwesenheits-Benachrichtigungen“-Tab in den Einstellungen aktiviert, so dass bei Abwesenheit einfacher eine automatische Antwort eingerichtet werden kann.

Bereits in der letzten Woche hatte ich zudem über die Schwierigkeiten bei der automatische Aktualisierung der Status-Seite gebloggt. Das hat sicher geändert, nun werden alle Komponenten auf der Status-Seite automatisch auf den aktuellen Status gesetzt. Dazu ruft ein Programm die aktuellen Test-Ergebnisse von den Monitoring-Providern, die unsere Server überwachen, ab (wir setzen parallel ein: Webmon, Monitis, Uptime Robot und New Relics Synthetics – zusätzlich zu einer eigenen Icinga2-Installation). Daraus wird ein Graph erzeugt, dessen Knoten jeweils eine Verfügbarkeit abhängig von dem Status ihrer „Kind-Knoten“ errechnen. Die Kind-Knoten sind die Monitoring-Ergebnisse der verschiedenen Provider. So ergibt sich schnell ein Überblick darüber, welche Teilbereiche des Systems von einem Problem betroffen sind und das Programm ändert dann die Status-Seite. Nur einen sinnvollen Text dazu verfassen und auf die Status-Seite schreiben, das ist derzeit noch nicht vorgesehen – aber verbessern kann man immer noch 😉

Das war’s auch schon wieder mit den Änderungen dieser Woche. Wir posten Freitag Nachmittags einen kleinen Rückblick auf die Woche. Stay tuned und gucke auch nächste Woche wieder rein!

Am letzten Wochenende wurden wir seit langer Zeit einmal wieder stärker mit DDoS-Angriffen belästigt. Das (beliebte) Ziel war die IP-Adresse, die wir zum Aufschalten von Domains benutzen (212.83.45.137). Bei kleineren DDoS-Angriffen ist die Standard-Lösung: unsinnige Pakete filtern (im Idealfall direkt am Switch) und fertig. Wenn das Angriffs-Volumen allerdings ein gewisses Maß übersteigt greift automatisch eine weitere Maßnahme: Nullrouting. Nullrouting ist „DIE“ Methode, um große DDoS-Angriffe abzuwehren: die Pakete an die angegeriffene IP werden schlicht von dem Netzwerk-Equipment nicht weitergeleitet. Große und kleine Anbieter nutzen diese Methode immer dann, wenn die Bandbreite des Angriffs so groß wird, dass das Filtern nichts mehr hilft.

Das Problem beim Nullrouting ist: wenn die IP-Adresse 212.83.45.137 wegen Nullrouting (aufgrund eines DDoS-Angriffs auf eine aufgeschaltete Domain) nicht mehr erreichbar ist, dann sind alle aufgeschalteten Domains nicht mehr erreichbar. Genau das war auch am letzten Wochenende der Fall, weshalb wir später noch eine Liste weiter IP-Adressen herumgeschickt haben, die als Alternative verwendet werden konnten und weiterhin online waren.

Um in Zukunft eine stabilere Aufschaltung von Domains gewährleisten zu können haben wir uns einfacher Mathematik bedient: „Ziehen ohne zurücklegen und ohne der Beachtung der Reihenfolge“ (n über k). Haben wir es damals nicht in der Schule geliebt?

Wir haben einen Block von IP-Adressen (bspw. 192.168.0.2 bis 192.168.0.50) in unseren „Pool“ gelegt. Jedes Mal, wenn eine Domain aufgeschaltet wird, ziehen wir aus diesem Pool eine Liste von 4 IP-Adressen und prüfen, dass diese Kombination bisher noch nicht vergeben wurde. So erhält jeder Kunde eine individuelle Liste von IP-Adressen, die nur für ihn „reserviert“ ist. Bei dem Aufschalten der Domain wird diese IP-Liste im DNS für die Domain eingetragen.

Wenn nun ein DDoS-Angriff stattfindet gibt es zwei Möglichkeiten (wir betrachten nur den Fall, dass der Angriff stark ist):

1. der Angreifer greift nur eine einzelne IP-Adresse an: diese IP-Adresse wird durch Nullrouting abgeschaltet. Da für die aufgeschaltete Domain mehrere IP-Adressen eingetragen sind, benutzt der Browser die nächste IP-Adresse aus dem DNS.
2. der Angreifer greift alle IP-Adressen für diese aufgeschaltete Domain an: es werden alle IP-Adressen mit Nullrouting abgeschaltet. In diesem Fall ist die aufgeschaltete Domain nicht zu erreichen – allerdings kann (durch den Vergleich mit der IP-Liste) identifiziert werden, welche Domain das Ziel des Angriffs war und weitere Maßnahmen ergreifen.

Ein weiterer Vorteil ist, dass alle anderen aufgeschalteten Domains weiterhin funktionieren, da die IP-Listen nicht ganz, sondern höchstens teilweise gleich sind. Schöner wäre es noch, wenn wir die IP-Adressen für die aufgeschalteten Domains dynamisch verwalten könnten, denn dann würden wir auch Fälle wie Nr. 2 behandeln können (durch Austausch von IP-Adressen) und bei Nr. 1 die Verbindungszeiten reduzieren (durch Entfernen von IP-Adressen), aber leider ist eben genau das bei aufgeschalteten Domains nicht möglich.

Das Formular zum Aufschalten von Domains haben wir für diese Änderung natürlich auch deutlich überarbeitet. Es lassen sich nun auch (mit Premium-Paket) direkt E-Mail-Dienste für Domain-Aufschaltungen konfigurieren, das war vorher nur über ein gesondertes Menü machbar.

In dem Zusammenhang haben wir noch einige Änderungen am internen Netzwerk an der Kommunikation der Webspace-Server untereinander vorgenommen, so dass die interne und externe Kommunikation besser getrennt ist. Ein eingehender DDoS-Angriff führt nun nicht mehr zu kurzzeitigen Fehlermeldungen von „Fehler 503“ o.ä.

Zu guter letzt haben wir uns auch berechtigte Kritik an der Status-Seite anhören müssen. Das Problem an der Status-Seite ist bisher, dass viele Ereignisse nicht automatisch auf der Status-Seite eingetragen werden. Bisher wurden die Informationen aus dem Monitoring darüber, welchen Status einzelne Dienste haben (und ggf. welche Probleme), nicht automatisch zu einem einheitlichen „Bild“ zusammengesetzt, was auf die Status-Seite übertragen werden kann. Unser Monitoring ist ein viel, viel komplexeres Gebilde als die Ansicht auf der Status-Seite und muss dementsprechend erst einmal eingedampft werden. Bisher haben wir dazu die Tools des Monitoring direkt verwendet, haben aber seit Monaten bereits an den Tools gearbeitet um die Monitoring-Daten aufzubereiten und daraus ein besseres Gesamtbild zu bauen – das dann automatisch auf die Status-Seite publiziert wird. Diese Tools werden wir in Kürze produktiv schalten, so dass die Status-Seite deutlich bessere Informationen enthält.

Und als winzige Kleinigkeit ist noch das LDAP-Modul für PHP installiert worden.

Wir posten Freitag Nachmittags einen kleinen Rückblick auf die Woche. Stay tuned und gucke auch nächste Woche wieder rein!

Passend zum Wochenende haben wir ein paar Updates eingespielt: das Webmail wurde auf eine aktuelle Version aktualisiert, die viele Fehler behebt. Zudem haben wir nun erstmalig ein Mobile-Skin installiert, mit dem das Webmail auf Mobilgeräten besser funktionieren sollte.

Ganz nebenbei haben wir dann auch noch ein PHP-Update (im wesentlichen ein Sicherheits-Update) auf 5.6.26 eingespielt.

Wir wünschen ein schönes Wochenende!