iptables实战：DDoS防护规则与单机防御策略-代码聚汇网

早上七点被电话吵醒，监控大屏上几个关键指标红得刺眼——入向流量从平时几十Mbps直接飙到几百Mbps，业务端口上的TCP半开连接数涨了好几倍，Web响应已经不是变慢的问题，是根本连不上。这是我第一次真正面对DDoS攻击时的场景。后来花了两个多小时，靠着一套iptables规则把服务从崩溃边缘拉了回来。

这次做的是iptables防火墙规则系列的第三个案例，主题是DDoS防护。坦白讲，iptables不是万能的，真遇上百Gbps级别的超大流量攻击，靠它根本扛不住，那得靠云清洗、高防IP这类商业方案。但如果你运维的业务还在小规模阶段，服务器是单机部署，也没有预算上商业防护，那这套规则就是你最现实的第一道防线——至少能扛住小流量攻击，或者在大流量攻击打满带宽之前，帮你把明显恶意的连接拒之门外，给应急处理争取时间。

这篇博文会把我的规则、排查思路和踩坑记录全部放出来，包括入站方向的SYN Flood防御、ICMP/UDP限速、连接数限制，以及很多人忽略的出站方向ICMP报文管理。所有规则都在CentOS 7.6、内核3.10环境下跑过，可以直接拿回去改改就用。

1. 先想清楚：iptables在DDoS防御中能承担什么角色

1.1 三类常见攻击形态与iptables的对应手段

DDoS攻击花样很多，但归根结底就那几类：

流量型攻击：UDP Flood、ICMP Flood、DNS反射放大等。目标是把出口带宽打满，让正常数据包根本进不了服务器，或者到了服务器但排队丢包。iptables对这类攻击只能做限速，不能完全消除——如果带宽已经被占满，iptables在服务器上根本没机会处理报文。
连接型攻击：SYN Flood、TCP连接耗尽、慢速连接攻击等。目标是把服务器的连接跟踪表（conntrack表）和进程最大连接数耗尽，让新连接无法建立。iptables对这类攻击非常有办法，限速、限连接数、DROP异常包，效果立竿见影。
应用层攻击：HTTP Flood、慢速POST等。目标是把应用服务器CPU、数据库连接池打满。iptables只能做非常粗粒度的限制（比如限制单IP并发连接、限制每分钟新连接数），更精细的防护需要Nginx层限流、WAF等配合。

搞明白攻击类型之后，你才会知道该把规则写在哪个方向、用在哪个链。这是很多新手第一个踩坑点——不管三七二十一，先写一堆DROP规则，结果业务先挂掉。

1.2 单机防护的正确姿势：不是丢弃，而是"限制"

我从第一次配DDoS规则期间学到的最重要的一点是：防御DDoS的核心不是"丢"，而是"限"。

如果只把恶意流量DROP掉，攻击者换个源IP就绕过了，而且DROP太狠的方式非常容易误伤正常用户。真正有效的做法是用limit、connlimit、hashlimit这类模块做速率限制和并发控制，让服务器在攻击流量冲击下仍然能分出资源处理正常请求。

什么意思？以SYN Flood为例，你看到的表象是大量源IP在疯狂发SYN包，但这些源IP绝大多数是伪造的，根本没有后续握手。如果直接写一条iptables -A INPUT -p tcp --syn -j DROP，那正常用户的新连接也进不来了，业务直接瘫痪。正确的做法是：对所有SYN包做速率限制，超过阈值的丢弃，阈值之内的放行。这样正常用户握手不受影响，而潮水般的伪造SYN在这个入口就被限住了。

1.3 防护链路设计：入站主防、出站反制、系统层兜底

我的规则设计分三层：

入站规则：限制入站的SYN、ICMP、UDP等高风险协议报文速率，限制单IP并发连接数，清理明显畸形包。
出站规则：很多人完全忽略的方向。当服务器收到大量伪造源IP的UDP或ICMP报文时，操作系统默认会向外回送ICMP错误报文，比如目标不可达（destination-unreachable）、超时（time-exceeded）。这些回包一方面占用了本就不宽裕的带宽，另一方面可能被攻击者当作反射源来利用。因此出站方向我也做了限制。
系统层面：调整内核参数，比如tcp_max_syn_backlog、net.ipv4.tcp_syncookies、nf_conntrack_max等，让服务器在洪水攻击下还能正常建立连接。

