Haftungsausschluss: Dieser Beitrag dient ausschließlich Bildungs- und Informationszwecken. Die hier gezeigten Informationen und Angriffe dürfen niemals für illegale Zwecke oder auf Systemen, für die keine explizite Erlaubnis eingeräumt wurde, verwendet werden. Solche Handlungen können gegen geltende Gesetze verstoßen und schwerwiegende rechtliche Konsequenzen nach sich ziehen.

Zusammenfassung

Dieser Beitrag fasst grundlegende Sicherheitsmaßnahmen für die Härtung von Webservern zusammen. Dieses SecCore Essential ist implementiert, wenn die folgenden Punkte zutreffen:

  • Directory Listing ist auf allen Webservern deaktiviert.
  • Es befinden sich keine Backup-, Konfigurations-, Datenbankdateien oder Ähnliches in öffentlich zugänglichen Verzeichnissen.
  • Alle Standardpasswörter von Webapplikationen, Datenbanken und Administrationsoberflächen wurden geändert.
  • Der Webserver gibt keine internen Informationen wie IP-Adressen, Dateisystempfade, Stack Traces oder detaillierte Versionsinformationen preis.

Einleitung

Webserver und Webapplikationen sind in den meisten Unternehmen direkt aus dem Internet erreichbar und stellen damit eines der ersten Ziele für Angreifer dar. Bereits einfache Fehlkonfigurationen können dazu führen, dass sensible Informationen offengelegt oder ganze Systeme kompromittiert werden. Häufig sind es keine komplexen Exploits, sondern grundlegende Versäumnisse in der Basiskonfiguration, die einen erfolgreichen Angriff ermöglichen.

Typische Schwachstellen umfassen aktiviertes Directory Listing, vergessene Backup- und Konfigurationsdateien auf dem Webserver, nicht geänderte Standardpasswörter sowie die unbeabsichtigte Preisgabe interner Informationen durch Fehlermeldungen oder HTTP-Header. Dieser Beitrag zeigt die häufigsten Angriffsvektoren auf und beschreibt wirksame Gegenmaßnahmen.

Häufige Angriffsvektoren

Die folgenden Abschnitte beschreiben verschiedene Angriffsvektoren, die im Zusammenhang mit unsicher konfigurierten Webservern stehen.

Directory Listing

Directory Listing ist eine Funktion vieler Webserver, die den Inhalt eines Verzeichnisses anzeigt, wenn keine Indexdatei (z.B. index.html oder index.php) vorhanden ist. Ist diese Funktion aktiviert, kann ein Angreifer sämtliche Dateien und Unterverzeichnisse eines Webverzeichnisses einsehen und herunterladen.

Dies führt dazu, dass sensible Dateien wie Konfigurationsdateien, Datenbankdumps, Quellcode oder interne Dokumentation für jeden zugänglich werden. Selbst wenn einzelne Dateien nicht direkt verlinkt sind, können sie über das Directory Listing gefunden und heruntergeladen werden. Auch wenn Tools wie Gobuster1 oder feroxbuster2 das Auffinden solcher Verzeichnisse automatisieren, reicht bei aktiviertem Directory Listing bereits ein einfacher Browser, um alle Inhalte einzusehen.

Backup- und Konfigurationsdateien auf Webservern

Ein häufiges und gravierendes Problem ist das Vorhandensein von Backup- und Konfigurationsdateien in öffentlich erreichbaren Verzeichnissen eines Webservers. Solche Dateien entstehen typischerweise bei Wartungsarbeiten, Software-Updates oder manuellen Sicherungen und werden anschließend nicht entfernt.

Beispiele für kritische Dateitypen sind:

  • Backup-Dateien: .bak, .old, .save, .orig, .copy (z.B. config.php.bak, web.config.old)
  • Archivdateien: .zip, .tar.gz, .sql.gz (z.B. backup.zip, database.sql.gz)
  • Datenbankdumps: .sql, .dump (z.B. production.sql, dump.sql)
  • Konfigurationsdateien: .env, .htaccess, wp-config.php, appsettings.json, database.yml
  • Versionskontrolldateien: .git/, .svn/, .gitignore

Diese Dateien enthalten häufig Datenbank-Zugangsdaten, API-Schlüssel, interne IP-Adressen oder sogar den vollständigen Quellcode einer Applikation. Ein Angreifer kann mit diesen Informationen die Datenbank direkt ansprechen, sich bei der Applikation als Administrator anmelden oder gezielt nach weiteren Schwachstellen im Quellcode suchen.

Besonders kritisch sind exponierte .git-Verzeichnisse, da dadurch mit Tools wie git-dumper3 der gesamte Quellcode inklusive der Commit-Historie rekonstruiert werden kann. Früher gelöschte Passwörter oder Zugangsdaten in älteren Commits werden dadurch wieder sichtbar.

