Kategorie: Technik

Veröffentlicht am

Probleme beim E-Mail-Versand mit Speedport-Routern der Deutschen Telekom

Bei den aktuellen Speedport-Routern (Modell “W 724V”) der Deutschen Telekom kommt es zu Problemen mit dem Mailversand über den Variomedia SMTP-Server, da die Telekom dort standardmäßig alle SMTP-Server bis auf die eigenen und die weniger anderer großer Anbieter gesperrt hat. Betroffen sind insbesondere Telekom-Kunden, die im Rahmen der Umstellung auf den IP-basierten Anschluss einen neuen Router erhalten haben.

Um wieder E-Mails über unseren SMTP-Server versenden zu können, müssen Sie diese Sperre entweder entweder ganz deaktiveren, oder den Variomedia SMTP-Server manuell freischalten. Loggen Sie sich dazu im Web-Interface des Routers (URL: “speedport.ip”) ein und wählen Sie oben das Menü “Internet”. Dann finden Sie links ein Menü “Liste der sicheren E-Mail-Server”, dort wählen Sie entweder die Option “Liste der sicheren E-Mail-Server verwenden” ab, oder Sie fügen den Variomedia SMTP-Server “smtp.variomedia.de” (bzw. “smtp.securehost.de”) zur Liste hinzu.

Nachtrag
Mit der Aktualisierung vom 10.03. hat die Telekom unsere SMTP-Server zu dieser Liste hinzugefügt, damit sollte das Problem behoben sein.

Veröffentlicht am

Apache-Modul “mod_speling” verfügbar

Auf unseren Linux-basierten Webservern wird (im Gegensatz zu normalen Windows-PCs) zwischen Groß- und Kleinschreibung bei Datei- und Verzeichnisnamen unterschieden, wenn Sie z.B. in Ihrem Webspace-Verzeichnis eine Datei “index.php” ablegen, und diese im Web-Browser als “INDEX.PHP” aufrufen, so wird der Aufruf fehlschlagen. Beim Domainnamen hingegen wird nicht zwischen Groß- und Kleinschreibung unterschieden, so macht es z.B. keinen Unterschied, ob Sie “variomedia.de” oder “VARIOMEDIA.DE” in Ihrem Browser aufrufen.
Manchmal ist es auch wünschenswert, dass kleine Tippfehler bei URLs automatisch korrigiert werden. z.B. wenn im Browser statt “.html” als Dateiendung “.htm” eingegeben wird.

Mit dem Apache-Modul mod_speling können diese Fehler in URLs automatisch korrigiert werden, der Webserver leitet dann auf die korrekte URL weiter. Falls es zu einer ungültigen URL mehrere möglicherweise passende Dateien auf dem Server gibt, wird eine Auswahl dieser Dateien angezeigt.

Das Modul wurde gestern auf allen Webservern installiert, ist jedoch aus Sicherheits- und Performancegründen standardmäßig deaktiviert. Um es zu aktivieren, muss eine .htaccess-Datei mit der Option “CheckSpelling on” im gewünschten Webspace-Verzeichnis erstellt werden. Sie können dabei wählen, ob ausschließlich Groß-/Kleinschreibung oder zusätzlich auch (maximal 1) Tippfehler automatisch korrigiert werden sollen:

Tippfehler und Groß-/Kleinschreibung korrigieren
<IfModule mod_speling.c>
  CheckSpelling on
</IfModule>

Nur Groß-/Kleinschreibung korrigieren
<IfModule mod_speling.c>
  CheckSpelling on
  CheckCaseOnly on
</IfModule>

Wie bei .htaccess-Dateien üblich gilt diese Einstellung dann auch für alle Unterverzeichnisse.

Veröffentlicht am

Aktuelle Änderungen an der Webserver-Konfiguration

Gegenwärtig wechseln wir die Server-Plattform bestehender älterer Webserver auf unsere aktuelle Softwareumumgebung, die wir seit Januar 2014 für neue Benutzeraccounts einsetzen. Dabei aktualisieren wir auch die verwendete Webserver-Software Apache von Version 2.2 auf 2.4, wodurch es vereinzelt zu Problemen aufgrund geänderter Konfigurationsdirektiven kommen kann.

Betroffen sind Benutzeraccounts, die vor dem Januar 2014 angelegt wurden.

Grundsätzlich sollten bestehende .htaccess-Konfigurationsdateien sowie HTML-Dateien mit “Server-Side-Includes” weiterhin funktionieren, in wenigen Ausnahmefällen kann es jedoch zu Problemen kommen. Eine ausführliche Dokumentation der mit Apache 2.4 möglichen Konfigurationsoptionen und SSI-Direktiven finden Sie hier.

