SFTP für virtuelle FTP-Benutzer

Bisher konnten virtuelle FTP-Benutzer nur unverschlüsselte FTP-Verbindungen und kein verschlüsseltes SFTP nutzen, dies war nur für den FTP-Hauptbenutzer möglich. Da unverschlüsselte FTP-Verbindungen aus Sicherheitsgründen nicht mehr benutzt werden sollten, bieten wir ab sofort SFTP auch für virtuelle FTP-Benutzer über den TCP-Port 2222 an. Für weitere Informationen beachten Sie bitte den zugehörigen FAQ-Artikel.

Hintergründe

Der SFTP-Dienst wurde bisher nicht mittels des von uns für FTP-Verbindungen genutzten Dienstes ProFTPD realisiert, sondern über den SSH-Dienst OpenSSH, der im Gegensatz zu ProFTPD keine virtuellen Benutzer unterstützt. ProFTPD unterstützt zwar grundsätzlich auch SFTP-Verbindungen, allerdings kann OpenSSH nicht einfach durch ProFTPD ersetzt werden, da OpenSSH noch weitere Funktionen wie z.B. eine Login-Shell bereit stellt, auf die wir nicht verzichten können. Weiterhin war die SFTP-Unterstützung in ProFTPD in der Vergangenheit noch sehr fehlerbehaftet, es kam z.B. häufig zu Problemen beim Verbindungsaufbau. In der aktuellen ProFTPD-Version sind diese Fehler jedoch weitgehend behoben, so dass einem Produktiveinsatz nun nichts mehr im Wege steht.

Um SFTP für virtuelle FTP-Benutzer zu realisieren, nutzen wir den TCP-Port 2222, da der Standard-Port 22 bereits vom SSH-Dienst belegt ist. Sie können SFTP-Verbindungen sowohl für den FTP-Hauptbenutzer als auch für alle virtuellen Benutzer über diesen Port nutzen (der FTP-Hauptbenutzer kann jedoch auch weiter den Standard-Port 22 für SFTP nutzen).

PHP 7.1 verfügbar

Auf unseren Webservern steht ab sofort die heute (02.12.2016) neu erschienene PHP-Version 7.1 zur Verfügung.

Vorteile von PHP 7.1

Bei der Entwicklung von PHP 7.1 wurden hauptsächlich kleinere Verbesserungen und Funktionserweiterungen vorgenommen. Für Endanwender interessant sind die möglichen Performance-Steigerungen durch den Wechsel auf PHP 7.1, diese belaufen sich auf bis zu 10% verglichen mit PHP 7.0.

Unterschiede zu PHP 7.0

Eine Übersicht über die Änderungen im Vergleich zur Vorgängerversion PHP 7.0 finden Sie hier. Grundsätzlich fallen die Unterschiede relativ gering aus, dennoch kann es bei einigen Anwendungen zu Kompatibilitätsproblemen kommen. So gibt es beispielsweise noch einige Probleme mit WordPress und PHP 7.1, die mit der voraussichtlich am 6.12. erscheinenden WordPress-Version 4.7 behoben werden.

PHP 7.1 aktivieren

Sie können PHP 7.1 für Ihre Webseiten wie üblich per .htaccess-Datei mittels folgender Direktive aktivieren:

AddHandler application/x-httpd-php71 .php

PHP 7.1 RC6 verfügbar

Auf unseren Webservern steht ab sofort der neueste und voraussichtlich letzte Release Candidate von PHP Version 7.1 zu Testzwecken zur Verfügung. Bitte beachten Sie, dass es sich noch um eine Vorabversion handelt, die nicht für den Produktiveinsatz gedacht ist. Sofern keine unerwarteten Probleme auftreten, wird PHP 7.1 planmäßig gegen Ende dieses Monats erscheinen.

Sie können PHP 7.1 wie üblich per .htaccess-Datei mittels folgender Direktive aktivieren:
AddHandler application/x-httpd-php71 .php

Eine Übersicht über die Änderungen im Vergleich zu Version 7.0 finden Sie hier. Da die Unterschiede zwischen Version 7.0 und 7.1 sehr gering sind, funktionieren die meisten zu PHP 7.0 kompatiblen Anwendungen auch problemlos mit PHP 7.1. Bei einigen bekannten PHP-Anwendungen wie z.B. WordPress können jedoch noch Probleme auftreten, für diese Anwendungen werden demnächst Updates erscheinen, um diese Probleme zu beheben.

