Apache mod_status absichern und Statuswerte richtig auswerten

Was mod_status sichtbar macht

Das Apache-Modul mod_status stellt Informationen über den laufenden Webserver bereit. Es hilft etwa bei der Frage, wie viele Worker gerade beschäftigt sind und welche Anfragen bearbeitet werden. Die folgenden Erläuterungen beziehen sich auf Apache HTTP Server 2.4; die Dokumentation des Entwicklungszweigs ist davon getrennt und nicht ohne Prüfung auf diese Version übertragbar.

Ein Handler erzeugt die Statusausgabe für einen konfigurierten URL-Pfad. Ein Location-Abschnitt kann diesen Pfad dem Handler server-status zuordnen; eine gleichnamige Datei im DocumentRoot ist dafür nicht erforderlich. Der Pfad ist damit ein Zugang zur Serverdiagnose und keine gewöhnliche, aus dem Dateisystem ausgelieferte Seite.

Für die manuelle Diagnose eignet sich die HTML-Ansicht. Die Variante mit ?auto liefert eine maschinenlesbare Darstellung, die ein Monitoring-System regelmäßig abrufen kann. Welche Details verfügbar sind, hängt unter anderem von der Serverkonfiguration ab. Der Parameter macht aus dem Endpunkt keinen separaten Dienst: Auch seine Ausgabe muss vor unberechtigtem Zugriff geschützt werden.

Voraussetzung ist, dass mod_status geladen ist und du die passende Apache-Konfiguration bearbeiten darfst. Für Zugriffsbeschränkungen müssen außerdem die benötigten Autorisierungsmodule verfügbar sein. Wie ein Modul aktiviert wird und welche Dateien dafür zuständig sind, unterscheidet sich je nach Distribution und Installation; ein einzelner Dateipfad ist deshalb kein allgemeingültiger Ausgangspunkt.

Für Apache Monitoring ist die Ausgabe eine Diagnosequelle, aber kein vollständiges Application Performance Monitoring. Sie zeigt beispielsweise, dass Worker beschäftigt sind, erklärt aber nicht selbst, ob eine Datenbank, ein Backend oder ein langsamer Client die Bearbeitung verzögert. Für solche Ursachenfragen brauchst du zusätzlich passende Anwendungs-, System- und Protokolldaten.

Statusdaten und ihre Sicherheitsfolgen

Die Statusseite zeigt unter anderem beschäftigte und freie Worker sowie Angaben zur Start- oder Neustartzeit und zur Laufzeit. Beschäftigte Worker stehen zum Zeitpunkt der Abfrage nicht als freie Kapazität zur Verfügung. Wie kritisch ein Verhältnis aus beschäftigt und frei ist, lässt sich erst mit dem Verlauf und der tatsächlich konfigurierten Worker-Grenze beurteilen.

Die Laufzeit hilft, aggregierte Werte zeitlich einzuordnen: Ein Durchschnitt seit dem Start kann kurze Lastspitzen verdecken. Ebenso ist ein Abruf mit wenigen freien Workern zunächst nur eine Momentaufnahme. Wiederholte Abfragen zusammen mit Antwortzeiten und Fehlern liefern eine bessere Grundlage, um eine mögliche Knappheit zu untersuchen.

Mit ExtendedStatus erfasst Apache zusätzliche Details, darunter aggregierte Zugriffe und Datenmengen sowie Informationen zu aktuellen Hosts und Requests. Beim Laden von mod_status ist diese Erfassung in Apache 2.4 standardmäßig eingeschaltet. Eine ausdrückliche Konfigurationsentscheidung macht dennoch nachvollziehbar, welche Detailtiefe im jeweiligen Betrieb vorgesehen ist.

Die genauere Erfassung hat ihren Preis: Sie verursacht zusätzlichen Aufwand und kann den Server verlangsamen. Wäge deshalb den diagnostischen Nutzen gegen diesen Aufwand ab, statt mehr Details automatisch als kostenlose Verbesserung zu betrachten. Ohne ExtendedStatus fehlen andererseits Informationen, die für die Zuordnung laufender Anfragen hilfreich sein können.

Die Ausgabe kann laufende Requests und Clientinformationen offenlegen. Behandle sie daher als sensible Betriebsdaten und nicht als öffentlichen Healthcheck. Die HTML-Ansicht und ?auto benötigen denselben Zugriffsschutz; ein schwer erratbarer Pfad verhindert keinen Zugriff durch jemanden, der ihn kennt oder entdeckt.

Zugriffswege und Worker-Modell prüfen

