企业官网建设流程全解析

这两年我处理过的DDoS攻击事件，两只手数不过来。从几Gbps的“小打小闹”，到上百Gbps直接把机房交换机打到告警的“大场面”都有。每次接到客户的电话，第一句话基本都是“网站打不开了”，第二句是“是不是被攻击了”。大多数情况下，确实是。DDoS这东西，从原理到防御，说起来并不复杂，但真到了扛攻击的时候，考验的是你对原理的理解够不够透彻，以及手里的防御手段能不能对症下药。这篇文章我就把TCP、UDP、CC这几类最常见的攻击方式和对应的防御策略，掰开揉碎讲清楚，都是实战里用得上的东西。

先说清楚一个概念，很多人把DoS和DDoS混着说，其实有区别。DoS（Denial of Service）是单点攻击，一台机器发恶意流量，把目标打瘫；DDoS（Distributed Denial of Service）是分布式攻击，成百上千台“肉鸡”组成僵尸网络同时发难，攻击源分布广，隐藏深，用传统的单IP封禁基本没用。现在的攻击基本都是DDoS，所以下面主要以DDoS为主来聊。

1. 先建立整体认知：DDoS攻击到底在干什么

理解DDoS，核心就一句话：耗尽目标资源，让合法用户无法访问。这里的“资源”分好几种，理解了资源类型，你才能理解为什么不同的攻击手法效果差别那么大。

第一类是带宽资源。服务器的出口带宽是有限的，比如你租了100Mbps的带宽，攻击者用几百台肉鸡每台发出满速的UDP包，瞬间就能把带宽打满。带宽满了的直接后果是正常用户的请求进不来，网站自然就“失联”了。这种攻击没什么技术含量，纯粹比的是谁流量大。

第二类是连接资源。服务器能同时维持的TCP连接数量是有限的，内存、文件描述符、连接表都有上限。攻击者发起大量半连接（握手不完成）或者全连接（握手完成但不发业务请求），把连接表占满，新来的正常连接就没办法建立了。这类攻击不需要很大的流量，几万个虚假连接就可能让一台服务器瘫痪，是技术含量较高也最难缠的类型。

第三类是应用资源。CPU、数据库连接、进程处理能力，这些都是应用层资源。攻击者模拟真实业务请求，比如频繁调用某个查询接口、反复刷新某个动态页面，让服务器把计算资源都消耗在处理无效请求上，数据库连接的池子被占满后，正常用户的请求就只能排队等死。这就是CC攻击的思路。

理解了这三类资源消耗，你再去看各种攻击手法就会清晰很多：有的攻击是为了打满带宽，有的攻击是为了占满连接，有的攻击是为了拖垮应用。对应的防御思路也自然分成了三层：网络层流量清洗、系统/网络层连接防护、应用层请求过滤。

这里还要纠正一个误区：很多人以为只有大流量才算DDoS。实际上，针对应用层的慢速攻击，每秒几个请求就能造成严重后果，这种攻击更难检测，也更考验防御策略的设计。

提示：判断一次攻击的类型，不要只看流量大小，要看你服务不可用的具体表现。带宽被打满是“全站所有服务都异常”，连接被占满往往是“连接超时但轻量接口还能通”，应用层攻击则是“部分接口很卡但ping完全正常”。这个在后面排查部分细讲。

2. 原理拆解：三类最常见的攻击武器

2.1 TCP类攻击：SYN Flood为什么那么难缠

TCP类攻击里，SYN Flood是当之无愧的“经典之王”，也是最容易复现的攻击方式。

要理解SYN Flood，得先复习TCP三次握手。正常情况下，客户端发一个SYN包，服务器回一个SYN-ACK包，客户端再回一个ACK包，连接建立成功。服务器在收到SYN发送SYN-ACK后，会进入SYN_RECV状态，把这个半连接记录在连接表里，等待客户端的ACK。如果客户端一直不回ACK，这个半连接会占用连接表资源，直到超时释放（通常几十秒到几分钟）。

