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.

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.

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.

Verbesserung der Anti-Spam-Maßnahmen

Nachdem sich unser vor 8 Monaten eingeführtes Greylisting verdächtiger E-Mails in der Praxis gut bewährt hat, haben wir heute (03.06.2016) eine weitere Verschärfung unserer Anti-Spam-Maßnahmen vorgenommen:

Bisher wurden E-Mails, die bestimmte Verdachtskriterien erfüllen, zunächst temporär abgelehnt, und erst in einem folgenden Zustellversuch nach einer Verzögerung von mindestens 5 Minuten angenommen (Greylisting). Bei manchen E-Mails treffen jedoch so viele Verdachtskriterien zu, dass praktisch ausgeschlossen werden kann, dass es sich um legitime E-Mails handelt. Solche E-Mails werden daher nun sofort als Spam klassifiziert und entsprechend der gewählten Spam-Filter-Einstellungen (Reject, Subject Rewrite, Junk-Ordner) behandelt.

Wir greifen dabei nicht auf ein einzelnes Kriterium zurück, sondern nutzen eine Kombination aus RFC-Standards und DNS-Blacklisten, dadurch ist die Gefahr von zusätzlichen False-Positives bei E-Mails von korrekt konfigurierten legitimen Mail-Servern praktisch ausgeschlossen.

Beginn der Let’s Encrypt Testphase

Wie angekündigt beginnt ab heute (23.05.2016) die Testphase für Let’s Encrypt-Zertifikate auf unseren Webservern.

Während der Testphase kann in jedem Webhosting-Paket ein Let’s Encrypt-Zertifikat (gültig für eine Domain sowie auf Wunsch eine zusätzliche Subdomain wie z.B. www) kostenfrei genutzt werden. Reseller können in der Testphase für ihre Hosting-Kunden insgesamt bis zu 10 Let’s Encrypt-Zertifikate erhalten. Die Einrichtung der Zertifikate ist während der Testphase noch nicht über unser Kundenmenü möglich, bitte wenden Sie sich dazu an unsere Kundenbetreuung.

Nach Ablauf der Testphase bleiben Ihre Zertifikate erhalten, wir planen in jedem Webhosting-Paket für unsere Endkunden mindestens ein Let’s Encrypt-Zertifikat ohne Mehrkosten anbieten, die dann einfach über unser Kundenmenü eingerichtet werden können. Reseller werden je nach Paket eine bestimmte Anzahl an Inklusiv-Zertifikaten erhalten.

Voraussetzung für die Ausstellung von Let’s Encrypt-Zertifikaten ist die Nutzung unserer Nameserver. Die Zertifikate gelten weiterhin nur auf unseren Webservern, falls Sie eine Domain per DNS A-Record auf Webserver von einem anderen Anbieter weiterleiten, müssen Sie ein SSL-Zertifikat bei diesem Anbieter beauftragen.

Weiterhin unterstützt Let’s Encrypt gegenwärtig keine Domain-Namen mit Sonderzeichen (IDN).

Tipp: In unseren FAQ finden Sie eine Anleitung, wie Sie nach Einrichtung des Zertifikats alle unverschlüsselten HTTP-Aufrufe auf HTTPS umleiten können.

Unterschiede zwischen Let’s Encrypt- und Comodo-Zertifikaten

Wir haben auf unseren Webservern bisher ausschließlich SSL-Zertifikate der Firma Comodo genutzt. SSL-Zertifikate dienen nicht nur zur Verschlüsselung, sondern weisen auch den Inhaber einer Domain verbindlich aus. Zur Überprüfung der Inhaberschaft gibt es unterschiedliche Verfahren:

  • Das einfachste Verfahren ist die Domain-Validierung, dabei prüft die Zertifizierungstelle mittels automatisierter technischer Vefahren, ob der Inhaber der Domain mit dem des Zertifikats übereinstimmt. Dies kann beispielsweise über spezielle DNS-Einträge erfolgen, die nach Vorgabe der Zertifizierungstelle angelegt werden müssen, und dann von dieser automatisch überprüft werden. Bei Domain-validierten Comodo-Zertifikaten übernehmen wir selbst die Prüfung der Inhaberangaben.
  • Ein besseres Verfahren ist die Inhaber- bzw. Organisations-Validierung, dazu muss der Besitzer einer Domain sich bei der Zertifizierungstelle (z.B. mittels Personalausweiskopie bei Privatpersonen oder Handelsregisterauszug bei Firmen) ausweisen, und diese Daten werden dann mit den im Whois der Domain hinterlegten Inhaberdaten verglichen. Im Zertifikat wird der Inhaber dann im Feld Organisation hinterlegt, während dieses Feld bei Domain-validierten Zertifikaten leer bleibt. Zusätzlich erfolgt eine telefonische Validierung des Inhabers durch die Zertifizierungsstelle.
    Wir empfehlen Unternehmen, Inhaber-validierte Zertifikate zu nutzen, da bei Domain-validierten Zertifikaten ein Missbrauch durch Angabe falscher Inhaber-Informationen viel einfacher möglich ist. Inhaber-validierte Zertifikate sind in der Wahrnehmung der meisten Nutzer seriöser und vertrauenswürdiger.
  • Eine besonders strenge Prüfung erfolgt bei sogenannten Extended Validation Zertifikaten, die sich für hohe Sicherheitsanforderungen empfehlen. Bei diesen wird der Inhaber des Zertifikats in der Bowser-Adresszeile grün hinterlegt angezeigt (vgl. www.variomedia.de), allerdings sind diese Zertifikate auch besonders teuer.