Erfasse vor einer Änderung die installierte Apache-Version und das aktive Multiprocessing Module, kurz MPM. Prüfe außerdem, welche virtuellen Hosts den betreffenden Listener bedienen, ob Reverse-Proxys Anfragen weiterleiten und welche Zugriffsregeln bereits gelten. Erst mit diesem Überblick lässt sich beurteilen, wo eine neue Regel wirkt und welche bestehenden Konfigurationen sie beeinflussen können.

Ein lokaler Monitoring-Agent könnte den Status über eine Loopback-Adresse abrufen. Ein erfolgreicher lokaler Abruf zeigt aber nur, dass dieser konkrete Weg mit der gewählten Adresse, dem Port und dem ausgewählten virtuellen Host funktioniert. Er beweist weder, dass andere Hosts geschützt sind, noch dass ein externer Zugriff scheitert.

Ein zweiter Weg kann über einen Reverse-Proxy und einen anderen virtuellen Host führen. Dort können andere Weiterleitungen oder Zugriffsregeln greifen; zudem ist zu prüfen, welche Clientadresse Apache für die Autorisierung tatsächlich heranzieht. Betrachte den Zugriffsweg deshalb einschließlich Proxy, Host-Auswahl und Apache-Regeln, statt den lokalen Test auf die gesamte Topologie zu übertragen.

Das MPM bestimmt, wie Apache Prozesse und gegebenenfalls Threads zur Verarbeitung einsetzt. Ein Prozess ist eine Betriebssystemeinheit; Threads laufen innerhalb eines Prozesses und können dort Aufgaben bearbeiten. Die Bedeutung einer Worker-Zahl hängt damit vom verwendeten Modell ab. Der Vergleich der Apache-Worker-Modelle erläutert die Unterschiede zwischen Prefork, Worker und Event.

Gerade beim event-MPM sind offene Verbindungen nicht automatisch gleichbedeutend mit dauerhaft belegten Worker-Threads. Bestimmte Wartezustände können anders behandelt werden als die aktive Verarbeitung einer Anfrage. Notiere daher das aktive MPM, bevor du aus Verbindungs- und Worker-Zahlen eine Kapazitätsentscheidung ableitest.

Lokalen Statusendpunkt einrichten

Prüfe vor der Änderung, ob Apache HTTP Server 2.4 läuft, mod_status geladen ist und die benötigten Autorisierungsmodule verfügbar sind. Erfasse außerdem die bestehenden virtuellen Hosts und Zugriffsregeln. Modulaktivierung und Konfigurationspfade unterscheiden sich je nach Distribution; das folgende Beispiel gehört in die passende Apache-Dateikonfiguration, nicht in eine pauschal vorausgesetzte Datei.

Das Beispiel schaltet ExtendedStatus ausdrücklich ein und ordnet den Pfad dem Statushandler zu. Require local begrenzt den Zugriff nach Apaches Regeln für lokale Verbindungen. Die Direktive für die Detailerfassung steht außerhalb des Location-Abschnitts. Vor der Übernahme musst du prüfen, wie dieser Abschnitt mit deiner vorhandenen Konfiguration zusammenwirkt.

ExtendedStatus On

<Location "/server-status">
    SetHandler server-status
    Require local
</Location>

Lass die Änderung gemäß deinem Betriebsprozess prüfen und freigeben, bevor du sie anwendest. Das Beispiel ist ein Ausgangspunkt, keine Zusicherung für alle virtuellen Hosts oder Proxy-Wege. Insbesondere vorhandene Autorisierungsabschnitte können beeinflussen, welche Regel für eine konkrete Anfrage gilt.

Nach der Anwendung kannst du die maschinenlesbare Ausgabe mit dem folgenden lesenden Befehl lokal abrufen. Er setzt einen Listener auf der gewählten Loopback-Adresse und dem Standardport 80 voraus. Prüfe auch, ob die Anfrage den vorgesehenen virtuellen Host erreicht; gegebenenfalls musst du Port und Host-Auswahl an deine Umgebung anpassen.

curl --fail --silent --show-error 'http://127.0.0.1/server-status?auto'

Ein fehlgeschlagener Abruf ist zunächst nur ein Hinweis, keine eindeutige Fehlerdiagnose. Neben der Autorisierung kommen etwa ein anderer Listener, eine abweichende Host-Zuordnung oder eine Weiterleitung infrage. Ein erfolgreicher lokaler Abruf wiederum sagt noch nicht aus, ob andere Zugriffswege geschützt sind.

Monitoring-Zugriff sicher erweitern

Wähle den Zugriffsweg danach, wo das Monitoring läuft und wer die Ausgabe benötigt. Ein Agent auf demselben Host kann die lokale Beschränkung nutzen. Muss ein externes System zugreifen, sollte die Freigabe auf tatsächlich benötigte Quellen begrenzt und anschließend über den vorgesehenen Netzwerkweg geprüft werden.