Beim Umstieg von PHP 7.0 auf 7.1 sind keine so großen Performance-Sprünge wie beim Umstieg von Version 5.6 auf 7.0 zu erwarten, wir konnten in ersten Tests immerhin eine bis zu 10% höhere Ausführungsgeschwindigkeit im Vergleich zur Vorgängerversion feststellen.

Änderung unserer SSL-Konfiguration (Deaktivierung Triple-DES)

Durch eine heute bekannt gewordene Sicherheitslücke in der Verschlüsselungsmethode Triple-DES, die von sehr alten Browsern für SSL-Verbindungen zu unseren Webservern genutzt wird, nehmen wir morgen im Laufe des Tages eine Konfigurationsänderung an allen Servern vor.

Die Änderung hat zur Folge, dass Nutzer, die die Kombination aus Windows XP und dem Internet Explorer 8 verwenden, keine verschlüsseleten Webseiten (https://…) mehr aufrufen können. Da sowohl Windows XP, als auch der Internet Explorer 8 seit vielen Jahren nicht mehr aktualisiert werden und demnach nicht mehr genutzt werden sollten, dürften die praktischen Auswirkungen der Änderungen sehr gering sein.

Das Problem tritt nur im Internet Explorer 8 unter Windows XP auf; andere Browser unter Windows XP können die Seiten weiterhin problemlos aufrufen.

 

Beschränkung der Zahl gleichzeitiger Empfänger pro E-Mail

Bisher war es möglich, über unsere SMTP-Server (smtp.variomedia.de) E-Mails mit nahezu beliebig vielen Empfängern zu versenden. Gemeint ist damit nicht die Zahl der E-Mails, sondern die Anzahl der Empfänger pro E-Mail (in den Feldern „An“, „CC“ oder „BCC“).

Eine E-Mail darf ab sofort maximal an 150 Empfänger („An“, „CC“ oder „BCC“) gleichzeitig gesendet werden. Wird diese Zahl überschritten, reagiert der SMTP-Server mit der Fehlermeldung „too many recipients“. Die gesamte E-Mail wurde dann nicht versendet. Sie können die E-Mail jederzeit erneut versenden, wenn Sie die Zahl der Empfänger reduziert haben. Der Versand mehrerer E-Mails mit jeweils unter 150 Empfängern ist problemlos möglich.

Die Einschränkung ist notwendig, um den Versand vom Spam über Postfächer mit ausgespähten Zugangsdaten einzudämmen.

Bitte beachten Sie, dass Newsletter oder andere Arten von legitimen Massen-E-Mails über darauf spezialisierte Software (z.B. PHPList) als einzelne E-Mails versendet werden sollten. Diese Programme verfügen in der Regel über ein Bounce-Management, d.h. sie können automatisiert auswerten, welche E-Mails zustellbar waren und ungültige E-Mail-Adressen aus dem Verteiler entfernen. In einem FAQ-Artikel haben wir näher beschrieben, warum eine hohe Anzahl unzustellbarer E-Mails zur Sperrung eines Postfachs führen kann.

PHP 5.5 End of Life

Mit der gestern (21.07.) veröffentlichten PHP-Version 5.5.38 wird die Unterstützung des Versionszweiges 5.5 von den PHP-Entwicklern eingestellt, es wird keine weiteren Updates (z.B. wegen Sicherheitslücken) für diese PHP-Version mehr geben. Wir empfehlen daher allen Kunden, die gegenwärtig noch PHP 5.5 nutzen, auf die neueren PHP-Versionen 5.6 oder 7.0 zu wechseln. Beim Wechsel von PHP 5.5 auf 5.6 treten nur in sehr selten Fällen Kompatibiltätsprobleme auf, da es keine großen Unterschiede zwischen beiden Versionen gibt. Bei PHP 7.0 wurden viele veraltete Bibliotheken und Funktionen entfernt, so dass hier häufiger Kompatibilitätsprobleme auftreten. Die PHP-Versionen 5.6 und 7.0 werden noch bis Ende 2018 mit regelmäßigen Sicherheitsupdates versorgt.

Sie können die auf Ihrem Webserver standardmäßig genutzte PHP-Version mittels SSH über den Shell-Befehl php -v oder der PHP-Funktion phpinfo() ermitteln. Mittels dieser Funktion können Sie auch prüfen, ob die Umstellung Ihrer Webseite auf eine andere PHP-Version erfolgreich war. Erstellen Sie dazu im gewünschen Webspace-Verzeichnis eine Textdatei mit der Endung .php (z.B. info.php) und dem Inhalt <?php phpinfo(); ?> und rufen diese Datei dann über Ihren Web-Browser auf (z.B. www.domain.de/info.php).

Eine Anleitung zum Wechsel der PHP-Version finden Sie hier. Falls Sie PHP-FPM nutzen, können Sie diese PHP-Version nicht selbst ändern, wenden Sie sich in diesem Fall bitte an unsere Kundenbetreuung.

Aufgrund möglicher Kompatibilitätsprobleme können wir die standardmäßig genutzte PHP-Version auf dem Webservern nicht einfach auf 5.6 oder 7.0 umstellen, da in diesem Fall bestehende Webseiten unter Umständen nicht mehr funktionieren.

Störung eines Mailservers am 14./15.07.2016

In der Nacht vom 13. zum 14.07.2016 kam es nach routinemäßigen Wartungsarbeiten an einem unserer Mailserver zu umfangreichen Störungen, die wir leider erst nach etwa 36 Stunden vollständig beheben konnten. Wir möchten in diesem Beitrag auf einige Fragen unserer Kunden eingehen und die Hintergründe des Ausfalls erläutern. Für die mit der Störung verbundenen Unannehmlichkeiten bitten wir vielmals um Entschuldigung.

Was ist passiert?

Am 13.07. haben wir um 23 Uhr die IMAP-Software eines unserer Mailserver auf eine neue Version aktualisiert. Andere Mailserver nutzten die neue Version bereits ohne Probleme, daher war nicht mit Schwierigkeiten zu rechnen.

Auf diesem Server kam es jedoch einige Stunden nach der Aktualisierung zu ebenso massiven wie unerklärlichen Performance-Problemen: Sobald der Server mehr als 1.500 IMAP-Verbindungen hatte, stieg die Serverlast extrem an und der Server reagierte nicht mehr. Dies führte zu erfolglosen Verbindungsversuchen, Timeouts und Verbindungsabbrüchen.

Das Update konnte nicht mehr rückgängig gemacht werden, da nach der Aktualisierung an allen Postfächern Änderungen durchgeführt wurden, die nicht abwärtskompatibel sind. Wir waren daher gezwungen, die Fehlerursache so schnell wie möglich zu finden und zu beheben. In den folgenden 36 Stunden bis zur Behebung des Fehlers haben unsere Mitarbeiter ununterbrochen daran gearbeitet. Zunächst vermuteten wir als Fehlerursache einen Engpass im Speichersystem, daher entschlossen wir uns, den betroffenen Mailserver von Festplatten auf schnellere SSDs umzurüsten. Da mehrere Terabyte an Daten kopiert werden mussten, hat es bis in die Nacht des folgenden Tages gedauert, bis der Server wieder online gehen konnte. Leider zeigte diese Maßnahme keinerlei Wirkung.

Am Ende stellte sich das Problem als ein Programmierfehler in der zentralen Postfachdatenbank der von uns eingesetzten Mailserver-Software Cyrus heraus. Perfiderweise manifestiert sich der Fehler nur unter bestimmten Bedingungen so dramatisch wie in unserem Fall. Am 15.7. gegen 13:30 führten wir Maßnahmen zur Umgehung des Fehlers durch, die das Problem erfolgreich behoben haben. Der Fehler wurde anschließend an die Entwickler der IMAP-Serversoftware kommuniziert und umgehend behoben. Durch die schnellen SSDs im Server ist der E-Mail-Zugriff nun schneller als je zuvor.

Zu keinem Zeitpunkt sind E-Mails verloren gegangen. In der Zeit, in der der Server nicht erreichbar war, wurden eingehende E-Mails auf anderen Servern zwischengespeichert und später zugestellt. Einige Kunden berichten davon, dass während der Störung gesendete E-Mails nicht als Kopie im Ordner “Gesendet” abgelegt wurden. Dies kann tatsächlich durch die Überlastung passiert sein. Wenn Sie Informationen benötigen, ob eine bestimmte E-Mail tatsächlich verschickt wurde, können wir dies für einige Tage in unseren Logdateien nachvollziehen. Bitte kontaktieren Sie in diesem Fall unsere Kundenbetreuung.

Wozu die neue Version?

Wir haben das Update vorgenommen, um Probleme mit der automatischen Erkennung von Standard-Ordnern unter Microsoft Outlook zu beheben. Die von uns nun verwendete Version 2.5.8 ist die neunte stabile Veröffentlichung in der 2.5.x Serie.  In dieser Software, die seit über einem Jahr (2.5.0 wurde am 03.03.2015 veröffentlicht) weltweit produktiv im Einsatz ist, haben wir keine Fehler solchen Ausmaßes mehr erwartet und in unseren Tests auch nicht erkennen können.

Welche Dienste genau waren betroffen?

Bei dem betroffenen Server handelt es sich um eines von mehreren “Mail-Backends”. Dies sind Server, auf denen die E-Mails unserer Kunden als Dateien gespeichert sind. Diese Server sind nicht direkt von außen erreichbar. Es gibt MX-Server, die E-Mails von fremden Mailservern annehmen und auf dem Mail-Backend ablegen. Der Abruf der E-Mails erfolgt dann über Dienste wie POP3 und IMAP, die überwiegend lesend auf die Mail-Backends zugreifen. Da wir mehrere Mail-Backends betreiben, waren von der Störung nur Domains betroffen, die auf diesem Backend eingerichtet waren. Viele Kunden waren irritiert, dass sie Probleme beim Abruf der E-Mails von einer Domain hatten, E-Mails von einer anderen Domain aber problemlos abgerufen werden konnten. Nach außen sieht es so aus, als wären „imap.variomedia.de“ bzw. „pop3.variomedia.de“ nur ein Server, tatsächlich ist es jedoch ein sogenannter Proxy, der die Verbindungen an das für das jeweilige Postfach zuständige Backend weiterleitet.

Wie wurden Kunden über die Störung informiert?

Die einzige realistische Option, alle Kunden im Fall einer solchen Störung aktiv zu informieren, wäre eine E-Mail gewesen. Gerade die betroffenen Kunden hätten die E-Mail aufgrund der Störung aber gar nicht abrufen können. Besonders aufgrund solcher Zusammenhänge nutzen wir für die Meldung von Problemen oder Ausfällen unseren Twitter-Feed, der auch ohne Twitter-Account öffentlich aufrufbar ist. Über beide Tage hinweg haben wir hier aktuell über den Stand der Dinge berichtet und auch viele Fragen von Kunden beantworten können. Nicht gelungen ist es uns, alle Anrufe anzunehmen; dafür waren es einfach zu viele Kunden, die völlig berechtigt wissen wollten, wann der E-Mail-Abruf wieder zuverlässig funktioniert.

Entschuldigung!

Wir sind uns bewusst, dass E-Mails ein wichtiger Pfeiler des privaten und geschäftlichen Lebens sind und ein längerer Ausfall für unsere betroffenen Kunden sehr schmerzvoll ist. Dafür bitten wir in aller Form um Entschuldigung.

Update vom 16.07.2016, 16:45 Uhr: Ergänzung zur Frage, ob E-Mails verloren gegangen sind hinzugefügt.

Störung eines Mailservers am 14./15.07.2016

In der Nacht vom 13. zum 14.07.2016 kam es nach routinemäßigen Wartungsarbeiten an einem unserer Mailserver zu umfangreichen Störungen, die nach wie vor andauern. Unter https://twitter.com/Variomedia finden Sie unseren Twitter-Feed, über den wir aktuell über den Stand der Dinge berichten. Hier im Blog wird es nach Abschluss der Arbeiten einen ausführlichen Bericht geben. Für die entstandenen Unannehmlichkeiten bitten wir alle betroffenen Kunden vielmals um Entschuldigung.

Update von 14:05 Uhr: Wir haben den Fehler gefunden und endgültig behoben. Ein ausführlicher Bericht folgt hier in Kürze!

Neues Sieve-Plugin im Webmail (serverbasierte Filterregeln für E-Mails)

Ab sofort steht in unserem Webmail ein neues Sieve-Plugin für die serverbasierte Filterung und Sortierung von eingehenden E-Mails zur Verfügung.

Serverbasierte Mailfilter (“Sieve”) haben den Vorteil, dass sie unabhängig vom E-Mail-Client ausgeführt werden. Auf mobilen Clients stehen oft keine Filterfunktionen für E-Mails zur Verfügung. Es ist daher sinnvoll, eingehende E-Mails serverseitig zu sortieren, um im Posteingang den Überblick zu behalten. Auch wenn Sie E-Mails mit mehreren Geräten oder PCs lesen, müssen Sie dort die Filterregeln nicht mehrfach pflegen.

Das neue Sieve-Plugin im Webmail erlaubt feinste Abstufungen, die bisher nur deutlich komplizierter zu realisieren waren. So können Sie zum Beispiel E-Mails, mit einem bestimmten Dateityp im Anhang in einen bestimmten Ordner einsortieren, indem Sie folgende Regel anlegen – hier im Beispiel für gepackte ZIP-Dateien (siehe Bild oben):

Body –> Raw –> weitere Optionen –> trifft auf den regulären Ausdruck zu –> filename=”.+\.zip”

Bitte beachten Sie, dass die eingerichteten Filterregeln stets nur für neue, eingehende E-Mails funktionieren. E-Mails, die bereits im Posteingang liegen, lassen sich auf diese Weise nicht sortieren.

Probleme mit der Autodiscover-Funktion von Outlook und Exchange (ActiveSync)

Microsoft Outlook und andere Exchange-kompatible E-Mail-Programme nutzen einen sogenannten Autodiscover-Mechanismus, um die Einstellungen (z.B. Posteingangsserver, Postausgangsserver, Authentifizierungsmethode) zu einem E-Mail-Postfach automatisch zu erkennen. Leider hat dieser Mechanismus einen grundlegenden Konstruktionsfehler, der seit der Einführung von Let’s Encrypt-Zertifikaten auf unseren Webservern zu unerwarteten Problemen führt:

Bei der Einrichtung eines neuen Postfachs sucht Outlook zuerst unter der Domain der E-Mail-Adresse per HTTPS nach einer passenden Konfigurationsdatei (z.B. “https://variomedia.de/autodiscover/autodiscover.xml”). Wenn die Verbindung zum HTTPS Port 443 abgelehnt wird, oder die Konfigurationsdatei nicht exisitiert, wird im nächsten Schritt die Subdomain autodiscover probiert (z.B. “https://autodiscover.variomedia.de/autodiscover/autodiscover.xml”). Wenn auch dies fehlschlägt, wird im letzten Schritt nach einem Autodiscover-SRV-Eintrag im DNS gesucht. Wenn jedoch ein ungültiges SSL-Zertifikat für die (Sub-)Domain hinterlegt ist, so wird eine entsprechende Warnung angezeigt.

Leider hat Microsoft dabei nicht bedacht, dass es auch Webserver gibt, die Server Name Identification (SNI) für SSL-Zertifikate nutzen, um mehrere Zertifikate unter einer IP-Adresse zu ermöglichen. In diesem Fall ist für manche Domains ein SSL-Zertifikat hinterlegt, und für andere Domains nicht. Wenn auf eine Domain, für die kein gültiges SSL-Zertifikat hinterlegt ist, per HTTPS zugegriffen wird, so liefert der Webserver standardmäßig das erste vorhandene SSL-Zertifikat aus. Da dieses Zertifikat aber nicht für die angefragte Domain gilt, wird nun eine entsprechende Warnung angezeigt.

Falls Sie einen neuen E-Mail-Account in Outlook einrichten, und für Ihre Domain kein SSL-Zertifikat hinterlegt ist, kommt es daher nun immer zu einer Fehlermeldung. Ihnen wird dann das SSL-Zertifikat für “ws0.web.vrmd.de” angezeigt. Sie können dieses Zertifikat entweder akzeptieren, oder die automatische Einrichtung mittels Autodiscover abbrechen.

Wir bieten einen Autodiscover-Dienst für Outlook und andere Exchange-kompatible E-Mail-Programme unter autodiscover.variomedia.de (bzw. autodiscover.securehost.de) an, der über einen SRV-Eintrag im DNS-Bereich genutzt werden kann. Diese SRV-Einträge wurden im Zuge der Einführung von Open-Xchange für alle Domains automatisch gesetzt.

Update vom 16.06.:

Wir werden für Let’s Encrypt Zertifikate zukünftig eine zusätzliche IP auf jedem Webserver einrichten, so dass die normale Webserver-IP keine HTTPS-Verbindungen mehr annimmt. Damit kann dieses Problem nicht mehr auftreten.