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.

Erpresser drohen Webseiten mit DDoS-Angriffen

Seit einigen Tagen versenden Erpresser massenhaft E-Mails an Webseiten-Betreiber, in denen mit einem massiven DDoS-Angriff gedroht wird, falls diese nicht 3 Bitcoins (etwa 1200€) zahlen. Auch einige unserer Kunden haben eine solche Drohung erhalten. Es gibt bisher jedoch keine Hinweise auf tatsächlich erfolgte DDoS-Angriffe, wir halten diese Drohung daher für einen Bluff. Sie sollten nicht zahlen.

Die E-Mail lautet wie folgt:

Betreff: DDOS ATTACK !
Von: RedDoor <Reddoor@openmailbox.org>

Hello,

You are going under DDoS attack unless you pay 3 Bitcoin.
Pay to **********************************
       
Please note that it will not be easy to mitigate our attack, because our current UDP flood power is 400-500 Gbps.

Don't worry, it will not be hard (we will try not to crash it at this moment) and will stop in 10 minutes. It's just to prove that we are serious.We
are aware that you probably don't have 3 BTC at the moment, so we are giving you 24 hours to get it and pay us.
Find the best exchanger for you on howtobuybitcoins.info or localbitcoins.com You can pay directly through exchanger to our BTC address,
you don't even need to have BTC wallet. Current price of 1 BTC is about 415 USD, so we are cheap, at the moment. But if you ignore us,
price will increase.
IMPORTANT: You don't even have to reply. Just pay 3 BTC to **********************************
- we will know it's you and you will never hear from us again. We say it because for big companies it's usually the problem as they don't
want that there is proof that they cooperated.
If you need to contact us, feel free to use some free email service.
But if you ignore us, and don't pay within 24 hours, long term attack will start, price to stop will go to 10 BTC and will keep increasing for
every hour of attack.
Many of our "clients" believe that if they pay us once, we will be back.
That's not how we work - we never attack the same target after we are paid.
If you are thinking about reporting this to authorities, feel free to try. But it won't help. We are not amateurs.
REMEMBER THIS: It's a one-time payment. Pay and you will not hear from us ever again!
We do bad things, but we keep our word.
Thank you.

Probleme beim POP3-Abruf in Outlook 2016

In der beliebten E-Mail-Software Outlook 2016 gibt es ein Problem beim Abruf von E-Mails per POP3, das zu gelöschten oder doppelt angezeigten E-Mails führen kann. Dieser Fehler tritt nur auf, wenn die Option “Kopie aller Nachrichten auf dem Server belassen” gewählt ist. Microsoft hat nun ein Update bereitgestellt, dass diesen Fehler behebt. Dieses Update kann über die automatische Updatefunktion von Outlook (bzw. Office 365) installiert werden.

Absenderverifizierung auf unseren Mail-Servern

Das Versenden von E-Mails mit einer ungültigen Absenderadresse (Envelope Sender) ist nicht zulässig und führt bei vielen Mail-Servern zu einer sofortigen Ablehnung. In diesem Fall besteht der begründete Verdacht, dass es sich um unerwünschte E-Mails (SPAM) handelt. Manchmal handelt es sich jedoch auch um legitime E-Mails, die versehentlich mit ungültigen Absenderadressen gesendet werden. Unsere Mail-Server haben bisher keine genauere Prüfung der Absenderadresse vorgenommen, wir haben uns nun jedoch dazu entschieden, ungültige Absenderadressen als zusätzliches Kriterium für unser bestehendes Greylisting zu nutzen, um weitere bisher nicht als SPAM erkannte E-Mails abzuweisen:

E-Mails mit einer Absenderadresse von einer nicht existierenden Domain oder einer Domain ohne gültigen A- bzw. MX-Eintrag führen jetzt ebenfalls zum Greylisting. Bei Absenderadressen, die auf unsere Mail-Server verweisen, wird zusätzlich geprüft, ob dieses Postfach auf unseren Mail-Servern existiert (bzw. ob es ein passendes Catch-All-Postfach gibt).

Durch das Greylisting werden diese E-Mails nicht abgelehnt, sondern erst nach einem zweiten Zustellversuch mit einer Verzögerung von mindestens 5 Minuten angenommen, es können also keine legitimen E-Mails verloren gehen.

MariaDB 10.1 verfügbar

Ab sofort können Sie im Kundenmenü für neue Datenbanken auch MariaDB in der aktuellen Version 10.1 nutzen. MariaDB ist eine Abspaltung von MySQL, die nach der Übernahme von MySQL durch Oracle von einigen früheren Entwicklern aus Unzufriedenheit mit dem neuen Eigentümer initiiert wurde. MariaDB nutzt die gleichen Schnittstellen und SQL-Befehle wie MySQL, die Version 10.1 ist weitgehend kompatibel zu MySQL Version 5.7. In den meisten Anwendungen (z.B. WordPress, Joomla, OwnCloud) können Sie einfach statt einer MySQL-Datenbank MariaDB nutzen (falls die Anwendung MariaDB nicht als eigenen Datenbank-Typ unterstützt, wählen Sie als Datenbank-Typ einfach MySQL).