这三层缺一不可。只在入站防，出站可能被利用；只防协议层，不调系统参数，连接表照样被打爆。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 环境准备与版本排查：iptables都装不对，后面全白搭

2.1 先解决"无法确定iptables版本"报错

在一些发行版上，比如刚装好的CentOS 7，你敲iptables --version可能会得到几个不同的结果。最常见的错误是"无法确定iptables版本"或"iptables: 未找到命令"。

这种情况一般是iptables、iptables-services没有安装，或者默认的firewalld抢占了你本要用的iptables资源。CentOS 7默认用的是firewalld，虽然它底层也是netfilter，但命令行工具和规则管理方式与传统的iptables差异很大。直接用系统自带的/usr/sbin/iptables命令去操作，有可能会遇到命令缺失或版本识别异常的问题。

解决办法是按下面的步骤来做：

bash复制# 1. 安装iptables和iptables-services
yum install -y iptables iptables-services

# 2. 停用firewalld，避免两个防火墙管理工具抢规则
systemctl stop firewalld
systemctl disable firewalld

# 3. 启动iptables服务
systemctl start iptables
systemctl enable iptables

# 4. 再次确认版本
iptables --version

如果你在Ubuntu/Debian系统，一般是ufw在管，可以安装iptables、iptables-persistent：

bash复制apt install -y iptables iptables-persistent

版本这块顺带一提：iptables 1.4.x和1.8.x的命令参数大体一致，但个别模块选项名有些差异，比如hashlimit在1.6之后有--hashlimit-htable-size这些参数。建议所有规则先在配套环境自测一遍，不要拿到生产环境就直接批量执行。

2.2 确认内核模块：规则写了没生效，先查模块

iptables的很多扩展模块不是默认编译进内核的，如果你执行一条涉及limit、hashlimit、connlimit的命令时出现"iptables: No chain/target/match by that name"，那基本就是对应的内核模块没加载。

在CentOS 7上，可以手动确认：

bash复制lsmod | grep x_tables
lsmod | grep nf_conntrack
lsmod | grep nfnetlink

如果发现模块缺失，先尝试加载：

bash复制modprobe xt_limit
modprobe xt_connlimit
modprobe xt_hashlimit
modprobe nf_conntrack

我遇到的一个真实案例是，某次在最小化安装的服务器上写connlimit规则，提示找不到匹配，排查了半天发现是缺少xt_connlimit模块。因为最小化安装默认装的内核模块集是精简的，很多扩展模块没有附带。加载之后规则就正常了。

注意：modprobe加载是临时生效的，重启后需要重新加载。如果依赖的模块比较多，建议在规则脚本开头统一执行，或者放到/etc/rc.local里。

2.3 清空历史规则：旧规则会让新策略变成一锅粥

在开始写DDoS防护规则之前，一定要先把系统里现有的规则理清楚，否则新规则和旧规则互相叠加，流量走向完全不符合预期。

我常规的清场操作：

bash复制iptables -t raw -F
iptables -t mangle -F
iptables -t nat -F
iptables -F
iptables -X
iptables -Z
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

注意最后三条，把默认策略先设成ACCEPT，是为了避免清空规则后把自己SSH断掉。清场后先确认服务器本身还能登录，再开始逐条加新规则。如果默认策略已经是DROP，清场之前先加一条iptables -A INPUT -j ACCEPT兜底，防止连接中断。

2.4 前置准备：先给自己留一条"逃生通道"

规则加得再猛，也要保证自己有一条能登录的后路。我给自己定了个规矩：所有防护规则落地前，先加一条允许自己管理IP的规则：

bash复制iptables -A INPUT -p tcp --dport 22 -s 你的管理IP --syn -m state --state NEW -j ACCEPT

这条规则一定要放在所有拒绝规则之前。如果管理IP不固定，那至少把SSH端口从22改成一个相对冷门的高端口，同时加上登录失败锁定，这样即使规则误伤，也不至于把自己锁在外面。

