蓝易云CDN：主机遭受DDoS攻击时该如何应对？怎样预防此类攻击？

服务器突然变慢、网站打不开、SSH连接频繁超时——如果你正在经历这些状况，很可能主机正在遭受DDoS攻击。这种攻击不挑时间、不挑对象，从个人博客到大型企业都可能成为目标。关键在于：遭遇攻击时能不能快速止血，日常有没有做好预防 🛡️

一、确认主机是否正在遭受攻击

在采取任何措施之前，先要判断清楚当前状况。很多时候业务异常不一定是DDoS，也可能是程序bug或配置错误导致的资源耗尽。以下几条命令可以帮你快速定位：

# 查看当前服务器的网络连接状态统计
# netstat -n 显示所有网络连接，不做DNS反向解析（速度更快）
# awk 提取第6列，也就是TCP连接状态字段（如ESTABLISHED、SYN_RECV、TIME_WAIT等）
# sort 排序后 uniq -c 统计每种状态出现的次数
# 如果SYN_RECV数量达到数百甚至数千，基本可以确认是SYN Flood攻击
netstat -n | awk '/^tcp/ {print $6}' | sort | uniq -c | sort -rn

正常情况下 ESTABLISHED 应该占大多数。如果 SYN_RECV 数量异常偏高，说明有大量半连接请求在消耗服务器资源，这是典型的SYN Flood特征。

# 统计每个来源IP的连接数量，找出连接数最多的前20个IP
# netstat -ntu 显示TCP和UDP连接，-n不解析域名
# awk 提取第5列（远端地址），再用cut以冒号分割取IP部分
# 最终按连接数降序排列，输出前20个
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

如果某几个IP的连接数远超其他地址（比如单个IP上千条连接），大概率这些就是攻击源。但要注意，真正的分布式攻击会使用成千上万个IP，每个IP的连接数可能并不高，这种情况需要从整体流量趋势来判断 📊

二、遭受攻击时的紧急应对步骤

第一步：启用CDN防护并隐藏源站

把域名解析切换到蓝易云CDN的CNAME，让所有流量先经过CDN的分布式节点清洗，再将干净流量回源。如果之前已经接入CDN但源站IP已经泄露，需要立刻更换源站IP，否则攻击者可以绕过CDN直接打击源站。

第二步：在源站防火墙锁定回源白名单

# 创建一条iptables规则链专门处理DDoS场景
# -N 表示新建一条自定义链，命名为ANTI_DDOS
iptables -N ANTI_DDOS

# 只允许CDN节点IP段访问Web端口
# -A ANTI_DDOS 在自定义链末尾追加规则
# -s 指定来源IP段（需替换为蓝易云CDN实际的回源IP段）
# -p tcp --dport 443 针对HTTPS端口
# -j ACCEPT 放行匹配的流量
iptables -A ANTI_DDOS -s 103.xx.xx.0/24 -p tcp --dport 443 -j ACCEPT
iptables -A ANTI_DDOS -s 103.xx.yy.0/24 -p tcp --dport 443 -j ACCEPT
iptables -A ANTI_DDOS -s 103.xx.xx.0/24 -p tcp --dport 80 -j ACCEPT
iptables -A ANTI_DDOS -s 103.xx.yy.0/24 -p tcp --dport 80 -j ACCEPT

# 拒绝所有其他来源对Web端口的访问
# 这条规则确保即使攻击者知道源站IP，也无法直接发起请求
iptables -A ANTI_DDOS -p tcp --dport 443 -j DROP
iptables -A ANTI_DDOS -p tcp --dport 80 -j DROP

# 将自定义链挂载到INPUT链上使其生效
# -I INPUT 表示插入到INPUT链的最前面，优先级最高
iptables -I INPUT -j ANTI_DDOS

这组命令的核心思路是：先放行CDN节点的回源IP，再拒绝所有其他来源的HTTP/HTTPS请求。这样即使源站IP暴露，攻击流量也会被直接丢弃。

第三步：内核级TCP参数加固

