© maximkabb, 123RF

Viele Websites setzen auf den Apache Webserver – nicht zuletzt deshalb ist er aber auch ein beliebtes Einfallstor für Bösewichte. Was sich dagegen mit einfachen Mitteln erreichen lässt, zeigt dieser Artikel.

Zweifellos gehören Webserver zu den häufigsten Arten von Servern, die Admins heute im Rechenzentrum betreuen. Ein aktuelles Geschäftsmodell, das ohne irgendeinen HTTP-basierten Onlinedienst auskommt, lässt sich ja kaum noch denken. Entsprechend verbreitet sind Apache, Nginx & Co.

Der hohe Verbreitungsgrad hat aber eine Kehrseite: Dadurch stellen Webserver auch ein äußerst attraktives Ziel für Angreifer dar. Wer etwa eine ungepatchte Lücke in einer aktuellen Apache-Version findet, kann diese im Netz anschließend auf einer riesigen Anzahl von Systemen unmittelbar ausnutzen.

Zwar schicken die Distributionen üblicherweise Software ins Rennen, die gegen die schlimmsten bekannten Probleme bereits von Anfang an gewappnet ist, dennoch kann der Admin auch darüber hinaus weitere Sicherheitsfunktionen einbauen, die ihn dann viel ruhiger schlafen lassen. Dieser Artikel stellt die wichtigsten und effektivsten Maßnahmen dieser Art vor.

Angriff und Abwehr verstehen

Ein klassisches Webserver-Setup besteht aus mehreren Ebenen. Im Hintergrund werkelt irgendeine Datenbank, meist Maria DB, die die Daten der Webapplikation enthält. Im Vordergrund kümmert sich Apache darum, die Webseiten an den User auszuliefern. Angreifer, die sich Zugang zu Ressourcen verschaffen wollen, können jede dieser Schichten anpeilen. Admins haben es also mit einem Bedrohungsszenario zu tun, das einigermaßen komplex ist und ein differenziertes Vorgehen erfordert.

Die möglichen Gegenmaßnahmen unterteilen sich in mehrere Kategorien. Erstens tut der Admin gut daran, so wenige Informationen wie möglich über sein Setup an Nutzer weiterzugeben. Alle Daten, die für den reibungslosen Betrieb des Webservers nicht nötig sind, sollten Anwender auf der anderen Seite auch nicht zu Gesicht bekommen. Ein praktisches Beispiel dafür ist das Verstecken der Apache-Version in HTTP-Antworten.

Zweitens kommen aktive Schutzmaßnahmen hinzu, die das Ausnutzen von Sicherheitslücken verhindern sollen. In direktem Zusammenhang damit steht eine dritte Kategorie von Maßnahmen: Das regelmäßige Einspielen von Updates, die erkannte Probleme reparieren.

Die vierte Säule der Abwehr besteht darin, stattfindende Angriffe zu erkennen – einschließlich der Angriffe in der Vergangenheit, die erfolgreich waren. Hier kommen etwa Intrusion Detection Systeme (IDS) zum Einsatz, die im Falle eines Falles Alarm auslösen. Im Folgenden geht dieser Artikel auf die vier Kategorien von Schutzmaßnahmen im Detail ein.

Grundsätzliches

Los geht es aber mit einigen Tipps, die Admins eigentlich selbstverständlich beachten sollten, die allerdings in erschreckend vielen Setups wenig bis gar keine Rolle spielen. Nicht selten hat sich der Autor dieses Artikels in der Vergangenheit auf Webservern eingeloggt – und eine Ubuntu-Anzeige begrüßte ihn, die ausstehende Security-Updates verkündete. Klarer Fall: Das betroffene System war irgendwann in der Vergangenheit einmal aufgesetzt und danach nie wieder angefasst worden, vermutlich aus Angst, durch ein Update die bestehende Konfiguration zu gefährden.