这里顺便说一个很有意思的搜索词：iptables -a input -j drop。大家都想写默认拒绝的规则，但很多人忽略了前提——你必须有明确的白名单规则在前面，否则这一条会把SSH也挡掉。我建议的规则顺序是：已有连接放行、关键端口白名单、DoS限速规则、最后才放一个兜底的DROP。兜底的DROP最好用-p 协议和--state NEW来限制，而不是一句话把整个INPUT DROP掉。

3. 入站防护规则拆解：SYN Flood、ICMP和UDP限速

3.1 SYN Flood：用limit做速率门控

SYN Flood是最经典的DDoS攻击方式。攻击者发送海量伪造源地址的TCP SYN报文，服务器内核收到SYN后，会分配传输控制块并发送SYN-ACK，然后等待客户端的ACK确认。由于源地址是伪造的，服务器永远等不到ACK，这些半开连接就会一直占用内存和连接表条目，直到超时。连接表被塞满后，正常用户的SYN包就会被内核直接丢弃。

我常用的第一层防护，是用limit模块给所有新SYN报文做一个速率门控：

bash复制# 允许每秒钟最多10个SYN包，短时间内允许20个突发量
iptables -A INPUT -p tcp --syn -m limit --limit 10/s --limit-burst 20 -j ACCEPT
# 超过上述限制的SYN包直接丢弃
iptables -A INPUT -p tcp --syn -j DROP

这条规则的意思很直白：在一个极小的窗口内，如果SYN包数量超过了20个，后续的SYN就会被丢。为什么是20个突发量？因为正常业务在早晨高峰时，每秒新建连接数可能就有几十个，把突发量设成20会误伤。所以这个值一定要根据自己业务的实际QPS去调整，没有一个万能数字。

如果你的并发确实很高，用limit会显得太粗糙。这时可以换成hashlimit，它可以按源IP维度分别做速率限制，而不是对所有SYN包一视同仁：

bash复制# 每个源IP每秒钟最多允许5个SYN包，突发量10个
iptables -A INPUT -p tcp --syn -m hashlimit \
    --hashlimit-above 5/s --hashlimit-burst 10 \
    --hashlimit-mode srcip --hashlimit-name syn_flood -j DROP

hashlimit的--hashlimit-mode srcip意思是按源IP分别统计，这样正常用户无论怎么刷新都不会被限住，而每个攻击源IP只能以每秒5个的速度发SYN，攻击力度瞬间被弱化。这里有个细节：hashlimit默认会建立一张hash表来跟踪每个源IP的速率，表的大小由--hashlimit-htable-size控制，如果攻击源IP数量非常多，这张表会被撑爆，所以大流量攻击下hashlimit可能失效，limit反而是更稳的兜底方案。我一般两层都写：先用limit做全局兜底，再用hashlimit做单IP细粒度限制。

3.2 连接数控制：connlimit限制单IP并发连接数

SYN Flood限速解决的是"每秒新建连接"的问题，但还有一种攻击是慢慢跟你磨——攻击者用少量肉鸡，每个IP建立大量连接，把服务器的并发连接数占满。这种攻击用connlimit模块可以很好地缓解。

bash复制# 每个源IP最多同时建立20个TCP连接，超过的新连接直接拒绝
iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 20 --connlimit-mask 32 -j REJECT --reject-with tcp-reset

--connlimit-mask 32表示按单个IP来统计，如果你改成24，就表示按整个/24网段来统计，这招对攻击者分散在多个IP但属于同一网段的情况很有效。REJECT而不是DROP的原因，是让客户端立刻收到TCP RST，快速释放本地连接资源，而不是傻等超时。不过，如果攻击者就是想要你多耗CPU，REJECT也可能被利用。我通常对--syn的新连接用REJECT，对已建立的异常连接用DROP，两者配合。

这个规则的阈值也要按业务算。比如一个网站服务器，正常用户打开页面可能要建立6-8个TCP连接（页面、CSS、JS、图片各一条连接），如果单个IP超过20条并发，一般就是在爬数据或者异常访问了。当然，如果是NAT出口网络（整个公司的人共享一个公网IP），20条肯定不够，这时候可以调大到50或者100，或者改用网段掩码大的方式。

