Wie überwacht man offene Ports für Webserver, Datenbanken und Mail-Dienste?

Offene Ports überwachen Sie dienstspezifisch: Prüfen Sie, ob jeder erwartete Port Verbindungen annimmt, ob das richtige Protokoll darauf antwortet, und vergleichen Sie die Verbindungszeit mit einer Baseline. Web- und Mail-Ports sollten aus mehreren öffentlichen Regionen geprüft werden, Datenbank-Ports dagegen von einem internen oder per Allowlist freigegebenen Standort aus – mit einem Alarm, sobald sie öffentlich erreichbar werden.

Warum ein TCP-Connect nicht ausreicht

Ein erfolgreicher TCP-Handshake beweist nur, dass etwas lauscht. Ein hängender Worker-Pool oder ein falsch konfigurierter Proxy kann Verbindungen annehmen und trotzdem nichts Brauchbares liefern. Gutes Port-Monitoring prüft deshalb die Protokollantwort: eine HTTP-Statuszeile, einen TLS-Handshake, eine SMTP-220-Begrüßung oder einen Datenbank-Handshake. Service-Fingerprinting liefert ein zweites Signal, indem es bestätigt, welche Software in welcher Version antwortet.

Referenztabelle nach Dienst

Dienst	Port(s)	Was validieren	Erwartete Erreichbarkeit
HTTP	80	Weiterleitung auf HTTPS	Öffentlich
HTTPS	443	TLS-Handshake, Zertifikat, Status	Öffentlich
MySQL	3306	Server-Begrüßung und Version	Nur intern
PostgreSQL	5432	Antwort auf SSLRequest	Nur intern
MongoDB	27017	Antwort auf hello-Befehl	Nur intern
Redis	6379	+PONG oder -NOAUTH	Nur intern
SQL Server	1433	TDS-Pre-Login-Antwort	Nur intern
SMTP	25	220-Banner, STARTTLS	Öffentlich (MX)
Submission	587 / 465	220; STARTTLS / implizites TLS	Öffentlich oder eingeschränkt
IMAP	143 / 993	* OK; TLS auf 993	Öffentlich oder eingeschränkt
POP3	110 / 995	+OK; TLS auf 995	Öffentlich oder eingeschränkt

Webserver: Ports 80 und 443

Prüfen Sie beide Ports aus mehreren Regionen. Auf Port 80 ist eine 301- oder 308-Weiterleitung auf HTTPS zu erwarten; ein 200 kann bedeuten, dass die Weiterleitung bei einer Konfigurationsänderung verloren ging. Auf Port 443 validieren Sie TLS-Handshake und Zertifikat, denn ein abgelaufenes oder nicht passendes Zertifikat legt Clients lahm, obwohl der Port offen ist. Erfassen Sie die Verbindungszeit getrennt von der Antwortlatenz: Steigt die Connect-Zeit, deutet das auf Netzwerk- oder Load-Balancer-Last hin, steigt die Antwortzeit, liegt das Problem eher in der Anwendung.

Datenbanken: privat überwachen, bei Exposition alarmieren

Datenbank-Ports sollten niemals aus dem Internet erreichbar sein. Daraus ergeben sich zwei getrennte Prüfungen:

1. Health-Check von innen. Führen Sie ihn von einem internen Host oder einer per Allowlist freigegebenen Quelle aus. MySQL sendet eine Begrüßung, sobald die Verbindung steht, während PostgreSQL, MongoDB, Redis und SQL Server auf den Client warten – der Check muss also zuerst sprechen.
2. Expositions-Check von außen. Prüfen Sie 3306, 5432, 27017, 6379 und 1433 von öffentlichen Standorten aus und werten Sie „offen“ als Fehlerzustand. Eine geänderte Security Group oder ein Container mit falschem Port-Mapping kann eine Datenbank binnen Minuten exponieren, und automatisierte Scanner finden offene Instanzen schnell.

Mail-Dienste: das Banner auswerten

Mail-Protokolle stellen sich selbst vor, was die Validierung einfach macht. SMTP-Server sollten mit 220 antworten; ein 421 bedeutet, dass der Dienst Verbindungen ablehnt. Bestätigen Sie auf Port 587, dass STARTTLS nach EHLO angeboten wird; auf 465, 993 und 995 muss der TLS-Handshake gelingen. IMAP sollte mit * OK grüßen, POP3 mit +OK. Manche Cloud-Netze blockieren ausgehenden Verkehr auf Port 25, prüfen Sie daher von Standorten, an denen er erlaubt ist.

Intervalle und Schwellenwerte

Typische Ausgangswerte, die Sie an Ihre eigene Baseline anpassen:

• Web (80/443): jede Minute aus mindestens drei Regionen; Alarm, wenn zwei oder mehr Standorte bei zwei aufeinanderfolgenden Checks fehlschlagen.
• Mail (25/587/993): alle 1 bis 5 Minuten; Alarm bei zwei aufeinanderfolgenden Fehlern oder einem unerwarteten Banner.
• Datenbank-Health (intern): jede Minute; Alarm nach zwei bis drei aufeinanderfolgenden Fehlern.
• Datenbank-Exposition (extern): alle 5 bis 15 Minuten; Alarm beim ersten Ergebnis „offen“.
• Latenz: Warnung, wenn die Verbindungszeit dauerhaft beim Zwei- bis Dreifachen der Baseline liegt.

Einen umfassenderen Überblick bieten unsere Best Practices für Port-Monitoring.

Umsetzung mit UpScanX

UpScanX Port-Monitoring führt TCP- und UDP-Port-Checks von über 15 globalen Standorten aus – mit Service-Fingerprinting und Versionserkennung, protokollspezifischer Antwortvalidierung sowie Messung von Verbindungszeit und Antwortlatenz. Es vergleicht den Port-Status mit einer Konfigurations-Baseline, erkennt unerwartete Dienste und alarmiert per E-Mail, Slack, Telegram, Microsoft Teams oder Webhook.

Wichtigste Erkenntnisse

• Validieren Sie auf jedem Port die Protokollantwort, nicht nur den TCP-Connect.
• Prüfen Sie öffentliche Web- und Mail-Ports aus mehreren Regionen und alarmieren Sie erst bei Übereinstimmung.
• Überwachen Sie die Datenbank-Health intern und behandeln Sie öffentliche Erreichbarkeit als Incident.
• Führen Sie ein Inventar der erwarteten Ports und alarmieren Sie bei jeder Abweichung davon.