Warum die Überwachung an der Webschicht endet
Das gängige Monitoring-Repertoire ist rund um HTTP gewachsen. Eine Prüfung ruft eine Adresse auf, wertet den Statuscode aus, misst die Antwortzeit und schlägt an, wenn eines davon aus dem Rahmen fällt. Darauf setzen alle weiterführenden Verfahren auf: Zusicherungen im API-Monitoring auf REST-Endpunkte, aufgezeichnete Browserflows, Prüfungen von Formularstrecken und Anmeldewegen. Diese Verfahren teilen eine Voraussetzung, die selten ausgesprochen wird: Der geprüfte Dienst muss HTTP sprechen. Für einen erheblichen Teil der Infrastruktur eines Betriebs trifft das nicht zu.
Ein Mailserver nimmt Nachrichten anderer Mailserver auf Port 25 entgegen (IETF RFC 5321) und Nachrichten der eigenen Nutzer auf Port 587, der seit 2011 als Standardweg für die Einlieferung festgeschrieben ist (IETF RFC 6409). Der Abruf läuft über Port 993 und die Einlieferung mit sofortiger Verschlüsselung über Port 465, beides mit einer von Beginn an aufgebauten TLS-Verbindung (IETF RFC 8314). Ein SSH-Dienst hört auf Port 22 und tauscht als Erstes eine Versionskennung im Klartext aus (IETF RFC 4253). Datenbanken warten auf Port 3306 oder 5432 (IANA), Cache-Dienste üblicherweise auf 6379. Keiner dieser Dienste liefert eine Seite aus, die sich mit einem HTTP-Aufruf abholen ließe. Wer sie überwachen will, muss eine Ebene tiefer ansetzen - bei der TCP-Verbindung selbst.
Der praktische Effekt dieser Lücke ist unangenehm: Der sichtbare Teil des Betriebs, die Website, wird engmaschig geprüft, während der unsichtbare Teil - der die eigentliche Arbeit erledigt - unbeobachtet läuft. Ein Ausfall dort meldet sich typischerweise erst, wenn ein Kunde anruft oder jemand im Team bemerkt, dass seit dem Vormittag keine Anfrage mehr eingegangen ist. Bis dahin sind erfahrungsgemäß Stunden vergangen, in denen keine Meldung ausgelöst wurde, weil kein Monitor für diesen Dienst existierte.
Eine Firmenwebsite kann tagelang tadellos ausgeliefert werden, während im Hintergrund die Mail-Einlieferung klemmt, der Datenbankdienst nach einem Neustart nicht wieder hochgekommen ist und die nächtliche Dateiübergabe an den Steuerberater seit Tagen abbricht. Die Website ist statisch genug, um davon nichts zu merken. Wie still solche Wege ausfallen können, zeigt der Beitrag zur Überwachung der Kontaktformular-Zustellung: Das Formular bedankt sich weiterhin, die Nachricht kommt trotzdem nirgends an.
Welche Dienste hinter welchen Ports arbeiten
Portnummern sind kein Zufall, sondern verwaltet. Die IANA führt ein Register der Dienstnamen und Portnummern, das in drei Bereiche geteilt ist: Systemports von 0 bis 1023, Nutzerports von 1024 bis 49151 und dynamische Ports ab 49152 (IETF RFC 6335). Die klassischen Infrastrukturdienste liegen fast vollständig im ersten Bereich, was die Überwachung erleichtert - die Zielports sind bekannt und ändern sich selten. Die folgende Übersicht ordnet den wichtigsten Ports zu, was ihr Ausfall im Alltag tatsächlich bedeutet.
| Port | Dienst | Was ein Ausfall im Alltag bedeutet |
|---|---|---|
| 22 | SSH-Fernzugang und SFTP (IANA) | Fernwartung und Dateiübergaben stehen still |
| 25 | SMTP zwischen Mailservern (IETF RFC 5321) | eingehende Post wird verzögert oder abgewiesen |
| 465 | Mail-Einlieferung mit sofortigem TLS (IETF RFC 8314) | Absender aus dem eigenen Haus kommen nicht durch |
| 587 | Mail-Einlieferung der eigenen Nutzer (IETF RFC 6409) | Bestellbestätigungen und Systemmeldungen bleiben liegen |
| 993 | IMAP-Abruf über TLS (IETF RFC 8314) | Postfächer lassen sich nicht mehr abrufen |
| 21 | FTP-Steuerverbindung (IETF RFC 959) | Übergaben an Partner und Dienstleister brechen ab |
| 3306 / 5432 | Datenbankdienste (IANA) | Anwendungen laufen ins Leere, obwohl die Seite lädt |
| 6379 | Cache-Dienst, üblicher Standardport | Antwortzeiten steigen, Warteschlangen laufen voll |
Zwei Beobachtungen aus dieser Liste sind für die Praxis wichtig. Erstens hängt an den Mailports weit mehr als die Korrespondenz mit Kunden: Passwort-Rücksetzungen, Rechnungsversand, Vertragsbestätigungen und automatische Systemmeldungen laufen über denselben Weg. Wie sich die Verschlüsselung dieses Wegs zusätzlich absichern und überwachen lässt, beschreibt der Beitrag zu MTA-STS und TLS-RPT. Zweitens gehören die beiden letzten Zeilen aus Sicherheitssicht überhaupt nicht ins offene Netz - ein Punkt, auf den der Beitrag zur externen Angriffsfläche exponierter Dienste und der Abschnitt weiter unten zurückkommen.
Offener Port, angenommene Verbindung, antwortendes Protokoll
Eine TCP-Verbindung entsteht in drei Schritten: Der Prüfknoten schickt ein SYN-Paket, der Dienst antwortet mit SYN-ACK, der Prüfknoten bestätigt mit ACK (IETF RFC 9293). Erst danach steht die Verbindung. Was dieser Ablauf beweist, wird in der Praxis regelmäßig überschätzt - er zeigt, dass ein Prozess auf dem Zielsystem den Port belegt und dass die Zwischenstationen das Paket durchgelassen haben. Er zeigt nicht, dass dieser Prozess seine eigentliche Arbeit tut.
Der Unterschied ist im Störungsfall entscheidend. Ein Sicherheitssystem kann die Verbindung stellvertretend annehmen und erst danach verwerfen; ein überlasteter Dienst kann Verbindungen in die Annahmewarteschlange legen, ohne sie je zu bearbeiten; ein Mailserver kann den Handshake abschließen und danach jede Einlieferung mit einem temporären Fehler ablehnen. In allen drei Fällen meldet eine reine Portprüfung Erfolg, während der Dienst faktisch ausgefallen ist. Deshalb lohnt es sich, die Prüfung in Stufen zu denken und je Dienst bewusst zu entscheiden, welche Tiefe angemessen ist.
Ein SYN-Paket erreicht das Zielsystem und wird nicht verworfen. Das belegt, dass der Netzweg frei ist und ein Prozess den Port hält. Es belegt nicht, dass der Dienst antwortet, weil ein Zwischensystem die Verbindung stellvertretend annehmen kann. Als alleinige Aussage taugt diese Stufe für die Prüfung des Netzwegs, nicht für die Bewertung eines Dienstes.
Der Handshake ist abgeschlossen, die Verbindung steht, und die Zeit bis dahin lässt sich messen. Das ist der Kern der Portüberwachung: Ein Dienst, der Verbindungen annimmt und dies in gleichbleibender Zeit tut, arbeitet in der Regel normal. Steigt die Zeit über Tage oder Wochen an, deutet das auf Überlast oder auf ein Problem im Netzweg hin.
Viele Dienste melden sich von sich aus, sobald die Verbindung steht: Ein SMTP-Server sendet eine Begrüßungszeile mit dem Code 220 (IETF RFC 5321), ein FTP-Dienst quittiert die Steuerverbindung ebenso (IETF RFC 959), ein SSH-Dienst schickt eine Versionskennung (IETF RFC 4253). Wer diese erste Antwort mitliest, prüft nicht mehr nur den Port, sondern den Dienst dahinter.
Eine korrekte Begrüßung sagt nichts über Anmeldung, Berechtigungen, Plattenplatz oder Warteschlangenlänge. Für diese Fragen braucht es Signale aus dem System selbst, etwa regelmäßige Lebenszeichen eines Hintergrundprozesses. Eine Portprüfung ist eine Außensicht: Sie erkennt zuverlässig das Fehlen eines Dienstes, aber nicht jede Form seiner Fehlfunktion.
Was die Zeit bis zum Verbindungsaufbau verrät
Neben dem Ja-Nein-Befund liefert jede Portprüfung eine Zahl: die Zeit vom ersten Paket bis zur stehenden Verbindung. Sie setzt sich aus der Namensauflösung, der Laufzeit über den Netzweg und der Reaktionszeit des Dienstes zusammen. Kommt eine Verschlüsselung hinzu, verlängert sich der Vorgang um den TLS-Handshake; mit TLS 1.3 genügt dafür ein Umlauf, in TLS 1.2 waren es zwei (IETF RFC 8446). Wer Port 465 oder 993 überwacht, misst diesen Anteil zwangsläufig mit, weil die Verschlüsselung dort direkt beim Verbindungsaufbau aufgesetzt wird (IETF RFC 8314).
Diese Zahl ist das brauchbarste Frühwarnsignal, das eine Portprüfung hergibt. Ein Dienst fällt selten von einer Minute auf die andere aus; häufiger wird er zunächst langsam, weil Verbindungen sich stauen, der Arbeitsspeicher knapp wird oder ein Netzweg umgeleitet wurde. Aussagekräftig ist dabei nicht der Mittelwert, sondern die Verteilung: Ein p95-Wert, der sich von 40 auf 900 Millisekunden verschiebt, ist ein Befund, auch wenn der Durchschnitt kaum steigt. Warum Perzentile dem Mittelwert vorzuziehen sind, erläutert der Beitrag zu p95 und p99 statt Durchschnitt.
Ein zweiter Nutzen ergibt sich aus dem Vergleich zwischen Prüfstandorten. Wenn die Verbindungszeit zum Mailserver an einem Standort stabil bleibt und an einem anderen um ein Vielfaches steigt, liegt das Problem mit hoher Wahrscheinlichkeit nicht im Dienst, sondern auf dem Weg dorthin. Genau dafür ist die Prüfung aus mehreren Standorten gedacht: Sie trennt den Ausfall eines Dienstes vom Ausfall einer Route und verhindert, dass eine gestörte Netzstrecke als Serverausfall gemeldet wird.
Ein Dienst, der noch antwortet, aber deutlich langsamer als in der Vorwoche, ist ein Vorbote. Wer ausschließlich den Zustand erreichbar oder nicht erreichbar speichert, verschenkt diese Information. Wer die Verbindungszeit je Standort als Zeitreihe führt, sieht die Verschlechterung häufig Tage vor dem eigentlichen Ausfall - und kann handeln, solange sich die Arbeit noch in ein geplantes Wartungsfenster legen lässt.
Wenn ein Port bewusst nicht öffentlich sein darf
Nicht jeder Port, der sich von außen erreichen lässt, sollte das auch. Datenbank- und Cache-Dienste, Verwaltungsoberflächen, Suchindizes und Nachrichtenwarteschlangen gehören in ein internes Netz oder hinter einen abgesicherten Zugang; die IT-Grundschutz-Bausteine empfehlen durchgängig, nur die tatsächlich benötigten Dienste nach außen freizugeben (BSI IT-Grundschutz). Der Grund ist nicht theoretisch: Im Verizon Data Breach Investigations Report 2026 ist das Ausnutzen von Schwachstellen mit 31 Prozent der häufigste initiale Angriffsweg (Verizon DBIR 2026), gegenüber dem Vorjahr ein Anstieg um 55 Prozent (Verizon DBIR 2026); ausgewertet wurden über 22.000 bestätigte Datenpannen in 145 Ländern (Verizon DBIR 2026). Jeder unnötig offene Dienstport vergrößert diese Fläche.
Für die Überwachung folgt daraus eine Umkehrung der Fragestellung. Bei einem öffentlichen Dienst lautet sie: Antwortet er? Bei einem internen Dienst lautet sie: Antwortet er nach innen - und schweigt er nach außen? Beide Prüfungen sind sinnvoll, aber sie messen Gegenteiliges. Eine Portprüfung von außen auf Port 3306 sollte fehlschlagen; schlägt sie an, ist das ein Befund für die Sicherheitsseite und kein Beleg für Verfügbarkeit. Dieser Unterschied gehört dokumentiert, sonst wird die grüne Anzeige eines solchen Monitors später falsch gelesen.
Die Verfügbarkeit interner Dienste lässt sich trotzdem messen, nur eben nicht von außen. Der übliche Weg führt über regelmäßige Lebenszeichen: Ein Prozess auf dem System meldet in festem Takt, dass er läuft, und das Ausbleiben dieser Meldung löst den Alarm aus. Dieses Vorgehen beschreibt der Beitrag zum Heartbeat-Monitoring für Hintergrundprozesse. Wer viele Dienst-Monitore anlegt, sollte parallel klären, wer sie sehen und ändern darf - dazu passt der Beitrag zu Zugriffsrechten und Prüfspur im Monitoring-Team.
Wenn eine Prüfung aus dem Internet auf 3306, 5432 oder 6379 eine stehende Verbindung meldet, ist die richtige Reaktion nicht Erleichterung, sondern ein Blick in die Firewall-Regeln. Behandeln Sie solche Prüfungen deshalb getrennt von der Verfügbarkeitsüberwachung: Der gewünschte Zustand ist hier die abgewiesene Verbindung, und ein Treffer gehört auf die Sicherheitsliste, nicht auf die öffentliche Statusseite.
Prüfintervall und das Rauschen der Verbindungstimeouts
Portprüfungen haben ein charakteristisches Fehlerbild. Während ein HTTP-Check im Störungsfall meist einen Statuscode zurückbringt, der etwas über die Ursache verrät, endet eine gescheiterte TCP-Verbindung in aller Regel in einer Zeitüberschreitung ohne weitere Auskunft. Der Grund liegt im Protokoll selbst: Geht ein SYN-Paket verloren, wiederholt der Systemstack den Versuch nach einer voreingestellten Wartezeit von einer Sekunde, die sich mit jedem weiteren Versuch verdoppelt (IETF RFC 6298). In einer verbreiteten Standardkonfiguration wird sechsmal wiederholt, sodass ein Verbindungsaufbau erst nach rund 127 Sekunden endgültig aufgegeben wird (Linux-Kerneldokumentation).
Für die Überwachung heißt das: Das eigene Zeitlimit der Prüfung ist die entscheidende Stellschraube, nicht das des Betriebssystems. Ein Prüfknoten, der nach fünf Sekunden abbricht, meldet bereits einen Ausfall, während der Systemstack noch geduldig weiterprobiert. Ein zu kurz gewähltes Limit erzeugt Fehlalarme bei jedem kurzen Paketverlust, ein zu langes verzögert die Erkennung echter Ausfälle. Bewährt hat sich, das Limit an der beobachteten Verbindungszeit auszurichten - etwa beim Zehnfachen des p95-Werts - statt an einer runden Zahl aus dem Bauch heraus.
| Aspekt | HTTP-Prüfung | TCP-Portprüfung |
|---|---|---|
| Was im Fehlerfall zurückkommt | Statuscode, Header, oft eine Fehlerseite | meist nur eine Zeitüberschreitung ohne Begründung |
| Häufigste Ursache eines Fehlalarms | kurzer 5xx-Ausschlag bei einem Neustart | ein verworfenes SYN-Paket auf dem Netzweg |
| Aussagekraft eines einzelnen Fehlversuchs | mittel, der Statuscode grenzt die Ursache ein | gering, solange kein zweiter Standort bestätigt |
| Sinnvolle Absicherung | Zusicherungen auf Inhalt und Laufzeit | Bestätigung durch mehrere Prüfstandorte |
| Wartezeit bis zur ersten Wiederholung | abhängig von der eingesetzten Bibliothek | eine Sekunde, danach jeweils verdoppelt (IETF RFC 6298) |
| Voreingestelltes Aufgeben des Systemstacks | abhängig vom eingesetzten Client | nach rund 127 Sekunden (Linux-Kerneldokumentation) |
Aus diesem Fehlerbild folgt die zweite Stellschraube: Ein einzelner fehlgeschlagener Versuch ist bei Portprüfungen ein schwächeres Signal als bei HTTP-Prüfungen. Wer daraus sofort eine Meldung macht, erzeugt Up-Down-Rauschen, das die Bereitschaft mürbe macht und echte Ausfälle überdeckt. Verlässlicher ist ein Konsens über mehrere Standorte: Erst wenn zwei von drei Prüfknoten denselben Ausfall sehen, gilt er als bestätigt. Wie sich dieses Rauschen systematisch dämpfen lässt, beschreibt der Beitrag zum Zähmen von Flapping-Alerts; welche Erkennungszeit welches Intervall verlangt, rechnet der Beitrag zur Wahl des Prüfintervalls durch.
Ein letzter Punkt betrifft die Gegenseite. Wiederholte Verbindungsversuche von denselben Adressen sehen aus Sicht mancher Schutzmechanismen wie ein Scanversuch aus, und eine automatische Sperre trifft dann ausgerechnet die eigene Überwachung. Das Ergebnis ist ein Ausfall, den es gar nicht gibt. Die Adressen der Prüfknoten gehören deshalb in die Ausnahmeliste der Schutzsysteme - eine Aufgabe, die der Beitrag zur Firewall-Whitelist für Monitoring im Detail behandelt.
Dienst-Monitore einrichten: ein Vorgehen in sechs Schritten
Aus der Theorie wird erst dann Betriebssicherheit, wenn die Prüfungen in feste Abläufe wandern. Ein pragmatisches Vorgehen, das sich an einem Nachmittag umsetzen lässt:
- Bestandsaufnahme der Dienste: Notieren Sie jeden Dienst, der ausfallen kann, ohne dass die Website es merkt - Mail-Einlieferung und -Abruf, SSH, Datenbanken, Dateiübergaben, Cache- und Suchdienste. Halten Sie je Dienst fest, welcher Port zuständig ist und ob er öffentlich erreichbar sein soll oder nicht.
- Prüftiefe je Dienst festlegen: Für interne Dienste genügt oft die reine Verbindungsprüfung, für Mail- und Übergabedienste lohnt sich die Stufe mit dem Mitlesen der ersten Protokollantwort. Notieren Sie die Entscheidung, damit später nachvollziehbar bleibt, was ein grünes Häkchen an dieser Stelle tatsächlich aussagt.
- Zeitlimit und Intervall aus Messwerten ableiten: Lassen Sie die Prüfung eine Woche mitlaufen, bevor Sie Schwellen setzen. Richten Sie das Zeitlimit am beobachteten p95-Wert der Verbindungszeit aus und das Intervall an der Erkennungszeit, die Sie brauchen - bei kritischen Diensten sind 60 Sekunden ein üblicher Ausgangswert.
- Bestätigung über mehrere Standorte verlangen: Setzen Sie die Meldeschwelle so, dass ein Ausfall erst nach Bestätigung durch einen zweiten Prüfstandort gilt. Das kostet wenige Sekunden Erkennungszeit und spart erfahrungsgemäß den größten Teil der Fehlalarme aus verworfenen Paketen.
- Alarmwege bündeln: Führen Sie Web- und Dienstprüfungen in dieselben Benachrichtigungswege und Eskalationsstufen, statt für die Infrastruktur ein zweites Werkzeug zu betreiben. Eine Bereitschaft, die zwei getrennte Postfächer beobachten muss, übersieht früher oder später eines davon.
- Ergebnisse aufbewahren und berichten: Halten Sie Verfügbarkeit und Verbindungszeiten je Dienst über die Zeit fest, damit sich Trends und erreichte Zielwerte belegen lassen. Wie lange diese Daten liegen bleiben dürfen und wann sie zu löschen sind, klärt der Beitrag zum Löschkonzept für Monitoring-Daten.
Zwei Nachbarthemen gehören in dieselbe Runde. Erstens verschieben Auslieferungen regelmäßig Ports, Zertifikate und Konfigurationen, ohne dass jemand die Monitore nachzieht; dass nach einem Deploy auch veraltete Zwischenstände hängen bleiben können, zeigt der Beitrag zu Cache-Fallen nach dem Deploy. Zweitens sollte jeder neu angelegte Dienst-Monitor eine benannte Zuständigkeit bekommen, sonst sammelt sich über die Jahre eine Liste von Prüfungen an, die sich nicht mehr zuordnen lassen und deren Meldungen deshalb ignoriert werden.
Website und Infrastruktur in einem Konto überwachen
Der Kern der Aufgabe ist unspektakulär: Die Dienste, die den Betrieb tragen, brauchen dieselbe Aufmerksamkeit wie die Seite, die ihn nach außen darstellt. Der Aufwand dafür ist überschaubar - eine Handvoll Portprüfungen, sinnvoll gesetzte Zeitlimits und eine Bestätigungsregel decken den größten Teil ab. Was den Unterschied macht, ist die Zusammenführung: ein Ort für Web und Infrastruktur, ein Alarmweg, eine Statusseite. Getrennte Werkzeuge erzeugen getrennte Zuständigkeiten, und zwischen zwei Zuständigkeiten fällt erfahrungsgemäß der Ausfall durch, mit dem am wenigsten gerechnet wurde.
XICTRAQ prüft neben HTTP und HTTPS auch beliebige TCP-Ports und damit Mailserver, SSH-Zugänge, Datenbanken, Dateiübergaben und Cache-Dienste. Die Prüfungen laufen aus drei EU-Rechenzentren, zwei davon in Deutschland und eines in Finnland; ein Ausfall gilt erst dann als bestätigt, wenn zwei von drei Knoten ihn sehen. Zu jedem Monitor werden Namensauflösung, Verbindungsaufbau, TLS-Handshake und Antwortzeit als Zeitreihe geführt und als Perzentile dargestellt, sodass sich eine schleichende Verschlechterung erkennen lässt. Geplante Arbeiten lassen sich vorab als Wartungsfenster hinterlegen, damit sie keine Meldung auslösen.
Die Ergebnisse laufen in dieselben Berichte und auf dieselbe öffentliche Statusseite wie die Website-Prüfungen - Kunden und Kollegen sehen einen Stand statt zweier getrennter Werkzeuge. Starten Sie mit dem kostenlosen Test und legen Sie den ersten Portmonitor für Ihren Mailserver an, oder sehen Sie sich in einer persönlichen Demo an, wie Dienst- und Website-Monitore in einem Konto zusammenlaufen.
Dieser Artikel basiert auf Daten von IETF (RFC 959, RFC 4253, RFC 5321, RFC 6298, RFC 6335, RFC 6409, RFC 8314, RFC 8446, RFC 9293), IANA, der Linux-Kerneldokumentation, dem BSI IT-Grundschutz und dem Verizon Data Breach Investigations Report 2026. Die genannten Zahlen beziehen sich auf den Stand der jeweiligen Veröffentlichung.