3.3 ICMP Flood：别一杆子把ping禁掉

ICMP Flood攻击常见的形式是ping flood——攻击者发送大量ICMP Echo Request报文，服务器内核需要处理并回复Echo Reply，CPU和带宽都会被打满。很多人的第一反应是把ICMP整个DROP掉，但这样做有个副作用：外部的网络监控、自动探测脚本会认为你的服务器宕机了，而且traceroute路径探测也会失败，不利于问题排查。

我倾向于给ICMP做限速而不是完全禁用：

bash复制# 允许每秒5个echo-request，突发量10个
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/s --limit-burst 10 -j ACCEPT
# 超过限制的echo-request丢弃
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

这里只限制了echo-request，没有限制其他ICMP类型。因为网络诊断还需要用到destination-unreachable、time-exceeded这些ICMP消息，特别是做MTU探测时需要用到icmp type 3 code 4（fragmentation-needed）。如果全部丢弃，某些大包传输场景会出问题。另外有个小细节：limit模块的速率是按报文数来算的，一个大包的ICMP（比如1500字节）和一个小包的ICMP（64字节）消耗的带宽完全不同，如果攻击者用大包打你，建议配合IP层长度匹配一起用：

bash复制# 限制大于512字节的ICMP报文，每秒最多2个
iptables -A INPUT -p icmp -m length --length 512:65535 -m limit --limit 2/s --limit-burst 5 -j DROP

3.4 UDP Flood：限速动作要更保守

UDP Flood攻击很难防，因为UDP是无连接的，服务器收到UDP报文后必须交给上层协议处理，即使端口没有服务监听，内核也会回一个ICMP destination-unreachable报文。攻击者可以伪造源IP，让服务器向外发送大量ICMP回包，形成反射放大。

如果业务本身不依赖UDP（比如没有DNS服务、没有视频流、没有游戏服务端），最干净的做法是：只放行必需的UDP端口，其余的UDP包直接丢弃：

bash复制# 放行DNS查询所使用的UDP 53端口
iptables -A INPUT -p udp --dport 53 -j ACCEPT
# 放行NTP所使用的UDP 123端口（如果服务器有NTP同步需求）
iptables -A INPUT -p udp --dport 123 -j ACCEPT
# 对入站UDP做整体限速兜底
iptables -A INPUT -p udp -m limit --limit 20/s --limit-burst 50 -j ACCEPT
iptables -A INPUT -p udp -j DROP

如果业务必须开放大量UDP端口，比如游戏或语音服务，那就必须以端口维度去限速，并且对每个源IP做并发限制。UDP没有连接状态，所以不能依赖connlimit做连接数统计，但可以结合hashlimit做单IP的UDP报文速率限制。

这里要特别提醒：UDP限速的阈值要非常保守。因为UDP Flood可以高到每秒钟几十万个包，而limit模块的匹配本身有CPU开销，如果你写的规则太多、太复杂，攻击还没把业务打挂，iptables先把CPU跑满了。

3.5 连接状态规则：让合法流量走快速通道

防护规则再多，也不能忘了最基础的状态规则。netfilter的连接跟踪机制会维护一张连接状态表（conntrack表），通过-m state可以精确判断一个报文属于哪个连接。合理的状态规则可以减少不必要的匹配开销：

bash复制# 已建立连接及其关联的子连接，直接放行
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# 状态表无法识别的非法报文，直接丢弃
iptables -A INPUT -m state --state INVALID -j DROP
# 全新的连接请求（NEW），进入后续的细节规则
iptables -A INPUT -m state --state NEW -j ACCEPT

这三条放在最前面，会让大多数正常流量直接短路，不会再经过后面N条复杂的limit规则。但注意，如果默认策略是DROP，那--state NEW -j ACCEPT必须配合详细的端口白名单和限速规则来用。我的习惯是：先放行ESTABLISHED和RELATED，然后是白名单端口，然后是DOS限速规则，最后才是一个总体的-j RETURN跳转到业务链去处理。

