IT Sicherheit beim Apache Webserver

Im ersten Teil der Artikelserie zum Thema IT Sicherheit sehen wir uns an, welche Möglichkeiten es gibt, die IT Sicherheit beim Apache Webserver zu erhöhen.

Zu diesem Artikel wurde ich von einem Freund angeregt, der mir vor einigen Wochen erzählt hat, wie unsicher der Apache Webserver doch sei und man diesen besser nicht einsetzen solle. Aufgrund der Tatsache, dass Apache der am häufigsten eingesetzte Webserver ist, erschien mir diese Aussage ein wenig undifferenziert und so habe ich mich mit dem Thema ein wenig näher auseinandergesetzt. Das Ergebnis meiner Recherchen werde ich nun in diesem Artikel wiedergeben.

Zunächst einige generelle Anmerkungen zum Thema IT Sicherheit: Im Fernsehen sieht es immer sehr leicht aus, ein Computersystem zu hacken. Die Protagonisten tippen wenige Befehle über die Tastatur ein und schon ist eine Firewall oder ein sonstwie geschütztes System geknackt. So einfach geht dies aber im wahren Leben nicht vonstatten. Um in einen Computer einzudringen, müssen zwei Voraussetzungen erfüllt sein: Der Hacker muß das System und die Sicherheitsmaßnahmen auf der einen Seite kennen und ihm müssen ferner bestehende Sicherheitslücken in dem entsprechenden System bekannt sein. Einfach auf gut Glück einige Befehle einzugeben und hoffen, dass sich der Computer dadurch beeindruckt fühlt und alle Viere von sich streckt, ist kein realistisches Szenario.

Nachdem der Angreifer weiß, mit welchem System er es zu tun hat, muß er sich Zugang zu diesem System verschaffen. Hier kommen der Administrator und die Benutzer eines Systems ins Spiel.
Frei nach dem Motto “Sicherheit ist ein Prozess” muss ein guter Administrator ständig die eingesetzte Software überwachen, gegebenenfalls aktualisierte Versionen einspielen, sich auf ändernde Angriffsmuster einstellen und auf ungewöhnliche Log-Einträge sofort reagieren. Wenn z.B. der Server Log zeigt, dass ein Benutzer binnen einer Minute dutzende Male erfolglos versucht sich einzuloggen, dann ist die Wahrscheinlichkeit groß, dass
1. dies nicht der rechtmäßige User ist und
2. kein Mensch sich so oft kurz hintereinander einloggen kann.
Einen solchen Account sollte ein umsichtiger Administrator sofort deaktivieren bzw. sollte eine Software auf dem Server laufen, die automatisch auf solche Vorkommnisse reagiert.
Benutzer sollten bei der Wahl eines Passwortes etwas kreativer sein als “12345”. Auch der eigene Name oder gar das Geburtsdatum sind keine geeigneten Passwörter. Schließlich gibt es heute genügend Passwortgeneratoren im Netz, die einem ein sicheres Passwort erstellen können (z.B. passwort generator). Dabei ist auch auf die Passwortlänge zu achten. Je länger das Passwort, desto schwerer ist es zu knacken. Eine Passwortlänge zwischen 8 und 12 Zeichen erzeugt eine hinreichende Sicherheit.

Zusammenfassend lässt sich die Strategie zur Absicherung eines Apache Webserver in zwei Schritte aufteilen:

1. Informationen über den verwendeten Server schwer zugänglich machen

Die zumeist über Mailing-Listen wie Bugtraq oder Full-Disclosure veröffentlichten Fehler werden naturgemäß nicht nur von Administratoren gelesen, sondern auch von Angreifern aufmerksam studiert. Um diesen Angreifern das Finden der passenden Exploits zur eingesetzten Serversoftware zu erschweren, gilt auf Administratorseite der Grundsatz der Sparsamkeit an einsehbaren Daten: Alles, was einem potentiellen Angreifer dazu dienen könnte Informationen über mögliche Schwachstellen herauszufinden, gilt es so gut wie möglich zu unterdrücken. Dies fängt bei vermeintlich unsichtbaren Angaben im HTTP-Header wie der Versionskennung an und hört bei der Nennung des Betriebssystems samt Auflistung installierter Module in Fehlermeldungen auf.

