Versionsbanner abschalten: Was Ihre Header verraten

Was in einem Versionsbanner tatsächlich steht

Der Begriff stammt aus der Netzwerkdiagnose: Ein Dienst meldet beim ersten Kontakt, wer er ist. Im Web steht diese Selbstauskunft in den Antwort-Headern. Der Testleitfaden der OWASP beschreibt das Einsammeln als Banner Grabbing und hält den Aufwand knapp: Es wird eine HTTP-Anfrage an den Webserver geschickt und dessen Antwort-Header betrachtet (OWASP Testing Guide). Kein Konto, kein Werkzeug mit Sonderrechten, keine ausgenutzte Schwachstelle - eine Anfrage genügt, und die Auskunft kommt aus der öffentlichen Seite selbst. Genau darum steht der Punkt in Prüfkatalogen weit vorn: Er kostet den Prüfer eine Sekunde und den Betreiber unter Umständen die Vorauswahl, mit der ein Angriff überhaupt erst beginnt.

• Server: Produktname, häufig die genaue Fassung, teils die Distribution und die geladenen Zusatzmodule.
• X-Powered-By: die Laufzeitumgebung hinter der Anwendung, in aller Regel mit Versionsnummer.
• X-AspNet-Version und X-AspNetMvc-Version: die Fassung des Anwendungsrahmens, unabhängig vom Webserver davor.
• X-Server und X-Backend-Server: interne Rechnernamen, die das Namensschema der eigenen Umgebung offenlegen.
• Via und X-Cache: vorgelagerte Zwischenstationen samt Produkt - sichtbar auch dann, wenn der Ursprungsserver schweigt.
• Fehlerseiten: die Standardseite eines Webservers nennt Produkt und Fassung in der Fußzeile, auch wenn der Header längst gekürzt ist.

In der Schwachstellensystematik hat der Befund eine eigene Klasse. CWE-200 beschreibt den Fall, dass ein Produkt schützenswerte Informationen an einen Akteur weitergibt, der zum Zugriff darauf nicht ausdrücklich berechtigt ist (MITRE CWE). Zu den dort aufgeführten Informationsarten gehört der Systemzustand samt Betriebssystem und installierten Paketen - also genau das, was ein Versionsbanner ohne Umweg liefert. Die Einordnung ist bewusst weit gefasst: Sie beschreibt keine ausnutzbare Lücke, sondern deren Vorstufe. Für die Bewertung im eigenen Haus ist das ein nützlicher Unterschied, weil er festlegt, mit welcher Dringlichkeit der Punkt behandelt wird.

Wie verbreitet die Preisgabe im Netz ist

Der Web Almanac wertet die Antworten von Millionen Hosts aus und verfolgt die Informations-Header über mehrere Jahrgänge. Für 2025 gilt: Diese Header erscheinen auf 91,5 Prozent und 23,9 Prozent der Hosts im Netz (Web Almanac 2025) - gemeint sind Server und X-Powered-By. Über drei Jahrgänge hinweg zeigt die Kurve leicht nach unten, doch die Bewegung ist klein. Der Bericht nennt auch den Grund: Viele Web-Techniken setzen einige dieser Kopfzeilen von sich aus, und der Sicherheitsgewinn beim Entfernen erscheint gering (Web Almanac 2025). Die folgende Übersicht ordnet die Felder danach, was sie über den Aufbau dahinter verraten.

Interessant wird es bei den Werten selbst. Unter den X-Powered-By-Angaben mit konkreter Fassung steht PHP/7.4.33 an der Spitze: 9,54 Prozent auf dem Desktop und 9,98 Prozent auf Mobilgeräten (Web Almanac 2025). Über beide Messreihen hinweg tragen mehr als 27 Prozent der X-Powered-By-Header eine Versionsangabe (Web Almanac 2025). Der Zweig 7.4 wird seit dem 28. November 2022 nicht mehr gepflegt, 7.4.33 war seine letzte Freigabe (PHP-Handbuch). Wer diese Zeichenkette in einer Antwort liest, kennt damit nicht nur das Produkt, sondern auch den Umstand, dass für diesen Zweig seit Jahren keine Sicherheitsfreigabe mehr erschienen ist. Das Handbuch selbst rät dringend zum Wechsel auf eine aktuelle Fassung, weil ältere Fassungen für Schwachstellen und Fehler offen bleiben, die inzwischen behoben sind (PHP-Handbuch).

