Een TCP-poort monitoren (en wanneer je moet alarmeren als er een open staat)

Poortmonitoring is twee taken in één. Soms wil je weten dat een service luistert, zoals een database of een SMTP-relay. Soms wil je weten dat een poort dichtgezet blijft achter de firewall, zoals SSH op een instance die aan het internet hangt. Dezelfde probe beantwoordt beide vragen, maar je alarmeert op tegengestelde resultaten. Deze gids behandelt wanneer je welke modus gebruikt, waarop je alarmeert en de poorten die mensen vaak verrassen.

Hoe een TCP-poortmonitor daadwerkelijk werkt

Een TCP-poortmonitor opent een socket naar het doel op de gekozen poort en wacht tot de three-way handshake voltooid is. Als de handshake slaagt, staat de poort open. Wordt de verbinding geweigerd, dan is de poort gesloten. Loopt de verbinding af in een timeout, dan dropt iets tussen de prober en je host het pakket, meestal een firewall.

De probe spreekt geen protocol bovenop de socket. Hij onderhandelt geen TLS, wisselt geen SSH-banners uit en draait geen databasequery. Hij vertelt je alleen of de poort antwoordt. Voor gezondheid op applicatieniveau heb je daarbovenop een HTTP- of custom check nodig.

Wanneer je de poort OPEN wilt

Gebruik poortmonitoring als servicegezondheidsprobe wanneer je niet eenvoudig een HTTP-check kunt doen. Er zijn vijf veelvoorkomende gevallen.

• Databaseservers op poort 5432 (Postgres), 3306 (MySQL), 6379 (Redis), 27017 (MongoDB). Als de listener crasht, breekt elke afhankelijke service, maar je kunt geen HTTP-probe uitvoeren.
• SMTP-relays op poort 25 of 587. SMTP-bannercontroles vangen listener-crashes op die interne health-endpoints missen.
• Game servers en andere custom TCP-protocollen die geen HTTP spreken.
• Interne load balancers die een niet-HTTP-healthpoort blootstellen aan upstream-services.
• VPN-endpoints op UDP-maar-ook-TCP-poorten zoals 443 voor OpenVPN-TCP en WireGuard.

Wanneer je de poort GESLOTEN wilt

Omgekeerde poortmonitoring is een beveiligingsvangrail. Je stelt de monitor in om te alarmeren wanneer de poort open komt te staan, omdat hij nooit open zou mogen staan vanaf het publieke internet. Dit patroon vangt de dingen op die misgaan tijdens een normale week aan infrastructuurwijzigingen.

Iemand opent tijdelijk een firewallregel om te debuggen en vergeet die terug te draaien. Een Kubernetes-service krijgt per ongeluk het type LoadBalancer. Een nieuwe instance krijgt de verkeerde security group. Een wijziging in een Terraform-module stelt een poort bloot die intern had moeten blijven. In elk geval vangt de omgekeerde poortmonitor de blootstelling binnen één checkinterval op.

De waardevolle poorten om nu omgekeerd te monitoren

Vijf poorten zijn de moeite waard om een omgekeerde controle op in te stellen voor elke host die met het internet verbonden is en deze niet zou mogen blootstellen.

• 22 (SSH) op productieapplicatieservers. Toegang via uitsluitend een bastion is de norm, en een per ongeluk openstaande SSH-poort verschijnt binnen enkele uren in massascanlogboeken.
• 3306 (MySQL) en 5432 (Postgres). Publieke databasepoorten zijn verantwoordelijk voor een aanzienlijk deel van de credential-stuffing-aanvallen.
• 6379 (Redis). Open Redis zonder authenticatie is een van de meest misbruikte misconfiguraties in de branche.
• 27017 (MongoDB). Hetzelfde verhaal als Redis. Standaardconfiguratie, geen authenticatie, publieke poort staat gelijk aan dataverlies.
• 9200 (Elasticsearch). Open clusters worden binnen enkele uren geschraapt, gemined en geransomed.

Waarschuwingsdrempels voor poortmonitoring

Servicegezondheid (poort moet OPEN zijn) vraagt om hetzelfde drempelpatroon als HTTP: waarschuwen na 3 opeenvolgende mislukkingen, korte fluctuaties onderdrukken. Netwerkstoringen die een enkele probe sluiten zijn ruis.

Beveiliging (poort moet GESLOTEN zijn) vraagt om het tegenovergestelde. Waarschuw bij de eerste detectie. Een per ongeluk openstaande SSH- of Redis-poort is een gebeurtenis van het hoogste alarmniveau. Bots scannen het publieke internet voortdurend, en het tijdsbestek tussen blootstelling en compromittering op een bekende poort wordt in minuten gemeten.

Een startchecklist voor beveiligingspoortmonitoring

Stel voor elk met het internet verbonden IP-adres dat uw team beheert omgekeerde monitors in op 22, 3306, 5432, 6379 en 27017 met een interval van 60 seconden. Stuur de waarschuwingen apart naar uw beveiligingskanaal, los van uw servicegezondheidswaarschuwingen. Voer eens per kwartaal een echte poortscan uit op uw eigen IP-adressen ter controle. De kosten zijn laag, de dekking is breed, en de faalmodi die hiermee worden opgevangen zijn catastrofaal.