1. DDoS攻击到底是个什么东西1.1 从一次“网络房涝”说起先别急着背定义。想象一下你开了一家奶茶店店面不大但日常客流刚刚好后厨、收银、出货都顺畅。突然有一天门口一下子涌进来几百人每个人只问你一句“珍珠奶茶怎么卖”然后堵在门口不进来也不走。后面的人继续往里挤真正的顾客进不去收银台被围死电话打不进来外卖订单全乱套。你明知道这些人不是真买家但每一张脸都是真实的你没法简单地把所有人赶走店就这么瘫了。DDoS攻击就是这么回事。全称是Distributed Denial of Service分布式拒绝服务攻击。简单说攻击者操控大量“僵尸”设备——可能是肉鸡电脑、摄像头、路由器、被攻陷的服务器——同时向目标服务器发起海量请求。这些请求本身不一定有多高明真正的破坏力在于“量”。量大到服务器来不及处理带宽被占满连接表被打爆CPU跑满内存耗尽正常用户的请求就全部被挤掉业务直接中断。你可能会问这跟DoS有什么区别DoS是单点攻击一个人用一台机器发起洪水般的请求但服务器很容易识别并屏蔽这个单一来源。DDoS的核心在于“分布式”攻击流量来自成千上万个不同IP分布在不同的网络、不同的地区、不同的运营商单靠防火墙拉黑某个IP根本解决不了问题因为来源太多了而且很多来源是真实的“无辜”的设备。正因如此DDoS成为目前网络上最难防御、也最容易被低估的威胁之一。1.2 为什么有人要发动DDoS动机千奇百怪但归结起来无非几类。第一类是勒索。攻击者先打瘫你的网站然后发邮件告诉你“给钱就停手”。很多中小型企业、电商平台都中过招。第二类是商业竞争选择特定时段打竞争对手的促销活动让对方的系统在大促当天宕机损失的是实实在在的真金白银。第三类是政治或意识形态表达某个组织或黑客团体针对特定目标发起抗议式攻击。第四类纯粹是炫技黑客想证明自己有能力瘫痪某个目标。第五类是游戏的游戏开服、赛事期间打崩服务器是重灾区。不管动机是什么结果都一样业务受损、数据可能丢失、用户信任度下降、后续修复成本远超一开始的防护投入。从我个人的观察来看近几年DDoS攻击的门槛已经降到了令人担忧的地步。早年你需要写代码、搭僵尸网络现在网络上甚至有“攻击即服务”的地下模式花很少的钱就能买到一次几十Gbps的攻击。这意味着任何一家拥有线上业务的小公司、小站长都可能有一天莫名其妙被打。这篇内容我会把原理、分类、防御办法一次讲透也附上我自己踩过坑之后的经验教训读完你至少能搞明白攻击是怎么来的、现在到哪一步了、我应该先做什么再去做什么。2. DDoS攻击的原理拆开来看其实很简单2.1 正常请求是怎么被处理的要理解攻击原理得先知道一个正常的用户请求在服务器端走过哪些关卡。假设你用浏览器访问一个网站。连接过程通常是这样DNS解析浏览器把域名换成IP地址。TCP三次握手你的机器向服务器发送SYN包服务器回复SYNACK你回ACK连接建立。发送HTTP请求浏览器发送GET /index.html等请求。服务器处理Web服务软件解析请求查数据库或读取文件生成响应。返回页面浏览器渲染页面TCP连接关闭或复用。这个流程里每一步都需要消耗服务器资源。三次握手消耗的是TCP连接表中的席位处理HTTP请求消耗的是CPU、内存、磁盘I/O和网络带宽。正常场景下资源绰绰有余但在攻击场景下攻击者会针对其中一个环节进行饱和打击。只要有一个环节被彻底堵死整个服务就不可用了。攻击的本质其实也是这四个字资源耗尽。带宽是资源连接表是资源CPU/内存也是资源。攻击要做的事情就是找到目标系统最短缺的那一种资源然后用巨额流量把它填满让正常请求无路可走。2.2 分布式和僵尸网络是如何运作的上面说过来自多个来源是DDoS的关键。那么攻击者怎么拿到成千上万的“攻击炮台”呢核心机制是僵尸网络。第一步批量扫描和植入。攻击者用蠕虫或漏洞利用脚本扫描互联网上暴露的脆弱设备最常见的包括未修改默认密码的摄像头、路由器、智能家居设备、老旧的Linux服务器。植入后门后把这些设备控制权提走。第二步集中控制。被控制的设备会主动连接到攻击者搭建的命令控制服务器等待指令。平时它们照常工作、网络流量很小极难发现。第三步发起攻击。攻击者对控制服务器下发一条指令所有僵尸设备同时向目标地址发起指定类型的流量。一瞬间成千上万个分布在各地的IP同时涌向你的服务器流量从四面八方汇聚形成一场“流量雪崩”。这里有一点很重要很多被控设备的主人完全不知情。攻击者借刀杀人用的刀是普通人家里的智能插座、楼下便利店的监控摄像头、某个小公司的路由器。这也给防御带来了巨大挑战——这些源IP都是真实的、分散的你无法通过简单地封锁IP来解决问题因为封锁了这5万个IP之后攻击者手里的池子里也许还有100万个。2.3 放大攻击四两拨千斤的高级玩法如果把普通的DDoS比作直接用车撞门那反射放大攻击就是借别人家的卡车来撞。攻击者不直接向目标发流量而是伪造源IP为目标的IP向互联网上大量开放特定UDP服务的服务器发送“小个子”请求。这些服务器收到请求后会把远远大得多的响应数据发送到伪造的源IP——也就是目标机器上。攻击者发出1Mbps的流量最终砸到目标头上可能是几百Mbps甚至几Gbps。最经典的两种放大向量DNS放大攻击者向开放的DNS递归服务器发送源IP伪造为目标的查询请求比如查询“ANY 某个域名”。一次几十字节的查询请求响应可能达到数千字节放大倍数通常在50倍以上。互联网上有大量配置不当的开放DNS服务器它们都是潜在的放大器。NTP放大向开放的时间同步协议服务器发送MONLIST请求获取最近连接过的客户端列表响应体量极大。历史上的攻击中NTP放大倍数可以达到数百倍一次几百字节的请求返回几十KB甚至几MB的数据。这种“小请求、大响应”的思路让攻击门槛进一步降低。哪怕攻击者手上的僵尸带宽只有几个Gbps他们也能通过放大手法折腾出上百Gbps的攻击流量。国内云服务商和运营商现在会在骨干网层面做一定的源地址校验来削弱这种伪造源IP的攻击但互联网上依然存在大量历史遗留的开放解析器和NTP服务器这类攻击在短期内不会消失。3. 常见攻击类型从打满带宽到打死应用3.1 体积型攻击把带宽直接打满体积型攻击的目标是带宽。攻击者制造巨量数据包淹没目标链路导致合法流量根本没有地方走。你可以把链路想象成一座大桥双向车道的承载量是固定的。体积型攻击就是把桥上每一寸路面都塞满货车所有正常车辆都得在入口排队谁也过不去。常见的手法包括UDP Flood向目标主机的任意端口发送大量UDP数据包。目标系统收到UDP包后会检查端口是否有应用在监听通常没有就回一个ICMP端口不可达报文。这些报文本身也要消耗CPU资源。更致命的是UDP没有三次握手机制源IP可以随意伪造防守方极难回溯。ICMP Flood也就是Ping洪水向目标发送大量超大尺寸的ICMP Echo请求。这种手法相对原始很多防护设备能轻松识别但在大流量攻击中它不会单独出现更多是作为一种流量填充手段混在其他攻击里。传输层混合型比如UDP碎片包、GRE封装等目的是让防护设备在碎片重组上消耗大量CPU同时占满带宽。判断体积型攻击有个方法在服务器上执行实时流量监控看到入向流量远远超出业务正常峰值而且几乎都是不明来源的数据包时大概率就是了。体积型攻击的防护逻辑也比较直接——要么硬扛带宽要么在更上游的节点做流量清洗具体操作我在第5部分详细说。3.2 协议型攻击打的是状态表和处理逻辑协议型攻击不追求占满带宽而是追求打垮目标系统维持连接状态的能力。最典型的例子是SYN Flood。SYN Flood的原理建立在TCP三次握手之上。攻击者发送大量SYN请求但从来不完成第三次握手。服务器收到SYN后会在内核的半连接队列里保存本次握手的状态并分配一小块内存回复SYNACK然后等待客户端的ACK。正常客户端会立刻回ACK完成握手攻击者则永远不会回。服务器等待超时、清掉记录后下一波SYN又来了。半连接队列很快就满了新的SYN请求无法进入正常的TCP连接也建立不起来。这类攻击的可怕之处在于它不需要很大的带宽就能造成毁灭性后果。攻击者每分钟发几千个SYN包就可能把一个中小型服务器打瘫因为服务器的半连接队列是固定且有上限的。除了SYN Flood协议层还有几种变体ACK Flood发送大量ACK包迫使服务器去查连接表如果查无此连接则返回RST同样消耗CPU。连接耗尽攻击发起大量真实的TCP连接建立完成后不发业务数据也不关闭占用服务器的文件描述符和内存池直到资源耗尽。这类攻击很难识别因为每个连接看起来都“合法”。SYN Flood的一个好类比旅馆前台只有100张房卡攻击者谎称有5000人要入住前台每发一张房卡就把某个房间锁上但“客人”永不到达房间逐渐全被锁死真客人来了也办不了入住。3.3 应用层攻击伪装成正常请求打死业务逻辑应用层攻击主要针对HTTP/HTTPS协议是当前最难防御的类型。因为它不要求高速率、大带宽只要像正常用户那样发请求即可从流量特征上几乎无法区分。最常见的应用层攻击包括HTTP Flood也叫CC攻击用大量僵尸或代理IP反复请求页面、图片、下载接口、搜索接口。它们单看每个请求都和普通用户浏览相差不大但聚合起来就能耗尽Web服务器的忙闲进程、后端数据库连接池以及线程池。慢速攻击Slowloris攻击者建立TCP连接后发一个不完整的HTTP请求头部然后以极慢的速度逐字节发送剩余内容。服务器会一直为这个“进行中的请求”保留线程或连接直到超时。这种手法用很少的连接就能拖垮Apache等老牌Web服务。重放攻击/组合拳高频请求某个消耗很大的接口比如短信发送接口、PDF导出接口、搜索接口。攻击者不关心页面本身只盯着那些会触发后端复杂计算的接口一次请求可能等同于正常用户十次访问的成本。这类攻击由于流量总量不大传统按带宽判断的防御方案常常失灵。如果服务器本身没有应用层的限流、频率控制和WAF规则被打是迟早的事。3.4 攻击类型总结与防御取舍攻击类型主要目标典型手法带宽消耗识别难度防御侧重点体积型链路带宽UDP Flood、ICMP Flood、DNS放大极大低上游清洗、高防带宽、CDN分散协议型连接状态、CPUSYN Flood、ACK Flood、连接耗尽中等中等内核参数调优、SYN代理、防火墙规则应用型应用逻辑、资源池HTTP Flood、慢速攻击、接口重放较小高WAF规则、IP频率限制、行为分析这张表是防御设计的起点。实际攻击中很少只出现一种类型更多是大流量带宽攻击掩护小流量精准应用攻击的组合打法。所以防御不能单点部署需要多层协同后面讲实操环节我再展开。4. 攻击的“成功条件”与影响范围4.1 攻击成功什么意思打穿哪一层才算成功很多人以为攻击成功就是“网站打不开”其实这是个相对概念。DDoS攻击成功与否取决于攻击目标中最薄弱的环节在哪里被打穿。对一台小网站服务器来说带宽可能只有10Mbps攻击流量达到100Mbps时链路直接堵死网站彻底无法访问。但对一个大客户来说带宽有10Gbps攻击流量也到了100Mbps的话根本毫无感觉。也就是说同一个攻击对不同目标造成的影响完全不同。攻击者通常会先用低流量试探摸清目标的承载上限再逐步加压。判定成功的维度包括链路层运营商接入带宽被占满普通数据包无法进出。设备层防火墙、负载均衡器的CPU或内存被打到100%设备失去处理能力。系统层服务器的TCP连接表、半连接队列溢出新连接无法建立。应用层Web服务器繁忙线程池耗尽后端数据库连接池达到上限接口响应时间呈指数级增长直至超时无响应。从用户角度看表现可能是页面加载极慢、卡在转圈无法打开、接口报错、服务时断时续、数据库主从延迟暴增。防御的最终目的就是把攻击对上述所有层面的影响压到可控范围内。4.2 影响范围和持续时间不只是技术问题DDoS的影响范围远超技术人员的第一反应。业务侧的影响通常是营收直接损失。电商、游戏、在线教育这类依赖实时线上交易的业务每中断一分钟都是白花花的银子流失。高峰期的几个小时内被打瘫可能直接抹掉当天利润。用户信任受损。用户访问失败后轻则过段时间再来重则转头用竞品。特别在服务型产品里一次长时间故障就可能带来一波不可逆的用户流失。安全风险放大。DDoS攻击很多时候是“烟雾弹”攻击者趁运维人员忙于处理流量洪峰时穿插Web渗透、数据窃取、植入后门等动作。你忙着堵洪水人家已经从窗户爬进屋了。供应链连锁反应。攻击目标如果是某个核心API或DNS服务所有依赖该服务的下游系统都会跟着宕机。这也是一些攻击者专门挑“单点基础设施”打的原因。持续时间方面早期攻击通常只有几分钟到几十分钟纯粹碰运气式骚扰。但现在有组织的攻击动辄持续数小时甚至数天攻击者会不断切换手法、调整流量大小试图找出防御体系的漏洞。所以应急方案必须考虑“拉锯战”的可持续性不能只靠一两个人手动硬顶。5. 防御体系怎么搭建从底层到应用的操作手册5.1 前置防线带宽、清洗和高防IP防御DDoS最核心的一条原则是不要在源站硬扛。如果你的服务器直接暴露在公网而攻击流量已经超过了运营商分配给机房的带宽上限那么无论你服务器的硬件多好、内核参数调得多么完美都无法挽救——因为大量数据包在更早的链路层就已经被堵死了。所以第一层防线必须前置选择能替你在上游“挡刀”的基础设施。如果你是中小企业或站长最务实的路径有几种使用云服务商的DDoS高防IP。国内主流云厂商都有类似产品本质上是一个具备超大带宽和流量清洗能力的转发节点。真实源站IP被隐藏起来所有流量先经过高防节点清洗掉攻击流量后只把干净流量转给源站。选择高防产品时重点看“保底防护能力弹性防护能力”比如保底10Gbps、弹性上探到30Gbps超出上限的部分会触发黑洞或单独计费这些要在采购前问清楚。接入CDN做全站加速和流量分摊。CDN通过边缘节点缓存静态资源用户请求直接被边缘节点消化回源量大幅减少攻击流量也分散到各个节点上。但要注意CDN不擅长处理针对源站IP的直接攻击所以CDN和高防IP配合使用效果更好。如果业务对时延敏感且资金充足可以购买运营商级别的流量清洗服务。运营商会将异常流量牵引到清洗设备上过滤后再注入回原链路。这种方案防护能力最强但价格也不低通常是中大型企业的选择。我自己踩过的坑就是早期图省钱把网站直接放在一台云主机上没挂任何防护结果有一天晚上被人用几十Gbps的UDP Flood直接打黑洞机房直接把IP封禁了。业务中断了两个多小时后来才发现只要把源站IP藏起来用高防IP做转发很多攻击根本打不到源站。5.2 源站加固操作系统和内核参数优化前置防线不是万能的高防设备转发回来的流量如果过于凶猛源站自己也得能扛一部分。操作系统层面有一些低成本的调优能明显提升抗攻击能力。以Linux系统为例最常用的一套优化项# 开启SYN Cookies防止半连接队列被SYN Flood打满 sysctl -w net.ipv4.tcp_syncookies1 # 缩短SYNACK重传次数让半连接更快超时回收 sysctl -w net.ipv4.tcp_synack_retries1 sysctl -w net.ipv4.tcp_syn_retries1 # 调整连接追踪表最大值避免conntrack表满导致丢包 sysctl -w net.netfilter.nf_conntrack_max2000000 # 降低TCP KeepAlive探测间隔尽快回收无效连接 sysctl -w net.ipv4.tcp_keepalive_time120 sysctl -w net.ipv4.tcp_keepalive_intvl30 sysctl -w net.ipv4.tcp_keepalive_probes3 # 增大本地端口范围应对大量出向连接 sysctl -w net.ipv4.ip_local_port_range1024 65535 # 缩短TIME_WAIT等待时长减少系统资源占用 sysctl -w net.ipv4.tcp_fin_timeout15这些参数在攻击发生时能起到减缓系统资源枯竭的作用但要明白一点参数调优是“被动增强”不是“主动防御”。如果攻击流量远超服务器的CPU和内存承载能力什么参数都没用最终还是得靠前置防线。另外建议在服务器上关闭不必要的外网端口仅开放业务必需的80、443、数据库内网端口等。攻击者发起的UDP Flood经常乱打端口如果某端口没有服务监听系统会回复ICMP不可达消息这个回复过程会白白消耗CPU。用防火墙统一控制入向来源也是个常用的手段但要注意策略不要写得过于死板否则误杀正常用户就得不偿失了。5.3 应用层防御不只靠防火墙应用层攻击的防御不能只依赖网络层的防火墙必须在业务入口处设计多重限流和校验机制。Nginx层面最基础的配置是限制每个IP的请求速率和并发连接数。一个正常用户在同一秒内不会发起几十次页面请求如果出现这种特征基本可以判定是脚本攻击或CC攻击。# 限制单个IP的并发连接数 limit_conn_zone $binary_remote_addr zoneperip:10m; limit_conn perip 10; # 限制单个IP的请求速率 limit_req_zone $binary_remote_addr zoneperipreq:10m rate10r/s; limit_req zoneperipreq burst20 nodelay;上面的配置中rate10r/s表示每个IP每秒最多允许10个请求burst20表示允许瞬间超过20个请求排队但不直接拒绝。这个参数要根据你的业务真实情况调整比如API接口可能需要更严苛的限制而门户网站的首页可以适当放宽。除了IP维度更精细的防御包括配置WAF规则识别并拦截常见的攻击特征。比如SQL注入、XSS探测、恶意爬虫UA等。现在很多云WAF和开源的ModSecurity都能做这块关键是规则要持续更新不能装完就不管。对需登录的接口加入验证码或滑动验证。攻击者即使批量调用登录接口也会被验证码拦截。但注意验证码本身在多并发下也会消耗资源要放在滑动验证、行为验证等轻量方案里选。对API接口做鉴权、签名校验、频率控制。不少攻击是直接冲着你暴露的API来的如果API没有鉴权任何人都能循环调用服务器资源就会被耗尽。API网关层做统一限流是最好的方案。使用基于行为的封禁策略。比如一段时间内某个IP请求的URL分布是否均匀、是否频繁请求同一资源、User-Agent是否异常等将这些特征喂给自动化分析脚本实时生成封禁名单同步到Nginx或防火墙。高级一点的方案是引入AI流量分析它能在几秒内识别出攻击模式但我个人建议先别急着上AI很多中小业务靠简单阈值和UA黑名单就能挡住80%以上的攻击。5.4 监控和预警别等被打瘫了才知道太多团队是在业务彻底不可用、用户投诉炸锅之后才发现被攻击了。其实DDoS攻击在早期往往有征兆就看监控做没做到位。我建议至少部署以下几项监控流量监控实时展示入向/出向带宽以5分钟粒度记录历史趋势。一旦发现带宽峰值超出平时正常峰值的数倍立刻告警。TCP连接监控跟踪服务器上的ESTABLISHED、SYN_RECV、TIME_WAIT等状态的连接数。SYN_RECV突然暴增基本可以断定是SYN Flood。Web服务监控关注请求QPS、平均响应时间、错误率。如果QPS没怎么变但响应时间暴涨可能是慢速攻击或应用层攻击。资源监控CPU、内存、磁盘I/O、文件描述符使用率这些指标在攻击发生时都会异常飙升。告警策略也别搞一刀切最好设置两级一级是“关注级”比如带宽超过日常峰值2倍但服务仍正常通知运维值班人员观察二级是“告警级”比如服务可用性下降、错误率超过5%需要立即启动应急流程。很多监控平台支持自定义告警频率和升级机制多花点时间调好阈值比事后补救划算得多。6. 攻击实验与防御验证别拿生产环境开玩笑6.1 用隔离实验环境搞懂攻击原理现在很多新人想学DDoS但一上来就照着网上的脚本去打某个网站这是极其错误而且违法的行为。真正专业的做法是搭一个隔离的实验环境在完全受控的范围内做测试。最简单的实验环境可以这样搭用VMware或VirtualBox建两台虚拟机。一台充当“攻击机”一台充当“靶机”。网络模式选仅主机模式或自定义的隔离网段确保数据包不会跑到外网。靶机上安装一个轻量级的Web服务比如Nginx或者Apache正常访问起来。攻击机上用一些专门的压力测试工具比如hping3、Apache Bench或wrk向靶机发起可控的测试流量。这里的目的是观察攻击特征而不是制造真正的破坏。比如用hping3模拟一个简单的SYN Flood测试# 针对靶机80端口每秒发送指定数量的SYN包源IP随机伪造 hping3 -S -p 80 --flood --rand-source 192.168.x.x在测试过程中打开Wireshark抓包你会看到大量SYN包发过去后靶机回复SYNACK但基本收不到ACK。用tcpdump或者ss命令查看靶机的TCP连接状态会发现半连接数量迅速上升正常的新连接开始超时。整个过程中你能直观地理解为什么SYN Flood会造成服务不可用。再比如用wrk测试应用层压力# 以100个并发连接、持续30秒请求目标地址 wrk -t 8 -c 100 -d 30s http://192.168.x.x/观察Nginx的access日志你会看到大量相同IP的请求在同一时间段内密集出现。随后在Nginx里加上限流配置再跑同一组wrk命令对比一下配置前后的QPS、响应时间和拒绝请求数防御效果一目了然。实验室测试最重要的一条原则永远只在隔离网络里操作并且时刻把流量控制在可控范围内。这些测试的目的不是学会攻击而是理解攻击的行为特征、识别方法和防御策略这样等真正被攻击时才不会手忙脚乱。6.2 如何验证你的防御配置是否有效配置完防御措施不验证等于没做。我自己习惯在每次业务发布前做一次“压力演习”把防御效果量化出来。演练步骤大概是在低峰期比如凌晨三四点选择一台测试用的服务器或高防IP节点确保不影响线上业务。用流量发生器逐步增加压力从占正常负载的80%加到200%、500%记录服务在每一档压力下的响应时间、请求成功率、CPU和带宽占用。同时模拟一种攻击类型比如SYN Flood观察半连接队列的变化、高防节点是否成功拦截、源站是否有感知。恢复流量后等待一段时间再逐级降压力确认没有残留影响。将测试结果整理成一份记录标注每种攻击类型下服务还能保持正常的最大的流量阈值。这份数据是后续扩容和采购高防带宽的依据。这里特别提醒压力测试不要在生产环境的业务高峰期做。哪怕你以为自己只是“压了一下”对真实用户来说就是卡顿甚至故障。如果有条件最好先在测试环境里做一轮再找一个业务流量最低的时间段做线上验证整个过程提前通知到客服和运营团队以免误判为真实故障。7. 常见问题与排查技巧实录7.1 怎么判断自己正在被DDoS攻击这个问题听起来简单但很多运维人员确实会在早期误判。以下几种典型现象组合出现时基本可以高度怀疑DDoS服务器或业务突然异常卡顿登录服务器执行top命令发现CPU/内存飙升但进程列表里看不到明显可疑的高占用进程。用iftop或nload查看流量入向带宽远高于日常水平而且来源IP分布杂乱、地域分布异常。执行netstat -ant | grep SYN_RECV | wc -l半连接数瞬间上万而平时只有个位数。Web日志中出现大量同一页面或同一接口的密集请求请求频率远超任何正常用户访客。业务监控平台显示平均响应时间从几百毫秒涨到几十秒错误率同步飙升。如果以上现象同时出现两三条以上按DDoS攻击的方向去排查大概率没错。同时建议立刻检查重要数据有没有被异常导出、系统有没有出现未知进程或计划任务防止DDoS只是掩人耳目的前奏。7.2 攻击发生时接下来应该做什么攻击已经开始别慌按顺序执行这几步。第一步确认攻击类型。看流量特征入向带宽极大多为体积型半连接多多为SYN Flood连接数多但带宽不大可能是连接耗尽或慢速攻击请求集中在特定URL多为应用层攻击。这一步决定了你后续的操作重点。第二步启用上游防护策略。如果你买了高防IP或CDN立刻把源站流量切到高防节点隐藏源站IP。如果攻击针对的是域名可以临时将解析切到高防IP。这里有个常被忽略的点确认源站IP没有通过DNS泄露出去否则切了域名也白搭攻击者可以直接打源站IP。第三步在服务器和防火墙上做紧急临时封禁。对于来源IP相对集中的攻击可以写临时防火墙规则批量封禁。# 封禁某个来源IP示例 iptables -A INPUT -s 1.2.3.4 -j DROP # 开启SYN代理若有iptables可临时开启防SYN Flood的模块 sysctl -w net.ipv4.tcp_syncookies1对应用层攻击临时调低Nginx限流阈值把可疑的User-Agent或特征请求直接返回403。这一步可能会误伤部分正常用户但在危急时刻保证整体服务可用是第一优先级。第四步联系云服务商或高防服务商开启紧急清洗和弹性防护。大部分云厂商都有7x24小时应急响应团队说明攻击规模和类型后他们会协助做流量牵引和清洗。如果你还没接入任何高防产品此时才临时买大概率已经来不及了所以防护还是要提前部署。第五步持续观察并记录。攻击不会几分钟就结束通常会持续数小时。每隔5-10分钟记录一次流量、连接数、资源使用率、封禁效果这些数据既方便你做后续优化也为可能的溯源取证留底。7.3 防御策略的常见误区和注意细节误区一以为防火墙能挡住一切。传统防火墙是基于状态检测的面对巨大的UDP Flood或混合型大流量攻击时防火墙本身就是瓶颈CPU先被打满整个网络就瘫痪了。大流量攻击必须在防火墙上游处理好而不是依赖防火墙硬扛。误区二带宽够大就不怕DDoS。带宽只是其中一环服务器的处理能力、应用代码的效率、数据库连接池的设置、CDN节点分布等都会影响抗攻击效果。100Gbps带宽的服务器如果应用层有一个极其消耗资源的接口被打爆照样会挂。误区三防御规则越严格越好。有些团队一遇到疑似攻击就疯狂封IP结果误封率高得吓人。尤其是移动网络用户很多出口IP是运营商共享的一个误封可能导致几百上千个正常用户无法访问。封禁尽量精确到IP端口或IPURL特征并把封禁有效期设置成有限时间。还有一些容易忽略的细节源站IP泄露是最大的软肋。攻击者只要拿到源站IP绕过高防直打源站再大的防护也是白搭。建议源站防火墙配置只允许高防节点的回源IP访问其他来源一律拒绝。留意DNS解析记录。如果域名用了高防IP但历史DNS记录或子域名的解析不小心暴露了源站IP同样等于裸奔。定期检查开放端口。服务器上不必要的端口尽量全部关闭特别是数据库、Redis、SSH等端口不要暴露在公网。攻击者扫描到开放端口后会优先冲着这些“软柿子”打。高防产品的回源带宽也要关注。即使高防清洗了攻击流量回源到源站的流量依然是正常流量的若干倍源站本身的带宽和性能不能太差否则清洗后的流量也接不住。7.4 更持久的安全运营节奏DDoS攻击不是一个一次性的项目而是一个长期对抗的过程。防御策略需要随着业务体量、攻击手法和自身架构的变化持续迭代。我个人的建议是每季度做一次防御体系复盘。复盘内容包括新业务上线后有没有增加新的攻击面过去一个季度的攻击数据进行过没有高防产品的防护能力是否还匹配当前的业务峰值WAF规则有没有及时更新源站IP有没有新的泄露途径同时关注安全圈的报告和动态了解最新的攻击手法和工具趋势把这些信息转化成自己的防护规则。持续运营层面下面几件事值得坚持做建立资产清单。知道自己有哪些公网IP、域名、端口、API接口这一份清单是所有防御动作的基础。很多公司业务扩张后连自己暴露了哪些资产都不知道防御自然无从谈起。定期做模拟演练。每隔一段时间用合法的压力测试工具对测试环境做一次攻击模拟检验防御规则、应急流程和团队协同是否顺畅。演练记录是持续改进的依据。制定备份和恢复方案。即使防御做得很到位也要假设最坏情况发生。关键数据包括数据库、配置文件的备份机制必须独立可靠恢复时间目标要明确写在应急预案里。和云服务商的应急团队保持联系。在攻击发生前建立好沟通渠道比事发后到处找人要高效得多。从实践来看DDoS防御的复杂度并没有想象中那么高真正难的是持续地保持警惕、及时更新防御规则、在危急时刻沉着应对。只要把基础设施选对、基础参数调优、应用层限流做好、监控告警到位绝大多数中小型业务完全可以把DDoS造成的影响控制在可接受范围之内。最后分享一点我个人的体会网络安全这个行当见多了攻击案例之后会明白一个道理——最关键的往往不是某项技术有多先进而是你能否在攻击来临之前就把该做的准备都做了。防御DDoS不是什么高深莫测的事它就藏在一个个具体的配置、一条条监控告警、一次次应急演练里。把这些基本功做扎实比追求任何“黑科技”都管用。