端口开放得多，不代表业务更稳定；规则写得过宽，反而会增加暴露面。做好抗攻击主机接入前的业务协议与端口梳理，关键是弄清每项服务由谁访问、使用什么协议，以及流量从哪里来、要到哪里去。
先画出业务通信清单
不要只向运维或开发询问“需要开哪些端口”。应把每条通信拆成客户端或来源、目标主机、协议、目标端口、方向和用途。这里的方向以受保护主机为参照：外部访问主机是入站，主机主动连接外部是出站。
| 常见用途 | 常见协议与端口 | 梳理时关注 |
|---|---|---|
| 安全外部访问网站 | TCP 443 | 确认是否还有其他对外服务，不要因网站可访问就放开全部端口。 |
| 远程管理 Linux 主机 | SSH 通常使用 TCP 22 | 核实管理来源地址；如使用非标准端口，应记录实际配置。 |
| 远程管理 Windows 主机 | RDP 通常使用 TCP 3389 | 明确是否需要公网访问，优先限制来源范围并采用额外身份验证。 |
| 域名解析 | DNS 常见为 UDP 53，也可能使用 TCP 53 | 依据解析服务的实际部署确认请求方向和目标。 |
| 应用连接 PostgreSQL | TCP 5432 是常见默认端口 | 仅允许确有需要的应用来源访问，不应扩大到无关主机。 |
这些是常见默认值，不是所有环境的固定配置。服务可能改用其他端口，最终应以主机监听情况、应用配置和现有防火墙策略为准。协议与端口必须成对记录；只写“开放 443”而不写 TCP、来源及用途，仍不足以形成准确规则。
按步骤核实接入需求
- 盘点正在提供的服务：分别询问业务负责人、系统管理员和网络管理员，核对网站、远程管理、解析、邮件或数据库等实际用途。未确认用途的监听端口，先标记待核实，不直接加入允许清单。
- 查明流量路径：记录访问者地址范围、主机地址、前置设备和目标端口。若存在地址转换或端口映射，还要确认转换前后的地址、端口及设备位置。
- 区分入站规则和出站规则：外部用户访问服务通常需要入站许可；主机向解析服务器、更新站点或其他业务系统发起连接，则涉及出站策略。不要因为开放了入站端口，就推断相关出站通信也已放通。
- 缩小来源范围：管理服务尽量使用源地址白名单，只允许约定的办公出口、专用管理网络或跳板机来源。业务确需广泛访问时，应写明理由，并确认保护设备对该协议和流量类型的支持情况。
- 测试并留存结果：先按计划配置规则，再分别验证正常业务、管理访问和必要的出站连接。记录测试时间、来源、目标、协议、端口及结果；变更后也检查日志，确认是否出现误拦截。
防护规则要与业务边界一致
接入抗攻击主机前的业务协议与端口梳理，不应只追求“能通”。例如，HTTPS 服务需要对外提供访问，不等于 SSH 或 RDP 也应该向所有来源开放。对于仅供内部系统调用的服务，应明确其可访问来源；对于主机主动访问外部的需求，也要注明目的地址或服务范围，避免配置成不受限制的出站通道。
还应向防护服务提供方确认规则覆盖范围：哪些协议和端口可以纳入防护，是否支持自定义端口，源站如何识别转发后的真实访问来源，以及规则变更和异常拦截如何处理。不同产品的能力和配置方式可能不同，不能仅凭“抗攻击”名称推断所有流量都受同等保护。
交付一份可复核的清单
最终清单至少包含业务名称、来源范围、目标主机、通信方向、传输协议、端口、用途、负责人和验证结果。接入抗攻击主机前的业务协议与端口梳理完成后，再将清单逐项对应到防护策略；业务变更时同步更新，删除已停用的规则。这样既便于定位连接失败，也能减少长期遗留的开放项。
常见问题
只知道端口，不知道协议，可以先放行吗？
不建议。相同端口号在不同协议下是不同的通信规则，应先查明应用实际使用 TCP、UDP 或其他协议，再配置。
非标准端口是否更安全？
更换端口可能减少部分自动化扫描噪声，但不能替代身份验证、访问范围限制和系统更新，也不能据此把来源限制取消。
接入后业务不通，先检查什么？
按清单核对来源地址是否变化、方向是否判断正确、协议与端口是否匹配，以及是否存在地址转换或额外网络策略；再结合防护侧和主机侧日志定位。