云主机安全组与防火墙配置避坑：放行规则写错导致的暴露面实测 核心要点图解，安全组与系统防火墙是两层独立防线，任何一层放行 0.0.0.0/0 都等于对公网开放。；用 nmap 从外网实测端口，比只看控制台规则更能反映真实暴露面。；数据库、Redis、22 端口应只放行固定管理 IP，禁止全网段开放。；修复后必须复测：规则生效与连接中断要同时验证。
云主机安全组与防火墙配置避坑：放行规则写错导致的暴露面实测 · 核心要点一图读懂（AegisX）

核心要点（TL;DR）

  • 安全组与系统防火墙是两层独立防线，任何一层放行 0.0.0.0/0 都等于对公网开放。
  • 用 nmap 从外网实测端口，比只看控制台规则更能反映真实暴露面。
  • 数据库、Redis、22 端口应只放行固定管理 IP，禁止全网段开放。
  • 修复后必须复测：规则生效与连接中断要同时验证。

很多云主机被入侵，起点不是漏洞利用，而是一条写错的安全组放行规则：源地址填了 0.0.0.0/0，端口填了 3306 或 6379，数据库和缓存就直接躺在公网上。本文用一次实测复现「规则写错→端口暴露→被扫到」的完整链路，并给出可逐条执行的排查命令、修复步骤和检查清单，帮你在下一次扫描到来之前把口子收掉。

一、先看清：暴露面是怎么被一条规则放出来的

云主机的入站流量通常经过两层过滤：云平台侧的安全组和系统内的防火墙（iptables/firewalld/ufw）。安全组是有状态过滤，规则匹配按优先级或全量允许逻辑执行，只要存在一条允许 0.0.0.0/0 访问某端口的规则，该端口就对全网可见。系统防火墙若默认策略是 ACCEPT，则等于没有第二道防线。

典型误配置有三种：

  • 图省事全放行：为远程调试临时加 0.0.0.0/0 放行 22 或 3389，事后忘记删除。
  • 端口填错：本想放行 8080 应用端口，误填 3306，把数据库暴露出去。
  • 监听地址没收敛：服务配置里 bind 写的是 0.0.0.0，配合宽泛规则直接对公网开放。

危害是链式的：暴露端口被扫描器发现后，弱口令爆破、未授权访问（Redis 未设密码、MySQL root 空密码）会接踵而至，最终导致数据泄露或主机被植入挖矿程序。

二、实测：从外网验证真实暴露面

不要只看控制台规则，要从外部实际扫一遍。以下命令在另一台公网主机上执行，目标为待测云主机公网 IP。

# 快速探测常见高危端口
nmap -Pn -p 22,80,443,3306,6379,9200,27017,3389 <目标IP>

# 全端口扫描（耗时较长，建议低峰执行）
nmap -Pn -p- --min-rate 2000 <目标IP>

# 单端口连通性验证
telnet <目标IP> 6379
nc -zv <目标IP> 3306

如果 3306、6379 显示 open，说明已经暴露。接着回到服务器上确认监听状态：

ss -tlnp | grep -E ':(22|3306|6379|9200)'
# 输出中 Local Address 为 0.0.0.0:6379 即表示监听全网卡

再用 curl 验证 Redis 是否真的无认证可访问（仅限自有测试环境）：

redis-cli -h <目标IP> -p 6379 ping
# 返回 PONG 说明未授权访问成立，属于高危

三、定位：找出那条写错的放行规则

在云控制台安全组页面导出规则，重点筛查以下字段组合：

检查项危险值建议值
源地址0.0.0.0/0、::/0固定办公 IP 或跳板机安全组
端口范围ALL、1-65535仅业务必需端口
协议ALLTCP/UDP 按需指定
授权对象任意指定安全组或 IP 段

系统侧同步检查默认策略与现有规则：

# iptables
sudo iptables -L INPUT -n -v --line-numbers

# firewalld
sudo firewall-cmd --list-all

# ufw
sudo ufw status verbose

若 INPUT 默认策略为 ACCEPT 且无拒绝规则，说明系统防火墙没有兜底能力，需要补默认拒绝策略。

