安全组与系统防火墙是分层协同关系：安全组在云平台网络层做粗粒度IP/端口过滤，系统防火墙在操作系统内核层做细粒度连接状态、速率等精细控制，二者共同构成纵深防御体系。
安全组和底层防火墙（如系统级的 iptables、firewalld 或 Windows 防火墙）不是互斥关系，而是分层叠加、各司其职的协同机制。它们共同构成“纵深防御”的第一道和第二道防线，分别在云平台网络层和操作系统内核层生效。
安全组：云平台侧的网络准入控制
安全组是云服务商提供的虚拟防火墙，作用于实例的网卡层面，属于网络基础设施层的访问控制。它不依赖操作系统，即使实例关机或系统崩溃，规则依然生效。
- 只对 IP、协议、端口、方向（入/出）做粗粒度匹配，不解析应用层内容
- 规则按顺序匹配，一旦命中即执行，不再继续向下检查
- 典型配置：仅允许办公 IP 访问 22 端口、开放 80/443 给所有公网、拒绝某风险 IP 的出向连接
- 一台 ECS 最多可绑定 5 个安全组，规则总数可达上千条，但需提前规划避免冲突
底层防火墙：操作系统内的精细过滤
底层防火墙运行在实例内部，由操作系统内核模块（如 netfilter）驱动，能处理更细粒度的流量控制，包括连接状态、速率限制、用户进程标识等。
- 支持基于连接状态（ESTABLISHED/RELATED）的放行，自动允许响应包通过
- 可设置每 IP 并发连接数、请求频率限制（防暴力破解、CC 攻击）
- 能配合服务配置，例如只允许 nginx 进程监听 80 端口，其他进程无法抢占
- 修改后需重启服务或重载规则（如
firewall-cmd --reload），且依赖系统正常运行
两者如何配合才真正有效
单独启用任一者都存在明显短板：仅靠安全组，攻击者一旦连上开放端口（如 443），就能发起 SQL 注入或恶意爬虫；仅靠系统防火墙，若实例被误配为“全端口放行”，就完全暴露在公网中。
- 先收紧安全组：默认拒绝所有入向，仅按最小权限开放必要端口和来源 IP（如只允办公网段 SSH、只允 CDN 回源 IP 访问 80/443）
- 再加固底层防火墙：在系统内进一步限制，例如限制 SSH 登录失败 5 次后封禁 IP、禁止非 root 用户绑定特权端口、关闭 ICMP 响应防止扫描
- 端口变更要同步更新：若把 SSH 从 22 改为 12345，必须同时在安全组中放行新端口，并在系统防火墙中开启对应规则，否则将彻底失联
- 避免规则冗余或矛盾：比如安全组已拒绝某 IP 访问，系统防火墙再加一条相同规则意义不大；但若安全组放行了 0.0.0.0/0，系统防火墙就必须承担全部过滤责任
实际部署建议
对于生产环境的 Web 服务器，推荐组合策略如下：
- 安全组：入向仅放行 80、443、特定管理 IP 的自定义 SSH 端口；出向默认允许，或限制仅访问可信 DNS、日志服务等地址
- 系统防火墙：
firewalld启用 rich rule 限制每 IP 每分钟 HTTP 请求不超过 60 次；禁用 ping；启用 fail2ban 监控 auth 日志并自动封禁爆破 IP - 额外补充：Web 层再接入 WAF，专门识别和拦截恶意 HTTP 请求体，形成“安全组 → 系统防火墙 → WAF”三层防护