Um die Anzeige von weiterführenden Informationen über den Apache Webserver zu unterdrücken, kann die Server Direktive ServerTokens verwendet werden. Diese Direktive steuert, ob der Response-Header Server, der an den Client zurückgesendet wird, eine Beschreibung des allgemeinen Betriebsystemtyps des Servers wie auch Informationen über einkompilierte Module enthält. In der Voreinstellung Full werden mindestens der Servername und die Versionsnummer angegeben.

Die installierten Module und die verwendeten Skriptsprachen werden bei einigen Betriebssystemen ebenso mitgesendet wie auch noch eine Angabe über das Betriebssystem selbst. Auf einem Liveserver sollte man die Einstellung auf Prod setzen. Damit wird nur noch der Servername ausgegeben.

Will man die Anzeige komplett unterdrücken, so muss man schon tiefer in die Innereien des Apache Webservers eingreifen, was nur Sinn macht, wenn man einen Root Server betreibt. In diesem Fall könnte man in den Quellcode des Webservers eingreifen. In der Datei version.h stehen folgende Zeilen, die abgeändert werden müssen:

#define SERVER_BASEVENDOR "Apache Group"
#define SERVER_BASEPRODUCT "Apache"
#define SERVER_BASEVERSION "2.4.27"

Diese Konstanten können Sie nach Herzenslust verändern, müssen danach jedoch den Webserver mit dem geänderten Quellcode neu übersetzen und installieren.

Es wird häufig noch die Direktive ServerSignature beschrieben. Diese ist zwar auch relevant, allerdings ist die Voreinstellung bereits auf Off, also den gesicherten Modus eingestellt, so dass hier kein Handlungsbefarf für den Administrator besteht.

Doch damit ist es mit dem verstecken der Informationen leider nicht getan. Es gibt noch andere Möglichkeiten, um herauszufinden, um welchen Webserver es sich handelt.

Die meisten Webserver implementieren den RFC 2068, die HTTP-Spezifikation, richtig. Dennoch gibt es einige kleinere Unterschiede, an denen man erkennen kann, welcher Webserver sich auf einem System befindet. Jeder Server kommuniziert mit einem Client mit Hilfe des Request/Response-Prinzips. In jedem Request oder Response befinden sich Header-Felder, die Angaben über den Client bzw. den Server enthalten, je nachdem in welche Richtung diese gesendet werden. Angaben über den Webserver findet man in den HTTP-Response-Header-Feldern. Diese Angaben unterscheiden sich bei den verschiedenen Servern. Über das Verhalten des jeweiligen Webservers lässt sich damit auf den verwendeten Webserver schließen (ich könnte den Vorgang auch näher durchleuchten, möchte aber hier keine schlafenden Hunde wecken ;-)).
Die Möglichkeiten, an Informationen über den Webserver zu gelangen, nennt man Webserver-Fingerprinting, also einen “Fingerabdruck” des Webservers erstellen. Hier führen gleiche Anfragen bei verschiedenen Webservern zu verschiedenen Verhaltensmustern, die ein Tool zur Webserver-Erkennung (HTTPrint oder WebserverFP) oder ein versierter Angreifer interpretieren kann.

Eine hundertprozentige Abschottung eines Apache Webservers ist daher leider nicht möglich. Doch durch die vorgenannte Maßnahme durch die ServerTokens Direktive, kann man es zumindest weniger versierten Angreifern schwerer machen. Weitere Maßnahmen zur Verschleierung werde ich im Rahmen des Artikels zur IT Sicherheit von PHP besprechen.

Von einer Behandlung der Webserver-Filter für Apache, z.B.

ModSecurity
mod_parmguard
mod evasive

habe ich in diesem Artikel abgesehen, weil diese Darstellung den Umfang dieses Formates sprengen würde.

2. Angriffsfläche reduzieren durch Deaktivierung von Modulen

Die Grundregel hierzu lautet: Je mehr Apache Module auf Ihrem Webserver aktiviert sind, desto größer ist die Gefahr, dass ein Angreifer irgendeine Sicherheitslücke in einem dieser Module entdeckt und diese ausnutzt, um den Webserver zu attackieren. Daher sollten grundsätzlich nur diejenigen Module aktiv sein, die Sie zum Betrieb Ihres Webprojektes tatsächlich benötigen. Welche dies im einzelnen sind, lässt sich natürlich nicht pauschal bestimmen. Jedoch können wir uns die standardmäßig aktivierten Module ansehen und anhand der Apache Dokumentation über die Notwendigkeit des Moduls nachdenken.

