先验证后封堵再根治
发现高危端口暴露（Redis 6379、Elasticsearch 9200、MongoDB 27017、Memcached 11211、Docker 2375/2376、Hadoop 8088、Rsync 873 等）时，处置要按固定顺序：先验证连通性与数据可达性（确认是自有资产）、再做边界止血（安全组或防火墙限源/封禁）、然后根治（改配置绑定地址、开启认证、升级版本）、最后复核（外部复测与日志确认无异常访问）。顺序颠倒会带来两种典型问题：上来就改配置可能直接中断业务且难以回滚；只封边界不根治，下一轮检查依旧命中。
基本信息
| 加固项 | 暴露面应急收敛与闭环 |
|---|---|
| 适用平台 | 全部平台（Linux、Windows、云主机、容器） |
| 权限要求 | 运维与网络管理员 |
| 达标判据 | 高危端口不再对外可达，且有整改记录 |
| 参考流程 | NIST SP 800-61 事件处置、等保边界防护要求 |
典型使用场景
- 暴露面扫描发现数据库或缓存端口对公网开放
- 攻防演练期间紧急收敛暴露面
- 收到云厂商或监管的暴露端口通告后处置
- 应急响应中先止血再追溯攻击者的访问范围
- 基线巡检发现的遗留问题进入整改闭环
处置流程骨架
处置流程骨架
# 1) 验证：确认端口开放与数据可达（自有资产、受控前提下）
ss -tulnp | grep -E ':(6379|9200|27017|11211|2375|2376|8088|873)'
# 2) 边界止血：安全组或防火墙先限来源（改前导出规则留档）
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.20.0.0/16" port port="6379" protocol="tcp" accept'
# 3) 根治：改配置（绑定地址、认证开关）+ 升级版本
# 4) 复核：外部复测 + 查访问日志确认无异常来源常见高危端口与根治方向
| 端口与服务 | 典型风险 | 根治方向 |
|---|---|---|
| 6379 Redis | 未授权写入、写密钥登录 | 绑回环、设置认证、改名高危命令 |
| 9200 Elasticsearch | 未授权读写索引、泄漏业务数据 | 开启安全认证、绑内网、限制来源 |
| 27017 MongoDB | 未开启认证时可直接清库 | 启用 authorization、收敛绑定地址 |
| 11211 Memcached | 数据泄露与 UDP 放大 | 关 UDP、绑回环、必要时启用 SASL |
| 2375/2376 Docker | 无认证时等同宿主机 root | 禁止对外暴露，改用 TLS 与受限接口 |
| 873 Rsync | 未授权同步、覆盖文件 | 限制来源、启用认证、避免匿名模块 |
处置前后都要留存证据：扫描输出、变更时间点、规则快照、复测结果。未授权访问类事件往往需要说明“从何时起被关闭”，没有时间戳的整改记录在事后举证时价值有限，也难以证明暴露窗口的长度。
边界止血动作本身也有风险：加限源规则后可能把业务调用方一起挡在外面。稳妥做法是先在非关键链路验证，或先只做监控与告警、再排维护窗口切换规则；同时确认带外通道可用，避免把自己锁在外面。