You monitor open ports per service: check that each expected port accepts connections, validate that the right protocol answers on it, and track connection time against a baseline. Web and mail ports should be checked from several public regions, while database ports should be monitored from an internal or allowlisted vantage point and raise an alert if they ever become publicly reachable.
Why a TCP Connect Is Not Enough
A successful TCP handshake only proves that something is listening. A hung worker pool or a misconfigured proxy can accept connections and return nothing useful. Good port monitoring checks the protocol response: an HTTP status line, a TLS handshake, an SMTP 220 greeting, or a database handshake. Service fingerprinting adds a second signal by confirming which software and version is answering.
Per-Service Reference Table
| Service | Port(s) | What to validate | Exposure expectation |
|---|---|---|---|
| HTTP | 80 | Redirect to HTTPS | Public |
| HTTPS | 443 | TLS handshake, certificate, status | Public |
| MySQL | 3306 | Server greeting and version | Internal only |
| PostgreSQL | 5432 | Reply to SSLRequest | Internal only |
| MongoDB | 27017 | hello command reply |
Internal only |
| Redis | 6379 | +PONG or -NOAUTH |
Internal only |
| SQL Server | 1433 | TDS pre-login reply | Internal only |
| SMTP | 25 | 220 banner, STARTTLS |
Public (MX) |
| Submission | 587 / 465 | 220; STARTTLS / implicit TLS |
Public or restricted |
| IMAP | 143 / 993 | * OK; TLS on 993 |
Public or restricted |
| POP3 | 110 / 995 | +OK; TLS on 995 |
Public or restricted |
Web Servers: Ports 80 and 443
Check both ports from multiple regions. On port 80, expect a 301 or 308 redirect to HTTPS; a 200 may mean the redirect was lost in a config change. On port 443, validate the TLS handshake and certificate, since an expired or mismatched certificate breaks clients even when the port is open. Track connection time separately from response latency: rising connect time points to network or load balancer pressure, rising response time to the application.
Databases: Monitor Privately, Alert on Exposure
Database ports should never be internet-facing, which means two distinct checks:
- Health check from inside. Run it from an internal host or an allowlisted source. MySQL sends a greeting as soon as the connection opens, while PostgreSQL, MongoDB, Redis, and SQL Server wait for the client, so the check must speak first.
- Exposure check from outside. Probe 3306, 5432, 27017, 6379, and 1433 from public locations and treat "open" as the failure state. A security group edit or a container published with the wrong port mapping can expose a database in minutes, and automated scanners find exposed instances quickly.
Mail Services: Read the Banner
Mail protocols announce themselves, which makes them easy to validate. SMTP servers should reply with 220; a 421 means the service is refusing connections. On port 587, confirm STARTTLS is advertised after EHLO; on 465, 993, and 995, confirm the TLS handshake succeeds. IMAP should greet with * OK and POP3 with +OK. Some cloud networks block outbound port 25, so probe from locations where it is permitted.
Intervals and Thresholds
Typical starting points, tuned against your own baseline:
- Web (80/443): every 1 minute from at least three regions; alert when two or more locations fail for two consecutive checks.
- Mail (25/587/993): every 1 to 5 minutes; alert on two consecutive failures or an unexpected banner.
- Database health (internal): every 1 minute; alert after two to three consecutive failures.
- Database exposure (external): every 5 to 15 minutes; alert on the first open result.
- Latency: warn when connection time stays above two to three times its baseline.
For a broader policy view, see our port monitoring best practices.
Putting It Into Practice With UpScanX
UpScanX port monitoring runs TCP and UDP port checks from 15+ global locations, with service fingerprinting and version detection, protocol-specific response validation, and connection time and response latency tracking. It compares port status against a configuration baseline, flags unexpected services, and alerts through Email, Slack, Telegram, Microsoft Teams, or Webhook.
Key Takeaways
- Validate the protocol response on every port, not just the TCP connect.
- Check public web and mail ports from multiple regions and require agreement before alerting.
- Monitor database health internally and treat public reachability as an incident.
- Keep an inventory of expected ports and alert on any change from it.