Linux IP白名单配置实战：从iptables到应用层防护

这篇事情要从一次不算愉快的排障说起。有台线上服务器被安全团队扫出异常，登录日志里一大半是来自各个地区IP的SSH爆破尝试，虽然密码够复杂没被攻破，但看着那几百条 Failed password 记录，心里属实不安稳。后来处理方案很简单：给这台机器加上IP白名单，只允许公司办公网出口IP和跳板机IP连进去，其他来源一律在防火墙层面就拦掉。就是这个过程，让我想好好把"Linux添加IP白名单"这件事从头到尾梳理一遍。

日常工作中你会发现，IP白名单需求比想象中常见得多：管理后台只允许内部网络访问、数据库端口只对应用服务器开放、SSH只接受固定出口IP连接、第三方回调接口只信任对方服务器地址……说法五花八门，落到技术上都是同一套能力：在Linux系统里，按来源IP精确控制谁能访问哪个服务。这篇文章就围绕这个场景展开，覆盖iptables和firewalld两种防火墙方案，再到Nginx、Servlet容器、SSH这些常用服务的白名单配置，最后是我自己踩过的一些坑和排查套路。适合Linux运维、后端开发，以及自建服务器、对安全性有要求的个人用户参考。你不需要把每条命令背下来，但看完至少能搞清楚"在哪个环节加白名单最合适、配完怎么验证、出了问题怎么查"。

1. 先搞清楚：Linux下IP白名单到底有哪几层

1.1 网络层白名单：负责“能不能连上”

网络层白名单，对应的就是Linux防火墙，常见的是iptables和firewalld。它们工作在TCP/IP协议栈的内核层面，在数据包真正到达应用程序之前做判断，允许的放行，不允许的直接丢弃或者拒绝。你可以把它理解成小区大门的保安，先看你的脸（来源IP），再看你要去几栋几单元（目标端口），不在名单里的压根进不了小区。

为什么要在这一层做白名单？因为效率高、覆盖范围广。一个端口一旦在iptables层面DROP掉，后面所有依赖这个端口的服务都不需要再关心请求来源，哪怕是Nginx、MySQL这类应用本身有Bug，网络层已经把危险挡在了门外。而且这一层的粒度可以非常细：源IP、源端口、目标IP、目标端口、协议类型都能组合匹配，也就是所谓的"四元组匹配"。可以说，网络层白名单是整个访问控制体系的基石，也是绝大多数场景下的首选方案。

1.2 应用层白名单：负责“进来之后能干什么”

网络层放行之后，请求会进入应用程序。应用层白名单就是在软件内部再设置一道关卡，典型代表是Nginx的allow/deny指令、Web应用的拦截器、Servlet容器的访问控制配置。它相当于楼栋单元的门禁，进了小区并不代表你能进每一栋楼，application层还要再验一次身份。

应用层白名单最大的优势是条件判断更灵活。你可以基于URL路径、请求方法、请求头、Cookie，甚至业务用户信息来做判断，而网络层只能看IP和端口。比如管理后台的/admin路径只允许内网IP访问，但前端静态资源允许所有人访问，这种场景用iptables做不了，Nginx里配置却很方便。另外，应用层白名单对应用自身的状态是感知的，可以做更丰富的日志记录，出问题时排查起来更直观。

但应用层白名单有个致命弱点：它依赖程序本身的正确性，代码逻辑有漏洞、配置项没生效，白名单就形同虚设。所以安全设计上讲究纵深防御，网络层和应用层各设一道门，而不是只靠其中一层。

1.3 服务层白名单：单独给SSH这类关键服务开小灶

单独把SSH拿出来说，是因为它太特殊了。SSH是每一台Linux服务器的命脉，一旦配置错，你可能连机器都登不进去。SSH相关的白名单，传统做法是通过/etc/hosts.allow和/etc/hosts.deny这两个文件，利用TCP Wrapper机制做访问控制，指定哪些来源IP可以使用ssh服务。不过需要提醒的是，现在不少Linux发行版默认不再编译libwrap支持，这种方式在部分系统上是不生效的，用之前得确认。

