Linux防火墙规则如何写？_Linuxiptables和firewalld配置实例

推荐使用firewalld的原因有三：1.firewalld支持动态修改规则，无需中断现有连接；2.它通过区域（zones）管理不同网络接口和信任级别，简化规则逻辑；3.自动处理规则持久化，减少人为操作失误。相比iptables线性操作易出错且每次修改需刷新整个规则集，firewalld更适合现代 linux 环境，尤其适用于服务器和桌面系统。 在Linux系统中，编写防火墙规则核心在于明确哪些网络流量被允许，哪些被拒绝。这通常涉及到两种主流工具： 和 ，它们各有侧重，但目标一致：构建一道网络安全屏障。理解其基本逻辑，即“默认拒绝，明确允许”，是写好规则的关键。 解决方案 编写Linux防火墙规则，无论是基于 的链式结构，还是 的区域（zone）概念，其本质都是定义网络包的处理策略。 使用编写规则 是一个低级别的工具，直接与Linux内核的netfilter框架交互。它通过表（tables）、链（chains）和规则（rules）来管理流量。 设置默认策略（Deny All原则）： 这是最重要的一步，确保未明确允许的流量都被拒绝。 注意： 在实际操作中，先设置默认DROP策略可能会导致远程连接中断，务必先确保允许SSH等管理端口，或在本地控制台操作。 允许特定服务/端口： 允许SSH（端口22）传入： 允许HTTP（端口80）和HTTPS（端口443）传入： 允许Loopback接口（本机通信）： 阻止特定IP地址访问： 保存规则： 的规则默认是临时的，重启后会丢失。需要使用特定工具保存。 Debian/Ubuntu: 或 CentOS/RHEL: 或 使用编写规则 是一个动态管理防火墙的守护进程，它使用区域（zones）来管理网络接口和流量，提供了更抽象、更易用的接口。 查看当前状态和区域： 允许服务或端口： 推荐使用服务名而非端口号，因为它包含了协议和端口的定义。 允许SSH服务（在public区域）： 允许HTTP和HTTPS服务： 允许特定端口（例如TCP 8080）： 阻止特定IP或IP范围： 也可以通过Rich Rules或Source-based zones来做更复杂的控制。 CentOS Linux 7.9.2009 CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离线兼容性测试。 下载 使用Rich Rule阻止特定IP： 移除规则： 将 替换为 。 为什么在现代Linux系统中更推荐使用firewalld？ 从我个人的经验来看， 在许多方面确实比 更适合现代Linux环境，尤其是在服务器或桌面系统上。 虽然强大且灵活，但它的操作是线性的，规则的顺序至关重要，这在规则数量庞大或需要频繁修改时，极易出错。每次修改都可能需要刷新整个规则集，这对于有状态连接的服务来说，风险不小。 则引入了“区域（zones）”的概念，这简直是管理多个网络接口和不同信任级别网络环境的福音。你可以将不同的接口分配到不同的区域，例如 （公共网络，限制严格）、 （内部网络，信任度高）或 （完全信任）。这种基于区域的策略，使得规则管理变得逻辑清晰，你不需要为每个接口重复编写相同的规则。更重要的是， 支持运行时动态修改规则，而无需中断现有连接，它会自动处理规则的持久化，这对于生产环境的稳定性至关重要。我曾遇到过因为 规则刷新导致服务中断的“惊魂一刻”，而 的动态特性就大大降低了这种风险。当然，对于一些极其复杂的、需要极致性能优化的场景，或者在一些嵌入式设备上， 的直接控制能力可能依然是首选。但对于绝大多数日常的服务器管理和应用部署， 的抽象层和易用性无疑是更明智的选择。 编写防火墙规则时，如何避免常见的配置陷阱？ 编写防火墙规则，尤其是初次接触时，很容易踩到一些坑。最常见的，也是最让人抓狂的，就是 把自己锁在服务器外面 。想象一下，你远程SSH到一台服务器，敲下 ，然后发现自己再也连不上了，那种心跳加速的感觉，只有经历过的人才懂。所以， 永远先允许SSH（或你正在使用的管理端口） ，并且 在应用任何默认拒绝策略之前，确保你的允许规则已经生效 。 另一个常见的陷阱是 规则顺序的误解 。 是按顺序处理规则的，一旦匹配到一条规则并执行了动作（如ACCEPT或DROP），后续的规则就不会再被检查。这意味着，如果你先写了一条 所有流量的规则，那么后面即使有 特定端口的规则，也永远不会被执行。所以， 最具体的允许规则应该放在更通用的拒绝规则之前 。 对于 ，虽然它的区域概念简化了管理，但 混淆和非永久规则 也是个问题。如果你不加 ，规则只在当前会话中生效，重启后就会消失。这在测试时很方便，但如果忘记加上，重启后服务可能就无法访问了。我通常会先不加 进行测试，确认无误后再加上并 。 最后， 过度依赖默认配置 也是一个隐患。虽然 的默认区域（如 ）通常比较安全，但对于生产环境，我们应该审视每个开放的端口和服务，确保它们确实是业务所需的，并且尽可能地限制源IP地址。我倾向于采用“白名单”策略，即只允许已知的、必要的流量通过，而不是修修补补地阻止恶意流量。 如何有效测试和验证防火墙规则的有效性？ 测试和验证防火墙规则是部署过程中不可或缺的一步，这能帮你避免上线后的“惊喜”。我通常会采用以下几个策略： 首先， 分步测试 。不要一次性应用所有规则，尤其是当规则集比较复杂的时候。可以先应用最核心的默认拒绝策略和必要的服务开放规则，然后逐步添加其他规则，每添加一部分就进行测试。 其次， 使用不同的客户端和网络环境进行测试 。例如，如果你的服务器对外提供Web服务，尝试从你的办公网络、家庭网络甚至手机 热点 去访问，模拟不同的外部访问路径。如果服务有内部和外部访问之分，确保内部客户端可以访问，外部客户端受限。 第三， 利用网络诊断工具 。 ：测试基本的网络连通性。如果连 都不通，那肯定有问题。 或(netcat) ：这是测试特定端口是否开放的利器。例如， 可以测试SSH端口是否开放。如果连接成功，说明防火墙允许了；如果连接超时或拒绝，则可能被防火墙阻止。 ：一个强大的网络扫描工具，可以用来发现服务器开放的端口。从外部网络对你的服务器进行 扫描，可以直观地看到哪些端口是开放的，这与你期望的规则是否一致。例如， 可以进行TCP连接扫描。 或 ：在服务器本地查看哪些服务正在监听哪些端口，以及当前的网络连接状态。这可以帮助你确认服务本身是否正常启动，以及防火墙规则是否正确地允许了这些服务的入站连接。 第四， 检查防火墙日志 。许多防火墙系统可以配置日志记录被拒绝或被接受的连接。通过查看这些日志，你可以发现哪些流量被阻止了，以及阻止的原因，这对于调试非常有用。 最后， 做好回滚计划 。在生产环境中，任何防火墙规则的修改都应该有快速回滚的方案。这意味着在应用新规则之前，你可能需要备份旧规则，或者知道如何快速地清空所有规则（例如 ），以便在出现问题时能迅速恢复服务。我个人习惯在修改前，先准备好一个“紧急放行”的脚本，万一锁死了，能通过带外管理（如KVM、IPMI）登录，运行脚本解除锁定。