Linux防火墙配置：iptables与firewalld实战教程

还在为Linux防火墙配置头疼？本文为你带来一套全面的配置教程，深入解析iptables与firewalld两种主流工具的应用实例，助你轻松构建坚固的网络安全屏障。推荐使用firewalld的原因在于其动态规则修改、区域管理和自动持久化特性，相较于iptables线性操作的易错性，firewalld更适合现代Linux环境。文章详细阐述了如何利用iptables设置默认策略、允许特定服务端口，以及如何使用firewalld进行区域配置、服务添加和IP阻止。此外，更分享了避免配置陷阱、有效测试规则的实用技巧，让你在Linux防火墙配置的道路上少走弯路，保障服务器和桌面系统的安全稳定运行。

推荐使用firewalld的原因有三：1.firewalld支持动态修改规则，无需中断现有连接；2.它通过区域（zones）管理不同网络接口和信任级别，简化规则逻辑；3.自动处理规则持久化，减少人为操作失误。相比iptables线性操作易出错且每次修改需刷新整个规则集，firewalld更适合现代Linux环境，尤其适用于服务器和桌面系统。

在Linux系统中，编写防火墙规则核心在于明确哪些网络流量被允许，哪些被拒绝。这通常涉及到两种主流工具：iptables和firewalld，它们各有侧重，但目标一致：构建一道网络安全屏障。理解其基本逻辑，即“默认拒绝，明确允许”，是写好规则的关键。

解决方案

编写Linux防火墙规则，无论是基于iptables的链式结构，还是firewalld的区域（zone）概念，其本质都是定义网络包的处理策略。

使用 iptables 编写规则

iptables 是一个低级别的工具，直接与Linux内核的netfilter框架交互。它通过表（tables）、链（chains）和规则（rules）来管理流量。

1. 设置默认策略（Deny All原则）： 这是最重要的一步，确保未明确允许的流量都被拒绝。

   

   # 允许已建立的连接和相关流量
   iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
   iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
   # 默认拒绝所有传入和转发流量
   iptables -P INPUT DROP
   iptables -P FORWARD DROP
   # 默认允许所有传出流量（可根据需求修改）
   iptables -P OUTPUT ACCEPT

   注意： 在实际操作中，先设置默认DROP策略可能会导致远程连接中断，务必先确保允许SSH等管理端口，或在本地控制台操作。

2. 允许特定服务/端口：

   • 允许SSH（端口22）传入：

     iptables -A INPUT -p tcp --dport 22 -j ACCEPT

   • 允许HTTP（端口80）和HTTPS（端口443）传入：

     iptables -A INPUT -p tcp --dport 80 -j ACCEPT
     iptables -A INPUT -p tcp --dport 443 -j ACCEPT

   • 允许Loopback接口（本机通信）：

     iptables -A INPUT -i lo -j ACCEPT
     iptables -A OUTPUT -o lo -j ACCEPT

   • 阻止特定IP地址访问：

     iptables -A INPUT -s 192.168.1.100 -j DROP

3. 保存规则： iptables 的规则默认是临时的，重启后会丢失。需要使用特定工具保存。

   • Debian/Ubuntu: sudo netfilter-persistent save 或 sudo iptables-save > /etc/iptables/rules.v4
   • CentOS/RHEL: sudo service iptables save 或 sudo iptables-save > /etc/sysconfig/iptables

使用 firewalld 编写规则

firewalld 是一个动态管理防火墙的守护进程，它使用区域（zones）来管理网络接口和流量，提供了更抽象、更易用的接口。

1. 查看当前状态和区域：

   firewall-cmd --state
   firewall-cmd --get-active-zones
   firewall-cmd --zone=public --list-all

2. 允许服务或端口： firewalld 推荐使用服务名而非端口号，因为它包含了协议和端口的定义。

   • 允许SSH服务（在public区域）：

     firewall-cmd --zone=public --add-service=ssh --permanent
     firewall-cmd --reload

   • 允许HTTP和HTTPS服务：

     firewall-cmd --zone=public --add-service=http --permanent
     firewall-cmd --zone=public --add-service=https --permanent
     firewall-cmd --reload

   • 允许特定端口（例如TCP 8080）：

     firewall-cmd --zone=public --add-port=8080/tcp --permanent
     firewall-cmd --reload

3. 阻止特定IP或IP范围：firewalld 也可以通过Rich Rules或Source-based zones来做更复杂的控制。

   • 使用Rich Rule阻止特定IP：

     firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.1.100" reject' --permanent
     firewall-cmd --reload

4. 移除规则： 将 add- 替换为 remove-。

   firewall-cmd --zone=public --remove-service=ssh --permanent
   firewall-cmd --reload

为什么在现代Linux系统中更推荐使用firewalld？

从我个人的经验来看，firewalld在许多方面确实比iptables更适合现代Linux环境，尤其是在服务器或桌面系统上。iptables虽然强大且灵活，但它的操作是线性的，规则的顺序至关重要，这在规则数量庞大或需要频繁修改时，极易出错。每次修改都可能需要刷新整个规则集，这对于有状态连接的服务来说，风险不小。

