为什么盯这十几个端口
扫描器与僵尸网络对所有云上地址做的是同一件事：按端口清单逐个尝试。数据库、缓存、消息队列、容器管理接口这些端口的共同特点是——默认安装往往没有认证或只有弱认证，一旦对全网开放，被利用只是时间问题。核查的目标不是「有没有风险」，而是明确列出当前对全网开放的高危端口，并逐个给出处置结论。
基本信息
| 加固项 | 高危端口暴露治理 |
|---|---|
| 适用平台 | 云主机与公网服务器 |
| 风险等级 | 高 |
| 基线 | 数据库、缓存、中间件与管理接口不对公网开放 |
| 核查两条线 | 云侧安全组规则与本机实际监听 |
典型使用场景
- 安全组巡检：定期核对全部安全组里来源为任意地址的高危端口放行
- 上线前检查：确认新部署的组件没有把自己暴露到公网
- 事件前哨：暴露清单是评估机器是否可能已被扫描利用的第一步
- 多云管理：账号多、安全组多时，用统一清单避免漏查
- 整改复核：封禁后从外部重新扫描验证实际连通性
需专项排查的端口清单
需专项排查的端口清单
# Redis 6379 / Elasticsearch 9200-9300 / MongoDB 27017 / Memcached 11211
# MySQL 3306 / PostgreSQL 5432 / MSSQL 1433 / K8s API 6443
# RDP 3389 / SMB 445 / Docker API 2375-2376 / RabbitMQ 5672 与 15672
# 本机自证：确认这些端口是否监听在全部地址
ss -tulnp | grep -E ':(6379|9200|27017|11211|3306|5432|1433|3389|2375|2376)([^0-9]|$)'高危端口与风险点
| 端口 | 服务 | 典型风险 |
|---|---|---|
| 6379 | Redis | 历史版本默认无认证，可被写入公钥或计划任务 |
| 9200-9300 | Elasticsearch | 未授权可读写全部索引，数据泄露与删库事件多发 |
| 27017 | MongoDB | 历史版本默认无认证，数据可直接导出或删除 |
| 11211 | Memcached | 无认证且常被用于放大攻击 |
| 3306 与 5432 | MySQL 与 PostgreSQL | 撞库与弱口令，账号来源未收敛时风险更高 |
| 3389 与 445 | RDP 与 SMB | 爆破与蠕虫横向的高频入口 |
| 2375-2376 | Docker API | 未加密接口等同交出宿主机控制权 |
| 6443 | Kubernetes API | 未收敛来源会暴露集群管理面 |
Redis、Elasticsearch、MongoDB 在部分版本下默认没有认证：对公网暴露等于把数据读写权交给对方。处置顺序是先封边界（安全组与主机防火墙），再补认证与版本升级，两步都要做，只做其中一步仍有被利用的窗口。
安全组放行、主机防火墙拒绝时，扫描结果会自相矛盾；反过来主机监听在内网地址但安全组全开放，也会出现「看起来没暴露」的错觉。结论以外部主机对你真实端口发起连接的实测结果为准，配置只能用来解释原因。
怎么把这件事变成常态
把端口清单固定成检查表，按周或按发布周期跑一遍：云侧用接口导出安全组规则筛来源为任意地址的条目，主机侧用 ss 对照。两侧都收敛后，再定期从外部做一次端口扫描作为独立验证。清单固定的好处是比对简单，出现新增的暴露项立刻能被识别，而不是等到被扫描利用之后才发现。