生产环境里给数据库、缓存、后台管理端口做 IP 白名单是我这些年做过最多的防火墙操作没有之一。Linux 防火墙 firewall 只允许特定 IP 访问这件事听起来就是一条规则的事但真到线上往往会在规则写了却没生效放行了还是连不上重启之后策略全丢这几步上反复折腾。而且很多事故不是防火墙没配是配得太宽松——端口开着、来源不限等于门装了锁却没锁上。这篇就把我用 firewalld 做 IP 白名单的完整思路摊开讲从需求怎么拆、zone 和 rich rule 怎么选到具体命令怎么写、怎么验证、怎么不把自己锁在门外全部给到能直接抄的配置。刚接触 Linux 的同学可以照着做有一点基础的可以重点看第三、四章的方案对比和第五章的排坑清单那些都是我实际踩过、并且在别人的机器上重复见过的问题。1. 先把需求想清楚为什么不是封端口而是认IP拿到只让某个 IP 访问某端口这个需求时很多人的第一反应是把端口全封掉然后再开口子。方向没错但顺序和粒度一旦搞混后面就会陷入今天加一个 IP、明天删一个 IP的循环。所以动手之前先把场景和原则对齐。1.1 三个最典型的白名单场景第一个是数据库。MySQL、PostgreSQL、Redis 这类服务正常只有应用服务器会连办公网和个人电脑根本不该有连接。这时候把 3306、6379 限制到应用服务器的网段是最划算的一条规则。第二个是运维入口。SSH 的 22 端口暴露在公网日志里每天几百上千次暴力尝试是常态。把它收敛到跳板机或者固定办公出口 IP攻击面立刻小一大截。这里要说明一点改端口不是安全措施扫描器一样找得到真正的收敛还是靠来源限制。第三个是内部管理后台。比如 Nginx 后面的 Grafana、Jenkins、各种管理面板通常挂在 80/443 或者高位端口上。这类服务本身有认证但版本漏洞、弱口令的新闻从来没断过加一层 IP 白名单等于多加一道锁。三个场景的共同点是来源是确定的、数量有限的、可控的。反过来如果是面向公网用户的业务端口就不该用 IP 白名单那是另一个思路。1.2 默认拒绝这件事比你想的更重要白名单的本质是默认拒绝 显式放行。这句话谁都懂但落实到操作上有两个细节特别容易翻车。第一放行之前先确认默认状态是不是拒绝。很多系统的 firewalld 默认 public zone 里已经放行了一批服务你只是又加了一条 rich rule那端口对所有人还是开的。正确顺序是先把宽泛的放行删掉再加精确的。第二拒绝的写法要分清 drop 和 reject。drop 是静默丢弃客户端会一直等到超时用户感受到的是卡住reject 会返回一个拒绝报文客户端秒失败报错信息明确。生产上我倾向用 reject因为出问题时排查成本低得多。drop 只在需要隐藏服务存在性的时候用但说实话在内部环境这个收益很有限。提示不要一边做白名单一边留着旧的宽泛规则。防火墙的匹配是有顺序和优先级的两套规则共存时人脑很难准确推演最终结果出问题时你会怀疑人生。1.3 工具选型firewalld、iptables、ufw 怎么选CentOS 7 之后、RHEL 7 之后、Fedora 系列默认都是 firewalld。它是对 nftables 或 iptables 的一层封装好处是配置持久化、支持 zone 抽象、支持 rich rule改完 reload 就能生效。RHEL 8 以上 firewalld 已经默认走 nftables 后端可以用下面这条命令确认firewall-cmd --get-backend返回nftables或者iptables看到哪个都不影响使用命令语法是一样的。iptables 是更底层的选择灵活但要自己处理持久化iptables-save、iptables-persistent或者写 systemd 单元规则一多也难维护。Debian、Ubuntu 系上还有 ufw语法最简单但它也是 iptables 的前端功能相对单薄。我的取舍很简单目标机器上已经跑着 firewalld就用 firewalld只有 iptables 环境就用 iptablesUbuntu 小机器图省事就 ufw。不要为了统一管理在一台已经跑着 firewalld 的机器上再装一套 ufw两套前端抢同一套内核规则后果很不可控。2. firewalld 的匹配逻辑先搞懂再动手命令敲下去能不能生效取决于你能不能预测 firewalld 会怎么匹配这条流量。这一章讲的不是概念科普是排错的底层依据。2.1 zone 的优先级source 永远压过 interfacefirewalld 用 zone区域来组织规则。一个网卡、一个来源地址都会被归属到某个 zone 里然后按那个 zone 的规则处理。归属的判断顺序是先看source也就是来源 IP 或网段和哪个 zone 里配置的 source 匹配source 匹配不上再看interface也就是包从哪张网卡进来都不匹配落到默认 zone通常是 public。这个顺序是理解所有白名单配置的钥匙。因为它意味着如果你给某个来源单独指定了一个 zone那么它的所有流量只按那个 zone 的规则走其他 zone 里放行了什么都没用。看当前状态用firewall-cmd --get-active-zones firewall-cmd --get-default-zone firewall-cmd --list-all --zonepublic--get-active-zones会告诉你每个 zone 当前挂了哪些 interface 和 source这是排查我的规则为什么不生效的第一个命令。注意同一个 source 不能同时出现在两个 zone 里。firewalld 不允许如果尝试添加会报冲突或者后者覆盖前者行为不保证。改配置前先用--get-active-zones确认。2.2 运行时配置和永久配置两个世界firewalld 有两套配置runtime 和 permanent。不带--permanent的命令改的是内存里的运行时规则立即生效重启丢失带--permanent的命令改的是磁盘上的配置文件不立即生效需要 reload 或者重启firewall-cmd --reload会把 permanent 的配置加载成 runtime。我在客户现场见过不止一次工程师加了一堆--permanent规则然后重启服务测发现好了但另一台机器加完不 reload 就测试怎么都不通最后排查了两小时。推荐的节奏是调试阶段用临时规则快速试确认无误后转到 permanent最后 reload 验证一次。把当前 runtime 整体固化的命令是firewall-cmd --runtime-to-permanent另外要区分两个 reloadfirewall-cmd --reload # 重载配置已建立的连接通常保留 firewall-cmd --complete-reload # 完全重载会清 conntrack已建立的连接会断日常改白名单用--reload就行。除非规则出现诡异的不生效才考虑--complete-reload但那会掐断在线连接生产环境要谨慎。2.3 rich rule 和 zone 白名单两条路线做只允许特定 IP 访问这件事firewalld 里有两条主流路线。路线一rich rule。用--add-rich-rule在一个 zone 里写带条件的放行语句语法接近自然语言。优点是直观、改动小、可以精确到某来源 某端口 某协议缺点是入口多了以后规则列表会变得很长。路线二自定义 zone。新建一个 zone把允许的来源用--add-source放进去再在这个 zone 里放行需要的端口。优点是把客户名单和服务清单分开管理扩缩容时思路清楚缺点是要理顺 zone 之间的优先级容易漏掉继承问题。两条路线我都用选择标准是来源数量少个位数且端口固定用 rich rule来源是一个网段或者需要长期维护的白名单用自定义 zone。下面两章分别给完整操作。3. 方案一rich rule 精确放行特定 IPrich rule 是我日常用得最多的写法因为它能在一行里表达完整的意图谁、从哪里来、访问什么、怎么处理。3.1 单 IP 单端口的最小可用配置假设应用服务器是10.20.30.40数据库端口 3306只允许它连。三条命令搞定。# 1. 先把 public zone 里对 3306 的宽泛放行删掉如果之前加过 firewall-cmd --permanent --zonepublic --remove-port3306/tcp # 2. 加一条只允许 10.20.30.40 访问 3306 的规则 firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address10.20.30.40/32 port port3306 protocoltcp accept # 3. 重载生效 firewall-cmd --reload逐段解释一下这条 rich rule 的语义。familyipv4协议族。纯 IPv4 环境写死 ipv4 最稳写 ipv6 的话源地址格式要跟着换。如果机器是双栈需要写两条。source address10.20.30.40/32来源地址。/32表示精确到单个 IP其实省略掩码也是按 /32 处理但写上更明确团队里其他人一眼能看懂。port port3306 protocoltcp目标端口和协议。注意这里的 port 写的是本机监听的端口不是客户端的源端口。accept匹配后放行。顺手加个日志出问题时能直接看到是谁被拒了firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address10.20.30.40/32 port port3306 protocoltcp log prefixDB-ALLOW levelinfo accept前缀里带上服务名日志里一 grep 就能定位。3.2 网段、多端口、多来源的写法放行一个网段把/32换成网段掩码即可firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address10.20.30.0/24 port port3306 protocoltcp accept这里有个常被忽略的点10.20.30.0/24覆盖 254 个地址如果你的应用集群只有 3 台机器用 /24 就等于多放行了 251 个潜在入口。做安全收敛时能写单机就写单机除非你确实不关心这个网段里的其他设备。放行一段连续端口用短横线firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address10.20.30.0/24 port port3306-3308 protocoltcp accept多端口但不是连续段rich rule 的 port 字段不支持逗号列表只能写多条 rule。比如同时开放 3306 和 6379firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address10.20.30.0/24 port port3306 protocoltcp accept firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source address10.20.30.0/24 port port6379 protocoltcp accept来源很多的时候一条条写 rich rule 会很臃肿这时候用 ipset。ipset 是内核里的地址集合匹配效率比逐条规则高管理也方便# 建一个 ipset类型 hash:net 表示可以放网段 firewall-cmd --permanent --new-ipsetdb_clients --typehash:net # 往集合里加条目 firewall-cmd --permanent --ipsetdb_clients --add-entry10.20.30.0/24 firewall-cmd --permanent --ipsetdb_clients --add-entry172.16.5.10 firewall-cmd --permanent --ipsetdb_clients --add-entry192.168.100.0/26 # 用 ipset 作为来源写一条 rich rule firewall-cmd --permanent --zonepublic --add-rich-rulerule familyipv4 source ipsetdb_clients port port3306 protocoltcp accept firewall-cmd --reload以后新增机器只需要往 ipset 里--add-entry不用动 zone 里的规则。查看集合内容firewall-cmd --permanent --ipsetdb_clients --get-entries这个用法在客户列表经常变的场景下特别省事我在做多租户环境的端口隔离时基本都用它。3.3 别忘了把默认放行关掉这是最容易被跳过的一步也是配了白名单却等于没配的头号原因。用下面这条命令把 public zone 的家底翻出来firewall-cmd --zonepublic --list-all重点看这几个字段字段含义处理建议ports直接放行的端口与白名单冲突的端口全部 removeservices按服务名放行的规则检查有没有覆盖目标端口比如 mysql 服务名rich rules已有富规则检查是否存在source缺失的宽泛规则masquerade地址伪装与白名单无关但顺手确认下是否符合预期interfaces绑定到该 zone 的网卡确认没有意外把网卡全绑进来删除宽泛放行的命令firewall-cmd --permanent --zonepublic --remove-port3306/tcp firewall-cmd --permanent --zonepublic --remove-servicemysql firewall-cmd --reload提示--remove-servicemysql和--remove-port3306/tcp是两回事。如果端口是通过 service 定义放行的删 port 是删不掉的。所以每次都要--list-all看全局不能只看 ports 那一栏。3.4 验证从允许的和不允许的两端各测一次规则加完必须从两个方向验证只测一边等于没测。在允许的机器上nc -vz 10.20.30.50 3306 # 或者 telnet 10.20.30.50 3306预期是succeeded或Connected。在不允许的机器上同样的命令预期是Connection refusedreject或者长时间挂起直到超时drop。如果允许的机器通了、不允许的机器也通说明有别的宽泛规则还在放行回到 3.3 继续删。如果两边都不通先别怀疑防火墙看第五章。本机验证防火墙规则是否命中可以看计数器nft list ruleset | grep -A5 3306 # nftables 后端 iptables -L -n -v | grep 3306 # iptables 后端计数器不涨说明流量根本没走到这条规则上。4. 方案二自定义 zone把白名单做成一等公民rich rule 适合小规模来源一多、端口一杂规则列表就开始变得难以阅读。这时候自定义 zone 会更清爽。4.1 建一个专用 zone 的思路核心思想是把这个 zone 当成一张客户名单 服务清单。名单里的来源source只能访问清单里的端口其他一律拒绝。名单外的来源压根不会匹配到这个 zone它们该去哪去哪被默认 zone 拒绝或者放行。关键点在于给这个 zone 设置一个严格的目标策略target。firewalld 里 target 的含义是这样的target未明确匹配的流量怎么处理default继续往下走其他 zone 的匹配流程ACCEPT全部接受REJECT返回拒绝报文DROP静默丢弃白名单场景我一般设REJECT让名单内的来源没被显式放行就直接被拒不再有其他 zone 兜底。这样行为可预测审计起来也清楚。4.2 完整实操步骤目标只允许10.20.30.0/24访问 3306 和 6379同时这个网段还要能 SSH 登录做运维。# 1. 新建一个 zone firewall-cmd --permanent --new-zonedbwl # 2. 把白名单来源放进去 firewall-cmd --permanent --zonedbwl --add-source10.20.30.0/24 # 3. 在 zone 内放行需要的端口 firewall-cmd --permanent --zonedbwl --add-port3306/tcp firewall-cmd --permanent --zonedbwl --add-port6379/tcp # 4. 关键让这个网段还能 SSH否则运维进来就断了 firewall-cmd --permanent --zonedbwl --add-servicessh # 5. 设置严格策略 firewall-cmd --permanent --zonedbwl --set-targetREJECT # 6. 重载 firewall-cmd --reload # 7. 确认归属 firewall-cmd --get-active-zones第 7 步的输出应该能看到dbwl下面挂着sources: 10.20.30.0/24。如果有问题也在这里能第一时间发现。这里有两个坑必须展开说。坑一别忘了放行 SSH。因为10.20.30.0/24这个网段的所有流量都归到dbwlzone 了而 dbwl 的 target 是 REJECT。你如果不显式放行 ssh运维人员的 SSH 会直接断而且是在你 reload 的那一刻断非常刺激。所以第 4 步不能省。坑二原 zone 里的宽泛放行还得删。白名单网段归到 dbwl 了但其他来源还是会走 public zone。public zone 里如果还留着 3306 的放行那么名单外的机器照样能连。所以要去 public zone 里把对应端口删掉firewall-cmd --permanent --zonepublic --remove-port3306/tcp firewall-cmd --permanent --zonepublic --remove-port6379/tcp firewall-cmd --reload这一步和 3.3 讲的是一样的道理白名单方案的效果 精确放行 删除宽泛放行缺一不可。4.3 两种方案的对比与选型建议维度rich rule自定义 zone上手难度低写一行是一条中要先理解 zone 归属规则可读性来源少时清晰多了就乱来源多时依然清晰来源变更需要加删规则或维护 ipset只动 source端口清单不变端口变更改动局部会影响该 zone 内所有来源误锁风险较低中容易漏放行 SSH 等必要服务适用规模来源 1~5 个来源一个网段或长期白名单我的实际做法通常是两者混用用小规模 rich rule 处理临时、零星的需求用自定义 zone 处理稳定的、成规模的隔离需求。混用本身没问题前提是每个改动都跟着--list-all确认一遍最终状态。5. 踩坑实录配置生效了但连不上的十种可能这一章是我觉得最有价值的部分。防火墙规则只是链路上的一环很多白名单配了还是连不上的问题根子压根不在防火墙。5.1 防火墙之外的三道门第一道服务本身监听在哪。用ss -tlnp看监听地址ss -tlnp | grep 3306如果输出是127.0.0.1:3306那这个服务只接受本机连接外面放行多少条规则都没用。需要改服务配置文件里的bind-addressMySQL或者bindRedis到0.0.0.0或者具体内网 IP然后重启服务。这个坑我在新装环境里踩过很多次尤其是那些默认装完就只监听本地的发行版包。第二道SELinux。在 RHEL、CentOS 系上如果你把服务端口改成了非标准端口比如 MySQL 换成 3307SELinux 会拦住它。检查方式getenforce semanage port -l | grep mysqld_port_t需要给新端口打标签semanage port -a -t mysqld_port_t -p tcp 3307getenforce返回Permissive的话不会拦但返回Enforcing就一定会。很多人排查到崩溃最后发现是 SELinux从此逢人就劝关 SELinux——这没必要加个标签就好。第三道云平台的安全组。这是最容易漏的一层。本地 firewalld 配得好好的但云上的安全组只开了 22 和 803306 压根没放行。安全组和主机防火墙是两道独立的门两道都要开。排查顺序建议是先看安全组再看主机防火墙最后看服务监听和 SELinux。从外到内一层层剥。5.2 常见问题速查表下面这张表是我自己整理的出问题的时候按顺序对一遍基本都能定位。现象最可能的原因排查命令 / 处理允许的机器也连不上服务只监听 127.0.0.1ss -tlnp检查监听地址允许的机器也连不上SELinux 拦截非标准端口getenforce、semanage port -l允许的机器也连不上云安全组没放行控制台检查安全组入方向规则不允许的机器也能连上还有宽泛的端口/服务放行firewall-cmd --list-all逐项检查不允许的机器也能连上同一来源挂在别的 zonefirewall-cmd --get-active-zones规则改了没反应只加了--permanent没 reloadfirewall-cmd --reload重启后规则全丢只加了 runtime 规则firewall-cmd --runtime-to-permanent连接卡住等到超时用的是 drop 而不是 reject把 drop 改成 reject报错 already exists规则重复添加--list-rich-rules查看后 removeSSH 断了白名单 zone 没放行 ssh带外控制台进去补--add-servicessh5.3 我自己的几条硬规矩做了这么多年总结下来有几条纪律能省掉大量的返工。第一条改防火墙之前先确认带外通道。物理机看有没有 IPMI云主机看控制台的 VNC 或串口登录能不能用。有一次我在一台没有带外通道的机器上改 SSH 白名单source 少写了一个网段结果把自己锁在外面只能让 IDC 的同事去机房插显示器。那之后我给自己定了个规矩没有带外通道的机器绝不在远程会话里直接 reload 防火墙。第二条用 at 或者 sleep 做自动回滚。这个技巧在改 SSH 相关规则时特别管用。做法是先起一个定时任务比如 5 分钟后把防火墙恢复到当前状态然后你再改规则。如果改完发现自己还能连上就去把那个定时任务取消如果连不上了5 分钟后自动回滚你又能进去了。# 先备份当前配置 firewall-cmd --runtime-to-permanent cp -r /etc/firewalld /etc/firewalld.bak.$(date %F-%H%M) # 起一个 5 分钟后执行的恢复任务 echo cp -rf /etc/firewalld.bak.$(date %F-%H%M)/* /etc/firewalld/ firewall-cmd --reload | at now 5 minutes然后放心大胆地改。改完确认没问题atq看一下任务号atrm删掉。第三条每条规则都要能说出来源和目的。我见过太多祖传规则谁也不知道为什么开、能不能删。所以我加规则的时候都会在维护文档里写清楚加了什么、为什么加、申请人是谁、什么时候可以清理。三个月之后回头看能省掉大量分析时间。第四条默认拒绝的同时日志要开。打开被拒流量的日志firewall-cmd --permanent --zonepublic --set-log-deniedall firewall-cmd --reload然后实时看journalctl -f -k | grep -i -E denied|dropped日志量大的时候要注意set-log-denied会刷屏建议配合limit使用比如在 rich rule 里加limit value10/m每分钟最多记 10 条。既能发现问题又不至于把磁盘写满。注意set-log-denied是 zone 级设置在生产环境长期开着要评估日志量。更稳妥的办法是只在排查期间开启定位完再关掉。6. 规模化维护批量白名单与自锁保护当机器数量从几台变成几十台白名单从三条变成三十条前面那些单机操作就不够用了。这一章讲两件我实际用得上的事。6.1 用脚本管理白名单手动敲命令的问题是容易漏、容易写错、没法审计。我的做法是把白名单写成一份文本清单然后用脚本读它幂等地同步到 firewalld。清单文件/etc/firewalld-whitelist.txt# 服务名 端口 来源 mysql 3306 10.20.30.0/24 mysql 3306 172.16.5.10/32 redis 6379 10.20.30.0/24同步脚本sync-whitelist.sh#!/bin/bash set -euo pipefail LIST/etc/firewalld-whitelist.txt IPSETmanaged_whitelist # 确保 ipset 存在 firewall-cmd --permanent --get-ipsets | grep -qw $IPSET || \ firewall-cmd --permanent --new-ipset$IPSET --typehash:net # 清空后重建条目保证幂等 for entry in $(firewall-cmd --permanent --ipset$IPSET --get-entries); do firewall-cmd --permanent --ipset$IPSET --remove-entry$entry done declare -A PORTS while read -r svc port src; do [[ -z ${svc:-} || $svc \#* ]] continue firewall-cmd --permanent --ipset$IPSET --add-entry$src PORTS[$port]$svc done $LIST # 为每个端口生成一条引用 ipset 的 rich rule for port in ${!PORTS[]}; do rulerule family\ipv4\ source ipset\$IPSET\ port port\$port\ protocol\tcp\ accept firewall-cmd --permanent --zonepublic --query-rich-rule$rule /dev/null 21 || \ firewall-cmd --permanent --zonepublic --add-rich-rule$rule done firewall-cmd --reload firewall-cmd --zonepublic --list-rich-rules脚本的关键设计点有三个。set -euo pipefail保证任何一步出错就停下不会带着半截状态继续跑。--query-rich-rule先判断再添加保证重复执行不会产生重复规则这就是幂等。最后统一 reload 一次避免中途 reload 导致连接抖动。这套东西我在十几台机器的环境里用了两年多改成 file 驱动之后加个 IP 就是编辑一行文本、跑一次脚本、看一眼输出比登进去敲命令靠谱得多。6.2 防止把自己锁在门外的兜底方案前面提过 at 定时回滚这里补充两个更长期的方案。方案一保留一个管理 zone。专门划一个来源网段或者一台跳板机的 IP给它单独一个 zone只放 SSH并且这个 zone 不参与任何业务端口的管理。这样不管你怎么改业务白名单管理入口始终是通的。firewall-cmd --permanent --new-zonemgmt firewall-cmd --permanent --zonemgmt --add-source192.168.88.0/24 firewall-cmd --permanent --zonemgmt --add-servicessh firewall-cmd --permanent --zonemgmt --set-targetREJECT firewall-cmd --reload方案二配置备份 定时校验。把/etc/firewalld纳入版本管理或者定期备份同时写一个巡检脚本每天检查一遍关键端口是否可连、白名单是否被意外清空。这个脚本可以用 nc 做简单探测#!/bin/bash TARGETS(10.20.30.50:3306 10.20.30.50:6379) for t in ${TARGETS[]}; do host${t%%:*}; port${t##*:} if nc -z -w3 $host $port; then echo OK $t else echo FAIL $t fi done挂到 cron 里每天跑一次输出到日志或者直接发通知。防火墙这种东西平时不出声一出事就是全站级别的有个定时体检能提前发现很多问题。最后分享一点我的实际体会这些年做下来我越来越觉得只允许特定 IP 访问这件事难点从来不在命令本身。命令就那么几条翻来覆去地敲一周就能背下来。真正的难点在于你要清楚知道流量的完整路径上有哪些关卡每一关现在是什么状态改完之后如何在不影响自己的前提下验证。安全组、主机防火墙、服务监听、SELinux、中间件自带的访问控制这五层里任意一层配错最终效果都不是你想要的。另外一个小习惯可能比技术更管用每次改防火墙先把当前状态完整地打印出来存档。firewall-cmd --list-all-zones /tmp/fw-before-$(date %F-%H%M).txt改完再存一份 after。真出问题的时候diff 一下这两份文件比凭记忆回忆我刚才改了啥靠谱一百倍。这个动作只花十秒钟但救过我至少三四次。