How to Monitor a TCP Port (And When to Alert on One Being Open)

Port monitoring is two jobs in one. Sometimes you want to know that a service is listening, like a database or an SMTP relay. Sometimes you want to know that a port stays firewalled off, like SSH on an internet-facing instance. The same probe answers both questions but you alert on opposite results. This guide covers when to use each mode, what to alert on, and the ports that catch people out.

How a TCP port monitor actually works

A TCP port monitor opens a socket to the target on the chosen port and waits for the three-way handshake to complete. If the handshake succeeds, the port is open. If the connection is refused, the port is closed. If the connection times out, something between the prober and your host is dropping the packet, usually a firewall.

The probe does not speak a protocol on top of the socket. It does not negotiate TLS, exchange SSH banners, or run a database query. It only tells you whether the port answers. For application-layer health you need an HTTP or custom check on top.

When you want the port OPEN

Use port monitoring as a service-health probe when you cannot easily do an HTTP check. Five common cases come up.

• Database servers on port 5432 (Postgres), 3306 (MySQL), 6379 (Redis), 27017 (MongoDB). If the listener crashes, every dependent service breaks, but you cannot run an HTTP probe.
• SMTP relays on port 25 or 587. SMTP banner checks catch listener crashes that internal health endpoints miss.
• Game servers and other custom TCP protocols that do not speak HTTP.
• Internal load balancers that expose a non-HTTP health port to upstream services.
• VPN endpoints on UDP-but-also-TCP ports like 443 for OpenVPN-TCP and WireGuard.

When you want the port CLOSED

Inverted port monitoring is a security guardrail. You set the monitor to alert when the port becomes open, because it should never be open from the public internet. The pattern catches the things that go wrong during a normal week of infrastructure changes.

Someone temporarily opens a firewall rule for debugging and forgets to revert. A Kubernetes service gets a LoadBalancer type by accident. A new instance gets the wrong security group. A Terraform module change exposes a port that was supposed to be internal. In every case, the inverted port monitor catches the exposure within one check interval.

The high-value ports to inverted-monitor right now

Five ports are worth setting up an inverted check on for any internet-facing host that should not be exposing them.

• 22 (SSH) on production application servers. Bastion-only access is the norm, and an accidentally-open SSH port shows up in mass-scan logs within hours.
• 3306 (MySQL) and 5432 (Postgres). Public database ports are responsible for a meaningful share of credential-stuffing attacks.
• 6379 (Redis). Open Redis with no authentication is one of the most-exploited misconfigurations in the industry.
• 27017 (MongoDB). Same story as Redis. Default config, no auth, public port equals data loss.
• 9200 (Elasticsearch). Open clusters get scraped, mined, and ransomed in hours.

Alert thresholds for port monitoring

Service-health (port should be OPEN) wants the same threshold pattern as HTTP: alert after 3 consecutive failures, suppress short flaps. Network blips that close a single probe are noise.

Security (port should be CLOSED) wants the opposite. Alert on the first detection. An accidentally-open SSH or Redis port is a five-alarm event. Bots are scanning the public internet constantly, and the window between exposure and compromise on a well-known port is measured in minutes.

A starter security port-monitoring checklist

For every internet-facing IP your team operates, set inverted monitors on 22, 3306, 5432, 6379, and 27017 at a 60-second interval. Route the alerts to your security channel separately from your service-health alerts. Once a quarter, run a real port scan against your own IPs as a control. The cost is small, the cover is wide, and the failure modes it catches are catastrophic.