企业官网建设流程全解析

半夜两点，某客户的手机连着震了三次，监控大屏上业务可用率已经跌到个位数，登录后台一看，带宽监控直接拉满成一条平线，ECS的CPU跑到了99%。这种场景对做运维或者管网站的人来说都不陌生：网站要么慢得打不开，要么干脆拒绝连接，看起来像极了DDoS攻击，但万一只是促销活动把服务器打崩了，或者某个接口代码出了死循环呢？

判断“是不是DDoS”，比“怎么防DDoS”更优先。方向错了，后续所有处置都是白费力气。基于我这些年的应急经验，真正靠谱的判断方式不是凭感觉，而是看四个高度可复用的特征。只要这四个特征对得上，基本就可以确定是DDoS，然后才能谈清洗和封禁。

1. 判定的底层逻辑：为什么靠特征就能确认

1.1 先搞明白DDoS到底在攻击什么

DDoS的全称是分布式拒绝服务攻击，核心目的只有一个：用大量来自不同来源的请求或数据包，把目标系统的计算资源、网络带宽或者连接会话耗尽，让正常用户无法访问。

要判断自己是不是在被攻击，必须先搞清楚攻击者在打哪一层。常见的有两种：一种是网络层攻击，比如SYN Flood、UDP Flood，特点是直接打满带宽或者耗尽连接表；另一种是应用层攻击，比如HTTP Flood、慢速连接攻击，特点是流量看起来不大，但每个请求都让服务器付出高昂的计算代价。

如果分不清层次，判断方法就容易走偏。比如只看带宽，应用层攻击的带宽占用可能只有几十兆，但CPU已经被拖垮。所以特征判断一定得从多个维度同时观察，不能只盯一个指标。

1.2 四个特征为什么可信

我自己总结这四个特征，核心依据是“正常流量和攻击流量在统计学分布上存在本质差异”。

一个真实的用户访问链路由无数个独立的个体组成，来源地域分散、访问节奏有快有慢、请求路径五花八门。而DDoS流量由程序化的僵尸网络或脚本批量发起，它们的来源高度集中（通常是同一批受控设备），访问节奏整齐划一，请求路径重复率极高。这四个特征，本质上就是抓“程序化流量”露出的马脚。

可信度来源于对照。把攻击时的流量特征、正常高峰期的流量特征、以及攻击停止后的流量特征放一起对比，你会发现攻击状态下的数据分布极度异常，这种异常不是靠几台服务器跑高负载就能模拟出来的。

2. 四个核心特征逐一拆解

2.1 特征一：源IP数量与地理分布极端异常

正常业务的访问来源，在IP维度上应该呈现长尾分布。哪怕你的业务没有做任何地域限制，来自全国乃至全球的用户IP也应该是相对离散的，单个IP的请求占比通常不会高得离谱。

被DDoS攻击时，这个特征会瞬间被打破。最典型的表现是：连接数或请求数被海量IP占据，但这些IP的请求行为高度一致，而且很多IP甚至不在业务目标地区。比如一个只面向国内用户的服务，突然涌入大量来自海外数据中心的IP访问，这就非常可疑。

实操中怎么快速判断？登录服务器执行：

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n | tail -20

这条命令会统计当前TCP连接中来源IP的出现次数，并倒序排列。正常情况下，前几个IP的连接占比不会特别夸张。如果发现前5个IP就占了一半以上的连接，甚至出现一个IP建立了几千个连接，基本可以断定有异常流量在试图耗尽连接表。

另一个观察维度是IP总数。正常业务即使流量再大，活跃源IP也是有限数量级，可能是几千到几万。而DDoS攻击的僵尸网络动辄几万几十万的独立IP同时发起请求。可以对比攻击前后各小时的独立IP总数，如果出现数量级的跳变，这就是攻击的直接证据。

注意：有些攻击会伪造源IP，也就是IP本身是随机生成的假地址。这种情况在SYN Flood里尤其常见，服务器的半连接队列会暴涨，但来源IP分布看起来反而“很均匀”，因为所有IP都是假的。此时不能只看IP统计，要结合下面的其他特征一起判断。

2.2 特征二：流量行为完全不像“人”

人访问网站是有行为特征的：点击页面后停留几秒，滚动浏览，不同用户访问路径不同，请求间隔随机。即使在高并发促销场景，用户的真实行为也会在时间轴上呈现出自然的随机波动。

攻击流量没有这些“人性”。最典型的三类异常行为：

