Kategorie: Technik

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.

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.

Dieser Artikel betrifft Sie nur, falls Sie Ihre Webseite per HTTPS betreiben.

Auf der aktuellen Black Hat-Konferenz wurde ein neuer Angriff gegen SSL/TLS vorgestellt, von dem unsere Kunden betroffen sein könnten: BREACH. Bei dem Angriff wird – vereinfacht gesagt – ein Zusammenspiel von HTTP-Komprimierung und SSL/TLS-Verschlüsselung ausgenutzt, um die Verschlüsselung auszuhebeln.

Der beste Schutz besteht darin, die HTTP-Komprimierung auszuschalten. Dies ist auch die Standardeinstellung auf unseren Servern. Sie kann jedoch per .htaccess manuell aktiviert werden und es ist nicht auszuschließen, dass dies bei Ihnen unbemerkt geschah, sofern Sie Drittsoftware installiert haben.

Test

Ob Ihre Webseite betroffen ist, können Sie leicht mit Hilfe des curl-Tools testen:

curl -I -H "Accept-Encoding: gzip" https://IHRE-WEBSEITE

Falls die Antwort kein Content-Encoding: gzip enthält, ist Ihre Webseite nicht betroffen.

Sollten Sie keinen Rechner zur Verfügung haben, auf dem curl installiert ist, können Sie sich auch einfach per SSH auf Ihrem Webserver anmelden und die Befehlszeile dort ausführen.

Schutz

Als grobe Faustregel gilt: Falls Sie

1. eine Webseite mit HTTPS betreiben,
2. diese Seite dynamisch im weitesten Sinn ist (Benutzereingaben verarbeitet etc.)
3. und eine .htaccess-Datei mit einer Zeile ähnlich

   AddOutputFilterByType DEFLATE text/html text/plain text/xml application/javascript text/css

   existiert,

empfehlen wir Ihnen alle Typen zu entfernen, die möglicherweise dynamisch generiert werden. In der Regel ist das text/html.

Im Zweifelsfall konsultieren Sie Sicherheitsspezialisten oder entfernen Sie die Zeile komplett. Bitte haben Sie Verständnis, dass wir über diese allgemeinen Hinweise hinaus keine individuelle Sicherheitsberatung durchführen können.

Gestern gegen 14:40 Uhr gab es einen schweren UDP DDoS Angriff auf einen unserer Webserver (ws4). Dadurch kam es zu einer Überlastung der Internet-Uplinks in einem unserer Rechenzentren, die zu kurzzeitigen Störungen in der Erreichbarkeit vieler unserer Server und Dienste geführt hat. Der Angriff war so massiv, dass sogar die leistungsfähigen 10 GBit/s Internet-Uplinks des Rechenzentrums überlastet wurden.

Um diese Störung zu beheben mussten wir daher die primäre Webserver-IP (81.28.232.69) des angegriffenen Servers auf Ebene der Carrier-Backbones des Rechenzentrums sperren lassen. Dadurch waren sämtliche Domains, die auf diese IP verweisen, für mehrere Stunden nicht mehr erreichbar. Wir hatten leider keine andere Möglichkeit, als den betroffenen Server auf diese Weise komplett zu sperren, da dieser Angriff zu Netzwerküberlastungen im gesamten Rechenzentrum geführt hat. Die Sperrung wurde gegen 23:20 Uhr aufgehoben, als der Angriff vorüber war. Es kann bei einigen Internet Service Providern noch zu Problemen mit der Erreichbarkeit dieses Webservers kommen, die im Laufe dieses Tages behoben sein sollten.

Bei Störungen oder Wartungsarbeiten informieren wir Sie wie immer über unseren Twitter-Feed (auch als RSS abonnierbar), um auch unabhängig von Störungen im Rechenzentrum unsere Kunden zu erreichen.

Für die entstandenen Unannehmlichkeiten bitten wir vielmals um Entschuldigung!