PHP 7 RC 3 verfügbar

Ab sofort steht auf unseren Webservern der aktuelle Release Candidate 3 von PHP 7 zu Testzwecken zur Verfügung.

Wir haben dabei eine für viele Kunden interessante Neuerung hinzugefügt, und zwar einen Datei-basierten PHP-Beschleuniger.

Hintergründe zu PHP-Beschleunigern

PHP ist eine Script-Sprache, die vor der Ausführung auf unseren Webservern in für Computer verständlichen Mikroprozessor-Code übersetzt werden muss. PHP nutzt dabei (ähnlich wie Java) eine sogenannte Virtuelle Maschine, es wird also nicht direkt Mikroprozessor-Code erzeugt, sondern zunächst sogenannter Bytecode für eine Virtuelle Maschine (Zend Engine), die daraus dann im nächsten Schritt Mikroprozessor-Code erzeugt und diesen ausführt.
Dieser Bytecode wird jedoch nach der Ausführung eines PHP-Scripts verworfen, und muss jedes Mal zeitaufwändig neu generiert werden. Um dies zu vermeiden gibt es diverse PHP-Beschleuniger wie den PHP-eigenen OpCache, die den Bytecode für spätere Script-Aufrufe optimieren und zwischenspeichern. Allerdings wurde dieser Bytecode bisher immer im Arbeitsspeicher abgelegt, was auf unseren Shared-Hosting-Servern aus technischen Gründen nicht funktioniert, und nur in den Pro-Paketen (bzw. auf Dedicated-Servern) mit PHP-FPM möglich ist.

Seit PHP 7 kann der PHP OpCache den Bytecode optional auch in Dateien speichern, damit lässt er sich auf allen Shared-Hosting-Servern nutzen.

Wir haben anhand einer aktuellen WordPress-Installation die möglichen Performance-Verbesserungen durch OpCache getestet (Mittelwert über 100 Aufrufe):

opcache-file-small

Im Vergleich zu PHP 5.6 ohne OpCache verkürzt sich die PHP-Ausführungszeit für die WordPress-Startseite um Faktor 2, der Datei-OpCache lohnt sich also wirklich.

PHP 7 und OpCache aktivieren

Um PHP 7 mit OpCache zu nutzen, erstellen Sie zunächst ein Verzeichnis für die Bytecode-Dateien auf Ihrem Webserver. Dieses Verzeichnis können Sie beliebig benennen (z.B. “opcache”), und an beliebiger Stelle in Ihrem Benutzerverzeichnis anlegen, die Zugriffsrechte sollten jedoch aus Sicherheitsgründen auf Ihren Benutzeraccount beschränkt werden (chmod 700).

Legen Sie dann im gewünschten Webserver-Verzeichnis eine .htaccess-Datei mit folgendem Inhalt an (bzw. fügen Sie folgende Zeile zu einer bestehenden .htaccess-Datei hinzu):

AddHandler application/x-httpd-php70 .php

Anschließend legen Sie in diesem Verzeichnis eine php.ini-Datei mit folgendem Inhalt an (bzw. fügen die folgenden Zeilen zu einer bestehenden php.ini-Datei hinzu):

zend_extension=/vrmd/webserver/php70/lib/opcache.so
opcache.file_cache=/homepages/u12345/opcache
opcache.file_cache_only=1

Ersetzen Sie dabei “/homepages/u12345/opcache” durch den vollständigen Pfad zu Ihrem Bytecode-Verzeichnis. Beachten Sie bitte, dass php.ini-Dateien nur in dem Verzeichnis gelten, wo auch das aufgerufene PHP-Script liegt, eventuell müssen Sie diese Datei daher noch in weitere Unterverzeichnisse kopieren.

Hinweis

Bitte beachten Sie, dass sich PHP 7 noch in der Entwicklungsphase befindet, es können noch diverse kleinere Fehler und Probleme auftreten. Sie sollten PHP 7 daher besser noch nicht für kritische Webseiten einsetzen.

PHP 7 im Performance-Vergleich

Die PHP-Entwickler haben für Version 7 drastische Performance-Verbesserungen um 100% und mehr im Vergleich zu den Vorgängerversionen angekündigt. Um dies zu überprüfen, haben wir die PHP-Ladezeiten einer aktuellen WordPress-Installation (Version 4.3) mit den unterschiedlichen bei uns verfügbaren PHP-Versionen gemessen (Mittelwert über 100 Zugriffe):

barchart