更通用、更推荐的方式，是直接在sshd_config里用Match Address做匹配。它可以在sshd进程内部做判断，效果上类似白名单，而且还不会影响防火墙规则。实际项目中，我通常建议：SSH白名单同时配置在防火墙和服务层两层，网络层负责拦掉绝大多数扫描流量，服务层负责账户策略的兜底，例如非白名单来源强制使用密钥登录、禁止密码登录。这对抵御暴力破解非常有效。

2. 最常用的方案：用iptables给SSH和业务端口做白名单

2.1 动手前先确认两件事：现状和安全通道

配iptables白名单，最怕的就是配到一半断连。不管你多熟练，操作前一定要先确认两件事：第一，当前机器的防火墙状态和已有规则是什么样的，别上来就追加，结果和旧规则冲突；第二，你有没有一条"救命通道"——比如云平台的VNC控制台、带外管理卡，再不济也得有个能登录物理机的途径。没有这条退路，IP白名单配置失误时，你连后悔的机会都没有。

查看当前状态和规则：

# 查看防火墙是否运行 systemctl status iptables 2>/dev/null || systemctl status firewalld # 查看INPUT链现有规则，带行号和流量统计 iptables -L INPUT -n --line-numbers -v

输出里你会看到每条规则的匹配条件、目标动作，以及已经匹配了多少个数据包。如果没有输出或者提示链不存在，说明当前INPUT链可能没有显式规则，全部依赖默认策略。看到默认策略是ACCEPT还是DROP很重要，这直接决定你接下来的配置顺序。

2.2 白名单规则的核心：顺序比命令本身还重要

iptables的规则是按顺序匹配的，上一条命中之后，下一条就不再执行。这就会引出一个经典误区：有人把白名单ACCEPT规则加在末尾，但前面已经有一条拒绝所有来源的DROP规则，白名单自然永远不会生效。正确思路是把白名单规则放在前面，拒绝规则放在后面。

以只允许某个IP访问SSH为例：

# 1. 允许白名单IP访问22端口 iptables -A INPUT -s 203.0.113.5/32 -p tcp --dport 22 -j ACCEPT # 2. 拒绝其他所有来源访问22端口 iptables -A INPUT -p tcp --dport 22 -j DROP

这里-s指定来源IP，/32是IPv4的单IP掩码写法，-p tcp限定协议，--dport 22限定目标端口，-j ACCEPT表示放行，-j DROP表示静默丢弃。用-A追加时，两条规则的相对顺序就是上面的样子，白名单在前，拒绝在后。如果反过来先DROP再ACCEPT，那后面那条ACCEPT永远不会被匹配到，等于所有来源都被封了。

我习惯把白名单规则用-I INPUT 1插到链首，确保它肯定在拒绝规则之前：

# 在INPUT链第1条位置插入白名单规则 iptables -I INPUT 1 -s 203.0.113.5/32 -p tcp --dport 22 -j ACCEPT

-I是插入，1是插入到第一条，这样做的好处是无论之前链上有什么规则，这条白名单都最先判断。但要注意，插入到最前只对"允许的IP"有效，如果旧链上还有别的拒绝规则，依然会挡掉后面追加的允许规则，所以稳妥起见还是先查看现状再动手。

2.3 多IP多网段怎么办：循环、文件和ipset

生产环境往往不止一个IP需要放行。办公网一堆出口IP、几个合作方的服务器IP、跳板机IP，加起来可能几十个。如果逐条iptables -A写上去，人累不说，规则维护也是一团乱麻。这种情况下我通常用两种方式：

第一种，把IP写进文件，用循环批量添加：

