如何配置CentOS防火墙？，CentOS防火墙配置教程

CentOS 防火墙配置，首选 Firewalld，兼顾安全与运维效率

在 CentOS 生产环境中，防火墙是保障服务器安全的第一道闸门。无论你是刚上线的云服务器，还是正在迁移业务的老系统，正确配置防火墙都能极大降低被入侵的风险。 基于长期运维实践，我们给出的核心结论是：CentOS 7 及以上版本应默认使用 Firewalld 作为防火墙管理工具，它支持动态规则、区域管理和 Rich Rule，比传统 iptables 更灵活；CentOS 6 或特殊场景才考虑 iptables。 配置防火墙时务必遵循“最小开放原则”，只放行业务必需端口,并利用云平台安全组与系统防火墙形成双重防护。

Firewalld：现代 CentOS 的默认选择

Firewalld 是 CentOS 7 起内置的动态防火墙管理工具，它通过 DBus 接口与内核 netfilter 交互，支持运行时配置与永久配置分离。这意味着你修改规则时无需重启服务，也不会中断现有连接,对生产环境尤为友好。

基础操作命令

• 启动并设置开机自启：

  systemctl start firewalld
  systemctl enable firewalld

• 查看状态与活动规则：

  firewall-cmd --state
  firewall-cmd --list-all

核心概念：区域（Zone）

Firewalld 使用“区域”来管理信任级别。默认区域为 public，适合大多数云服务器场景，你可以为不同网络接口分配不同区域,从而实现精细控制。

查看当前默认区域：

firewall-cmd --get-default-zone

常见区域说明：

• public：仅允许少量外部访问,适合公网入口。
• internal：信任内部网络,适合内网互通。
• dmz：允许部分端口对公网开放,常用于隔离区。

端口与服务的放行

开放端口（以 8080 为例）：

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

放行服务（如 http）：

firewall-cmd --permanent --add-service=http
firewall-cmd --reload

注意：必须添加 --permanent 参数才能永久生效，否则重启后规则丢失。 修改后执行 firewall-cmd --reload 加载新规则。

移除规则与自我保护

• 移除已开放的端口：

  firewall-cmd --permanent --remove-port=8080/tcp
  firewall-cmd --reload

• 查看端口是否被放行：

  firewall-cmd --query-port=8080/tcp

生产环境建议：先用 --add-port 临时测试业务，确认无问题后再改用 --permanent 规则,避免误放行导致风险。

Rich Rule：复杂场景下的精准控制

当简单的端口或服务规则无法满足需求时，比如需要限制来源 IP、控制访问速率，Rich Rule 能提供更强大的表达能力。

典型场景：只允许特定 IP 访问 SSH（22 端口）

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10" port port="22" protocol="tcp" accept'
firewall-cmd --reload

禁止某个 IP 段访问 80 端口：

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port port="80" protocol="tcp" reject'
firewall-cmd --reload

Rich Rule 的优先级高于普通端口规则，利用它可实现“默认拒绝，白名单放行”的高安全策略,有效对抗扫描和暴力破解。

iptables 的适用场景与迁移建议

尽管 Firewalld 是主流，但 CentOS 6 系统或容器内环境仍会用到 iptables，iptables 的规则链直接、性能开销极低,适合对包处理有极致要求的场景。

一个典型的 iptables 规则示例：

iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -P INPUT DROP

注意：iptables 规则顺序敏感，且默认策略改为 DROP 前务必确认放行了 SSH（22 端口），避免锁死服务器，我们建议你 尽量将旧 iptables 规则迁移到 Firewalld

，因为 Firewalld 自带持久化、支持动态加载,运维维护成本更低。

云安全组与系统防火墙的协同策略

绝大多数云平台（如酷番云）都提供安全组功能，它在虚拟机外部做流量过滤，而系统防火墙（Firewalld/iptables）在虚拟机内部生效。 两者协同,才能构建纵深防御。

经验案例（来自酷番云运维团队）：

某电商客户在酷番云上运行单台 CentOS 7.9 服务器，之前只在云安全组放行了 80、443、22 端口，但系统 firewalld 处于停用状态，一次安全巡检发现服务器被植入了挖矿程序，原因在于应用进程反弹了一个高端口连接,我们给出的解决方案是：

1. 在酷番云控制台安全组中，保留 80、443、22 等必需端口，移除其他所有放行规则。
2. 在系统内启用 firewalld，并只放行以下端口：

   firewall-cmd --permanent --add-port=80/tcp
   firewall-cmd --permanent --add-port=443/tcp
   firewall-cmd --permanent --add-service=ssh
   firewall-cmd --reload

3. 额外使用 Rich Rule 限制 SSH 仅允许办公网段 IP 访问。
4. 开启 SSH 登录失败次数限制，并配置 Fail2Ban 联动。

结果：两周内暴力破解尝试次数降低了 99% 以上，挖矿进程未再出现。 这个案例验证了“云安全组 + 系统防火墙”双层的有效性。核心原则是：安全组放行外部流量，firewalld 管控本机进程的出入方向，两者规则越严格，安全水位越高。

常见故障排查与最佳实践

端口明明放行，外部却无法访问

• 检查 firewalld 是否运行：systemctl status firewalld
• 检查安全组是否放行对应端口（酷番云控制台-安全组）
• 检查进程监听地址是否为 0.0.0：ss -lntp
• 检查 SELinux 是否拦截：getenforce，若为 Enforcing，可临时 setenforce 0 测试

修改规则后业务中断

• 确认是否使用了 --reload 而非 --complete-reload，前者保持连接不断
• 确认是否有新建的 DROP 规则命中业务流量



• 建议每次修改前备份现有规则：

  firewall-cmd --list-all > /backup/firewalld_$(date +%F).txt

自动化配置建议

使用配置管理工具（如 Ansible）批量下发防火墙规则，避免人工逐台操作造成漂移，例如将所需的端口和服务定义在变量文件中，然后统一执行 firewall-cmd 命令,确保所有服务器规则一致。

相关问答

问 1：CentOS 7 中如何查看当前所有防火墙规则，并确认某个特定端口是否被放行？

答：使用 firewall-cmd --list-all 查看默认区域的所有规则，输出中会包含 ports、services、rich rules 等字段，若要精确查询某个端口，执行 firewall-cmd --query-port=8080/tcp 会返回 yes 或 no，注意查询的是运行时配置，如需查询永久配置，在使用查询命令时省略 --permanent 即可（因为默认查询运行时），若要确认永久配置则需加上 --permanent。

问 2：如果我把 SSH 端口改成了 2222，firewalld 中应该如何正确放行并保证重连不失败？

答：首先临时放行新端口 firewall-cmd --add-port=2222/tcp（不添加 permanent），然后修改 SSH 配置文件 /etc/ssh/sshd_config 中的 Port 为 2222，重启 sshd 服务，此时保持当前 SSH 连接不中断，新开一个连接测试 2222 端口是否成功，确认可用后，再执行 firewall-cmd --permanent --add-port=2222/tcp 并移除旧端口 22 的放行规则，firewall-cmd --reload。千万记住：在未确认新端口可连接前，不要移除 22 端口规则，否则一旦 SSH 断开你将无法远程管理服务器。

防火墙配置不是“一劳永逸”的工作，建议每周检查一次规则清单，梳理业务变更引发的端口调整，如果你在酷番云上部署 CentOS 服务器，欢迎使用我们的安全组和轻量防火墙可视化工具，帮你更高效地管理访问策略，你在配置防火墙时遇到过哪些“坑”？欢迎在评论区留言交流,我们共同探讨解决方案。