1. 项目概述:为什么需要精细化IP访问控制?
在服务器运维和网络安全管理中,我们经常遇到这样的场景:一台部署了关键服务(比如数据库、管理后台、API接口)的服务器,我们并不希望它对全世界开放。全开放意味着暴露在扫描和攻击之下,安全风险陡增。最直接、最有效的初级防御策略之一,就是 基于源IP地址的访问控制 ——只允许受信任的、已知的IP地址或IP段进行连接,其他一律拒绝。
firewalld 作为 CentOS 7/8、RHEL 7/8 及 Fedora 等主流 Linux 发行版上默认的动态防火墙管理器,它相比传统的 iptables 命令,提供了更为友好和灵活的配置方式,特别是通过 firewall-cmd 工具和富规则(rich rules)功能,实现复杂的过滤策略变得清晰许多。这次,我们就来深入聊聊,如何用 firewalld 构建一个“白名单”式的访问控制体系,确保服务只对你指定的IP“开门迎客”。
这个操作的核心价值在于 最小化攻击面 。想象一下你的服务器是一座城堡,全开放就像城门大开;而配置IP白名单,则是只给持有特定令牌(信任的IP)的信使打开一道小门,其他人连护城河都过不了。这对于保护数据库、SSH服务、Web管理界面等尤为关键。
2. firewalld基础概念与架构解析
在动手配置之前,有必要理解 firewalld 的几个核心工作概念,这能让你明白每一步操作背后的逻辑,而不是死记命令。
2.1 区域(Zone):安全策略的容器
firewalld 引入了“区域”的概念,这是一个非常巧妙的设计。你可以把区域理解为针对不同信任级别的网络环境预设的一套规则模板。每个网络接口(如 eth0, ens33)都会被分配到一个区域中,从而继承该区域的所有规则。
常见的默认区域有:
- public(默认) : 用于公共区域,不相信网络内的其他计算机。这是新接口的默认区域,策略最为严格。
- internal : 用于内部网络,信任网络内的其他计算机。
- trusted : 接受所有的网络连接,信任度最高。
- drop : 丢弃所有传入的数据包,且不回复任何信息(“闷声”丢弃)。
- block : 拒绝所有传入的数据包,但会回复一个拒绝(reject)消息。
我们的配置通常围绕 public 区域进行,因为服务器对外提供服务时,默认就处于这个最不信任的区域。
2.2 运行时与永久配置
这是 firewalld 配置中一个至关重要的区别,也是新手容易踩坑的地方。
- 运行时配置(Runtime) : 立即生效,但重启
firewalld服务或服务器后,配置会丢失。通过--runtime-to-permanent选项或直接使用--permanent标志可以避免这个问题,但测试时先用运行时配置更安全。 - 永久配置(Permanent) : 写入配置文件(
/etc/firewalld/),不会立即生效,需要重载firewalld或重启服务后才会应用。生产环境变更务必使用永久配置。
一个标准的操作流程是:先添加运行时规则测试效果,确认无误后,再将其转为永久配置。
# 添加运行时规则
sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.1.100" accept'
# 测试连通性...
# 确认无误后,将运行时规则转为永久
sudo firewall-cmd --runtime-to-permanent
# 或者,直接添加永久规则(需重载或重启服务生效)
sudo firewall-cmd --zone=public --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.100" accept'
sudo firewall-cmd --reload
2.3 富规则(Rich Rules):实现复杂策略的利器
基础的 firewalld 命令可以开放端口、服务,但无法精细到“允许某个IP访问某个端口”。这时就需要 富规则 。富规则提供了类似 iptables 命令的细粒度控制能力,可以指定协议、端口、源/目标地址、动作(accept, reject, drop)等。
我们本次实现IP白名单,核心就是利用富规则。其基本语法结构如下:
rule [family="ipv4|ipv6"]
[source|destination address="address[/mask]"|mac="mac-address"|ipset="ipset-name"]
[service name="service-name"]
[port port="number-or-range" protocol="tcp|udp"]
[protocol value="protocol-name"]
[log [prefix="prefixtext"] [level="emerg|alert|crit|error|warning|notice|in
1115




被折叠的 条评论
为什么被折叠?