• 请求频率整齐划一：大量来源IP在相同的时间点发起请求，间隔极其规律。比如每秒发出5个请求，所有IP都严格遵循这个频率。
• 请求路径高度集中：攻击通常只针对某一个消耗资源的接口或页面反复请求，比如登录接口、搜索接口、首页。正常用户根本不会在短时间内只访问一个URL。
• User-Agent与Referer异常：攻击脚本常常使用固定或伪造的浏览器标识。如果某段时间所有请求的UA都集中在一两个值，或者Referer完全为空或指向同一个来源，这本身就是一个危险信号。

这个阶段建议配合Web访问日志做分析。比如Nginx日志，可以抽样统计某时间段内访问前十的URL及其请求次数占比。正常业务的TOP URL占比一般不会超过20%到30%。如果是攻击，单个URL可能占到80%甚至90%以上。

awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

这条命令会输出访问量最大的10个URL路径。如果发现排名第一的路径请求数远超其他路径总和，且该路径恰好是动态接口（比如登录、查询类接口），那就要高度警惕应用层攻击。

2.3 特征三：系统资源被同步“打满”

DDoS攻击的最终目的，是通过消耗资源达到拒绝服务。所以系统资源在短时间内被打满，是攻击成功的标志之一。这里要看的资源主要有三个：带宽、CPU、连接数。

带宽被打满是最直观的。如果服务器出网带宽持续在99%以上徘徊，而业务本身并没有大流量下载或直播场景，基本可以判断网络层攻击正在发生。可以用：

sar -n DEV 1 5

查看网卡每秒的收发流量。正常业务下，网卡流量曲线应该是波动状的，高峰期高、低谷期低。攻击发生时，这个曲线会变成一条接近完美的水平直线，数值顶到带宽上限。

CPU和内存则更偏向应用层攻击的特征。如果带宽占用并不高，但CPU跑满，而且top里显示的是业务进程消耗，比如Java进程或Nginx worker进程，那说明攻击请求已经穿越了网络层，打进了应用逻辑层，正在反复执行高消耗代码。

连接数这个指标同样关键。查看整体连接状态：

ss -s

输出中如果看到大量连接处于SYN-RECV状态，那多半是SYN Flood攻击；如果TIME_WAIT状态异常多，可能是短连接洪水。这两种状态的数量在正常情况下应该是很低的，一旦暴涨，TCP协议栈本身的处理能力就会被耗尽。

有一个容易踩的坑：很多人只看CPU或者只带宽，忽略了资源的联动性。实际上DDoS攻击经常是分层次的，攻击者先打网络层把带宽占住，再打应用层把CPU拉高，两个指标同时爆表才说明攻击是“真有效”的。如果只有一个指标异常，排查时要多留个心，可能是其他故障而非DDoS。

2.4 特征四：网络层与TCP连接状态呈现攻击模式

这个特征需要结合抓包和连接状态分析，它是四个特征里最具有确定性的。

正常的TCP三次握手过程中，服务器收到SYN后进入SYN-RECV状态，等待客户端回ACK，这个状态通常只存在几毫秒就被状态机推进。在DDoS攻击场景下，大量SYN包带着不可达的伪造源IP发过来，服务器发出去的SYN-ACK永远得不到回应，SYN-RECV连接就在队列里越积越多，最终半连接队列溢出，服务器拒绝一切新连接。

出现这种情况时，用tcpdump看一眼就能实锤：

tcpdump -i eth0 -n 'tcp[13] & 2 != 0'

这条命令抓取所有SYN包。如果抓包结果里SYN包的数量占比极高，而且多个源IP在极短时间内密集产生SYN请求，并且这些请求没有后续的ACK回包，那就是典型的SYN Flood形态。

还有一种值得注意的网络层攻击表现，是所有数据包的大小都异常一致。比如UDP Flood攻击，攻击者常发送固定大小的数据包打满带宽。抓包时会看到包长几乎都是同一数值，比如1400字节或者500字节，规律性极强。这一点与PPS（每秒数据包数）指标相映证——正常业务的PPS一般不会特别高，而UDP Flood的PPS可以轻松达到几百万甚至上千万。

TCP连接状态分析可以直观地用：

netstat -ant | awk '{print $6}' | sort | uniq -c

观察各状态的分布。正常状态下，ESTABLISHED占大头，SYN-RECV和TIME-WAIT各有少量。如果SYN-RECV突然几千几万，而ESTABLISHED持续下滑，那么网络层攻击的结论基本可以成立。

3. 怎么把“像”变成“实锤”：验证工具与命令实操

3.1 先用三条命令快速取证

遇到业务异常，留给你判断的时间非常短，大原则上越快越好。我自己的习惯是上服务器后固定先跑三条命令，用输出结果做第一轮交叉验证。

第一条看连接状态分布，判断是否为TCP层攻击：

ss -ant | awk '{print $1}' | sort | uniq -c