Warum eine Versionsangabe Suchläufe anzieht

Der Web Almanac begründet die Messung mit einem Satz, der die Wirkungskette gut trifft: Wenn Websites zu viele Informationen über ihre Infrastruktur veröffentlichen, etwa den Server und dessen genaue Fassung, laufen sie ein höheres Risiko, zum Ziel automatischer Schwachstellenscanner zu werden (Web Almanac 2025). Dem steht die nüchterne Einordnung der Serverdokumentation gegenüber, nach der das Abschalten des Server-Headers überhaupt nichts dazu beiträgt, den Server sicherer zu machen (Apache HTTP Server). Beides zusammen ergibt die realistische Erwartung: Der Nutzen liegt in der Vorauswahl, nicht im Schutz. Vier Mechanismen erklären, warum die Vorauswahl trotzdem zählt.

Die Zahlen hinter der Kategorie sind deutlich: In der Auswertung zu Security Misconfiguration wiesen alle getesteten Anwendungen eine Form von Fehlkonfiguration auf, bei einer durchschnittlichen Häufigkeitsrate von 3,00 Prozent (OWASP). Eine Versionsangabe im Header ist dabei der harmloseste Vertreter dieser Familie - und zugleich der sichtbarste, weil er ohne Anmeldung von außen ablesbar ist. Wer die OWASP Top 10:2025 im Überblick durchgeht, findet die Kategorie unmittelbar hinter dem Zugriffsschutz und damit an einer Stelle, die in Prüfberichten selten überlesen wird.

Was die Norm sagt - und was sie nicht verspricht

Der Server-Header ist in RFC 9110 beschrieben, der Norm für die Semantik von HTTP. Dort steht keine Aufforderung, ihn wegzulassen, wohl aber eine, ihn kurz zu halten: Ein Ursprungsserver soll keinen Server-Header erzeugen, der unnötig feingliedrige Angaben enthält, und die Aufnahme von Teilprodukten Dritter begrenzen (RFC 9110). Die Begründung folgt im selben Abschnitt: Überlange und detaillierte Werte des Server-Feldes erhöhen die Antwortzeit und geben unter Umständen interne Umsetzungsdetails preis, die es Angreifern geringfügig leichter machen können, bekannte Sicherheitslücken zu finden und auszunutzen (RFC 9110). Die Norm zieht damit eine Linie zwischen Auskunft und Preisgabe - und legt sie bei der Fassungsnummer an.

Theoretisch kann das einem Angreifer die Ausnutzung bekannter Sicherheitslücken erleichtern; in der Praxis probieren Angreifer alle in Frage kommenden Lücken durch, unabhängig von den scheinbar eingesetzten Softwarefassungen.

— RFC 9110, Abschnitt 17.12, sinngemäß übersetzt

Der zweite Teil ist der wichtigere, weil er die Erwartung ordnet. Die Dokumentation des Apache HTTP Server wird an derselben Stelle noch direkter: Das Abschalten des Server-Headers trage überhaupt nichts dazu bei, den Server sicherer zu machen (Apache HTTP Server). Beide Aussagen widersprechen der Empfehlung nicht, das Banner zu kürzen - sie ordnen ihren Wert ein. Das BSI formuliert die Anforderung für den Webserver dennoch eng und ohne Einschränkung: Aus den HTTP-Informationen und den angezeigten Fehlermeldungen sollten weder der Produktname noch die verwendete Fassung des Webservers ersichtlich sein (BSI). Zwischen beiden Polen liegt die praktische Antwort: kürzen, weil es wenig kostet, und aktualisieren, weil nur das die Angriffsfläche verkleinert.

Die Stellschrauben je Schicht