实际生产中，INVALID状态的报文很多是攻击包的残留痕迹，直接丢弃能省不少CPU。但要注意，某些打了TCP Timestamp补丁的操作系统，在时钟回拨时可能产生大量INVALID报文，这时贸然丢弃可能会误伤，需要结合/proc/sys/net/ipv4/tcp_timestamps的配置一起考虑。

4. 出站方向的"反哺"规则：echo-reply、time-exceeded、destination-unreachable为什么也要管

4.1 出站ICMP回包如何变成攻击放大器

说到DDoS防护，绝大多数人第一反应都是管入站。但我在实战中几次被坑之后，发现出站方向同样藏着风险。

举个典型场景：攻击者伪造受害者IP作为源地址，向你的服务器发送大量UDP报文。你的服务器收到这些UDP报文后，发现对应端口没有服务在监听，内核会默认回复一个ICMP destination-unreachable报文。源地址是伪造的受害者IP，所以这些回包会发向受害者。如果你有N台服务器同时被利用，攻击者就能用一种"反弹"的方式，借助你的服务器带宽去打别人。这就是反射放大攻击的雏形。

再比如time-exceeded（ICMP type 11），当服务器收到TTL为0的报文时，或者遇到某些路由环路的场景，内核会回送该报文。攻击者可以故意构造大量TTL为1的报文，诱导服务器加速回包，从而消耗出站带宽。echo-reply就更直接了，如果服务器被攻击者诱导，对伪造源地址的ping请求不停回echo-reply，出站带宽也会被消耗掉。

所以我在出站方向做了限制，目标很简单：不让服务器在不知情的情况下，成为攻击链条里的"帮凶"，同时避免回包耗尽自己的带宽。

4.2 三条关键ICMP类型的管理策略

针对当前热门的搜索词里提到的三个类型，我的规则是：

bash复制# 1. echo-reply（type 0）限速，允许正常ping回包，但不让洪峰耗尽带宽
iptables -A OUTPUT -p icmp --icmp-type echo-reply -m limit --limit 5/s --limit-burst 10 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -j DROP

# 2. time-exceeded（type 11）限速
iptables -A OUTPUT -p icmp --icmp-type time-exceeded -m limit --limit 3/s --limit-burst 5 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type time-exceeded -j DROP

# 3. destination-unreachable（type 3）限速
iptables -A OUTPUT -p icmp --icmp-type destination-unreachable -m limit --limit 5/s --limit-burst 10 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type destination-unreachable -j DROP

你可能会问：这些ICMP出站消息明明是网络协议正常运作的一部分，一刀切限速会不会影响功能？

需要分场景看：

echo-reply：正常服务器回应ping请求，主要用于网络连通性检查。如果服务器本身不需要被外部ping（比如只提供API服务的后端），完全可以直接丢弃；如果需要被监控系统ping，5/s的速率足够用了。真正大流量攻击下，5/s的限速能屏蔽掉99.9%的异常回包。
time-exceeded：这是traceroute路径探测的关键。如果你还需要做网络路径问题排查，建议保留一部分时间超过的回复。将速率设置为3/s，traceroute在正常使用中不会有问题，因为它本身速率很慢；但攻击者想用这个通道做放大，就会受到限制。
destination-unreachable：这个要小心。路径MTU发现依赖ICMP type 3 code 4，如果完全禁掉，部分大包TCP会话可能出问题。所以我建议只做限速，不要完全丢弃。如果某些业务明确不需要路径MTU发现（比如纯内网同网段通信），可以适当收紧。

我的生产环境里，对这三类ICMP出站报文的处理是限速而不是禁掉，就是怕将来排查问题时少一个工具。但如果你明确知道自己的服务器会被攻击者盯上，且业务完全不需要对外提供这些ICMP诊断能力，直接DROP也是可行策略。

4.3 保留必要链路的平衡做法

出站规则还有一个容易踩的坑：IPv6。

IPv6对ICMP的依赖要比IPv4高得多——邻居发现协议（NDP）完全建立在ICMPv6之上。如果你在IPv6环境下也按IPv4的思路去禁ICMP，可能会导致IPv6邻居解析失败、路由不可达，甚至出现比DDoS攻击还严重的网络中断。我处理IPv6环境时的习惯是：在IPv6链路上只限制ICMPv6的echo-request速率，其余ICMPv6类型（如邻居请求、路由器通告）保持默认放行，除非有专业的IPv6安全需求，否则不轻易动它们。

