So überwachen Sie einen TCP-Port (und wann Sie bei einem offenen Port alarmieren sollten)

Port-Überwachung ist zwei Aufgaben in einer. Manchmal möchten Sie wissen, dass ein Dienst lauscht, wie eine Datenbank oder ein SMTP-Relay. Manchmal möchten Sie wissen, dass ein Port durch die Firewall blockiert bleibt, wie SSH auf einer Instanz mit Internetzugang. Dieselbe Probe beantwortet beide Fragen, aber Sie alarmieren bei entgegengesetzten Ergebnissen. Dieser Leitfaden behandelt, wann welcher Modus zu verwenden ist, worauf zu alarmieren ist und welche Ports gerne übersehen werden.

Wie ein TCP-Port-Monitor tatsächlich funktioniert

Ein TCP-Port-Monitor öffnet einen Socket zum Ziel auf dem gewählten Port und wartet darauf, dass der Drei-Wege-Handshake abgeschlossen wird. Wenn der Handshake gelingt, ist der Port offen. Wenn die Verbindung abgelehnt wird, ist der Port geschlossen. Wenn die Verbindung in eine Zeitüberschreitung läuft, verwirft etwas zwischen dem Prober und Ihrem Host das Paket, in der Regel eine Firewall.

Die Probe spricht kein Protokoll auf dem Socket. Sie verhandelt kein TLS, tauscht keine SSH-Banner aus und führt keine Datenbankabfrage aus. Sie sagt Ihnen nur, ob der Port antwortet. Für die Gesundheit auf Anwendungsebene benötigen Sie eine zusätzliche HTTP- oder benutzerdefinierte Prüfung.

Wenn der Port OFFEN sein soll

Verwenden Sie die Port-Überwachung als Probe für die Dienstgesundheit, wenn Sie nicht ohne Weiteres eine HTTP-Prüfung durchführen können. Fünf häufige Fälle kommen vor.

• Datenbankserver auf Port 5432 (Postgres), 3306 (MySQL), 6379 (Redis), 27017 (MongoDB). Wenn der Listener abstürzt, fällt jeder abhängige Dienst aus, aber Sie können keine HTTP-Probe ausführen.
• SMTP-Relays auf Port 25 oder 587. SMTP-Banner-Prüfungen erkennen Listener-Abstürze, die interne Health-Endpunkte übersehen.
• Game-Server und andere benutzerdefinierte TCP-Protokolle, die kein HTTP sprechen.
• Interne Load Balancer, die einen Nicht-HTTP-Health-Port für vorgelagerte Dienste bereitstellen.
• VPN-Endpunkte auf UDP- aber auch TCP-Ports wie 443 für OpenVPN-TCP und WireGuard.

Wenn der Port GESCHLOSSEN sein soll

Invertierte Port-Überwachung ist ein Sicherheitsschutz. Sie konfigurieren den Monitor so, dass er alarmiert, wenn der Port offen wird, weil er niemals aus dem öffentlichen Internet zugänglich sein sollte. Das Muster erkennt die Dinge, die im normalen Wochenverlauf von Infrastrukturänderungen schiefgehen.

Jemand öffnet vorübergehend eine Firewall-Regel zum Debuggen und vergisst, sie zurückzusetzen. Ein Kubernetes-Service erhält versehentlich den Typ LoadBalancer. Eine neue Instanz bekommt die falsche Sicherheitsgruppe. Eine Änderung an einem Terraform-Modul legt einen Port offen, der intern hätte bleiben sollen. In jedem Fall erkennt der invertierte Port-Monitor die Offenlegung innerhalb eines Prüfintervalls.

Die wertvollsten Ports, die Sie jetzt invertiert überwachen sollten

Für jeden Host mit Internetzugang, der diese Ports nicht offenlegen sollte, lohnt es sich, fünf Ports invertiert zu prüfen.

• 22 (SSH) auf Produktions-Anwendungsservern. Der Zugriff nur über Bastion ist die Norm, und ein versehentlich offener SSH-Port taucht innerhalb von Stunden in Massenscan-Protokollen auf.
• 3306 (MySQL) und 5432 (Postgres). Öffentliche Datenbank-Ports sind für einen erheblichen Anteil von Credential-Stuffing-Angriffen verantwortlich.
• 6379 (Redis). Offenes Redis ohne Authentifizierung ist eine der am häufigsten ausgenutzten Fehlkonfigurationen der Branche.
• 27017 (MongoDB). Dieselbe Geschichte wie bei Redis. Standardkonfiguration, keine Authentifizierung, öffentlicher Port bedeutet Datenverlust.
• 9200 (Elasticsearch). Offene Cluster werden innerhalb von Stunden gescraped, für Mining missbraucht und erpresst.

Alarm-Schwellenwerte für die Port-Überwachung

Für die Dienstgesundheit (Port sollte OFFEN sein) gilt dasselbe Schwellenmuster wie für HTTP: nach 3 aufeinanderfolgenden Fehlern alarmieren, kurze Aussetzer unterdrücken. Netzwerk-Aussetzer, die eine einzelne Probe schließen, sind Rauschen.

Für die Sicherheit (Port sollte GESCHLOSSEN sein) gilt das Gegenteil. Alarmieren Sie bei der ersten Erkennung. Ein versehentlich offener SSH- oder Redis-Port ist ein Fünf-Alarm-Ereignis. Bots scannen das öffentliche Internet ununterbrochen, und das Zeitfenster zwischen Offenlegung und Kompromittierung auf einem bekannten Port wird in Minuten gemessen.

Eine Einstiegs-Checkliste für die Sicherheits-Port-Überwachung

Für jede IP mit Internetzugang, die Ihr Team betreibt, richten Sie invertierte Monitore auf 22, 3306, 5432, 6379 und 27017 mit einem Intervall von 60 Sekunden ein. Leiten Sie die Warnungen getrennt von Ihren Dienstgesundheits-Warnungen an Ihren Sicherheitskanal. Führen Sie einmal pro Quartal als Kontrolle einen echten Port-Scan gegen Ihre eigenen IPs durch. Die Kosten sind gering, die Abdeckung ist breit, und die abgefangenen Fehlerfälle sind katastrophal.