Auch diese Woche hat sich wieder einiges getan, leider war vieles davon hinter den Kulissen. Ein kleiner Einblick:

Beispielsweise haben wir den Restore-Prozess beschleunigt. Wenn wir (z.B. im Premium-Paket täglich) ein Backup machen, wird das Backup sofort an einen Storage-Server (ein 4HE Supermicro SC847E16 mit derzeit 30x 2TB, 6 Einschübe sind noch frei) übertragen. Dort liegen die Backups dann bis zu dem Moment, an dem sie wieder angefordert werden: es muss aber natürlich das Backup irgendwann wiederhergestellt werden, in der Regel in ein zip-Archiv. Das haben wir beschleunigt, u.a. in dem die temporären Dateien nun auf einem schnelleren RAID entpackt werden. Ein Test-Archiv von 2 GB Endgröße mit 125.000 Dateien wird nun in etwa 5 Minuten erstellt (aus dem Backup-Format extrahiert und wieder zu einem zip-Archiv zusammengefügt). Übrigens stellt das Restore-System demnächst das 500. mal Daten aus dem Backup wieder her – ob das gut oder schlecht ist, darüber kann man sicher streiten 😉

Das Abrechnungssystem für Premium-Pakete haben wir überarbeitet, denn in Zukunft wollen wir den Speicherplatz beim Premium-Paket flexibel gestalten. Dann lässt sich nicht nur der Preis und Abrechnungszeitraum mit Wirkung zur nächsten Abrechnung einstellen, sondern auch den Speicherplatz in Schritten von 10 GB. Vorerst werden wir 200 GB als Obergrenze setzen. Wir überlegen jetzt nur noch an der Preisstaffel (für den Mindestpreis) herum, dann kann es losgehen.

Natürlich gab es auch einiges an Bugfixes und Verbesserungen, z.B. in der Webseiten-Statistik, wo es einen Fehler bei der Umrechnung gab, versehentlich zweimal getätigte PayPal-Zahlungen für eine Bestellung können einfacher und schneller erstattet werden und neu angemeldete Accounts werden gleichmäßiger auf alle Server-Systeme verteilt.

Wir posten Freitag Nachmittags einen kleinen Rückblick auf die Woche. Auch nächste Woche tut sich bestimmt wieder einiges, also: kiek mol wedder rin!

Diese Woche war nicht nur kürzer als sonst, wegen Krankheit war auch der Support etwas geringer besetzt. Deswegen gibt’s leider nicht so viel zu berichten:

Eine Vereinfachung gibt es bei der Verbindung zum MySQL-Server. Statt „[username].lima-db.de“ oder „mysql.lima-city.de“ kann jetzt auch „localhost“ verwendet werden um zur Datenbank zu verbinden. Das funktioniert allerdings nur vom „eigenen Webspace“ aus, also der Account „mustermann“ kann per „localhost“ zu seinen eigene Datenbanken verbinden, aber nicht zu denen von „mustermann2“. Auch von extern funktioniert das (natürlich) nicht, denn „localhost“ ist immer die eigene Maschine.

Wir prüfen nun die DMARC-Header eingehender E-Mails, sofern sie vorhanden sind. DMARC ist ein Standard zur Authentifizierung und Überwachung von E-Mails, die den Missbrauch von Absender-Adressen verringern soll. Bisher ist der Filter nur im Test-Modus: E-Mails, welche die DMARC-Prüfung nicht bestehen, werden noch nicht abgelehnt. Den Filter schalten wir voraussichtlich im Laufe der nächsten Woche scharf, wir möchten noch überwachen ob es unvorhergesehene Probleme gibt. Wir erhoffen uns, dass noch weniger Phishing- und Spam-Mail in die Mailboxen gelangt 🙂

Bei der Aufschaltung von Domains werden es seit Kurzem vier IP-Adressen zur Eintragung angeboten um Lastverteilung und DDoS-Schutz zu erreichen. Manche Domain-Provider unterstützen allerdings nur eine IP-Adresse (was unfassbar albern ist, aber lassen wir das…). Wir haben nun eine Möglichkeit hinzugefügt, DNS-Probleme bei der Aufschaltung zu ignorieren und so z.B. nur eine IP-Adresse aufzuschalten.