另外，出站规则还有一个容易被忽略的好处：当服务器被入侵后，攻击者利用服务器发起对外攻击时，出站限速能延缓攻击节奏，给应急响应争取时间。虽然不是核心防护目的，但属于"意外之喜"。

5. 完整脚本、持久化与验证

5.1 可落地的完整防护脚本

把以上规则汇总成一个可以独立运行的脚本，方便直接复用。脚本里的阈值是通用值，生产环境需要按业务实际情况调整：

bash复制#!/bin/bash
# iptables DDoS防护脚本
# 适用环境：CentOS 7.x / 内核3.10，单机部署场景
# 使用前请修改你的管理IP变量

MANAGE_IP="x.x.x.x/32"   # 你的管理IP，放第一个白名单
SSH_PORT="22"
WEB_PORTS="80,443"

# 0. 清空旧规则（谨慎执行，确保当前能登录服务器）
iptables -t raw -F
iptables -t mangle -F
iptables -t nat -F
iptables -F
iptables -X
iptables -Z
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

# 1. 基础状态放行
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state INVALID -j DROP

# 2. 管理白名单
iptables -A INPUT -s $MANAGE_IP -p tcp --dport $SSH_PORT -j ACCEPT

# 3. 业务端口白名单（HTTP/HTTPS）
iptables -A INPUT -p tcp -m multiport --dports $WEB_PORTS -j ACCEPT

# 4. 其他允许的入站服务（按需添加）
# iptables -A INPUT -p tcp --dport 53 -j ACCEPT   # DNS
# iptables -A INPUT -p udp --dport 53 -j ACCEPT
# iptables -A INPUT -p udp --dport 123 -j ACCEPT  # NTP

# 5. SYN Flood防护
iptables -A INPUT -p tcp --syn -m limit --limit 10/s --limit-burst 20 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

# 6. 单IP并发连接数限制
iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 30 --connlimit-mask 32 -j REJECT --reject-with tcp-reset

# 7. ICMP Flood防护
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/s --limit-burst 10 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

# 8. UDP Flood防护（按业务放行UDP端口，其余限速）
iptables -A INPUT -p udp -m limit --limit 20/s --limit-burst 50 -j ACCEPT
iptables -A INPUT -p udp -j DROP

# 9. 出站ICMP防护
iptables -A OUTPUT -p icmp --icmp-type echo-reply -m limit --limit 5/s --limit-burst 10 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -j DROP
iptables -A OUTPUT -p icmp --icmp-type time-exceeded -m limit --limit 3/s --limit-burst 5 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type time-exceeded -j DROP
iptables -A OUTPUT -p icmp --icmp-type destination-unreachable -m limit --limit 5/s --limit-burst 10 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type destination-unreachable -j DROP

# 10. 默认拒绝所有其他入站新连接
iptables -A INPUT -j DROP

# 11. 保存规则
service iptables save

注意第10步的兜底DROP规则，它放在所有白名单和限速规则之后，所以正常用户的前面都已经放行了，能走到这一步的基本就是攻击流量和未知端口扫描。如果业务还有别的入站需求，比如SSH、数据库、内部接口等，一定要在业务端口白名单那一段补好，否则全部会被DROP掉。

5.2 规则持久化：别让重启把你打回原形

规则写完后如果只停留在当前运行的会话里，服务器一重启全部失效。CentOS 7上我习惯用iptables-services的保存机制：

bash复制service iptables save

这个命令会把当前规则写入/etc/sysconfig/iptables文件。下次开机时，iptables服务会从这个文件自动恢复规则。

如果不用iptables-services，也可以手动把规则导出到文件，再写一个开机自启脚本：

bash复制iptables-save > /etc/iptables.rules

然后在/etc/rc.local里加一行：

bash复制iptables-restore < /etc/iptables.rules

记得给/etc/rc.d/rc.local加执行权限：chmod +x /etc/rc.d/rc.local。

