In der digitalen Welt, wo Angriffe auf Webserver alltäglich sind, ist jede noch so kleine Information, die Sie über Ihre Infrastruktur preisgeben, ein potenzielles Einfallstor für Cyberkriminelle. Eine der häufig übersehenen Stellen, an denen Informationen ungewollt preisgegeben werden, ist der HTTP-Header – genauer gesagt, die Angabe der Webserver-Software und ihrer Version. Was auf den ersten Blick harmlos erscheinen mag, kann in den falschen Händen zu einem ernsthaften Sicherheitsrisiko werden. In diesem umfassenden Artikel erfahren Sie, warum die Offenlegung der Webserver-Version ein Problem darstellt und welche konkreten Schritte Sie unternehmen können, um diese Informationen zu verbergen.
Warum ist die Offenlegung der Webserver-Version ein Risiko?
Stellen Sie sich vor, ein Einbrecher möchte in ein Haus eindringen. Wenn er weiß, welches Schlosssystem verwendet wird, kann er gezielt nach Schwachstellen suchen oder sich das passende Werkzeug besorgen. Ähnlich verhält es sich mit Webservern. Wenn Ihre Webserver-Software (z.B. Apache, Nginx, IIS) und deren genaue Versionsnummer im HTTP-Header angezeigt werden, liefern Sie Angreifern wertvolle Informationen. Dies wird als Informationslecks (Information Disclosure) bezeichnet.
Der Hauptgrund für diese Gefahr liegt in der Existenz bekannter Schwachstellen. Software ist nie fehlerfrei, und regelmäßige Sicherheitsupdates sind notwendig, um entdeckte Lücken zu schließen. Angreifer unterhalten Datenbanken mit Schwachstellen (z.B. CVE-Datenbanken – Common Vulnerabilities and Exposures), die spezifische Softwareversionen betreffen. Wenn ein Angreifer weiß, dass Sie beispielsweise Apache 2.4.41 verwenden und diese Version eine bekannte, öffentlich dokumentierte Sicherheitslücke aufweist, kann er gezielt nach Exploits suchen, um diese Lücke auszunutzen. Dies kann von der Ausführung von Code über das Stehlen von Daten bis hin zur vollständigen Übernahme Ihres Servers reichen.
Selbst wenn Ihre Software auf dem neuesten Stand ist, wissen Sie nie, wann eine sogenannte Zero-Day-Schwachstelle entdeckt und veröffentlicht wird. Wenn Ihre Version dann für jedermann sichtbar ist, gehören Sie möglicherweise zu den ersten Zielen für automatisierte Angriffe, die diese neue Lücke ausnutzen. Die Offenlegung der Version erleichtert also das Scannen und Kategorisieren potenzieller Ziele für automatisierte Bots und Scans. Das Verbergen dieser Information ist zwar keine unüberwindbare Barriere, aber es erhöht den Aufwand für den Angreifer erheblich und macht Ihren Server weniger attraktiv als ein leicht zu identifizierendes Ziel.
Es geht also nicht darum, Sicherheit durch Verschleierung („Security by Obscurity”) zu erreichen – ein Konzept, das oft kritisiert wird, weil es keine echte Sicherheit bietet. Vielmehr geht es darum, die Angriffsfläche zu minimieren. Jedes Detail, das Sie einem potenziellen Angreifer vorenthalten können, zwingt ihn zu mehr Aufwand, um Informationen zu sammeln (Reconnaissance). Dies kann dazu führen, dass Ihr Server als zu „schwierig” eingestuft und stattdessen ein leichteres Ziel gewählt wird.
Wo tauchen diese Informationen auf? Den HTTP-Header verstehen
Wenn Ihr Browser eine Webseite anfordert, sendet der Webserver eine Antwort, die aus einem HTTP-Statuscode und verschiedenen Headern besteht, gefolgt vom eigentlichen Inhalt der Webseite. Einer dieser Header ist der `Server`-Header, der typischerweise Informationen über die verwendete Webserver-Software und ihre Version enthält. Beispiele hierfür sind `Server: Apache/2.4.56 (Unix)` oder `Server: nginx/1.22.1`. Auch andere Header können Hinweise geben, wie z.B. `X-Powered-By` (oft für PHP, ASP.NET oder andere Frameworks) oder `X-AspNet-Version`.
Sie können diese Informationen ganz einfach selbst überprüfen:
- Browser-Entwicklertools: Öffnen Sie in Ihrem Browser die Entwicklertools (meist F12 oder Rechtsklick > Untersuchen), wechseln Sie zum Tab „Netzwerk” oder „Network”, laden Sie die Seite neu, klicken Sie auf die Hauptanfrage (oft der Domainname) und schauen Sie sich die „Antwort-Header” (Response Headers) an.
- `curl`-Befehl (Kommandozeile): Geben Sie im Terminal oder der Eingabeaufforderung ein: `curl -I https://ihredomain.de`. Das `-I` (Großbuchstabe i) bewirkt, dass nur die Header ausgegeben werden.
- Online-Header-Checker: Es gibt zahlreiche Webseiten, die Ihnen nach Eingabe einer URL die HTTP-Header anzeigen.
Praktische Schritte zum Verbergen der Server-Version
Die Methoden zur Unterdrückung der Versionsinformationen variieren je nach verwendetem Webserver. Hier sind die Anleitungen für die gängigsten Server:
1. Apache HTTP Server
Apache ist einer der am weitesten verbreiteten Webserver. Die Offenlegung der Version kann hier über zwei wichtige Direktiven in Ihrer Konfigurationsdatei gesteuert werden: `ServerTokens` und `ServerSignature`.
`ServerTokens`-Direktive
Diese Direktive steuert, was der `Server`-Antwort-Header sendet. Sie kann in der Hauptkonfigurationsdatei (`httpd.conf` oder in einer enthaltenen Konfigurationsdatei wie `apache2.conf` oder `000-default.conf` unter Debian/Ubuntu) gesetzt werden. Die verfügbaren Optionen sind:
- `Full` (Standard): Sendet „Apache/2.4.56 (Unix) OpenSSL/1.1.1u mod_fcgid/2.3.9” (sehr detailliert).
- `OS`: Sendet „Apache/2.4.56 (Unix)”.
- `Min`: Sendet „Apache/2.4.56”.
- `Minor`: Sendet „Apache/2.4”.
- `Major`: Sendet „Apache/2”.
- `ProductOnly`: Sendet nur „Apache”. Dies ist die empfohlene Einstellung für maximale Sicherheit.
Um die Versionsinformation zu minimieren, suchen Sie die Zeile `ServerTokens` in Ihrer Konfigurationsdatei und ändern Sie sie auf:
ServerTokens ProductOnly`ServerSignature`-Direktive
Diese Direktive steuert, ob der Server auf automatisch generierten Seiten (z.B. Fehlerseiten, Verzeichnislisten) eine Fußzeile mit der Server-Version und dem Hostnamen hinzufügt. Standardmäßig ist dies oft auf `On` oder `EMail` gesetzt.
Um dies zu deaktivieren, ändern Sie die Zeile `ServerSignature` auf:
ServerSignature OffZusammenfassung für Apache
Suchen Sie in Ihrer `httpd.conf` oder einer ähnlichen globalen Konfigurationsdatei (oft unter `/etc/apache2/apache2.conf` oder `/etc/httpd/conf/httpd.conf`) nach diesen Direktiven und ändern Sie sie wie folgt:
ServerTokens ProductOnly
ServerSignature OffNachdem Sie die Änderungen vorgenommen haben, müssen Sie den Apache-Dienst neu starten, damit die Änderungen wirksam werden:
sudo systemctl restart apache2 # oder sudo service apache2 restart
# Für CentOS/RHEL: sudo systemctl restart httpdStellen Sie sicher, dass diese Änderungen nicht durch andere Konfigurationsdateien (z.B. in `conf.d/` oder `sites-enabled/`) überschrieben werden.
2. Nginx
Nginx ist bekannt für seine hohe Leistung und Effizienz. Das Verbergen der Version ist hier noch einfacher als bei Apache.
`server_tokens`-Direktive
Die `server_tokens`-Direktive steuert die Ausgabe der Nginx-Version in den Fehlermeldungen und im `Server`-Header. Sie kann im `http`, `server` oder `location` Kontext der `nginx.conf`-Datei gesetzt werden.
Um die Versionsinformation zu entfernen, fügen Sie die folgende Zeile hinzu oder ändern Sie sie auf:
server_tokens off;Die empfohlene Stelle hierfür ist der `http`-Block, da dies global für alle Server in Ihrer Nginx-Konfiguration gilt. Zum Beispiel:
http {
server_tokens off;
# ... weitere Konfiguration ...
}Nachdem Sie die Änderung vorgenommen haben, testen Sie die Konfiguration und laden Sie Nginx neu:
sudo nginx -t
sudo systemctl reload nginx # oder sudo service nginx reloadBeachten Sie, dass selbst mit `server_tokens off` Nginx immer noch „nginx” im `Server`-Header senden wird, aber ohne Versionsnummer. Eine vollständige Entfernung des „nginx”-Strings aus dem Header ist nur durch das Neukompilieren von Nginx mit bestimmten Kompilierungsoptionen möglich, was für die meisten Anwendungsfälle übertrieben und unnötig ist.
3. Microsoft IIS (Internet Information Services)
Für Microsoft IIS-Server gibt es mehrere Stellen, an denen Versionsinformationen offengelegt werden können, insbesondere der `Server`-Header und der `X-Powered-By`-Header.
Entfernen des `Server`-Headers
IIS bietet standardmäßig keine direkte Konfigurationsoption, um den `Server`-Header zu entfernen oder zu ändern. Dies erfordert in der Regel die Verwendung des URL Rewrite Module oder eines Drittanbieter-Moduls. Wenn Sie das URL Rewrite Module installiert haben (es ist ein separates Feature, das Sie hinzufügen müssen), können Sie eine Ausgangsregel erstellen, um den Header zu entfernen:
- Öffnen Sie den IIS Manager.
- Wählen Sie den Server im linken Bereich aus.
- Doppelklicken Sie im Bereich „IIS” auf „URL Rewrite”.
- Klicken Sie im rechten Bereich auf „Add Rule(s)…” und wählen Sie „Blank Rule” unter „Outbound Rules” aus.
- Geben Sie einen Namen für die Regel ein (z.B. „Remove Server Header”).
- Im Abschnitt „Matching Scope” wählen Sie „Server Variable” aus.
- Setzen Sie „Variable name” auf `RESPONSE_SERVER`.
- Setzen Sie „Variable value” auf `.*` (Regulärer Ausdruck für beliebigen Inhalt).
- Im Abschnitt „Actions” wählen Sie „Rewrite” oder „Custom Action” aus. Bei „Action type” wählen Sie „Rewrite”.
- Setzen Sie „Value” auf einen leeren String oder einen Platzhalter wie „Web Server”.
- Bestätigen Sie die Regel.
Alternativ können Sie die `web.config` Datei Ihrer Webanwendung bearbeiten:
<configuration>
<system.webServer>
<outboundRules>
<rule name="Remove Server Header">
<match serverVariable="RESPONSE_Server" pattern=".*" />
<action type="Rewrite" value="" />
</rule>
</outboundRules>
</system.webServer>
</configuration>Beachten Sie, dass das URL Rewrite Module nicht nur dazu dient, URLs umzuschreiben, sondern auch HTTP-Header zu manipulieren.
Entfernen von `X-Powered-By` und `X-AspNet-Version`
Diese Header geben Aufschluss über die verwendete Anwendungstechnologie (ASP.NET, PHP, etc.) und deren Version. Sie können diese über den IIS Manager oder die `web.config` entfernen.
Via IIS Manager:
- Wählen Sie den Server oder die Website aus.
- Doppelklicken Sie im Bereich „Verwaltung” auf „HTTP Response Headers”.
- Im rechten Bereich können Sie vorhandene Header auswählen und entfernen oder neue hinzufügen. Der `X-Powered-By`-Header kann hier entfernt werden.
- Für `X-AspNet-Version`: Wechseln Sie zu den „Application Pools”, wählen Sie Ihren Anwendungspool aus, klicken Sie auf „Advanced Settings…” und setzen Sie „Enable 32-bit Applications” und „Managed Pipeline Mode” auf die gewünschten Werte. Die `X-AspNet-Version` wird oft durch das ASP.NET Framework selbst hinzugefügt.
Via `web.config`:
Um den `X-Powered-By`-Header zu entfernen:
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<remove name="X-Powered-By" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>Um den `X-AspNet-Version`-Header zu unterdrücken, ist eine Änderung im `
<configuration>
<system.web>
<httpRuntime enableVersionHeader="false" />
</system.web>
</configuration>Nach diesen Änderungen müssen Sie in der Regel keinen vollständigen Neustart des IIS-Dienstes durchführen, da IIS Änderungen an der `web.config` automatisch erkennt und die Konfiguration neu lädt. Dennoch kann ein `iisreset` im Falle von Problemen hilfreich sein.
Weitere Header und allgemeine Best Practices
Neben den Haupt-Webserver-Headern gibt es noch andere, die Informationen preisgeben können:
- PHP: Wenn Sie PHP verwenden, kann der `X-Powered-By: PHP/X.Y.Z`-Header angezeigt werden. Um dies zu verhindern, öffnen Sie Ihre `php.ini`-Datei und suchen Sie die Direktive `expose_php`. Setzen Sie diese auf `Off`:
expose_php = OffNach der Änderung müssen Sie den Webserver-Dienst (Apache, Nginx, PHP-FPM) neu starten.
- Content Management Systeme (CMS) und Frameworks: Einige CMS wie WordPress oder Drupal, oder Frameworks wie Laravel oder Symfony, können ebenfalls eigene Header hinzufügen. Prüfen Sie deren Dokumentation, wie Sie diese deaktivieren können. Oft gibt es Konfigurationsoptionen oder Plugins dafür.
- Reverse Proxies und Load Balancer: Wenn Sie einen Reverse Proxy (wie Cloudflare, Akamai, Varnish, HAProxy) oder einen Load Balancer vor Ihrem Webserver haben, ist es entscheidend zu prüfen, welche Header dieser weiterleitet oder selbst hinzufügt. Viele dieser Dienste bieten Optionen zur Manipulation von Headern an, sodass Sie die Kontrolle über die ausgehenden Informationen behalten. Cloudflare beispielsweise maskiert den `Server`-Header standardmäßig, wenn Sie ihren Dienst nutzen.
- Web Application Firewalls (WAFs): Eine WAF kann oft so konfiguriert werden, dass sie bestimmte Header blockiert oder umschreibt, bevor sie den Endbenutzer erreichen. Dies kann eine zusätzliche Sicherheitsebene bieten.
Potenzielle Auswirkungen und Dinge, die man beachten sollte
Das Verbergen der Webserver-Version hat in den meisten Fällen keine negativen Auswirkungen auf die Funktionalität Ihrer Webseite oder Anwendung. Es ist eine reine Sicherheitsmaßnahme, die die Informationslecks minimiert.
Es gibt jedoch einige seltene Ausnahmen:
- Drittanbieter-Tools: Einige sehr spezifische Monitoring-Tools oder Integrationslösungen könnten darauf angewiesen sein, die Webserver-Version zu erkennen. Dies ist jedoch äußerst selten und sollte in der Dokumentation des Tools vermerkt sein.
- Debugging: Für Entwickler und Administratoren kann die sichtbare Version beim Debugging hilfreich sein. Intern (z.B. in Server-Logs oder lokalen Tests) bleibt die Version natürlich sichtbar und relevant. Die Änderung betrifft nur die extern sichtbaren Header.
- Es ist keine Allheillösung: Das Verbergen der Version ist eine von vielen wichtigen Sicherheitsmaßnahmen, aber kein Ersatz für regelmäßige Updates, starke Passwörter, eine gut konfigurierte Firewall oder die Implementierung weiterer Sicherheitsprotokolle wie HSTS oder Content Security Policy. Ein Angreifer könnte andere Wege finden, um die Server-Software zu identifizieren, beispielsweise durch das Ausnutzen bekannter Fehlerbilder bei bestimmten Versionen oder durch detaillierte Schwachstellen-Scanner, die über bloße Header-Informationen hinausgehen.
Betrachten Sie diese Maßnahme als Teil einer umfassenden Defense-in-Depth-Strategie. Jede kleine Hürde, die Sie einem Angreifer in den Weg legen, erhöht die Sicherheit Ihres Systems.
Fazit
Die Offenlegung der Webserver-Version im HTTP-Header ist ein vermeidbares Sicherheitsrisiko, das Angreifern wertvolle Informationen liefert. Durch das Anwenden der oben beschriebenen Konfigurationen für Apache, Nginx oder IIS sowie weiterer Frameworks können Sie diese Informationen verbergen und Ihre Angriffsfläche erheblich reduzieren. Dieser Schritt ist relativ einfach umzusetzen und erfordert kaum Aufwand, bietet aber einen spürbaren Zugewinn an Sicherheit.
Denken Sie daran: Sicherheit ist ein kontinuierlicher Prozess. Das Verbergen von Versionen ist ein wichtiger Baustein, aber es ist entscheidend, dass Sie Ihre Webserver-Software und alle darauf laufenden Anwendungen stets auf dem neuesten Stand halten, regelmäßige Sicherheitsaudits durchführen und einen mehrschichtigen Ansatz zur Absicherung Ihrer Infrastruktur verfolgen. Indem Sie proaktiv handeln und selbst die kleinsten Informationslecks schließen, schützen Sie Ihre Webseite und Ihre Daten effektiv vor potenziellen Bedrohungen. Nehmen Sie Ihre digitale Sicherheit ernst – Ihre Nutzer und Ihre Daten werden es Ihnen danken!