一次扫描 8000 个端口之后：聊聊公网暴露面

攻击者不需要”黑进”你的系统，他只需要找到一个你忘了关的门。

一切从 nmap 开始

红队评估的第一步永远是侦察（Reconnaissance）。拿到授权后，我对目标的一个 /24 网段做了全端口扫描：

nmap -sS -p- -T4 --min-rate 2000 -oG all.txt 203.0.113.0/24

结果：**254 个 IP，开放端口 8000+**，其中高价值目标（80/443/22/3389/3306/6379 等）集中在 37 个主机上。

⚠️ 免责声明：以下所有内容均为攻防演练场景，请勿对未授权目标执行任何扫描。

高价值目标画像

把 8000 个端口按服务类型归类，大致是这样：

最扎眼的几个发现：

1. Redis 无认证直接暴露公网 —— 经典未授权访问，redis-cli -h x.x.x.x ping 直接回 PONG
2. 一个 Jenkins 开在 8080，管理后台弱口令 admin/admin
3. 摄像头 RTSP 流未加密，ffplay rtsp://... 就能看画面

为什么会出现这么多暴露面

和运维聊完，暴露面失控的原因基本是这四类：

1. 默认端口 + 无认证

# 反面教材
services:
  redis:
    image: redis:latest
    ports:
      - "6379:6379"   # 直接映射到公网，且没设密码

2. 临时开的口子忘了关

线上排查问题临时 iptables -A INPUT -p tcp --dport 9000 -j ACCEPT，问题解决后没人回收规则。

3. 云安全组规则太宽

0.0.0.0/0 的入站规则是重灾区，尤其是一些”图省事”的运维。

4. 资产清单缺失

很多团队根本没有资产台账，自己都不知道公网挂了哪些服务——扫描结果比运维自己的记录还全。

暴露面收敛清单

给这位运维同学的整改建议，也是通用最佳实践：

# 1. 立即下线未使用的服务
systemctl disable --now redis-server

# 2. Redis/DB 绑定内网 + 认证
sed -i 's/^# bind 127.0.0.1/bind 127.0.0.1/' /etc/redis/redis.conf
redis-cli config set requirepass "$(openssl rand -hex 16)"

# 3. 一键排查所有对外开放端口
ss -tlnp | awk '{print $4}' | grep -v '127.0.0.1\|::1\|0.0.0.0:22\|0.0.0.0:80\|0.0.0.0:443'

更系统的做法：

• 资产台账：所有公网服务登记 IP/端口/负责人/用途，用 CMDB 或简单的 CSV 都行
• 收敛默认策略：云安全组默认拒绝，按需放行，并加上来源 IP 白名单
• 周期性扫描：每月一次 nmap + Nuclei 自动扫，结果和台账比对
• SSO 统一认证：所有管理后台接入 SSO，禁止本地弱口令

复盘

$ ./scan.sh
[+] 扫描 254 个 IP
[+] 发现开放端口 8000+ 个
[+] 高危暴露面 4 个 → 已下发整改工单
[+] 复测通过 4/4
[✓] 本次演练暴露面收敛完成

安全不是买来的，是数出来的——先把公网暴露面数清楚，再谈防火墙和 WAF。你连自己暴露了什么都不知道，攻击者可是知道的。