SYN Flood的攻击逻辑就是滥用这个机制：攻击者发送大量伪造源IP的SYN包，服务器收到后按地址回SYN-ACK，但这个地址根本不存在或者不回包，于是连接表里堆积了大量SYN_RECV状态的半连接。连接表容量是有限的，占满之后，新的合法连接请求（包括你自己的正常访客）就会被丢弃，表现为服务器无法接受新连接。

我见过一个典型的案例：某电商平台在促销期间被SYN Flood打了两个小时，从监控上看入向流量其实只有200Mbps左右，服务器CPU和内存都正常，但就是所有新用户都连不上。原因就是连接表被半连接塞满了。这种攻击最阴险的地方在于，它不需要很大的带宽，只需要有足够多的源IP来绕过连接相关的限制。

防御SYN Flood，业界有几板斧：一是启用SYN Cookie机制，服务器不再为每个SYN分配连接表条目，而是通过加密计算生成一个Cookie放在SYN-ACK里，等客户端回ACK时验证Cookie后才建立连接，从机制上杜绝了半连接占满连接表的问题；二是在网络层对超时半连接进行清理，设置较短的SYN超时时间；三是在防火墙上做源IP速率限制，或直接启用代理模式中继连接。这些手段可以组合使用，后面我详细讲配置。

2.2 UDP类攻击：大流量打满带宽的简单粗暴

UDP类攻击的思路简单很多：UDP是无连接的协议，接收端收到UDP包后不需要握手确认，只能被动处理。攻击者利用大量肉鸡向目标发送海量UDP数据包，直接打满带宽。

典型的UDP攻击流量通常是随机源端口、随机源IP发往目标的随机或固定端口。目标服务器收到这些UDP包之后，如果对应的端口没有服务监听，系统会回送ICMP Port Unreachable报文，这反过来又会占用服务器和网络设备的中断处理能力。攻击流量加上回程的ICMP流量，双重消耗主机资源。

还有一种破坏力很强的UDP攻击方式叫放大攻击，最出名的是DNS放大攻击。攻击者向开放的DNS递归服务器发送源IP伪装成受害者的查询请求，而DNS响应报文通常比查询报文大几十倍（比如一个几十字节的ANY查询，响应可能是几百到几千字节）。攻击者借助大量开放的DNS服务器作为“放大器”，用很小的带宽放大出巨大的流量，定向打到受害者身上。我见过一次DNS放大攻击，攻击端实际带宽不到100Mbps，打到目标机房的流量却接近20Gbps，这就是放大的威力。

UDP攻击的防御核心在于流量清洗和带宽冗余。清洗设备会识别UDP流量的来源、大小、频率，对于畸形包、超大数据包、异常高频率的源IP直接丢弃。如果你的业务不使用UDP协议，最省事的方式就是在防火墙上直接阻断外部入向的UDP流量，阻断后攻击流量照样打到机房出口带宽上，但至少服务器不再需要处理这些包。要真正缓解大流量UDP攻击，还是需要上游运营商或高防节点的带宽冗余来消化攻击流量。

注意：不要试图用“封IP”来解决UDP Flood。UDP攻击的源IP基本是伪造的，如果攻击者使用真实的肉鸡IP，你也很难封完——肉鸡数量动辄几万几十万。正确的做法是依赖清洗设备和足够的带宽冗余，而不是逐条封禁IP。

2.3 CC攻击：盯上应用层的“慢刀子”

CC攻击（Challenge Collapsar，国内习惯叫法，国际上统称HTTP Flood）跟SYN Flood、UDP Flood完全不同，它的攻击目标不是网络层和系统层，而是应用层。

CC攻击的原理是模拟真实用户行为，向目标Web应用发送大量看似正常的HTTP请求。攻击者通常会挑选服务器处理成本最高的接口，比如需要查询数据库的动态页面、需要上传文件/处理图片的接口、需要调用外部服务的接口。这些接口平均响应时间本来就长，攻击者用大量肉鸡（或者用工具不断变换IP）同时请求，应用服务器的线程池、数据库连接池、CPU资源很快会被耗尽。

CC攻击为什么难防？因为它看起来太“正常”了。同样是发送GET请求，攻击流量和正常用户流量在协议层面没有任何区别——都符合HTTP规范，都是合法的TCP连接，甚至请求头都是完整的。传统的防火墙和ACL规则在这种攻击面前基本失效，因为它们区分不出“这个请求是真人发的还是程序发的”。