# 每行一个IP，井号开头是注释 cat > /etc/ip-whitelist.txt <<'EOF' 203.0.113.5 203.0.113.10 198.51.100.0/24 EOF # 批量添加白名单规则 while read ip; do [[ "$ip" =~ ^#.*$ || -z "$ip" ]] && continue iptables -A INPUT -s "$ip" -p tcp --dport 22 -j ACCEPT done < /etc/ip-whitelist.txt

第二种，IP数量特别多（上百个）的时候，建议用ipset。ipset的好处是匹配性能更高，而且规则只写一条，后续增删IP不用改iptables规则，只需操作ipset集合。基础用法：

# 创建一个名为whitelist的IP集合 ipset create whitelist hash:ip # 往集合里添加IP ipset add whitelist 203.0.113.5 ipset add whitelist 198.51.100.0/24 # 让iptables直接匹配这个集合 iptables -I INPUT 1 -m set --match-set whitelist src -p tcp --dport 22 -j ACCEPT

后续要临时放行某个IP，执行ipset add whitelist 新IP即可生效，不需要再动iptables规则。这个思路在维护大量白名单时非常实用，尤其是业务方频繁"这个IP也要加一下"的场景。

2.4 保存规则：别再让重启把白名单“冲掉”

iptables命令直接操作的是内核当前生效的规则，内存态的，重启后默认全部丢失。不少新人配完白名单测得好好的，隔天机器一重启，规则全没了，服务重新暴露出来。所以规则配置完，一定要保存。

不同发行版保存方式不一样：

• RHEL/CentOS 6 及以前：service iptables save，规则写入/etc/sysconfig/iptables
• RHEL/CentOS 7/8、Rocky Linux、AlmaLinux 等：如果用了firewalld，不要混用iptables命令做持久化；如果确实在管理iptables，需要安装iptables-services包

yum install -y iptables-services systemctl enable iptables systemctl start iptables iptables-save > /etc/sysconfig/iptables

• Ubuntu/Debian：安装iptables-persistent

apt install -y iptables-persistent netfilter-persistent save

需要注意，现在很多发行版底层已经用nftables替代了iptables，iptables命令只是一个兼容层。我见过一些系统上iptables-save保存完，重启后规则又没了的Case，多半是persistent服务没启动或者系统同时存在firewalld在管理nftables规则集。配置完成后，最好主动重启一次机器验证规则还在不在，别等业务告警了才想起检查。

3. 现代发行版的主流选择：firewalld白名单实战

3.1 zone概念与rich rule配置

如果你用的是RHEL/CentOS 7以上、Rocky Linux、Fedora这类发行版，默认防火墙管理工具是firewalld，很多人还停留在"firewalld是iptables的壳"这种认知上。这个说法没大错，firewalld底层确实还是nftables/iptables，但它引入了一套更直观的管理模型：zone（区域）。每个网络接口可以归属一个zone，不同zone有不同的信任级别和放行策略。比如默认的public zone，对外部流量采取保守策略；trusted zone则表示完全信任这个来源。

给特定IP放行某个端口，最灵活的是使用rich rule（富规则）。例如只允许办公网IP段访问SSH：

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.0/24" port protocol="tcp" port="22" accept'

这条命令的语义很直白：对来自203.0.113.0/24网段的IPv4流量，如果目标是TCP端口22，就接受。加--permanent表示写入持久化配置，不加的话只对当前运行期有效。配置完记得重新加载：

firewall-cmd --reload

如果要移除这条白名单：

firewall-cmd --permanent --remove-rich-rule='rule family="ipv4" source address="203.0.113.0/24" port protocol="tcp" port="22" accept' firewall-cmd --reload

很多朋友喜欢用firewall-cmd --add-port=22/tcp这种方式放行端口，但它放行的是所有来源，相当于没有白名单。如果明确要做IP白名单，rich rule才是正确的姿势，别把这两个概念混了。

3.2 验证与回滚：先不持久化，确认再保存