Tatsächlich ist PHP 7 deutlich schneller als die Vorgängerversionen, die angekündigte Verbesserung um 100% tritt unter PHP-FPM in Kombination mit dem PHP Opcode Cache tatsächlich ein.

Weitere Informationen zur Nutzung von PHP 7 auf unseren Webservern finden Sie hier.

Bitte beachten Sie, dass PHP-FPM  gegenwärtig nur in den Pro-Paketen bzw. für Reseller mit Dedicated-Server genutzt werden kann, zur Aktivierung von PHP-FPM wenden Sie sich bitte an unsere Kundenbetreuung.

Start von .online am 26.8.2015

Am 26. August um 18 Uhr (MESZ) startet die neue Top-Level-Domain “.online”. Vormerkungen sind noch bis Montag, den 24. August um 18 Uhr unter https://ntlds.variomedia.de möglich. Der Preis für .online-Domains beträgt 39,- Euro pro Jahr. Die Vergabe ist nicht beschränkt, d.h. jeder Interessent kann eine .online-Domain registrieren. Bis zum 26. August um 18 Uhr ist gegen einen einmaligen Aufpreis auch noch eine Vorab-Registrierung möglich, davon haben schon über 800 Interessenten einer .online-Domain Gebrauch gemacht. Details dazu finden Sie unter https://ntlds.variomedia.de/domain/online.

 

Die neue Top-Level-Domain: .online

 

Wir freuen uns auf den Start dieser neuen Top-Level-Domain und hoffen, möglichst viele der von unseren Kunden gewünschten Domains erfolgreich registrieren zu können!

 

PHP 7 RC 1 verfügbar

Auf unseren Webservern steht ab sofort der Release Candidate 1 von PHP 7 zu Evaluierungszwecken zur Verfügung.

Bitte beachten Sie, dass es sich noch nicht um die endgültige Release-Version handelt, die voraussichtlich gegen Mitte November erscheinen wird, es können also noch diverse kleinere Fehler und Probleme auftreten. Wir empfehlen daher, PHP 7 noch nicht für den Produktivbetrieb kritischer Webseiten zu nutzen, Sie können jedoch schon prüfen, ob Ihre Webseite mit PHP 7 kompatibel ist, und so rechtzeitig den Umstieg auf die neueste PHP-Version vorbereiten. Beim Umstieg auf PHP 7 ist insbesondere zu beachten, dass einige veraltete Funktionen, die unter PHP 5.6 noch funktioniert haben, unter PHP 7 nicht mehr zur Verfügung stehen.

Um PHP 7 für Ihre Webseite zu nutzen, erstellen Sie im gewünschten Webspace-Verzeichnis eine .htaccess-Datei mit folgendem Inhalt (bzw. fügen Sie folgende Zeile zu einer bestehenden .htaccess-Datei hinzu):

AddHandler application/x-httpd-php70 .php

Wir werden auch die nächsten Release Candidates von PHP 7 zeitnah auf unseren Webservern bereitstellen, bis hin zur Veröffentlichung der endültigen Release-Version von PHP 7.

Mit den Apache-Handler application/x-httpd-php70 kann zukünftig die aktuellste Version von PHP 7.0 auf unseren Webservern genutzt werden.

An der bisherigen Standard-PHP-Version des von Ihnen genutzen Webservers ändert sich nichts, für neue Präsenzen wird aktuell standardmäßig PHP 5.5 genutzt, ältere Webserver nutzen PHP 5.3.

Weitere Informationen zur Auswahl der PHP-Version finden Sie hier.

Freigabe von über 60.000 bisher gesperrten .berlin-Domains

Am 21. Juli 2015 werden über 60.000 .berlin-Domains freigegeben, die bisher zur Registrierung gesperrt waren. Sie können die vollständige Liste aller bisher gesperrten .berlin-Domains hier abrufen. Wir haben die Liste mit in Deutschland weit verbreiteten Vor- und Nachnamen und einem deutschen Wörterbuch abgeglichen.

Alle in der Liste aufgeführten Domains sind ab dem 21. Juli 2015 zum Preis von 48,- Euro pro Jahr frei registrierbar. Bitte wenden Sie sich an die Variomedia-Kundenbetreuung, um eine oder mehrere Domains zum Tag der Freigabe vorzumerken. Vielen Dank!

Sunrise-Start von .online am 18.06.2015

Im März 2014 startete mit .berlin die bei uns bisher erfolgreichste TLD aller neuen Top-Level-Domains. Auch weltweit steht .berlin recht weit vorn: Rund 150.000 Registrierungen bedeuten Platz 7 in der Rangliste, weit vor den TLDs anderer Städte.