比较常用的CC攻击变种是“慢速攻击”，攻击者建立连接后慢慢发送请求头，每次只发几个字节，让服务器一直等待完整请求，长时间占用连接资源。最典型的实现就是Slowloris。对付这种慢速攻击，靠的是在反向代理层设置请求头和请求体超时时间，超时就直接断开连接。

CC攻击的检测和防护需要一层额外的“行为识别”逻辑：统计每个源IP的请求频率、请求路径分布、User-Agent特征、HTTP版本等，对异常高频的请求进行验证码挑战、临时封禁或限流。具体的防护策略在后面应用层防护章节展开。

为了让你对这几种攻击有个直观的对比，我整理了一张常见的攻击对比表：

3. 防御体系设计：从链路层到应用层的分层对抗

3.1 网络层防护：流量清洗和黑洞路由

网络层的防护目标很明确：在不影响正常业务的前提下，把恶意流量丢弃在目标服务器之外。这个目标听起来简单，实现起来却需要一套完整的防护体系。

最关键的是流量清洗。清洗的原理是在网络入口处对全量流量进行分析，区分正常流量和攻击流量，只把清洗后的正常流量转发给源站。专业的清洗设备通常具备几种能力：DDoS指纹识别（对SYN Flood、UDP Flood这类特定协议特征进行识别）、行为分析（IP流量模型异常检测）、限速和端口阻断。部署方式通常是把流量牵引到清洗设备，清洗完再回注到源站。

然后是带宽冗余。再怎么清洗，如果攻击流量超过了你的出口物理带宽，那一切防御都白搭——因为流量在到达清洗设备之前已经堵死了。所以高防机房才那么贵，本质上是为带宽冗余买单。对于小体量的攻击，一个几百Gbps的高防节点绰绰有余；对于上百Gbps的大流量攻击，需要有分布式防护节点做流量分散。

黑洞路由是最不得已的手段。当攻击流量大到超出所有防御能力时，运营商层面的做法是把受害IP的流量直接丢弃，所有到该IP的流量全部进黑洞。这种做法谁都不愿意用，因为意味着你的服务彻底断网。但它是防止攻击波及整个机房（甚至整个网络）的最后防线。我记得某机房在一次超大流量的攻击中被迫对受害客户IP实施了黑洞，虽然客户服务中断了几小时，但如果黑洞不及时，整个机房的交换设备都可能被击穿，影响更大。

对大多数中小团队来说，自己建设完整的DDoS清洗系统并不现实。更务实的方式是选择高防服务（高防IP/高防CDN），把攻击流量引流到高防节点，由服务商来承担流量清洗的职责。高防方案的重点配置参数包括：防护带宽（决定能抗多大流量）、清洗策略（SYN Cookie是否开启、分片包是否丢弃等）、封禁阈值（过多大流量触发黑洞或告警）、回源方式（按域名回源还是按IP回源）。配置时需要结合自己的真实业务流量基线来定，阈值设太低容易误杀，设太高起不到防护作用。

3.2 应用层防护：CC攻击的针对性拦截

应用层防御的核心是“维持服务可用性”。即使有清洗设备挡住了大部分SYN Flood和UDP Flood，CC攻击这种形态还是会穿透到应用层。所以你的应用层也必须有对应的防护手段。

第一招是缓存策略。CC攻击之所以难防，是因为每个请求都会触发后端处理。如果能让大部分请求命中缓存，后端压力会大幅下降。静态资源（图片、JS、CSS）交给CDN缓存；查询类的动态接口，如果数据实时性要求不高，也尽量做边缘缓存。缓存是最优雅的CC防护方式，因为它不仅防攻击，还提升了正常用户的访问速度。

第二招是行为分析。在Web应用防火墙或反向代理层，对请求做频率统计和特征提取。同一IP请求频率超过阈值（比如每秒10次）就触发验证码；同一IP短时间请求大量不同URL（遍历式攻击特征）就限流；User-Agent异常（比如所有请求都是相同的非浏览器UA）就直接拦截。有些商业WAF产品还支持动态指纹识别，对频繁变化的UA特征做聚类分析，识别准确率更高。