Ähnliches gilt meist auch für die Applikationen, denen die Webserver zuarbeiten: Joomla, WordPress, Drupal und die verschiedenen anderen CMS-Systeme geben in schöner Regelmäßigkeit Security Advisories und dazu passende Updates heraus, ebenso wie die vielen Distributoren für ihre Linux-Systeme. Wer jene Updates konsequent ignoriert, braucht sich um andere Sicherheitsmaßnahmen gar keine Gedanken zu machen – er unterhält ein System, das ohnehin offen wie ein Scheunentor ist.

Wer Webserver betreibt, sollte größten Wert darauf legen, dass er das System jederzeit problemlos von Grund auf wieder herstellen und die Nutzerdaten aus Backups einspielen kann. Auf dieser Grundlage lassen sich Updates planen und testen, und selbst wenn beim Update der produktiven Umgebung etwas nicht so läuft wie erwartet, ist der alte Zustand schnell wieder hergestellt.

Um das kontinuierliche Einspielen von Security Updates kommen Admins in keinem Fall herum. Und falls die eigene Verantwortung nur bis zur Applikationsebene reicht, die Kunden also für ihre Webanwendungen selbst verantwortlich sind, sollte der Admin zumindest sein Monitoring so einrichten, dass es die Kunden automatisch auf ausstehende Sicherheitsupdates hinweist.

In der Regel geht es Angreifern heute gar nicht mehr darum, die volle Kontrolle über ein entferntes System zu erlangen. Oft genug reicht es etwa, wenn ein Bösewicht einen Server für den Versand von Spam-Nachrichten missbrauchen kann, beispielsweise als Teil eines Botnetzes. Und dafür benötigt er in der Regel keine Rootrechte, oft ist das System sogar so eingerichtet, dass die jeweilige Webapplikation selbst E-Mails über einen Relay-Host verschickt.

Gelingt es einem Ganoven, die Kontrolle über die Webapplikation zu übernehmen, fällt ihm auch die Option zum massenhaften Versand vom Spam in die Hände – und die Inbox des Admin dürfte sich früher oder später mit entsprechenden Abuse-Beschwerden füllen.

Denkbar ist aber auch, dass der Webserver aus der Ferne gesteuert zum Teil eines Botnetzes wird, das gezielt für DDoS-Attacken auf andere Dienste im Internet zum Einsatz kommt. Im schlimmsten Fall sieht sich das betreibende Unternehmen möglicherweise juristischen Fragen gegenüber, bei denen es auch um Schadenersatz gehen kann. Lange Rede, kurzer Sinn: Das Einspielen von Sicherheitsupdates für alle Ebenen des eigenen Webserver-Stacks ist unbedingte Voraussetzung und darf unter keinen Umständen ausbleiben.

Schritt 2: Die Angriffsfläche verkleinern

Betrüger im Netz verhalten sich ähnlich wie jene Langfinger, die in Häuser oder Wohnungen einsteigen: Sie wählen stets den Weg des geringsten Widerstandes. Weil es im Netz so viele verwundbare Systeme gibt, verlieren Angreifer schnell das Interesse daran, Mehraufwand zu betreiben, um spezielle Systeme in ihre Gewalt zu bringen – es sei denn, es handelt sich um solche, die im Hintergrund Zugriff auf andere, wichtigere Ressourcen verheißen. Das ist beim Otto-Normal-Webserver in aller Regel jedoch auszuschließen.

Eine sinnvolle Idee ist es deshalb, Angreifern so wenig Informationen wie möglich freiwillig zu überlassen. Ein Beispiel: Weiß der Angreifer, welche Version des Apache-Webservers auf dem Zielsystem läuft, weiß er auch, ob dieses potenziell verwundbar ist. Denn selbstverständlich lesen auch Bösewichte die einschlägigen Security Bulletins der Distributoren. Das Problem: In der Standardkonfiguration liefert Apache diese Information bereitwillig aus.

Der Admin unterbindet dieses Verhalten, indem er in seiner Konfiguration den Wert von »ServerSignature« auf »Off« setzt. Ebenso empfiehlt es sich, den Wert von »ServerTokens« auf »Prod« zu setzen. Dann steht im Header der Antwort eines Apache-Webservers nur noch »Apache«, nicht aber die komplette Versionsnummer, anders als in Abbildung 1.