Betrachtet man die Zahl der Vormerkungen dürfte die wohl generischste aller neuen Top-Level-Domains “.online” ähnlich erfolgreich werden. Ab dem 18. Juni können Markenrechtsinhaber ihre .online-Domain beauftragen. Danach findet vom 19. bis zum 26. August eine Landrush-Period statt, in der die gewünschte .online-Domain auch ohne Markenrechte, aber mit einem Aufpreis schon vor dem offiziellen Start registriert werden kann. Der offizielle Start (“Golive”) findet dann am 26. August 2015 statt.

Vormerkungen für alle Phasen können unter https://ntlds.variomedia.de vorgenommen werden. Unter https://ntlds.variomedia.de/domain/online finden Sie außerdem eine Übersicht über alle Preise und Termine zum Start von .online.

Neue Hosting-Pakete mit dedizierten Servern

Nachdem wir zum Jahreswechsel unsere neuen Easy.Hosting-Pakete eingeführt haben, gibt es nun auch neue Pro.Hosting-Pakete, die sich an Kunden mit besonders hohen Ansprüchen richten.

Unser Pro.A-Paket ersetzt das bisherige Premium-Upgrade. Das Paket beinhaltet 10 Inklusivdomains, 50 GB Webspace und 100 Postfächer mit jeweils 10 GB Speicherplatz und kostet 30,- Euro pro Monat. Das Paket wird auf einem Premium-Server gehostet, der von maximal 9 anderen Kunden genutzt wird. Mit PHP-FPM bieten wir allen Betreibern von Online-Shops und Content-Management-Systemen die maximale Performance.

Die Pro.B- und Pro.C-Pakete nutzen jeweils einen kompletten Server für sich allein. Sie kosten 45,- Euro pro Monat bzw. 75,- Euro pro Monat und beinhalten noch mehr Speicherplatz, Datenbanken und Postfächer. Die Nutzung eines dedizierten Servers mit bis zu 4 CPU-Kernen, 8 GB RAM und PHP-FPM stellt genug Reserven für sehr umfangreiche und gut besuchte Seiten zur Verfügung.

Ihren Auftrag zum Tarifwechsel in eines der neuen Pakete nehmen wir jederzeit formlos per E-Mail entgegen. Für den Umzug auf den jeweiligen Server benötigen wir eine Vorlaufzeit von 2 Tagen, damit der Wechsel ohne Unterbrechungen stattfinden kann. Eine Übersicht aller neuen Pro-Pakete finden Sie auf unserer Webseite.

Probleme bei der Einrichtung von E-Mail-Konten unter Thunderbird

Beim beliebten E-Mail-Client Thunderbird gibt es einen seit mehreren Jahren unbehobenen Bug bei der Erkennung der SMTP-Server-Einstellungen, der für Probleme bei der Einrichtung von E-Mail-Konten sorgt.

Das SMTP-Protokoll wird zum Versenden von E-Mails genutzt. Thunderbird nutzt für SMTP standardmäßig den TCP-Port 587, für den wir auf unseren SMTP-Servern (optional) Verschlüsselung mittels StartTLS anbieten. Bei der automatischen Erkennung der Server-Einstellungen versucht Thunderbird zunächst eine verschlüsselte Verbindung mittels StartTLS aufzubauen. Wenn dies fehlschlägt, wird eine unverschlüsselte Verbindung genutzt.

Leider hält sich Thunderbird bei der Erkennung der SMTP-Server-Einstellungen nicht genau an das SMTP-Protokoll, so dass unser Mail-Server beim Verbindungsaufbau mittels StartTLS eine Fehlermeldung zurückliefert, und Thunderbird dann automatisch eine unverschlüsselte Verbindung wählt:

smtp_500

In aktuellen Thunderbird-Versionen wird dann im nächsten Schritt eine Warnung angezeigt, dass keine Verschlüsselung genutzt wird, obwohl unsere Server sehr wohl Verschlüsselung unterstützen:

tb-fehler-500

Wählen Sie in diesem Fall für den SMTP-Server entweder unter Port 465 und unter SSL SSL/TLS und klicken dann auf “Erneut testen”, dann sollte die automatische Erkennung sofort funktionieren und Sie können “Fertig” auswählen.

Alternativ können Sie unter Port 587 und unter SSL StartTLS wählen und dann “Erneut testen” klicken. Meistens schlägt der Verbindungstest dann jedoch erneut fehl, und Thunderbird meldet einen Fehler. In diesem Fall sollten sie so lange auf “Erneut testen” klicken, bis es irgendwann klappt. Dies erfordert normalerweise mehrere Versuche, doch irgendwann funktioniert es und Sie können “Fertig” auswählen.

