Port-Monitoring baut wiederholt eine Verbindung zu einem bestimmten Host und Port auf, etwa db01:5432, um zu bestätigen, dass ein Dienst tatsächlich Verbindungen annimmt. Es liegt zwischen Ping und HTTP-Checks und beantwortet eine Frage: Lauscht der Prozess, ist er über den Netzwerkpfad erreichbar und nimmt er Verbindungen schnell genug an? Für die Netzwerkzuverlässigkeit ist das entscheidend, weil viele Ausfälle passieren, während der Host noch läuft – und nur ein Check auf Port-Ebene sie bemerkt.
So funktioniert ein Port-Check
Ein TCP-Port-Check baut eine Verbindung genau wie ein Client auf: SYN, SYN-ACK, ACK, danach Verbindungsabbau. Das Ergebnis fällt in einen von drei Zuständen:
- Open: Der Handshake wurde abgeschlossen, also lauscht ein Dienst und ist erreichbar.
- Closed: Der Host hat mit einem Reset (RST) geantwortet – er ist erreichbar, aber an diesen Port ist nichts gebunden.
- Filtered: Bis zum Timeout kam keine Antwort, meist weil eine Firewall, Security Group oder ACL das Paket stillschweigend verworfen hat.
UDP kennt keinen Handshake. Ein Check sendet daher ein Probe-Datagramm und wertet eine gültige Antwort als Erfolg. Ein ICMP-„Port unreachable“ bedeutet geschlossen, Stille dagegen ist mehrdeutig. UDP-Checks funktionieren deshalb am besten mit einer protokollspezifischen Payload, zum Beispiel einer echten DNS-Abfrage an Port 53.
Auch die Verbindungszeit zählt: Ein Handshake, der von 20 ms auf 800 ms springt, ist ein Frühwarnsignal, selbst wenn der Port noch als offen gemeldet wird.
Wo Port-Monitoring zwischen Ping und HTTP steht
Betrachten Sie die drei Check-Typen als Schichten: Host, Dienst, Anwendung.
| Check | Beantwortete Frage | Typischer blinder Fleck |
|---|---|---|
| Ping (ICMP) | Ist der Host im Netzwerk erreichbar? | Dienst abgestürzt, während das Betriebssystem weiter antwortet |
| Port (TCP/UDP) | Nimmt dieser Dienst Verbindungen an? | Anwendung liefert nach dem Verbindungsaufbau Fehler |
| HTTP/HTTPS | Liefert die Anwendung die richtige Antwort? | Nicht-HTTP-Dienste wie Datenbanken, SMTP oder MQTT |
Für Dienste, die kein HTTP sprechen – etwa PostgreSQL, Redis, SMTP, SSH oder RabbitMQ –, ist der Port-Check oft das direkteste externe Verfügbarkeitssignal.
Zuverlässigkeitsprobleme, die Port-Monitoring erkennt
Diese Vorfälle rutschen an Ping vorbei und werden erst auf Port-Ebene sichtbar:
- Dienst abgestürzt, Host läuft weiter. Die Datenbank wurde vom OOM-Killer beendet, aber der Kernel beantwortet weiterhin Pings. Der Port wechselt innerhalb eines Intervalls auf „closed“.
- Änderung an Firewall oder Security Group. Eine Infrastructure-as-Code-Änderung blockiert den Traffic auf Port 5432. Der Host bleibt per Ping erreichbar, der Port wird „filtered“.
- Listener am falschen Interface gebunden. Der Dienst bindet an
127.0.0.1statt an0.0.0.0. Lokal wirkt alles gesund, externe Checks sehen den Port jedoch als geschlossen. - Langsames Accept oder Port-Erschöpfung. Ein voller Accept-Backlog, sich stauende TIME_WAIT-Verbindungen oder ein ausgelasteter Pool lassen Handshakes hängen. Steigende Verbindungszeiten sind oft das erste Symptom.
- Unerwartete Dienste. Ein Port, der geschlossen sein sollte, etwa eine Debug-Schnittstelle, ist plötzlich offen – ein Problem für Zuverlässigkeit und Sicherheit zugleich.
Was Port-Monitoring nicht erkennt
Ein offener Port ist kein Beweis für einen gesunden Dienst. Ein Webserver kann Verbindungen annehmen und trotzdem 500-Fehler liefern, eine Datenbank kann Verbindungen akzeptieren und Abfragen wegen voller Festplatte ablehnen, und ein TLS-Listener kann ein abgelaufenes Zertifikat ausliefern. Über langsame Abfragen oder Datenkorrektheit sagen Port-Checks ebenfalls nichts aus. Kombinieren Sie sie mit HTTP-, API- und SSL-Checks für die Schichten darüber und mit Ping für das Netzwerk darunter.
Praktische Hinweise zur Einrichtung
- Überwachen Sie jeden extern erreichbaren Dienst-Port sowie interne Ports, von denen kritische Pfade abhängen.
- Nutzen Sie für Produktionsdienste Intervalle von 30 bis 60 Sekunden; für weniger kritische Systeme reichen meist 1 bis 5 Minuten.
- Setzen Sie Timeouts von etwa 5 bis 10 Sekunden und alarmieren Sie bei Verbindungszeiten deutlich über der Baseline, nicht erst bei einem Ausfall.
- Bestätigen Sie Ausfälle von mehr als einem Standort, bevor Sie alarmieren, damit ein einzelner gestörter Netzwerkpfad keinen Fehlalarm auslöst.
- Pflegen Sie eine Baseline, welche Ports offen und welche geschlossen sein sollen, und alarmieren Sie bei Abweichungen in beide Richtungen.
Das Port-Monitoring von UpScanX bietet TCP- und UDP-Checks, Service-Fingerprinting mit Versionserkennung, protokollspezifische Antwortvalidierung und die Messung der Verbindungszeit von mehr als 15 globalen Standorten. UpScanX vergleicht den Port-Status außerdem mit Ihrer Konfigurations-Baseline, um unerwartete Dienste zu melden, und versendet Alerts per Email, Slack, Telegram, Microsoft Teams oder Webhook. Weitere Details finden Sie unter So funktioniert Port-Monitoring.
Wichtigste Erkenntnisse
- Port-Monitoring prüft, ob ein bestimmter Dienst Verbindungen annimmt – nicht nur, ob der Host erreichbar ist.
- Es erkennt abgestürzte Prozesse, Firewall-Änderungen, falsche Bind-Adressen und Verbindungssättigung, die Ping übersieht.
- Die Zustände „open“, „closed“ und „filtered“ deuten auf unterschiedliche Ursachen hin und beschleunigen so die Fehleranalyse.
- Es validiert kein Anwendungsverhalten; kombinieren Sie es daher mit Ping-, HTTP- und SSL-Checks für eine vollständige Abdeckung.