Abbildung 1: In seinen Headern verrät der Apache-Webserver ab Werk viele Details über sich selbst – für Angreifer ein gefundenes Fressen.

Auch PHP lässt sich übrigens einige Geschwätzigkeit abgewöhnen: Setzt der Admin in der »php.ini« den Wert »expose_php« auf »Off«, fällt der »X-Powered-By«-Header in der Antwort von Apache weg, der ansonsten Details über die genutzte PHP-Version preisgäbe. Weil PHP ebenfalls ein sehr beliebtes Einfallstor für Gauner ist, sei diese Einstellung dringend empfohlen.

Directory Listings verbieten

Viele Anwender deaktivieren das so genannte Directory Listing in Apache in der Standardkonfiguration ohnehin, Admins tun gut daran, die Einstellung bei sich zu überprüfen. Im Grunde geht es nur darum, ob Apache beim Öffnen eines Ordners per Webbrowser dessen Inhalt anzeigt, falls keine Index-Datei (also »index.html« oder »index.php«) vorhanden ist, oder ob er stattdessen den Fehlercode 403 anzeigt, also »Permission Denied« zurückliefert.

Eingeschaltete Directory Listings haben in der Vergangenheit manchem Unternehmen tatsächlich beinahe den Hals gebrochen: So kommt es bisweilen vor, dass Admins im Stress während eines Ausfalls unverschlüsselte Backups der Datenbank in einem Ordner anlegen, der per Apache serviert wird. Sind Directory Listings aktiviert, kann ein potenzieller Angreifer seelenruhig die Inhalte aller Verzeichnisse unterhalb von »DocumentRoot« durchgehen und schauen, ob er dort vielleicht etwas Spannendes findet. Indem der Admin für seine Apache-Verzeichnisse die Option »-Indexes« setzt, unterbindet er dieses Treiben.

Unnötige Module

Last but not least sollen auch die Apache-Module zur Sprache kommen: Viele Distributoren gehen nämlich nach dem Motto “Viel hilf viel” vor und aktivieren Apache-Module, die die meisten Nutzer gar nicht brauchen. Es schadet nicht, auf dem eigenen Systemen einmal nachzusehen, welche Apache-Module aktiv sind. Wer etwa das »mod_info« aktiv vorfindet, sollte unbedingt handeln: Es exponiert nämlich die Seite »/server-status«, über die Surfer sich in kurzer Zeit ein möglichst umfassendes Bild des Servers machen und viele Details über ihn herausfinden können.

Entweder schaltet der Admin das »mod_info«-Modul gleich ganz ab, oder er verbietet per »Location«-Direktive in der Apache-Konfiguration den Zugriff auf »/server-status« und lässt nur Ausnahmen etwa für den lokalen Zugriff oder für den Zugriff einiger ausgewählter Hosts zu (Abbildung 2).

Abbildung 2: Die Server-Status-Seite von Apache sollte bei produktiven Setups ausgeschaltet oder zumindest zugriffsbeschränkt sein.

“mod_security”

Doch so sehr Admins sich auch bemühen, die unfreiwillige Weitergabe von Details ihrer Apache-Installation in die Außenwelt zu unterbinden, völlig immun gegen Angriffe macht das nicht. Es wälzen sich immer wieder neue Wellen von Brute-Force-Angriffen durch das Internet, die auf gut Glück schauen, wo sie eventuell vorhandene Sicherheitslücken ausnutzen können.

Das vorrangige Ziel dieser Angriffe sind beliebte Webapplikationen wie Dropbox, Drupal, WordPress oder viele andere vergleichbare Produkte. Weil diese stark verbreitet sind, versprechen die Langfinger sich leichte Beute.

Das Prinzip ist immer dasselbe: Programmgesteuert rufen die Angreifer entsprechende URLs auf und können so eine mögliche Sicherheitslücke automatisch ausnutzen und das Zielsystem dazu bringen, sich in gewünschter Weise zu verhalten. Regelmäßig kommen dieselben Angriffsarten zum Einsatz: SQL-Injections, Cross-Site-Scripting und ähnliche Mittel gehören zu den bevorzugen Tools der Gauner.

