一段话讲清DDoS攻防的底层逻辑做了几年线上业务的稳定性保障和DDoS攻防打交道是免不了的。我见过不少团队平时不把这事儿当回事等到某一天入口带宽被打满、监控告警响成一片、用户疯狂反馈“网站打不开”的时候才手忙脚乱去翻文档找方案。那种感觉做过一次就再也不想经历第二次。这篇内容想把自己这些年积累的东西做一个完整梳理从攻击是怎么发生的到攻击流量长什么样再到企业级防护怎么落地全部串起来讲。文章面向的主要是三类人刚入门的安全运维想系统了解DDoS体系的开发者以及正在为公司选型防护方案的决策者。内容尽量做到通篇都能落地不只讲原理更讲操作。先说一个最核心的认知DDoS攻防的本质不是“技术对抗”而是“资源对抗”。攻击方在赌你的带宽、CPU、连接处理能力撑不住防守方要做的就是让你自己的系统比攻击者消耗得更慢、恢复得更快。理解了这个底层逻辑后面所有技术选择就都好理解了。1. 攻击原理拆解DDoS到底是怎么把服务打挂的很多文章一上来就列各种攻击类型但如果不先搞清楚攻击的根本逻辑类型表背得再熟也没用。我从底层开始拆。1.1 从一次正常请求说起服务被“挤垮”的本质假设有个电商网站平时每天几十万访问量服务器配置是4核8G带宽100M。正常情况下一台接入层Nginx能扛住的并发连接数大概在几千到一万左右这取决于配置和后端响应速度。现在攻击者要做的事情很简单让这个数字超过上限。他们不需要突破你的防火墙不需要拿到服务器权限只需要让“合法请求”的量多到你处理不过来。就像一家奶茶店正常排队20人店员忙得过来现在突然有2000个人同时来排队不管这些人是真顾客还是雇来的托儿店里的出杯速度跟不上后面的顾客就等不了体验就崩溃了。这就是DDoS的基本逻辑——通过制造超量的请求或数据耗尽目标系统的带宽、CPU、内存、连接数等资源让正常用户无法获得服务。它不是“破坏”而是“挤占”后者更难防御因为它看起来和正常流量没有本质区别。1.2 三种核心攻击模型带宽型、连接型、资源耗尽型虽然DDoS攻击的手段五花八门但归纳下来就三类模型理解这三类后面看任何攻击类型都能一眼归位。第一类是带宽型攻击。攻击者的目标是直接打满你的出口带宽。常见手法是UDP Flood用大流量UDP报文直接砸向目标IP。比如你带宽是1Gbps攻击流量来了2Gbps那不管你服务器性能多强数据包根本进不来进来的也出不去服务自然就挂了。这类攻击最简单粗暴也最容易理解。第二类是连接型攻击。攻击者不追求占用多大带宽而是把目标服务器的连接资源消耗殆尽。典型是SYN Flood攻击者发送大量TCP连接请求但从不完成三次握手。服务器每收到一个SYN包就会分配一块内存记录这个半开连接等超时释放。当半开连接数达到系统上限时新的连接请求就再也无法建立了。第三类是资源耗尽型攻击。这类攻击更“聪明”它不直接打满带宽或连接数而是通过发送特定类型的请求让服务器CPU在应用层做大量计算。最典型的例子是HTTP慢速攻击攻击者建立连接后一点点地发送数据让服务器长期占用连接和线程资源。还有针对特定接口的CC攻击模拟正常业务请求消耗数据库查询能力和后端计算资源一台低配服务器面对几百个并发恶意请求可能就会CPU飙到100%。这三类模型对应防护手段也完全不同。带宽型得靠流量清洗连接型得靠SYN Cookie和连接限制资源耗尽型得靠应用层的限流和风控。后面我都会展开讲。1.3 攻击者从哪里来僵尸网络与放大攻击攻击者手头哪有那么多流量早期靠蠕虫病毒感染大量个人电脑组成僵尸网络Botnet。现在更常见的做法是打云主机——有些人扫到弱口令的服务器植入木马这些服务器带宽动辄几百M甚至几G攒上几百台就能拼出不小的攻击能力。还有一类叫反射放大攻击效果更恐怖。攻击者伪造源IP为受害者的IP向互联网上的开放DNS、NTP、Memcached等服务发送大量小请求这些服务会把响应发到受害者IP上。如果是个Memcached服务器放大倍数可以达到一万倍以上——攻击者用1Mbps的流量就能打出10Gbps的攻击效果。这种攻击成本极低防御难度却很高因为流量来源是大量正常服务单纯封禁某个IP根本封不过来。理解了这三块就理解了DDoS的整个攻击面。后面的防护体系本质上都是围绕这几种攻击模型来设计的。2. 攻击特征与识别怎么分辨是攻击还是正常峰值防护的第一步不是“防”而是“认”。你得先搞清楚当前到底是真被打了还是正常的业务高峰。2.1 从监控指标识别DDoS攻击我习惯看五个指标任何一个出现异常就要开始警觉带宽使用率是最直观的。如果平时峰值只有200Mbps突然跑到800Mbps而且没有合理业务解释比如没有大促、没有活动那基本可以断定被流量型攻击打了。TCP连接数是第二个关键指标。SYN Flood发生时服务器上的半开连接数会急剧增长正常几十几百的连接数可能瞬间飙到几万甚至几十万。用netstat能看到大量SYN_RECV状态的连接这基本就是被打了。请求QPS是第三个。某个接口平时QPS几百突然几千几万而且来源IP非常分散大概率是CC攻击。要注意的是做活动期间QPS也会涨所以得结合业务背景来判断。错误率是第四个。如果服务器出现大量连接超时、502/504错误同时带宽和连接数异常说明系统资源已经耗尽服务正在崩溃。日志特征第五个。攻击日志往往高度相似——同一个UA、固定请求路径、规律性访问间隔、没有业务转化行为。这些在应用层日志里比较容易观察到。2.2 典型攻击流量特征速查我自己整理了一个速查表遇到异常时直接对照能大大加快判断速度。攻击类型流量特征服务器表现UDP Flood大流量UDP包来源端口固定带宽瞬间打满CPU处理软中断飙升SYN Flood大量SYN包源IP分散无后续ACK半开连接数暴涨正常连接无法建立HTTP FloodCC攻击高QPS请求路径固定UA规律CPU飙升数据库慢查询增多响应时间拉长慢速攻击连接极少但一直不释放连接数缓慢增长线程池耗尽DNS Query Flood大量DNS查询请求DNS服务CPU飙高解析超时这里面SYN Flood和UDP Flood相对容易识别因为特征明显。CC攻击最坑的是它混在正常业务请求里光看流量很难分辨必须结合业务特征来确认。这也是为什么很多企业带宽防御做得很好但应用层被CC打得没脾气的核心原因。2.3 识别中的两个常见误判第一个误判是把正常业务高峰当成攻击。电商大促、整点秒杀、热门产品开售瞬间流量都可能是平时的十倍以上。我见过有团队在大促前误开了黑洞路由结果活动一开始所有用户全部被引流到黑洞整场活动直接废掉。所以确认攻击前一定先和业务方确认当前是否有活动、是否有预期外的流量波动。第二个误判是漏掉慢速攻击。慢速攻击流量不大带宽和CPU都不一定报警但连接数会持续累积。很多人的监控只看带宽和CPU不看连接数结果服务被拖死的时候还找不到原因。这里建议大家在监控里把“当前TCP连接数”和“ESTABLISHED连接数”单独拎出来配好阈值告警很多时候能救你一条命。3. 企业级防护体系设计分层防御才是正解护城河不是一条而是好几道。真正站得住的防护体系从来不是靠某一台设备或者某一个云服务就能完成的。3.1 纵深防御的整体架构我把企业级DDoS防护拆成三层来做。最外层是流量清洗层。这一层通常由云服务商或IDC机房提供核心能力是“在流量到达你的服务器之前先把攻击流量过滤掉”。云清洗、运营商级黑洞都在这一层。带宽型攻击在这里被解决你的源站服务器根本感知不到巨大流量打过。中间层是接入层防护。这一层由你自己的基础设施承担比如负载均衡、防火墙、反向代理。核心能力是连接层防护包括SYN Cookie、连接数限制、IP黑名单、地理位置限制等。连接型攻击在这里被拦截你的后端服务器不会因为连接耗尽而崩溃。最内层是应用层防护。这一层针对的是CC攻击和慢速攻击需要结合业务做精细化限制。比如接口限流、行为分析、验证码挑战、URI黑白名单。资源耗尽型攻击在这里解决你的应用服务不会因为恶意请求而CPU打满。这三层是递进关系外层拦大流量中层拦恶意连接内层拦恶意请求。任何一层失守服务都会出问题所以不能只依赖某一层。很多公司上了云清洗就万事大吉结果被HTTP慢速攻击打穿了——因为云清洗默认不过滤低频慢速流量它判断不出来这是攻击。3.2 关键防护参数与配置建议防护参数不能随便填配错了要么防不住要么误伤正常用户。带宽防护阈值。清洗设备的防护阈值设置为带宽的80%左右比较合理。比如你带宽1Gbps阈值设800Mbps超过就触发清洗。设太高防不住设太低容易误清洗。这个值不是一个固定数要根据业务实际情况调整。SYN Flood防护。建议开启SYN Cookie然后在接入层设置半开连接数上限。Nginx里可以这样配置# 限制每IP并发连接数 limit_conn_zone $binary_remote_addr zoneaddr:10m; server { listen 80; limit_conn addr 10; }这里把单IP并发连接限制在10个。正常用户一般不会超过这个数但要注意如果用户在公司里走的是统一出口IP那NAT后面的所有同事都算同一个IP限制太严会把正常用户都挡住。这个值需要根据你的业务形态来调。应用层限流用Nginx的limit_req模块# 限制每IP每秒请求数 limit_req_zone $binary_remote_addr zonereq_limit:10m rate5r/s; server { location /api/ { limit_req zonereq_limit burst10 nodelay; } }这个配置是每IP每秒最多5个请求允许瞬间10个突发。对于API服务这个值是偏保守的如果你们的业务正常峰值就超过这个数需要调高。核心逻辑是这个值要卡在“正常业务峰值”和“攻击流量特征”之间。卡对了攻击被拦卡错了误伤用户。TCP连接超时参数也值得调整。攻击者建立的连接如果不完整占用连接資源不释放那么连接超时时间设短一点能快速回收资源。在Linux内核层面可以调整# 缩短SYN重试次数和半开连接超时 sysctl -w net.ipv4.tcp_synack_retries1 sysctl -w net.ipv4.tcp_syn_retries1 sysctl -w net.ipv4.tcp_max_syn_backlog1024这些参数可以把半开连接的占用时间从几十秒缩短到几秒让系统更快速地从攻击中恢复。3.3 高可用架构对DDoS防护的意义如果公司有条件我强烈建议把架构往高可用方向演进多地域部署、负载均衡、无状态化改造。这样做最直接的好处是当某个地域入口被攻击时可以把流量切到其他地域。举个例子部署了华东和华北两个地域华东被打了正常情况下是清洗但如果攻击量超出了清洗能力可以临时把域名解析切到华北让华东的机器慢慢恢复。这要求你的服务是无状态的会话数据不在本地保存切过去之后业务无感知。这个方案在很多中小公司里被忽略因为前期改造成本不小。但经历过一次大规模攻击后你就会明白高可用架构不只是在服务器宕机时有用在DDoS防护上同样是战略级资产。3.4 云清洗能力评测与选型选云清洗服务别只看“清洗能力多大”里面有几个坑要注意。第一个坑是清洗触发阈值。有些云厂商默认的清洗阈值很高你得主动去后台配置不配置的话小流量攻击根本不会触发清洗。我见过有团队上了云清洗结果被打了半小时都没触发客服一问才知道默认阈值没调。第二个坑是清洗能力上限。厂商宣传“可抵御T级攻击”但那个数字是全网数据中心的总能力分摊到你所在的地域实际清洗能力可能只有几百G。选型之前一定问清楚你所在的节点清洗能力是多少如果超出怎么办有没有限流策略。第三个坑是回源链路。清洗结束后干净流量要回源到你的服务器回源带宽是否独立计算回源链路是否充足如果回源链路窄攻击流量被清洗了但正常流量也进不来等于白防。这个细节很多人在选型时不会问。第四个坑是误判与误清洗。云清洗设备为了追求性能判断逻辑相对粗糙正常业务流量有时会被误杀尤其是TCP指纹不标准或者请求频率较高的业务。上线前一定要做充分的联调测试把正常业务跑一遍确认清洗设备放行所有合法流量。3.5 内部应急响应机制技术策略之外还得有一套流程。我建议公司内部至少要有这么一份文档谁负责确认攻击、谁负责联系运营商、谁负责切换流量、谁负责对外通告。DDoS攻击一来所有人都是懵的如果没有预先排练过流程光靠现场开会决策时间完全来不及。理想的响应时间线是监控告警后1分钟内确认攻击类型3分钟内联系云厂商介入清洗5分钟内完成流量调度决策10分钟内恢复服务。这条时间线看起来紧张但只要你提前做好了预案和演练完全做得到。我在实际工作中把攻击响应时间从最初的半小时优化到了5分钟以内关键就是有人盯监控、有方案可执行、有决策权限前置。4. 实战落地一次完整DDoS防护部署的过程复盘光讲理论没意思我把一个典型的接入流程完整走一遍从评估到上线照着做就能跑通。4.1 阶段一资产核查与攻击面梳理防护方案设计之前第一件事不是买设备而是把家底盘清楚。第一步梳理所有对外暴露的入口域名、IP、端口、协议。能用一个统一入口收拢的就不要暴露多个IP和端口攻击面越小越好。第二步梳理业务依赖关系哪些业务可以降级、哪些接口可以限流、数据库是否有独立出口。第三步明确各业务的关键性和容忍度核心交易链路的防护优先级最高静态资源可以先放一放。梳理完成后你会发现原本以为只有两个入口实际上有四五个。有些老项目还在用裸IP访问不走域名清洗设备根本识别不到这些流量等于裸奔。这些历史包袱一定要在防护方案设计前解决掉。4.2 阶段二防护策略配置与验证配置流程按下面几步走每一步做完都要验证第一步接入云清洗服务。拿到清洗IP后把业务域名的解析切到清洗IP清洗IP回源到你原来的服务器IP。这一步完成的是最外层清洗攻击流量会被云厂商过滤。第二步在服务器上启用连接层防护。开启SYN Cookie、配置Nginx连接数和请求数限制。这里建议配置完先小流量验证确认不会误伤正常用户。第三步做清洗验证。可以用压测工具模拟攻击流量测试清洗设备能否正确识别并过滤。攻击流量通常由安全团队或第三方来做测试时一定要提前通知所有相关方因为故意打出来的攻击流量是真的会影响到线上服务的。第四步跑全链路压测。模拟正常业务峰值流量走完整个链路确认防护策略不会影响业务性能。这个环节最容易发现配置过严导致的误伤问题。我这里有一套常用的压测命令参数仅供参考# 模拟高并发连接观察服务器连接数和响应时间 ./wrk -t8 -c500 -d60s http://your-domain/api/health # 模拟高频请求测试限流策略是否生效 ./wrk -t4 -c200 -d120s -s attack.lua http://your-domain/api/order/list重点观察几个指标请求成功率、错误率、响应延迟、服务器CPU/内存/带宽。如果压测过程中出现大量502或者响应时间暴涨第一件事不是调配置而是先压测请求日志和Nginx错误日志定位是被限流拦了还是服务本身不行了。4.3 阶段三检测与告警体系建设防护上线后检测体系是整个方案的“眼睛”没有它策略配置再对也看不出效果。我的建议是至少配四类告警带宽类告警。监控入口流量和出口流量按时间的5分钟粒度聚合阈值设置为带宽的70%-80%。超过就告警。带宽告警是最基础的一道线它的作用是让你在带宽被打满前先收到通知给自己留出反应时间。连接数告警。监控TCP连接总数、SYN_RECV数量、ESTABLISHED数量。SYN_RECV数量异常增长、超过正常基线一倍以上告警。这条告警在很多团队被忽视但它是SYN Flood攻击最灵敏的信号。应用层告警。监控核心接口的QPS、RT、错误率这些指标波动异常时告警。比如正常QPS基线是300突然3000即使带宽没报警也要查一下是不是被攻击了。日志分析告警。对Nginx和网关日志做基础分析如果在短时间内出现大量相同路径相同UA的请求就要留意。可以用类似这样的方式分析日志# 统计访问最多的20个路径 awk {print $7} access.log | sort | uniq -c | sort -rn | head -20 # 统计访问最多的20个IP awk {print $1} access.log | sort | uniq -c | sort -rn | head -20这几条命令在攻击发生时就是你的第一手侦查工具。我见过不少团队攻击发生半小时了才发现就是因为没有日志分析的告警手段。告警不是说越多越好而是分级处理紧急告警严重带宽异常、SYN_RECV暴涨、核心接口错误率飙升直接通知到人和值班群普通告警QPS波动、连接数稍高进告警列表人工确认。告警太多会让人疲掉真正的紧急告警反而被淹没。4.4 阶段四应急预案与演练预案如果只写在文档里等于没有预案。我见过太多公司应急预案写得漂漂亮亮CTO一翻说“没问题按这个执行”真到攻击发生时发现第一步就卡住了——没人知道云厂商的工单系统怎么提、应急联系人是谁。有效的方法是每季度至少做一次攻防演练用模拟攻击检验整个流程的响应速度和准确性。模拟攻击建议从低强度开始逐步加大过程中记录每个环节的响应时间找出流程中的瓶颈和漏洞。另外注意预案里一定要有“止损决策”这一项。当攻击量超过当前防护能力上限时最优解不是硬抗而是部分牺牲——直接宣布服务降级只保核心业务。这个决策权要提前明确不能等到现场再开会讨论。我在实际中设置的规则是如果攻击流量超过清洗能力的80%立即切换至“保护模式”只透传核心交易链路流量其余全部丢弃或返回错误页。5. 常见问题与排查技巧实录下面这些是实际运维中经常遇到的坑整理成了一份排查速查表照着做基本能解决大部分问题。5.1 常见问题速查表问题原因分析处理方式带宽被打满但清洗设备没有触发清洗阈值配置过高或未配置检查云清洗后台配置确认触发阈值调低服务连接超时TCP连接数接近上限可能是SYN Flood开启SYN Cookie并观察SYN_RECV数量确认清洗设备已启用但攻击流量仍然进来了有域名或IP未接入清洗或回源链路被绕过核查所有对外暴露入口确认域名解析全部指向清洗IPCPU负载高但带宽正常可能是CC攻击或慢速攻击打开Nginx日志分析请求路径和IP分布配合限流策略正常用户的请求也被拦截限流阈值设置过低或触发条件太敏感查阅被限流的IP日志拉高阈值并设置burst缓冲攻击结束后服务还是恢复不了可能有连接残留或后端服务已过载重启接入层服务检查后端数据库连接池和线程池状态5.2 几个实战排查案例案例一某个业务线的服务每天早上10点准时“崩”。排查发现每天10点是业务的高峰时段服务器配置也够就是莫名迟迟响应。最后定位到是每天晚上跑批任务把系统连接数占住释放不及时早上业务一起来连接池就不够了。这不是DDoS攻击但表现出来的症状很像慢速攻击。这个案例的教训是排查时先看自己的系统状态不要一上来就认为是外部攻击。案例二客户反馈“网站打不开”但带宽和CPU都很正常。后来在Nginx日志里发现大量请求UA特别规律——100个IP同时访问同一个路径间隔精确到毫秒。这是应用层的HTTP Flood攻击。最后处理方式在Nginx上对特定路径加了一个每IP每分钟60次的限制攻击流量立刻被挡住业务恢复正常。案例三清洗设备一直显示“攻击中”但源站的带宽还是被打满。排查发现有一台老服务器的IP没有接入清洗攻击流量直接打到这台机器上然后从这台机器上继续打其他机器。处理方式把这台老服务器的IP也切到清洗同时把它收进内网禁止直接暴露公网。我个人的经验是80%的防护事故根源不是攻击太强而是防护配置有盲区——要么有一台机器没接入防护要么有一个域名没切到清洗IP上。所以最值得花时间的是把资产梳理和攻击面梳理做扎实这一步偷懒后面会加倍还回来。5.3 攻防之外的工程建议最后分享几条工程上的建议算是这几年踩过坑后的心得。第一能从架构上解决的问题不要依赖安全设备。把业务做无状态化拆到多个地域比买再贵的清洗设备都值。这不是说清洗设备没用而是架构的冗余给了你防护措施失效时的退路。第二与其追求百分百防住不如追求“打得烂还能恢复”。DDoS攻击不可能完全防住尤其是超大流量攻击。你的目标应该是攻击来了核心业务扛住攻击走了系统快速恢复。那些在攻击结束后一蹶不振的团队问题不在防护而在于恢复能力太弱。第三日志和监控的投入永远不过分。很多团队觉得监控系统不重要临时出了问题再查日志也不迟。实际上DDoS攻击是分秒必争的晚发现一分钟业务就多受影响一分钟恢复时间也可能成倍增加。日志和监控不是成本是保险。这些内容涵盖了我对DDoS攻击的理解和防护实践的大部分沉淀。按这套体系去搭不能说百分之百防住所有攻击但至少大多数情况下你不会再是那个在深夜被叫起来、面对告警一脸茫然的运维了。