Eine Kleinigkeit kam auch noch dazu: wenn bei der Domain-Registrierung oder dem Domain-Umzug ein Fehler auftritt, wird nun eine detailliertere Fehlermeldung angezeigt (z.B. „Transfer-Lock gesetzt“, „AuthInfo stimmt nicht überein“ etc.).

Wir posten Freitag Nachmittags einen kleinen Rückblick auf die Woche. Diesmal etwas kürzer wegen des Feiertags, aber vielleicht erwartet Dich nächste Woche ein Feuerwerk an interessanten Änderungen! Also: kiek mol wedder rin!

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!

E-Mail ist das klassische Kommunikationsmittel im Internet und hat mittlerweile einen wichtigen Platz im täglichen Leben vieler Menschen eingenommen. Natürlich bieten auch wir E-Mail-Postfächer für unsere Kunden an. Bisher war E-Mail allerdings nur für Domains, die bei lima-city gekauft wurden, möglich.

Das ändert sich nun, denn ab heute bieten wir Kunden mit Premium-Paket unsere E-Mail-Dienste auch für aufgeschaltete Domains an. Dazu ist es nur erforderlich, einen DNS-Record für die Domain einzutragen. Anschließend kann die Domain in der Verwaltung für E-Mail-Empfang und -Versand freigeschaltet und sofort benutzt werden. Es können auch hier unbegrenzt viele Postfächer mit je 10 GB Speicherplatz angelegt werden.

Wie bei den anderen Postfächern sind ein Spam-Filter, manuelle Filter-Regeln und das Webmail verfügbar.

Jede Homepage braucht eine Adresse, vor allem eine, die einfach zu merken ist. Bisher haben wir davon eine ganze Reihe zur Verfügung gestellt in Form von „benutzername.lima-city.de“, „benutzername.lima-city.at“, „benutzername.lima.zone“ usw. Das führte dazu, dass der Benutzername plötzlich zentrales Element der Webseitengestaltung wurde und wir regelmäßig Fragen zur Änderung des Benutzernamen oder Einrichtung anderer Subdomains bekamen. Weil wir zuletzt auch noch kürzere Domains wie „benutzername.de.cool“ hinzugefügt haben, die mit der Beschränkung ihr Potenzial nicht ausschöpfen können (ich denke da an „ich-finde-schokola.de.cool“ o.ä.), möchten wir eine bessere Lösung finden.

Daher geben wir diesen Zusammenhang Benutzername/Subdomain nun auf. Ab sofort können für die Domains „de.cool“, „lima.zone“, „1337.pictures“, „clan.rip“ und „webspace.rocks“ beliebige Subdomains registriert werden (1337.pictures und clan.rip sind neu). Für die nächsten ca. 8 Wochen (bis zum 15.05.2016, 0:00) gibt es eine spezielle Phase („Sunrise-Phase“), in der die Benutzernamen anderer Accounts nicht registrierbar sind (Benutzer „hans“ kann nicht „peter.de.cool“ schnappen wenn der Benutzername „peter“ belegt ist, so dass „peter“ 8 Wochen Zeit hat um sich selbst „peter.de.cool“ zu registrieren). Damit hat jeder Zeit, seinen eigenen Benutzernamen zu registrieren. Ab dem 15.5. werden die Karten neu gemischt und es können alle Namen registriert werden.

Damit sinnlose Massen-Registrierungen verhindert werden (z.B. ein Benutzer registriert sich alle Städtenamen in der Form von bremen.de.cool, hamburg.de.cool etc.) beschränken wir die Anzahl aller kostenloser Subdomains pro Account zuerst auf 25 Stück. Wir werden nach ca. 3 Monaten prüfen ob das Limit von der Höhe und dem dahinter stehenden Gedanken sinnvoll ist und dann ggf. ändern oder aufheben.

Im Laufe der Zeit werden wir weitere Domains hinzufügen, daher: stay tuned und viel Spaß mit den neuen Subdomains!