Genau hier setzt »mod_security« [1] an: Es schaltet sich zwischen den Webserver und den externen Client und prüft die eingehenden Anfragen auf verschiedene Muster oder Kommandos hin. Erkennt es einen Angriff, weist es die gesamte Anfrage zurück. Der Client bekommt lediglich eine 403er-Meldung mit »Permission Denied« zurück – und der Angriff ist erfolgreich unterbunden.

Wie funktioniert »mod_security« im Detail und wie die Einrichtung? Das folgende Beispiel orientiert sich an Ubuntu 16.04. Um »mod_security« dort zu nutzen, empfiehlt es sich, auf das entsprechende Paket zurückzugreifen, das zu Ubuntu gehört. Es trägt den Namen »libapache2-modsecurity« und lässt sich wie gewohnt per »apt-get « installieren. Danach aktiviert der Admin per »sudo a2enmod headers« und »sudo a2enmod security2« das Headers-Modul sowie das Security-Modul. Ersteres ist nötig, um aussagekräftige Fehlermeldungen zu erhalten, falls ein Request von »mod_security« aufgrund fehlerhafter Header zurückgewiesen wird.

Nach der Installation des passenden Pakets ist »mod_security« zwar schon aktiv, noch kennt es allerdings keine Regeln, anhand derer es Zugriffe auf den Webserver kontrollieren soll. Um das zu ändern, kopiert der Admin noch die Datei »/etc/modsecurity/modsecurity.conf-recommended« nach »/etc/modsecurity/modsecurity.conf«.

Danach empfiehlt es sich, die Datei im Editor der persönlichen Präferenz zu öffnen und zur Zeile »SecRuleEngine« zu springen. Der Parameter kennt drei Werte: »Off« schaltet die Erkennung von Angriffen ab. »On« schaltet die Erkennung scharf und sorgt dafür, dass »mod_security« verdächtige Aktivitäten unterbindet.

»DetectionOnly« ist ein Mittelding: Hier überprüft »mod_security« zwar den durchgehenden Traffic und hinterlässt auch entsprechende Lognachrichten, unterbindet jedoch Angriffe nicht, wenn es sie identifiziert zu haben glaubt. Im produktiven Einsatz sollte der Wert folglich auf »On« stehen.

Am Ende der Konfigurationsdatei stellt der Admin sicher, dass die Inhalte der Core Set Rules (CRS) von »mod_security« aktiv sind. Dazu fügt er am Ende von »modsecurity.conf« drei Zeilen ein:

