1. 什么是DDoS攻击——先搞懂它到底干了什么做了这么多年线上业务和网络安全我见过太多“网站突然打不开”的场面监控大屏全线飘红用户群里骂声一片运维慌慌张张地跑到机房结果发现既不是代码上线出Bug也不是数据库连不上而是流量入口被一股来路不明的请求浪潮彻底堵死。这个场景就是DDoS攻击最典型的“作案现场”。DDoS攻击全称是Distributed Denial of Service中文叫分布式拒绝服务攻击。它干的事情说白了就是用海量的伪造请求把目标服务的资源全部耗尽让正常的用户无法访问。注意“分布式”这三个字——它不是一台电脑在搞事而是攻击者操控成千上万台设备同时发起请求从四面八方涌向同一个目标。你可以把它想象成一家餐厅门外挤进来几百个根本不点餐的人把每个座位都占满堵住门口真正的客人连门都进不去。老板看着满屋子人头客人却一个也服务不了营业额直接归零——这就是DDoS攻击的效果。这篇文章我会把DDoS攻击从原理到防御整个链路讲透包括攻击流量到底是怎么构造的、为什么会造成这么大的杀伤力、常见攻击类型有哪些、以及作为开发者和运维可以怎么一步步扛住这些攻击。不管你是刚接触网络的零基础新手还是在线上业务扛过几次真实攻击的从业者这篇都值得你花点时间慢慢看。1.1 从DoS到DDoS只多了一个字母破坏力却是天壤之别要理解DDoS先得从它的前身DoS说起。DoSDenial of Service是拒绝服务攻击单台机器对单台服务器发起攻击。比如我开一台电脑不断向你的网站发送连接请求如果你的服务器配置不高确实也可能被拖垮。但问题是——单台机器的网络带宽和系统资源是有限的而服务器的性能也在不断提升一台电脑撑死了也就几百兆带宽、几万个并发连接现在稍微好一点的服务器都能轻松抗住所以纯单机DoS已经很难造成实质威胁。DDoS的可怕之处在于“分布式”三个字。攻击者不会只用一台电脑而是先通过各种手段控制一大批“肉鸡”——也就是被植入木马或后门的普通电脑、服务器甚至摄像头、路由器等联网设备组成一个僵尸网络Botnet。发起攻击时攻击者一声令下成百上千甚至几十万台设备同步向目标发送流量这个规模就完全不是单机能比的了。做个对比你就明白了假设一台服务器的处理能力是每秒接待1万个客人。DoS攻击像是叫一个人每秒敲1万次门服务器还能应付而DDoS是叫一万个人同时每秒敲一万次门也就是每秒上亿次的请求量涌过来服务器、带宽、防火墙、负载均衡器全都会被瞬间压垮。更麻烦的是这上万台设备来自天南海北真实IP分布在全球各地你拉黑一批IP剩下还有九千多批根本封不过来。从防护角度来看DoS你封掉那个攻击源IP就完事了DDoS则意味着攻击源分布在成百上千个网段有些还借用了公共基础设施来放大流量处理难度完全不在一个量级。这就是为什么很多公司在DoDDoS面前连挣扎的机会都没有几十Gbps的流量一灌进来机房上联交换机直接就断掉了。1.2 DDoS攻击的三要素谁在打、用什么打、为什么打理解DDoS攻击的构成抓住三个核心要素就够了。第一要素是攻击源。DDoS是“人多力量大”但攻击者自己绝不会暴露真实IP。他们通过僵尸网络操控海量“受控设备”。这些设备平时正常上网用户毫无察觉但早已被木马程序接管。攻击指令下达时这些“肉鸡”就成了免费的攻击武器。还有一类攻击源更隐蔽——反射放大服务器。攻击者向互联网上大量开放的DNS服务器、NTP服务器发送源IP伪装成受害者的查询请求这些服务器响应时会把放大后的流量发到受害者头上。这类攻击源本身是正常业务服务器它们“无罩”地参与了攻击受害者想溯源都很难。第二要素是攻击载荷。流量也好、请求也罢总得有具体的内容。常见的载荷有直接灌带宽的UDP大包有专门消耗连接表的SYN报文还有伪装成正常用户请求的HTTP GET/POST。不同类型的载荷打击的是目标不同层面的资源后文我会逐个拆解。第三要素是攻击目标与动机。游戏行业被打是因为竞争对手雇人搞事电商平台被打是因为大促前有人敲诈勒索金融类网站被打可能是因为黑产想要报复或者转移视线。当然也有纯粹炫技的“脚本小子”拿着网上现成的攻击工具乱打一气。搞清楚动机有助于判断攻击的持续时间和强度——勒索型攻击通常比较猛烈但持续时间不会太长同行恶意竞争则可能反复出现防不胜防。2. DDoS攻击原理深度拆解——流量是怎么“合法”打瘫业务的很多零基础的朋友总觉得DDoS很玄乎好像攻击者有什么厉害的黑客技术。实际上DDoS攻击的原理并不复杂它抓住的其实是互联网基础设施一个非常本质的弱点任何服务器的资源和处理能力都有上限而互联网上的请求几乎不需要成本。2.1 资源有限、请求无限一句话说透DDoS的本质假设你有一个非常优秀的客服团队每天能处理1万个电话。正常情况下每天来电5000个大家轻松应对。但如果有一天突然打进来100万个电话呢即使每个电话都是真的客服也接不过来电话系统直接瘫痪更狠的是这些电话里大部分还是接了就挂断的骚扰电话客服全被无效通话占住真正有问题的客户反而永远排在队列后面。服务器的运作逻辑完全一样。它每天能处理的连接数量是固定的CPU能计算的指令是固定的带宽能传输的数据量也是固定的。攻击者不需要攻破你的系统不需要窃取你的数据只需要让服务器的处理能力全部浪费在垃圾请求上就能达到“瘫痪”的目的。这就像你锁好了家门窗户也装了防盗网但攻击者每天在你家门口堆放几百吨垃圾让你出不了门——他没有破门而入却达到了让你无法使用房子的目的。理解了这个本质你就能明白为什么DDoS这么难彻底防御它不依赖任何系统漏洞而是滥用互联网最基本的开放和自由原则。你的服务器本来就该响应外部请求否则互联网服务就不成立而攻击者利用的恰恰就是这个“该响应”的逻辑让请求量大到超出你的处理上限。2.2 三大资源瓶颈带宽、连接表、应用处理能力DDoS攻击按照“打击目标”可以分成三类资源消耗模型理解了这三个模型就理解了DDoS的几乎所有分支。第一类是带宽资源。服务器的网络链路就像一条水管单位时间内能流过的数据是有限的这叫带宽。攻击者不断向目标发送大流量数据包把水管彻底堵满。比如你独享10Gbps的带宽攻击者给你塞20Gbps的流量多出来的10Gbps怎么办要么在你的机房上联口排队造成整条链路延迟飙升要么直接被运营商丢弃而丢弃的往往也包括正常用户的数据包。这时候最典型的表象就是服务器CPU正常、内存正常、负载正常但业务彻底不可用——因为请求根本进不来全卡在网络层。第二类是连接表资源。这是很多业务运维容易忽略的点。服务器处理TCP连接时需要在内核里维护一张连接状态表记录每个连接的IP、端口和状态。这张表的大小是有限的一般Linux服务器默认能存几万个半连接状态超过这个数量新连接就直接丢弃。SYN Flood就是专门冲着这里来的——伪造大量源IP发TCP握手请求每次都只发第一步就消失服务器傻傻地等在第二步连接表瞬间爆满之后所有正常用户的连接请求都进不来了。第三类是应用处理能力。这类攻击的目标是服务器上跑的业务程序比如PHP、Java、Python进程或者数据库。攻击者发送大量看似完全正常的业务请求——比如查询商品详情、调用转账接口——但频率极高。服务器的CPU满负荷运转、数据库连接被占满、Redis缓存穿透应用就慢慢卡死。这类攻击最阴险的地方在于单个请求完全合法没有明显的恶意报文特征传统防火墙根本拦截不住。2.3 经典原理实例SYN Flood是怎么把服务器“堵死”的TCP三次握手是互联网通信的基础而SYN FloodSYN洪水攻击是DDoS攻击里最经典、也最容易被新手理解的一种我详细讲讲它的完整过程。正常情况下的TCP握手是这样三步客户端发一个SYN包第一步表示“我要连接”服务器回一个SYN-ACK包第二步表示“收到同意连接”客户端再回一个ACK包第三步表示“好我们建立连接”。第三步完成后连接才算真正建立双方才开始传数据。SYN Flood攻击的“智慧”在于它只做第一步永远不完成第二步。攻击者伪造大量不存在的源IP地址向服务器疯狂发送SYN包。服务器收到后会为每个SYN包在内存里分配一个半连接状态并发出SYN-ACK包等待对方回复。问题是这些源IP全是假的永远不可能有ACK包回来。服务器默认会等好几秒甚至几十秒才超时清除这些半连接而新来的SYN包还在源源不断地进——每秒钟几万个假SYN包进来几万个半连接占着内存和表项很快连接表就被塞满了。一旦半连接队列满了服务器对后续的所有SYN包都会直接丢弃不管你是正常用户还是攻击流量。这个时候从用户角度看网站就是“连不上”从服务器角度看CPU和内存其实还有余量但新连接一个都进不来。特别典型的检查方式是执行ss -tunap | grep SYN_RECV | wc -l如果这个数字持续上涨并逼近系统限制基本可以判定被SYN Flood打了。为什么这么简单的攻击至今依然有效因为TCP协议本身设计于几十年前当时的设计目标是可靠通信根本没有考虑恶意攻击的场景。后来有了SYN Cookie技术简单说就是服务器收到SYN后不再为它分配半连接内存资源而是用Cookie的方式记录状态直到收到合法的ACK才恢复连接状态——这才算给SYN Flood的伤害打上了一块补丁。具体配置我在防御章节会给出参数。3. 攻击分层详解——不同层级的DDoS各有各的打法DDoS攻击不是单一技术而是按攻击发生的协议层级有一条完整的谱系。我习惯把它分成三大类体积型、协议型、应用层。它们在攻击效果、检测难度和防御手段上差别很大挨个说清楚。3.1 体积型攻击用天文数字的流量硬生生砸瘫链路体积型攻击英文叫Volumetric Attack目标是前面说的第一类资源——带宽。攻击者拼的是“量”用UDP Flood、ICMP Flood、DNS放大、NTP放大等手段把目标带宽彻底塞满。UDP Flood是最简单粗暴的向目标服务器的随机端口发送大量UDP数据包。服务器收到后会逐个检查有没有对应的应用程序在监听没有就回复ICMP不可达。攻击流量本身加上回复流量双向消耗带宽和系统资源。DNS放大攻击则利用了公网DNS服务器的“好心”。攻击者构造一个源IP伪装成受害者的查询请求例如查询一个很大的TXT记录发送给互联网上大量开放的DNS服务器。这些DNS服务器会把查询结果回传给受害者而响应包通常比查询包大几十倍甚至上百倍。攻击者用1Mbps的上行带宽就能让DNS服务器产生100Mbps甚至更多的流量灌向受害者这就是“放大效应”。NTP放大攻击原理类似用的是NTP时间同步协议的monlist命令放大倍数比DNS还高。这类攻击的检测相对容易——流量曲线呈脉冲式暴涨时间跨度可能就几分钟到几十分钟。但防御却很难因为当流量超过你带宽的几十倍时流量根本还没来得及到你的服务器就在运营商的骨干网里把你端口“灌死”了。应对手段一般是联系运营商或者云厂商做黑洞路由或者流量清洗后文细说。3.2 协议型攻击玩弄协议规则让服务器自己把自己累死协议型攻击Protocol Attack的目标是前面说的第二类资源——连接状态表以及防火墙、负载均衡器等网络设备的处理能力。它们利用的是协议设计中的逻辑漏洞攻击流量本身不大但能造成极大的资源消耗。SYN Flood刚才已经详细讲过是协议型攻击的代表。ACK Flood则是发送大量ACK包给目标服务器服务器需要逐一查询连接状态表中对应的连接查不到就直接丢弃或回复RST包白白浪费CPU时间。TCP连接耗尽也很常见——攻击者控制真实IP通常是感染僵尸网络的肉鸡和目标服务器建立真实、完整的TCP连接把连接数撑满。因为有真实握手这类请求从协议角度看完全合法硬件防火墙很难识别只有等连接表满了才发现问题。还有一类容易被忽略的分片包攻击Fragmentation Attack攻击者发送大量畸形的IP分片包让服务器在重组分片时耗尽CPU和内存。这类攻击不追求流量大小追求的是计算资源的浪费检测起来也比流量型攻击难得多。3.3 应用层攻击伪装成“正常用户”慢慢折磨业务应用层攻击也就是平时大家常说的CC攻击Challenge Collapsar源自早期一款防护产品后来成了这类攻击的通用叫法是目前最主流也最难防的DDoS类型。它的目标是前面说的第三类资源——应用服务本身攻击特征最不明显。攻击者不拼流量拼的是“有效的业务请求”。比如你做一个电商网站攻击者直接高并发请求“搜索商品”接口、反复调用“提交订单”接口、疯狂刷新“获取短信验证码”接口。每个请求都合法都有完整的HTTP头、合理的User-Agent甚至还会带Cookie。如果是人工模拟的CC攻击请求频率可能只有每秒几百次服务器从CPU、带宽上都看不出任何异常但业务就是响应越来越慢、数据库连接池被耗尽、日志文件疯狂膨胀。更狠的是慢速攻击例如Slowloris攻击者建立连接之后故意分多次慢慢发送HTTP请求头每隔几十秒发一小段让服务器一直保持着连接等待数据。Apache这类服务器默认对每个空闲连接都有超时时间但Slowloris通过在超时前续上一段数据让连接永远不算超时。一个攻击者几千个连接就能把Apache的并发连接数撑满正常用户根本挤不进来。三种攻击类型各有各的“打法”我整理了一张表方便大家对照攻击类型代表攻击方式资源消耗目标检测难度防御侧重体积型UDP Flood、DNS/NTP放大链路带宽较容易流量曲线暴涨带宽冗余、流量清洗、黑洞路由协议型SYN Flood、ACK Flood连接表、网络设备CPU中等会话状态异常SYN Cookie、连接数限制、防火墙策略应用层CC攻击、Slowloris应用CPU、数据库连接困难请求看似正常WAF、限流、行为分析、验证码实际攻击中攻击者经常会多管齐下先用体积型攻击打掉你的带宽再用应用层攻击折磨你的业务让运维人员手忙脚乱。如果你的服务器扛住了第一波流量型攻击紧接着要立刻检查应用层的状态因为真正的杀招往往在后面。4. 不违法的DDoS实验——搭个本地环境亲手看攻击过程学习DDoS最有效的办法不是看多少篇文章而是亲手做一次实验。很多人一听“DDoS实验”就想到攻击别人这是完全错误的理解。所有实验都必须在你自己可控的本地环境里进行目的是搞清楚攻击流量长什么样、服务器资源是怎么被耗尽的这样才能在真实攻击发生时第一时间做出正确判断。4.1 搭建最小测试环境最简单的做法是准备两台Linux虚拟机用VirtualBox装CentOS或者Ubuntu都行或者直接用一台性能还行的笔记本跑两个容器。一台当“受害者”一台当“攻击者”中间通过虚拟化网络连接。受害者这台装一个Web服务器推荐Nginx因为安装简单、日志清爽。装好以后访问默认页确认能正常打开。apt install nginx -y systemctl enable nginx systemctl start nginx curl http://127.0.0.1/如果看到Nginx的欢迎页说明基础环境就绪。接下来先给系统装几个排查工具后面要用apt install htop tcpdump dstat -y我特别建议第一次实验时把带宽监控工具也装好比如用nload能直观看到网卡流量变化。你用一个终端跑nload另一个终端跑压测能非常直观地看到攻击流量灌进来时网卡使用率从百分之几直接飙到接近100%。4.2 用压测工具模拟攻击流量注意这里说“模拟”而不是“发起攻击”核心区别在于目标地址是127.0.0.1或者你自己虚拟机的内网IP。用工具制造的请求量让服务资源耗尽观察过程这就是合法、安全的实验。用abApacheBench来模拟应用层的高并发请求是最简单的apt install apache2-utils -y ab -n 100000 -c 1000 http://127.0.0.1/这条命令的意思是对本地Web服务器发起10万个请求同时保持1000个并发。实验前先记录一下正常情况下的响应时间和吞吐量比如正常时Time per request可能在10毫秒左右。实验过程中你会看到响应时间迅速恶化从10毫秒涨到几百毫秒甚至最终超时。如果想模拟更接近真实SYN Flood的效果可以用hping3hping3 -S -p 80 --flood 127.0.0.1-S表示发送SYN包--flood表示尽可能快地发送。注意这条命令需要root权限而且这个实验绝对不能对公网IP执行——哪怕是对着别人一台完全不用的测试机也不行因为这已经构成违法行为了。所有实验必须严格控制在本机或你完全拥有的虚拟机内部网络里。4.3 观察资源崩溃的过程实验做完了最关键的环节是“看过程”。模拟应用层攻击时我建议你在另一台终端跑htop和dstat观察以下指标的变化CPU usage——如果Nginx是单worker配置CPU使用率会冲到100%TCP连接数——用ss -tunap | wc -l查看总量变化Nginx访问日志——tail -f /var/log/nginx/access.log你会看到请求暂停在连接的建立阶段很多请求根本没形成访问日志平均负载——uptime或者cat /proc/loadavgload值会显著上升实验结束后停掉压测工具过几分钟再访问Nginx页面通常服务会自行恢复。这说明攻击过程只是耗尽了资源没有破坏服务器本身。这也是DDoS攻击的一个重要特性它属于破坏可用性而不是破坏数据完整性服务停止后往往不需要重启就能自动恢复。用hping3模拟SYN攻击时重点观察半连接队列的变化ss -tunap | grep SYN_RECV | wc -l cat /proc/sys/net/ipv4/tcp_max_syn_backlog正常情况下列表里的SYN_RECV数量小于100攻击开启后这个数字会飙升到几千甚至上万直到触达tcp_max_syn_backlog的上限。踩过这个坑以后再去看生产环境的告警指标你一眼就能分辨出是不是SYN Flood。顺便说一句实验做完要把虚拟机快照恢复一下或者把压测工具卸载掉免得留着这些工具在环境里成为安全隐患。5. 防御体系与实操配置——从上线前到被攻击后的完整闭环DDoS防御没有办法“买一个设备就一劳永逸”——因为它对抗的是一群分布在全球的攻击者而你的防御资源总是有限的。但做好分层防御、提前准备预案可以把攻击的影响范围压到最小。我把防御经验分为事前、事中、事后三段来说每一段都有可以直接抄的配置。5.1 事前防御把攻击面缩到最小把系统底子打硬首先做“降维”——减少暴露面。你的网站域名有DNS、有Web端口80/443、有服务器IP地址这些都是攻击者可能的入口。但是如果所有流量都经过CDN源站IP不暴露攻击者就只能打CDN的边缘节点而CDN天然就是分布式架构带宽和节点都是海量的大流量攻击打到CDN上往往会被分散掉。很多业务被DDoS打穿不是因为没上CDN而是因为源站IP泄露了——比如直接用IP访问的测试链接被搜索引擎收录、历史DNS记录还留着源站IP、或者邮件头里暴露了服务器IP。所以上线前建议做一次源站IP清理全站只用域名访问、关闭服务器对外发邮件、隐藏后台登录入口。然后是系统加固。针对SYN Flood调整内核参数非常有效这几项是我在生产环境实测过、可以放心用的# /etc/sysctl.conf net.ipv4.tcp_syncookies 1 // 开启SYN Cookie半连接队列满时保护服务 net.ipv4.tcp_max_syn_backlog 8192 // 加大半连接队列让服务器能扛更多突发 net.ipv4.tcp_syn_retries 1 // 减少SYN重传次数快速丢弃无响应的半连接 net.ipv4.tcp_tw_reuse 1 // 复用TIME_WAIT状态的连接执行sysctl -p生效。开了SYN Cookie之后即使半连接队列满了内核依然能处理新的SYN请求代价是稍微增加一点CPU计算量一般可以忽略不计。应用层限流也得提前配好。Nginx的limit_req模块是限流的好手按IP维度限制请求速率效果立竿见影limit_req_zone $binary_remote_addr zoneapi_limit:10m rate5r/s; server { location /api/ { limit_req zoneapi_limit burst20 nodelay; } }这段配置的意思是每个客户端IP访问/api/路径时平均每秒最多5个请求允许瞬时最多20个请求排队。实际使用中rate和burst要根据自己的业务峰值来调调得太紧会误伤正常用户调得太松起不到限流效果。我一般建议先观察一周正常流量曲线按峰值的1.5倍设置rate再留一个比较大的burst应对突发流量。5.2 事中处置在攻击已经发生时稳住局面先确认是不是DDoS。攻击来了第一步不是忙着拉黑IP而是快速判断“这是不是DDoS、攻击类型是什么”。有三个指标可以快速确认执行ifstat或者看云厂商监控入方向带宽是否异常暴涨执行ss -state established | wc -l和ss -state syn-recv | wc -l连接数是否远超正常值执行uptime看负载是否暴涨但CPU大部分被软中断占用如果带宽爆了、连接数爆了、负载也爆了那基本就是DDoS没跑了。先不要急着在服务器上封IP——当攻击流量几百Gbps灌过来的时候流量在运营商骨干网就已经把你端口塞满了你封IP根本来不及服务器连命令都执行不利索。紧急联动的两个方向一是联系云服务商或机房启用黑洞路由RTBH和流量清洗。黑洞路由简单说就是让运营商把发到你IP的流量直接丢到“黑洞”里你的服务器瞬间恢复负载但代价是正常流量也一起丢了相当于“断臂求生”只适合攻击流量已经超过你能承接的上限时用。流量清洗则是把流量引流到清洗设备上清洗设备通过特征过滤掉攻击流量再把干净的流量转发回你的服务器这是目前最主流的DDoS缓解手段但需要提前和云厂商开通服务临时开通往往来不及。二是在服务器上做应急防护。如果攻击流量还在你带宽能承接的范围比如几Gbps可以尝试在防火墙层做限制。以下是几个常用命令# 封掉单个攻击IP iptables -A INPUT -s 1.2.3.4 -j DROP # 限制每个IP的并发连接数不超过100 iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 100 -j DROP # 限制特定端口每秒新连接数 iptables -A INPUT -p tcp --syn --dport 80 -m limit --limit 100/s -j ACCEPT注意这些命令只是应急手段如果攻击源IP是伪造的或者分布在千万个真实IP上封IP的效果很有限。真正兜底的还是云厂商的大流量清洗能力——你本地防火墙永远拼不过带宽型攻击。5.3 事后的复盘与溯源攻击停止了不代表事情就结束了。我的习惯是攻击过后一定做完整复盘至少有五件事要干第一保存攻击证据。包括流量监控图、防火墙日志、CDN日志、服务器访问日志这些既是溯源的基础也是如果后续需要走法律途径时的证据。第二分析攻击特征。翻看攻击时段内的日志回答几个问题主要攻击类型是什么带宽型还是CC攻击源IP分布在哪攻击目标端口是哪个攻击包有什么共同特征比如固定User-Agent、固定请求路径这些信息能帮你完善防火墙规则和WAF策略。第三修复暴露面。攻击进来了一定是有原因的。检查源站IP是否泄露、防火墙是否有漏洞、WAF规则是否有可绕过的地方把所有问题在下次攻击前修掉。第四调整监控阈值。被攻击前可能带宽告警阈值设得太高导致攻击发生后十几分钟才被发现。把监控阈值调低比如带宽超过正常值的80%就告警并且把自动告警和自动引流联动起来能做到攻击开始时第一时间切换流量清洗模式。第五做一次攻防演练。模拟一次小规模DDoS攻击让值班人员实际操作一遍应急处置流程。没演练过的预案等于没有预案——真出事的时候大家全在蒙圈。6. 常见问题与排查技巧实录做了这么多年安全相关的活儿经常被问到一些和DDoS相关的细节问题我挑几个典型的整理成表格后面详说问题一句话答案网站突然变慢怎么判断是不是被DDoS了看三个指标入带宽是否暴涨、SYN_RECV是否异常、负载是否飙升攻击流量里的IP是真的吗协议型攻击多为伪造IP应用层CC攻击大多来自真实肉鸡IP上了CDN为什么还是被打大概率是源站IP泄露或者攻击打的是CDN回源链路带宽买大一点就能防住DDoS吗买再多带宽也不够关键是清洗能力和快速调度能力被攻击时怎么最快恢复业务启用高防IP或黑洞路由先把总线保住再慢慢清洗为什么有些攻击流量通过了防火墙应用层攻击的流量和正常请求无法靠防火墙特征区分问题一如何快速区分DDoS和业务代码Bug导致的故障这是运维最怕搞混的场景。曾经有人业务接口变慢排查了一天业务代码最后发现是半夜被人打了同步流量。区分方法其实很简单——业务问题通常表现为CPU或数据库慢但网络入流量是平稳的DDoS攻击则是网络层指标首先异常。建议优先看云监控的“公网入带宽”和“连接数”两个指标如果入带宽从平时10Mbps突然跳到2Gbps基本可以放弃排查业务代码了。问题二什么是高防IP和CDN有什么区别很多刚接触的人会把两者搞混。CDN的核心能力是内容缓存和加速把静态资源分发到离用户最近的节点它能扛掉一部分带宽型攻击但遇到针对源站的CC攻击就力不从心。高防IP则是一个“流量清洗入口”所有流量先经过高防机房的清洗集群把攻击流量过滤掉后才转发到你的源站。一般高防IP产品会提供若干防护峰值比如10Gbps、50Gbps、100Gbps超过这个峰值就会触发黑洞。建议的做法是CDN和高防IP配合使用CDN挡在业务最前面高防IP做第二道防线源站藏在最深处。问题三攻击源分布在国外拉黑国外的IP就行吗这要分场景。如果业务只服务国内用户拉黑海外IP是可行的权宜之计很多防火墙支持按国家/地区IP库做策略。但现在攻击者用全球分布式的僵尸网络国内也有很多肉鸡单纯靠地域封禁既挡不住所有攻击还可能误伤海外华人用户。我碰见过一个被攻击的跨境电商就因为着急封了一大批海外IP第二天损失了相当一部分海外客户——所以地域封禁要慎用。问题四被攻击时能不能不给攻击者钱但是又尽量保住业务这个问题的答案取决于你的防御纵深。我见过最快恢复业务的案例攻击流量超过100Gbps秒级触发高防IP黑洞。但黑洞之后业务全停。对方的处理方式是在DNS层面加了一条备用线路的解析——主IP黑洞期间流量被调度到备用服务的IP业务没有间歇。这个操作的前提是提前做了多活架构和DNS容灾否则临时想调度也来不及。7. 写在最后的一些经验我职业生涯里处理过的DDoS攻击不算少从早期的游戏私服到后来的云上电商平台从几Gbps的小打小闹到上百Gbps的暴击踩过的坑比看过的文档都多。如果让我给刚接触这块的朋友一句最重要的建议那就是DDoS防御不是一个技术方案而是一套运营机制。技术方案很容易买到——云厂商的高防IP、WAF、CDN这些花钱就有。难的是把方案接入到你的业务架构里并做成自动化的运营闭环监控要自动告警、流量要自动调度、清洗要自动触发、源站要自动切换。这一套流程如果靠人盯攻击发生最宝贵的几分钟全都浪费在打电话和等确认上等你想明白要干什么业务已经挂了很久了。我个人还有几个小原则分享出来供参考所有系统上线前都要做一次最小规模的DDoS演练哪怕是往自己测试环境灌几Gbps的流量让值班人员真真切切感受一次告警、调度、恢复的过程。只有演习过真打起来才不会慌。不要迷信“买了高防就万事大吉”。高防有防护峰值超过峰值照样黑洞高防IP的IP地址可能被攻击者提前探测到源站真实IP然后直接绕过高防打源站。日志和监控数据的留存时间至少半年。有些攻击是间歇性的打两天停一天没有历史数据你根本发现不了规律。DDoS攻击看起来轰轰烈烈本质上就是一场资源和耐心的消耗战。攻击者花很小的成本就能制造很大的麻烦而防守方要花成倍的代价去加固每一层防线。这篇文章把它的原理、攻击方式、实验方法和防御思路都过了一遍真正上战场前建议你还是拿自己的业务环境多做几次压力测试把防御手段真正练熟。毕竟只有千日做贼没有千日防贼的道理——防得住的前提是你在攻击到来之前早已准备好。