MySQL 5.7 als Standard

Weiterhin haben wir die Standard-MySQL-Version für neue Datenbanken von MySQL Version 5.6 auf Version 5.7 umgestellt. Wenn Sie eine neue Datenbank anlegen, und keine andere MySQL-Version auswählen, wird standardmäßig Version 5.7 genutzt.

Mögliche Probleme mit MySQL 5.7

Seit MySQL Version 5.6 sind standardmäßig die Optionen STRICT_TRANS_TABLES und NO_ENGINE_SUBSTITUTION gesetzt, die Option STRICT_TRANS_TABLES  kann allerdings bei älteren Anwendungen manchmal zu Problemen führen. Alternativ können Sie auch weiterhin MySQL Version 5.5 oder das neue MariaDB nutzen, oder Sie deaktivieren diese Option für eine MySQL-Session über folgenden Befehl:

SET SESSION sql_mode = "NO_ENGINE_SUBSTITUTION";

Schwere Sicherheitslücke in allen Joomla-Versionen

Am 14. Dezember wurde eine schwere Sicherheitslücke in allen Versionen des beliebten Content-Management-Systems Joomla bekanntgegeben, die es Angreifern ermöglicht, beliebigen PHP-Code auszuführen. Diese Sicherheitslücke wurde bereits 2 Tage zuvor ausgenutzt, um über automatisierte Scripte massenhaft Joomla-Installationen mit Schadcode zu infizieren.

Wir haben nach Veröffentlichung der Details am Abend des 14. Dezember unsere Webserver-Firewall angepasst, um die uns bekannten automatisieren Angriffe zu unterbinden, doch einen Schutz vor neuartigen Angriffen auf diese Sicherheitslücke gibt es nicht. Sofern Sie eine Joomla-Installation auf unseren Webservern nutzen, sollten Sie daher unverzüglich die bereitgestellten Updates installieren.

Joomla Version 3.x lässt sich über den integrierten Updater auf die neue Version 3.4.6 aktualisieren. Für die älteren Versionen 1.5 und 2.5 stehen Updates für die betroffene Datei “libraries/joomla/session/session.php” bereit, die manuell per (S)FTP bzw. SSH installiert werden müssen.

Update

Die Sicherheitslücke lässt sich nur in Zusammenhang mit einem Bug in älteren PHP-Versionen ausnutzen. Betroffen ist bei uns nur PHP 5.3, für das es seit längerer Zeit keine Sicherheitsupdates mehr gibt. Die für Ihre Webseite benutzte PHP-Version können Sie über eine PHP-Datei mit folgender Zeile ermitteln:
<?php phpinfo();?>

PHP 7.0 verfügbar

Seit heute steht auf unseren Webservern die neue Version 7.0 von PHP zur Verfügung. Der Versionssprung von 5.6 auf 7 liegt daran, dass die Entwicklung von PHP 6 aus verschiedenen Gründen eingestellt wurde.

Vorteile von PHP 7

Die Hauptverbesserungen bei PHP 7 wurden an den internen Datenstrukturen vorgenommen, dort konnte der Speicherbedarf stark reduziert werden. Dies führt zu einer deutlichen Erhöhung der Ausführungsgeschwindigkeit von PHP-Scripten, in der Praxis laufen viele Anwendungen wie z.B. WordPress unter PHP 7.0 doppelt so schnell wie unter PHP 5.6, der Umstieg auf PHP 7 lohnt sich also.

Mögliche Probleme beim Wechsel auf PHP 7

Bei PHP 7 wurden einige bisher nur als veraltet markierte Extensions endgültig entfernt, darunter auch die häufig eingesetzte originale MySQL-Extension. Als Alternativen können die MySQL-Improved-Extension (MySQLi) oder PDO genutzt werden.

Weiterhin sind einige Begriffe wie int, float, bool, string, true, false und null nun reserviert und dürfen nicht mehr für Klassennamen oder Ähnliches genutzt werden, dies führt bei einigen PHP-Anwendungen wie beispielsweise Joomla zu Problemen.

Eine vollständige Übersicht der nicht abwärtskompatiblen Änderungen finden Sie hier.

Aufgrund dieser Änderungen sind viele bekannte PHP-Anwendungen nicht kompatibel mit PHP 7. Für die meisten betroffenen Anwendungen sollten jedoch in Kürze Updates erscheinen, die diese Probleme beheben. Die bei uns am häufigsten genutzte PHP-Anwendung WordPress ist in der aktuellen Version vollständig kompatibel mit PHP 7, es kann jedoch unter Umständen Probleme mit älteren WordPress-Plugins geben.

PHP 7 aktivieren

PHP 7 wird nicht automatisch für alle PHP-Scripte auf unseren Webservern genutzt, da bei einer Änderung der Standard-PHP-Version viele Webseiten nicht mehr korrekt funktionieren würden. Sie können jedoch die gewünschte PHP-Version für Ihre Webseiten über eine Konfigurationsdatei vorgeben, eine Anleitung dazu finden Sie hier.

Let’s Encrypt Zertifikate bei Variomedia

