云服务器安全防护需安全组与系统防火墙协同：安全组负责网络边界粗粒度过滤，系统防火墙负责服务入口细粒度加固，二者分工明确、规则一致、避免冲突，共同构成分层防御体系。
云服务器的安全防护不能只靠安全组或只靠系统防火墙，二者是分层协作的关系：安全组管网络边界，系统防火墙管服务入口。协同的关键在于规则一致、职责分明、不互相抵消。
明确分工：安全组负责粗粒度网络层过滤
安全组是云平台提供的虚拟防火墙，作用在实例网卡外侧，属于第一道防线。它不识别应用层协议，只按 IP、端口、协议做放行/拒绝判断。
- 默认策略为“全部拒绝入方向”，必须显式添加白名单规则才能访问
- 规则生效快（秒级），无需重启服务器或服务
- 适合控制谁（IP）能连到哪（端口），比如只允许办公公网 IP 访问 SSH 22 端口
- 不建议在安全组里开放 0.0.0.0/0，尤其对数据库、Redis 等敏感端口
系统防火墙负责细粒度服务层加固
firewalld（CentOS/RHEL）或 ufw（Ubuntu/Debian）运行在操作系统内，可结合服务、区域、富规则做更精细的控制，是对安全组的补充而非替代。
- 即使安全组已限制 IP，仍建议在 firewalld 中同步加白名单，防止单点配置失误导致暴露
- firewalld 支持 rich rule，例如：
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.123.45.67" port port="3306" protocol="tcp" accept' - ufw 更简洁：
ufw allow from 203.123.45.67 to any port 3306 proto tcp - 启用后务必执行
firewall-cmd --reload或ufw enable生效
避免规则冲突：检查并统一放行逻辑
常见问题不是“设了没用”，而是“两边都设但逻辑矛盾”。比如安全组允许某 IP 访问 80 端口，但 firewalld 却 DROP 所有入向流量——结果就是连不上。
- 先确认系统防火墙状态：
firewall-cmd --state或ufw status verbose - 若 firewalld 启用，
firewall-cmd --list-all查看当前规则；ufw 用ufw status numbered - 确保安全组开放的端口，在系统防火墙中也明确允许（不要依赖 public zone 默认规则）
- 如仅需特定 IP 访问，系统防火墙里不要留“allow 80/tcp”这种无源地址限制的宽泛规则
运维习惯：把安全组当主控，系统防火墙当保险
日常维护中，优先在云控制台调整安全组——它对所有绑定实例生效、操作审计清晰、不受 SSH 断连影响。系统防火墙则用于兜底和临时调试。
- 上线前：先配好安全组白名单，再部署 firewalld/ufw 白名单规则
- 排查连通性时：先查安全组是否放行、再查系统防火墙是否拦截、最后看服务是否监听正确地址（如 0.0.0.0 而非 127.0.0.1）
- 批量管理多台服务器时，用 Ansible 或脚本统一下发 firewalld 规则，但安全组仍需在控制台或 API 层统一绑定
- 临时调试可临时放宽规则，但事后必须清理，尤其是测试用的 0.0.0.0/0