Standardpasswörter

Viele Webapplikationen, Content-Management-Systeme (CMS) und Administrationsoberflächen werden mit vordefinierten Zugangsdaten ausgeliefert. Bekannte Beispiele sind:

  • Apache Tomcat: tomcat:tomcat oder admin:admin
  • phpMyAdmin: häufig ohne Passwort oder mit root ohne Passwort konfiguriert
  • WordPress: Standardbenutzer admin mit bei der Installation gewähltem, oft schwachem Passwort
  • Router und Appliances: admin:admin, admin:password oder herstellerspezifische Kombinationen

Datenbanken wie DefaultCreds-Cheat-Sheet4 und CIRT.net5 sammeln öffentlich bekannte Standardzugangsdaten für tausende Produkte. Angreifer testen diese systematisch gegen erreichbare Dienste, oft automatisiert mit Tools wie Hydra6 oder Nuclei7.

Wird das Standardpasswort nicht geändert, erhält ein Angreifer sofort vollen Zugriff auf die jeweilige Applikation. Bei Administrationsoberflächen kann dies die vollständige Kontrolle über den Webserver oder die darunterliegende Infrastruktur bedeuten.

Preisgabe interner Informationen

Webserver und Webapplikationen können auf verschiedene Weise interne Informationen preisgeben, die einem Angreifer bei der weiteren Planung und Durchführung eines Angriffs helfen. Diese Informationspreisgabe geschieht oft unbeabsichtigt und wird daher leicht übersehen.

Typische Quellen für die Offenlegung interner Informationen sind:

  • HTTP-Header: Server-Header wie Server: Apache/2.4.51 (Ubuntu) oder X-Powered-By: PHP/7.4.3 verraten die eingesetzte Software und deren Versionsnummern. Dies ermöglicht einem Angreifer, gezielt nach bekannten Schwachstellen für diese Versionen zu suchen.
  • Fehlermeldungen: Detaillierte Fehlermeldungen, wie sie beispielsweise im Debug-Modus von Frameworks wie Django, Laravel oder ASP.NET ausgegeben werden, enthalten häufig Dateisystempfade, Datenbankstrings, Stack Traces oder interne Variablennamen. Diese Informationen erleichtern die gezielte Ausnutzung weiterer Schwachstellen erheblich.
  • Interne IP-Adressen: Durch fehlerhafte Reverse-Proxy-Konfigurationen, Weiterleitungen oder spezielle HTTP-Header (z.B. X-Forwarded-For, X-Real-IP) können interne IP-Adressen aus privaten Adressbereichen (z.B. 10.x.x.x, 172.16.x.x, 192.168.x.x) nach außen gelangen. Diese Informationen geben Aufschluss über die interne Netzwerkstruktur.
  • Statusseiten und Debugging-Endpunkte: Seiten wie /server-status, /server-info (Apache), /actuator (Spring Boot) oder /elmah.axd (ASP.NET) können detaillierte Informationen über laufende Prozesse, aktive Verbindungen und Systemkonfigurationen preisgeben, wenn sie nicht zugriffsbeschränkt sind.

Angriffsszenario

Der folgende Abschnitt zeigt, wie ein Angreifer grundlegende Fehlkonfigurationen eines Webservers ausnutzen kann, um Zugriff auf sensible Daten und Systeme zu erlangen.

Durch einen externen Netzwerkscan wurde eine öffentlich erreichbare Webapplikation unter demo.lab.local gefunden. Dabei wurde die verwendete Software vom Server preisgegeben:

HTTP/1.1 200 OK
Server: Apache/2.4.51 (Ubuntu)
X-Powered-By: PHP/8.1.2

Anschließend kann mithilfe von Gobuster1 nach bekannten Dateien und Verzeichnissen auf dem Webserver gesucht werden. Dabei wurden mehrere interessante Pfade gefunden:

gobuster dir -u http://demo.lab.local -w /usr/share/wordlists/dirb/common.txt
/admin                (Status: 301)
/backup               (Status: 200)
/phpmyadmin           (Status: 200)
/.git                 (Status: 301)

Da das Verzeichnis /backup Directory Listing aktiviert hatte, konnten die darin gespeicherten Dateien ausgelesen werden: Aktiviertes Directory Listing

Nach dem Herunterladen und Entpacken der Datei database_backup.sql.gz wurden darin gespeicherte Datenbank-Zugangsdaten gefunden: Ausgelesene SQL-Konfiguration

Mit diesen Zugangsdaten konnte eine Verbindung auf die Produktionsdatenbank hergestellt werden, sodass diese eingesehen, verändert und exportiert wurde.

