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.

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();?>