Bei Require ip ist nicht allein entscheidend, welche Adresse der Monitoring-Server aus seiner Sicht besitzt. Hinter einem Reverse-Proxy muss die installierte Konfiguration die Adresse liefern, die Apache für die Autorisierung tatsächlich heranzieht. Prüfe diese Zuordnung auf dem realen Weg, bevor du ein Netz freigibst; eine vermutete Clientadresse ist keine belastbare Zugriffskontrolle.

Mehrere Require-Direktiven innerhalb eines Abschnitts wirken ohne geeigneten Container grundsätzlich wie eine Oder-Verknüpfung: Erfüllt eine Anfrage eine der Bedingungen, kann das bereits genügen. Soll ein Client aus dem erlaubten Netz kommen und sich zusätzlich anmelden, fasse die Bedingungen ausdrücklich in einem <RequireAll>-Container zusammen und teste beide Anforderungen einzeln.

Bei Basic Authentication schützt erst ein geeigneter Transport wie TLS die Zugangsdaten auf dem Übertragungsweg. Ein separates Management-Netz kann die Erreichbarkeit zusätzlich begrenzen, ersetzt aber keine wirksame Apache-Autorisierung. Auch dort sollten nur berechtigte Systeme die HTML- und die maschinenlesbare Ausgabe abrufen können.

Statuswerte richtig einordnen

Die Statusseite beantwortet unterschiedliche Diagnosefragen mit unterschiedlichen Daten. Lies die Worker-Belegung deshalb nicht isoliert: Sie beschreibt den Zustand zum Abrufzeitpunkt. Zusätzliche Request-Details hängen von der Konfiguration und insbesondere von ExtendedStatus ab; welche Felder erscheinen, kann sich mit Server und MPM unterscheiden.

Angenommen, ein Abruf zeigt viele beschäftigte und nur wenige freie Worker. Das kann ein kurzer Lastspitzenwert sein oder auf länger anhaltenden Druck hindeuten. Wiederhole die Abfrage und vergleiche den Verlauf mit Antwortzeiten, Fehlern und der tatsächlich geltenden Worker-Grenze, bevor du eine Kapazitätsänderung erwägst.

Beim event-MPM können bestimmte Wartezustände vom Listener statt von dauerhaft gebundenen Worker-Threads betreut werden. Writing und Keep-alive sind daher als Verbindungszustände zu lesen, nicht pauschal als Zahl belegter Threads. Auch beendende Prozesse und ältere Generationen nach einem graceful restart können das Bild beeinflussen; prüfe die Einzelheiten für deine installierte 2.4-Version.

Für die Einordnung der Architektur ergänzt der Vergleich von Event MPM und Worker MPM die Statusanzeige. Die Wahl des MPM erklärt, wie Apache Verbindungen und Arbeit organisiert; sie ersetzt aber keine Beobachtung des konkreten Servers und seiner Anwendung.

Statusdaten über Zeit beobachten

Für Apache Monitoring ist eine einzelne Statusseite nur ein Ausschnitt. Lass die maschinenlesbare Ausgabe über ?auto regelmäßig von einem berechtigten Agenten abrufen und speichere die Werte mit einem Zeitstempel. So kannst du etwa erkennen, ob wenige freie Worker nur kurz auftreten oder über mehrere Abfragen hinweg bestehen bleiben.

Für eine Intervallrate vergleichst du einen kumulierten Zähler mit seinem vorherigen Wert und teilst die Differenz durch die verstrichene Zeit. Steigt beispielsweise die Zahl der Zugriffe innerhalb von 60 Sekunden um 120, entspricht das für dieses Intervall durchschnittlich zwei Zugriffen pro Sekunde. Dieser Mittelwert sagt noch nichts über die Verteilung innerhalb der Minute aus.

Prüfe vor der Differenzbildung Start- beziehungsweise Neustartinformationen und den Zählerstand. Ist der Server neu gestartet oder ein Zähler gegenüber dem vorherigen Abruf zurückgegangen, behandle das als Reset und beginne eine neue Vergleichsreihe. Eine negative Verkehrsrate aus zwei Zählerständen wäre hier irreführend; auch ausgefallene Abfragen sollten im Verlauf erkennbar bleiben.

Die von mod_status ausgegebenen Durchschnitte über die Serverlaufzeit glätten kurze Lastspitzen. Eine Zeitreihe mit passend gewähltem Abfrageintervall zeigt Veränderungen genauer, kann aber ebenfalls Ereignisse zwischen zwei Abfragen verpassen. Wähle das Intervall daher passend zur Diagnosefrage und berücksichtige den Aufwand für Erfassung und Speicherung.