第三招是验证码和身份验证。对疑似攻击的IP返回一个验证码页面，要求用户完成JS挑战或图形验证码。攻击脚本通常不会执行JavaScript，也不会识别图形验证码，这一招能过滤掉大量自动化的CC工具。但对那些带headless浏览器的重型攻击流量，验证码的效果会打折扣，此时需要配合IP信誉库和威胁情报一起判断。

第四招是限流和降级。在网关层配置每IP QPS限制，超出部分返回友好提示或直接拒绝；同时设置全局并发限制，防止某个接口被耗尽。对于非核心业务接口，可以做一个降级开关，攻击期间自动返回兜底数据，牺牲部分灵活性来保证核心业务可用。

提示：CC攻击的防护要特别注意“误杀”问题。在CDN节点后面部署防护时，你看到的源IP可能是CDN节点的IP，而不是真实用户IP，如果按单IP限流，会把大量正常用户误杀。正确做法是解析真实用户IP（通过X-Forwarded-For头），或者按会话维度做统计。

3.3 架构层加固：把单点拆成多点

架构层面的防御思路跟前面都不一样：前面是想方设法“挡”，架构层面是“扛”。即使攻击穿透了第一道防线，只要你的架构足够冗余，服务依然能撑住。

最简单有效的架构加固方式就是多节点部署。把服务部署在多个机房的多个可用区，前面用负载均衡调度。当某个机房遭遇大流量攻击时，可以把流量切换到其他机房。攻击者的目标是打瘫你的服务，如果你的服务在多处都有副本，对方的攻击成本就大大提高了。

更进一步的做法是弹性伸缩。很多云平台支持根据流量自动扩容计算节点，即使攻击导致个别节点CPU飙高，系统也能通过快速启动新节点来分摊压力。对于CC攻击这招非常管用——攻击消耗你的计算资源，你就快速补充资源，让攻击成本远高于防御成本，很多攻击者会自动放弃。

架构层面还要注意数据库的防护。应用层可能扛住了攻击，但数据库连接池一旦被占满就很容易引发级联故障。常规做法包括：给数据库设置最大连接数、开启连接池复用、对慢查询做熔断。另外，把数据库从应用服务器中独立出去部署，即使应用被攻击，数据库也不至于被拖垮。

还有一点容易被忽略：DNS解析层面的防护。DDoS攻击者常常会尝试直接攻击DNS服务（DNS解析是服务的入口，DNS挂了用户域名解析不了，服务一样不可达）。确保DNS服务有充足的冗余和防护能力，比如用多组独立DNS服务商、开启DNSSEC（这个按需选配），同时避免把DNS服务器和业务服务器放在同一网络设备下。

4. 实操记录：一次典型DDoS应急响应全过程

理论讲完了，我拿一次真实处理过的应急响应案例来演示完整的实操流程。这里把技术细节稍作修改，但整体过程是原汁原味的。希望大家看完能对“理论怎么落实到行动”有更具体的把握。

4.1 攻击识别：从现象判断攻击类型

某天下午三点，客户A的电商平台突然出现大面积访问超时。我登录服务器查看，首先看网络层情况。

# 查看网卡流量 sar -n DEV 1 5 # 查看TCP连接状态统计 ss -ant | awk '{print $1}' | sort | uniq -c

第一眼看sar的输出，入向流量从日常的50Mbps飙升到2Gbps左右，判断基本可以锁定是DDoS。再看ss的输出，SYN_RECV状态连接有数万个，远超正常水平——这是SYN Flood的典型特征。同时发现UDP端口流量异常，大量发往随机端口的UDP包。

进一步确认，查看连接表和实时抓包：

# 查看SYN_RECV状态的源IP ss -ant | grep SYN-RECV | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20 # 抓包分析 tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-syn != 0' -c 1000

抓包结果里大量源IP集中在少数几个IP段，并且TTL值比较统一，判断攻击流量来自一批被控肉鸡，而非真实用户。结合入向带宽大、SYN_RECV连接多这两个特征，判断为SYN Flood和UDP Flood的混合攻击，流量规模约2Gbps。