四、分步修复：把宽泛规则收敛到最小权限

  1. 先建后删：在安全组中新增精确规则，例如仅允许办公出口 IP 203.0.113.10/32 访问 22 端口，验证可登录后，再删除旧的 0.0.0.0/0 规则。
  2. 收敛服务监听地址：数据库与缓存只监听内网或本机。以 Redis 为例，在 redis.conf 中设置 bind 127.0.0.1 并开启 requirepass；MySQL 设置 bind-address = 127.0.0.1。
  3. 补系统防火墙默认拒绝： 
    # ufw 示例
sudo ufw default deny incoming
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow 443/tcp
sudo ufw enable
  4. 管理端口加跳板：22 端口不对公网开放，统一经跳板机或云厂商运维通道登录。
  5. 复测：重复第二节的 nmap 扫描，确认高危端口由 open 变为 filtered 或 closed，同时验证业务端口仍可正常访问。
修复期间务必保留一条可用管理通道，避免删规则后把自己锁在门外。生产环境建议在低峰期操作并提前通知。

五、配置检查清单（逐项打勾）

  • 安全组中不存在源为 0.0.0.0/0 的 22/3306/6379/9200 放行规则。
  • 所有高危服务监听地址为 127.0.0.1 或内网 IP，而非 0.0.0.0。
  • 系统防火墙默认入站策略为 DROP/deny，仅放行明确端口。
  • 公网仅开放 80/443 等业务必需端口，且已配置 WAF 或限速。
  • 安全组规则有命名和备注，临时规则设置到期提醒。
  • 已用外网 nmap 复测，实际开放端口与预期清单一致。
  • 开启登录审计与异常告警，定期复查规则变更记录。

在边界防护层面，AegisX 可对云主机入站流量做统一策略管理与暴露面巡检，把安全组与主机防火墙的规则收敛到同一套最小权限基线，减少人工比对遗漏。

六、行动建议

今天就做三件事：导出全部安全组规则筛出 0.0.0.0/0 条目；在服务器上执行 ss -tlnp 核对监听地址；从外网跑一次 nmap 全端口扫描。三者比对出的差异，就是你当前真实的暴露面。把宽泛规则收敛为固定源 IP、把高危服务绑定到内网、给系统防火墙补上默认拒绝，这三步做完，绝大多数因放行规则写错导致的入侵路径就会被切断。

常见问题（FAQ）

安全组已经限制了端口，为什么服务器还是被扫到？

最常见原因是系统内防火墙或服务监听地址与安全组不一致。安全组只过滤进站流量，若服务监听在 0.0.0.0 且安全组存在 0.0.0.0/0 放行规则，端口就对全网可见。另外云厂商的默认规则、弹性公网 IP 绑定、以及同账号其他实例的内网互访也可能绕过你的预期。排查时要用外网 nmap 实测，而不是只看控制台。

0.0.0.0/0 放行到底有多危险？

等于把端口交给全网扫描器。互联网上针对 22、6379、3306、9200 等端口的自动化爆破和漏洞利用是持续不断的，暴露后通常在数小时到数天内就会出现异常登录或挖矿进程。正确做法是把源地址收敛到固定办公 IP 或跳板机安全组，确需公网访问的只开放 443/80 等必要端口，并配合认证与限速。

安全组和 iptables/firewalld 应该配哪个？

两层都要配，但职责不同。安全组是云平台侧的第一道边界，优先在这里做粗粒度收敛；系统防火墙是第二道，用于精细化控制和兜底。实践建议：安全组只放行必要端口和可信源 IP，系统防火墙默认拒绝入站，仅放行明确需要的服务，并保持规则可版本化管理，避免两边规则互相矛盾导致排障困难。

修改安全组规则会不会导致业务中断？

会有风险，尤其是删除规则时。安全组通常是有状态过滤，删除放行规则会立即切断已建立的新连接。建议先在业务低峰操作，保留一条应急管理通道（如跳板机或云助手），修改后立即用 curl、telnet 或 nc 验证关键端口连通性，并观察监控告警。对生产环境优先采用新增精确规则再删除宽泛规则的顺序。

怎么快速自查云主机暴露面？

分三步：一是在控制台导出所有安全组规则，筛出源为 0.0.0.0/0 或 ::/0 的条目；二是在服务器上执行 ss -tlnp 查看监听地址，确认是否有服务绑定 0.0.0.0；三是从外部网络用 nmap -Pn -p- 目标IP 做全端口扫描，比对实际开放端口与预期清单。三者不一致的地方就是需要收敛的暴露面。