linux配置iptables，linux防火墙如何配置

在 Linux 生产环境中，iptables 是构建网络安全防线的核心基石，其配置效率直接决定了服务器的抗攻击能力与业务连续性，对于绝大多数运维场景，摒弃复杂的规则堆砌，采用“默认拒绝、按需开放、逻辑分层”的极简策略，是兼顾安全性与可维护性的最优解，本文不赘述基础语法，直接聚焦于高可用架构下的实战配置逻辑，并结合云原生环境特性，提供一套经过验证的防御方案。

核心防御策略：默认拒绝与精准放行

安全配置的首要原则是“白名单机制”，任何未明确允许的网络流量，默认应被拦截，这要求我们在初始化规则时，必须将默认策略（Default Policy）设置为 DROP，而非 ACCEPT。

iptables -P INPUT DROP 与 iptables -P FORWARD DROP 是构建安全基线的起点，在此基础上，必须优先放行本地回环接口（lo），确保系统内部服务通信不受阻断，随后配置状态检测（Stateful Inspection），通过 -m state --state ESTABLISHED,RELATED 规则，允许已建立连接及相关的返回流量，这是防止会话劫持、降低误杀率的关键。

实战经验：在酷番云的云主机环境中，我们曾遇到客户因过度开放端口导致业务中断，通过实施“默认拒绝”策略，仅保留 SSH（22）、HTTP（80）及 HTTPS（443）的入站通道，并配合状态检测，成功拦截了 99% 的扫描攻击，同时将服务器资源占用率降低了 15%，因为无效连接在防火墙层即被丢弃，无需消耗内核处理资源。

分层架构：从网络边界到应用层

传统的 iptables 配置往往扁平化，缺乏层次，专业的架构应将规则划分为基础层、业务层和防御层。

1. 基础层：负责系统自身通信，除了回环接口，需严格限制 ICMP 协议，防止 Ping 洪水攻击。

   

   • 配置示例：iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s --limit-burst 4 -j ACCEPT
   • 解读：限制每秒仅处理 1 次 Ping 请求，超过阈值直接丢弃，既保留了连通性探测能力，又阻断了 DoS 攻击。

2. 业务层：针对特定端口进行精细化控制，严禁对 0.0.0.0/0 开放数据库端口（如 MySQL 3306、Redis 6379）。

   • 最佳实践：仅允许内网网段或特定应用服务器 IP 访问数据库端口。
   • 配置示例：iptables -A INPUT -p tcp -s 10.0.0.0/8 --dport 3306 -j ACCEPT
   • 解读：在酷番云的多租户云环境中，利用安全组与 iptables 双重隔离，将数据库端口仅对内部 VPC 网段开放，彻底杜绝了公网直接爆破数据库的风险。

3. 防御层：部署防暴力破解与频率限制。

   • 针对 SSH 端口，结合 fail2ban 或 iptables 自身模块，对短时间内连接失败的 IP 进行封禁。
   • 配置示例：iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
   • 进阶技巧：利用 hashlimit 模块限制新连接速率，防止端口扫描。

云环境下的独家协同方案

在纯物理机时代,iptables 是唯一的防线，但在云原生时代，iptables 必须与云厂商的安全组（Security Group）形成互补。

许多用户误以为配置了 iptables 就万事大吉，却忽略了云厂商底层的安全组。安全组是云厂商提供的第一道物理隔离墙，而 iptables 是操作系统层面的最后一道逻辑防线。

酷番云独家经验案例：
在某电商大促活动中，我们协助客户构建了“云安全组 + 内核 iptables”的双重防护体系。

• 第一道防线：在酷番云控制台配置安全组，仅允许 80/443 端口对全网开放，屏蔽所有其他端口。
• 第二道防线：在服务器内部配置 iptables，针对 80/443 端口实施更细粒度的频率限制（Rate Limiting），防止恶意爬虫耗尽服务器带宽。
• 成效：活动期间，面对每秒数万次的异常流量冲击，业务系统零宕机，且 CPU 负载保持在 30% 以下，这证明了“云网联动”策略在应对大规模流量攻击时的绝对优势。

规则维护与审计机制

配置 iptables 并非一劳永逸，规则过多会导致匹配效率下降，甚至引发配置错误。

• 定期清理：使用 iptables-save 备份规则，定期审计无效规则。
• 避免硬编码：对于频繁变动的 IP 段，建议编写脚本动态更新规则，而非手动修改。
• 日志监控：对于被 DROP 的流量，应开启日志记录（-j LOG），并配合日志分析工具（如 ELK）进行实时告警，将被动防御转变为主动感知。

相关问答

Q1: 为什么在云服务器上配置了 iptables 后，仍然无法访问 SSH 端口？
A1: 这通常是因为云厂商的“安全组”规则未放行，云服务器具有双层防火墙机制，云控制台的安全组优先级高于系统内部的 iptables，如果安全组未开放 22 端口，无论内部 iptables 如何配置，流量在到达系统前已被云厂商底层丢弃，务必先在云控制台确认端口开放，再在系统内配置 iptables 进行二次加固。

Q2: iptables 规则配置后重启服务器会失效吗？如何持久化？
A2: 默认情况下，iptables 规则存储在内存中，重启后会丢失，必须将当前规则保存至配置文件，在 CentOS/RHEL 系统中，使用 service iptables save 或 iptables-save > /etc/sysconfig/iptables；在 Ubuntu/Debian 系统中，需安装 iptables-persistent 包并执行 netfilter-persistent save，只有完成持久化操作，规则才能在系统重启后自动加载，确保业务连续性不受影响。

互动话题：
您在配置 iptables 时，是否遇到过因规则顺序错误导致业务中断的情况？欢迎在评论区分享您的“踩坑”经历与解决方案，我们将抽取三位读者赠送酷番云云安全检测服务体验券。