4.2 Linux系统层面的应急调优

确认攻击类型后，在防护设备还在调整策略的同时，我需要在服务器本地做紧急调优，减少攻击对系统的影响。

第一项是启用SYN Cookie，这是对付SYN Flood最有效的一招：

# 永久启用 echo 1 > /proc/sys/net/ipv4/tcp_syncookies # 设置SYN重试次数（缩短半连接占用时间） echo 1 > /proc/sys/net/ipv4/tcp_syn_retries # 设置SYN-ACK重试次数 echo 1 > /proc/sys/net/ipv4/tcp_synack_retries # 设置SYN队列长度（适当调大，配合SYN Cookie能缓存更多合法连接） echo 4096 > /proc/sys/net/ipv4/tcp_max_syn_backlog

第二项是减少UDP包对系统的冲击。因为客户的业务完全不用UDP协议，所以直接在防火墙层丢弃所有入向UDP包：

iptables -I INPUT -p udp --dport 0:65535 -j DROP

注意这里只丢弃入向UDP，不影响出向UDP。如果服务不需要对外提供UDP能力，这招效果立竿见影。

第三项是tcp_tw_reuse（TIME_WAIT连接复用）和文件描述符调整：

echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle # 注意：部分内核版本已移除该参数 ulimit -n 65535

需要特别提醒：tcp_tw_recycle在NAT环境下会导致部分客户端连接异常，新版内核已经废弃。如果非要调，先确认你的内核版本。这属于经验问题，很多运维老手在新内核上沿用旧习惯，反而踩坑。

第四项是缩短应用层的超时时间。对于被大量fake连接挂住的应用线程，超时时间太长会导致线程被无效连接占据。把Web服务的空闲超时从默认的60秒缩短到10秒左右，能更快释放被占用的线程资源。

4.3 防御策略的落地与效果评估

服务器本地的紧急调优只能减轻影响，真正的防线还是在高防节点上。客户的业务已经接了高防IP，我把流量切到了高防，在控制台上调整清洗策略。

清洗策略调整了几个关键参数：SYN报文速率阈值从默认的5000pps拉低到2000pps，超过即触发SYN Cookie机制；UDP报文速率阈值从默认的3000pps拉低到1000pps，超过的UDP流量一律丢弃；同时开启了畸形报文过滤、分片包丢弃规则。

流量切换到高防后，入向攻击流量被清洗节点接住，真正到达源站的只有清洗后的正常流量。我同时观察sar和ss的输出，SYN_RECV的数量在两分钟内从数万个掉到几百个，网卡入向流量恢复到正常水平，网站恢复可访问。

这次攻击持续了大约4个小时，后面流量逐渐减弱后结束。复盘来看，服务器本地的紧急调优为高防策略生效争取了时间，而高防节点承担了主要的流量清洗任务。这套“本地调优+云清洗”的组合是处理DDoS最务实有效的组合方式。

4.4 应急响应的通用SOP

这次处理过程我总结成一套通用SOP，推荐你直接参考使用：

攻击确认阶段（前5分钟）

• 查看网卡流量，判断是否异常巨大
• 查看TCP连接状态，重点关注SYN_RECV、TIME_WAIT、ESTABLISHED数量
• 使用tcpdump抓包，确认攻击源IP特征和报文类型

紧急缓解阶段（5-30分钟）

• 启用SYN Cookie，调整TCP相关内核参数
• 在防火墙上阻断非业务端口的流量
• 启用高防节点，切换流量到清洗链路
• 必要时启用CDN，让静态资源从边缘节点分发

持续对抗阶段（30分钟-数小时）

• 持续观察攻击流量趋势，动态调整清洗阈值
• 对应用层请求进行频率限制，缓解CC攻击渗透
• 检查服务器负载和日志，排查异常请求模式
• 与上游机房/高防服务商保持沟通，必要时协同处置

复盘总结阶段（攻击结束后）

• 导出攻击期间的全量监控数据和访问日志
• 分析攻击类型、攻击源特征、攻击峰值
• 评估现有防御策略的有效性，调整防护阈值配置
• 针对暴露出来的薄弱环节进行加固