TLS-Sicherheitsproblem “Logjam”

Vor einigen Tagen wurde unter dem Namen Logjam ein mögliches Sicherheitsproblem mit der TLS-Verschlüsselung bekannt, die zur Verschlüsselung von Webseiten (HTTPS) und E-Mails (POP3, IMAP, SMTP) genutzt wird. Ein Angreifer kann unter bestimmten Umständen den DiffieHellman-Schlüsselaustausch zwischen Client und Server so manipulieren, dass nur schwache 512 Bit Parameter genutzt werden, die nach aktuellem Stand nicht mehr als sicher gelten. Dieser Angriff ist auf unseren Servern jedoch nicht möglich, da wir keine so kurzen Diffie-Hellman-Paramter unterstützen.

Wir haben uns im Rahmen des Logjam-Sicherheitsproblems dazu entschieden, wenn möglich nur noch als extrem sichere geltende 4096 Bit Diffie-Hellman-Parameter zu nutzen. Die meisten unserer Server nutzten bereits vor Bekanntwerden dieses Sicherheitsproblems 4096 Bit Parameter, auf einigen Servern wurden jedoch noch kürzere 1024 Bit Parameter genutzt, die von machen Sicherheitsexperten als bereits problematisch kurz eingestuft werden. Seit dem 22.05. nutzen alle Server (bis auf eine Ausnahme) 4096 Bit Parameter, dadurch kann es jetzt jedoch bei einigen veralteten Programmen zu Verbindungsproblemen kommen.

Einzige Ausnahme bilden die Mail-Server, wir mussten bei POP3 und IMAP aufgrund von Problemen mit älteren Mail-Clients wieder auf 1024 Bit Diffie-Hellman-Parameter zurückwechseln. Aktuelle Mail-Clients nutzten jedoch im Regelfall ohnehin das modernere Elliptic-Curve-Diffie-Hellman, das mit kürzeren Parametern und weniger Rechenleistung auskommt.

Die technischen Hintergründe

Die TLS-Verschlüsselung nutzt eine Kombination aus asymmetrischer Verschlüsselung zum Schlüsselaustausch und symmetrischer Verschlüsselung zur eigentlichen Verschlüsselung der Daten. Mittels asymmetrischer Verschlüsselung wird ein zufälliger geheimer Schlüssel vom Client an den Server übertragen, der nur vom Server wieder entschlüsselt werden kann. Da die asymmetrische Verschlüsselung sehr aufwändige kryptographische Algorithmen nutzt, kann sie aus Performance-Gründen nicht zur eigentlichen Verschlüsselung der Daten eingesetzt werden, hierfür werden wesentliche effizientere symmetrische Verschlüsselungsalgorithmen genutzt.

Der TLS-Standard sieht mehrere Verfahren zum Schlüsselaustausch und zur Verschlüsselung vor, einige davon sind jedoch mittlerweile veraltet und gelten als unsicher. Unsere Server sind daher so konfiguriert, dass nur nach aktuellem Stand sichere Verfahren genutzt werden können.

Die gegenwärtig sichersten Verfahren zum Schlüsselaustausch sind Diffie-Hellman (DHE) sowie Elliptic-Curve-DiffieHellman (ECDHE). Bei beiden Verfahren wird zwischen Client und Server für jede Verbindung ein individueller Schlüssel generiert (Perfect Forward Secrecy). Weiterhin wird für ältere Clients noch das RSA-Verfahren unterstützt, bei dem der Schlüsselaustausch mit dem RSA-Schlüssel aus dem X.509-Zertifikat des Servers gesichert wird. Dieses Verfahren hat jedoch den Nachteil, dass ein Angreifer mit Kenntnis des geheimen Server-Schlüssels alle Verbindungen entschlüsseln kann. ECDHE und DHE werden daher bevorzugt, RSA wird nur genutzt, wenn ein Client kein Diffie-Hellman unterstützt.

Bei DHE und ECDHE sendet der Server bestimmte Parameter an den Client, die in einem komplexen Algorithmus zur Berechnung der Verschlüsselung genutzt werden. Die Länge dieser Parameter entscheidet über die Sicherheit der Verschlüsselung. Bei DHE ist die minimal zulässige Länge 512 Bit, dies gilt jedoch seit längerer Zeit als nicht mehr als ausreichend sicher. Auch 1024 Bit Parameter gelten mittlerweile als problematisch, es werden mindestens 2048 Bit empfohlen.