# ModSecurity Core Set Rules (CRS)
IncludeOptional /usr/share/modsecurity-crs/*.conf IncludeOptional /usr/share/modsecurity-crs/activated_rules/*.conf

Ein abschließender Reload von Apache aktiviert die neue Modulkonfiguration. Im Access- sowie Error-Log der jeweiligen Website finden sich künftig Einträge über geblockte Zugriffe. Auch führt »mod_security« ein eigenes Logfile in »/var/log«, das detaillierte Auskünfte darüber gibt, warum ein spezieller Request geblockt worden ist (Abbildung 3).

Abbildung 3: Sobald »mod_security« aktiv ist, greift das Modul aktiv in die Kommunikation des Webservers ein und unterbindet verdächtige Aktivitäten.

Mit False Positives umgehen

Einen Haken hat die Sache mit »mod_security«: Aktiviert man das Modul, kommt es bei den gängigen Anwendungen wie WordPress oder Joomla, aber auch bei klassischen Businessanwendungen wie Jira oder Confluence zu einer Reihe von False Positives. Im schlimmsten Falle lassen sich jene Dienste dann gar nicht mehr nutzen.

Der Admin hat allerdings viele Optionen, dem Problem entgegenzuwirken: Er kann die entsprechenden Regeln im CRS entweder komplett deaktivieren oder Ausnahmen vom bestehenden Regelwerk per Konfigurationsdatei definieren. Dazu legt er im CRS-Verzeichnis eine neue Konfigurationsdatei an, in der verschiedene Schlüsselwörter zu nutzen sind. Um etwa die Regel mit der ID 123 zu deaktivieren, genügt der Eintrag » SecRuleRemoveById 123«. Per »SecRule«-Direktive lassen sich hier auch vorhandene Regeln ändern (Abbildung 4).

Abbildung 4: Ein fertiger Regelsatz für »mod_security« kommt von den CRS, aber der Admin hat die Möglichkeit, die Regeln zu verändern.

Möchte der Admin gleich einen ganzen Block von Sicherheitsregeln außer Kraft setzen, geht das ebenfalls per »SecRuleRemoveById« – anstelle der einzelnen ID gibt er allerdings einen ID-Bereich im Format »1-1000« an. Die Nummerierung der Dateinamen im CRS-Verzeichnis kommt ihm dabei zur Hilfe, weil die Dateinamen jeweils auch die IDs enthalten. Die Regeln 941000 bis 941999 etwa beschäftigen sich ausschließlich mit potenziellen XSS-Attacken.

Der wirklich mühsame Teil der Arbeit ist aber jener, die Regeln zu identifizieren, die im Alltag Probleme bereiten. Dazu ist es nötig, sich die von »mod_security« in seinem Logfile ausgegebenen Meldungen im Detail anzusehen und die problematischen Regeln herauszufiltern. Wichtig: Ändert der Admin die Konfiguration von »mod_security«, ist anschließend ein Neustart des Webservers notwendig, damit diese auch aktiv werden.

Übrigens: Probleme macht »mod_security« auch an Stellen, an denen man nicht unbedingt damit rechnet. Lädt der Admin etwa in Confluence eine Word-Datei hoch, deren Header beschädigt ist, wertet »mod_security« das regelmäßig als Angriff und Confluence zeigt nur einen Permission-Denied-Fehler an. Das ist unerwartet, weil innerhalb von Confluence solche Fehler eigentlich von der Software selbst abgefangen und mit einer aussagekräftigen Meldung ausgegeben werden. Wer »mod_security« nutzt, sollte daran denken, dass das Modul schräge Fehlermeldungen auslösen kann.

Wer mehr über das Schreiben von Whitelists für »mod_security« erfahren möchte, schaut sich am besten bei den Entwicklern der CRS um: Die beschreiben in einer ausführlichen Anleitung alles, was man wissen muss [2].

Die große Lösung: Suricata

Schaut man sich die Funktionalität an, die »mod_security« bietet, entsteht schnell der Eindruck eines Intrusion-Prevention-Systems (IPS). Bei »mod_security« liegt der Fokus allerdings auf typischen Webserver-Attacken und Angriffen.

Eine umfassende Lösung in Form eines IDS samt IPS ist Suricata [3]: Das Werkzeug heftet sich an das vorhandene Netzwerkinterface und schneidet den dort vorbeigehenden Traffic mit, überprüft ihn anhand gegebener Signaturen auf eventuelle Angriffe und unterbindet diese auf Wunsch. De facto handelt es sich bei Suricata also um ein IDS, das auf Wunsch auch IPS-Funktionen ausführt. Die gute Nachricht: Die Installation von Suricata unter Ubuntu 16.04 gestaltet sich problemlos und unkompliziert, wie das folgende Beispiel beweist.

Im ersten Schritt aktiviert der Admin das Suricata-PPA von Peter Manev, sodass die dort hinterlegten Pakete auf seinem System zur Verfügung stehen. Im Anschluss lässt sich Suricata mittels »apt-get install suricata« wie üblich installieren. Danach öffnet der Admin in einem Editor seiner Wahl die Datei »/etc/suricata/suricata-debian.yaml«, um den Dienst an die verschiedenen lokalen Bedingungen anzupassen.

In der Sektion »outputs:« sollte »file« aktiviert sein und der Parameter »filename« sollte dorthin zeigen, wo der Admin die Logeinträge von Suricata später sehen möchte – etwa »/var/log/ suricata/suricata.log«. In »/etc/default/suricata« setzt der Admin den Wert von »RUN« anschließend auf »YES«. Der Befehl »sudo systemctl restart suricata« setzt Suricata in Gang. Noch fehlt allerdings ein Satz von Regeln, anhand derer Suricata Angriffe erkennt. Dem Ubuntu-Paket liegen die entsprechenden Regeldefinitionen nämlich nicht bei.

Das ist allerdings nicht der Schludrigkeit des Paketautors geschuldet, sondern hat ganz handfeste praktische Gründe: Ähnlich wie bei Antiviren-Tools wie Clam AV ändern sich auch die Angriffssignaturen für Suricata ständig. Das kleine Werkzeug »oinkmaster« hilft dabei, die Signaturen unabhängig von der Paketverwaltung aktuell zu halten. Praktisch: »oinkmaster« gehört zu Suricata, ist also nach der Installation des Pakets schon vorhanden.

In »/etc/oinkmaster.conf« stellt der Admin sicher, dass beim Feld »url« der Eintrag http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz lautet. Danach setzt der Befehl »sudo oinkmaster -o /etc/suricata/rules« das Update der Signaturen in Gang. Weil Suricata ab Werk so konfiguriert ist, dass es alle Dateien in »/etc/suricata/rules« automatisch einliest, ist nach dem »oinkmaster«-Aufruf nur noch ein abschließender Suricata-Neustart nötig – fertig (Abbildung 5).

Abbildung 5: Suricata ist ein komplettes IDS und erkennt verdächtige Aktivitäten nicht nur auf der Webserver-Ebene. Zudem kann es auch vorbeugend einschreiten, wenn es Angriffe erkennt.

Benötigte IPtables-Regeln

Netzwerkpakete durchlaufen die aktuelle Konfiguration durch Suricata allerdings noch nicht. Weil das IDS ab Werk darauf ausgelegt ist, die Nfqueue-Funktionalität des Kernels zu nutzen, ist eine entsprechende IPtables-Konfiguration ebenfalls nötig. Freilich könnte der Admin Suricata auch so umkonfigurieren, dass es sich direkt an eine spezifische Netzwerkkarte hängt. Das sorgt aber für Probleme, wenn möglicherweise gefährliche Pakete auf mehreren Interfaces den Weg in das System finden.

Die Nfqueue-basierte Lösung hingegen erlaubt es, Pakete auf beliebigen Schnittstellen zu untersuchen. Obendrein ist es nicht sonderlich kompliziert, die passende Konfiguration im System zu hinterlegen. Dafür genügen zwei »iptables«-Aufrufe:

sudo iptables -I INPUT -j NFQUEUE
sudo iptables -I OUTPUT -j NFQUEUE

Zusätzlich sollte der Administrator noch Sorge dafür tragen, dass diese Befehle auch einen Reboot überleben, dass die entsprechende Konfiguration also auch nach dem Neustart des Systems vorhanden ist.

Ist IPtables wie beschrieben konfiguriert, scannt Suricata automatisch ein- wie ausgehende Pakete nach den in seinen Signaturen festgelegten Regeln. Erkennt es einen Angriff, schreibt es eine entsprechende Meldungszeile in sein Log. Das muss der Admin dann allerdings händisch in sein Monitoring einbauen, wenn er Warnungen auf Basis der Suricata-Tests erhalten möchte.

Fine-Tuning für Suricata

Das beschriebene Suricata-Setup ist erst die Grundausstattung und kratzt nur an der Oberfläche dessen, was Suricata leisten könnte. Wer will, dass Suricata Angriffe nicht nur erkennt, sondern auch unterbindet, muss dazu ins Regelwerk von Suricata eingreifen [4]: Neben dem Melden eines Angriffs bietet Suricata auch die Möglichkeit, Pakete, die es für verdächtig hält, automatisch zu verwerfen oder zurückzuweisen.

Wie bei »mod_security« steigt in diesem Fall aber auch bei Suricata die Gefahr von False Positives und es kommen eventuell auch solche Pakete nicht beim Empfänger an, die eigentlich ihren Weg ins System hätten finden sollen.