这套SOP的核心原则是：先恢复服务，再论修复。攻击发生时不要纠结于揪出攻击源（基本做不到），而是尽快把流量切到有防护能力的地方，让服务先恢复可用。

5. 常见问题与排查技巧实录

在实际处理DDoS的过程中，会遇到各种容易误判或处理不当的情况。这里把经常踩的坑和判断技巧整理成速查表，供大家参考。

再补充几个排查中的独家心得。

第一，用ping做判断要小心。很多新手发现“服务器ping不通”就认定被攻击了，其实不一定。机房防火墙常常会主动丢弃ICMP报文，目的是隐藏服务器真实状态，导致ping不通但服务正常的情况很常见。反过来，服务异常但ping正常的情况也经常发生（CC攻击时就是如此）。所以ping的结果只能作为参考，不能作为攻击判断的唯一依据。

第二，抓包是定位攻击类型最直接的手段。我强烈建议在服务器上常驻一个tcpdump或ngrep，攻击发生时立刻抓10秒的包，看报文特征。SYN Flood的报文特征是全是SYN包且无后续；UDP Flood的报文特征是大量UDP小包、随机端口；CC攻击的报文特征则是完整的HTTP请求且UA固定或随机变化。抓包一秒钟能确认的事，靠猜可能要猜半天。

第三，源IP的封禁操作要非常谨慎。我见过一个案例：某运营小伙伴在攻击期间封禁了某个“异常”IP段，结果发现那是CDN节点的IP段，误伤了大量正常请求。正确做法是：先把流量中明显恶意的源IP段加入黑名单，但只封那些确认是肉鸡的IP段；对于不确定的，优先使用限速而非封禁。封禁操作最好在明确了攻击特征之后再执行。

第四，注意区分“大流量攻击”和“低速率攻击”。很多防御方案都聚焦在应对大流量上，但对低速率、高隐蔽性的攻击（比如慢速CC攻击、Slowloris）防范不足。这类攻击恰恰是中小团队最容易被击穿的点。建议在每次演练中专门设置低速率攻击场景，确保护栏策略全覆盖，而不只是盯着大流量看监控大屏。

6. 工具与资源盘点：实用的检测和演练方案

除了商业高防和WAF，开源生态里也有不少好用的工具，适合做检测、应急和演练。

检测与监控方面，最常用的是netdata和Prometheus+Grafana的组合。netdata部署简单，单机监控能看到实时流量和连接状态，非常适合攻击发生时快速查看；Prometheus适合做长期指标采集和历史趋势分析，能帮你建立“正常流量基线”，这个基线对判断攻击时什么样才算异常非常重要。如果资源允许，建议把Zabbix也用起来，它足够老练、稳定。

抓包与分析工具，tcpdump是首选，功能强大、资源占用低；Wireshark适合做深度分析和协议解码。在安全分析场景中，还可以用Bro/Zeek来做协议分析和异常检测，功能全面但配置相对复杂。

攻击演练工具方面，除了最常见的hping3（可以模拟SYN Flood、UDP Flood、ICMP Flood），还有几个专门做DDoS测试的工具。注意：这些工具只能在授权环境下使用，对未经授权的目标进行攻击测试是违法的，这一点请一定遵守。演练环境的搭建建议：用一个独立的测试环境，服务器用云主机或本地虚拟机部署，测试工具装在另一个隔离的网段里，攻击目标限定在环境内部IP。

有一个经常被忽略但非常有效的演练项目是“故障注入”。在测试环境中人为触发各种异常（如拔掉一块网卡、清空缓冲区、模拟高延迟），观察服务的降级表现。这样即使没有真实攻击，也能检验你的架构是否具备足够的容错能力。

我在实际经历中体会到，工具不在多，关键是组合怎么用。监控工具负责报警，帮你第一时间发现攻击；抓包工具负责取证，帮你确认攻击类型；防御工具负责对抗，帮你消除攻击影响；演练工具负责训练，让你的团队在真实攻击发生时能冷静应对。这四类工具各司其职，组合起来才是一个完整的防御链路。