CentOS下firewalld区域规则与端口暴露治理

在CentOS 7及之后的版本中，firewalld取代iptables成为默认的动态防火墙管理工具。很多运维人员习惯性地遇到端口不通就执行 firewall-cmd --add-port，却忽略了区域（zone）规则叠加和源地址绑定带来的隐性暴露风险。一台服务器的SSH端口明明只允许办公网段访问，但换一个区域或者网卡重启后，规则却意外放行了所有流量，这种治理盲区正是生产环境中最常见的安全事故源头。

问题的核心在于，firewalld的规则匹配并非简单的线性顺序，而是先匹配区域绑定关系，再匹配区域内的规则。当一个请求进入网卡时，firewalld首先判断该网卡属于哪个区域，然后只应用该区域内的规则。如果网卡被错误地分配到了public区域，而你在internal区域配置了严格的限制，那些限制根本不会生效。更隐蔽的是，如果源地址被某个区域绑定，即使网卡属于另一个区域，流量也会被源地址所在的区域规则接管。

firewalld预定义了多个区域，从信任度最低的drop到信任度最高的trusted。drop区域默认丢弃所有入站流量，连回复都不给；block区域会回复拒绝信息；public区域用于公共网络，通常只开放特定端口；internal和home区域信任度更高；trusted区域则放行所有流量。这些区域本身没有优先级高低之分，关键在于哪个区域与入站流量产生绑定关系。

绑定关系的判断遵循两条路径。第一条是源地址绑定，如果数据包的源IP地址匹配了某个区域的source配置，那么该数据包直接由这个区域处理，不再考虑网卡绑定。第二条是网卡绑定，如果没有源地址匹配，则看数据包进入的网卡被绑定到了哪个区域。如果既没有源地址匹配也没有网卡绑定，则使用默认区域，默认区域通常是public。这个逻辑意味着，哪怕你把eth0绑定到了drop区域，只要有人从某个源IP过来，而这个源IP被绑定到了trusted区域，流量照样畅通无阻。

很多人只用 firewall-cmd --list-all 查看默认区域配置，这远远不够。你必须逐一检查每个区域的绑定情况。执行以下命令可以看到所有区域及其绑定的网卡和源地址：

# 查看所有活跃区域及其绑定的接口
firewall-cmd --get-active-zones

# 查看特定区域的完整配置，包括source绑定
firewall-cmd --zone=public --list-all
firewall-cmd --zone=internal --list-all

# 查看所有区域的详细配置
for zone in $(firewall-cmd --get-zones); do
    echo "=== Zone: $zone ==="
    firewall-cmd --zone=$zone --list-all
done

执行后你会看到每个区域下的sources字段，这个字段列出了所有被绑定到该区域的源IP地址或网段。如果sources为空，说明该区域只通过网卡绑定生效。interfaces字段则显示绑定的网卡名称。services字段列出开放的服务，ports字段列出直接开放的端口。rich-rules字段包含更复杂的规则。这些信息拼在一起，才构成该区域完整的规则集合。

一种典型错误是，管理员在internal区域配置了严格的SSH访问限制，只允许192.168.1.0/24网段访问22端口，但服务器的网卡eth0却被绑定在public区域。由于public区域没有源地址绑定，所有进入eth0的流量都由public区域处理，internal区域的限制形同虚设。如果public区域恰好开放了22端口，SSH服务就暴露给了整个网络。

排查这类问题需要逆向追溯。先用ss -tlnp确认服务监听的端口和地址，然后检查防火墙日志。firewalld的日志默认不会记录被拒绝的包，需要开启日志记录：

# 开启firewalld拒绝日志
firewall-cmd --set-log-denied=all

# 查看日志
journalctl -xe | grep -i firewall
dmesg | grep -i firewall

日志中会明确显示哪个区域的规则拒绝了数据包，以及数据包的源地址、目的端口和进入的网卡。通过日志可以反向定位实际生效的区域，然后对比该区域的配置与你的预期是否一致。

源地址绑定是firewalld中最强大的功能之一，也是最容易被误用的。正确的做法是，将特定源IP或网段绑定到信任度更高的区域，而不是在低信任度区域中添加富规则来放行。例如，允许办公网段192.168.10.0/24访问所有服务，应该这样做：

# 将办公网段绑定到internal区域
firewall-cmd --permanent --zone=internal --add-source=192.168.10.0/24

# 在internal区域开放所需服务
firewall-cmd --permanent --zone=internal --add-service=ssh
firewall-cmd --permanent --zone=internal --add-service=http

# 重载使配置生效
firewall-cmd --reload

这样配置后，来自192.168.10.0/24的流量无论从哪个网卡进入，都会由internal区域处理。其他流量则按照网卡绑定的区域处理。这种分层治理的思路，比在单一区域中堆砌大量富规则要清晰得多，也更容易审计。

当服务或端口的开放不能满足需求时，需要使用富规则（rich rule）。富规则可以基于源地址、目的地址、端口、协议、时间等多种条件进行精细化控制。例如，只允许特定IP访问特定端口，并限制连接频率：

# 只允许192.168.1.100访问8080端口，每分钟最多10个新连接
firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port port="8080" protocol="tcp" accept limit value="10/m"'