Die Änderungen im Einzelnen:

  • Verzeichnisindex
    Auf den alten Webservern wurde für Verzeichnisse ohne Indexdatei (index.php, index.html usw.) standardmäßig eine Auflistung aller Dateien angezeigt, dieser Verzeichnisindex ist auf den neueren Webservern aus Sicherheitsgründen deaktiviert. Falls es keine gültige Index-Datei gibt, wird eine Fehlermeldung angezeigt. Diese Änderung wurde notwendig, da viele Kunden dieses Verhalten des Webservers nicht erwartet haben, und dadurch unter Umständen Dateien mit sensiblen Inhalten ungewollt  im Internet auffindbar waren. Um den Verzeichnisindex wieder zu aktivieren, legen Sie in in Ihrem Benutzerverzeichnis (bzw. dem gewünschten Unterverzeichnis) auf dem Webserver eine .htaccess-Datei mit der Option “Options +Indexes” an.
  • .htaccess-Dateien
    In .htaccess-Dateien ist unbedingt auf korrekte Groß- und Kleinschreibung bei den Konfigurationsdirektiven zu achten.
  • Server-Side-Includes
    Die Syntax für SSI-Expressions wurde in Apache 2.4 geändert, die alte Syntax lässt sich durch eine .htaccess-Datei mit der Option “SSILegacyExprParser on” wieder aktivieren.
  • Cronjobs
    Es ist in Einzelfällen vorgekommen, dass Cronjobs, die auf den bisherigen Servern liefen jetzt nicht mehr aktiv sind. Bitte fügen Sie diese wieder hinzu, sollte Ihr Benutzeraccount von dem Problem betroffen sein.
  • PHP
    Auf den neuen Webservern steht PHP 4 nicht mehr zur Verfügung, da es mittlerweile veraltet ist und sei Jahren nicht mehr mit Sicherheitsupdates versorgt wird. Verfügbar sind die PHP-Versionen 5.2, 5.3, 5.5 und 5.6. Die Standard-PHP-Version hat sich nicht geändert, für ältere Accounts ist dies weiterhin PHP 5.3. Sie können auch eine andere PHP-Version auswählen, Informationen dazu finden Sie hier. Bitte beachten Sie: Die Deaktivierung des ebenfalls veralteten PHP 5.2 ist für den 1.7.2015 geplant.
    Aus Sicherheitsgründen wurde weiterhin die PHP-Einstellung “allow_url_fopen” in allen PHP-Versionen standardmäßig deaktiviert. Sie können diese Einstellung über eine php.ini-Datei mit der Option “allow_url_fopen = on” wieder aktivieren.
  • SSH Host Keys
    Wir haben einige bestehende Webserver mit sehr vielen Präsenzen auf mehrere neue Server aufgeteilt, um die Leistung zu verbessern. Daher kommt es bei einigen Kunden-Accounts zu einer Warnung beim SSH- bzw. SFTP-Zugriff, dass sich der Host-Key geändert hat.
  • HTTP Status Codes
    Mit der neuen Apache-Version werden nur noch offizielle HTTP Status-Codes unterstützt. Die Verwendung inoffizieller Status-Codes wie 421 oder 509 in .htaccess-Direktiven führt jetzt zu einem Server-Fehler.
  • Server-Betriebssystem
    Durch den Wechsel der verwendeten Linux-Distribution von CentOS 5 auf Ubuntu 14.04 kann es für Kunden, die eigene Binärpakete nutzen, ebenfalls vereinzelt zu Problemen aufgrund aktuellerer Softwarepakete und Systembibliotheken kommen.
Veröffentlicht am

PHP 5.6 auf allen neuen Webservern

Ab sofort steht auf allen neuen Webservern PHP in der Version 5.6 zur Verfügung.  In unseren FAQ finden Sie eine Anleitung, wie sich PHP 5.6 für Ihren Benutzeraccount aktivieren lässt.

Kunden, die derzeit noch auf älteren Webservern liegen und PHP 5.6 daher noch nicht nutzen können, werden in den nächsten Wochen auf neuere Webserver umgezogen. Neu eingerichtete Benutzeraccounts werden ausschließlich auf neuen Webservern eingerichtet.

Veröffentlicht am

Ruhe in Frieden: SSL 3