Ab dem 3. Dezember wird die Zertifizierungsstelle Let’s Encrypt kostenlose SSL-Zertifikate für Webserver ausstellen, die von sämtlichen Web-Browsern akzeptiert werden. Wir erhalten derzeit viele Anfragen von Kunden, ob wir diese ebenfalls unterstützen werden. Grundsätzlich planen wir, Let’s Encrypt Zertifikate anzubieten. Es gibt allerdings noch einige bisher ungelöste technische Probleme bei der Domain-Validierung durch Let’s Encrypt, so dass wir derzeit noch nicht genauer sagen können, wann und in welcher Form wir diese Zertifikate anbieten können.

Um ein SSL-Zertifikat zu erhalten, muss zuvor bei der Zertifizierungsstelle der Besitz der Domain nachgewiesen werden. Let’s Ecrypt nutzt hierzu einen Mechanismus, der eine Datei mit einem verschlüsselten Token per HTTP von der gewünschten Domain herunterlädt, die nur vom Inhaber der Domain angelegt werden kann. Alternativ kann auch eine Validierung mittels spezieller DNS-Einträge erfolgen, dieses Verfahren wird jedoch zum Start von Let’s Encrypt am 3. Dezember noch nicht unterstützt, sondern erst später nachgereicht.

Um den gesamten Vorgang zu automatisieren stellt Let’s Encypt eine eigene Software bereit, die jedoch auf unseren Webservern nicht funktioniert. Wir müssen daher das von Let’s Encrypt genutzte ACME-Protokoll selbst implementieren. Weiterhin gelten die Let’s Encrypt-Zertifikate nur 90 Tage, so dass wir auch eine automatische Verlängerung implementieren müssen. Eine automatisierte Validierung ist in unserem Webserver-Verwaltungssystem praktisch nur mittels DNS-Validierung umsetzbar, daher müssen wir noch warten, bis dies von Let’s Encrypt unterstützt wird.

Bitte beachten Sie, dass es bei uns grundsätzlich nicht möglich ist, selbst erstellte oder von regulären Zertifizierungsstellen direkt erworbene SSL-Zertifikate einzubinden, da wir ein automatisiertes System zur Verwaltung von SSL-Zerfikaten nutzen, das nicht mit Zertifikaten anderer Anbieter funktioniert.

Phusion Passenger für Ruby, Python und Node.js

Wir erhalten regelmäßig Anfragen, ob wir auch Hosting für Ruby on Rails, Python WSGI oder Node.js anbieten können. Daher planen wir, in unseren Pro-Paketen und auf Dedicated-Servern zukünftig auch Ruby Rack (z.B. Ruby on Rails, Sinatra), Python WSGI (z.B. Django, Flask, Pyramid) und Node.js mittels Phusion Passenger (als Apache-Modul) zu unterstützen. Passenger, auch als mod_rails bekannt, ist der Standard-Application-Server für Ruby on Rails, unterstützt jedoch auch andere Sprachen wie Python (WSGI) und Node.js.

Um eine Web-Anwendung mittels Passenger zu nutzen, muss sich diese an die typische Rack-Verzeichnisstuktur halten. Python- und Node.js-Anwendungen lassen sich sehr einfach anpassen:

  • Im Hauptverzeichnis der Web-Anwendung muss ein Unterverzeichnis “public” für statische HTML-Dateien, Bilder und CGI-Scripte angelegt werden.
  • Der Webserver-Pfad für die gewünschten Domains sollte auf dieses Verzeichnis zeigen.
  • Im Hauptverzeichnis der Web-Anwendung muss Passenger per .htaccess-Datei aktiviert und ein Startup-Script angelegt werden, dass die Anwendung lädt (z.B. config.ru, passenger_wsgi.py, app.js).
  • Wenn im Public-Verzeichnis keine Indexdatei (index.html, index.php, usw.) hinterlegt ist, wird die Anfrage vom Webserver an Passenger weitergeleitet.
  • Passenger lädt beim ersten Seitenaufruf das Startup-Script der Anwendung und leitet dann alle Anfragen an diese weiter.

Für interessierte Kunden bieten wir ab sofort eine kostenlose Testphase unserer Pro-Pakete an, bitte wenden Sie sich dazu an unsere Kundenbetreuung.

Mögliche Probleme mit Apache 2.4.17 und mod_rewrite

Wir haben am 15.10. ein Update der Webserver-Software Apache von Version 2.4.16 auf 2.4.17 vorgenommen, dabei hat sich eine unerwartete Änderung im Modul mod_rewrite ergeben, die zu Problemen mit einigen PHP-Anwendungen (z.B. Concrete5) führen kann: Die Server-Variable “REDIRECT_URL” wurde von einer relativen URL (z.B. “/kapitel/2/”) auf eine vollständige URL (z.B. “http://www.domain.de/kapitel/2/”) umgestellt, daher könnten PHP-Scripte, die auf diese Variable zurückgreifen, unter Umständen nicht mehr korrekt funktionieren.

Falls Sie seit dem 15.10. Probleme mit Ihrer Webseite festgestellt haben, die zuvor nicht aufgetreten sind, wenden Sie sich bitte an unsere Kundenbetreuung.