Die Voreinstellungen sprechen für sich. Beim Apache HTTP Server lautet die Vorgabe für die Direktive ServerTokens schlicht Full (Apache HTTP Server) - die Antwort nennt dann Produkt, Fassung, Betriebssystemtyp und einkompilierte Module in einer Zeile. Bei nginx ist server_tokens auf on voreingestellt (nginx); die Direktive steuert, ob die nginx-Fassung auf Fehlerseiten und im Server-Antwortheader ausgegeben wird (nginx). Und PHP setzt expose_php in der Vorgabe auf 1, womit der Welt mitgeteilt wird, dass PHP auf dem Server installiert ist, einschließlich der PHP-Fassung im HTTP-Header (PHP-Handbuch). Drei Voreinstellungen, drei Zeilen in der Antwort - ohne dass jemand sie eingerichtet hätte.

Die Reihenfolge beim Umstellen ist nicht beliebig. Ein vorgelagerter Dienst kann Kopfzeilen ergänzen, überschreiben oder unverändert durchreichen; wer nur den Ursprungsserver anfasst, sieht am Ende womöglich dieselbe Antwort wie zuvor. Deshalb gilt der einfache Grundsatz: von außen messen, nicht in der Konfigurationsdatei nachlesen. Die Antwort an der öffentlichen Adresse ist die einzige Instanz, die zählt, und sie weicht regelmäßig von dem ab, was im Repository steht. Drei Aufrufe genügen für die Gegenprobe - einer vor der Umstellung, einer auf eine nicht vorhandene Adresse und einer danach.

Zwei Punkte werden dabei häufig übersehen. Erstens die Fehlerseiten: Die Standardseite eines Webservers nennt das Produkt in der Fußzeile, auch wenn der Header bereits gekürzt ist. Beim Apache HTTP Server schaltet ServerSignature diese Zeile, bei nginx wirkt server_tokens auf Header und Fehlerseiten zugleich (nginx). Zweitens die selten aufgerufenen Antwortarten: Umleitungen, Statuscode 404 und Statuscode 500 stammen oft aus einer anderen Ebene als die Startseite und bleiben beim Umstellen unberührt. Beides gehört in dieselbe Prüfung wie der Header - und ergänzt die Übersicht der Sicherheits-Header, die die Gegenrichtung behandelt: was eine Antwort zusätzlich enthalten sollte.

Was nach dem Abschalten sichtbar bleibt

Ein leerer Server-Header macht eine Umgebung nicht unkenntlich. Der Testleitfaden nennt den einfachsten Restweg: Ist die Serverangabe verdeckt, lässt sich der Typ des Servers anhand der Reihenfolge der Kopfzeilen erraten (OWASP Testing Guide). Daneben bleiben zahlreiche Eigenheiten, die kein Schalter abstellt, weil sie aus der Umsetzung selbst stammen und nicht aus einer Konfigurationszeile.

• Reihenfolge und Schreibweise der Kopfzeilen unterscheiden sich je Produkt und bleiben erhalten, auch wenn die Werte selbst nichts mehr verraten.
• Aufbau der Fehlerseiten, Wortlaut der Statusmeldungen und die Behandlung ungewöhnlicher Anfragen sind produktspezifisch und schwer zu vereinheitlichen.
• Namen und Aufbau der Sitzungscookies deuten auf die Laufzeitumgebung; welche Eigenschaften dort ohnehin gesetzt gehören, behandelt der Beitrag zu sicheren Sitzungscookies.
• Format der ETag-Werte und die Behandlung bedingter Anfragen folgen der Umsetzung des jeweiligen Servers und lassen sich zuordnen.
• Verhalten bei HTTP/2 und HTTP/3 sowie die Reihenfolge der angebotenen Verschlüsselungsverfahren im TLS-Handschlag bilden ein weiteres Erkennungsmerkmal.
• Offene Dienste jenseits des Webservers melden ihre eigene Kennung; welche das sind, zeigt eine Bestandsaufnahme der nach außen erreichbaren Dienste.

Warum das Banner zurückkommt

Das Abschalten ist eine Arbeit von Minuten. Das Abgeschaltet-Bleiben ist ein Zustand, der gehalten werden muss. In der Praxis kehrt die Zeile aus sechs wiederkehrenden Gründen zurück, und in fast allen Fällen bemerkt es niemand, weil die Seite weiter funktioniert. Genau das macht den Punkt zu einem Fall für die wiederkehrende Prüfung und nicht für die Übergabeliste eines Projekts.