第二条看当前正在消耗连接的IP来源：

netstat -plan | grep :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

第三条看带宽和包量：

sar -n DEV 1 3

分别拿到连接状态分布、来源IP统计、网卡流量三项数据后，直接和上文提到的异常标准对照。三项里面有两项异常，基本就可以确定是DDoS，无需再等待更多的人工确认。

实战中我最常遇到的一种情况是：运维同学已经打开云厂商的监控后台，发现入带宽已经打满100M，但还在纠结“要不要提工单”。实际上不必迟疑，先把服务器的出口流量切断或者开启流量清洗，再继续定位，这才是正确的处置顺序。判断和处置不冲突，可以并行。

3.2 抓包看关键字段：从数据层面确认

命令行工具能告诉我们“看起来像什么”，抓包则能告诉我们“到底是什么”。抓包不需要抓全量，抓几秒钟就足够，关键是抓到攻击特征最明显的网卡流量。

tcpdump -i eth0 -c 5000 -nn -w attack.pcap

抓到pcap文件后，可以用Wireshark打开分析，也可以直接用tcpdump自带的统计能力查看协议分布：

tcpdump -r attack.pcap -nn | awk '{print $3}' | sort | uniq -c | sort -nr | head

重点看两个方面：

• 协议分布：如果UDP包占比异常高，而业务本身没有大流量UDP应用（如视频流），那就是UDP Flood。
• 包大小分布：用-nn -S参数查看包长度，如果绝大多数包长度相似，那是程序化打流特征。

比如前阵子某客户的服务器带宽被打满，抓包结果里出现了大量目标端口为53的UDP包，包长清一色是1200字节。原因很快清晰：攻击者都是在用伪造源IP向服务器的DNS端口发起UDP查询洪流。知道这一点的好处是，防护策略可以直接在防火墙层丢弃目标端口53的UDP包，问题立刻解决。

3.3 通过回源验证锁定攻击方向

有时候服务器前面已经有CDN或者高防IP，你看到的异常流量是源站回源流量，而不是攻击流量本身。这种情况需要多一个判断维度：回源验证。

具体操作是：确认业务配置的源站地址是不是暴露了。攻击者如果连源站IP都打不到，就只能打高防IP，这种情况下源站看到的流量应该是“正常的”——只有CDN节点的正常回源。如果源站看到大量非CDN回源IP段的请求，说明源站IP已经泄露，攻击者绕过了防护直打源站，此时判断结论不是“是否被攻击”，而是“防护是否已失效”。

云厂商的控制台一般都会提供“攻击IP TOP榜”或“清洗前/清洗后流量对比”，这个数据非常关键。清洗前的数据反映攻击真实规模，清洗后的数据反映正常业务流量基线。通过对比两张曲线，你可以轻易算出被攻击的强度，以及正常业务体量的大小，为后续扩容或者调整防护阈值提供依据。

回源验证环节还需要确认一个细节：业务侧有没有开启防火墙对源IP的访问限制。很多情况下，攻击者拿到的源站IP根本不是从DNS解析来的，而是从历史泄露的配置文件中翻出来的。此时光靠高防是拦不住的，必须同步做源站IP的访问白名单控制，将非CDN来源的请求全部拒绝。

4. 容易误判的几种情况要避开

4.1 突发流量不等于攻击

运营的同学半夜发来消息：“用户量暴涨500%，是不是被攻击了？”这类情况我处理过很多起，最后排查下来，有的是App被某平台推荐了，有的是新闻上了热搜带来大量访问，还有的是爬虫在短时间内疯狂抓取。

突发流量和DDoS攻击有一个核心区别：突发流量的用户是多点并发，请求路径分散，用户行为随机；DDoS攻击是程序化行为，请求路径集中，节奏规律。你把上面提到的行为特征拉出来逐条对照，就能判断个大概。如果时间来得及，还可以在页面埋点采集用户的鼠标轨迹、滚动行为这类客户端特征，正常用户的行为特征是攻击脚本完全模拟不了的。

4.2 恶意爬虫与业务突增的区别

爬虫是介于正常用户和DDoS之间的一种灰色流量。它会高频抓取，会集中访问目标URL，但通常规模不大、带宽占用不高，也不会恶意消耗连接表。判断时要看资源损耗的具体表现：爬虫的并发量一般是几十到几百，最多也就上千，不会把服务器直接打死；而DDoS攻击的并发量通常以万计，对资源的消耗是断崖式的。

如果确认是恶意爬虫在消耗资源，处理方式也和DDoS完全不同。DDoS需要流量清洗，爬虫只需要在接入层做UA和IP限速，或者加robots协议约束，甚至直接在WAF层封禁。

4.3 应用层CC与网络层DDoS的区分

