如何监控 TCP 端口（以及何时对端口开放发出告警）

端口监控其实是两项工作合二为一。有时你想知道某个服务正在监听，比如数据库或 SMTP 中继。有时你想知道某个端口保持被防火墙阻断，比如面向互联网实例上的 SSH。同一探测能回答这两个问题，但你对相反的结果发出告警。本指南介绍何时使用每种模式、应针对什么进行告警，以及容易让人栽跟头的端口。

TCP 端口监控的实际工作方式

TCP 端口监控会向目标在所选端口上打开一个套接字，并等待三次握手完成。如果握手成功，端口是开放的。如果连接被拒绝，端口是关闭的。如果连接超时，说明探测器和你的主机之间有什么东西在丢弃数据包，通常是防火墙。

该探测不会在套接字之上运行任何协议。它不会协商 TLS、交换 SSH 横幅或运行数据库查询。它只告诉你端口是否响应。对于应用层的健康状况，你需要在其之上添加 HTTP 或自定义检查。

当你希望端口为 OPEN 时

当你无法轻松进行 HTTP 检查时，可以将端口监控用作服务健康探测。常见有五种情况。

• 数据库服务器在端口 5432（Postgres）、3306（MySQL）、6379（Redis）、27017（MongoDB）上。如果监听器崩溃，每个依赖服务都会中断，但你无法运行 HTTP 探测。
• SMTP 中继在端口 25 或 587 上。SMTP 横幅检查能捕捉到内部健康端点漏掉的监听器崩溃。
• 游戏服务器和其他不使用 HTTP 的自定义 TCP 协议。
• 内部负载均衡器，向上游服务暴露非 HTTP 健康端口。
• VPN 端点，使用 UDP 同时也使用 TCP 的端口，比如 OpenVPN-TCP 和 WireGuard 使用的 443。

当你希望端口为 CLOSED 时

反向端口监控是一种安全防护机制。您将监控设置为在端口变为开放时发出告警，因为该端口本就不应从公共互联网开放。这种模式可捕获基础设施变更过程中那些一周内会出现的常见问题。

有人为了调试临时开放了防火墙规则却忘了恢复。某个 Kubernetes 服务被意外设置为 LoadBalancer 类型。新实例被分配了错误的安全组。Terraform 模块变更暴露了一个本应仅供内部使用的端口。在每种情况下，反向端口监控都能在一个检查间隔内捕获到这种暴露。

当下值得反向监控的高价值端口

对于任何不应暴露这些端口的面向互联网主机，有五个端口值得设置反向检查。

• 22 (SSH) 在生产应用服务器上。仅堡垒机访问是常态，意外开放的 SSH 端口会在几小时内出现在大规模扫描日志中。
• 3306 (MySQL) 和 5432 (Postgres)。公开的数据库端口在凭证填充攻击中占有相当大的比例。
• 6379 (Redis)。未启用身份验证的开放 Redis 是业界被利用最多的配置错误之一。
• 27017 (MongoDB)。与 Redis 情况相同。默认配置、无身份验证、公开端口，等于数据丢失。
• 9200 (Elasticsearch)。开放的集群会在数小时内被抓取、挖矿和勒索。

端口监控的告警阈值

服务健康监控（端口应为开放状态）需要与 HTTP 相同的阈值模式：连续 3 次失败后告警，抑制短暂抖动。导致单次探测关闭的网络小故障只是噪声。

安全监控（端口应为关闭状态）则相反。首次检测到时即告警。意外开放的 SSH 或 Redis 端口属于五级警报事件。机器人持续扫描公共互联网，知名端口从暴露到被攻陷的窗口期以分钟计。

安全端口监控入门检查清单

为您团队运营的每一个面向互联网的 IP，以 60 秒为间隔对端口 22、3306、5432、6379 和 27017 设置反向监控。将这些告警与服务健康告警分开路由至您的安全频道。每季度一次，对您自己的 IP 进行真正的端口扫描作为对照。成本很低，覆盖面很广，而它能捕获的故障模式则可能是灾难性的。