Welche Module aktiv sind, lässt sich bei laufendem Apache Webserver über die Kommandozeile anzeigen:

Unter Windows geht dies mit dem Befehl

httpd -M

und unter Linux / Mac OS mit

apachectl -M

Hier nun eine Auflistung von Modulen, die problemlos deaktiviert werden können, sofern sie im jeweiligen Webprojekt nicht benötigt werden.

3. Weitere Sicherheitseinstellungen

3.1. Cross-Site-Tracing (XST)

Bei einem Cross-Site-Tracing-Angriff (XST) wird versucht, bestimmte Benutzerdaten auszuschnüffeln. Über eine reguläre Webserver-Funktion (HTTP-TRACE) und durch Sicherheitslücken in Browsern ist es für einen Dritten möglich, HTTP-Header-Informationen zu erhalten. Dieser Angriff tritt besonders in Verbindung mit Cross-Site-Scripting (XSS) auf. Auf dem Apache Webserver werden HTTP-TRACE Anfragen über die Server Direktive TraceEnable ermöglicht. Daher ist es sinnvoll, die Einstellung auf Off zu stellen.

3.2. ETag

Ein ETag (Entity Tag) ist ein Feld im HTTP Header, welches zur Bestimmung von Änderungen an der angeforderten Ressource dient und damit beim Caching eingesetzt wird. Findige Hacker können dieses ETag aber zur Informationsbeschaffung verwenden, z.B. Inode Nummer oder multipart MIME boundary. Um dies zu unterbinden, sollte man die Anzeige des ETag abschalten. Hierzu wird in der httpd.conf die folgende Zeile eingetragen:

FileETag None

3.3. HTTP Request Methoden

Das HTTP 1.1 Protokoll unterstützt viele Request Methoden, die oftmals nicht benötigt werden, aber ein Sicherheitsrisiko darstellen können. Deshalb sollte man diejenigen Methoden, die man nicht benötigt, abschalten. Gewöhnlich verwendet man GET, HEAD und POST in einer Web Anwendung. Also können alle anderen Methoden (OPTIONS, PUT, DELETE, TRACE, CONNECT) deaktiviert werden. Hierzu ergänzt man die folgenden Zeilen in der httpd.conf innerhalb von :

<LimitExcept POST GET>
    require all denied
</LimitExcept>

3.4. Cookie mit HttpOnly und Secure Flag setzen

Cross-Site-Scripting (XSS) Attacken ermöglichen dem Angreifer Sessions und Cookies zu stehlen und manipulieren. Ein Weg, dies zu unterbinden ist, HttpOnly und Secure Flags in ein Cookie einzubauen.
Hierzu muss das Apache Modul mod_header aktiviert werden. Dazu kommentieren Sie die folgende Zeile in httpd.conf aus:

LoadModule headers_module modules/mod_headers.so

Ferner fügen Sie die folgende Zeile ebenfalls in die httpd.conf:

Header edit Set-Cookie ^(.*)$ $1 ;HttpOnly;Secure

3.5. Clickjacking Attacke

Clickjacking ist eine Technik, bei der ein Computerhacker die Darstellung einer Internetseite überlagert und dann deren Nutzer dazu veranlasst, scheinbar harmlose Mausklicks und/oder Tastatureingaben durchzuführen. Zur Absicherung lässt sich folgende Direktive im Apache httpd.conf einsetzen:

Header always append X-Frame-Options SAMEORIGIN

3.6. Server Side Includes (SSI)

SSI sind in (meist HTML-)Dokumente eingebettete, einfach zu nutzende Skript-Befehle, die auf dem Webserver ausgeführt werden, bevor das Dokument an den Client ausgeliefert wird. Daher auch ein gern verwendetes Einfallstor für Angreifer. Da SSI heute nur noch selten verwendet werden, sollte man diese auf dem Apache Webserver deaktivieren. Hierzu dient der folgende Eintrag in httpd.conf:

<directory "[ihr docroot verzeichnis]">
    Options -Indexes -Includes +FollowSymLinks
    ...

Hier ist auch gleichzeitig die Option Indexes deaktiviert, welche die Anzeige eines Webverzeichnisses unterbindet, wenn die URL auf ein Verzeichnis zeigt, in dem sich keine durch DirectoryIndex definierte Indexdatei (z.B. index.html) befindet. Da dieses Verhalten für einen Live Server fatal wäre und die Voreinstellung bei Apache auf Options Indexes steht, sollte man diese Direktive auf jeden Fall ausschalten. Bei der Verwendung von mod_rewrite sollte jedoch die Option FollowSymLinks eingeschaltet sein, da es ansonsten Schwierigkeiten mit dem Routing geben könnte.

