攻击正在持续时，逐台主机盲目关端口既慢，也可能中断正常业务。攻击期间业务端口暴露面排查流程应先确定外部实际可达的入口，再结合用途和风险排优先级，最后验证变更是否生效。以下五步适用于云主机、数据中心和混合环境；操作前应确认资产归属与授权范围。
第一步：划定范围，保留现场信息
先记录受影响的域名、公网地址、负载均衡器、主机及业务负责人，并注明排查时间、时区和攻击现象。把资产清单与云平台实例、DNS记录、负载均衡监听器、NAT映射、主机防火墙及容器入口配置交叉核对，避免只检查服务器而漏掉转发层。保存变更前规则和告警记录，注明配置来源；这有助于回滚，也能区分原有暴露与攻击期间新增的变化。
范围分为两类：一类是已知受影响系统及其入口，优先检查；另一类是同一业务边界内可能共享入口或凭据的资产，作为后续扩展范围。未经授权不要对第三方地址扫描，也不要为求快而大范围探测。
第二步：确认哪些端口从外部真正可达
对照配置与实际连通性。安全组或防火墙显示允许，并不代表公网一定能访问；反过来，负载均衡转发、端口映射或上游规则也可能让主机配置中看似关闭的服务仍然可达。应从获准的外部网络位置，对照业务入口逐项验证，并由资产侧确认端口对应的进程、服务和负责人。
重点辨认端口用途，而不是只看数字：80、443常用于网页入口，22常用于SSH管理，3306常用于MySQL，6379常用于Redis。它们只是常见默认值，服务也可能配置在其他端口；端口开放本身不能证明服务存在漏洞，但管理面或数据服务直接面向公网通常需要优先核实。记录协议、来源范围、目的资产、服务用途和验证时间，形成可复查清单。
第三步：按风险排序，先处理高危入口
给每项暴露标注三个因素：外部可达程度、服务敏感性、业务影响。可按高、中、低分级，不必假装有适用于所有环境的精确分数。无需公网访问的数据库或管理服务，通常应排在公开网页入口之前；已确认被攻击利用、服务负责人不明或来源范围过宽的项目，也应提升优先级。
- 高：不需要公网访问的管理或数据端口对任意来源开放，或已与当前攻击现象相关。优先限制来源、关闭不必要监听，必要时先由业务负责人确认替代访问路径。
- 中：对公网开放但有明确业务用途的服务。核查监听范围、访问控制和维护责任，优先缩小不必要的来源范围。
- 低：经确认的公开业务入口，配置与用途一致且监测正常。保留必要访问，持续观察，不因端口开放就直接下线。
排序时同步记录处置负责人、预计影响和回滚条件。攻击期间若无法立即关闭端口，先采取范围更小、可撤销的限制措施，并明确复查时间。
第四步：实施最小变更，避免扩大故障
从变更影响较小的规则开始：删除过期放行项、收窄来源范围、停止不再使用的监听，再评估是否需要关闭公网入口。云安全组、主机防火墙和负载均衡器可能同时生效，修改一层后要确认流量路径，不能把规则“看起来已改”当成完成。
每项变更应保留修改前后配置、操作人、时间及业务确认结果。若服务确需远程管理，优先采用组织已批准的受控接入方式，而非临时把管理端口重新对公网开放。发生连接异常时按预设条件回滚，并记录回滚原因；不要在攻击期间同时改动大量无关配置。
第五步：从独立视角复核并闭环
处置后，从与初次验证不同的获准网络位置重新检查目标端口；同时核对云侧规则、主机监听状态和负载均衡转发。外部不可达但内部配置仍放行，或外部探测失败却业务健康检查异常，都需要继续判断，不能只凭一次探测下结论。对于必须保留的入口，复核其来源范围、服务归属和监控告警是否符合预期。
最终清单至少标记“已关闭”“已限制”“业务保留”“待确认”及对应证据。设置后续复查时间，并让非变更执行者抽查高优先级项目。这样，攻击期间业务端口暴露面排查流程才从临时封堵变成可验证、可追踪的处置闭环。
常见问题
端口扫描显示开放，就代表服务有漏洞吗？
不代表。它只说明在特定时间、网络位置和探测方式下端口可连接，还需确认服务身份、用途、访问控制及漏洞情况。
能否一次性关闭所有非标准端口？
不建议。非标准端口可能承载正常业务；应先查明进程、转发关系和负责人，再决定限制或关闭。
从内部检查可以替代外部复测吗？
不能完全替代。内部检查用于核对配置和监听，外部复测用于确认真实可达性，两者应结合。
攻击期间业务端口暴露面排查流程多久复查一次？
高风险变更后应尽快复测；之后的频率依资产重要性、攻击态势和组织变更制度确定，不宜套用固定周期。