拓冰网站定制 
凌晨两点被一波登录失败告警叫醒登上去一看一台公网可达的 MySQL 端口被刷了几万次认证尝试——这种时候你才会真正体会到 Linux 防火墙 firewalld 默认策略的厉害不显式放行的一律进不来。反过来也一样只要你没把只允许特定 IP 访问这件事配对一条--add-port就可能把数据库、Redis、管理后台全部敞开给全世界。这篇东西不讲教科书目录只讲我这些年反复做过的一件事在 firewalld 上把某个服务、某个端口锁死给一批指定的 IP 或者网段并且保证它重启之后还在、变更之后不断、出错之后能查。如果你手里的机器是 CentOS 7/8、RHEL 7/8/9、Rocky、Alma、Fedora、openEuler 这一类默认防火墙管理工具就是 firewalld本文的命令可以直接抄。如果你只是想给自己的云主机开个 3306 给办公室或者想把 SSH 从公网收回到运维网段下面这些内容基本够你把活干完。我会把为什么这么写讲清楚因为 firewalld 最大的坑不是命令记不住而是规则写了却不生效你还不知道为什么。1. 先把需求说清楚只允许特定 IP 访问到底在限制什么很多人上来就问firewalld 怎么只允许某个 IP但真正落到配置上这句话至少要拆成三件事谁可以进源地址白名单、进来能碰什么端口/服务/协议、以及除白名单之外的流量怎么处置拒绝还是静默丢弃。这三件事没想清楚命令敲得再顺也会返工。1.1 三个必须先定的问题第一个问题是白名单的粒度。是单个 IP10.10.20.15、一个 C 段10.10.20.0/24还是一堆零散地址单个 IP 用富规则最省事成片的网段建议用独立 zone几十上百个零散地址就该上 ipset 集合了。别小看这个选择它直接决定了你后面每次加人加机器是改一条命令还是翻十个文件。第二个问题是保护对象。是只锁 SSH22、只锁数据库3306、6379、还是整机只留一个业务端口如果目标是这台机器只对运维网段开放管理入口那应该做的是把整个 zone 的白名单收窄而不是一个个端口去补规则——补漏永远补不完。第三个问题最容易被忽略非白名单流量要拒绝还是丢弃。拒绝REJECT会回一个 ICMP 不可达客户端立刻报No route to host或者Connection refused排查起来直观丢弃DROP什么都不回客户端只能等到超时安全性略高一点但排障时你会怀疑人生。我自己的习惯是内网服务用拒绝公网暴露面用丢弃。提示先把白名单 IP 从运维同事、跳板机、监控探针、CI 发布机、备份服务器这几个来源全部收集齐再去动防火墙。漏掉监控探针是最常见的事故来源——防火墙一改监控报警全红然后又慌慌张张全放开。1.2 为什么我不建议直接手写 iptables 规则firewalld 底层最终还是落到 netfilter 上理论上你完全可以用iptables -A INPUT -s 10.10.20.0/24 -p tcp --dport 3306 -j ACCEPT这类命令搞定。但在这类长期维护的机器上我基本不这么干原因有三个。第一firewalld 和裸 iptables 会互相打架。firewalld 在启动和 reload 时会重建自己的链你在它管理的链上手工插的规则下一次 reload 就可能被冲掉反过来你手工插在 INPUT 最前面的规则又可能让 firewalld 的 zone 规则形同虚设制造出我明明没放行怎么还能连上的诡异现象。第二RHEL 9 之后 firewalld 默认走 nftables 后端你敲iptables -L看到的其实是 iptables-nft 的翻译视图语义和真实的 nft 规则集并不完全一一对应。用nft list ruleset看反而更准但前提是你得懂 nft 语法。第三可维护性。firewalld 的规则是声明式的、存在 XML 里的可以纳入配置管理、可以做版本对比、可以--query-rich-rule查询。白名单这种需要长期维护的东西声明式永远比过程式友好。所以我的原则是能用 firewalld 的 zone、source、rich rule、ipset 解决的就不碰 direct 规则只有在容器链路这种 firewalld 管不到的地方才考虑去 DOCKER-USER 链上补规则。2. firewalld 的 zone 与 source 匹配逻辑规则写对了却不生效的根源命令我都敲了--list-all里也能看到但就是没用——这类问题九成出在匹配逻辑上。firewalld 不是规则列表它是区域 分发的模型一个包到底走哪个 zone是有明确优先级的。2.1 zone 是怎么被选中的firewalld 给每个网卡绑定一个默认 zone通常是 public同时允许某些 zone 绑定源地址。当一个数据包进入时匹配顺序大致是先看源地址有没有命中某个绑定了 source 的 zone命中就用那个 zone 的规则没命中再看入站网卡属于哪个 zone都没有走默认 zone。这个顺序带来一个非常关键的推论如果你在 public zone 里保留了service namessh同时又在另一个 zone 里给白名单 IP 放行了 SSH那么非白名单 IP 依然能从 public zone 进来。因为 public zone 是网卡绑定的 zone它照样在生效。很多人以为我新建了一个只允许白名单的 zone就安全了其实什么都没有改变。正确的做法是把该服务从通用 zone 里摘掉。用命令说就是先--remove-servicessh让 public zone 不再对所有人放行 SSH再把白名单单独处理。这一步不做后面写多少富规则都是白费。2.2 runtime 与 permanent一次规则丢失的真实教训firewalld 有运行时配置和永久配置两套。firewall-cmd不带--permanent是改运行时立刻生效但重启就没了带--permanent改的是/etc/firewalld下的文件必须--reload或者重启服务才生效。我早期踩过一次特别典型的坑为了快速让一个新来的同事连上数据库我敲了一条不带--permanent的富规则测试通了收工。半个月后机房割接重启白名单消失了数据库对全网敞开直到第二天安全扫描报告发过来才发现。从那之后我的习惯是任何一条规则都成对敲先敲--permanent版本再--reload最后用--permanent --list-all回读一遍确认它真的写进了配置文件。顺便说几个容易混淆的命令区别值得记住命令作用是否影响已建立连接firewall-cmd --reload按永久配置重建规则保留当前连接状态基本不影响firewall-cmd --complete-reload彻底重载连 netfilter 模块一起重置会断开现有连接firewall-cmd --runtime-to-permanent把当前运行时规则全部存成永久不影响systemctl reload firewalld等价于--reload基本不影响还有一个反直觉的点即使你把某个端口彻底封死已经建立起来的连接不会被新的防火墙规则掐断因为 firewalld 的 INPUT 链最前面有一条ctstate RELATED,ESTABLISHED的放行。这意味着你改完 SSH 白名单之后当前那个 SSH 会话还是活的你会误以为白名单没生效其实只是老连接还没断。验证必须另开一个新会话或者用nc -zv从别的机器上重新发起连接。3. 三种落地写法的选型对比与具体命令同一个需求firewalld 至少有三套写法复杂度、可维护性、适用场景完全不同。我把它们按什么时候用排一下你不用全学挑一个适合的就行。3.1 富规则rich rule单个端口白名单的首选如果需求是3306 只允许 10.10.20.0/24 访问其他端口保持现状富规则是最短路径。核心就两条把原来的通配放行去掉加上带 source 的放行。# 先看现状确认 3306 是不是通过 --add-port 对所有人开放的 firewall-cmd --zonepublic --list-all # 关键一步把通配的 3306 放行删掉 firewall-cmd --permanent --zonepublic --remove-port3306/tcp # 只给运维网段开口子 firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address10.10.20.0/24 port port3306 protocoltcp accept # 生效 firewall-cmd --reload # 回读确认 firewall-cmd --zonepublic --list-rich-rules富规则里的source只接受单个地址、单个网段、MAC 或者 ipset 名字不能写成逗号分隔的一串。所以如果你有五个来源要么写五条富规则要么上 ipset。另外富规则也支持直接引用服务名比如rule familyipv4 source address10.10.20.0/24 service namessh accept效果和写端口一样可读性更好。关于富规则的执行顺序这里必须提醒一句在同一个 priority默认 0下多条富规则的先后顺序在不同 firewalld 版本上表现并不完全一致早期版本甚至和你敲命令的顺序无关而是取决于配置文件的组织方式。所以别同时写一条 accept 和一条 drop 兜底然后指望顺序正确。正确姿势是让 zone 自己的 target 去兜底zone 默认 target 是 default未匹配任何规则的流量会被拒绝这就够了。如果你确实需要精确控制顺序用priority-10这种属性显式指定firewalld 0.6 及以上支持CentOS 7 自带的 0.4.x 不支持先firewall-cmd --version确认。3.2 独立 zone source多端口、多来源的清晰方案当你要保护的不止一个端口或者白名单有好几批来源我更倾向于新建一个专用 zone。好处是一次性把这批 IP 能碰什么打包描述清楚读起来像一份声明而不是一堆碎规则。# 新建一个不继承任何默认规则的空 zone firewall-cmd --permanent --new-zoneops-only # 绑定白名单来源可以绑多条 firewall-cmd --permanent --zoneops-only --add-source10.10.20.0/24 firewall-cmd --permanent --zoneops-only --add-source10.10.30.15/32 # 放开这批人需要的端口 firewall-cmd --permanent --zoneops-only --add-servicessh firewall-cmd --permanent --zoneops-only --add-port3306/tcp firewall-cmd --permanent --zoneops-only --add-port9100/tcp # 把通用 zone 里的对应放行撤掉这是最容易漏的一步 firewall-cmd --permanent --zonepublic --remove-servicessh firewall-cmd --permanent --zonepublic --remove-port3306/tcp firewall-cmd --reload firewall-cmd --get-active-zones--get-active-zones会列出每个活跃 zone 绑定的网卡和源地址这是我每次改完必看的命令它能一眼看出某个 zone 到底绑上了哪些 source避免zone 建了但没绑上这种低级问题。注意新建 zone 的默认 target 就是拒绝未匹配流量如果你希望对方连端口探测都得不到回应可以再补一条--permanent --zoneops-only --set-targetDROP行为会从回拒绝变成直接丢。3.3 ipset 集合IP 数量多、变更频繁时用白名单超过十几个、或者需要频繁增删比如给每个离职/入职的同事调整富规则的线性增长就很难看了。这时候用 ipset把地址集合从规则里抽出来单独维护。# 建一个 hash:net 类型的集合 firewall-cmd --permanent --new-ipsetops_allow --typehash:net # 往集合里塞地址网段和单 IP 都能塞 firewall-cmd --permanent --ipsetops_allow --add-entry10.10.20.0/24 firewall-cmd --permanent --ipsetops_allow --add-entry10.10.30.15/32 # 规则里引用集合名而不是具体地址 firewall-cmd --permanent --zonepublic --remove-port3306/tcp firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source ipsetops_allow port port3306 protocoltcp accept firewall-cmd --reload firewall-cmd --ipsetops_allow --get-entriesipset 最舒服的地方是变更成本低加一个地址只需要--ipsetops_allow --add-entryx.x.x.x/32运行时立即生效再补一条--permanent版本保证重启后还在根本不用动规则本身。但这里有个版本坑要提前说firewalld 0.9 之后在 RHEL 9 系上默认切到了 nftables 后端ipset 是通过 nft 的集合能力模拟实现的早期版本上确实出现过--new-ipset报错、或者规则能建但流量不被匹配的情况。动手前先确认两件事firewall-cmd --version和grep FirewallBackend /etc/firewalld/firewalld.conf。如果确实撞上了要么升级 firewalld要么退回到富规则写多条source address要么把后端切回 iptablesFirewallBackendiptables改完systemctl restart firewalld注意这会清掉运行时规则切之前在控制台做好备份。3.4 三种方案怎么选方案适合场景变更成本主要限制富规则1 到 2 个端口 少量来源低改一条命令一条规则只能一个 source来源多了会很长独立 zone多个端口 几批固定来源中需要维护 zone 绑定必须记得从通用 zone 撤掉对应放行ipset来源几十上百、频繁增删最低加地址即可后端兼容性需要确认老版本有坑我自己的默认选择是临时调试用富规则长期跑的服务上独立 zone白名单会持续变动的用 ipset。三者并不互斥同一台机器完全可以同时用。4. 完整实操把 SSH 和 MySQL 只开放给运维网段上面都是零件这一节把零件拼成一个完整可复现的过程。假设机器10.0.0.5运维网段10.10.20.0/24目标是把 SSH22和 MySQL3306只开放给这个网段其他端口维持现状。4.1 动手前的现状快照与回滚预案改防火墙最怕的不是改错是改错之后连不上去改回来。所以第一步永远是备份和留后路。# 备份整个 firewalld 配置目录 tar czf /root/firewalld-backup-$(date %F).tgz /etc/firewalld # 记录当前完整规则方便对比 firewall-cmd --list-all-zones /root/firewall-before.txt iptables -L -n --line-numbers /root/iptables-before.txt 2/dev/null nft list ruleset /root/nft-before.txt 2/dev/null # 挂一个 10 分钟后自动放行 SSH 的定时任务确认没问题再取消 echo firewall-cmd --permanent --zonepublic --add-servicessh; firewall-cmd --reload | at now 10 minutes atq这个at兜底是我强烈建议每个运维都养成的习惯。改完规则、验证通过之后atrm 任务号取消掉就行万一真把自己关在外面了十分钟后 SSH 自动恢复你可以从控制台或者 VNC 上去收拾。比事后求人开带外管理要体面得多。4.2 分步落地# 1. 确认服务本身在监听 ss -lntp | grep -E :(22|3306)\b # 2. 查看当前 zone 里 SSH 和 MySQL 是怎么放行的 firewall-cmd --zonepublic --list-all # 大概率能看到services: ssh ports: 3306/tcp # 3. 撤掉对所有人的放行 firewall-cmd --permanent --zonepublic --remove-servicessh firewall-cmd --permanent --zonepublic --remove-port3306/tcp # 4. 只给运维网段放行 firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address10.10.20.0/24 service namessh accept firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address10.10.20.0/24 port port3306 protocoltcp accept # 5. 应用并回读 firewall-cmd --reload firewall-cmd --zonepublic --list-all第 3 步是整套动作里唯一有断网风险的地方也是最有价值的地方。很多人舍不得删--remove-servicessh觉得反正我加了白名单规则老的放行留着也没事结果就是白名单形同虚设。如果你担心删除和新增之间有零点几秒的空窗比如正在跑自动化脚本可以把第 4 步的规则先用--timeout做成临时规则先加上确认无误后再转永久# 先临时生效 5 分钟方便快速验证 firewall-cmd --zonepublic --add-rich-rulerule familyipv4 source address10.10.20.0/24 service namessh accept --timeout300 # 验证通过后再写入永久配置 firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address10.10.20.0/24 service namessh accept firewall-cmd --reload4.3 验证三条命令确认规则真的生效验证不能只看配置要看实际流量行为。我通常从三个角度确认第一从白名单内的机器发起连接必须成功。nc -zv 10.0.0.5 22 nc -zv 10.0.0.5 3306 mysql -h 10.0.0.5 -u readonly -p -e select 1第二从白名单外的机器发起连接必须失败而且要看清失败方式。返回No route to host说明被 REJECT 了ICMP 不可达返回超时说明被 DROP 了。这两种都是对的只是策略不同但如果白名单外的机器居然连上了那一定是某个 zone 里还留着通配放行。# 在非白名单机器上执行预期失败 nc -zv -w 3 10.0.0.5 22 nc -zv -w 3 10.0.0.5 3306第三从内核层面看规则是否真的挂上去了。这一步能区分firewalld 说它加了和内核真的在拦。# iptables 后端 iptables -L IN_public -n -v --line-numbers # nftables 后端RHEL 9 系 nft list table inet firewalld | head -60 # 确认连接跟踪里白名单外的尝试确实被计数了 conntrack -L -p tcp --dport 3306 2/dev/null | head我最看重的是IN_public链里能看到那条带-s 10.10.20.0/24的 ACCEPT以及链尾那条拒绝规则。只要这两者同时存在且顺序正确逻辑上就不可能有漏网。5. 规则不生效的排查链路从现象到根因这部分是我觉得比命令更值钱的东西。firewalld 的问题几乎都能归到几类固定原因上按顺序排查基本十分钟内能定位。5.1 现象一加了白名单所有 IP 还是能连这是最高频的问题根因基本只有一个——通用 zone 里的通配放行没删。你在 public zone 留了--add-servicessh那所有 IP 都能连 SSH白名单规则根本没机会被匹配到因为通配规则已经把包接走了。排查动作firewall-cmd --zonepublic --list-services和--list-ports看看要保护的服务是不是还在里面。顺带还得确认一下有没有通过其他 zone 放行firewall-cmd --list-all-zones | grep -B5 -A5 ssh一把梭全查一遍。还有一个变种服务是通过--add-service加的你以为--remove-port能删掉它其实它挂在 service 下面删端口没用。SSH 就是典型它默认以--add-servicessh的形式存在必须--remove-servicessh。5.2 现象二白名单 IP 自己也连不上了这个更让人紧张但其实通常是三类原因。一是--reload之后运行时规则被永久配置覆盖而你只敲了运行时的那一条永久配置里没有所以白名单规则在 reload 时消失了。二是--add-source加到了 zone 上但那个 zone 没有绑定到正确的网卡或者源--get-active-zones一看就知道。三是目标端口本身没在监听或者监听在错误的地址上比如 MySQL 绑了bind-address 127.0.0.1那防火墙怎么放开都连不上用ss -lntp确认监听地址是0.0.0.0还是127.0.0.1。我遇到过一次特别隐蔽的防火墙完全正确但上层云平台的安全组只放行了办公网段运维网段压根没在安全组里。所以排查顺序永远是从外往里——先看云安全组/上层防火墙再看主机 firewalld最后看服务监听。5.3 现象三重启或者 reload 之后规则没了如果你用的是--permanent那不会丢。丢的情况基本是三种敲了不带--permanent的运行时规则手工写的 iptables 规则没有持久化或者是被杀软、安全加固脚本、配置管理工具在启动时重写了一遍防火墙配置。最后一种最阴。很多企业的基线加固脚本会在开机时执行一遍标准防火墙配置把你的自定义规则覆盖掉。这时候光改 firewalld 没用得去改那个加固脚本或者让它在末尾调用firewall-cmd --reload。5.4 Docker 与云端环境带来的额外干扰容器环境下firewalld 的白名单可能完全不起作用。原因是 Docker 启动时会自己往 iptables 的 filter 表和 nat 表里插链docker run -p发布的端口走的是DOCKER链在 firewalld 的 zone 链之前就被处理了所以你在 public zone 里怎么收窄都没用容器端口还是对所有 IP 开放。处理这类问题有几种思路我按推荐度排一下。首选是把规则加到DOCKER-USER链上这个链是 Docker 专门留给用户的不会被 Docker 自己覆盖# 允许白名单 iptables -I DOCKER-USER -s 10.10.20.0/24 -j RETURN # 其余全部丢弃 iptables -A DOCKER-USER -j DROP但要注意这些规则重启后会丢得配合iptables-services保存或者用 firewalld 的--direct规则写进去让 firewalld 帮你持久化。次选是让容器只监听内网地址把暴露面交给上游的负载均衡或反向代理来控制。最不推荐的就是直接关掉 Docker 的 iptables 管理--iptablesfalse那等于放弃了容器网络的所有隔离能力后面会出更大的问题。云端环境还要多查一层云厂商的安全组、网络 ACL、NAT 网关的白名单这些都是主机防火墙之外的前置关卡。主机上配对了、安全组没放行一样连不上反过来安全组放行了、主机上没配也一样连不上。这两层是与的关系不是或。5.5 排查顺序整理现象最可能的原因验证命令修复方式白名单外 IP 仍可访问通用 zone 有通配放行firewall-cmd --zonepublic --list-all--remove-service或--remove-port白名单内 IP 也连不上只敲了运行时规则firewall-cmd --permanent --zonepublic --list-rich-rules补--permanent后--reloadreload 后规则消失加固脚本覆盖配置grep -r firewall-cmd /etc/rc.d /etc/cron*修改脚本或调整执行顺序规则存在但完全不生效zone 没绑定到该网卡/源firewall-cmd --get-active-zones重新--add-source或绑定网卡容器端口仍全网开放Docker 链绕过 zoneiptables -L DOCKER-USER -n在 DOCKER-USER 链加规则连不上但无任何日志上层安全组未放行云控制台安全组规则补齐安全组白名单提示排查时优先用nc -zv -w 3从外部发起连接而不是在目标机器上curl localhost。本机回环流量根本不经过 INPUT 链的 zone 匹配测出来的结果永远是通的会把你带偏。6. 长期维护白名单变更、审计日志与防锁死机制配好只是开始真正费精力的是后面几个月甚至几年的维护。这块我吃过不少亏总结下来就三件事要提前做。6.1 把白名单当配置来管如果白名单会用 ipset建议写一个简单的增删脚本避免每次手敲长命令敲错 IP。核心是运行时和永久配置一起改改完不用 reloadipset 条目是即时生效的#!/bin/bash # /usr/local/bin/ops-allow.sh set -euo pipefail SETops_allow ACTION$1 ENTRY$2 case $ACTION in add) firewall-cmd --permanent --ipset$SET --add-entry$ENTRY firewall-cmd --ipset$SET --add-entry$ENTRY ;; del) firewall-cmd --permanent --ipset$SET --remove-entry$ENTRY firewall-cmd --ipset$SET --remove-entry$ENTRY ;; list) firewall-cmd --ipset$SET --get-entries ;; *) echo usage: $0 {add|del|list} ip[/mask] exit 1 ;; esac用法就是ops-allow.sh add 10.10.40.0/24。把/etc/firewalld/zones/*.xml和/etc/firewalld/ipsets/*.xml一起放进 Git 或者配置管理系统每次变更都有记录出问题能 diff。这比事后翻 bash history 猜自己改了什么靠谱一百倍。6.2 加日志把被拒绝的连接留痕光有白名单没有日志等于盲人摸象。当同事说我连不上了你得能立刻拿出证据证明你的 IP 不在白名单里而不是靠猜。做法很简单在 zone 里加一条带 log 的兜底规则把落网流量记下来。注意 log 可以和 drop/reject 组合在一条规则里firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address0.0.0.0/0 port port3306 protocoltcp log prefixMYSQL-DENY levelinfo limit value5/m drop firewall-cmd --reload # 看日志journald 环境 journalctl -k -f | grep MYSQL-DENY # 传统 rsyslog 环境 tail -f /var/log/messages | grep MYSQL-DENYlimit value5/m这个限速务必加上。不加的话一次端口扫描就能把磁盘写满或者直接把日志刷爆到日志系统崩掉这是血泪经验。前缀里带上服务名比如MYSQL-DENY、SSH-DENY后面过滤起来会轻松很多。还有一点如果你同时写了 accept 富规则和这条 drop 兜底规则顺序就很关键了。前面说过同 priority 下的顺序在不同版本上行为不一致所以这条 drop 规则更适合放在一个只绑定白名单源之外的流量的场景里或者干脆不写它让 zone 的 target 去兜底。要写就必须配priority不能靠运气。6.3 防锁死三件套最后说三个我每次都用的保命动作。第一改动前开两个 SSH 会话改完在第二个会话里验证验证通过再关第一个。第二用--timeout加临时规则做灰度确认无误再转永久。第三就是前面提到的at定时回滚。再补一个小技巧如果你把 SSH 换了非标准端口改 firewalld 只是第一步SELinux 那边也得放行否则会出现防火墙通了但服务起不来的现象# 查看当前允许的 SSH 端口 semanage port -l | grep ssh_port_t # 添加自定义端口 semanage port -a -t ssh_port_t -p tcp 22222另外提醒一句Debian 和 Ubuntu 默认用的是 ufw 而不是 firewalld命令风格完全不同放行白名单大概是ufw allow from 10.10.20.0/24 to any port 3306。关键是别在两套工具里同时开两边的规则都往 iptables 里写互相叠加之后你很难判断到底是哪条在生效排障成本会成倍上升。要切就彻底切先ufw disable再用 firewalld或者反过来。我个人在几台长期跑的机器上最后都收敛成了同一个模式一个专用的 ops-only zone 绑定运维网段ipset 维护具体地址一条日志兜底规则负责留痕配置目录进 Git。这样半年之后回头看白名单里都有谁、什么时候加的、为什么加一清二楚。防火墙这种东西配好那一刻不算完能在半年后还有人看得懂才算真的配好了。 firewalld 指定IP访问与端口白名单实战
凌晨两点被一波登录失败告警叫醒登上去一看一台公网可达的 MySQL 端口被刷了几万次认证尝试——这种时候你才会真正体会到 Linux 防火墙 firewalld 默认策略的厉害不显式放行的一律进不来。反过来也一样只要你没把只允许特定 IP 访问这件事配对一条--add-port就可能把数据库、Redis、管理后台全部敞开给全世界。这篇东西不讲教科书目录只讲我这些年反复做过的一件事在 firewalld 上把某个服务、某个端口锁死给一批指定的 IP 或者网段并且保证它重启之后还在、变更之后不断、出错之后能查。如果你手里的机器是 CentOS 7/8、RHEL 7/8/9、Rocky、Alma、Fedora、openEuler 这一类默认防火墙管理工具就是 firewalld本文的命令可以直接抄。如果你只是想给自己的云主机开个 3306 给办公室或者想把 SSH 从公网收回到运维网段下面这些内容基本够你把活干完。我会把为什么这么写讲清楚因为 firewalld 最大的坑不是命令记不住而是规则写了却不生效你还不知道为什么。1. 先把需求说清楚只允许特定 IP 访问到底在限制什么很多人上来就问firewalld 怎么只允许某个 IP但真正落到配置上这句话至少要拆成三件事谁可以进源地址白名单、进来能碰什么端口/服务/协议、以及除白名单之外的流量怎么处置拒绝还是静默丢弃。这三件事没想清楚命令敲得再顺也会返工。1.1 三个必须先定的问题第一个问题是白名单的粒度。是单个 IP10.10.20.15、一个 C 段10.10.20.0/24还是一堆零散地址单个 IP 用富规则最省事成片的网段建议用独立 zone几十上百个零散地址就该上 ipset 集合了。别小看这个选择它直接决定了你后面每次加人加机器是改一条命令还是翻十个文件。第二个问题是保护对象。是只锁 SSH22、只锁数据库3306、6379、还是整机只留一个业务端口如果目标是这台机器只对运维网段开放管理入口那应该做的是把整个 zone 的白名单收窄而不是一个个端口去补规则——补漏永远补不完。第三个问题最容易被忽略非白名单流量要拒绝还是丢弃。拒绝REJECT会回一个 ICMP 不可达客户端立刻报No route to host或者Connection refused排查起来直观丢弃DROP什么都不回客户端只能等到超时安全性略高一点但排障时你会怀疑人生。我自己的习惯是内网服务用拒绝公网暴露面用丢弃。提示先把白名单 IP 从运维同事、跳板机、监控探针、CI 发布机、备份服务器这几个来源全部收集齐再去动防火墙。漏掉监控探针是最常见的事故来源——防火墙一改监控报警全红然后又慌慌张张全放开。1.2 为什么我不建议直接手写 iptables 规则firewalld 底层最终还是落到 netfilter 上理论上你完全可以用iptables -A INPUT -s 10.10.20.0/24 -p tcp --dport 3306 -j ACCEPT这类命令搞定。但在这类长期维护的机器上我基本不这么干原因有三个。第一firewalld 和裸 iptables 会互相打架。firewalld 在启动和 reload 时会重建自己的链你在它管理的链上手工插的规则下一次 reload 就可能被冲掉反过来你手工插在 INPUT 最前面的规则又可能让 firewalld 的 zone 规则形同虚设制造出我明明没放行怎么还能连上的诡异现象。第二RHEL 9 之后 firewalld 默认走 nftables 后端你敲iptables -L看到的其实是 iptables-nft 的翻译视图语义和真实的 nft 规则集并不完全一一对应。用nft list ruleset看反而更准但前提是你得懂 nft 语法。第三可维护性。firewalld 的规则是声明式的、存在 XML 里的可以纳入配置管理、可以做版本对比、可以--query-rich-rule查询。白名单这种需要长期维护的东西声明式永远比过程式友好。所以我的原则是能用 firewalld 的 zone、source、rich rule、ipset 解决的就不碰 direct 规则只有在容器链路这种 firewalld 管不到的地方才考虑去 DOCKER-USER 链上补规则。2. firewalld 的 zone 与 source 匹配逻辑规则写对了却不生效的根源命令我都敲了--list-all里也能看到但就是没用——这类问题九成出在匹配逻辑上。firewalld 不是规则列表它是区域 分发的模型一个包到底走哪个 zone是有明确优先级的。2.1 zone 是怎么被选中的firewalld 给每个网卡绑定一个默认 zone通常是 public同时允许某些 zone 绑定源地址。当一个数据包进入时匹配顺序大致是先看源地址有没有命中某个绑定了 source 的 zone命中就用那个 zone 的规则没命中再看入站网卡属于哪个 zone都没有走默认 zone。这个顺序带来一个非常关键的推论如果你在 public zone 里保留了service namessh同时又在另一个 zone 里给白名单 IP 放行了 SSH那么非白名单 IP 依然能从 public zone 进来。因为 public zone 是网卡绑定的 zone它照样在生效。很多人以为我新建了一个只允许白名单的 zone就安全了其实什么都没有改变。正确的做法是把该服务从通用 zone 里摘掉。用命令说就是先--remove-servicessh让 public zone 不再对所有人放行 SSH再把白名单单独处理。这一步不做后面写多少富规则都是白费。2.2 runtime 与 permanent一次规则丢失的真实教训firewalld 有运行时配置和永久配置两套。firewall-cmd不带--permanent是改运行时立刻生效但重启就没了带--permanent改的是/etc/firewalld下的文件必须--reload或者重启服务才生效。我早期踩过一次特别典型的坑为了快速让一个新来的同事连上数据库我敲了一条不带--permanent的富规则测试通了收工。半个月后机房割接重启白名单消失了数据库对全网敞开直到第二天安全扫描报告发过来才发现。从那之后我的习惯是任何一条规则都成对敲先敲--permanent版本再--reload最后用--permanent --list-all回读一遍确认它真的写进了配置文件。顺便说几个容易混淆的命令区别值得记住命令作用是否影响已建立连接firewall-cmd --reload按永久配置重建规则保留当前连接状态基本不影响firewall-cmd --complete-reload彻底重载连 netfilter 模块一起重置会断开现有连接firewall-cmd --runtime-to-permanent把当前运行时规则全部存成永久不影响systemctl reload firewalld等价于--reload基本不影响还有一个反直觉的点即使你把某个端口彻底封死已经建立起来的连接不会被新的防火墙规则掐断因为 firewalld 的 INPUT 链最前面有一条ctstate RELATED,ESTABLISHED的放行。这意味着你改完 SSH 白名单之后当前那个 SSH 会话还是活的你会误以为白名单没生效其实只是老连接还没断。验证必须另开一个新会话或者用nc -zv从别的机器上重新发起连接。3. 三种落地写法的选型对比与具体命令同一个需求firewalld 至少有三套写法复杂度、可维护性、适用场景完全不同。我把它们按什么时候用排一下你不用全学挑一个适合的就行。3.1 富规则rich rule单个端口白名单的首选如果需求是3306 只允许 10.10.20.0/24 访问其他端口保持现状富规则是最短路径。核心就两条把原来的通配放行去掉加上带 source 的放行。# 先看现状确认 3306 是不是通过 --add-port 对所有人开放的 firewall-cmd --zonepublic --list-all # 关键一步把通配的 3306 放行删掉 firewall-cmd --permanent --zonepublic --remove-port3306/tcp # 只给运维网段开口子 firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address10.10.20.0/24 port port3306 protocoltcp accept # 生效 firewall-cmd --reload # 回读确认 firewall-cmd --zonepublic --list-rich-rules富规则里的source只接受单个地址、单个网段、MAC 或者 ipset 名字不能写成逗号分隔的一串。所以如果你有五个来源要么写五条富规则要么上 ipset。另外富规则也支持直接引用服务名比如rule familyipv4 source address10.10.20.0/24 service namessh accept效果和写端口一样可读性更好。关于富规则的执行顺序这里必须提醒一句在同一个 priority默认 0下多条富规则的先后顺序在不同 firewalld 版本上表现并不完全一致早期版本甚至和你敲命令的顺序无关而是取决于配置文件的组织方式。所以别同时写一条 accept 和一条 drop 兜底然后指望顺序正确。正确姿势是让 zone 自己的 target 去兜底zone 默认 target 是 default未匹配任何规则的流量会被拒绝这就够了。如果你确实需要精确控制顺序用priority-10这种属性显式指定firewalld 0.6 及以上支持CentOS 7 自带的 0.4.x 不支持先firewall-cmd --version确认。3.2 独立 zone source多端口、多来源的清晰方案当你要保护的不止一个端口或者白名单有好几批来源我更倾向于新建一个专用 zone。好处是一次性把这批 IP 能碰什么打包描述清楚读起来像一份声明而不是一堆碎规则。# 新建一个不继承任何默认规则的空 zone firewall-cmd --permanent --new-zoneops-only # 绑定白名单来源可以绑多条 firewall-cmd --permanent --zoneops-only --add-source10.10.20.0/24 firewall-cmd --permanent --zoneops-only --add-source10.10.30.15/32 # 放开这批人需要的端口 firewall-cmd --permanent --zoneops-only --add-servicessh firewall-cmd --permanent --zoneops-only --add-port3306/tcp firewall-cmd --permanent --zoneops-only --add-port9100/tcp # 把通用 zone 里的对应放行撤掉这是最容易漏的一步 firewall-cmd --permanent --zonepublic --remove-servicessh firewall-cmd --permanent --zonepublic --remove-port3306/tcp firewall-cmd --reload firewall-cmd --get-active-zones--get-active-zones会列出每个活跃 zone 绑定的网卡和源地址这是我每次改完必看的命令它能一眼看出某个 zone 到底绑上了哪些 source避免zone 建了但没绑上这种低级问题。注意新建 zone 的默认 target 就是拒绝未匹配流量如果你希望对方连端口探测都得不到回应可以再补一条--permanent --zoneops-only --set-targetDROP行为会从回拒绝变成直接丢。3.3 ipset 集合IP 数量多、变更频繁时用白名单超过十几个、或者需要频繁增删比如给每个离职/入职的同事调整富规则的线性增长就很难看了。这时候用 ipset把地址集合从规则里抽出来单独维护。# 建一个 hash:net 类型的集合 firewall-cmd --permanent --new-ipsetops_allow --typehash:net # 往集合里塞地址网段和单 IP 都能塞 firewall-cmd --permanent --ipsetops_allow --add-entry10.10.20.0/24 firewall-cmd --permanent --ipsetops_allow --add-entry10.10.30.15/32 # 规则里引用集合名而不是具体地址 firewall-cmd --permanent --zonepublic --remove-port3306/tcp firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source ipsetops_allow port port3306 protocoltcp accept firewall-cmd --reload firewall-cmd --ipsetops_allow --get-entriesipset 最舒服的地方是变更成本低加一个地址只需要--ipsetops_allow --add-entryx.x.x.x/32运行时立即生效再补一条--permanent版本保证重启后还在根本不用动规则本身。但这里有个版本坑要提前说firewalld 0.9 之后在 RHEL 9 系上默认切到了 nftables 后端ipset 是通过 nft 的集合能力模拟实现的早期版本上确实出现过--new-ipset报错、或者规则能建但流量不被匹配的情况。动手前先确认两件事firewall-cmd --version和grep FirewallBackend /etc/firewalld/firewalld.conf。如果确实撞上了要么升级 firewalld要么退回到富规则写多条source address要么把后端切回 iptablesFirewallBackendiptables改完systemctl restart firewalld注意这会清掉运行时规则切之前在控制台做好备份。3.4 三种方案怎么选方案适合场景变更成本主要限制富规则1 到 2 个端口 少量来源低改一条命令一条规则只能一个 source来源多了会很长独立 zone多个端口 几批固定来源中需要维护 zone 绑定必须记得从通用 zone 撤掉对应放行ipset来源几十上百、频繁增删最低加地址即可后端兼容性需要确认老版本有坑我自己的默认选择是临时调试用富规则长期跑的服务上独立 zone白名单会持续变动的用 ipset。三者并不互斥同一台机器完全可以同时用。4. 完整实操把 SSH 和 MySQL 只开放给运维网段上面都是零件这一节把零件拼成一个完整可复现的过程。假设机器10.0.0.5运维网段10.10.20.0/24目标是把 SSH22和 MySQL3306只开放给这个网段其他端口维持现状。4.1 动手前的现状快照与回滚预案改防火墙最怕的不是改错是改错之后连不上去改回来。所以第一步永远是备份和留后路。# 备份整个 firewalld 配置目录 tar czf /root/firewalld-backup-$(date %F).tgz /etc/firewalld # 记录当前完整规则方便对比 firewall-cmd --list-all-zones /root/firewall-before.txt iptables -L -n --line-numbers /root/iptables-before.txt 2/dev/null nft list ruleset /root/nft-before.txt 2/dev/null # 挂一个 10 分钟后自动放行 SSH 的定时任务确认没问题再取消 echo firewall-cmd --permanent --zonepublic --add-servicessh; firewall-cmd --reload | at now 10 minutes atq这个at兜底是我强烈建议每个运维都养成的习惯。改完规则、验证通过之后atrm 任务号取消掉就行万一真把自己关在外面了十分钟后 SSH 自动恢复你可以从控制台或者 VNC 上去收拾。比事后求人开带外管理要体面得多。4.2 分步落地# 1. 确认服务本身在监听 ss -lntp | grep -E :(22|3306)\b # 2. 查看当前 zone 里 SSH 和 MySQL 是怎么放行的 firewall-cmd --zonepublic --list-all # 大概率能看到services: ssh ports: 3306/tcp # 3. 撤掉对所有人的放行 firewall-cmd --permanent --zonepublic --remove-servicessh firewall-cmd --permanent --zonepublic --remove-port3306/tcp # 4. 只给运维网段放行 firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address10.10.20.0/24 service namessh accept firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address10.10.20.0/24 port port3306 protocoltcp accept # 5. 应用并回读 firewall-cmd --reload firewall-cmd --zonepublic --list-all第 3 步是整套动作里唯一有断网风险的地方也是最有价值的地方。很多人舍不得删--remove-servicessh觉得反正我加了白名单规则老的放行留着也没事结果就是白名单形同虚设。如果你担心删除和新增之间有零点几秒的空窗比如正在跑自动化脚本可以把第 4 步的规则先用--timeout做成临时规则先加上确认无误后再转永久# 先临时生效 5 分钟方便快速验证 firewall-cmd --zonepublic --add-rich-rulerule familyipv4 source address10.10.20.0/24 service namessh accept --timeout300 # 验证通过后再写入永久配置 firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address10.10.20.0/24 service namessh accept firewall-cmd --reload4.3 验证三条命令确认规则真的生效验证不能只看配置要看实际流量行为。我通常从三个角度确认第一从白名单内的机器发起连接必须成功。nc -zv 10.0.0.5 22 nc -zv 10.0.0.5 3306 mysql -h 10.0.0.5 -u readonly -p -e select 1第二从白名单外的机器发起连接必须失败而且要看清失败方式。返回No route to host说明被 REJECT 了ICMP 不可达返回超时说明被 DROP 了。这两种都是对的只是策略不同但如果白名单外的机器居然连上了那一定是某个 zone 里还留着通配放行。# 在非白名单机器上执行预期失败 nc -zv -w 3 10.0.0.5 22 nc -zv -w 3 10.0.0.5 3306第三从内核层面看规则是否真的挂上去了。这一步能区分firewalld 说它加了和内核真的在拦。# iptables 后端 iptables -L IN_public -n -v --line-numbers # nftables 后端RHEL 9 系 nft list table inet firewalld | head -60 # 确认连接跟踪里白名单外的尝试确实被计数了 conntrack -L -p tcp --dport 3306 2/dev/null | head我最看重的是IN_public链里能看到那条带-s 10.10.20.0/24的 ACCEPT以及链尾那条拒绝规则。只要这两者同时存在且顺序正确逻辑上就不可能有漏网。5. 规则不生效的排查链路从现象到根因这部分是我觉得比命令更值钱的东西。firewalld 的问题几乎都能归到几类固定原因上按顺序排查基本十分钟内能定位。5.1 现象一加了白名单所有 IP 还是能连这是最高频的问题根因基本只有一个——通用 zone 里的通配放行没删。你在 public zone 留了--add-servicessh那所有 IP 都能连 SSH白名单规则根本没机会被匹配到因为通配规则已经把包接走了。排查动作firewall-cmd --zonepublic --list-services和--list-ports看看要保护的服务是不是还在里面。顺带还得确认一下有没有通过其他 zone 放行firewall-cmd --list-all-zones | grep -B5 -A5 ssh一把梭全查一遍。还有一个变种服务是通过--add-service加的你以为--remove-port能删掉它其实它挂在 service 下面删端口没用。SSH 就是典型它默认以--add-servicessh的形式存在必须--remove-servicessh。5.2 现象二白名单 IP 自己也连不上了这个更让人紧张但其实通常是三类原因。一是--reload之后运行时规则被永久配置覆盖而你只敲了运行时的那一条永久配置里没有所以白名单规则在 reload 时消失了。二是--add-source加到了 zone 上但那个 zone 没有绑定到正确的网卡或者源--get-active-zones一看就知道。三是目标端口本身没在监听或者监听在错误的地址上比如 MySQL 绑了bind-address 127.0.0.1那防火墙怎么放开都连不上用ss -lntp确认监听地址是0.0.0.0还是127.0.0.1。我遇到过一次特别隐蔽的防火墙完全正确但上层云平台的安全组只放行了办公网段运维网段压根没在安全组里。所以排查顺序永远是从外往里——先看云安全组/上层防火墙再看主机 firewalld最后看服务监听。5.3 现象三重启或者 reload 之后规则没了如果你用的是--permanent那不会丢。丢的情况基本是三种敲了不带--permanent的运行时规则手工写的 iptables 规则没有持久化或者是被杀软、安全加固脚本、配置管理工具在启动时重写了一遍防火墙配置。最后一种最阴。很多企业的基线加固脚本会在开机时执行一遍标准防火墙配置把你的自定义规则覆盖掉。这时候光改 firewalld 没用得去改那个加固脚本或者让它在末尾调用firewall-cmd --reload。5.4 Docker 与云端环境带来的额外干扰容器环境下firewalld 的白名单可能完全不起作用。原因是 Docker 启动时会自己往 iptables 的 filter 表和 nat 表里插链docker run -p发布的端口走的是DOCKER链在 firewalld 的 zone 链之前就被处理了所以你在 public zone 里怎么收窄都没用容器端口还是对所有 IP 开放。处理这类问题有几种思路我按推荐度排一下。首选是把规则加到DOCKER-USER链上这个链是 Docker 专门留给用户的不会被 Docker 自己覆盖# 允许白名单 iptables -I DOCKER-USER -s 10.10.20.0/24 -j RETURN # 其余全部丢弃 iptables -A DOCKER-USER -j DROP但要注意这些规则重启后会丢得配合iptables-services保存或者用 firewalld 的--direct规则写进去让 firewalld 帮你持久化。次选是让容器只监听内网地址把暴露面交给上游的负载均衡或反向代理来控制。最不推荐的就是直接关掉 Docker 的 iptables 管理--iptablesfalse那等于放弃了容器网络的所有隔离能力后面会出更大的问题。云端环境还要多查一层云厂商的安全组、网络 ACL、NAT 网关的白名单这些都是主机防火墙之外的前置关卡。主机上配对了、安全组没放行一样连不上反过来安全组放行了、主机上没配也一样连不上。这两层是与的关系不是或。5.5 排查顺序整理现象最可能的原因验证命令修复方式白名单外 IP 仍可访问通用 zone 有通配放行firewall-cmd --zonepublic --list-all--remove-service或--remove-port白名单内 IP 也连不上只敲了运行时规则firewall-cmd --permanent --zonepublic --list-rich-rules补--permanent后--reloadreload 后规则消失加固脚本覆盖配置grep -r firewall-cmd /etc/rc.d /etc/cron*修改脚本或调整执行顺序规则存在但完全不生效zone 没绑定到该网卡/源firewall-cmd --get-active-zones重新--add-source或绑定网卡容器端口仍全网开放Docker 链绕过 zoneiptables -L DOCKER-USER -n在 DOCKER-USER 链加规则连不上但无任何日志上层安全组未放行云控制台安全组规则补齐安全组白名单提示排查时优先用nc -zv -w 3从外部发起连接而不是在目标机器上curl localhost。本机回环流量根本不经过 INPUT 链的 zone 匹配测出来的结果永远是通的会把你带偏。6. 长期维护白名单变更、审计日志与防锁死机制配好只是开始真正费精力的是后面几个月甚至几年的维护。这块我吃过不少亏总结下来就三件事要提前做。6.1 把白名单当配置来管如果白名单会用 ipset建议写一个简单的增删脚本避免每次手敲长命令敲错 IP。核心是运行时和永久配置一起改改完不用 reloadipset 条目是即时生效的#!/bin/bash # /usr/local/bin/ops-allow.sh set -euo pipefail SETops_allow ACTION$1 ENTRY$2 case $ACTION in add) firewall-cmd --permanent --ipset$SET --add-entry$ENTRY firewall-cmd --ipset$SET --add-entry$ENTRY ;; del) firewall-cmd --permanent --ipset$SET --remove-entry$ENTRY firewall-cmd --ipset$SET --remove-entry$ENTRY ;; list) firewall-cmd --ipset$SET --get-entries ;; *) echo usage: $0 {add|del|list} ip[/mask] exit 1 ;; esac用法就是ops-allow.sh add 10.10.40.0/24。把/etc/firewalld/zones/*.xml和/etc/firewalld/ipsets/*.xml一起放进 Git 或者配置管理系统每次变更都有记录出问题能 diff。这比事后翻 bash history 猜自己改了什么靠谱一百倍。6.2 加日志把被拒绝的连接留痕光有白名单没有日志等于盲人摸象。当同事说我连不上了你得能立刻拿出证据证明你的 IP 不在白名单里而不是靠猜。做法很简单在 zone 里加一条带 log 的兜底规则把落网流量记下来。注意 log 可以和 drop/reject 组合在一条规则里firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address0.0.0.0/0 port port3306 protocoltcp log prefixMYSQL-DENY levelinfo limit value5/m drop firewall-cmd --reload # 看日志journald 环境 journalctl -k -f | grep MYSQL-DENY # 传统 rsyslog 环境 tail -f /var/log/messages | grep MYSQL-DENYlimit value5/m这个限速务必加上。不加的话一次端口扫描就能把磁盘写满或者直接把日志刷爆到日志系统崩掉这是血泪经验。前缀里带上服务名比如MYSQL-DENY、SSH-DENY后面过滤起来会轻松很多。还有一点如果你同时写了 accept 富规则和这条 drop 兜底规则顺序就很关键了。前面说过同 priority 下的顺序在不同版本上行为不一致所以这条 drop 规则更适合放在一个只绑定白名单源之外的流量的场景里或者干脆不写它让 zone 的 target 去兜底。要写就必须配priority不能靠运气。6.3 防锁死三件套最后说三个我每次都用的保命动作。第一改动前开两个 SSH 会话改完在第二个会话里验证验证通过再关第一个。第二用--timeout加临时规则做灰度确认无误再转永久。第三就是前面提到的at定时回滚。再补一个小技巧如果你把 SSH 换了非标准端口改 firewalld 只是第一步SELinux 那边也得放行否则会出现防火墙通了但服务起不来的现象# 查看当前允许的 SSH 端口 semanage port -l | grep ssh_port_t # 添加自定义端口 semanage port -a -t ssh_port_t -p tcp 22222另外提醒一句Debian 和 Ubuntu 默认用的是 ufw 而不是 firewalld命令风格完全不同放行白名单大概是ufw allow from 10.10.20.0/24 to any port 3306。关键是别在两套工具里同时开两边的规则都往 iptables 里写互相叠加之后你很难判断到底是哪条在生效排障成本会成倍上升。要切就彻底切先ufw disable再用 firewalld或者反过来。我个人在几台长期跑的机器上最后都收敛成了同一个模式一个专用的 ops-only zone 绑定运维网段ipset 维护具体地址一条日志兜底规则负责留痕配置目录进 Git。这样半年之后回头看白名单里都有谁、什么时候加的、为什么加一清二楚。防火墙这种东西配好那一刻不算完能在半年后还有人看得懂才算真的配好了。