Schwere Sicherheitslücke im Web-Shop Magento

Am 9. Februar 2015 wurde relativ stillschweigend ein Patch für die bekannte Web-Shop-Software Magento veröffentlicht, der mehrere schwere Sicherheitslücken in fast allen aktuellen und auch älteren Magento-Versionen schließt. Betroffen ist sowohl die Community Edition als auch die Enterprise Edition. Über diese Sicherheitslücken lassen sich SQL-Befehle sowie PHP-Code einschleusen, dadurch könnten Angreifer beispielsweise zusätzliche Adminstrator-Benutzer erstellen, auf Kreditkartennummern von Kunden zugreifen oder Spam-Scripte installieren.

Die Details zu der Sicherheitslücke wurden mehrere Monate geheimgehalten, um Magento-Benutzern genügend Zeit zum Einspielen des Patches zu geben. Am 23. April wurden nun sämtliche Details zur dieser Sicherheitslücke veröffentlicht; bereits wenige Stunden nach Veröffentlichung finden sich Hinweise auf die ersten Angriffe in unseren Webserver-Logs. Wir haben die Angreifer mittlerweile so gut es geht per Webserver-Firewall ausgesperrt, einige ungepatchte Magento-Installationen sind jedoch bereits gehackt wurden. Offenbar haben die Angreifer zusätzliche Administrator-Benutzer angelegt, die unbedingt wieder gelöscht werden müssen. Wir werden betroffene Kunden in Kürze informieren. Wenn eine Installation bereits manipuliert wurde, sollten sicherheitshalber alle Passwörter (Administrator-Accounts, MySQL, FTP) geändert werden.

Bitte beachten Sie, dass durch unsere Webserver-Firewall Tests auf diese Sicherheitslücke (z.B. shoplift.byte.nl) falsche Ergebnisse liefern.

Falls Sie bei uns einen Magento-Shop betreiben, sollten Sie unbedingt den von Magento bereitgestellten Patch SUPEE-5344 installieren. Die Installation ist leider etwas kompliziert, da die Patches als Shell-Script für die jeweilige Magento-Version bereitgestellt werden, dass Sie per (S)FTP in das Wurzelverzeichnis Ihrer Magento-Installation kopieren und dort per SSH oder über ein PHP-Script ausführen müssen:

  • Patch per SSH einspielen
    Kopieren Sie die Patch-Datei per (S)FTP in das Magento-Installationsverzeichnis. Loggen Sie sich dann per SSH auf Ihrem Webserver ein. Falls Sie Magento in einem Unterverzeichnis installiert haben (z.B. magento), wechseln Sie zuerst in dieses Verzeichnis:
    cd magento
    Anschließend führen Sie folgenden Befehl aus:
    bash PATCH_SUPEE-5344_CE_1.8.0.0_v1-2015-02-10-08-10-38.sh
    Ersetzen Sie dabei PATCH_SUPEE-5344_CE_1.8.0.0_v1-2015-02-10-08-10-38.sh durch den Namen der Patch-Datei für Ihre Magento-Version.
  • Patch per PHP-Script einspielen
    Erzeugen Sie eine Text-Datei patch.php mit folgendem Inhalt:
    <?php
    passthru("/bin/bash PATCH_SUPEE-5344_CE_1.8.0.0_v1-2015-02-10-08-10-38.sh");
    ?>

    Ersetzen Sie dabei PATCH_SUPEE-5344_CE_1.8.0.0_v1-2015-02-10-08-10-38.sh durch den Namen der Patch-Datei für Ihre Magento-Version. Kopieren Sie die PHP-Datei und die Patch-Datei per (S)FTP in das Magento-Installationsverzeichnis auf den Webserver. Anschließend rufen Sie die PHP-Datei über Ihren Web-Browser unter der URL Ihres Webshops auf (z.B. “www.meinshop.de/patch.php”). Die beiden hochgeladenen Dateien sollten danach wieder gelöscht werden.

Falls der Patch erfolgreich war erscheint folgende Ausgabe:

Checking if patch can be applied/reverted successfully…
Patch was applied/reverted successfully.

Anschließend sollten Sie den Cache in Magento zurücksetzen (System -> Cache Management). Bitte prüfen Sie auch, ob der im August 2014 bereitgestellten Patch SUPEE-1533 installiert wurde, der eine ähnliche Sicherheitslücke schließt.

Bitte beachten Sie, dass auch die gegenwärtig aktuellste Magento-Version 1.9.1.0 von dieser Sicherheitslücke betroffen ist und gepatcht werden muss.