Beim bereits in About Security #203 erwähnten Virtual Hosting hosted ein Webserver mehrere voneinander unabhängige Websites, die anhand des 'Host'-HTTP-Headers identifiziert werden. Eine falsche Konfiguration kann dabei zu möglichen Angriffspunkten führen.

Der Apache-Webserver wird z.B. folgendermaßen für die Nutzung virtueller Hosts konfiguriert:

<VirtualHost *>
  ServerName website.example
  DocumentRoot www/website
</VirtualHost>
 
<VirtualHost *>
  ServerName andere-website.example
  DocumentRoot www/anderewebsite
</VirtualHost>

In den VirtualHost-Containern können außer dem DocumentRoot weitere für die betreffende Website geltende Optionen konfiguriert werden. Eine häufige Fehlkonfiguration ist dabei das Übersehen des Default-Hosts, wodurch alle durchgeführten Konfigurationen, besonders natürlich die mit Sicherheitsbezug, nur für virtuelle Hosts gelten und beim Zugriff auf den Default-Host ignoriert werden.

Fehlkonfigurationen entdecken

Zuerst wird eine Reihe von GET-Requests für das Root-Verzeichnis gesendet:

• Zuerst mit dem korrekten 'Host'-Header der untersuchten Website,
• dann mit einem unsinnigen 'Host'-Header,
• dann der IP-Adresse des Webservers als 'Host'-Header und
• ohne 'Host'-Header.

Danach werden die Ergebnisse der Requests verglichen. Bei Verwendung der IP-Adresse als 'Host'-Header wird oft ein Directory-Listing ausgegeben, manchmal unterscheiden sich für verschiedene 'Host'-Header auch die zurückgelieferten Default-Inhalte.

Gibt es unterschiedliche Reaktionen, wird die Webanwendung danach mit den entsprechenden 'Host'-Headern wie ab About Security #144 beschrieben erneut untersucht. Der Schwachstellenscanner Nikto kann mit der Option -vhost verwendet werden, um bei der ersten Untersuchung übersehene Default-Inhalte (siehe About Security #210) zu finden.

Sichere Konfiguration

Die sichere Konfiguration des Webservers ist nicht besonders schwierig, die meisten Fehler entstehen, weil etwas übersehen oder falsch eingeschätzt wird. Um so wichtiger ist es, die Dokumentation aller eingesetzten Programme sowie evtl. vorhandene Anleitungen zum Härten gründlich zu studieren. Machmal verstecken sich die wichtigsten Punkte in Fußnoten oder Anhängen. Die folgenden allgemeinen Punkte müssen unabhängig von der jeweils verwendeten speziellen Software auf jedem Fall berücksichtigt werden:

• Vorhandene Default-Zugangsdaten müssen geändert werden (siehe About Security #209). Wenn möglich, sollten dabei Benutzername und Passwort geändert werden. Kann nur das Passwort geändert werden, muss das besonders gut werden - Brute-Force- und Wörterbuchangriffe auf bekannte Benutzernamen sind übliche Angriffe. Nicht benötigte Default-Accounts sollten komplett gelöscht werden.
• Der öffentliche Zugriff auf Administrationsinterfaces muss deaktiviert werden. Das kann entweder durch eine Zugriffskontrolle für die entsprechenden Pfade im Webroot-Verzeichnis und/oder über entsprechende Firewall-Regeln für die für das Administrationsinterface verwendeten Ports geschehen.
• Nicht benötigte Default-Inhalte müssen entfernt werden (siehe About Security #209 / #210). Dazu kann zum einen der Inhalt der Webverzeichnisse manuell durchsucht werden, zum anderen der Schwachstellenscanner Nikto als zusätzliche Kontrolle dienen. Dabei sollte man die unterschiedlichen Ansätze beachten: Nikto sucht nach bekannten Default-Inhalten ("was ist da, wo es immer ist"), während man selbst nach nicht gewünschten Inhalten sucht ("was ist da, obwohl es nicht da hin gehört").
• Benötigte Default-Inhalte und besonders -Funktionalitäten müssen so weit wie möglich gehärtet werden. Allgemein läuft das darauf hinaus, alle nicht benötigten Optionen und Funktionen zu deaktivieren.
• Alle Webverzeichnisse müssen auf unerwünschte Ausgaben von Directory-Listings geprüft werden (siehe About Security #210). Wenn nirgends Verzeichnislisten benötigt werden, können sie in der serverweiten Konfiguration deaktiviert werden. Außerdem kann sicher gestellt werden, das in jedem Verzeichnis eine Default-Datei wie z.B. index.html enthalten ist.
• Alle nicht von der Webanwendung benötigten HTTP-Methoden sollten deaktiviert werden (siehe About Security #211). Sehr wahrscheinlich bleiben dann nur GET und POST übrig.
• Eine nicht benötigte Proxy-Funktion muss deaktiviert werden (siehe About Security #212). Ist eine Nutzung des Webservers als Proxy notwendig, muss die Funktion so weit wie möglich gehärtet werden. Idealerweise sind dann nur Zugriffe auf die genau spezifizierten Hosts und Ports möglich, die erwünscht sind. Als zusätzliche Sicherheitsmaßnahme können ausgehende Requests auf der Netzwerkebene auf Zulässigkeit geprüft werden.
• Wird Virtual Hosting verwendet (s.o.), müssen alle Schutzmaßnahmen auch für den Default-Host durchgeführt werden.

Hiermit ist der Themenbereich "Schwachstellensuche im Webserver" abgeschlossen. Ab der nächsten Folge geht es um die Suche nach Schwachstellen in der Authentifizierung.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #206: Schwachstellen-Suche: Webserver identifizieren
• About Security #207: Schwachstellen-Suche: Webserver angreifen
• About Security #208: Schwachstellen-Suche: Webserver schützen
• About Security #209: Schwachstellen-Suche: Webserver untersuchen
• About Security #210: Schwachstellen-Suche: Webserver-Konfiguration
• About Security #211: Schwachstellen-Suche: Gefährliche HTTP-Methoden
• About Security #212: Schwachstellen-Suche: Proxy-Server
• About Security #213: Schwachstellen-Suche: Webserver konfigurieren