Niemand mag es, es kostet viel Zeit und Nerven und einige wenige verdienen viel Geld damit. Die Rede ist von Spam. Wir bekommen nicht nur Spam, sondern wir versenden auch welchen. Nun ja, nicht direkt wir, und auch nicht freiwillig oder mit Absicht, aber es gibt Accounts bei uns, die nur zum Versenden von lästigen Botschaften angelegt werden. Andere Accounts bei uns werden wegen Sicherheitslücken oder schlechter Passwörter geknackt und dann zum Spam-Versand missbraucht.

Gegen all das kämpfen wir ständig an, und eines der Einfallstore möchten wir jetzt schließen. Es handelt sich um den Port 25. Ein Port identifiziert zusammen mit der IP-Adresse das Ziel einer Internetverbindung, 25 steht für „SMTP“: „Simple Mail Transfer Protocol“, einfaches E-Mail Transport-Protokoll (es gibt übrigens kein „kompliziertes E-Mail Transport-Protokoll“, E-Mail ist schon so komplex genug ;-)). Dieser Port wird von Spam-Versendern häufig und auch von unserem Webspace genutzt um gefälschte und ungewollte E-Mails bei anderen Mail-Servern über das Internet einzuliefern. Für den häufigsten Zweck, nämlich E-Mail über einen Server zu versenden, bei dem man ein „Kundenkonto“ bzw. einen gesicherten Zugang hat, gibt es aber einen anderen Port für das gleiche Protokoll (587/Submission). Es ist 100% kompatibel, da es ebenfalls SMTP ist und gleichzeitig fast immer so konfiguriert, dass vor dem Versand einer E-Mail geprüft wird, ob der Versender auch berechtigt ist über den Mail-Server zu versenden.

Da auch viele andere Provider, ob Webspace, Server oder Cloud, den Port 25 sperren und nur Mail-Versand per Port 587 erlauben, ziehen wir mit und machen das Internet damit ein bisschen Spam-feindlicher. Für legitimen E-Mail-Versand macht das keinen Unterschied.

Zum 1.4. werden wir daher über PHP das Herstellen ausgehender SMTP-Verbindungen zu Port 25 nicht mehr zulassen. Der Versand von E-Mails über SMTP ist selbstverständlich weiterhin möglich, dazu sollte allerdings der besser geeignete Port 587 (für Submission) verwendet werden, SMTPS (465) kann selbstverständlich auch genutzt werden. Und zu guter letzte bleibt auch die Möglichkeit, die PHP-Funktion mail() zu verwenden.

Bin ich betroffen?
Betroffen ist Dein Mail-Versand, wenn beide Voraussetzungen erfüllt sind: a) Du versendest per PHP E-Mails (z.B. über ein Kontaktformular, Bestellbestätigungen eines Shops, etc) b) Du hast den Versand über einen Mail-Server per SMTP eingestellt, z.B. über Deinen Account bei Googlemail oder web.de. Benutzer des Mail-Servers bei lima-city, der Versand über unseren Mail-Server oder der Versand von E-Mail über PHP-Mail sind nicht betroffen.

Was ändert sich für mich?
Wenn Du betroffen bist (siehe oben) musst Du nur die Port-Nummer in den Einstellungen des SMTP-Servers ändern. Dort sollte als Port „25“ eingetragen sein. Ändere diese Einstellung bitte auf „587“, aktiviere die Verschlüsselung (STARTTLS) und speichere die Änderung. Bitte denke auch daran eine Test-Mail zu senden. Das ist auch schon alles!

Ich verwende für den Versand per SMTP ein Postfach auf dem Mail-Server von lima-city. Bin ich auch betroffen?
Grundsätzlich schadet es nicht, wenn Du die Änderung vornimmst, da der Port 587 dafür semantisch besser passt. Der Mail-Server wird aber von uns nicht blockiert, da er in unserem eigenen Netz steht und entsprechend abgesichert ist.

Heute haben wir eine neue „Endung“ für die kostenlosen Subdomains hinzugefügt: „.de.cool“.

Damit können nun in der Verwaltung neue Subdomains in Form von „[benutzername].de.cool“ erstellt werden: in der Verwaltung unter „Websites & Domains“ auf „lima-city-Subdomain erstellen“ klicken und aus der Liste „[benutzername].de.cool“ auswählen. Nach dem Speichern ist die Domain innerhalb von ein paar Minuten aktiv. Selbstverständlich sind die Subdomains alle per SSL erreichbar.