SSL und TLS werden im Internet zum Verschlüsseln des Datenverkehrs zwischen Clients und Servern verwendet.  Es findet unter anderem Verwendung bei dem verbreiteten HTTPS-Protokoll, aber auch beispielsweise bei der Kommunikation zwischen E-Mail-Servern. Bei SSL handelt es sich ursprünglich um einen Standard von Netscape, während TLS seit 1999 der offizielle Nachfolger ist und von der IETF – dem Standardorgan des Internets – spezifiziert wird.

Da uns die Sicherheit der von unseren Kunden genutzten Dienste sehr am Herzen liegt, hatten unsere Server stets sehr ausgefeilte TLS-Konfigurationen, die maximale Sicherheit mit praktikabler Kompatibilität balancierten.  Deshalb war auch SSL in der Version 3 (die letzte Version vor TLS aus dem Jahr 1996!) aktiviert, da es keine handfesten Gründen dagegen gab.

Da sich nun jedoch die Gerüchte mehren (hier oder hier), dass Microsoft in dieser Woche kritische Probleme mit SSL 3 veröffentlichen will, nehmen wir es zum Anlass und deaktivieren es auf allen unseren Systemen.

Das bedeutet, dass ab sofort nur noch Verschlüsselung mit TLS 1.0 (aus dem Jahr 1999!) und neuer möglich ist.

In der Praxis bedeutet dies, dass Internet Explorer 6 unter Windows XP nicht mehr auf HTTPS-Seiten auf unseren Servern zugreifen kann.

Es ist jedoch weiterhin möglich unter Windows XP mit Internet Explorer 8, Firefox oder Chrome diese Seiten abzurufen. Wir denken daher nicht, dass ernsthafte Einschränkung bei der Nutzung unserer Webserver zu erwarten sind. Ebenfalls aktualisiert wurden die Konfigurationen unserer E-Mail-Server.

Update vom 15.10.2014: Mittlerweile wurde die Schwachstelle von Google (statt wie anfangs vermutet Microsoft) veröffentlicht: sie wurde POODLE getauft und ist ein naher Verwandter des älteren BEAST-Angriffs. Das bedeutet, es benötigt einen aktiven Angreifer und ist somit nicht mit Shellshock oder gar Heartbleed vergleichbar. Wir sehen uns in der Maßnahme, SSL 3 abzuschalten bestätigt. Es sind keine weiteren Maßnahmen notwendig.

Veröffentlicht am

Bash-Sicherheitslücke “ShellShock”

Am 24.09. wurde eine Sicherheitslücke in der auch auf unseren Webservern verwendeten Unix-Shell “Bash” bekannt, die es Angreifern per HTTP ermöglicht, über CGI-Scripte (PHP, Python, Perl) mit Shell-Aufrufen eigene Befehle auf dem Webserver auszuführen (CVE-2014-6271). Für diese Sicherheitslücke waren wenige Stunden nach Bekanntwerden Patches verfügbar, die wir selbstverständlich sofort auf allen Servern eingespielt haben.

In den folgenden Tagen wurden weitere Probleme in Bash bekannt, die jedoch weniger schwerwiegende Angriffsmöglichkeiten auf unseren Servern geboten haben (CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277 CVE-2014-6278). Auch für diese Sicherheitslücken haben wir kurz nach Bekanntwerden Patches installiert.

In den Webserver-Logs finden sich keine Hinweise, dass diese Sicherheitslücken in der Zeit zwischen Bekanntwerden bis zum Einspielen der Updates von Angreifern ausgenutzt wurden.

Veröffentlicht am

Mögliches Sicherheitsproblem auf den Webservern: FollowSymLinks

Wir haben aufgrund möglicher Sicherheitsprobleme auf den Webservern eine Änderung an der Server-Konfiguration vornehmen müssen. Die Konfigurationsdirektive “FollowSymLinks” kann ab sofort nicht mehr in .htaccess-Dateien benutzt werden. Falls Sie diese Option nutzen, wird für Ihre Webseite jetzt eine Fehlermeldung angezeigt.

Bitte entfernen Sie diese Option in allen .htaccess-Dateien, oder ersetzen sie durch “SymLinksIfOwnerMatch”. Wir nehmen diese Änderung im Laufe des Tages automatisch für alle bestehenden .htaccess-Dateien vor.

Update: Die Option “All” kann ebenso nicht mehr in .htaccess-Dateien benutzt werden, da sie  “FollowSymLinks” impliziert.

Veröffentlicht am

OpenSSL-Bug