Gegenmaßnahmen

Um die Sicherheit von Webservern nachhaltig zu verbessern, sollten die folgenden Maßnahmen umgesetzt werden.

Directory Listing deaktivieren

Directory Listing muss auf allen Webservern deaktiviert werden. Die Konfiguration hierfür unterscheidet sich je nach eingesetztem Webserver:

  • Apache: In der Konfigurationsdatei oder .htaccess die Option Options -Indexes setzen.
  • Nginx: Die Direktive autoindex off; in der Serverkonfiguration sicherstellen (dies ist die Standardeinstellung).
  • IIS: Im IIS-Manager unter dem jeweiligen Verzeichnis die Option Directory Browsing deaktivieren.

Zusätzlich sollte in jedem öffentlich erreichbaren Verzeichnis eine Indexdatei vorhanden sein, die entweder eine sinnvolle Seite oder einen HTTP-Fehlercode (z.B. 403 Forbidden) zurückgibt.

Backup- und Konfigurationsdateien entfernen

Auf öffentlich zugänglichen Webservern dürfen sich keine Backup-, Konfigurations- oder andere sensible Dateien befinden. Folgende Maßnahmen sollten umgesetzt werden:

  • Vor der Inbetriebnahme und nach jeder Wartung müssen alle temporären und nicht benötigten Dateien entfernt werden.
  • Automatisierte Scans mit Tools wie Nikto8 oder Nuclei7 sollten regelmäßig durchgeführt werden, um vergessene Dateien aufzuspüren.
  • Versionskontrollverzeichnisse (.git, .svn) dürfen niemals auf einem Produktionsserver vorhanden sein oder müssen über die Webserver-Konfiguration blockiert werden.
  • Sensible Konfigurationsdateien (.env, Datenbankverbindungen) sollten außerhalb des Document Root des Webservers gespeichert werden.
  • Deployment-Prozesse sollten so gestaltet sein, dass nur die für den Betrieb notwendigen Dateien auf den Webserver übertragen werden.

Standardpasswörter ändern

Sämtliche Standardpasswörter müssen vor der Inbetriebnahme geändert werden:

  • Bei der Installation von Webapplikationen, CMS, Datenbanken und Administrationsoberflächen müssen eindeutige, starke Passwörter vergeben werden.
  • Nicht benötigte Standardkonten (z.B. admin, test, guest) sollten deaktiviert oder gelöscht werden.
  • Administrationsoberflächen wie phpMyAdmin, Adminer oder Webmin sollten nicht öffentlich erreichbar sein und idealerweise hinter einem VPN oder einer IP-basierten Zugriffsbeschränkung liegen.
  • Regelmäßige Überprüfungen der eingesetzten Dienste auf bekannte Standardzugangsdaten sollten in den operativen Betrieb integriert werden.

Offenlegung interner Informationen verhindern

Die Preisgabe interner Informationen über HTTP-Header, Fehlermeldungen und Statusseiten muss unterbunden werden:

  • Server-Header minimieren: Die Konfiguration des Webservers sollte so angepasst werden, dass keine detaillierten Versionsinformationen ausgegeben werden. Bei Apache kann dies mit ServerTokens Prod und ServerSignature Off erreicht werden, bei Nginx mit server_tokens off;.
  • Debug-Modus deaktivieren: Produktionssysteme dürfen niemals im Debug-Modus betrieben werden. Fehlermeldungen sollten generisch gehalten und detaillierte Informationen ausschließlich in serverseitige Logdateien geschrieben werden.
  • Statusseiten absichern: Endpunkte wie /server-status, /server-info, /actuator oder Debugging-Seiten müssen deaktiviert oder durch Authentifizierung und IP-basierte Zugriffsbeschränkungen geschützt werden.
  • HTTP-Header bereinigen: Header wie X-Powered-By sollten entfernt werden. Gleichzeitig sollten sicherheitsrelevante Header wie X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security und Content-Security-Policy konfiguriert werden.
  • Reverse-Proxy-Konfiguration prüfen: Bei Einsatz eines Reverse Proxys muss sichergestellt werden, dass keine internen IP-Adressen oder Hostnamen in Headern oder Weiterleitungen nach außen gelangen.

Regelmäßige Überprüfung

Die beschriebenen Maßnahmen sollten nicht nur einmalig umgesetzt, sondern regelmäßig überprüft werden:

  • Automatisierte Vulnerability-Scanner sollten regelmäßig gegen die eigenen Webserver ausgeführt werden.
  • Die öffentliche Angriffsfläche sollte überwacht werden.
  • Penetration Tests sollten regelmäßig durchgeführt werden, um Fehlkonfigurationen und Schwachstellen frühzeitig zu erkennen.