Let’s Encrypt Zertifikate sind ausschließlich Domain-validiert, eine Inhaber-Validierung ist nicht möglich.

Ein weiterer Unterschied besteht bei der Einbindung der Zertifikate auf den Webservern: Auf unseren Webservern verwenden wir (wie alle Shared-Hosting-Anbieter) das sogenannte namensbasierte Virtual Hosting, dabei nutzen alle Domains auf einem Webserver die gleiche IPv4-Adresse, und der Webserver ordnet einer Domain anhand des vom Browser gesendeten HTTP Host-Headers eine Webseite zu. Bei Domains mit SSL-Zertifikaten war es jedoch bis vor wenigen Jahren noch nicht möglich, mehrere Zertifikate unter der gleichen IP-Adresse zu nutzen, daher erhält jedes Comodo-Zertifikat aus technischen Gründen immer eine eigene IPv4-Adresse, die dann zusätzlich auf dem Webserver eingerichtet wird.

Für Let’s Encrypt-Zertifikate können wir jedoch keine eigenen IPv4-Adressen mehr vergeben, denn dafür stehen uns nicht genügend ungenutzte IPv4-Adressen zur Verfügung. Mittlerweile gibt es jedoch mittels SNI die Möglichkeit, beliebig viele SSL-Zertifikate unter einer IP-Adresse zu nutzen, allerdings wird dieses Verfahren von älteren Browsern (z.B. Internet Explorer 6) und Betriebssystemen (z.B. Windows XP, Android 2.4) nicht unterstützt. Es kann daher mit Let’s Encrypt-Zertifikaten bei älteren PCs, Smartphones oder Tablets zu Problemen kommen.

Hinsichtlich der Verschlüsselung gibt es jedoch keine Unterschiede zwischen Let’s Encrypt- und Comodo-Zertifikaten, unsere Webserver erfüllen alle modernen Standards wie TLS Version 1.2, (EC)DHE-Schlüsselaustausch (Perfect Forward Secrecy) und AES-Verschüsselung (SSL Labs Note A+ bei gesetztem HSTS-Header).

Update vom 01.02.2017: Die Testphase ist jetzt beendet. Bitte beachten Sie folgenden Blog-Beitrag: Let’s Encrypt-Zertifikate jetzt offiziell erhältlich

DDoS-Angriff auf unser Rechenzentrum

Am 17.05.2016 gab es zwischen 14:05 und 14:45 Uhr einen sogenannten DDoS-Angriff auf unser Rechenzentrum.

Der Angriff galt nicht uns, sondern zielte auf einen anderen Kunden des Betreibers unseres Rechenzentrums. Durch den Angriff kam es zu einer Überlastung der Internet-Anbindungen (z.B. zur Telekom) des Rechenzentrums, so dass unsere Dienste zu dieser Zeit teilweise nicht erreichbar waren. Wir bitten, die Störung zu entschuldigen.

Kostenlose Let’s Encrypt Zertifikate bei Variomedia

Wie bereits angekündigt, wird es bald möglich sein, über uns kostenlose SSL-Zertifikate von Let’s Encrypt auf den Webservern zu beauftragen.

Wir haben die dafür nötigen Technologien und Methoden implementiert und werden voraussichtlich ab dem 23.05. zunächst eine Testphase für interessierte Kunden anbieten, um eventuell noch auftretende Probleme bei der automatischen Erstellung und Validierung von Zertifikaten zu beseitigen.

In der Testphase können SSL-Zertifikate auf Wunsch durch unsere Kundenbetreuung installiert werden, genauere Details zum Ablauf werden wir nächste Woche bekannt geben. Sobald alles zuverlässig funktioniert, können SSL-Zertifikate später einfach per Mausklick im Kundenmenü eingerichtet werden.

Wir planen, in jedem unserer Webhosting-Pakete zukünftig mindestens ein kostenloses SSL-Zertifikat anzubieten, das für eine Domain sowie die zugehörige www-Subdomain gilt.

Probleme mit ownCloud und PHP 7

Gegenwärtig gibt es ein Problem mit ownCloud und der aktuellen PHP-Version 7.0.6, die wir am 29.04. auf allen Webservern installiert haben. Betroffen sind ausschließlich Kunden, die PHP 7 manuell über eine .htaccess-Konfigurationsdatei aktiviert haben. Unter PHP 7 wird beim Aufruf der ownCloud-Seite die Fehlermeldung “Interner Serverfehler” angezeigt. Die Ursache ist ein Programmierfehler in ownCloud, der bei den vorigen PHP-Versionen noch keine Auswirkungen hatte.

Die einfachste Lösung für dieses Problem ist die ältere PHP-Version 5.6 zu nutzen, bis der Fehler durch ein ownCloud-Update behoben wird. Eine Anleitung zur Auswahl der PHP-Version finden Sie hier.

Falls Sie weiterhin PHP 7 nutzen möchten, muss die PHP-Datei “request.php” im ownCloud-Unterverzeichnis “lib/private/appframework/http” angepasst werden. Sie können diese Datei per (S)FTP herunterladen oder direkt auf dem Webserver mit einem Texteditor bearbeiten. Suchen Sie nach der Zeile “public function __isset($name) {” und fügen dort die folgenden 3 grün markieren Zeilen hinzu:

    public function __isset($name) {
        if (in_array($name, $this->allowedKeys, true)) {
            return true;
        }
        return isset($this->items['parameters'][$name])
    }

Update vom 02.05.2016: Wir haben bei allen von uns für Kunden installierten Owncloud-Instanzen die entsprechenden Änderungen vorgenommen.