firewalld区域机制需按业务角色而非IP段划分，如finance-zone、dev-test-zone等专属区域绑定接口并限制流向，跨区通信须显式富规则授权，且数据库须配合bind-address与nftables/SELinux补强。
不能靠IP段“一刀切”，得按业务角色建区域、绑接口、控流向——比如财务系统和研发测试环境哪怕在同一子网，也必须隔离。
用 firewalld 区域（Zone）打标签，不靠IP靠职责
firewalld 的 zone 机制是天然适配业务边界的工具。别再把所有服务器塞进 public 区；每个部门或系统应分配专属 zone，例如：
- finance-zone：专用于财务系统，只允许财务内网段（10.50.10.0/24）通过 HTTPS 访问，禁止 ICMP 和 SSH 直连
- dev-test-zone：给研发测试环境使用，开放 8080/3000 等调试端口，但禁止访问生产数据库端口（3306/5432）
- hr-zone：HR 系统所在区域，仅放行 LDAP（389）、HTTPS（443），且只接受 HR 办公网段（172.16.30.0/24）
创建方式：firewall-cmd --permanent --new-zone=finance-zone，再绑定物理或虚拟接口：firewall-cmd --permanent --zone=finance-zone --add-interface=eth1。
跨区域通信必须显式授权，禁用隐式信任
同一台服务器上跑多个部门服务时，区域间默认不通——这是安全前提。若 HR 系统需调用统一认证服务（在 auth-zone），就得写富规则：
- 只允许可信源：
firewall-cmd --permanent --zone=hr-zone --add-rich-rule='rule source address="172.16.30.0/24" destination zone="auth-zone" port port="443" protocol="tcp" accept' - 拒绝其他所有跨区尝试，并记录：
firewall-cmd --permanent --zone=hr-zone --add-rich-rule='rule destination zone="auth-zone" log prefix="HR_TO_AUTH_BLOCK" drop' - 重载后验证：
firewall-cmd --reload && firewall-cmd --zone=hr-zone --list-all
数据库与后端服务必须绑定内网地址，防火墙不是万能补丁
即使划分了 finance-zone，如果 MySQL 配置为 bind-address = 0.0.0.0，攻击者从 dev-test-zone 主机仍可直连——防火墙拦不住本机流量。
- 数据库监听地址设为
127.0.0.1或专用内网 IP（如10.50.20.5），再配合 firewalld 仅放行 finance-zone 中指定应用服务器的 IP - Redis 同理，禁用
protected-mode no，启用requirepass并限制bind到 internal 网段 - 用
ss -tlnp | grep :3306检查实际监听地址，避免配置与防火墙策略脱节
用 nftables 补强链级控制，堵住 zone 无法覆盖的缝隙
firewalld zone 是逻辑层，nftables 是链级执行层。当多个部门容器共宿主机时，仅靠 zone 不够——需结合 cgroup 或进程上下文：
- 给财务容器打 cgroup 标签：
systemd-run --scope --property=Slice=finance.slice your-app - nft 添加规则：
nft add rule inet filter forward meta cgroup /finance tcp dport 3306 ct state established accept - 同时启用 SELinux 策略，让财务进程类型（
finance_t）只能连接数据库端口，其他进程类型根本无权发起该连接