firewalld的配置有两个状态：运行期和持久化。运行期配置即时生效但不保证重启保留，持久化配置写入磁盘在重启后加载。我强烈建议调试阶段只改运行期配置，验证没问题后再加--permanent保存。这样即使规则写错，重新加载或者重启机器，系统还能恢复到原来状态，不至于因为一条错误的rich rule连不上服务器。

一个例子，我想放行某个IP访问Web端口，先执行：

firewall-cmd --add-rich-rule='rule family="ipv4" source address="203.0.113.5/32" port protocol="tcp" port="80" accept'

然后用另一台机器验证访问是否正常，确认无误后，再补上--permanent重新执行并reload。验证白名单是否生效有个实用小技巧：你用非白名单IP访问一下相关端口，如果被拒绝，说明规则工作正常；如果还能访问，说明规则有问题，或者有其他放行规则存在。

查看当前firewalld所有有效规则，用这条命令：

firewall-cmd --list-all

它会显示当前zone里放行的所有服务、端口和rich rules，一目了然。

3.3 iptables还是firewalld：选型经验

我在实际工作中经常被问：到底用iptables还是firewalld好？答案取决于环境和你的使用习惯。如果是新装的标准发行版，firewalld是默认方案，zone和rich rule的语义清晰，配置管理比纯iptables命令可读性好太多，而且支持动态修改、运行时和持久化分离，踩坑概率更低。

如果你维护的是一批存量机器，系统里已经有一套成熟的iptables脚本，或者你更习惯把规则写进启动脚本里统一管理，那继续用iptables也沒问题。技术没有好坏，只有适不适合。不过要提醒一点：firewalld和iptables-services不要同时启用，否则两个工具都在管理内核规则，互相覆盖，排起障来酸爽加倍。选一个作为主力，另一个停用并禁用开机自启。

4. 再做一层保险：Nginx、Servlet容器和SSH的白名单

4.1 Nginx的allow/deny：给管理后台加门禁

网络层防火墙搞定之后，其实已经能挡住绝大多数不安全访问了。但有些场景必须在应用层再配一层白名单，比如同一个Nginx上跑着多个站点，只希望管理后台路径对特定来源开放，其他路径保持不变。这时候Nginx的allow和deny指令就派上用场了。

配置在server块、location块或者http块里均可，以location为例：

# 管理后台只允许办公网IP访问 location /admin/ { allow 192.168.1.0/24; allow 203.0.113.5; deny all; # 下面继续配置你的代理、静态文件等逻辑 proxy_pass http://backend_admin; }

这段配置的意思是：来源IP是192.168.1.0/24网段或者203.0.113.5时，允许访问/admin/路径；其他来源一律拒绝，返回403。同样要注意匹配顺序，Nginx的allow和deny是从上往下匹配的，找到了匹配项就停止。所以必须把具体的允许规则写在deny all前面，否则deny all会先拦住一切。

在Nginx里做IP白名单，很多人容易忽略一个问题：如果前面挂了CDN、SLB或者多层反向代理，Nginx拿到的remote_addr是代理服务器的IP，不是真实客户端IP。直接按remote_addr做白名单，要么把代理IP放行（等于放开所有经过代理的来源），要么把真实IP全部误拦。正确做法是先通过real_ip模块，告诉Nginx哪些来源是可信代理，然后从X-Forwarded-For里提取真实IP：

# 信任内网代理服务器 set_real_ip_from 10.0.0.0/8; real_ip_header X-Forwarded-For; real_ip_recursive on;

这段配置放在http块里，配合allow/deny使用，$remote_addr就会变成真实客户端IP，白名单判断就准确了。这个点非常关键，我在后面排查章节还会再展开。

4.2 服务端口白名单：以Druid StatViewServlet为例

