Welche Ports sollten Sie in der Produktionsinfrastruktur zuerst überwachen?

Beginnen Sie mit den Ports, die Ihre Kunden direkt nutzen: HTTPS auf 443, die Weiterleitung auf 80, API-Gateway-Ports sowie DNS oder SMTP, sofern Sie diese selbst betreiben. Decken Sie danach interne Abhängigkeiten ab, die den gesamten Stack lahmlegen können, etwa Datenbanken, Caches und Message Queues. Überwachen Sie schließlich Management-Ports wie SSH, RDP und die Docker-API, um sicherzustellen, dass sie aus dem Internet nicht erreichbar sind.

Ports nach Auswirkung priorisieren, nicht nach Nummer

Wer jeden lauschenden Dienst gleichzeitig überwacht, erzeugt viele Fehlalarme und keine klare Zuständigkeit. Bewerten Sie stattdessen jeden Port anhand von drei Fragen, bevor Sie einen Check anlegen:

1. Auswirkung auf Kunden und Umsatz. Wenn dieser Port nicht mehr antwortet: Sehen Nutzer Fehler, schlägt der Checkout fehl, laufen API-Clients in Timeouts?
2. Single Point of Failure. Steht dahinter genau eine primäre Datenbank, ein Broker oder ein Load Balancer, oder gibt es ein automatisches Failover?
3. Expositionsrisiko. Wäre es ein Sicherheitsvorfall, wenn dieser Port aus dem öffentlichen Internet erreichbar würde?

Hohe Werte bei den ersten beiden Fragen ordnen einen Port einer Verfügbarkeitsstufe zu. Ein hoher Wert bei der dritten ordnet ihn einer Expositionsstufe zu, in der „offen“ die Alarmbedingung ist.

Stufe 1: Öffentliche Einstiegspunkte

Richten Sie diese Checks zuerst ein, typischerweise mit 30–60 Sekunden Intervall aus mehreren Regionen:

• 443 (HTTPS): Ihre wichtigste Eingangstür. Prüfen Sie den TLS-Handshake, nicht nur den TCP-Verbindungsaufbau.
• 80 (HTTP): sollte mit einer Weiterleitung auf 443 antworten. Eine defekte Weiterleitung lässt Nutzer, die über alte Links kommen, ins Leere laufen.
• API-Gateway-Ports (zum Beispiel 8443 oder ein eigener gRPC-Port), die Partner oder mobile Apps direkt aufrufen.
• 53 über TCP und UDP, wenn Sie Ihr autoritatives DNS selbst hosten. UDP trägt die meisten Anfragen, TCP übernimmt große Antworten und Zonentransfers – prüfen Sie also beides.
• 25, 465 oder 587, wenn Sie Transaktions-E-Mails über eigene Relays versenden. Fällt SMTP unbemerkt aus, kommen Passwort-Resets und Rechnungen nicht mehr an.

Checks von mehreren Standorten sind wichtig, weil eine Firewall- oder CDN-Änderung einen Port in einer Region offen und in einer anderen gefiltert hinterlassen kann.

Stufe 2: Interne Abhängigkeiten

Diese Dienste sollten nicht öffentlich sein. Prüfen Sie sie daher aus dem eigenen Netzwerk heraus oder von einer Monitoring-IP, die in Ihrer Firewall ausdrücklich freigegeben ist:

• 5432 (PostgreSQL) und 3306 (MySQL): sowohl Primary- als auch Replica-Endpunkte.
• 6379 (Redis): Caches fallen oft unbemerkt aus und überlasten dann die dahinterliegende Datenbank.
• 5672 (RabbitMQ) und 9092 (Kafka): Ein hängender Broker staut jeden asynchronen Job.
• Listener interner Load Balancer vor den einzelnen Service-Schichten.

Erfassen Sie neben dem Up/Down-Status auch die Verbindungszeit. Braucht ein Datenbank-Port 800 ms statt 5 ms, um eine Verbindung anzunehmen, deutet das häufig auf einen erschöpften Connection Pool oder einen überlasteten Host hin.

Stufe 3: Ports, die geschlossen bleiben sollten

Die letzte Stufe kehrt die Logik um. Sie alarmieren, wenn diese Ports aus dem öffentlichen Internet erreichbar sind:

Port	Dienst	Warum öffentliche Erreichbarkeit riskant ist
22	SSH	Ständiges Ziel von Brute-Force- und Credential-Stuffing-Angriffen
3389	RDP	Häufiges Einfallstor für Ransomware
2375 / 2376	Docker-API	2375 ist nicht authentifiziert und gewährt Kontrolle über den Host
6443	Kubernetes-API	Sollte auf erlaubte IP-Bereiche oder private Netzwerke beschränkt sein
9200	Elasticsearch	Häufige Quelle offengelegter Daten
27017	MongoDB	Wurde in der Vergangenheit massenhaft gescannt und gelöscht, wenn offen

Führen Sie diese Checks alle 5–15 Minuten von externen Standorten aus. So erkennen Sie eine gelockerte Security Group, ein fehlerhaft konfiguriertes Helm-Chart oder einen vergessenen Debug-Port.

So setzen Sie das mit UpScanX um

Das Port-Monitoring von UpScanX führt TCP- und UDP-Checks von über 15 globalen Standorten aus und eignet sich damit für eine schrittweise Einführung:

1. Woche 1: Legen Sie die Checks der Stufe 1 mit protokollspezifischer Antwortvalidierung an, damit auch ein Port alarmiert, der Verbindungen annimmt, aber fehlerhafte Antworten liefert.
2. Woche 2: Ergänzen Sie die Checks der Stufe 2 überall dort, wo Ihr Netzwerk Monitoring-Zugriff erlaubt, und nutzen Sie die Messung von Verbindungszeit und Antwortlatenz. Warnen Sie ab etwa dem 2- bis 3-Fachen der normalen Verbindungszeit.
3. Woche 3: Erfassen Sie eine Konfigurations-Baseline für Stufe 3 und aktivieren Sie die Erkennung von Port-Statusänderungen. Service-Fingerprinting mit Versionserkennung meldet zudem einen Port, auf dem nginx laufen sollte, der sich aber plötzlich als etwas anderes identifiziert.

Leiten Sie Alarme der Stufe 1 an Slack oder Microsoft Teams, wo Ihr Team sie sofort sieht, und senden Sie Expositionsalarme der Stufe 3 per E-Mail oder Webhook an Ihr Security-Team. Was Sie an jedem offenen Port prüfen sollten, zeigt unsere Checkliste zur Überwachung kritischer offener Ports.

Wichtigste Erkenntnisse

• Priorisieren Sie nach Kundenauswirkung, Single Points of Failure und Expositionsrisiko statt nach Portnummer.
• Überwachen Sie zuerst öffentliche Einstiegspunkte, dann interne Datenabhängigkeiten, dann Management-Ports.
• Messen Sie die Verbindungslatenz, nicht nur die Erreichbarkeit, um Verschlechterungen früh zu erkennen.
• Überprüfen Sie die Liste nach größeren Infrastrukturänderungen; neue Dienste bringen unbemerkt neue Ports mit.