Auch gespeicherte Statusdaten gehören geschützt: Je nach Ausgabe können Request- und Clientinformationen enthalten sein. Beschränke den Zugriff auf Agent, Speicher und Auswertung auf berechtigte Personen und Systeme. Lege außerdem fest, wie lange Rohdaten und abgeleitete Kennzahlen für den jeweiligen Betriebszweck aufbewahrt werden.

Zugriff und Fehlermeldungen prüfen

Prüfe nach einer freigegebenen Änderung zunächst den vorgesehenen berechtigten Zugriff, etwa vom lokalen Monitoring-Agenten. Kontrolliere anschließend von einem ausdrücklich nicht erlaubten Netzstandort aus sowohl die HTML-Seite als auch die Variante ?auto. Beide dürfen dort keine Statusdaten liefern. Ein Test von nur einem Standort oder auf nur einem Zugriffsweg reicht nicht aus.

Wiederhole die Prüfung für die tatsächlich erreichbaren virtuellen Hosts und gegebenenfalls für direkte und über einen Reverse-Proxy geführte Verbindungen. Ein lokaler Erfolg belegt nicht, dass der Proxy denselben Schutz durchsetzt. Achte auch auf Weiterleitungen: Entscheidend ist, ob am Ende eines Zugriffswegs sensible Statusdaten ausgegeben werden.

Schlägt ein erlaubter Abruf fehl, untersuche neben der Autorisierung auch Listener, Adresse und Port sowie die Auswahl des virtuellen Hosts. Proxy- und Redirect-Regeln können die Anfrage ebenfalls anders leiten als erwartet. Ein einzelner Fehler lässt deshalb weder sicher auf eine falsche Zugriffsregel noch auf einen defekten Handler schließen.

Kontrolliere bestehende Konfigurationen auf alte Zugriffsdirektiven wie Order und Deny. Deren unbedachte Mischung mit den neueren Require-Regeln kann zu unerwarteten Ergebnissen führen. Prüfe die tatsächlich wirksame Kombination, statt aus einer einzelnen erlaubenden Regel auf den endgültigen Zugriff zu schließen.

Eine geschützte Location ist zudem nicht zwingend der einzige mögliche Statusendpunkt. Ist mod_status geladen, kann sein Handler auch in Konfigurationen pro Verzeichnis einschließlich .htaccess verfügbar sein. Prüfe daher vorhandene Einträge und erlaubte Delegationen, besonders auf gemeinsam genutzten Servern, damit kein weiterer ungeschützter Handler eingerichtet werden kann.

Von Indizien zu Betriebsentscheidungen

Sind wiederholt viele Worker beschäftigt und nur wenige frei, ist das ein Hinweis auf möglichen Kapazitätsdruck, aber noch kein Ursachennachweis. Vergleiche den Verlauf mit Antwortzeiten, Fehlerraten und der tatsächlich geltenden Worker-Grenze. Erst das gemeinsame Bild zeigt, ob die Belegung mit spürbaren Problemen zusammenfällt und wie dauerhaft sie ist.

Bevor du eine Grenze erhöhst, prüfe den verfügbaren Speicher und den zusätzlichen Bedarf der vorgesehenen Prozesse oder Threads. Untersuche zugleich, warum Bearbeitungen lange dauern: Eine höhere Parallelität kann die eigentliche Ursache bestehen lassen und weitere Ressourcen binden. Änderungen gehören deshalb in einen kontrollierten Betriebsprozess mit anschließender Beobachtung.

Bei langsamen Anfragen helfen wiederholte Statusabrufe, aktuelle Requests und zugehörige Prozesse einzugrenzen. Vergleiche die Zeitpunkte mit Access- und Error-Logs sowie mit Daten der Anwendung und ihrer Backends. Ein flüchtiger Request kann zwischen zwei Abrufen verschwinden; eine einzelne Anzeige identifiziert weder zuverlässig eine bestimmte Anwendung als Ursache noch belegt sie einen Angriff.

Für eine auffällige Prozess-ID kannst du ergänzend Betriebssystemdaten wie CPU- und Speichernutzung prüfen. Diese Zuordnung ist eine weitere Spur, kein Ersatz für den zeitlichen Abgleich mit Requests und Logs. Insbesondere bei wiederholten Beobachtungen solltest du berücksichtigen, dass Prozesse und ihre gerade bearbeiteten Anfragen wechseln können.

Beim event-MPM beachte außerdem beendende Prozesse und alte Generationen nach einem graceful restart. Sie können das Bild während des Übergangs beeinflussen; offene Verbindungen sind dabei nicht pauschal mit dauerhaft belegten Worker-Threads gleichzusetzen. Prüfe die Besonderheiten der installierten Apache-2.4-Version, bevor du aus einer solchen Übergangsphase eine dauerhafte Kapazitätsentscheidung ableitest.