Java后端用Druid连接池的很多，Druid自带的监控页StatViewServlet功能强大，能看到SQL执行、连接池占用、慢查询等一堆敏感信息。这个页面暴露在公网上，基本等于把数据库健康状况脱光了给人看。Druid本身是有白名单设计的，但很多人没配置，或者根本不知道有这个参数。

在Spring Boot中配置Druid监控页的白名单：

spring: datasource: druid: stat-view-servlet: # 开启监控页 enabled: true url-pattern: /druid/* # 白名单，多个IP用逗号分隔，留空意味着允许所有IP访问 allow: 127.0.0.1,203.0.113.5 # 黑名单，优先于白名单 deny: 10.0.0.0/8 # 登录监控页的账号密码，必须设强密码 login-username: admin login-password: 你自己的复杂密码

这里有一个关键点，也是官方文档里容易被忽略的说明：allow参数如果不配置，默认表示允许所有来源访问。这个"默认开放"的设计初衷可能是方便开发调试，但是如果直接部署到生产环境，运维又没注意到这个参数，监控页就裸奔在公网上了。我在不少客户现场见过这种情况，alert日志里一堆扫描器在探测/druid/index.html，因为路径是公开的，一探测一个准。

Druid的allow参数支持IP和IP段，格式是逗号分隔的字符串。常见的误区是以为deny优先，实际也是deny优先，即被deny的IP无论是否在allow里，都会被拒绝。这是一个很实用的细节。

4.3 SSH白名单：从hosts.allow到Match Address

在sysV时代，管理SSH白名单最常见的做法是改/etc/hosts.allow和/etc/hosts.deny：

# /etc/hosts.allow sshd: 203.0.113.5 sshd: 192.168.1.0/255.255.255.0 # /etc/hosts.deny sshd: ALL

原理是TCP Wrapper，在连接到达sshd之前做一层封装式的判断。但现在很多系统默认编译时不再启用libwrap，改完半天不生效是常态。所以我更推荐直接在sshd_config里使用Match Address指令，它由sshd自己解析，不依赖外部库，跨发行版通用性更好。

# /etc/ssh/sshd_config # 白名单来源走密码登录 Match Address 203.0.113.5,192.168.1.0/24 PasswordAuthentication yes # 其余来源禁用密码登录，仅允许密钥登录 Match all PasswordAuthentication no

注意这个逻辑：先在白名单范围里允许密码认证，然后在Match all里关闭密码认证。效果就是白名单之外的用户，即使端口没被防火墙DROP，也无法用密码登录，只能使用密钥。如果你连密钥都不想放行，可以在防火墙层把非白名单IP对22端口的流量直接DROP。

如果要更彻底，只让白名单来源能创建SSH连接，可以在iptables或firewalld里设置。顺便提醒一句，你的办公网出口IP如果是动态分配的，配置SSH白名单要慎重，否则哪天运营商重新拨号，你的IP变了，人就进不去了。

5. 白名单配置常见的坑与排查方法

5.1 规则顺序和默认策略：为什么“配了但没生效”

白名单"配了但没生效"是我见过最多的排障问题，而九成以上都出在规则顺序或默认策略上。

拿iptables举例子，INPUT链的匹配是按顺序从上往下执行的。如果你先执行了iptables -A INPUT -j DROP这类拒绝所有数据的规则，再执行iptables -A INPUT -s 白名单IP -j ACCEPT，那么根据匹配顺序，新到访的数据包先撞上DROP规则，直接被丢弃，根本轮不到后面的ACCEPT规则。所以"白名单规则在前、拒绝规则在后"是不变的原则。

另一个问题是INPUT链的默认策略。用iptables -P INPUT DROP把默认策略改成丢弃后，整个INPUT链上没有任何匹配的数据包都会被拦住。此时必须保证白名单规则已经添加成功且顺序正确。有个排查小技巧：添加规则后用iptables -L INPUT -n --line-numbers查看规则行号，再对照一下执行顺序，基本能立刻定位问题。