还有一个常见问题是：service iptables save时提示"Failed to save rules"或者保存的规则文件为空。这多半是因为iptables-services没有正常安装或者权限问题。确认/etc/sysconfig/iptables文件存在并且iptables用户对它有写权限。如果不行就用iptables-save > /etc/sysconfig/iptables手动导出一份。也见过CentOS主进程里同时开了firewalld和iptables导致保存冲突的，临时把firewalld停了再保存就能解决。

5.3 验证手段：工具模拟与规则统计

规则写完不代表防护生效，必须做验证。

第一件事：查看规则统计信息

bash复制iptables -L -n -v --line-numbers

-v参数会显示每个规则匹配的包和字节数。攻击发生的时候，被命中的DROP规则上的计数器会快速上涨。如果"SYN Flood防护"那一行的包数量持续增长，说明规则确实在拦截流量。

第二件事：用hping3模拟SYN Flood

bash复制hping3 -S -p 80 -i u1000 --flood 你的服务器IP

-i u1000表示每微秒发送一个数据包，--flood表示快速发送。跑几秒钟之后，回到服务器上看iptables -L -n -v，SYN防护规则那行的DROP计数应该明显上涨。同时用另一个终端尝试正常访问Web服务，看是否还能通。这一步非常关键，因为如果规则误伤正常用户，测试时你会立刻发现。

第三件事：用tcpdump确认回包行为

bash复制tcpdump -i eth0 icmp and src 服务器IP

模拟ICMP Flood后，观察出站的echo-reply是否被限速到了设定的速率范围。如果看到大量回包还在往外发，说明规则顺序有问题，回包可能在匹配到limit规则之前就被其他ACCEPT规则放行了。

第四件事：最实在的验收方式——攻击下正常访问

在攻击进行的同时，用curl从外部反复请求服务器上的业务页面，确认响应时间没有明显恶化。如果攻击10秒内页面还能打开，说明规则生效了；如果直接超时，先看是带宽被打满还是规则顺序问题。

5.4 排错：规则不生效时按这个顺序查

遇到过太多朋友说"我写了DROP，为什么攻击流量还在"，排错顺序基本是：

看规则序号：iptables -L INPUT -n -v --line-numbers，确认你的DROP规则是否真的排在ACCEPT规则之前。iptables是顺序匹配，先匹配到ACCEPT就会跳过后面的DROP。
看内核模块：limit、connlimit、hashlimit是否加载，lsmod | grep xt_。
看网卡流量：sar -n DEV 1或ifstat，确认攻击流量是打到了服务器网卡，还是没有打到（这决定了iptables到底有没有机会处理）。
看conntrack表：sysctl net.netfilter.nf_conntrack_max和cat /proc/sys/net/netfilter/nf_conntrack_count，如果表满了，新连接会直接丢，即使iptables规则写对了也可能出现"连不上但不进规则"的假象。
看CPU：mpstat -P ALL 1，如果CPU100%在软中断上，多半是流量真的打满了，规则已经尽力在丢包，只是丢包也需要CPU。

有一回我在排查一个"规则没用"的问题，发现攻击流量每分钟几百万个包，但由于网卡开启了RSS多队列，流量被分到多个CPU核心处理，每个核心都在拼命跑软中断。iptables虽然逐条匹配了规则，但DROP动作本身也要消耗CPU，最后CPU还是被打满了。这种情况不是规则的问题，是单机性能的物理极限。能做的只有两条路：一是升级到更好的服务器或者加网卡队列，二是把部分防护能力前置到网络层/云厂商。

6. 边界、取舍与落地建议

6.1 规则不是越多越好，排序比数量重要

iptables规则是线性匹配的，每多一条规则，每个数据包通过时就会多一次比较运算。在DDoS场景下，攻击流量每秒钟可能有几十万个包，如果规则集本身变成性能瓶颈，就会得不偿失。我见过有人把几百条IP白名单和黑名单规则放在前面，结果攻击来时，即使大部分流量被丢弃，CPU也先被规则匹配耗尽了。

