DDoS攻击——分布式拒绝服务攻击这个从业十年的老话题热度从来没有降下来。无论是刚入行的运维新人还是负责核心业务平台的资深架构师面对DDoS时都会真切地感受到一种无力感业务明明写着“高可用”攻击一来大量正常用户却挤不进门。这篇文章我准备顺着一次真实事件的脉络把DDoS从原理、分类、检测到防御的整条链路拆开讲透不讲虚的全程用实战视角还原适合所有管理在线业务、负责系统稳定性的工程师阅读。1. 从一个深夜告警说起一次DDoS事件的完整复盘1.1 事件现场业务突然“不可用”事情发生在某平台大促前夜我正在值班告警系统突然开始疯狂推送消息网关可用性从99.9%直接跌到了30%以下页面打开极慢部分接口直接超时。进入监控面板第一眼看到的是带宽曲线拉成了一条直线——入站流量在几分钟内从正常水平飙升了几十倍外网IP的连接数瞬间冲破上限。服务器CPU倒是没有跑满但TCP连接表已经被塞得乱七八糟新建连接几乎全部失败。当时的第一反应是“会不会是活动流量太大了”但再一看源IP非常分散而且大量连接停留在半开状态这基本上就是教科书式的SYN Flood特征。1.2 应急处理从“懵”到“止损”当时团队分了两路一路查流量构成一路尝试在上层做拦截。由于托管机房没有配备流量清洗服务我们只能先靠系统层面压一压开启SYN Cookie、缩小超时时间、临时加白名单。这些操作起了一部分作用但并没有根本解决问题因为攻击流量已经打满了入口带宽。后来联系运营商通过切换接入链路、启用上游黑洞策略才把影响控制住。整个过程大约持续了两个小时业务才算恢复稳定。1.3 复盘得出的三条教训这次事件之后我反复复盘总结了三条对后续工作帮助极大的教训任何面向公网的业务都必须提前假设“我会被打”不能把“大概率没事”当成安全依据。监控不能只看CPU和带宽TCP连接状态、SYN到达速率、入站源IP分布这些指标才是识别DDoS的关键信号。应急响应必须提前演练真正被攻击的现场没有时间查文档只能靠肌肉记忆。也正是从这次事件开始我系统性整理了DDoS的原理和防御方案。下面顺着这条线一层层展开。2. 原理篇DDoS到底是怎么把服务打瘫的2.1 从一次正常访问看资源消耗要理解DDoS先得理解一次正常的网络请求要经过哪些步骤。当用户在浏览器输入网址并按下回车时你的服务器需要完成一系列事情接入网卡读取数据包协议栈解析TCP握手应用进程分配内存、创建连接对象业务代码处理请求并产生响应。每一步都在消耗资源包括CPU、内存、文件描述符和网络带宽。DDoS的思路就是盯住这些资源的某一个用海量垃圾请求把它填满让正常请求排不上队。2.2 TCP三次握手与SYN Flood的底层逻辑TCP握手的过程客户端先发送一个SYN包服务器收到后把这条连接放进半连接队列并回复SYN-ACK客户端再回一个ACK这条连接才进入已连接状态。问题就出在半连接队列——它是以空间换速度的有限缓冲区正常情况下队列里的连接几毫秒就会因为收到ACK而被移除。SYN Flood攻击的做法是伪造海量源IP的SYN包服务器每收到一个都要占用一个半连接槽位并回复SYN-ACK但伪造源根本不会回应ACK于是队列里的悬挂连接一直堆积等到队列满了新到的SYN包直接丢失正常用户连TCP握手都完不成。打个比方餐厅只有一张预订记录板攻击者下单了一万个“永远不来但又不取消”的座位真正的客人到了之后发现系统显示满客。服务器虽然还活着但对用户来说它已经“不存在”了。SYN Flood可怕的地方不在于流量大小而在于它以极低的成本占满连接表。2.3 反射放大攻击借别人的手打你网络层DDoS里反射放大攻击属于杀伤力最大的一类“代打”模式。它的原理是攻击者伪造受害者的IP作为源地址向大量开放的UDP协议服务比如DNS解析器、NTP时间同步服务发送小体积的查询请求。这些服务器收到请求后会把响应数据包发到伪造的源地址——也就是受害者那里。由于这些UDP协议的特性响应体积往往远大于请求体积能达到几十倍的放大效果。这里有一个关键点很多UDP协议本身不校验源地址真实性攻击者可以自由伪装。当攻击者同时驱动成千上万的反射节点时受害者收到的就是来自“全世界服务器”的洪水。这也是为何在防御层很难通过“封禁某个固定IP”来解决问题——源头是分散的而且真正发起请求的服务器都是无辜的。2.4 应用层攻击打的是“像人一样的访问”应用层DDoS更隐蔽它针对的是业务逻辑。攻击者完整走完TCP握手发起看似正常的HTTP请求比如反复请求一个复杂的查询接口、下载大文件或者用极慢的速度发送请求头把连接长时间占住。这种流量清洗设备很难区分因为它从协议栈到应用层都是“合法的流量”如果清洗规则不精细误伤率会非常高。慢速攻击是我见过最“阴”的一种它正常建立连接之后每隔几十秒才发送几个字节。服务器在等待完整请求时可用的并发连接数是有上限的几十条这样的慢连接就能占满一个小型应用服务器。对付这类攻击光靠增加带宽完全没有作用必须在应用层配置响应超时和速率限制。3. 攻击类型全景先认清楚你的对手3.1 网络层洪水攻击把带宽彻底打爆UDP Flood和ICMP Flood是网络层的典型代表。攻击者向目标服务器发送大量随机端口的高速率UDP包或者用巨量ICMP Echo Request灌满链路。这类攻击的特点是不需要维护连接状态纯粹靠包量碾压。目标通常不是打挂某台服务器而是直接把机房带宽占满让合法流量进不来。从监控上看最典型的现象就是进出带宽完全不成比例入方向远远高于出方向。3.2 传输层状态耗尽攻击你的连接表是突破口传输层的SYN Flood、ACK Flood盯着的是操作系统的状态表。每一条TCP连接在服务器侧都要占用内存和文件描述符攻击者用伪造连接填满连接表之后正常的连接就无法建立。这类攻击和带宽没有直接关系几台服务器发起的小流量SYN Flood就能打瘫一台配置尚可的服务器。对应到监控指标就是SYN_RECV状态的连接数突然飙升、同时ESTABLISHED连接数不降但新连接成功率暴跌。3.3 应用层资源消耗攻击伪装成正常用户应用层攻击的目标从系统资源转移到了业务资源上。HTTP Flood是高频次的GET/POST请求模拟真人浏览、登录、搜索慢速攻击则在合法的TCP连接里拖时间。这类攻击如果频率控制得当很难和真实的高峰流量区分。CC攻击Challenge Collapsar行业里常这么叫也是应用层的典型手法它会精准地打最消耗资源的接口比如报表导出、数据库查询、文件上传。3.4 攻击类型速查表攻击类型攻击层次消耗的资源主要特征防御观察点UDP Flood网络层带宽、网络设备转发能力随机端口、高速率UDP包入带宽异常、UDP包速率骤增SYN Flood传输层半连接队列、内存SYN包速率高、半连接堆积SYN_RECV数量飙升ACK Flood传输层连接表、CPU中断大量ACK包但无业务流空包/小包速率异常HTTP Flood应用层应用进程、数据库连接高频访问同URL、UA规律单URL请求频率异常慢速攻击应用层应用并发连接池连接建立但请求头极慢大量空闲慢连接4. 检测先行在被攻击之前先学会发现攻击4.1 服务器侧“三张表”迅速定位第一次遭遇DDoS时我最容易犯的错就是盯着CPU和内存看。其实服务器侧排查DDoS最重要的三张“表”是连接状态表、网络接口计数器和进程开销。连接状态表用一条命令就能看ss -nat | awk {print $1} | sort | uniq -c。如果SYN_RECV状态的数量突然从几百冲到几万大概率被SYN Flood打了如果TIME_WAIT突然飙高可能是高并发或短连接风暴如果ESTABLISHED数量没变但连接建立越来越慢多半是系统资源或网络链路出问题。网络接口计数器用ifstat或者sar -n DEV 1来观察重点看packets/s每秒包数、rxkB/s入方向字节速率和drop丢包。DDoS的特征是pps每秒包数极高但单包极小这种流量往往会触发网卡中断瓶颈导致CPU softirq占用飙升。4.2 抓包确认只看关键信息在确认存在异常流量后抓包是判断攻击类型最直接的手段。抓包时不需要长时间留存全部流量抓个几百个包就足够看出门道。重点看三件事源IP是否分布异常、目标端口是否有规律、载荷内容是否重复。大量源IP分散且目标全是同一个端口配合TCP SYN标志位基本可以判定是SYN Flood。目标端口随机且数据包内容是乱码通常是UDP Flood。源IP较少但请求特征高度重复可能是应用层的CC攻击。抓包工具用系统自带或者常见的开源工具都行。需要注意抓包本身在高流量下也会消耗CPU建议在入口交换机做端口镜像在独立分析机上抓包不要在业务服务器上硬抓。4.3 建立有效告警阈值设多少才合理很多团队的告警体系只监控CPU、内存、磁盘这些指标对DDoS来说太钝了。我建议至少把以下几项纳入监控并配置“比率型”和“绝对值型”两类告警入方向带宽利用率超过总带宽的70%就要警惕。每秒SYN包数量相对正常基线上升3倍以上时触发告警。SYN_RECV连接数超过系统半连接队列阈值的一半时触发。应用响应时间P95出现阶梯式跳升时关注。“基线”是告警设置的核心逻辑。每个业务的正常流量特征不一样没有统一的绝对值。比如一个日活百万的平台和一个内部系统SYN包速率基线差了成百上千倍。先把历史一个月的流量数据拉出来取平均值和峰值再按“超过平均值3倍”来设告警是比较稳妥的做法。5. 防御体系从边缘到内核层层设防5.1 边缘层流量清洗与高防IP防御DDoS的第一道防线应该在离攻击源最近的边缘节点而不是业务服务器。商业高防IP的核心能力是把攻击流量引流到清洗集群识别并丢弃恶意流量后把清洗后的正常流量回源到服务器。选择高防服务时不能只看它“最大防护能力”的数字还要关注三个细节是否支持TCP/UDP协议全解析、清洗时延有多高、源站IP是否支持隐藏。这里有个实操要点源站IP的隐蔽是很多团队忽略的。高防IP只是入口如果源站IP泄露比如子域名解析、历史DNS记录泄露、邮件头泄露攻击者完全可以绕过高防直接打源站。正确做法是源站只允许来自高防节点的IP访问并关闭源站上的非必要端口。5.2 网络层路由层面的紧急控制当遭遇超大流量攻击时网络层有一些“粗糙但有效”的控制手段。黑洞路由是最极端的办法把受害IP的流量全部丢到黑洞业务也会中断但至少能保住整个网段的完好。黑洞路由一般由运营商或云服务商执行这属于紧急止损不是防御手段。ACL或入方向速率限制可以用来临时压制某种类型的流量比如在路由器上封禁异常的UDP目标端口但它的问题在于无法区分合法和非法流量容易误伤。我的经验是网络层控制只能是“紧急按钮”真正的防线还是要靠边缘清洗设备。日常运维时必须提前和网络服务商确认好应急联系方式否则攻击发生时临时找人响应链条会非常长。5.3 系统层内核参数加固实战在本地服务器上调整Linux内核参数能显著提高抗DDoS能力。下面这组参数是我在实践里验证过效果比较好的适用于大部分互联网业务场景# 开启SYN Cookie半连接队列满时仍能处理新建连接 net.ipv4.tcp_syncookies 1 # 收不到客户端ACK时不重传或只重传一次SYN-ACK减轻队列压力 net.ipv4.tcp_synack_retries 1 # 扩大半连接队列长度给正常连接更多缓冲空间 net.ipv4.tcp_max_syn_backlog 65535 # 关闭时间戳选项的RFC1323扩展减少处理开销视场景而定慎用 net.ipv4.tcp_timestamps 0 # 提高本地端口范围避免高并发下端口耗尽 net.ipv4.ip_local_port_range 1024 65535开启SYN Cookie是最关键的一步它让服务器在队列满时不再丢弃新SYN而是通过计算方式确认客户端后续ACK的合法性。对于真正的攻击仍然会消耗CPU做计算但相比被打挂至少能撑住一部分正常流量。这只会在极端情况下启用我个人建议保持开启。5.4 应用层Nginx限流与动态验证应用层的DDoS需要靠业务侧的限流来处理。Nginx提供了两个非常实用的模块limit_req和limit_conn。前者限制单位时间内的请求速率后者限制单IP的并发连接数。我常用的配置长这样# 定义限流区域按客户端IP1m共享内存速率20r/s limit_req_zone $binary_remote_addr zonereq_limit:10m rate20r/s; # 定义连接数限制区域按客户端IP最多20个并发 limit_conn_zone $binary_remote_addr zoneconn_limit:10m; server { location /api/ { # 请求速率限制超过则返回503 limit_req zonereq_limit burst40 nodelay; # 连接数限制 limit_conn conn_limit 20; } }如果业务被针对性的应用层攻击打中比如单接口被高频请求常规的IP限流不够用因为攻击源可能分布在几十万个IP上。这种时候需要引入验证码、客户端JavaScript挑战或者交给WAF做指纹识别靠“行为特征”而不是“来源”来区分人机。6. 典型DDoS应对全过程从告警到复盘6.1 确认攻击方向先判断打在哪一层收到告警后第一件事不是直接上防火墙封IP而是花两分钟判断攻击类型。看带宽面板带宽打满、pps极高大概率是网络层洪水。看连接状态SYN_RECV堆积、连接建立失败大概率是SYN Flood。看应用日志请求量大但来源集中在少数IP且请求路径高度一致大概率是应用层CC。我一直强调“确认攻击方向”这个动作是因为很多团队在应急时搞错了重点明明是SYN Flood却去调应用层限流结果根本不解决连接建立失败的问题。方向错了做什么都是白费。6.2 切换防护路径开启高防或清洗如果确认攻击流量已经超过本地带宽上限唯一的选择是立刻把流量切到高防线路。这是为什么要在攻击发生之前就准备好高防服务的原因。切换动作本身通常是把DNS解析或BGP路由指向高防IP操作很快但要注意DNS解析需要等待TTL过期业务域名如果TTL配置过长切换生效时间会拉得很长。当初我踩过这个坑所以后来把对外域名的TTL统一调整到了60秒左右。切换之后不要以为万事大吉。要持续观察清洗节点上的流量特征确认攻击方向是否保持不变。攻击者有时会观察到业务切到了高防转而换一种攻击方式比如从SYN Flood改成HTTP Flood这时候清洗策略也要跟着调整。6.3 本地加固与降载在切换高防的同时服务器本地也要做好降载操作。启用内核参数优化把Nginx/应用层的超时时间调短释放被占住的连接资源。对于确认为恶意的来源网段如果数量有限可以在服务器入口做临时封禁。但这里要特别注意在启用高防之后服务器只接收清洗后的流量正常的封禁动作应该在高防上做而不是在源站做否则会造成“防御链断路”。6.4 事后复盘把每一次攻击变成加固机会攻击结束后必须做完整复盘。把攻击期间捕获的数据包、监控图表、系统日志归档分析攻击特征源IP分布、攻击类型、持续时长、目标端口。复盘的核心产出不是报告而是三类可落地的改进防御策略调整比如高防清洗规则是否需要升级、监控阈值优化基线是否需要重新设定、架构改造源站是否需要进一步收敛暴露面。7. 常见误区与避坑清单7.1 误区防火墙能扛住DDoS这是新手最容易产生的误解。传统防火墙是为“过滤”设计的处理性能在万级pps以下还有余力但DDoS的流量动辄就是上百万pps防火墙本身的CPU和协议栈处理能力会在攻击流量下被打满变成新的瓶颈。即便开启了SYN Cookie功能的防火墙面对超大流量时也容易撑不住。防火墙应该用在该用的地方作为纵深防御的一部分而不是DDoS的第一道防线。7.2 误区封掉攻击IP就能解决对于小规模攻击封IP是有效的。但DDoS的常态是“源IP池”无限庞大且不断变化尤其是反射放大攻击源IP是无数个正常服务器封IP等于把自己和整个网络断开。不能把精力放在“抓真凶”上而要放在“让攻击流量到不了源站”上。7.3 误区带宽够大就安全带宽只决定“能承受多大的流量”但SYN Flood打的是连接表、应用层攻击打的是应用进程这些资源瓶颈和带宽没有必然关系。一条万兆链路如果服务器TCP栈在半连接队列上被打爆一样瘫痪。防御不能只买带宽要按攻击类型做完整的资源预算。7.4 避坑清单这些经验值钱源站IP不要暴露所有对外入口走高防/CDN同时定期检查解析记录和子域名防止源站被挖出来。域名TTL设置短一些应急切换高防时才不会等太久。高防服务要提前开通。攻击发生后再去找服务商从审核到配置通常要好几个小时业务早就挂了。监控里加一条“超时比例”DDoS发生时它往往比带宽更早报警。应急剧本要写下来脚本也要提前写好。现场打开编辑器现写脚本压力会放大到让人忘了还有Nginx。结尾最后说一点个人经验我做了这么多年安全运营最真切的体会是DDoS防御没法一劳永逸它是一个需要持续迭代的过程。攻击手法在变业务架构也在变昨天有效的清洗规则明天可能就有误伤。今天这篇文章里讲到的每一层防御单独拎出来都可能在特定场景下失效但组合在一起、提前演练过它就能真正在关键时刻让业务活下去。不要等被打了才想起来搭建防护。把基础监控做好、把高防服务提前接入、把应急预案写好、把内核参数调优这些事情都是花几个小时就能完成的但它们决定了灾难来临时你是手忙脚乱还是游刃有余。