# 开启SYN Cookie机制
# 正常情况下服务器收到SYN包会分配资源维护半连接队列
# 开启SYN Cookie后，服务器不再为SYN请求分配资源
# 而是通过加密算法在SYN-ACK中编码连接信息
# 只有收到合法的第三次握手（ACK）时才真正建立连接
# 这能从根本上化解SYN Flood攻击
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# 降低SYN半连接的超时重试次数
# 默认值通常是5（对应约180秒的等待），这里降到2
# 即服务器只会重试2次SYN-ACK（约15秒），之后丢弃该半连接
# 大幅缩短恶意半连接占用资源的时间
echo 2 > /proc/sys/net/ipv4/tcp_synack_retries

# 扩大半连接队列容量
# 默认值通常是128或256，在攻击期间会迅速被填满
# 提升到65535可以容纳更多排队的SYN请求
# 配合SYN Cookie使用，为合法连接腾出更多缓冲空间
echo 65535 > /proc/sys/net/ipv4/tcp_max_syn_backlog

# 缩短TIME_WAIT状态的回收时间
# TIME_WAIT是TCP连接关闭后的等待状态，默认持续60秒
# 攻击期间会产生大量短连接，导致TIME_WAIT堆积耗尽端口资源
# 开启快速回收可以更快释放这些端口
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle

需要注意的是，tcp_tw_recycle 在NAT网络环境下可能导致部分合法连接被误拒，如果你的用户大量通过NAT网关访问，建议改用 tcp_tw_reuse，它更安全但回收效率略低 ⚠️

第四步：Nginx层紧急限流

# 在nginx.conf的http段添加限流区域定义
# limit_conn_zone 按IP建立并发连接数限制
# $binary_remote_addr 是客户端IP的二进制表示，每条记录仅占64字节
# zone=conn_limit:10m 分配10MB共享内存，约可追踪16万个IP
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

# limit_req_zone 按IP建立请求速率限制
# rate=15r/s 表示每个IP每秒最多处理15个请求
limit_req_zone $binary_remote_addr zone=req_limit:10m rate=15r/s;

在需要保护的server或location块中应用：

server {
    # 限制单个IP最多同时保持100个并发连接
    # 超出部分直接返回503错误
    limit_conn conn_limit 100;
    
    # 限制单个IP的请求速率
    # burst=30 允许30个请求排队（应对正常的突发访问）
    # nodelay 排队请求不延迟处理，超出burst的直接拒绝
    limit_req zone=req_limit burst=30 nodelay;
    
    # 限制每个连接的传输速率为1MB/s
    # 防止Slow Read类慢速攻击长时间占用连接资源
    limit_rate 1m;
}

这三条限制从不同维度约束恶意流量：并发连接数控制资源占用上限，请求速率防止高频轰炸，传输速率防止慢速耗尽攻击。三者叠加形成立体防护 🔒

三、日常预防DDoS攻击的关键措施

紧急应对终归是被动的，真正有效的防护一定建立在日常预防上。

源站IP保密是第一要务。 不要在DNS历史记录、邮件服务器头部、网页源码注释中暴露源站真实IP。接入CDN之前就使用过的IP地址，很可能已经被扫描工具记录，建议在接入CDN后更换一个全新IP。

关闭不必要的服务和端口。 很多主机默认开放了大量不需要的端口，每多开一个端口就多一个攻击入口。只保留业务必需的端口（如443、80、22），其余一律在防火墙层面DROP掉。

配置弹性带宽和自动扩展。 如果业务托管在云环境中，建议开启带宽弹性扩展能力。虽然这会增加一些费用，但在遭遇中小规模攻击时可以争取到宝贵的响应时间，不至于一上来就被打瘫。

建立监控告警体系。 对服务器的入站带宽、TCP连接数、CPU利用率、HTTP状态码分布设置阈值告警。当带宽突然飙升300%或SYN_RECV数量超过阈值时立即通知运维人员，确保能在攻击早期介入处理 📱

定期审查CDN防护配置。 防护规则不是配完就一劳永逸的。业务变化、新增域名、调整回源策略都可能引入新的防护缺口。建议至少每季度对CDN的WAF规则、限流阈值、回源白名单做一次全面检查。

启用JA4指纹识别能力。 传统的IP黑名单在面对分布式攻击时效果有限，但攻击工具的TLS握手指纹往往是固定的。通过JA4指纹建立威胁信誉库，即使攻击者频繁更换IP，只要工具不变，指纹不变，就能持续拦截 🎯

DDoS攻击没有百分之百的防御方案，但做好应急预案和日常预防，可以将损失降到最低。记住一个原则：平时多一分准备，攻击时就少十分慌乱。