firewalld则引入了“区域（zones）”的概念，这简直是管理多个网络接口和不同信任级别网络环境的福音。你可以将不同的接口分配到不同的区域，例如public（公共网络，限制严格）、internal（内部网络，信任度高）或trusted（完全信任）。这种基于区域的策略，使得规则管理变得逻辑清晰，你不需要为每个接口重复编写相同的规则。更重要的是，firewalld支持运行时动态修改规则，而无需中断现有连接，它会自动处理规则的持久化，这对于生产环境的稳定性至关重要。我曾遇到过因为iptables规则刷新导致服务中断的“惊魂一刻”，而firewalld的动态特性就大大降低了这种风险。当然，对于一些极其复杂的、需要极致性能优化的场景，或者在一些嵌入式设备上，iptables的直接控制能力可能依然是首选。但对于绝大多数日常的服务器管理和应用部署，firewalld的抽象层和易用性无疑是更明智的选择。

编写防火墙规则时，如何避免常见的配置陷阱？

编写防火墙规则，尤其是初次接触时，很容易踩到一些坑。最常见的，也是最让人抓狂的，就是把自己锁在服务器外面。想象一下，你远程SSH到一台服务器，敲下iptables -P INPUT DROP，然后发现自己再也连不上了，那种心跳加速的感觉，只有经历过的人才懂。所以，永远先允许SSH（或你正在使用的管理端口），并且在应用任何默认拒绝策略之前，确保你的允许规则已经生效。

另一个常见的陷阱是规则顺序的误解。iptables是按顺序处理规则的，一旦匹配到一条规则并执行了动作（如ACCEPT或DROP），后续的规则就不会再被检查。这意味着，如果你先写了一条DROP所有流量的规则，那么后面即使有ACCEPT特定端口的规则，也永远不会被执行。所以，最具体的允许规则应该放在更通用的拒绝规则之前。

对于firewalld，虽然它的区域概念简化了管理，但混淆--permanent和非永久规则也是个问题。如果你不加--permanent，规则只在当前会话中生效，重启后就会消失。这在测试时很方便，但如果忘记加上，重启后服务可能就无法访问了。我通常会先不加--permanent进行测试，确认无误后再加上并--reload。

最后，过度依赖默认配置也是一个隐患。虽然firewalld的默认区域（如public）通常比较安全，但对于生产环境，我们应该审视每个开放的端口和服务，确保它们确实是业务所需的，并且尽可能地限制源IP地址。我倾向于采用“白名单”策略，即只允许已知的、必要的流量通过，而不是修修补补地阻止恶意流量。

如何有效测试和验证防火墙规则的有效性？

测试和验证防火墙规则是部署过程中不可或缺的一步，这能帮你避免上线后的“惊喜”。我通常会采用以下几个策略：

首先，分步测试。不要一次性应用所有规则，尤其是当规则集比较复杂的时候。可以先应用最核心的默认拒绝策略和必要的服务开放规则，然后逐步添加其他规则，每添加一部分就进行测试。

其次，使用不同的客户端和网络环境进行测试。例如，如果你的服务器对外提供Web服务，尝试从你的办公网络、家庭网络甚至手机热点去访问，模拟不同的外部访问路径。如果服务有内部和外部访问之分，确保内部客户端可以访问，外部客户端受限。

第三，利用网络诊断工具。

• ping：测试基本的网络连通性。如果连ping都不通，那肯定有问题。
• telnet或nc (netcat)：这是测试特定端口是否开放的利器。例如，telnet your_server_ip 22可以测试SSH端口是否开放。如果连接成功，说明防火墙允许了；如果连接超时或拒绝，则可能被防火墙阻止。
• nmap：一个强大的网络扫描工具，可以用来发现服务器开放的端口。从外部网络对你的服务器进行nmap扫描，可以直观地看到哪些端口是开放的，这与你期望的规则是否一致。例如，nmap -sT your_server_ip可以进行TCP连接扫描。
• ss或netstat：在服务器本地查看哪些服务正在监听哪些端口，以及当前的网络连接状态。这可以帮助你确认服务本身是否正常启动，以及防火墙规则是否正确地允许了这些服务的入站连接。

第四，检查防火墙日志。许多防火墙系统可以配置日志记录被拒绝或被接受的连接。通过查看这些日志，你可以发现哪些流量被阻止了，以及阻止的原因，这对于调试非常有用。

最后，做好回滚计划。在生产环境中，任何防火墙规则的修改都应该有快速回滚的方案。这意味着在应用新规则之前，你可能需要备份旧规则，或者知道如何快速地清空所有规则（例如iptables -F），以便在出现问题时能迅速恢复服务。我个人习惯在修改前，先准备好一个“紧急放行”的脚本，万一锁死了，能通过带外管理（如KVM、IPMI）登录，运行脚本解除锁定。

理论要掌握，实操不能落！以上关于《Linux防火墙配置：iptables与firewalld实战教程》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！