我的经验是：把最可能命中的规则放前面，把代价最高的规则放后面。比如状态规则（ESTABLISHED,RELATED）放最前，因为大多数正常流量属于这一类，可以快速短路。然后是端口白名单，接着是限速类规则，最后才是兜底DROP。如果有很多IP要封禁，建议用ipset而不是逐条iptables规则，ipset在匹配效率上比逐条规则高好几个量级。

6.2 内核参数：iptables之外的灵魂伴侣

iptables规则只是"拦截报文"，但DDoS的很多攻击效果是通过内核行为放大的。必须配合调整内核参数：

bash复制# 开启TCP SYN Cookie，内核在SYN队列满时用Cookie机制维持服务
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# 增大SYN队列长度
echo 4096 > /proc/sys/net/ipv4/tcp_max_syn_backlog

# 增大conntrack表容量
echo 65536 > /proc/sys/net/netfilter/nf_conntrack_max

# 缩短SYN半开连接的超时时间，让恶意半开连接快速释放
echo 1 > /proc/sys/net/ipv4/tcp_timestamps
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle

注意tcp_tw_recycle在NAT环境下可能引起异常，Linux内核4.12之后已将其移除，CentOS 7老内核可以设置，但如果有NAT转发场景建议别开。还有一个比较管用的参数是net.ipv4.tcp_fin_timeout，默认60秒，把它改成15-30秒，可以让快速连接的复用更快，减少TIME_WAIT堆积。

把这些参数写入/etc/sysctl.conf就能持久化：

bash复制net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.netfilter.nf_conntrack_max = 65536
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_tw_reuse = 1

改完之后执行sysctl -p。

6.3 什么时候必须换方案：认清单机防护的物理极限

iptables防DDoS有非常现实的边界。我自己做过的压力测试显示，在普通的4核8G云主机上，iptables单纯做DROP操作，能处理的报文速率大概在50万pps左右，再高的话CPU软中断就会被打满。如果再叠加limit、hashlimit这些复杂规则，性能还会再降一些。也就是说，如果攻击流量达到100万pps以上，即使规则写对了，服务器也会因为处理不过来而瘫痪。

这时候该做什么？我的选择顺序是：

用CDN先扛流量型攻击：把静态资源和部分API放到CDN后面，源站IP隐藏起来，攻击者打不到源站。
用云厂商的高防IP：把DNS解析切到高防IP，它会先清洗流量，只有干净流量才回源到服务器。成本较高，但面对大流量攻击时是唯一现实的选择。
在服务器前面加一个轻量级负载均衡：用LVS或者Nginx做入口，使用一台性能较好的设备先做流量分发，把攻击流量挡在前面一层。这属于架构调整，需要提前规划。
多活设计：业务本身做多机房部署，即使一个机房被打挂，流量切到另一个机房。

iptables在这些方案里仍然有价值——它是成本最低、最快部署的临时防护手段。我的真实做法是：平时把规则关掉或者放宽，只有在攻击发生时一键开启，缓解几分钟，等云清洗或高防IP的路由切换生效。这样既不会影响业务正常流量，又能在关键时刻顶住冲击。

另外，别忘了日志。iptables的LOG目标虽然会消耗额外资源，但在排查攻击特征时非常有价值。我习惯在DDoS攻击期间临时加一条LOG规则，把限速命中的数据包打到系统日志里，分析攻击报文的特征（源IP分布、端口变化、TOS值等），再做针对性封禁。攻击停止后记得把LOG规则删掉，否则日志文件会爆炸。

对于打算直接把这套规则用于生产环境的读者，最后再提醒一次：阈值一定要按自己的业务调。我的10/s SYN限制和5/s ICMP限制只适合小流量的Web服务，如果你的业务本身QPS很高，这些值要往上调。规则上线前，先在测试环境压一遍，确认真实业务不会触发误杀，再拿到线上。

还有一个小技巧：规则全部配好之后，给规则文件留一份注释备份，在/etc/sysconfig/iptables文件里用#写上每条规则的用途和调整时间。攻击发生时大家都很紧张，留好注释能让你或者同事在混乱中快速定位问题，而不是现场猜规则。这套脚本我用了快三年，中间迭代过好几版，每次改动都留了注释，回滚的时候省了太多时间。

iptables实战：DDoS防护规则与单机防御策略