业务突然卡顿、用户大面积反馈打不开页面、后台监控曲线直接拉满——这套流程跑过线上业务的人都不陌生。但这里有个容易栽跟头的判断误区把所有的访问异常都当成DDoS或者反过来明明是DDoS却当成普通流量高峰处理。判断是否遭遇DDoS攻击核心不是看流量大小而是看流量的“行为特征”。这篇内容我把最常见的四种特征整理出来都是可以直接在监控、日志、接入层快速核验的硬指标不需要依赖复杂的安全设备哪怕只有一台服务器和一台路由器也能做出八九不离十的判断。适合谁看维护过线上业务、被突发的流量波动折腾过、或者正在搭建基础监控体系的人。内容不涉及商业安全产品的具体用法全部基于通用网络原理和常见开源工具看完可以直接对照自己的环境做排查。1. 判断DDoS的第一步先分清故障类型很多人一看到带宽跑满就喊DDoS其实先别急着下结论。线上业务的访问异常通常分三类网络层故障交换机、光缆、路由问题、服务器层故障CPU、内存、数据库连接数耗尽、应用层故障代码Bug、依赖服务超时。DDoS攻击只是导致这三类故障的其中一种原因甚至很多时候攻击者只是“点火”真正把系统搞垮的是资源配置不合理或者代码健壮性差。所以判断是否遭遇DDoS攻击第一个动作不是查攻击特征而是确认故障的范围和性质。先回答四个问题是全站不可用还是部分区域不可用是持续不可用还是间歇性不可用是只有动态请求受影响还是静态资源也受影响是用户侧反馈异常还是监控系统主动告警这四个问题的答案能帮你快速缩小排查范围。比如全站不可用且静态资源都加载失败大概率是网络层或者带宽被塞满如果是只有登录接口超时、静态资源正常那更像应用层问题。DDoS攻击的特征从网络层到应用层都有不同层级的攻击对应的排查手段完全不同先定位故障层级再判断是否遭受DDoS思路才会清晰。这里有一个实践中的判断技巧用三个时间点做对比——攻击前的正常基线、异常出现时的峰值、异常结束后的回落情况。DDoS攻击的特征之一是流量“来得快、去得也快”攻击停止后流量通常会迅速回落。如果流量是缓慢爬升又缓慢下降那更像是业务自然增长或爬虫抓取导致的波动。2. 四种高辨识度特征一查便知的判断依据判断是否遭遇DDoS攻击真正管用的其实就四种特征。这四种特征分别对应不同攻击层级组合起来基本能覆盖95%以上的DDoS场景。每一条都可以通过自有监控、流量工具或日志系统来验证不需要额外采购设备。2.1 特征一流量曲线呈“断崖式”突增且来源IP高度集中DDoS攻击最直观的特征是流量曲线的形态异常。正常业务流量增长是渐进的有白天晚上的自然波动有促销活动带来的脉冲式增长但无论哪种流量曲线都是连续且可解释的。DDoS攻击不同——攻击流量通常会在几十秒内完成爆发式增长曲线像被刀切了一样从正常水平直接拉满到带宽上限。这个特征的操作性在于打开流量监控图看异常发生前的基线值、异常时的峰值、异常持续的时间。真正的DDoS攻击流量上升时间通常小于5分钟峰值流量是基线的几倍甚至几十倍。如果是正常业务高峰流量上升过程至少以小时为单位。来源IP的分布是另一个硬指标。常规业务流量的来源IP必然分散符合用户地理位置的自然分布。DDoS攻击的流量来源则高度集中——可能是某个IP段、某个机房段、某个国家的地址段。验证方法很直接把异常时段的访问日志按来源IP做聚合统计如果Top10的IP贡献了超过50%的流量基本可以判断流量成分不正常。我在实际排查中见过一个典型案例某业务高峰期流量突然翻了8倍最初被当成业务增长。后来拉取访问日志按IP聚合发现单个IP在5分钟内发起了超过20000次请求而正常用户几乎不会在5分钟内请求超过100次。IP集中度这个指标是区分DDoS攻击和正常突发流量的第一道分水岭。2.2 特征二请求特征异常集中在单一目标或特定协议DDoS攻击不管层级的差别背后都有一个共同点攻击者要最大化消耗目标资源所以攻击流量一定会集中在特定目标上——某个URL、某个API接口、某个页面或者某些协议类型。正常用户访问路径是发散性的有人看首页、有人看详情页、有人提交表单请求分布相对均匀。DDoS攻击的请求分布则高度聚焦。判断方法在Web服务器日志里按URL维度统计请求分布。如果异常时段内单个URL的请求占比异常升高比如超过总请求的70%而这个URL平时占比不到10%就需要警惕。很多DDoS攻击工具默认只打主页或固定路径请求特征非常明显。协议维度的判断也很有价值。如果流量主要消耗在TCP三次握手表现为大量SYN报文、半连接数暴涨属于SYN Flood攻击如果UDP流量异常增大且目标端口集中在少数几个端口属于UDP Flood攻击。这些在接入层交换机或服务器的连接状态统计里都能直接看到。我建议的做法是在Nginx或Apache日志里临时增加按$request_uri、$http_user_agent、$http_referer三个维度的实时统计持续观察10分钟。如果统计结果呈现高度集中的趋势就说明流量成分不自然大概率是攻击流量。2.3 特征三连接与协议行为异常明显不符合正常用户习惯这一条是最容易被忽视的但对判断攻击类型最有帮助。正常用户的访问行为遵循一定的规律先请求HTML页面再请求页面里引用的CSS、JS、图片资源每个连接发起的请求数有限请求间隔是秒级或毫秒级但访问总量与页面资源数匹配。DDoS攻击的协议行为完全不是这样。常见的不符合正常习惯的行为包括单个连接在极短时间内发起大量请求正常浏览器一个连接最多同时处理6个请求请求间隔时间极短且非常有规律正常用户有思考时间请求的HTTP头不完整或内容异常缺少User-Agent、Accept等常规字段大量请求使用相同的User-Agent或使用明显改动的UA值。判定方法可以量化为三个指标。第一连接数与请求数的比例正常业务一个连接通常对应2~10个请求攻击流量往往一个连接一个请求或一个连接对应几十上百个请求。第二请求的时间间隔分布正常业务的请求间隔呈自然分布攻击请求的间隔高度均匀。第三HTTP头完整率正常浏览器请求都会带完整的头信息攻击工具为了提升发包速度经常省略非必要字段。实操中可以用一条命令快速统计当前TCP连接状态netstat -ant | awk {print $6} | sort | uniq -c | sort -n如果SYN_RECV状态的连接数远高于ESTABLISHED说明有大量连接卡在三次握手阶段这是SYN类的攻击特征。正常服务器上SYN_RECV的连接占比很低且会快速完成握手转为ESTABLISHED或直接关闭。如果SYN_RECV积压持续不降且数量达到系统最大连接数限制基本可以认定为SYN Flood攻击。2.4 特征四业务指标与流量指标严重偏离这一条是判断是否“被攻击打趴下”的最核心依据但很多人会忽略。正常业务场景中流量增长通常伴随业务指标同步增长——流量翻倍订单数也应该增长CPU使用率上升但仍在合理范围响应时间可能略有增加但整体可用。DDoS攻击场景则完全不同流量暴涨但业务指标不涨反跌。具体表现为带宽占用从100M涨到800M但单位时间的有效请求数没增加甚至下降CPU使用率打满但处理的业务逻辑请求数没有同步上涨页面响应时间从200ms涨到10秒以上但并发用户数没有真实增长。这里需要特别留意应用层DDoS攻击的特征是流量不明显、但业务指标剧烈恶化。攻击者模拟真实用户的请求行为每次请求都消耗大量服务端资源比如复杂的数据库查询、加密解密计算单个请求的体积不大但每个请求都让服务器“做重活”。这种攻击最阴险因为流量层面看不出异常只有深入业务指标才能发现。判断方法将监控系统里的带宽曲线、QPS每秒请求数、CPU使用率、平均响应时间四类指标放在同一个时间轴里对比。如果带宽和QPS暴涨、CPU打满但成功请求数和业务成交量不变或下降同时伴随响应时间显著劣化这就是典型的资源耗尽型攻击特征。还有一种偏离需要特别注意请求成功率的异常。正常业务请求成功率在99%以上如果出现大量请求超时、连接被重置、返回5XX错误同时流量在涨说明系统已经无法正常处理请求——要么是资源被耗尽要么是接入层被堵住。这个现象配合前面三条可以确定是DDoS攻击而不是正常流量突发。3. 实战排查路径从发现异常到确认攻击的完整流程判断是否遭遇DDoS攻击不能只看某一个特征就下结论——需要多条特征交叉验证。这一节把完整排查路径拆出来照着走一遍10分钟内基本能出结论。3.1 先看监控大盘快速定位异常范围第一步永远是从全局监控切入。打开你的带宽监控、服务器负载监控、应用性能监控如果有的话把异常发生前后的时间段调出来比对。重点看三个时间节点的数据异常前15分钟的基线数据、异常开始时的拐点、异常过程中的峰值。这张监控截图会告诉你三类信息异常的开始时间用于和业务改动、发布操作做关联排查、异常的峰值强度用于判断攻击规模、异常的持续时间用于判断攻击节奏。如果异常发生在凌晨、没有任何业务变更的情况下突然出现且达到带宽上限DDoS的嫌疑就很大。监控数据的选取建议不要只看单台服务器的数据要看整个出口链路的数据。因为DDoS攻击通常打到IP或带宽层单台服务器可能已经被挤掉线但网络出口的流量数据还在。如果条件允许直接在路由器和防火墙上查看接口流量统计这是最准确的第一手数据。3.2 拉取日志做模式匹配验证四条特征监控确认异常后第二步是拉日志验证特征。按时间窗口异常开始前5分钟到当前时间拉取接入层Nginx、负载均衡的访问日志然后做四类统计按来源IP聚合的请求数Top20按URL聚合的请求数Top10按User-Agent聚合的请求数Top10TCP连接状态统计。如果日志里出现以下模式一个或几个IP贡献了绝大多数请求请求高度集中于某个URLUA字段为常见攻击工具的标记或大量重复值SYN_RECV积压——四条特征里面命中两条以上就可以基本确认是DDoS攻击接下来要做的就是阻断和防护。这个环节的效率取决于日志格式是否完善。建议在Nginx日志里打开以下字段$remote_addr来源IP、$request_uri完整请求路径、$http_user_agentUA、$status状态码、$request_time请求耗时、$upstream_response_time后端响应耗时。命中三轮排查就不会出现“日志字段不够导致查不下去”的情况。3.3 用命令行工具做实时观测动态确认攻击过程静态日志分析有延迟如果攻击仍在持续需要用实时观测工具确认攻击的动态过程。这里分享三组常用的排查命令都基于Linux系统自带工具不需要额外安装。第一组看网络连接状态watch -n 1 ss -s watch -n 1 netstat -ant | grep SYN_RECV | wc -lss -s显示系统级TCP统计能快速看到连接数总量第二行统计SYN_RECV数量正常情况下这个数字应该在个位数或十位数攻击时会飙升到数千甚至数万。第二组看流量来源tcpdump -i eth0 -nn -c 5000 port 80 | awk {print $3} | cut -d. -f1-4 | sort | uniq -c | sort -nr | head这条命令抓取5000个到达80端口的包按来源IP聚合取Top10。正常场景Top10的占比不会超过20%攻击场景下Top1就能占30%以上。第三组看请求处理效率top -bn1 | head -20 uptimeCPU使用率和负载均值能反映攻击是否已经压垮系统。如果CPU在100%附近徘徊但业务QPS没有同步增长说明CPU在空转——大量资源在处理垃圾请求。3.4 交叉验证从猜测到确认的完整闭环有了监控数据、日志统计、实时观测三组信息就可以做交叉验证了。验证的逻辑很简单问三个问题。第一异常流量是否符合“来源集中、目标集中、行为异常”这三个模式如果全部命中是DDoS攻击的可能性极高。第二业务指标是否与流量指标严重偏离如果带宽在涨但业务量在跌说明流量不产生业务价值大概率是攻击流量。第三异常是否与业务变更上线、发布、活动存在时间上的关联如果没有任何业务变更异常纯属凭空出现攻击的可能性再次提升。三个问题都命中可以直接认定为DDoS攻击进入防护流程。如果部分命中建议继续观察5~10分钟看特征是否持续。这里要提醒一个反向场景如果是正常的突发流量比如某外部平台导流流量来源分散、请求路径多样、业务指标同步上涨——三条都与之相反就不能误判成DDoS否则可能导致错误的封禁操作把真实用户也挡在门外。4. 典型误判场景与排查避坑实录判断DDoS攻击的难点不在“判断本身”而在“判断准确”。我把实际操作中见过最多的误判场景整理出来每条都对应一种具体的教训值得在排查前先过一遍。4.1 场景一爬虫流量被当成DDoS搜索引擎爬虫、数据采集工具、监控探测源这些正常但“不太守规矩”的流量和DDoS攻击的行为特征有部分重叠——高IP集中度、规律性请求、特定的UA标记。区分的关键指标是“请求是否有目的性”。爬虫的请求虽然频繁但会遵循一定规则会读取robots.txt、会等待页面加载完成、请求的URL有规律通常是详情页、列表页。DDoS攻击的请求基本没有目的性就是围绕固定目标反复打。实操建议如果怀疑是爬虫先看UA并做反向DNS解析。主流搜索引擎的爬虫UA明确且可验证且有对应的反解域名。如果UA可疑、IP归属不明、反解失败再纳入攻击判断。一个更实用的比例指标爬虫通常只占总体流量的20%以下除非站点本身以内容抓取为核心场景。如果单个来源的流量占比超过总流量的30%且来源IP在反向DNS中无法识别归属攻击的可能性大。4.2 场景二数据库慢查询导致的“伪DDoS”这是我自己踩过最深的坑。有一次线上服务查询突然超时严重流量、带宽都没有异常但CPU打满、QPS暴跌第一反应就是被应用层DDoS打了。排查一圈后发现是有个新上线的报表功能在特定时间触发了一个全表扫描数据库连接池被占满后端请求全部排队超时。教训是什么业务指标与流量指标偏离时除了攻击还要排查自身系统问题。前端流量正常、后端资源被打满的情况既可能是精准打击后端的应用层DDoS也可能是自身代码缺陷、数据量增长或慢SQL导致的雪崩。排查建议先看慢查询日志和数据级指标数据库连接数、锁等待时间再看应用日志中的异常堆栈。如果数据库侧找到明显的慢查询、全表扫描或锁竞争优先处理自身的性能问题。攻击的特征是“流量有变化”自身问题的特征通常是“流量没变、性能变了”或“流量没变、性能变了”。还有一个细节应用层DDoS攻击通常会持续且有节奏打一会儿、停一会儿自身系统问题则往往有明确的触发点定时任务、特定查询条件、特定页面访问。查看异常首次出现前5分钟的后台日志找有没有定时任务启动、缓存过期、冷数据加载的记录。4.3 场景三缓存雪崩和热点Key问题被当成DDoS缓存失效导致大量请求同时穿透到数据库现象和DDoS非常像QPS瞬间暴增、数据库压力剧增、响应时间抬高。但本质区别在于穿透流量来自真实用户来源IP分散请求路径多样且业务指标订单、页面浏览、登录在同步上涨。判断方法回到“特征四”看业务指标是否同步变化。缓存雪崩时用户能正常使用业务只是响应变慢真正成交、访问等业务量不会跌DDoS攻击时用户根本进不来业务指标一定是下跌的。区分建议查一下缓存服务的命中率监控。如果命中率在异常时段突然从95%跌到20%说明是缓存层面的问题如果命中率没变但流量暴涨才考虑是攻击流量直接打到接入层。4.4 场景四真正的“慢速攻击”容易被漏判和前面的误判方向相反有一种DDoS攻击流量特征很不明显——慢速攻击。攻击者建立连接后不发送完整请求或者以极低速率发数据把服务器的连接池慢慢占满。这种攻击的流量曲线几乎看不出异常带宽占用可能只有几Mbps但连接数会持续爬升直到服务器无法接受新连接。判断方法不在流量大小而在连接数与业务量的比值连接数持续上升、但实际完成的请求数很低或大量连接处于空闲/半开状态。用前面的netstat命令观察ESTABLISHED状态的连接数量和持续时间如果大量连接长时间存在但没有数据交互就要考虑慢速攻击。常见的慢速攻击手法包括Slowloris慢慢发送HTTP请求头、Slow POST缓慢发送请求体和慢速读客户端缓慢读取响应。这三种攻击流量层都很安静但都会导致连接池被占满。识别要点大量ESTABLISHED连接长时间保持但传输字节数为0或极低。把这个问题单独提出来是因为很多团队的监控只做带宽和QPS没有做连接数的趋势监控。慢速攻击会让带宽指标“看起来正常”但业务已经不可用这是最容易漏判的攻击类型值得专门增加连接数监控。5. 确认攻击之后的应急处理思路判断确认后处理环节同样有讲究。这里不展开完整的DDoS防护方案那是另一篇内容只讲几个在判断环节之后必须马上做的动作避免“判断对了、处理错了”的尴尬。5.1 第一步立刻确认防护能力和攻击规模是否匹配判断确认后的第一个动作不是“硬扛”而是评估自身防护能力。如果你的出口带宽只有100M攻击流量已经到500M此时无论服务器配置多高带宽都会先被打满业务一样不可用。这时候需要做的不是调服务器参数而是联系上游带宽提供商或云服务商启用流量清洗或黑洞策略。评估核心指标是攻击流量峰值 vs 自身出口带宽SYN_RECV积压 vs 系统最大连接数限制服务器CPU负载 vs CPU核数。三个指标中任意一个达到80%以上说明系统正在资源耗尽边缘必须快速决策。5.2 第二步先阻断再溯源不要边阻断边溯源很多人习惯先分析攻击来源再做处置这个顺序在DDoS场景中是错的。DDoS攻击的特征是流量大、持续时间不定多分析一分钟业务就多瘫痪一分钟。正确顺序是先用粗粒度手段将攻击流量挡在门外再从容地分析日志、保留证据。阻断手段按层级从低到高在防火墙上设置ACL拒绝特定来源IP在接入交换机上用黑洞路由将目标IP流量丢弃在Web服务器上用iptables限制并发连接数和请求速率有云WAF就走云WAF的防护策略。原则是越快恢复业务越好溯源的工作放在业务恢复之后。5.3 第三步保留攻击前后完整证据链路判断DDoS攻击的特征依赖日志后续溯源、追责、改善防护同样依赖日志。确认攻击后立刻备份以下数据攻击开始前24小时的访问日志用于建立正常基线攻击过程中的流量抓包文件tcpdump抓5~10分钟即可防火墙和接入设备的告警日志监控系统的性能曲线导出。抓包操作建议在前面“实时观测”的命令基础上升级加上时间窗口和端口过滤保存为pcap文件备用timeout 300 tcpdump -i eth0 -nn -s0 -w attack_capture.pcap port 80 or port 443这组数据是后续做攻击溯源、出具分析报告、和云服务商对线索赔如果有SLA的核心依据。判断DDoS攻击从来不只是“知道是攻击”就完事完整的证据闭环才能让一次排查产生长期的防护价值。5.4 第四步攻击结束后复盘防护短板攻击结束后对照前面四条特征做一次复盘哪条特征最先暴露了攻击迹象现有监控是否覆盖了该指标攻击流量从哪个层级进入现有防护在哪个环节失守我见过做得好的团队会把每次DDoS攻击的关键数据归档成一张表攻击类型、峰值流量、持续时间、攻击源IP段、最有效的阻断手段、从发现到恢复的耗时。积累几轮之后再遇到攻击就能快速匹配历史模式判断和处置效率会有质的提升。DDoS攻击的特征虽然多变但攻击者的手法套路是有限的用“历史经验库”去匹配新攻击是最实用主义的高效路径。6. 判断能力的底层把监控做扎实比判断技巧更重要说了这么多判断特征最后想回到一个更根本的问题判断DDoS攻击的所有技巧都建立在一个前提上——你手上有可以查的数据。没有历史基线、没有访问日志、没有连接状态统计再多的判断特征都是空中楼阁。我的实际体会是把基础监控补齐比研究攻击特征值更优先。一个基础但完整的监控组合至少包括四层网络层带宽、出入流量、丢包率系统层CPU、内存、连接数、负载应用层QPS、响应时间、错误率、业务成交量安全层防火墙拦截数、访问日志异常聚合。四层数据配合才能完整支撑“流量和业务指标是否偏离”这一核心判断逻辑。尤其是连接数这个指标很多团队没有纳入监控。DDoS攻击几乎都会体现在连接数的异常变化上——要么是连接总量暴涨要么是半开连接积压要么是连接长期占用不释放。把连接数趋势监控加上慢速攻击这类隐蔽攻击也逃不过眼睛。另外分享一个实操经验监控数据尽量保留30天以上。DDoS攻击的特征判断极度依赖基线对比如果只有当天的数据异常发生后很难准确判断“这个流量值是不是正常”。保留一个月的监控数据不仅方便判断攻击还能帮你找出业务本身的流量节奏——正常的高峰时段、促销活动的流量形态、爬虫流量的日常占比这些都是判断“异常”的对照物。下次再遇到流量异常别急着看服务器日志先打开流量监控把当前曲线和历史基线的差别看清楚再用这篇文章里的四条特征逐条验证。判断DDoS攻击本质上是一个“对比”的过程——和基线对比、和正常行为对比、和业务指标对比。对比维度足够多误判的概率自然就低。判断准确了后续的防护动作才做得对。 
长河君 · 2026/10/20 22:59:27 · 阅读 1.2k 判断DDoS攻击的四个关键特征：流量行为识别与排查
业务突然卡顿、用户大面积反馈打不开页面、后台监控曲线直接拉满——这套流程跑过线上业务的人都不陌生。但这里有个容易栽跟头的判断误区把所有的访问异常都当成DDoS或者反过来明明是DDoS却当成普通流量高峰处理。判断是否遭遇DDoS攻击核心不是看流量大小而是看流量的“行为特征”。这篇内容我把最常见的四种特征整理出来都是可以直接在监控、日志、接入层快速核验的硬指标不需要依赖复杂的安全设备哪怕只有一台服务器和一台路由器也能做出八九不离十的判断。适合谁看维护过线上业务、被突发的流量波动折腾过、或者正在搭建基础监控体系的人。内容不涉及商业安全产品的具体用法全部基于通用网络原理和常见开源工具看完可以直接对照自己的环境做排查。1. 判断DDoS的第一步先分清故障类型很多人一看到带宽跑满就喊DDoS其实先别急着下结论。线上业务的访问异常通常分三类网络层故障交换机、光缆、路由问题、服务器层故障CPU、内存、数据库连接数耗尽、应用层故障代码Bug、依赖服务超时。DDoS攻击只是导致这三类故障的其中一种原因甚至很多时候攻击者只是“点火”真正把系统搞垮的是资源配置不合理或者代码健壮性差。所以判断是否遭遇DDoS攻击第一个动作不是查攻击特征而是确认故障的范围和性质。先回答四个问题是全站不可用还是部分区域不可用是持续不可用还是间歇性不可用是只有动态请求受影响还是静态资源也受影响是用户侧反馈异常还是监控系统主动告警这四个问题的答案能帮你快速缩小排查范围。比如全站不可用且静态资源都加载失败大概率是网络层或者带宽被塞满如果是只有登录接口超时、静态资源正常那更像应用层问题。DDoS攻击的特征从网络层到应用层都有不同层级的攻击对应的排查手段完全不同先定位故障层级再判断是否遭受DDoS思路才会清晰。这里有一个实践中的判断技巧用三个时间点做对比——攻击前的正常基线、异常出现时的峰值、异常结束后的回落情况。DDoS攻击的特征之一是流量“来得快、去得也快”攻击停止后流量通常会迅速回落。如果流量是缓慢爬升又缓慢下降那更像是业务自然增长或爬虫抓取导致的波动。2. 四种高辨识度特征一查便知的判断依据判断是否遭遇DDoS攻击真正管用的其实就四种特征。这四种特征分别对应不同攻击层级组合起来基本能覆盖95%以上的DDoS场景。每一条都可以通过自有监控、流量工具或日志系统来验证不需要额外采购设备。2.1 特征一流量曲线呈“断崖式”突增且来源IP高度集中DDoS攻击最直观的特征是流量曲线的形态异常。正常业务流量增长是渐进的有白天晚上的自然波动有促销活动带来的脉冲式增长但无论哪种流量曲线都是连续且可解释的。DDoS攻击不同——攻击流量通常会在几十秒内完成爆发式增长曲线像被刀切了一样从正常水平直接拉满到带宽上限。这个特征的操作性在于打开流量监控图看异常发生前的基线值、异常时的峰值、异常持续的时间。真正的DDoS攻击流量上升时间通常小于5分钟峰值流量是基线的几倍甚至几十倍。如果是正常业务高峰流量上升过程至少以小时为单位。来源IP的分布是另一个硬指标。常规业务流量的来源IP必然分散符合用户地理位置的自然分布。DDoS攻击的流量来源则高度集中——可能是某个IP段、某个机房段、某个国家的地址段。验证方法很直接把异常时段的访问日志按来源IP做聚合统计如果Top10的IP贡献了超过50%的流量基本可以判断流量成分不正常。我在实际排查中见过一个典型案例某业务高峰期流量突然翻了8倍最初被当成业务增长。后来拉取访问日志按IP聚合发现单个IP在5分钟内发起了超过20000次请求而正常用户几乎不会在5分钟内请求超过100次。IP集中度这个指标是区分DDoS攻击和正常突发流量的第一道分水岭。2.2 特征二请求特征异常集中在单一目标或特定协议DDoS攻击不管层级的差别背后都有一个共同点攻击者要最大化消耗目标资源所以攻击流量一定会集中在特定目标上——某个URL、某个API接口、某个页面或者某些协议类型。正常用户访问路径是发散性的有人看首页、有人看详情页、有人提交表单请求分布相对均匀。DDoS攻击的请求分布则高度聚焦。判断方法在Web服务器日志里按URL维度统计请求分布。如果异常时段内单个URL的请求占比异常升高比如超过总请求的70%而这个URL平时占比不到10%就需要警惕。很多DDoS攻击工具默认只打主页或固定路径请求特征非常明显。协议维度的判断也很有价值。如果流量主要消耗在TCP三次握手表现为大量SYN报文、半连接数暴涨属于SYN Flood攻击如果UDP流量异常增大且目标端口集中在少数几个端口属于UDP Flood攻击。这些在接入层交换机或服务器的连接状态统计里都能直接看到。我建议的做法是在Nginx或Apache日志里临时增加按$request_uri、$http_user_agent、$http_referer三个维度的实时统计持续观察10分钟。如果统计结果呈现高度集中的趋势就说明流量成分不自然大概率是攻击流量。2.3 特征三连接与协议行为异常明显不符合正常用户习惯这一条是最容易被忽视的但对判断攻击类型最有帮助。正常用户的访问行为遵循一定的规律先请求HTML页面再请求页面里引用的CSS、JS、图片资源每个连接发起的请求数有限请求间隔是秒级或毫秒级但访问总量与页面资源数匹配。DDoS攻击的协议行为完全不是这样。常见的不符合正常习惯的行为包括单个连接在极短时间内发起大量请求正常浏览器一个连接最多同时处理6个请求请求间隔时间极短且非常有规律正常用户有思考时间请求的HTTP头不完整或内容异常缺少User-Agent、Accept等常规字段大量请求使用相同的User-Agent或使用明显改动的UA值。判定方法可以量化为三个指标。第一连接数与请求数的比例正常业务一个连接通常对应2~10个请求攻击流量往往一个连接一个请求或一个连接对应几十上百个请求。第二请求的时间间隔分布正常业务的请求间隔呈自然分布攻击请求的间隔高度均匀。第三HTTP头完整率正常浏览器请求都会带完整的头信息攻击工具为了提升发包速度经常省略非必要字段。实操中可以用一条命令快速统计当前TCP连接状态netstat -ant | awk {print $6} | sort | uniq -c | sort -n如果SYN_RECV状态的连接数远高于ESTABLISHED说明有大量连接卡在三次握手阶段这是SYN类的攻击特征。正常服务器上SYN_RECV的连接占比很低且会快速完成握手转为ESTABLISHED或直接关闭。如果SYN_RECV积压持续不降且数量达到系统最大连接数限制基本可以认定为SYN Flood攻击。2.4 特征四业务指标与流量指标严重偏离这一条是判断是否“被攻击打趴下”的最核心依据但很多人会忽略。正常业务场景中流量增长通常伴随业务指标同步增长——流量翻倍订单数也应该增长CPU使用率上升但仍在合理范围响应时间可能略有增加但整体可用。DDoS攻击场景则完全不同流量暴涨但业务指标不涨反跌。具体表现为带宽占用从100M涨到800M但单位时间的有效请求数没增加甚至下降CPU使用率打满但处理的业务逻辑请求数没有同步上涨页面响应时间从200ms涨到10秒以上但并发用户数没有真实增长。这里需要特别留意应用层DDoS攻击的特征是流量不明显、但业务指标剧烈恶化。攻击者模拟真实用户的请求行为每次请求都消耗大量服务端资源比如复杂的数据库查询、加密解密计算单个请求的体积不大但每个请求都让服务器“做重活”。这种攻击最阴险因为流量层面看不出异常只有深入业务指标才能发现。判断方法将监控系统里的带宽曲线、QPS每秒请求数、CPU使用率、平均响应时间四类指标放在同一个时间轴里对比。如果带宽和QPS暴涨、CPU打满但成功请求数和业务成交量不变或下降同时伴随响应时间显著劣化这就是典型的资源耗尽型攻击特征。还有一种偏离需要特别注意请求成功率的异常。正常业务请求成功率在99%以上如果出现大量请求超时、连接被重置、返回5XX错误同时流量在涨说明系统已经无法正常处理请求——要么是资源被耗尽要么是接入层被堵住。这个现象配合前面三条可以确定是DDoS攻击而不是正常流量突发。3. 实战排查路径从发现异常到确认攻击的完整流程判断是否遭遇DDoS攻击不能只看某一个特征就下结论——需要多条特征交叉验证。这一节把完整排查路径拆出来照着走一遍10分钟内基本能出结论。3.1 先看监控大盘快速定位异常范围第一步永远是从全局监控切入。打开你的带宽监控、服务器负载监控、应用性能监控如果有的话把异常发生前后的时间段调出来比对。重点看三个时间节点的数据异常前15分钟的基线数据、异常开始时的拐点、异常过程中的峰值。这张监控截图会告诉你三类信息异常的开始时间用于和业务改动、发布操作做关联排查、异常的峰值强度用于判断攻击规模、异常的持续时间用于判断攻击节奏。如果异常发生在凌晨、没有任何业务变更的情况下突然出现且达到带宽上限DDoS的嫌疑就很大。监控数据的选取建议不要只看单台服务器的数据要看整个出口链路的数据。因为DDoS攻击通常打到IP或带宽层单台服务器可能已经被挤掉线但网络出口的流量数据还在。如果条件允许直接在路由器和防火墙上查看接口流量统计这是最准确的第一手数据。3.2 拉取日志做模式匹配验证四条特征监控确认异常后第二步是拉日志验证特征。按时间窗口异常开始前5分钟到当前时间拉取接入层Nginx、负载均衡的访问日志然后做四类统计按来源IP聚合的请求数Top20按URL聚合的请求数Top10按User-Agent聚合的请求数Top10TCP连接状态统计。如果日志里出现以下模式一个或几个IP贡献了绝大多数请求请求高度集中于某个URLUA字段为常见攻击工具的标记或大量重复值SYN_RECV积压——四条特征里面命中两条以上就可以基本确认是DDoS攻击接下来要做的就是阻断和防护。这个环节的效率取决于日志格式是否完善。建议在Nginx日志里打开以下字段$remote_addr来源IP、$request_uri完整请求路径、$http_user_agentUA、$status状态码、$request_time请求耗时、$upstream_response_time后端响应耗时。命中三轮排查就不会出现“日志字段不够导致查不下去”的情况。3.3 用命令行工具做实时观测动态确认攻击过程静态日志分析有延迟如果攻击仍在持续需要用实时观测工具确认攻击的动态过程。这里分享三组常用的排查命令都基于Linux系统自带工具不需要额外安装。第一组看网络连接状态watch -n 1 ss -s watch -n 1 netstat -ant | grep SYN_RECV | wc -lss -s显示系统级TCP统计能快速看到连接数总量第二行统计SYN_RECV数量正常情况下这个数字应该在个位数或十位数攻击时会飙升到数千甚至数万。第二组看流量来源tcpdump -i eth0 -nn -c 5000 port 80 | awk {print $3} | cut -d. -f1-4 | sort | uniq -c | sort -nr | head这条命令抓取5000个到达80端口的包按来源IP聚合取Top10。正常场景Top10的占比不会超过20%攻击场景下Top1就能占30%以上。第三组看请求处理效率top -bn1 | head -20 uptimeCPU使用率和负载均值能反映攻击是否已经压垮系统。如果CPU在100%附近徘徊但业务QPS没有同步增长说明CPU在空转——大量资源在处理垃圾请求。3.4 交叉验证从猜测到确认的完整闭环有了监控数据、日志统计、实时观测三组信息就可以做交叉验证了。验证的逻辑很简单问三个问题。第一异常流量是否符合“来源集中、目标集中、行为异常”这三个模式如果全部命中是DDoS攻击的可能性极高。第二业务指标是否与流量指标严重偏离如果带宽在涨但业务量在跌说明流量不产生业务价值大概率是攻击流量。第三异常是否与业务变更上线、发布、活动存在时间上的关联如果没有任何业务变更异常纯属凭空出现攻击的可能性再次提升。三个问题都命中可以直接认定为DDoS攻击进入防护流程。如果部分命中建议继续观察5~10分钟看特征是否持续。这里要提醒一个反向场景如果是正常的突发流量比如某外部平台导流流量来源分散、请求路径多样、业务指标同步上涨——三条都与之相反就不能误判成DDoS否则可能导致错误的封禁操作把真实用户也挡在门外。4. 典型误判场景与排查避坑实录判断DDoS攻击的难点不在“判断本身”而在“判断准确”。我把实际操作中见过最多的误判场景整理出来每条都对应一种具体的教训值得在排查前先过一遍。4.1 场景一爬虫流量被当成DDoS搜索引擎爬虫、数据采集工具、监控探测源这些正常但“不太守规矩”的流量和DDoS攻击的行为特征有部分重叠——高IP集中度、规律性请求、特定的UA标记。区分的关键指标是“请求是否有目的性”。爬虫的请求虽然频繁但会遵循一定规则会读取robots.txt、会等待页面加载完成、请求的URL有规律通常是详情页、列表页。DDoS攻击的请求基本没有目的性就是围绕固定目标反复打。实操建议如果怀疑是爬虫先看UA并做反向DNS解析。主流搜索引擎的爬虫UA明确且可验证且有对应的反解域名。如果UA可疑、IP归属不明、反解失败再纳入攻击判断。一个更实用的比例指标爬虫通常只占总体流量的20%以下除非站点本身以内容抓取为核心场景。如果单个来源的流量占比超过总流量的30%且来源IP在反向DNS中无法识别归属攻击的可能性大。4.2 场景二数据库慢查询导致的“伪DDoS”这是我自己踩过最深的坑。有一次线上服务查询突然超时严重流量、带宽都没有异常但CPU打满、QPS暴跌第一反应就是被应用层DDoS打了。排查一圈后发现是有个新上线的报表功能在特定时间触发了一个全表扫描数据库连接池被占满后端请求全部排队超时。教训是什么业务指标与流量指标偏离时除了攻击还要排查自身系统问题。前端流量正常、后端资源被打满的情况既可能是精准打击后端的应用层DDoS也可能是自身代码缺陷、数据量增长或慢SQL导致的雪崩。排查建议先看慢查询日志和数据级指标数据库连接数、锁等待时间再看应用日志中的异常堆栈。如果数据库侧找到明显的慢查询、全表扫描或锁竞争优先处理自身的性能问题。攻击的特征是“流量有变化”自身问题的特征通常是“流量没变、性能变了”或“流量没变、性能变了”。还有一个细节应用层DDoS攻击通常会持续且有节奏打一会儿、停一会儿自身系统问题则往往有明确的触发点定时任务、特定查询条件、特定页面访问。查看异常首次出现前5分钟的后台日志找有没有定时任务启动、缓存过期、冷数据加载的记录。4.3 场景三缓存雪崩和热点Key问题被当成DDoS缓存失效导致大量请求同时穿透到数据库现象和DDoS非常像QPS瞬间暴增、数据库压力剧增、响应时间抬高。但本质区别在于穿透流量来自真实用户来源IP分散请求路径多样且业务指标订单、页面浏览、登录在同步上涨。判断方法回到“特征四”看业务指标是否同步变化。缓存雪崩时用户能正常使用业务只是响应变慢真正成交、访问等业务量不会跌DDoS攻击时用户根本进不来业务指标一定是下跌的。区分建议查一下缓存服务的命中率监控。如果命中率在异常时段突然从95%跌到20%说明是缓存层面的问题如果命中率没变但流量暴涨才考虑是攻击流量直接打到接入层。4.4 场景四真正的“慢速攻击”容易被漏判和前面的误判方向相反有一种DDoS攻击流量特征很不明显——慢速攻击。攻击者建立连接后不发送完整请求或者以极低速率发数据把服务器的连接池慢慢占满。这种攻击的流量曲线几乎看不出异常带宽占用可能只有几Mbps但连接数会持续爬升直到服务器无法接受新连接。判断方法不在流量大小而在连接数与业务量的比值连接数持续上升、但实际完成的请求数很低或大量连接处于空闲/半开状态。用前面的netstat命令观察ESTABLISHED状态的连接数量和持续时间如果大量连接长时间存在但没有数据交互就要考虑慢速攻击。常见的慢速攻击手法包括Slowloris慢慢发送HTTP请求头、Slow POST缓慢发送请求体和慢速读客户端缓慢读取响应。这三种攻击流量层都很安静但都会导致连接池被占满。识别要点大量ESTABLISHED连接长时间保持但传输字节数为0或极低。把这个问题单独提出来是因为很多团队的监控只做带宽和QPS没有做连接数的趋势监控。慢速攻击会让带宽指标“看起来正常”但业务已经不可用这是最容易漏判的攻击类型值得专门增加连接数监控。5. 确认攻击之后的应急处理思路判断确认后处理环节同样有讲究。这里不展开完整的DDoS防护方案那是另一篇内容只讲几个在判断环节之后必须马上做的动作避免“判断对了、处理错了”的尴尬。5.1 第一步立刻确认防护能力和攻击规模是否匹配判断确认后的第一个动作不是“硬扛”而是评估自身防护能力。如果你的出口带宽只有100M攻击流量已经到500M此时无论服务器配置多高带宽都会先被打满业务一样不可用。这时候需要做的不是调服务器参数而是联系上游带宽提供商或云服务商启用流量清洗或黑洞策略。评估核心指标是攻击流量峰值 vs 自身出口带宽SYN_RECV积压 vs 系统最大连接数限制服务器CPU负载 vs CPU核数。三个指标中任意一个达到80%以上说明系统正在资源耗尽边缘必须快速决策。5.2 第二步先阻断再溯源不要边阻断边溯源很多人习惯先分析攻击来源再做处置这个顺序在DDoS场景中是错的。DDoS攻击的特征是流量大、持续时间不定多分析一分钟业务就多瘫痪一分钟。正确顺序是先用粗粒度手段将攻击流量挡在门外再从容地分析日志、保留证据。阻断手段按层级从低到高在防火墙上设置ACL拒绝特定来源IP在接入交换机上用黑洞路由将目标IP流量丢弃在Web服务器上用iptables限制并发连接数和请求速率有云WAF就走云WAF的防护策略。原则是越快恢复业务越好溯源的工作放在业务恢复之后。5.3 第三步保留攻击前后完整证据链路判断DDoS攻击的特征依赖日志后续溯源、追责、改善防护同样依赖日志。确认攻击后立刻备份以下数据攻击开始前24小时的访问日志用于建立正常基线攻击过程中的流量抓包文件tcpdump抓5~10分钟即可防火墙和接入设备的告警日志监控系统的性能曲线导出。抓包操作建议在前面“实时观测”的命令基础上升级加上时间窗口和端口过滤保存为pcap文件备用timeout 300 tcpdump -i eth0 -nn -s0 -w attack_capture.pcap port 80 or port 443这组数据是后续做攻击溯源、出具分析报告、和云服务商对线索赔如果有SLA的核心依据。判断DDoS攻击从来不只是“知道是攻击”就完事完整的证据闭环才能让一次排查产生长期的防护价值。5.4 第四步攻击结束后复盘防护短板攻击结束后对照前面四条特征做一次复盘哪条特征最先暴露了攻击迹象现有监控是否覆盖了该指标攻击流量从哪个层级进入现有防护在哪个环节失守我见过做得好的团队会把每次DDoS攻击的关键数据归档成一张表攻击类型、峰值流量、持续时间、攻击源IP段、最有效的阻断手段、从发现到恢复的耗时。积累几轮之后再遇到攻击就能快速匹配历史模式判断和处置效率会有质的提升。DDoS攻击的特征虽然多变但攻击者的手法套路是有限的用“历史经验库”去匹配新攻击是最实用主义的高效路径。6. 判断能力的底层把监控做扎实比判断技巧更重要说了这么多判断特征最后想回到一个更根本的问题判断DDoS攻击的所有技巧都建立在一个前提上——你手上有可以查的数据。没有历史基线、没有访问日志、没有连接状态统计再多的判断特征都是空中楼阁。我的实际体会是把基础监控补齐比研究攻击特征值更优先。一个基础但完整的监控组合至少包括四层网络层带宽、出入流量、丢包率系统层CPU、内存、连接数、负载应用层QPS、响应时间、错误率、业务成交量安全层防火墙拦截数、访问日志异常聚合。四层数据配合才能完整支撑“流量和业务指标是否偏离”这一核心判断逻辑。尤其是连接数这个指标很多团队没有纳入监控。DDoS攻击几乎都会体现在连接数的异常变化上——要么是连接总量暴涨要么是半开连接积压要么是连接长期占用不释放。把连接数趋势监控加上慢速攻击这类隐蔽攻击也逃不过眼睛。另外分享一个实操经验监控数据尽量保留30天以上。DDoS攻击的特征判断极度依赖基线对比如果只有当天的数据异常发生后很难准确判断“这个流量值是不是正常”。保留一个月的监控数据不仅方便判断攻击还能帮你找出业务本身的流量节奏——正常的高峰时段、促销活动的流量形态、爬虫流量的日常占比这些都是判断“异常”的对照物。下次再遇到流量异常别急着看服务器日志先打开流量监控把当前曲线和历史基线的差别看清楚再用这篇文章里的四条特征逐条验证。判断DDoS攻击本质上是一个“对比”的过程——和基线对比、和正常行为对比、和业务指标对比。对比维度足够多误判的概率自然就低。判断准确了后续的防护动作才做得对。