3.7. X-XSS Protection

Hierbei handelt es sich um einen weiteren HTTP Header, der die in den meisten aktuellen Browsern eingebauten Cross-Site-Scripting (XSS)-Filter aktiviert. Diese sind standardmäßig aktiviert, daher ist dieser Header nur dazu da, den Filter für Ihre Seite wieder zu aktivieren, falls der Benutzer ihn abgeschaltet haben sollte. Hierzu ist folgende Zeile in httpd.config einzutragen:

Header set X-XSS-Protection "1; mode=block"

3.8. Slowloris Attacke

Slowloris ist eine Software, mit der ein einzelner Rechner unter minimaler Verwendung von Netzwerkressourcen einen Webserver lahmlegen kann.

Slowloris versucht, möglichst viele Verbindungen zum Zielserver aufzubauen und diese so lange wie möglich offen zu halten. Dieser Effekt wird durch paralleles Öffnen von Verbindungen und Senden von Teilanfragen erreicht. Von Zeit zu Zeit werden die Teilanfragen durch weitere HTTP-Header ergänzt, die Anfragen werden aber nie vollständig abgeschlossen. Dadurch steigt die Anzahl offener Verbindungen rasch an. Da die Anzahl offener Verbindungen, die ein Webserver gleichzeitig halten kann, begrenzt ist, werden legitime Anfragen von Webbrowsern abgelehnt – der Server ist lahmgelegt.

Es gibt derzeit kein wirksames Mittel gegen einen Slowloris-Angriff, aber es gibt Möglichkeiten, dessen Auswirkungen zu verringern. Zum einen kann man die Zeitspanne, die ein Client verbunden bleiben darf, verringern. Dazu trägt man in die httpd.conf folgende Zeile ein:

timeout 60

Standardmäßig ist der Wert auf 300 Sekunden eingestellt.

Speziell für den Apache-Webserver gibt es eine Reihe von Modulen, die den Schaden durch Slowloris verringern können, so zum Beispiel mod_limitipconn, mod_qos, mod_evasive, mod_security und mod_antiloris. Ab Version 2.2.15 enthält Apache das Modul mod_reqtimeout, welches von den Entwicklern als offizielle Lösung vorgeschlagen wird.

Letzteres kann über httpd.conf konfiguriert werden mit dem folgenden Eintrag:

RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

Dies sind die Standardeinstellungen und man kann an den einzelnen Stellschrauben noch etwas herumdrehen.

Natürlich muß das Modul zuvor auch aktiviert werden, indem die folgende Zeile in httpd.conf entkommentiert wird:

LoadModule reqtimeout_module modules/mod_reqtimeout.so

Zusätzlich sollte man die Sicherheit durch den Einsatz von SSL noch erhöhen. Hierzu würde es aber eines eigenen Artikels bedürfen, um die Installation und Konfiguration dediziert zu erläutern.

Diese Auflistung ist nicht abschließend und ich werde sie noch erweitern, sobald mir weitere Maßnahmen in den Sinn kommen oder über den Weg laufen sollten.

Fazit

Eine fehlerfreie Software gibt es nicht. Dazu ist der Entwicklungsprozess zu komplex und es spielen innerhalb eines Betriebssystems noch viele weitere Faktoren mit, die ein Entwickler einfach nicht voraussehen kann (Verwendung von Systembibliotheken, diverse Protokolle, Verwendung von APIs von Drittherstellern, etc.). Daher kann auch jedes noch so sorgfältig erstellte Programm von Hackern angegriffen werden. Die einzige Möglichkeit dem entgegenzuwirken ist, es dem Angreifer das Leben möglichst schwer zu machen. Im Internet sind die größten Schwachstellen die Übertragungsprotokolle TCP/IP zum einen und HTTP zum anderen. Daher ist bei der Konfiguration und Administration eines Apache Webservers (und dies gilt für alle anderen Webserver genauso!) äußerste Vorsicht und eine ständige Überwachung geboten.

Ähnliche Artikel:

• Apache Localhost mit HTTPS
• Apache Web Server auf Windows installieren
• PHP 7 auf Windows installieren