加了高防还是被DDoS打挂？防护误区与自检清单

作者

很多站长有过这样的经历：明明买了 DDoS 高防，攻击一来，网站还是打不开。本文用 9 个问答盘点 DDoS防御 中最常见的误区，逐条给出症状、原因与可执行的排查命令，最后附一份防护体系自检清单。

Q：加了高防为什么还是被打挂？原因分哪几类？

  • 不是高防没用，而是防护链路上还有没被覆盖的缺口。常见缺口分四类：
  • 入口被绕过：源站 IP 泄露，攻击绕开高防直接打源站。
  • 层次没覆盖：只防了四层流量型攻击，没防七层 CC。
  • 指标没看对：只盯带宽，忽略了 pps 与连接数这类低成本高杀伤的指标。
  • 配置没配好：清洗阈值、黑洞阈值、回源策略设置不合理，防护形同虚设。

Q：误区一：以为买了高防就万事大吉

  • 最大的坑是源站 IP 泄露。攻击者只要拿到源站真实 IP，就可以完全绕开高防清洗节点直打源站。
  • 自查方法：把域名强行解析到源站 IP 直连，如果返回正常页面，说明源站没有做来源限制。
# 若返回 200 且是正常页面，说明源站 IP 能被直连
curl -s -o /dev/null -w '%{http_code}\n' \
  --resolve www.example.com:443:203.0.113.9 https://www.example.com/
  • 加固方式：源站只放行高防回源段，其余全部拒绝，对外只暴露清洗层入口。
server {
    listen 443 ssl;
    allow 203.0.113.0/24;   # 只允许高防回源段
    deny  all;
}

Q：误区二：只防了四层，没防七层 CC

  • 四层（SYN Flood、UDP Flood）看的是流量与连接，七层（CC）看的是请求本身。
  • CC 的流量可能很小、完全落在保底带宽之内，四层清洗对它几乎无感，但动态请求会把后端 CPU 拖垮。
  • 补法：在边缘或源站做请求级限频，给动态接口设更严的阈值。
limit_req_zone $binary_remote_addr zone=api:10m rate=2r/s;
location ~ ^/(api|search)/ {
    limit_req zone=api burst=5 nodelay;
    limit_req_status 429;
}
  • 条件允许时叠加人机验证：只对可疑档位触发验证码，对正常流量零打扰。

Q：误区三：只看带宽，不看 pps 和连接数

  • 带宽（bps）只是三个指标之一。pps（每秒包数） 与 并发连接数 才是小包攻击与连接耗尽的主战场。
  • 典型陷阱：带宽才用了几百兆，但 pps 飙到上千万，设备光口与 CPU 先撑不住。
# 看并发连接与状态分布
ss -s

# 看半开连接堆积情况
ss -ant state syn-recv | wc -l
netstat -s | grep -i -E 'listen|overflow|drop'

# 检查内核半连接队列是否过小
sysctl net.ipv4.tcp_max_syn_backlog net.core.somaxconn
  • 防护侧也要问清：服务商的防护规格是按带宽算，还是带宽与 pps 双指标。

Q：误区四：清洗阈值和黑洞设置不合理

  • 阈值设太高，攻击没触发清洗就直接穿透到源站；设太低，轻微波动就误触发，甚至把正常流量当攻击。
  • 黑洞阈值才是关键：超过某个流量就直接丢进黑洞（屏蔽），业务彻底中断，很多「被打挂」其实就是进了黑洞。
  • 要问清三件事：清洗触发阈值是多少、黑洞阈值是多少、进黑洞后怎么解封、多久解封。
  • 更稳的做法是按业务分级设阈值：核心业务尽量不进黑洞，用清洗与限速顶住。

Q：误区五：防住了入口，回源却被打满

  • 高防把攻击流量洗掉了，但回源链路是另一条瓶颈。如果回源带宽很小，或被大量正常态请求拖垮，源站照样 502 / 504。
  • 排查思路：对比攻击前后源站的入向流量与连接数，看是不是「入口干净了、源站还是满的」。
# 看源站实时入向流量
iftop -i eth0 -n -N -P

# 看历史网卡速率峰值（单位 KB/s）
sar -n DEV 1 5 | grep eth0
  • 缓解：回源走内网或专线、开启缓存减少回源请求、对回源做连接数与速率限制。

Q：误区六：只有一层防护，没有降级和预案

  • 只靠一个高防节点或一个 WAF，一旦它本身异常（链路抖动、配置变更、额度用尽），业务就没有兜底。
  • 常见缺失：没有备用入口、没有静态兜底页、没有提前演练，出事时全凭现场发挥。
  • 补法：入口层做冗余（多高防或多线路）、准备静态降级页、核心业务与次要业务分级保命。
  • 预案要写清谁负责、按什么顺序处置、达到什么条件升级，否则纸面预案等于没有。

Q：怎么给自家防护体系做一次自检？

检查项 合格标准 怎么验
源站 IP 隐藏 域名直连源站被拒 curl –resolve 直连测试
回源白名单 只放行高防回源段 复核 Nginx allow / deny
四层防护 能扛流量型攻击 看服务商规格与清洗记录
七层防护 能限频挡 CC limit_req 规则与 429 比例
指标监控 带宽 / pps / 连接数三看 监控面板与告警阈值
阈值配置 清洗与黑洞阈值明确 向服务商书面确认
回源链路 回源带宽有余量 iftop / sar 观察峰值
应急预案 有降级页与演练记录 演练时间与结果归档

Q：还有什么补充建议？

  • 先量化再加固：统计攻击的峰值带宽、pps、时长与类型，缺什么补什么，别一上来就加预算。
  • 入口架构优先于设备：把源站藏好、把入口上移，通常比换更贵的设备有效得多。
  • 把阈值与计费口径写进合同，出事时才有据可查。
  • 定期演练：不演练的预案只是文档，演练过的预案才是能力。
  • 一句话总结：高防只解决「入口流量」这一段，真正决定业务能不能撑住的是源站隐藏、层次覆盖、指标监控和应急预案这四件事，缺一项就可能在某个方向被穿透。