富规则还可以实现端口转发，这是端口暴露治理中经常被忽略的环节。很多内网服务通过端口转发暴露出去，但转发规则本身可能缺乏来源限制。配置端口转发时必须同时添加源地址过滤：

# 将外部443端口转发到内网服务器的8443端口，仅允许特定源IP
firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="203.0.113.0/24" forward-port port="443" protocol="tcp" to-port="8443" to-addr="192.168.100.10"'

直接规则（direct rule）则提供了更底层的控制能力，可以插入iptables的原始链中。但直接规则绕过了firewalld的区域管理，容易造成规则混乱，除非有特殊需求，否则应尽量避免使用。如果确实需要，务必在配置文件中做好注释说明。

firewalld区分永久配置（--permanent）和运行时配置。不带--permanent参数的命令只影响当前运行状态，重启后失效。带--permanent参数的命令只写入配置文件，不影响当前运行状态，需要执行firewall-cmd --reload才能生效。这个设计导致了一个常见的陷阱：管理员在排查问题时临时添加了运行时规则，问题解决后忘记将其持久化，服务器重启后问题复现。或者反过来，添加了永久配置但忘记reload，以为规则已经生效。

建议养成习惯，修改配置时同时执行两条命令，一条修改运行时，一条修改永久配置，然后立即验证：

# 同时修改运行时和永久配置
firewall-cmd --zone=public --add-port=8080/tcp
firewall-cmd --permanent --zone=public --add-port=8080/tcp

# 验证运行时配置
firewall-cmd --zone=public --query-port=8080/tcp

# 验证永久配置
firewall-cmd --permanent --zone=public --query-port=8080/tcp

如果端口较多，也可以先全部用--permanent配置好，最后一次性reload，但reload会中断现有连接，生产环境需要谨慎操作。

端口暴露治理的核心原则是最小权限，即只开放业务必需的端口，且只对必需的来源地址开放。审计现有规则时，需要关注以下几点：开放了哪些端口，这些端口是否都有业务需求；每个端口的来源地址范围是否过大；是否存在已经不再使用的历史规则；不同区域之间是否存在规则冲突或覆盖。

可以通过导出所有区域的配置来进行全面审计：

# 导出所有区域的永久配置
for zone in $(firewall-cmd --get-zones); do
    echo "=== Zone: $zone ==="
    firewall-cmd --permanent --zone=$zone --list-all
done

审计时特别注意那些sources为空的区域，如果这些区域开放了敏感端口，意味着任何未被其他区域源地址匹配的流量都可能访问这些端口。还要检查是否存在多个区域绑定同一个网卡的情况，虽然firewalld不允许一个网卡同时绑定多个区域，但在配置文件中可能存在残留的旧绑定记录。

对于多台服务器的端口暴露治理，手动配置容易产生不一致。可以将firewalld的配置文件纳入版本管理。firewalld的配置文件位于/etc/firewalld/目录下，zones子目录存放各区域的配置文件，每个区域一个XML文件。可以直接编辑这些XML文件来批量部署规则，或者使用配置管理工具如Ansible进行统一管理。

一个典型的Ansible任务示例如下：

- name: 配置firewalld区域规则
  firewalld:
    zone: public
    port: "{{ item }}"
    permanent: yes
    state: enabled
  loop:
    - 80/tcp
    - 443/tcp
  notify: reload firewalld

- name: 绑定源地址到internal区域
  firewalld:
    zone: internal
    source: 192.168.10.0/24
    permanent: yes
    state: enabled
  notify: reload firewalld

自动化治理的关键在于保持配置的一致性，任何手动修改都应该回写到配置管理系统中。同时，定期扫描开放端口并与预期配置进行比对，及时发现偏离。可以使用nmap从外部扫描，结合firewall-cmd的配置导出，进行自动化差异分析。

当发现异常端口暴露或正在遭受攻击时，需要快速收敛端口。firewalld提供了panic模式，可以立即切断所有入站和出站流量，只保留已建立的连接：

# 开启panic模式
firewall-cmd --panic-on

# 关闭panic模式
firewall-cmd --panic-off

# 查询panic模式状态
firewall-cmd --query-panic

panic模式是应急响应的最后手段，会中断所有服务。更精细的做法是快速移除特定端口或源地址。如果攻击来自特定IP，可以直接将该IP加入drop区域：

# 将攻击IP加入drop区域
firewall-cmd --zone=drop --add-source=203.0.113.50
firewall-cmd --permanent --zone=drop --add-source=203.0.113.50

drop区域默认丢弃所有入站流量且不回复，攻击者无法判断端口是否开放，也无法建立连接。这种封禁方式比在public区域添加拒绝规则更彻底，因为拒绝规则仍然会回复RST包，攻击者可以据此判断主机存活。

端口暴露治理不是一次性工作，而是持续的过程。每次业务变更、每次系统升级，都可能引入新的端口暴露。建立定期审计机制，将firewalld配置纳入变更管理流程，才能在动态环境中保持安全基线。区域规则的设计应该遵循“默认拒绝、明确允许”的原则，默认区域只开放必要端口，高信任度操作通过源地址绑定来实现，避免在低信任度区域中过度开放。这种分层治理架构，既保证了业务的灵活性，也守住了安全的底线。