1. 项目概述为什么我们需要重新审视 firewalld在 Linux 服务器运维和网络管理的日常工作中防火墙配置是保障系统安全的第一道也是最重要的一道防线。很多朋友可能对iptables耳熟能详觉得它功能强大、无所不能。但当你面对一个需要动态调整规则、管理多个网络区域或者希望配置过程更直观、更“现代”一些的场景时原生的iptables命令行操作就显得有些繁琐和不够直观了。这正是firewalld诞生的背景。简单来说firewalld不是一个全新的底层防火墙它更像是iptables以及后来的nftables的一个动态管理前端。它的核心价值在于引入了“区域Zone”和“服务Service”这两个高度抽象的概念让防火墙规则的管理从“针对端口和IP写规则”变成了“针对应用场景定义策略”。比如你可以轻松地定义一个叫“internal”的区域允许 SSH 和 Samba 服务然后把这个区域应用到你的内网网卡上再定义一个“public”区域只开放 Web 服务应用到对外的网卡上。这种基于“区域”的管理模式非常贴合现代服务器多网卡、多用途的实际部署场景。我见过不少运维同事在紧急情况下为了开一个端口直接iptables -I INPUT -p tcp --dport 8080 -j ACCEPT命令是执行了但可能破坏了原有的规则顺序或者忘记保存导致服务器重启后规则丢失安全防线出现缺口。firewalld通过将配置持久化存储通常是 XML 文件和提供运行时与永久配置分离的机制很大程度上避免了这类问题。你可以先测试运行时规则确认无误后再将其转为永久配置整个过程更可控、更安全。所以无论你是刚接触 Linux 防火墙的新手还是习惯了iptables但想寻求更高效管理方式的老手深入理解firewalld都很有必要。它已经是 CentOS/RHEL 7/8/9、Fedora 等主流发行版的默认防火墙解决方案掌握它就掌握了这些系统安全配置的“标准姿势”。接下来我们就从最基础的概念开始一步步拆解它的配置逻辑和实战应用。2. firewalld 核心概念与架构深度解析要玩转firewalld不能只停留在敲几个firewall-cmd命令的层面必须理解其背后的设计哲学和核心组件。这就像开车知道油门和刹车在哪能上路但了解发动机和变速箱原理才能开得更好、更安全。2.1 区域Zone防火墙策略的容器区域是firewalld最核心的抽象。你可以把它想象成一个个预设了不同安全级别的“策略模板”或“安全情景”。每个区域都定义了一组规则决定了什么样的流量被允许什么样的被拒绝。firewalld默认提供了多个预定义区域按信任度从高到低大致排列如下trusted信任所有流量。这相当于完全放行通常用于最安全的内部网络测试环境生产环境慎用。home适用于家庭网络。默认允许 SSH、mdns、samba-client 等与家庭共享相关的服务。internal用于内部网络信任度仅次于 home。通常允许 SSH、DHCPv6-client 等管理性服务。work用于工作场所。允许 SSH、DHCPv6-client 等。public默认区域。用于公共、不可信的场所如机场、咖啡馆的Wi-Fi。默认只允许 SSH 和 DHCPv6-client。这是新安装系统后未配置网卡时所处的区域也是最安全的起点。dmz用于非军事区隔离区的服务器这些服务器对外部网络有限地提供服务。默认允许 SSH。external用于启用了伪装masquerading的外部网络通常作为网关。默认允许 SSH。block拒绝所有传入连接并回复 icmp-host-prohibited 消息。系统可以主动发起出站连接。drop最严格。丢弃所有传入的数据包不回复任何信息。同样系统可以主动发起出站连接。注意block和drop的区别很关键。block是“礼貌地拒绝”会告知对方“此路不通”发送拒绝包而drop是“无声地丢弃”对方会一直等待直到超时。从安全角度drop更隐蔽但可能给调试带来麻烦。通常对明确的攻击源使用drop对普通访问使用block。每个网卡接口如 eth0, ens192或一个源 IP 地址范围都可以被绑定到一个特定的区域。一个接口同一时间只能属于一个区域但一个区域可以包含多个接口。这种设计使得我们可以根据网络环境如内网、外网、管理网轻松地应用不同的安全策略。2.2 服务Service端口与协议的组合抽象服务是另一个伟大的抽象。在iptables里我们常说“开放 80 端口”。但在firewalld里我们更倾向于说“允许 http 服务”。一个“服务”在firewalld中是一个 XML 文件它明确定义了这个服务需要的一个或多个端口以及协议类型如 tcp/udp甚至还可以包含目的地址、模块加载如用于 FTP 的nf_conntrack_ftp等更丰富的信息。例如/usr/lib/firewalld/services/目录下的http.xml文件内容大致如下?xml version1.0 encodingutf-8? service shortWWW (HTTP)/short descriptionHTTP is the protocol used to serve Web pages. If you plan to make your Web server publicly available, enable this option. This option is not required for viewing pages locally or developing Web pages./description port protocoltcp port80/ /service通过允许一个“服务”你实际上就开放了其定义的所有端口。这比记忆端口号更直观也更容易管理。比如允许samba服务就自动开放了 137/udp, 138/udp, 139/tcp, 445/tcp 等多个端口无需手动一个个添加。2.3 运行时与永久配置灵活性与安全性的平衡这是firewalld管理上的一个关键特性也是容易混淆的点。运行时配置Runtime指当前内存中生效的防火墙规则。通过firewall-cmd命令进行的修改如果不加--permanent参数默认只影响运行时配置。它的好处是你可以立即测试修改效果如果配置有误重启firewalld服务或者服务器这些临时规则就会消失系统会回退到上次保存的永久配置状态。这是一个非常重要的“安全垫”。永久配置Permanent指保存在磁盘配置文件如/etc/firewalld/下的 XML 文件中的规则。这些规则在系统重启或firewalld服务重启后依然存在。任何计划长期生效的更改都必须使用--permanent参数。一个最佳实践工作流是firewall-cmd --add-servicehttp不加--permanent在运行时添加规则进行测试。用浏览器或curl测试 80 端口是否可访问。测试通过后firewall-cmd --add-servicehttp --permanent将规则写入永久配置。firewall-cmd --reload重载配置使永久配置立即生效。注意reload会合并运行时和永久配置但更常见的做法是直接执行第5步。或者更常见的做法是直接firewall-cmd --add-servicehttp --permanent firewall-cmd --reload一步到位但前提是你对规则很有把握。2.4 直接规则Direct Rules留给高手的后门尽管firewalld提供了丰富的抽象但总有它预定义的服务或区域无法满足的复杂需求。例如你需要设置特定的iptables链、写一个复杂的包匹配规则或者使用firewalld不直接支持的扩展模块。这时“直接规则”就派上用场了。通过firewall-cmd --direct选项你可以向底层的iptables或nftables插入原生命令。这给了管理员最大的灵活性但同时也意味着你需要自行承担规则管理和持久化的责任因为firewalld可能无法完全理解或优化这些直接规则。实操心得除非绝对必要否则尽量避免使用直接规则。因为它破坏了firewalld配置的统一性和可读性。如果必须使用务必做好详细的文档记录并确保将其通过--permanent方式保存否则重启后就会丢失。3. 实战配置从零开始构建你的防火墙策略理解了核心概念我们进入实战环节。假设我们有一台新安装的 CentOS 8 服务器它有两块网卡ens192连接公司内网IP段 10.0.1.0/24和ens224连接互联网。我们的目标是内网可 SSH 管理并可访问所有服务互联网仅能访问 Web80, 443和特定 API 端口8080。3.1 环境检查与初始状态确认首先我们需要确认firewalld已经安装并运行。# 检查 firewalld 状态 systemctl status firewalld # 如果未运行则启动并设置开机自启 sudo systemctl start firewalld sudo systemctl enable firewalld # 查看默认区域和活动区域 sudo firewall-cmd --get-default-zone sudo firewall-cmd --get-active-zones新系统默认区域是public且所有网卡通常都处于默认区域。--get-active-zones会显示哪些区域被应用到了具体的接口上。3.2 为不同网络接口分配区域根据我们的规划将内网接口ens192分配到更宽松的internal区域将公网接口ens224分配到严格的public区域。# 将 ens192 接口移至 internal 区域运行时 sudo firewall-cmd --zoneinternal --change-interfaceens192 # 将 ens224 接口移至 public 区域运行时 sudo firewall-cmd --zonepublic --change-interfaceens224 # 立即查看活动区域确认更改 sudo firewall-cmd --get-active-zones输出应类似internal interfaces: ens192 public interfaces: ens224--change-interface会同时将接口从原有区域移除并添加到新区域。现在两个接口已经应用了不同的基础策略。3.3 在区域中管理服务与端口接下来我们需要根据业务需求在各个区域中开放相应的服务。1. 配置 internal 区域内网策略我们希望内网可以 SSH 管理并且可以访问这台服务器上未来可能部署的所有服务比如数据库、缓存等。一个简单粗暴的方法是允许来自内网的所有流量但这不够安全。更精细的做法是只开放需要的服务。# 首先查看 internal 区域当前允许的服务 sudo firewall-cmd --zoneinternal --list-services # 默认可能已经有 ssh dhcpv6-client # 假设我们内网还需要访问 MySQL (3306) 和 Redis (6379) # 先检查是否有预定义的 mysql 和 redis 服务 sudo firewall-cmd --get-services | grep -E “mysql|redis” # 如果有可以直接添加服务。如果没有我们需要通过端口方式添加。 # 添加 MySQL 端口 (更推荐创建自定义服务见后文) sudo firewall-cmd --zoneinternal --add-port3306/tcp # 添加 Redis 端口 sudo firewall-cmd --zoneinternal --add-port6379/tcp # 同时我们希望 internal 区域默认允许所有来自内网 IP 段的访问谨慎操作 # 这可以通过设置区域的源地址source来实现但更好的做法是保持区域基于接口然后精细管理服务。 # 这里我们先采用精细管理端口的方案。2. 配置 public 区域公网策略公网区域必须保持严格。默认只允许 SSH建议更改端口或使用密钥认证加强安全。我们需要开放 Web 服务。# 允许 http 和 https 服务 sudo firewall-cmd --zonepublic --add-servicehttp sudo firewall-cmd --zonepublic --add-servicehttps # 允许自定义的 API 端口 8080 sudo firewall-cmd --zonepublic --add-port8080/tcp # 再次强调公网开放 SSH 是高风险操作。建议 # a) 使用非22端口--add-port2222/tcp # b) 或仅允许特定管理IP访问使用富规则Rich Rules这是更安全的方式下文会讲。3.4 创建与使用自定义服务开放 8080 端口时我们用了--add-port。如果这个端口代表一个特定的应用比如my-app-api更好的做法是创建一个自定义服务提高可读性和可维护性。步骤1创建服务定义文件自定义服务文件应放在/etc/firewalld/services/目录下覆盖系统预定义的/usr/lib/firewalld/services/目录。sudo vi /etc/firewalld/services/my-app-api.xml输入以下内容?xml version1.0 encodingutf-8? service shortMy App API Service/short descriptionThis is the API endpoint for my custom application, providing RESTful interfaces./description port protocoltcp port8080/ !-- 如果需要可以定义多个端口和协议 -- !-- port protocoludp port8081/ -- !-- 还可以定义目的地址、加载模块等 -- /service步骤2重载 firewalld 以识别新服务sudo firewall-cmd --reload步骤3使用自定义服务现在你可以像使用系统服务一样使用它# 从 public 区域移除之前添加的端口规则如果已添加 sudo firewall-cmd --zonepublic --remove-port8080/tcp # 添加自定义服务 sudo firewall-cmd --zonepublic --add-servicemy-app-api这样做的好处是未来如果 API 端口变更你只需要修改这一个 XML 文件然后重载即可所有引用了此服务的区域都会自动更新无需到处查找和修改端口号。3.5 使用富规则Rich Rules实现高级控制富规则是firewalld提供的强大语法允许你编写类似iptables那样精细的规则但结构更清晰。常用场景包括限制特定 IP 访问、记录日志、限制连接速率等。场景1在 public 区域仅允许特定管理 IP如 203.0.113.100访问 SSH 端口# 首先移除 public 区域默认的 ssh 服务对所有IP开放 sudo firewall-cmd --zonepublic --remove-servicessh # 添加一条富规则允许特定IP访问22端口 sudo firewall-cmd --zonepublic --add-rich-rule‘rule family“ipv4” source address“203.0.113.100” port port“22” protocol“tcp” accept’场景2在 internal 区域拒绝来自某个问题内网 IP10.0.1.99的所有访问sudo firewall-cmd --zoneinternal --add-rich-rule‘rule family“ipv4” source address“10.0.1.99” reject’ # 使用 ‘reject’ 会发送拒绝包使用 ‘drop’ 则静默丢弃。场景3记录并丢弃来自某个网段192.168.2.0/24对 3306 端口的访问尝试sudo firewall-cmd --zonepublic --add-rich-rule‘rule family“ipv4” source address“192.168.2.0/24” port port“3306” protocol“tcp” log prefix“MYSQL_PROBE” level“notice” limit value“2/m” drop’这条规则很丰富它匹配 IPv4、源网段、目标端口和协议对匹配的数据包打上“MYSQL_PROBE”的日志前缀日志级别为 notice并且限制日志频率为每分钟最多2条避免日志洪水最后执行丢弃动作。重要提示富规则的顺序至关重要firewalld按规则添加的顺序进行匹配。通常更具体的规则应该放在前面。你可以使用--list-rich-rules查看顺序但目前firewalld没有内置的命令来直接调整已有富规则的顺序。如果需要调整可能需要先删除再按正确顺序重新添加。3.6 保存配置将运行时规则永久化经过一系列测试所有规则工作正常。现在我们需要将它们全部保存为永久配置确保服务器重启后依然有效。# 方法一将运行时配置直接复制到永久配置最常用 sudo firewall-cmd --runtime-to-permanent # 执行此命令后当前所有运行时配置包括区域绑定、服务、端口、富规则等都会被写入对应的永久配置文件中。 # 方法二在每次修改命令中都加上 --permanent 参数如我们之前部分命令所示 # 然后需要执行重载来让永久配置生效 sudo firewall-cmd --reload # 验证永久配置 sudo firewall-cmd --zonepublic --list-all --permanent sudo firewall-cmd --zoneinternal --list-all --permanent我个人的习惯是在测试阶段使用不带--permanent的命令快速验证。全部测试通过后运行一次--runtime-to-permanent一劳永逸。这是一种高效且安全的工作流。4. 高级特性与运维技巧掌握了基础配置后我们来看看firewalld的一些高级特性和在生产环境中非常实用的运维技巧。4.1 端口转发与 IP 伪装Masqueradingfirewalld可以方便地配置 NAT 和端口转发这对于将服务器作为网关或者对外暴露内网服务非常有用。IP 伪装SNAT这通常用在网关服务器上允许内网机器通过该网关访问互联网。# 在 external 或 public 区域启用伪装 sudo firewall-cmd --zonepublic --add-masquerade启用后该区域对应的接口如ens224就会对来自其他接口如ens192的流量进行源地址转换SNAT。端口转发DNAT将到达本机某个端口的流量转发到另一台机器的指定端口。例如将公网 IP 的 80 端口流量转发到内网 Web 服务器10.0.1.10的 8080 端口。# 假设公网接口在 public 区域 # 启用富规则进行转发 sudo firewall-cmd --zonepublic --add-rich-rule‘rule familyipv4 forward-port port80 protocoltcp to-port8080 to-addr10.0.1.10’这条规则需要masquerade功能的支持。to-addr可以省略如果省略则转发到本机其他端口。4.2 使用 GUI 工具firewall-config与 Cockpit 集成对于不习惯命令行的用户或者需要进行复杂规则可视化管理的场景firewall-config图形化工具非常有用。# 在桌面环境安装 sudo yum install firewall-config # RHEL/CentOS sudo dnf install firewall-config # Fedora启动后你可以通过图形界面管理所有区域、服务、端口和富规则非常直观。所有在 GUI 中的操作最终都会转化为firewall-cmd命令执行。此外在现代的 CentOS/RHEL 8/9 中集成的CockpitWeb 控制台也提供了对firewalld的基础管理功能。通过浏览器访问https://your-server:9090在“网络”部分即可进行防火墙配置这对于轻量级管理非常方便。4.3 配置备份、迁移与版本控制防火墙配置是系统安全的核心对其进行备份和版本控制至关重要。备份配置firewalld的所有永久配置都存储在/etc/firewalld/目录下。# 备份整个配置目录 sudo tar -czvf firewalld-backup-$(date %Y%m%d).tar.gz /etc/firewalld/ # 特别注意 /etc/firewalld/zones/ 下的区域定义和 /etc/firewalld/services/ 下的自定义服务。迁移配置要将一台服务器的firewalld配置应用到另一台最简单的方法就是复制整个/etc/firewalld/目录或者至少是zones/和services/子目录到新服务器然后重载firewalld。确保两边的网络接口名称和 IP 规划一致否则可能需要调整区域与接口的绑定关系。版本控制我强烈建议将/etc/firewalld/目录纳入 Git 等版本控制系统。每次进行重大变更前提交一次当前状态。如果新规则导致网络中断可以快速回滚到上一个可用的配置版本。这比手动记忆和恢复要可靠得多。4.4 性能考量与调试技巧对于高流量服务器防火墙规则的数量和复杂度会影响性能。虽然firewalld本身开销很小它只是管理前端但底层nftables规则集的效率是关键。规则优化尽量使用“服务”而非大量独立的“端口”规则。富规则虽然强大但比简单的端口允许规则更耗资源。避免编写过于复杂、匹配条件很多的富规则。区域简化不要创建过多不必要的区域。每个区域都对应一套完整的规则链。根据网络拓扑合理规划区域数量。调试命令# 1. 查看详细规则转换为 nftables 后的样子 sudo nft list ruleset # 这是查看最终生效规则的最直接方式。 # 2. 查看 firewalld 的详细日志 sudo journalctl -u firewalld -f # 当添加/删除规则遇到问题时查看这里的日志非常有帮助。 # 3. 检查某个端口在哪个区域被如何处理的 sudo firewall-cmd --zonepublic --query-port8080/tcp sudo firewall-cmd --zoneinternal --query-port8080/tcp # 4. 追踪数据包路径高级调试 # 使用 nft 的追踪功能或者传统的 tcpdump 在相应网卡抓包。 sudo tcpdump -i ens224 port 80 -nnvv5. 常见问题排查与解决方案实录在实际操作中你肯定会遇到各种“坑”。下面是我总结的一些典型问题及其解决方法。5.1 规则不生效检查运行时与永久配置这是最常见的问题。现象是明明用firewall-cmd --add-port添加了规则但端口还是不通。原因1只修改了运行时配置但没有重载或保存为永久配置在firewalld服务重启后规则丢失。解决使用--runtime-to-permanent保存或使用--reload重载服务。原因2规则添加到了错误的区域。网卡接口可能绑定在另一个区域。解决使用firewall-cmd --get-active-zones和firewall-cmd --list-all --zonezone-name仔细检查接口绑定和区域内的规则。原因3有更优先的规则如一条reject或drop的富规则在先匹配并拒绝了流量。解决使用firewall-cmd --list-all --zonezone-name查看所有规则特别是富规则。注意规则的顺序firewalld中富规则的匹配顺序就是它们被添加的顺序。5.2 服务重启或系统重启后网络断开原因可能将管理 SSH 的网卡接口错误地绑定到了一个默认拒绝所有流量的区域如block,drop并且规则被永久化了。重启后SSH 连接被阻断。解决如果还能通过物理控制台Console登录直接在上面修改。如果无法物理登录并且服务器在云平台上如 AWS, Azure, GCP云平台通常提供了“救援模式”或“串行控制台”功能可以通过这些方式登录并修复配置。紧急情况下可以尝试在系统启动时grub菜单进入单用户模式或紧急模式这时网络和防火墙服务可能尚未启动可以修改/etc/firewalld/zones/下的配置文件。预防在永久化任何会阻断管理连接的规则之前务必先通过--timeout参数测试。例如你计划修改 SSH 端口或限制 IP可以先添加一个临时规则sudo firewall-cmd --zonepublic --add-rich-rule‘rule familyipv4 source address203.0.113.100 port port22 protocoltcp accept’ --timeout300这条规则会在300秒后自动消失给你一个测试和回滚的窗口期。5.3 自定义服务文件不识别或报错原因1XML 文件格式错误。解决使用xmllint工具检查语法。xmllint --noout /etc/firewalld/services/my-service.xml原因2文件权限或所有权不正确。解决确保文件属于root:root权限通常是644。sudo chown root:root /etc/firewalld/services/my-service.xml sudo chmod 644 /etc/firewalld/services/my-service.xml原因3没有重载firewalld。解决在创建或修改服务文件后执行sudo firewall-cmd --reload。5.4 与 Docker、Kubernetes 等容器网络的冲突容器技术如 Docker在启动时可能会自动创建自己的iptables/nftables规则有时会绕过或与firewalld的规则产生冲突导致容器网络不通。现象主机防火墙看起来开放了端口但容器服务无法从外部访问。解决思路让 Docker 使用 firewalld在 Docker 的配置文件中/etc/docker/daemon.json可以设置iptables: false来阻止 Docker 自动管理iptables。但这需要你手动在firewalld中为容器流量配置复杂的转发规则不推荐新手。更常见的做法也是 Docker 默认的允许 Docker 管理自己的链但确保firewalld不会过滤掉 Docker 网桥如docker0的流量。通常你需要将 Docker 的网桥接口或容器所在的网络接口放入trusted区域。sudo firewall-cmd --zonetrusted --add-interfacedocker0 --permanent sudo firewall-cmd --reload对于 Kubernetes情况更复杂kube-proxy会大量操作iptables/nftables。通常的实践是在 Kubernetes 节点上要么完全禁用firewalld使用其他如 Calico 的网络策略要么精细配置firewalld规则只管控节点管理流量将 Pod 和 Service 网络相关的接口如cni0,flannel.1等也放入trusted区域让 CNI 插件来管理其安全。5.5 富规则顺序问题与管理如前所述firewalld缺乏直接调整富规则顺序的命令。如果规则顺序错了比如先添加了一条drop all的规则后面的accept规则就永远不生效。解决使用sudo firewall-cmd --zonezone --list-rich-rules查看当前顺序。使用sudo firewall-cmd --zonezone --remove-rich-rule‘rule’删除需要调整的规则。注意删除时必须提供规则的完整文本复制时要确保引号匹配。按照你想要的顺序重新使用--add-rich-rule添加规则。这是一个繁琐的过程。因此在编写复杂的富规则集时最好先在文本编辑器中规划好顺序然后编写一个脚本一次性执行所有添加命令确保顺序正确。防火墙配置是门实践性极强的学问firewalld通过良好的抽象降低了入门门槛但其底层依然是复杂的网络包过滤体系。我的建议是在测试环境中多做实验每次变更前做好备份并使用--timeout参数进行安全测试。将配置文档化、版本化这样即使在最棘手的问题出现时你也能有条不紊地恢复和排查。记住防火墙策略的核心原则是“最小权限”只开放必须的拒绝一切不必要的并定期审计你的规则集。