firewalld也是一样的道理，rich rule之间也有优先级。如果你设置了多个rich rule，一个允许一个拒绝，结果取决于匹配顺序。所以规则配置完成后最好做正反两个方向的测试：白名单IP能连通，非白名单IP被拒绝，才算真正完成。

5.2 动态IP与安全组冲突：把自己锁在门外的教训

白名单配好后，最大的风险不是配置本身，而是来源IP变了。企业办公网的出口IP大多是动态分配的，也许今天还是203.0.113.5，明天运营商重新拨号就变成了203.0.113.188。如果这些IP被写死在白名单里，你第二天上班就会发现SSH怎么也连不上，那种感觉我太熟悉了。

应对办法有几条路径：一是遇到固定IP需求，和网络部门确认运营商是否能提供静态IP；二是通过DDNS动态域名配合运维脚本，定期更新白名单里的IP；三是在云上使用堡垒机，让所有运维人员先登录堡垒机，再把堡垒机IP加入白名单。第三种方案在正规企业里用得最多，既解决了IP变化问题，又方便审计操作记录，算是一举两得。

还有一个经常被忽视的点：云服务器的安全组和系统内部防火墙是两层不同机制。安全组是虚拟机外部的网络策略，系统防火墙是机器内部的策略。有些朋友在系统里加好了白名单，却发现外部还是能访问，一查才发现云控制台上的安全组放行了所有来源的端口，等于系统防火墙外面已经失守了。反过来，安全组限制太严格，系统防火墙再怎么配，请求也进不来。排查白名单问题时，一定要把这两层都检查一遍。

5.3 多层代理下的真实IP：白名单能不能被绕过

"用户是用多层代理，ip都能捕获到吗"——这几乎是每次聊白名单都要被问到的问题。直接回答：从TCP/IP协议本身的逻辑讲，无论用户套了多少层代理，服务器在建立TCP连接时一定知道直接和它握手的那一跳的IP，因为这是网络层的硬事实，不是应用层能隐藏的。但问题在于，应用层程序拿到的一般是HTTP头部里的信息，如果只依赖某些头部做判断，就可能被伪造。

最典型的例子是只信任X-Forwarded-For头。这个头是HTTP协议里的一个约定，用于传递原始客户端IP，设计初衷是好的：CDN、反向代理在转发请求时，把来源IP追加到头里。但它有一个天生缺陷，如果Nginx没有正确配置real_ip_module去覆盖remote_addr，应用直接读取X-Forwarded-For来做权限判断，攻击者完全可以手动构造一个请求头，把XFF写成白名单里的IP，轻而易举绕过白名单。

所以在我们前面提到的Nginx配置里，set_real_ip_from加real_ip_header这套组合，本质就是在告诉Nginx：只有这些可信代理传过来的XFF才值得信任。可信代理之外，任何客户端自带的XFF都不应该作为判断依据。这一点非常重要，不然白名单只是筛了个寂寞。

5.4 排查工具速查：从ss到tcpdump

最后整理一份排查白名单问题的实用命令表，都是我日常高频使用的：

排查流程我一般是这么走的：先确认服务在正常监听，ss -lntp看一下端口有没有LISTEN；再看系统防火墙规则，iptables或firewalld当前允许哪些来源；然后从外部机器用nc或者curl测连通性，判断是否真的被拦截；如果还查不出来，抓包看数据包到没到网卡、是被丢弃还是被拒绝。按这个顺序，大部分问题十分钟内就能定位出来。

最后分享一个我自己的习惯，也算是踩过几次坑之后养成的肌肉记忆：每次改白名单规则前，先把当前规则全文备份一份到文件里，同时确认云平台控制台或者带外管理通道是通的，再动手改。改完之后，一定要用白名单内和白名单外两个视角各测一遍，确认放行和拦截都符合预期，最后再保存规则。这套流程看起来繁琐，但真正遇到"把自己锁在门外"的那一刻，你会感激当初多花的那两分钟。