有时候你的带宽很稳，但CPU狂飙，业务卡死。这时候要判断是网络层DDoS还是应用层CC攻击，两者的应对措施完全不同。

应用层CC攻击的特征是：请求量可能不是特别大，但每个请求都会触发业务逻辑中较重的计算，比如数据库查询、文件读取、加解密操作。攻击者的目标是让服务端反复执行这些重操作，累垮CPU和数据库连接池。

区分办法：用top看进程消耗，如果CPU消耗集中在业务进程，而且Web日志中某个API的访问频率极高、响应时间从几十毫秒涨到几秒，那大概率是CC攻击。与之对比，网络层DDoS时消耗最大的是内核网络栈，CPU可能花在软中断处理上。

应对CC攻击，流量清洗只能过滤一部分，更有效的手段是加Web应用防火墙，按访问频率和会话特征动态拦截可疑请求；而应对网络层DDoS，只能通过高防IP和流量清洗中心来扛。

5. 确认攻击后怎么办：快速处置思路

5.1 限速与黑洞时的取舍

判断确认是DDoS攻击后的第一反应是“赶紧把攻击流量挡住”，但挡的方法有讲究。

云服务商一般都提供“黑洞”策略，攻击流量超过一定阈值时会自动把IP的流量全部丢弃，服务器彻底不可访问。黑洞能止损，但也意味着正常业务也断了。所以操作上要区分情况：如果攻击量不是特别大，自己加防火墙规则限速即可；如果攻击量巨大且已超出防御能力，先黑洞止损，再启用高防产品，业务恢复优先于一切。

自己做iptables限速也可以作为一种临时方案，比如限制单IP最大并发连接数：

iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 -j DROP

但这个方法对付大流量分布式攻击几乎没有用。分布式攻击连接数分散在几万个IP上，单IP连接数根本超不了阈值。真正有效的防护还是依赖运营商级的高防清洗节点。

5.2 云上高防与人机校验的组合

经历过几次攻击后，我的建议是：重要业务不要裸奔，宁可花点成本也要前置高防。高防IP并不是一挂了之，要配合合理的清洗策略。

干净的业务和高防的配合方式：域名解析到高防IP，高防回源到源站；高防上配置清洗阈值，低于阈值正常放行，高于阈值自动清洗。同时开启人机校验（比如滑块验证），在攻击发生时自动弹出，把正常用户放行、把脚本请求挡在外面。

这套组合拳的有效性在于：高防负责扛掉大流量，人机校验负责过滤应用层的脚本请求，两者互补。只挂高防不打人机校验，遇到CC攻击照样会被拖死；只加人机校验没有高防，网络层一打直接就黑洞。

5.3 事后复盘要留什么

很多人处理完攻击就完事了，不做复盘，这是最大的失误。DDoS攻击很少有只打一波就收手的，攻击者通常会调整手法和规模再来一轮，复盘就是为了下一波更快速地定位和处理。

复盘至少要留三样东西：

• 攻击期间的完整抓包文件：保存原始数据包，用于分析攻击类型、来源、特征，也可以作为后续网络取证依据。
• 攻击前后的流量曲线截图：确认攻击的起止时间、攻击峰值、清洗效果，用于评估防护能力是否足够。
• 处置时间线记录：几点发现问题、几点确认类型、几点切换高防、几点业务恢复，每个环节花了多长时间。下次再遇到直接拿着时间线优化流程。

流量曲线里还有一个重要的信息是攻击的规律性。某些攻击者会固定在凌晨或者业务高峰期发动攻击，这个发现决定了你能否在下一波攻击来临前提前提高防御等级。

我在处置过程中养成了一个习惯：攻击结束后，马上在防护设备上增加一条针对此次攻击特征的临时封禁规则，不管这次攻击已经结束还是没有。原因是，同一批僵尸网络的IP和指纹特征停止后不会马上完全消失，在攻击停止后的数小时内，残留的扫描和探测请求依然存在。封掉它们，可以避免攻击者通过后门重新渗透。

关于DDoS攻击的判断，核心还是那句反复强调的话：不要只盯一个指标。四个特征里面至少两个同时满足才靠谱，因为任何单一的异常都可能是其他原因造成的误报。另外，遇到疑似攻击时建议顺手把攻击前后的“正常流量基线”记录下来，没有基线就没有参照，事后的数据分析容易失去方向。

个人实操里，我觉得最值得投资的不是复杂的检测工具，而是平时对业务的理解。你对业务正常状态下的流量模型、连接状态、请求路径越熟悉，异常出现时你判断的速度越快。攻击的处置窗口往往就那么几分钟，多熟悉一分自己的系统，就少一分被动。