Unter dem Namen “Heartbleed” ist in der Nacht von Montag zu Dienstag dieser Woche ein Fehler in der freien Software “OpenSSL” bekannt geworden, der sehr weitreichende Folgen für alle Internet-Nutzer hat. Heise Online schreibt dazu:

Die weit verbreitete Krypto-Bibliothek OpenSSL enthielt einen Programmierfehler, der es erlaubte, von betroffenen Systemen geheime Schlüssel, Passwörter und andere Daten auszulesen. Krypto-Guru Bruce Schneier stuft den Fehler als “Katastrophe” ein: “Auf einer Skala von 0 bis 10 ist das eine 11”.

Betroffen sind zahlreiche Dienste im Internet, die diese Software einsetzen – von Facebook, über Dropbox bis zu Yahoo und Google. Aktuelle Informationen und eine umfangreiche Erklärung des Fehlers finden Sie unter http://www.heise.de/thema/Heartbleed. Eine aktuelle Liste großer betroffener Dienste finden Sie hier.

Wie sind Variomedia-Kunden betroffen?

Es gibt zwei Ebenen, auf denen SSL und der Heartbleed-Bug bei uns eine Rolle spielen:

  • Kunden, die ein eigenes SSL-Zertifikat für die verschlüsselte Datenübertragung (z.B. für ihrem Online-Shop) nutzen sind bis auf sehr wenige Ausnahmen (<1%) nicht betroffen, da wir hier eine OpenSSL-Version einsetzen, die den Fehler nicht enthält.
  • Betroffen sind allerdings alle Nutzer unserer eigenen Dienste, wie des Webmails, des Kundenmenüs, DynDNS und aller weiteren Dienste, die unter variomedia.de und securehost.de angeboten werden.

Es gibt im Moment keine Hinweise darauf, dass der OpenSSL-Fehler ausgenutzt wurde und Daten unserer Kunden missbraucht wurden – eine endgültige Sicherheit gibt es diesbezüglich jedoch nicht. Wir haben wenige Minuten nach Bekanntwerden des Bugs ein Update auf allen Servern eingespielt, das den Fehler behebt. In den letzten Tagen wurden außerdem alle SSL-Zertifikate ausgetauscht, deren Schlüssel potentiell kompromittiert gewesen sein könnten.

Was ist zu tun?

Wir empfehlen dennoch allen Kunden, alle Passwörter zu ändern, d.h. insbesondere Passwörter für:

  • Kundenmenü
  • E-Mail-Postfächer

Nicht unmittelbar betroffen sind folgende Dienste, bei denen wir dennoch die Änderung von Passwörtern empfehlen:

  • FTP/SFTP/SSH
  • MySQL (Bitte beachten Sie, dass bei einer Änderung des MySQL-Passworts auch Änderungen in Ihren Scripten erforderlich sind.)
  • DynDNS (Bitte ändern Sie die Zugangsdaten auch in Ihren Routern/DynDNS-Scripten.)

Es ist eine gute Gelegenheit, wirklich sichere Passwörter zu vergeben. Hilfreiche Tipps dazu finden Sie auf den Seiten des BSI (Bundesamt für Sicherheit in der Informationstechnik).

Für Fragen stehen Ihnen wir Ihnen gerne zur Verfügung!

Veröffentlicht am

Sicherheitslücke in Joomla-Extension “eXtplorer”

Es gibt aktuell eine schwere Sicherheitslücke in der Joomla Dateimanager Extension “eXtplorer”, die es Angreifern ermöglicht, beliebige Dateien auf Webserver hochzuladen. Diese Sicherheitslücke wurde in den vergangenen Tagen bereits mehrfach ausgenutzt, um Spam über unsere Webserver zu versenden. Falls Sie diese Extension in einer älteren Version als 2.1.5 vom 19.12.2013 benutzen sollten Sie dringend auf die aktuelle Version updaten.

Bitte prüfen Sie auch stets, ob für Joomla selbst und alle installierten Plugins und Erweiterungen neue Versionen verfügbar sind.

Veröffentlicht am

Variomedia auf der RuPy 2013

RuPy 2013Vom 10.-13. Oktober zieht es unsere Entwickler nach Budapest, Ungarn, zur diesjährigen RuPy Conference. Neben vielen Fachvorträgen zu Python und JavaScript werden wir uns mit anderen Entwicklern über Projekte und Best-Practices austauschen.

Wir würden uns freuen Sie auf der Konferenz persönlich kennenzulernen, bei Interesse kontaktieren Sie uns doch einfach spontan per Twitter oder Facebook.