1. Paketaktualisierung mit neuer Standardkonfiguration: Das Update legt eine unveränderte Konfigurationsdatei daneben oder ersetzt sie. Die eigene Anpassung landet als Sicherungskopie im Verzeichnis und wird nicht mehr gelesen.
2. Ein zusätzlicher Dienst davor: Ein neuer Zwischenspeicher oder eine neue Ausgleichsschicht setzt eigene Kopfzeilen und trägt Via oder X-Cache in die Antwort ein, obwohl der Ursprungsserver längst schweigt.
3. Ein zweiter virtueller Host: Die Anpassung wurde im Hauptbereich gesetzt, der neue Auftritt erbt sie nicht. Ergebnis sind zwei Adressen desselben Hauses mit zwei verschiedenen Antworten.
4. Neues Abbild, alte Vorgabe: Ein Neubau des Containers zieht das Grundabbild frisch und beginnt wieder bei der Voreinstellung, wenn die Anpassung nicht im Bauplan steht.
5. Rahmenwechsel bringt neue Kopfzeilen: Ein Sprung auf die nächste Fassung eines Anwendungsrahmens fügt Felder hinzu, die es zuvor nicht gab. Wie schnell sich Fassungen heute ablösen, zeigt der Beitrag zu zweiwöchigen Freigabezyklen.
6. Rücksprung nach einer Störung: Wird nach einem Zwischenfall ein älterer Stand eingespielt, kommt die alte Konfiguration mit - und mit ihr die alte Signatur.

Die Header-Prüfung in die laufende Überwachung nehmen

Ein Punkt, der ohne Vorwarnung zurückkehrt und dabei keine sichtbare Störung verursacht, ist der Musterfall für eine wiederkehrende Messung. Die Prüfung selbst ist billig: eine Anfrage je Adresse, ein Abgleich mit dem zuletzt bekannten Stand, eine Meldung bei Abweichung. Teuer ist nur, sie von Hand zu wiederholen. Sechs Schritte machen daraus eine belastbare Routine.

1. Bestand festhalten: Notieren Sie je Adresse den heutigen Wert von Server, X-Powered-By, X-AspNet-Version, Via und den eigenen Rahmen-Kopfzeilen. Ohne Ausgangswert gibt es später keine Abweichung, sondern nur eine Momentaufnahme.
2. Alle Adressen erfassen, nicht nur die Startseite: Nebendomains, Weiterleitungsziele, Bilddienste und Formularannahmen antworten oft aus einer anderen Ebene. Wie sich diese Lücke systematisch schließen lässt, beschreibt der Beitrag zur Abdeckung des URL-Bestands.
3. Antwortarten mitprüfen: Neben Statuscode 200 gehören Umleitung, Statuscode 404 und Statuscode 500 in den Prüflauf, weil dort andere Ebenen antworten.
4. Schwelle festlegen: Definieren Sie, welche Änderung eine Meldung auslöst - eine neu erscheinende Fassungsnummer sollte es, ein geänderter Zwischenspeicher-Treffer nicht.
5. Meldeweg für Hinweise von außen einrichten: Wer eine Preisgabe entdeckt, braucht eine Adresse dafür. Der Beitrag zu security.txt und Meldewegen beschreibt den kurzen Weg dorthin.
6. Befund in die regelmäßige Auswertung geben: Ein wiederkehrender Sicherheitsscan hält den Header-Zustand neben Zertifikatslaufzeit, Erreichbarkeit und Inhaltsänderung fest, sodass Abweichungen im gleichen Bericht auftauchen.

Der Aufwand für diese Routine ist gering, der Nutzen liegt im Nebeneffekt: Wer die Antwort-Header laufend erfasst, bemerkt auch den Wechsel einer Laufzeitumgebung, die stillschweigende Einführung eines vorgelagerten Dienstes und die Rückkehr eines Standes nach einer Störung. Aus einer Sicherheitsmaßnahme wird damit ein Fenster auf den tatsächlichen Aufbau der eigenen Umgebung. Welche Prüfungen in welchem Takt laufen und was das kostet, zeigt die Übersicht der Pakete - die Header-Auswertung ist Teil des wiederkehrenden Laufs und nicht als Einzelposten geführt.