Federlesen #14: Mehr Sicherheit bei und mit Apache-Produkten
Da Open-Source-Software der Apache Software Foundation bei Entwicklern und Administratoren beliebt ist, stellt sich die Frage, wie sicher diese Produkte sind und welche Möglichkeiten es gibt, ihr Sicherheitsniveau zu erhöhen.
- Frank Pientka
Nicht erst durch PRISM und XKeyscore hat das Thema Sicherheit eine große Aufmerksamkeit in der Öffentlichkeit erlangt. Da Open-Source-Software der Apache Software Foundation bei Entwicklern und Administratoren beliebt ist, stellt sich die Frage, wie sicher diese Produkte sind und welche Möglichkeiten es gibt, ihr Sicherheitsniveau zu erhöhen.
Die oft diskutierte Frage, ob Open-Source-Software sicherer als kommerzielle Software ist, lässt sich nur schwer beantworten, da das Thema Websicherheit viele Aspekte hat. Hier spielt nicht nur die Zahl oder die Kritikalität der gemeldeten Sicherheitslücken eine Rolle, sondern auch der Umgang damit. Neben den Herstellern sind genauso die Nutzer der Software in der Pflicht, sich frühzeitig und regelmäßig mit Sicherheit zu beschäftigen. Einen automatisierten Sicherheitsdienst gibt es bei Apache nicht, hier ist es nötig, selbst die vorhandenen Informationen gezielt zu nutzen.
Eine gute Einstiegsstelle ist die Common Vulnerabilities and Exposures List (CVE), die seit 1999 die MITRA Corporation MITRE kostenlos zur Verfügung stellt. Um Mehrfachnennungen gleicher Schwachstellen zu vermeiden, werden gemeldete Fehler mit einem eindeutigen Bezeichner (CVE-YYYY-NNNN) und einer Risikoeinschätzung pro Meldejahr zentral erfasst und kategorisiert. Da die Sicherheitslücken allein durch die große Vielzahl der Produkte zugenommen haben, kann die vierstellige fortlaufende Nummer ab Anfang des nächsten Jahres bei Bedarf auch länger sein. Wie bisher erhalten nur die Nummern 1 bis 999 führende Nullen, um vierstellig zu sein.
Apache hält derzeit den Platz 13 der Top-50-CVE-Listen mit 470 gemeldeten Fehlern in 80 Produkten, was durchschnittlich sechs Fehler pro Produkt bedeutet. Bei den häufigsten Sicherheitsfehlern, die sich auch in anderen Listen wie der von OWASP wiederfinden, handelt es sich um DoS-Attacken (Denial Of Services), Cross-Site Scripting (XSS) und Bypass-Operationen.
(Bild: OWASP (http://heise.de/-1887487.html))
Möchte man nach bekannten Sicherheitslücken in Apache-Produkten suchen, wird man in dem Bugtracker oder den Change-Protokollen der Produkte fündig. Etwas komfortabler geht es für alle Apache-Produkte über folgende Abfrage in der CVE-Datenbank, die sich dann noch gezielt verfeinern lässt. Alternativ, wenn auch nicht ganz aktuell, kann man in der National Vulnerability Database (NVD) des NIST-Instituts suchen.
Allgemeine Informationen zum Thema Sicherheit bei der Apache Software Foundation finden sich unter http://www.apache.org/security/, für das ein eigenes Sicherheits-Team mit der E-Mail-Adresse security@apache.org projektübergreifend zuständig ist. Einige Apache-Produkte betreiben eine eigene Seite, die die behobenen CVE-Schwachstellen auflistet, und eigene Mailinglisten, wie security@tomcat.apache.org, oder deren Archiv unter. Für den Apache-HTTP-Server, Tomcat oder Struts-Webframework gibt es Sicherheitsberichte für jede unterstützte Version.
Da Vorbeugen besser als Heilen ist, helfen auch spezielle Hinweisseiten, wie
- http://wiki.apache.org/tomcatq/FAQ/Security
- http://tomcat.apache.org/tomcat-8.0-doc/security-howto.html
- http://httpd.apache.org/docs/trunk/misc/security_tips.html
weiter, potenzielle Sicherheitslücken bereits bei der Konfiguration zu vermeiden. Den letzten Einbruch und Diebstahl der Nutzerdaten hätten die Betreiber des Apple-Entwicklerportals vermeiden können, wenn sie die ausgenutzte Schwachstelle CVE-2013-2251, die mit Struts 2.3.15 bereits behoben war, rechtzeitig aktualisiert hätten.
Türsteher und Filter
Um nicht jedem Zutritt zu gewähren, hat es sich bei Webanwendungen bewährt, einen Proxy zu verwenden. Beliebt ist dabei das Reverse Proxy Module des Apache-HTTP-Servers. Statt eines HTTP-Servers lässt sich auch der Apache Traffic Server als Cache-Proxy oder das Firewall-Modul mod_security einsetzen, um den direkten Zugriff auf die nachgelagerten Systeme zu erschweren.
Mit einem zwischengeschalteten Filter lassen sich CSRF-Angriffe (Cross-Site Request Forgery) verhindern. Für Tomcat 6 und 7 ist der Token-basierte CsrfPreventionFilter bereits für die Verwaltungsanwendungen Manager und Host aktiviert oder kann auch in den eigenen Webanwendungen einfach in der Datei WEB-INF\web.xml aktiviert werden. Für den Apache-Server gibt es ein noch recht neues, unter der LGPLv2 stehendes Modul mod_csrf zum Verhindern von CSRF-Angriffen.
