难度系数：四星 ★★★★ (敏感词已被替换)

关键词：Web 、DoS 、日志 、蜜罐

故事人物：小王(网络管理员)

一、摘要：

本文详细探讨了Web服务器遭受DoS Attack时的检测与防御策略。文章通过实际案例，描述了在春节假期后Web服务器出现故障的情况，通过分析防火墙和路由器日志，发现异常流量特征，如大量UDP数据包和小数据包Attack，判断服务器可能遭受Attack。文章进一步分析了Attack原理和对服务的影响，如资源耗尽、性能下降和服务中断等，并提出了多种预防和缓解措施，包括网络入口过滤、流量速率限制、入侵检测系统、使用DDoS防护服务以及部署蜜罐诱骗Attack 等。

二、什么是DoS Attack

拒绝服务Attack(DoS)是一种通过各种手段阻止或拒绝合法用户访问网络服务器的破坏性Attack方式。从严格意义上讲，DoS 技术是一种破坏网络服务的技术手段，它通过人为或非人为的方式发起Attack，使主机的硬件、软件或网络资源无法正常工作，从而导致系统无法及时接收、处理或响应服务请求。这种Attack可以由网络内外的攻击者账户发起。

内部用户可能通过长时间占用系统资源(如内存和 CPU)来引发拒绝服务攻击，而外部攻击者则可能通过占用大量系统或网络资源的方式，使其他用户的请求无法得到及时处理，进而引发拒绝服务攻击。

TCP SYN泛洪攻击是一种典型DoS Attack，因为它通过恶意占用服务器的资源，导致服务器无法为正常用户提供服务。这种Attack方式对于网络系统的安全性和稳定性构成了严重威胁。

下面用四张动图来形象展示正常访问和TCP SYN泛洪攻击的过程。

1)正常的TCP三次握手

2)攻击者发送大量 SYN 请求来消耗目标服务器的资源。

3)服务器资源被大量消耗导致崩溃

4)当正常TCP连接到服务器时，服务端无法处理正常的连接请求，最终表现为Web服务器无法访问。

如果还是难以理解上述组图，那么不妨再举一个更贴近生活的例子：想象一下，许多恶意顾客(攻击者)涌入一家餐厅，他们纷纷占据座位却不点任何食物，就这样干坐着。随着这些“恶意顾客”越来越多，餐厅内的座位逐渐被全部占满。此时，真正想要用餐的顾客(正常用户)因为没有空位可坐，便无法享受到餐厅的服务。

攻击者光占座而不点餐：这类似于DoS Attack攻击者发送大量无意义的请求或数据包，占据服务器的资源(如连接队列、带宽等)，但并不进行正常的交互(如完成数据传输、处理请求等)。

直到把所有座位占满：这对应于攻击者通过大量请求耗尽服务器的资源，使服务器无法处理更多的请求。

理解了DOS，那么DDOS的概念就容易接受了，DDoS Attack，即分布式拒绝服务攻击(Distributed Denial of Service)，也是一种恶意网络攻击手段，其目的是通过大量虚假或恶意流量(通常攻击者会通过非常手段获取一个或多个僵尸网络获取庞大的带宽)淹没目标服务器或网络资源使其无法正常响应合法用户的请求，从而导致服务中断或瘫痪。

三、事件发生

春节假期刚刚结束，办公室里还弥漫着节日的余温。首个工作日的下午1点，小王像往常一样回到工位，解锁电脑，准备开始新一周的工作。屏幕上，Web服务器性能监控软件的图像突然映入眼帘——一条红色曲线正急速下滑，仿佛在无声地发出警报。小王的心猛地一沉，他知道，这绝不是什么好兆头。

“服务器响应速度急剧下降！”小王暗自嘀咕，他的手指迅速在键盘上敲击，打开Web服务器的日志文件。就在这时，公司首席运营官(CIO)急匆匆地走了过来，脸上写满了焦虑：“小王，客户反馈说网站完全无法访问了！”

小王的心提到了嗓子眼。他迅速从自己的台式电脑上打开浏览器，输入公司网址。几秒钟后，屏幕上弹出了一个令人不安的提示：“无法访问此页面”。这一刻，他意识到，一场危机已经悄然降临。

小王皱着眉头，努力回想起春节放假前对Web服务器的操作记录。他清楚地记得，这几天自己并没有对服务器进行任何更改或操作，服务器之前也一直运行得非常平稳，从未出现过类似的性能问题。这突如其来的故障，让他感到一丝不安。

他迅速打开Web服务器的日志文件，仔细翻阅着一行行记录，希望能找到一丝线索。然而，日志中没有任何可疑之处，一切看起来都正常得令人费解。小王的眉头锁得更紧了，他的直觉告诉他，问题肯定出在别处。

“如果服务器日志没问题，那会不会是网络层面出了问题？”小王心中一动，决定进一步查看防火墙日志和路由器日志。他深吸一口气，试图让自己冷静下来，然后迅速切换到防火墙的管理界面，开始仔细检查。

时间一分一秒地过去，小王的眼睛紧紧盯着屏幕，不放过任何一条记录。终于，在一堆看似正常的日志中，他发现了一些异常的流量记录。他的心跳加速，随后将有代表性的可疑记录打印出来，并迅速过滤掉正常的流量，试图找出隐藏在其中的线索。以下是防火墙日志的可疑信息,如表1所示。

表1 防火墙日志

小王对表1中的内容进行了仔细分析，并从中总结了4个问题。

     1.异常流量特征

大量UDP数据包：端口号7的数据包确实使用UDP协议，但也有可能使用其他协议。因此，协议号为17，端口号为7的情况下，基本可以判定存在UDP数据包，那么我们从这些日志信息可以判定存在UDP数据包，数量很大，且这些数据包的源IP地址和源端口号各不相同，但目的IP地址均为192.168.0.175，目的端口号均为7。这表明有大量的UDP数据包被发送到Web服务器的回显端口，可能是攻击者在进行UDP洪水攻击。

     2.攻击源的多样性

多个源IP地址：日志中显示了多个不同的源IP地址，如172.16.45.2、10.166.166.166、10.168.45.3等，这表明攻击可能来自多个不同的源，具有分布式的特征，而且这些IP地址很可能是被篡改过，增加了追踪。

随机的源端口号：源端口号也各不相同，如7843、19、34511等，这可能是攻击者使用随机端口来发起攻击，以避免被防火墙规则拦截。

     3.攻击目标明确

特定目的IP和端口：所有异常流量的目的IP地址均为192.168.0.175，即Web服务器的IP地址，目的端口号均为7，即回显端口。这表明攻击者的目标非常明确，就是针对Web服务器的回显端口进行攻击，以消耗服务器的资源，导致服务中断。

    4.攻击的持续性和规律性

持续的流量记录：日志中记录了多个时间点的异常流量，这表明攻击是持续进行的，而不是偶发性的。攻击者可能在一段时间内持续不断地发送UDP数据包，以保持对服务器的压力。

规律性的数据包发送：从日志中可以看出，攻击者在不同的时间点发送了相似的UDP数据包，这可能表明攻击者使用了某种自动化工具或脚本来进行攻击，具有一定的规律性。

小王经过以上防火墙日志表1的内容分析，猜测Web服务器很可能遭受了UDP洪水攻击，攻击者通过发送大量UDP数据包到服务器的回显端口，消耗服务器的资源，导致服务中断。攻击具有分布式的特征，来自多个不同的源IP地址和随机的源端口号，且攻击是持续进行的，具有一定的规律性。在表1中无法得知数据包的大小，但小王十分怀疑是UDP小包洪水攻击，为了验证他的猜测，随后在路由器日志上做了同样的工作，调取了流量信息，并打印出看上去异常的日志。以下是发生在攻击期间的路由器日志。

图1  Netflow流量

随后，小王在图1中发现以下4个可疑之处：

  1.UDP数据包异常：

在IP数据包大小分布中，我们可以看到98.4%的数据包大小在33字节到64字节之间。表明存在大量的小数据包，此时小王基本可以锤石这是DoS攻击(UDP洪水攻击)。

而且在协议统计中，UDP-other协议的流量占比非常高，达到了39.2%，且每秒数据包数(Packets/Sec)为48.1，这可能表明存在异常的位置UDP流量，比例还相当高。

   2.TCP连接异常：

TCP-other协议的流量占比也相对较高，达到了0.1%，且每秒数据包数(Packets/Sec)为65.5，这可能表明存在异常的TCP流量或未知的TCP协议类型。

TCP-Telnet和TCP-FTP等协议的流量相对较低，但Idle(Sec)值较高，可能表明存在一些空闲连接或潜在的扫描活动。

  3.IP分片流量：

TCP和UDP的分片流量(TCP-Frag和UDP-Frag)相对较低，但Idle(Sec)值较高，可能表明存在一些分片攻击或潜在的扫描活动。

  4.流量分布不均：

从IP数据包大小分布来看，流量主要集中在小数据包(33字节到64字节)，这可能表明存在大量的小包攻击或扫描活动。

经过以上参数分析，小王断定网络存在DoS攻击，但或许是有其他网络攻击，为了一探究竟小王对数据开始深入挖掘。

四、调查路由器

路由器日志在DDoS攻击调查中提供了丰富的信息，是识别攻击特征、追踪攻击源的重要工具

具体表现在2个方面：

1.识别攻击特征

路由器日志记录了网络流量的详细信息，包括数据包的源地址、目的地址、协议类型、时间戳等。在遭遇DDoS攻击时还表现为大量来自不同源的流量突然涌入目标服务器。路由器日志可以帮助分析这些流量的模式，例如流量的峰值、异常协议等等，这些信息可以帮助调查人员了解攻击的流量特征与来源。

2.追踪攻击源

路由器日志可以显示攻击流量在网络中的路径，帮助调查人员追踪攻击的源头。通过分析日志中的IP地址和连接记录，可以确定攻击是否经过了中间节或者是Proxy。

下面小王查询边界路由器的IP流量缓存(IP Flow Switching Cache)的状态。

图2 路由器NetFlow输出

以下是小王对图2中数据的分析：

1.IP数据包大小分布：

图2中显示了不同大小IP数据包的分布情况。可以看到，64字节的数据包占比最高，这通常与ICMP(Internet控制消息协议)流量有关，因为ICMP消息通常很小。

2.IP流量缓存状态：

缓存中总共有2092个活跃的流量条目(active flows)，50378个非活跃的流量条目(inactive flows)，以及8924个新增的流量条目(added)。有32341次老化轮询(ager polls)，但没有流量分配失败(flow alloc failures)。

3.流量超时设置：

活跃流量的超时时间设置为30分钟，非活跃流量的超时时间设置为15秒。

4.协议流量统计：

各种协议的流量统计显示了每种协议的总流量数(Total Flows)、每秒流量数(Flows/Sec)、每秒数据包数(Packets/Sec)、每个流量的数据包数(Packets/Flow)、每个数据包的大小(Bytes/Pkt)、每秒字节数(Bytes/Sec)、活跃时间(Active(Sec)/Flow)和空闲时间(Idle(Sec)/Flow)。

TCP-other协议的流量占比相对较高，每秒有62.2个数据包，每个流量有0.5个数据包，这可能表明有大量的短连接或扫描活动。

UDP-other协议的流量也值得关注，每秒有0.2个数据包，每个流量有0.5个数据包，这可能表明有未知的UDP协议流量或潜在的攻击尝试。

ICMP协议的流量相对较高，每秒有0.5个数据包，这可能是正常的网络通信，也可能是网络扫描或攻击的一部分。

5.潜在问题：

UDP-Frag和TCP-Frag的Idle(Sec)值较高，表明存在分片重组问题或潜在的分片攻击。

UDP-other和TCP-other的流量(即未知流量)需要进一步调查，以确定是否有异常流量或潜在的安全威胁。

当出现有大量小数据包+大量分片流量，时这明显符合Dos攻击的特征，很可能是有潜在的僵尸网络活动或是Dos攻击。但这张图对新手并不友好，只有经验丰富的工程师才能分析出来。值得注意的是案例中网站服务器的访问量直线下降，大概率是遭遇了DoS攻击。小王开始调查，到底发生了什么，以及该如何修复故障。

五、事件分析

Web服务器发生了什么？有可能受到什么样的攻击呢？从不断发送小的UDP包来看，攻击看似发自两个发起点，可能是两个攻击者同时使用不同的工具。但仅凭防火墙日志和路由器日志中显示的UDP数据包特征，还无法准确判断，还需要进一步确认攻击的分布性(是否来自多个源地址)以及是否有其他攻击特征(如流量的规律性等)。

在任何情况下，超负荷的数据流都会拖垮Web服务器。然而攻击地址源不确定，不知道是攻击源本身是分布的，还是同一个地址伪装出许多不同的IP地址，这个问题比较难判断。接下来只需联系那个网络的管理员就可以得到进一步的信息。假如源地址是伪装的，追踪这个攻击者就麻烦得多。

若使用的是Cisco路由器，则还需查询NetFlow高速缓存。NetFlow是Cisco快速转发(CEF)交换框架的特性之一，主要是用来提高路由器处理大量数据包的能力。

为了追踪这个伪装的地址，必须查询每个节点路由器上的NetFlow缓存，才能确定流量进入了哪个接口，然后通过这些路由器一次一个接口地往回一路追踪，直至找到那个IP地址源。然而这样做是非常难的，因为在Web Server和攻击者的发起PC之间可能经由许多路由器，而且属于不同的组织。另外，必须在攻击正在进行时做这些分析。

经过分析之后，将防火墙日志和路由器日志里的信息关联起来，发现了一些有趣的相似性，如表黑色标记处。攻击的目标显然是Web服务器192.168.0.175，端口为UDP 7，即回显端口。这看起来很像拒绝服务攻击(但还不能确定，因为攻击的分布很随意)。地址看起来多多少少是随意而分散的，只有一个源地址是固定不变的，其源端口号也没变。这很有趣。接着，我们将注意力集中到路由器日志上。

立刻发现，攻击发生时路由器日志上有大量的64字节的数据包，而此时Web服务器日志上没有任何问题。他还发现，案发时路由器日志里还有大量的“UDP-other”数据包，而Web服务器日志也一切正常。这种现象与基于UDP的拒绝服务攻击的假设还是很相符的。

攻击者正是用许多小的UDP数据包对Web服务器的回显(echo 7)端口进行洪泛式攻击，因此，我们的下一步任务就是阻止该行为。

首先，我们在路由器上堵截攻击。快速地为路由器设置了一个过滤规则。因为源地址的来源很随机，他们认为很难用限制某个地址或某一块范围的地址来阻止攻击，因此决定禁止所有发给192.168.0.175的UDP包。这种做法会使服务器丧失某些功能，如DNS，但至少能让Web服务器正常工作。

路由器最初的临时DOS访问控制链表(ACL)，服务器IP是192.168.0.175。

access-list 121 remark Temporary block DoS attack on web server 192.168.0.175
access-list 105 deny udp any host 192.168.0.175
access-list 105 permit ip any any

• 1.
• 2.
• 3.

这样的做法为Web服务器减轻了负担，但攻击仍能到达Web服务器，在一定程度上降低了网络性能。 那么下一步工作是联系上游ISP提供商，想请他们暂时限制所有在他的网站端口7上的UDP入流量。这样做可降低打到服务器的流量。

六、预防措施

对于预防及缓解这种带宽相关的拒绝服务(DoS)Attack，并没有单一的、一劳永逸的解决方案。从根本上说，这是一种“高带宽打败低带宽”的攻击类型。如果攻击者能够控制(通过僵尸网络)得到更大带宽，有时甚至是极为庞大的带宽，就有可能击垮网络中带宽不足的部分，弱小一方没有胜算，只能减小损失。在这种残酷事实面前我们不能坐以待毙，这里谈谈预防措施与缓解策略。有许多方法可以让攻击发生时减小其影响，具体如下：

l网络入口过滤  网络服务提供商应在他的下游网络上设置入口过滤，以防止假信息包进入网络(而把它们留在互联网上)。这将防止攻击者伪装IP地址，从而易于追踪。

l网络流量过滤  过滤掉网络不需要的流量总是不会错的。这还能防止DoS攻击，但为了达到效果，这些过滤器应尽量设置在网络上游。

l网络流量速率限制  一些路由器有流量速率的最高限制。这些限制条款将加强带宽策略，并允许一个给定类型的网络流量匹配有限的带宽。这一措施也能预先缓解正在进行的攻击，同时，这些过滤器应尽量设置在网络上游(尽可能靠近攻击者)；

l单点传送RPF (单播反向路径转发)这是CEF用于检查在接口收到的数据包的另一特性。利用这种技术可以在检查在接口收到的数据包的源IP地址。如果源IP地址在CEF表上没有与指向接收数据包时的接口一致的路由，路由器就会丢弃这个数据包。这种机制阻止了所有伪装源IP地址的攻击，从而增强了网络对Dos攻击的防御能力。

1. 使用DoS防护服务

当服务器部署在云端时，可考虑使用专业的DoS防护服务，这些服务可以提供额外的流量清洗和攻击缓解功能。例如，服务器如果部署在云端(如阿里云、百度云、腾讯云等)，这些云服务提供商通常会提供相应的DoS防护服务，可以抵御流量型和资源耗尽型DoS攻击。

2. 反击战之蜜罐诱骗Dos攻击者

在本案例中，即使部署了防火墙，依然未能有效阻止攻击。这主要是因为现有防火墙在面对DoS攻击时，往往存在一定的局限性。为此，我们采取了一种新的策略，即部署一系列低交互式蜜罐，将其伪装成服务器，以此来诱骗攻击者。

2.1 基本思路：在攻击准备阶段，攻击者通常会在网络上寻找存在安全vulnerability的主机，并尝试入侵这些主机，以获取最高管理权限或至少获得一个能够执行攻击任务的账号。随后，攻击者会在这些已被控制的主机上安装主控软件或DDoS攻击程序，使其成为主控端或代理端。

因此，在整个网络体系中，部署了一批伪装成存在安全vulnerability主机的蜜罐。为了降低被攻击者察觉的风险，这些蜜罐采用的是没有安全措施、存在vulnerability的真实主机系统。

2.2 实现方法：开源蜜罐有很多，笔者推荐使用T-Pot蜜罐，它是一体化、可选分布式、多架构蜜罐平台，支持几十个蜜罐和无数可视化选项，使用 Elastic Stack、动画实时攻击地图和大量安全工具，以进一步改善欺骗体验。它部署了一系列协议特定的Docker容器，模拟了多种常见的网络服务，如HTTP、SSH、FTP等，从而诱骗攻击者。

该方案就像聪明的猎人巧妙布置的陷阱，旨在追踪和捕捉攻击者的行踪。然而，我们必须警惕，如果配置操作不当可能会适得其反。因为维护这类蜜罐系统的成本高，需要对其进行严格的隔离和妥善的保护。如果处理不当，不仅可能无法实现预期的效果，还可能给整个网络系统带来更大的风险和损失。

七、IDS系统为何无法杜绝DoS攻击？

各位读者可能会感到疑惑，防火墙和入侵检测系统都是网络安全设备，为何无法有效预防DDoS攻击呢？这背后主要有两个关键原因是需要大家掌握的。

1).IDS通常使用已知的攻击特征或模式来检测入侵行为。入侵检测系统存储了大量已知攻击的特征信息，一旦检测到与这些特征相匹配的网络流量，就会发出警报。然而DDoS攻击的特征多种多样，且攻击手段不断更新和变化，新型的DDoS攻击可能没有明显的特征，或者其特征与正常网络流量相似，难以被特征库识别。例如，一些DDoS攻击会利用合法的HTTP请求来进行攻击，这些请求在特征上与正常用户访问网站的行为非常相似，IDS很难通过特征匹配来区分它们。例如今年春节期间，漂亮国利用符合DDos方式攻击我国的Deepseek服务器，使其访问受限的案例。在这种大规模DDoS攻击中，异常流量与正常流量的界限变得模糊，很难准确判断哪些流量是攻击流量。

2).DDoS攻击通常来自多个不同的IP地址，这些IP地址可能分布在世界各地，形成了一个分布式网络。IDS很难同时处理来自多个攻击源的流量，尽管有IP信誉可以判断IP是否为恶意地址，但攻击流量可能来自合法用户的真实设备，如被僵尸网络控制的家庭路由器或智能设备，这使得IDS更难区分攻击流量和正常流量。

要有效防御DDoS攻击，需要综合运用各种安全设备，将路由器、防火墙、入侵检测系统(IDS)等安全设备协同起来共同防御DDoS攻击，减小损失。

八、总结

无论是出于报复、敲诈extortion的目的，还是为了发动更大规模的攻击，DoS(拒绝服务)或DDoS(分布式拒绝服务)攻击都构成了严重威胁。通常，DoS攻击并非旨在夺取系统控制权，而是通过Vulnerability exploitation，意图使系统陷入崩溃状态，无法对外服务，值得注意的是，本文所讨论的案例仅涉及DoS攻击的一种初级形式。大家今后遇到的问题会更复杂，尤其在现代DoS攻击中，攻击者更多地采用了反射攻击(例如DNS反射攻击、NTP反射攻击等)、应用层攻击(特别是针对HTTP/HTTPS服务的攻击)以及多向量攻击等复合型手段。这些Attack方式不仅更加隐蔽，而且防御难度显著增加。因此，我们必须不断探索和创新防御手段，以应对这些日益复杂的威胁。

难度系数：四星 ★★★★ (敏感词已被替换)

关键词：Web 、DoS 、日志 、蜜罐

故事人物：小王(网络管理员)

一、摘要：

本文详细探讨了Web服务器遭受DoS Attack时的检测与防御策略。文章通过实际案例，描述了在春节假期后Web服务器出现故障的情况，通过分析防火墙和路由器日志，发现异常流量特征，如大量UDP数据包和小数据包Attack，判断服务器可能遭受Attack。文章进一步分析了Attack原理和对服务的影响，如资源耗尽、性能下降和服务中断等，并提出了多种预防和缓解措施，包括网络入口过滤、流量速率限制、入侵检测系统、使用DDoS防护服务以及部署蜜罐诱骗Attack 等。

二、什么是DoS Attack

拒绝服务Attack(DoS)是一种通过各种手段阻止或拒绝合法用户访问网络服务器的破坏性Attack方式。从严格意义上讲，DoS 技术是一种破坏网络服务的技术手段，它通过人为或非人为的方式发起Attack，使主机的硬件、软件或网络资源无法正常工作，从而导致系统无法及时接收、处理或响应服务请求。这种Attack可以由网络内外的攻击者账户发起。

内部用户可能通过长时间占用系统资源(如内存和 CPU)来引发拒绝服务攻击，而外部攻击者则可能通过占用大量系统或网络资源的方式，使其他用户的请求无法得到及时处理，进而引发拒绝服务攻击。

TCP SYN泛洪攻击是一种典型DoS Attack，因为它通过恶意占用服务器的资源，导致服务器无法为正常用户提供服务。这种Attack方式对于网络系统的安全性和稳定性构成了严重威胁。

下面用四张动图来形象展示正常访问和TCP SYN泛洪攻击的过程。

1)正常的TCP三次握手

2)攻击者发送大量 SYN 请求来消耗目标服务器的资源。

3)服务器资源被大量消耗导致崩溃

4)当正常TCP连接到服务器时，服务端无法处理正常的连接请求，最终表现为Web服务器无法访问。

如果还是难以理解上述组图，那么不妨再举一个更贴近生活的例子：想象一下，许多恶意顾客(攻击者)涌入一家餐厅，他们纷纷占据座位却不点任何食物，就这样干坐着。随着这些“恶意顾客”越来越多，餐厅内的座位逐渐被全部占满。此时，真正想要用餐的顾客(正常用户)因为没有空位可坐，便无法享受到餐厅的服务。

攻击者光占座而不点餐：这类似于DoS Attack攻击者发送大量无意义的请求或数据包，占据服务器的资源(如连接队列、带宽等)，但并不进行正常的交互(如完成数据传输、处理请求等)。

直到把所有座位占满：这对应于攻击者通过大量请求耗尽服务器的资源，使服务器无法处理更多的请求。

理解了DOS，那么DDOS的概念就容易接受了，DDoS Attack，即分布式拒绝服务攻击(Distributed Denial of Service)，也是一种恶意网络攻击手段，其目的是通过大量虚假或恶意流量(通常攻击者会通过非常手段获取一个或多个僵尸网络获取庞大的带宽)淹没目标服务器或网络资源使其无法正常响应合法用户的请求，从而导致服务中断或瘫痪。

三、事件发生

春节假期刚刚结束，办公室里还弥漫着节日的余温。首个工作日的下午1点，小王像往常一样回到工位，解锁电脑，准备开始新一周的工作。屏幕上，Web服务器性能监控软件的图像突然映入眼帘——一条红色曲线正急速下滑，仿佛在无声地发出警报。小王的心猛地一沉，他知道，这绝不是什么好兆头。

“服务器响应速度急剧下降！”小王暗自嘀咕，他的手指迅速在键盘上敲击，打开Web服务器的日志文件。就在这时，公司首席运营官(CIO)急匆匆地走了过来，脸上写满了焦虑：“小王，客户反馈说网站完全无法访问了！”

小王的心提到了嗓子眼。他迅速从自己的台式电脑上打开浏览器，输入公司网址。几秒钟后，屏幕上弹出了一个令人不安的提示：“无法访问此页面”。这一刻，他意识到，一场危机已经悄然降临。

小王皱着眉头，努力回想起春节放假前对Web服务器的操作记录。他清楚地记得，这几天自己并没有对服务器进行任何更改或操作，服务器之前也一直运行得非常平稳，从未出现过类似的性能问题。这突如其来的故障，让他感到一丝不安。

他迅速打开Web服务器的日志文件，仔细翻阅着一行行记录，希望能找到一丝线索。然而，日志中没有任何可疑之处，一切看起来都正常得令人费解。小王的眉头锁得更紧了，他的直觉告诉他，问题肯定出在别处。

“如果服务器日志没问题，那会不会是网络层面出了问题？”小王心中一动，决定进一步查看防火墙日志和路由器日志。他深吸一口气，试图让自己冷静下来，然后迅速切换到防火墙的管理界面，开始仔细检查。

时间一分一秒地过去，小王的眼睛紧紧盯着屏幕，不放过任何一条记录。终于，在一堆看似正常的日志中，他发现了一些异常的流量记录。他的心跳加速，随后将有代表性的可疑记录打印出来，并迅速过滤掉正常的流量，试图找出隐藏在其中的线索。以下是防火墙日志的可疑信息,如表1所示。

表1 防火墙日志

小王对表1中的内容进行了仔细分析，并从中总结了4个问题。

     1.异常流量特征

大量UDP数据包：端口号7的数据包确实使用UDP协议，但也有可能使用其他协议。因此，协议号为17，端口号为7的情况下，基本可以判定存在UDP数据包，那么我们从这些日志信息可以判定存在UDP数据包，数量很大，且这些数据包的源IP地址和源端口号各不相同，但目的IP地址均为192.168.0.175，目的端口号均为7。这表明有大量的UDP数据包被发送到Web服务器的回显端口，可能是攻击者在进行UDP洪水攻击。

     2.攻击源的多样性

多个源IP地址：日志中显示了多个不同的源IP地址，如172.16.45.2、10.166.166.166、10.168.45.3等，这表明攻击可能来自多个不同的源，具有分布式的特征，而且这些IP地址很可能是被篡改过，增加了追踪。

随机的源端口号：源端口号也各不相同，如7843、19、34511等，这可能是攻击者使用随机端口来发起攻击，以避免被防火墙规则拦截。

     3.攻击目标明确

特定目的IP和端口：所有异常流量的目的IP地址均为192.168.0.175，即Web服务器的IP地址，目的端口号均为7，即回显端口。这表明攻击者的目标非常明确，就是针对Web服务器的回显端口进行攻击，以消耗服务器的资源，导致服务中断。

    4.攻击的持续性和规律性

持续的流量记录：日志中记录了多个时间点的异常流量，这表明攻击是持续进行的，而不是偶发性的。攻击者可能在一段时间内持续不断地发送UDP数据包，以保持对服务器的压力。

规律性的数据包发送：从日志中可以看出，攻击者在不同的时间点发送了相似的UDP数据包，这可能表明攻击者使用了某种自动化工具或脚本来进行攻击，具有一定的规律性。

小王经过以上防火墙日志表1的内容分析，猜测Web服务器很可能遭受了UDP洪水攻击，攻击者通过发送大量UDP数据包到服务器的回显端口，消耗服务器的资源，导致服务中断。攻击具有分布式的特征，来自多个不同的源IP地址和随机的源端口号，且攻击是持续进行的，具有一定的规律性。在表1中无法得知数据包的大小，但小王十分怀疑是UDP小包洪水攻击，为了验证他的猜测，随后在路由器日志上做了同样的工作，调取了流量信息，并打印出看上去异常的日志。以下是发生在攻击期间的路由器日志。

图1  Netflow流量

随后，小王在图1中发现以下4个可疑之处：

  1.UDP数据包异常：

在IP数据包大小分布中，我们可以看到98.4%的数据包大小在33字节到64字节之间。表明存在大量的小数据包，此时小王基本可以锤石这是DoS攻击(UDP洪水攻击)。

而且在协议统计中，UDP-other协议的流量占比非常高，达到了39.2%，且每秒数据包数(Packets/Sec)为48.1，这可能表明存在异常的位置UDP流量，比例还相当高。

   2.TCP连接异常：

TCP-other协议的流量占比也相对较高，达到了0.1%，且每秒数据包数(Packets/Sec)为65.5，这可能表明存在异常的TCP流量或未知的TCP协议类型。

TCP-Telnet和TCP-FTP等协议的流量相对较低，但Idle(Sec)值较高，可能表明存在一些空闲连接或潜在的扫描活动。

  3.IP分片流量：

TCP和UDP的分片流量(TCP-Frag和UDP-Frag)相对较低，但Idle(Sec)值较高，可能表明存在一些分片攻击或潜在的扫描活动。

  4.流量分布不均：

从IP数据包大小分布来看，流量主要集中在小数据包(33字节到64字节)，这可能表明存在大量的小包攻击或扫描活动。

经过以上参数分析，小王断定网络存在DoS攻击，但或许是有其他网络攻击，为了一探究竟小王对数据开始深入挖掘。

四、调查路由器

路由器日志在DDoS攻击调查中提供了丰富的信息，是识别攻击特征、追踪攻击源的重要工具

具体表现在2个方面：

1.识别攻击特征

路由器日志记录了网络流量的详细信息，包括数据包的源地址、目的地址、协议类型、时间戳等。在遭遇DDoS攻击时还表现为大量来自不同源的流量突然涌入目标服务器。路由器日志可以帮助分析这些流量的模式，例如流量的峰值、异常协议等等，这些信息可以帮助调查人员了解攻击的流量特征与来源。

2.追踪攻击源

路由器日志可以显示攻击流量在网络中的路径，帮助调查人员追踪攻击的源头。通过分析日志中的IP地址和连接记录，可以确定攻击是否经过了中间节或者是Proxy。

下面小王查询边界路由器的IP流量缓存(IP Flow Switching Cache)的状态。

图2 路由器NetFlow输出

以下是小王对图2中数据的分析：

1.IP数据包大小分布：

图2中显示了不同大小IP数据包的分布情况。可以看到，64字节的数据包占比最高，这通常与ICMP(Internet控制消息协议)流量有关，因为ICMP消息通常很小。

2.IP流量缓存状态：

缓存中总共有2092个活跃的流量条目(active flows)，50378个非活跃的流量条目(inactive flows)，以及8924个新增的流量条目(added)。有32341次老化轮询(ager polls)，但没有流量分配失败(flow alloc failures)。

3.流量超时设置：

活跃流量的超时时间设置为30分钟，非活跃流量的超时时间设置为15秒。

4.协议流量统计：

各种协议的流量统计显示了每种协议的总流量数(Total Flows)、每秒流量数(Flows/Sec)、每秒数据包数(Packets/Sec)、每个流量的数据包数(Packets/Flow)、每个数据包的大小(Bytes/Pkt)、每秒字节数(Bytes/Sec)、活跃时间(Active(Sec)/Flow)和空闲时间(Idle(Sec)/Flow)。

TCP-other协议的流量占比相对较高，每秒有62.2个数据包，每个流量有0.5个数据包，这可能表明有大量的短连接或扫描活动。

UDP-other协议的流量也值得关注，每秒有0.2个数据包，每个流量有0.5个数据包，这可能表明有未知的UDP协议流量或潜在的攻击尝试。

ICMP协议的流量相对较高，每秒有0.5个数据包，这可能是正常的网络通信，也可能是网络扫描或攻击的一部分。

5.潜在问题：

UDP-Frag和TCP-Frag的Idle(Sec)值较高，表明存在分片重组问题或潜在的分片攻击。

UDP-other和TCP-other的流量(即未知流量)需要进一步调查，以确定是否有异常流量或潜在的安全威胁。

当出现有大量小数据包+大量分片流量，时这明显符合Dos攻击的特征，很可能是有潜在的僵尸网络活动或是Dos攻击。但这张图对新手并不友好，只有经验丰富的工程师才能分析出来。值得注意的是案例中网站服务器的访问量直线下降，大概率是遭遇了DoS攻击。小王开始调查，到底发生了什么，以及该如何修复故障。

五、事件分析

Web服务器发生了什么？有可能受到什么样的攻击呢？从不断发送小的UDP包来看，攻击看似发自两个发起点，可能是两个攻击者同时使用不同的工具。但仅凭防火墙日志和路由器日志中显示的UDP数据包特征，还无法准确判断，还需要进一步确认攻击的分布性(是否来自多个源地址)以及是否有其他攻击特征(如流量的规律性等)。

在任何情况下，超负荷的数据流都会拖垮Web服务器。然而攻击地址源不确定，不知道是攻击源本身是分布的，还是同一个地址伪装出许多不同的IP地址，这个问题比较难判断。接下来只需联系那个网络的管理员就可以得到进一步的信息。假如源地址是伪装的，追踪这个攻击者就麻烦得多。

若使用的是Cisco路由器，则还需查询NetFlow高速缓存。NetFlow是Cisco快速转发(CEF)交换框架的特性之一，主要是用来提高路由器处理大量数据包的能力。

为了追踪这个伪装的地址，必须查询每个节点路由器上的NetFlow缓存，才能确定流量进入了哪个接口，然后通过这些路由器一次一个接口地往回一路追踪，直至找到那个IP地址源。然而这样做是非常难的，因为在Web Server和攻击者的发起PC之间可能经由许多路由器，而且属于不同的组织。另外，必须在攻击正在进行时做这些分析。

经过分析之后，将防火墙日志和路由器日志里的信息关联起来，发现了一些有趣的相似性，如表黑色标记处。攻击的目标显然是Web服务器192.168.0.175，端口为UDP 7，即回显端口。这看起来很像拒绝服务攻击(但还不能确定，因为攻击的分布很随意)。地址看起来多多少少是随意而分散的，只有一个源地址是固定不变的，其源端口号也没变。这很有趣。接着，我们将注意力集中到路由器日志上。

立刻发现，攻击发生时路由器日志上有大量的64字节的数据包，而此时Web服务器日志上没有任何问题。他还发现，案发时路由器日志里还有大量的“UDP-other”数据包，而Web服务器日志也一切正常。这种现象与基于UDP的拒绝服务攻击的假设还是很相符的。

攻击者正是用许多小的UDP数据包对Web服务器的回显(echo 7)端口进行洪泛式攻击，因此，我们的下一步任务就是阻止该行为。

首先，我们在路由器上堵截攻击。快速地为路由器设置了一个过滤规则。因为源地址的来源很随机，他们认为很难用限制某个地址或某一块范围的地址来阻止攻击，因此决定禁止所有发给192.168.0.175的UDP包。这种做法会使服务器丧失某些功能，如DNS，但至少能让Web服务器正常工作。

路由器最初的临时DOS访问控制链表(ACL)，服务器IP是192.168.0.175。

access-list 121 remark Temporary block DoS attack on web server 192.168.0.175
access-list 105 deny udp any host 192.168.0.175
access-list 105 permit ip any any

• 1.
• 2.
• 3.

这样的做法为Web服务器减轻了负担，但攻击仍能到达Web服务器，在一定程度上降低了网络性能。 那么下一步工作是联系上游ISP提供商，想请他们暂时限制所有在他的网站端口7上的UDP入流量。这样做可降低打到服务器的流量。

六、预防措施

对于预防及缓解这种带宽相关的拒绝服务(DoS)Attack，并没有单一的、一劳永逸的解决方案。从根本上说，这是一种“高带宽打败低带宽”的攻击类型。如果攻击者能够控制(通过僵尸网络)得到更大带宽，有时甚至是极为庞大的带宽，就有可能击垮网络中带宽不足的部分，弱小一方没有胜算，只能减小损失。在这种残酷事实面前我们不能坐以待毙，这里谈谈预防措施与缓解策略。有许多方法可以让攻击发生时减小其影响，具体如下：

l网络入口过滤  网络服务提供商应在他的下游网络上设置入口过滤，以防止假信息包进入网络(而把它们留在互联网上)。这将防止攻击者伪装IP地址，从而易于追踪。

l网络流量过滤  过滤掉网络不需要的流量总是不会错的。这还能防止DoS攻击，但为了达到效果，这些过滤器应尽量设置在网络上游。

l网络流量速率限制  一些路由器有流量速率的最高限制。这些限制条款将加强带宽策略，并允许一个给定类型的网络流量匹配有限的带宽。这一措施也能预先缓解正在进行的攻击，同时，这些过滤器应尽量设置在网络上游(尽可能靠近攻击者)；

l单点传送RPF (单播反向路径转发)这是CEF用于检查在接口收到的数据包的另一特性。利用这种技术可以在检查在接口收到的数据包的源IP地址。如果源IP地址在CEF表上没有与指向接收数据包时的接口一致的路由，路由器就会丢弃这个数据包。这种机制阻止了所有伪装源IP地址的攻击，从而增强了网络对Dos攻击的防御能力。

1. 使用DoS防护服务

当服务器部署在云端时，可考虑使用专业的DoS防护服务，这些服务可以提供额外的流量清洗和攻击缓解功能。例如，服务器如果部署在云端(如阿里云、百度云、腾讯云等)，这些云服务提供商通常会提供相应的DoS防护服务，可以抵御流量型和资源耗尽型DoS攻击。

2. 反击战之蜜罐诱骗Dos攻击者

在本案例中，即使部署了防火墙，依然未能有效阻止攻击。这主要是因为现有防火墙在面对DoS攻击时，往往存在一定的局限性。为此，我们采取了一种新的策略，即部署一系列低交互式蜜罐，将其伪装成服务器，以此来诱骗攻击者。

2.1 基本思路：在攻击准备阶段，攻击者通常会在网络上寻找存在安全vulnerability的主机，并尝试入侵这些主机，以获取最高管理权限或至少获得一个能够执行攻击任务的账号。随后，攻击者会在这些已被控制的主机上安装主控软件或DDoS攻击程序，使其成为主控端或代理端。

因此，在整个网络体系中，部署了一批伪装成存在安全vulnerability主机的蜜罐。为了降低被攻击者察觉的风险，这些蜜罐采用的是没有安全措施、存在vulnerability的真实主机系统。

2.2 实现方法：开源蜜罐有很多，笔者推荐使用T-Pot蜜罐，它是一体化、可选分布式、多架构蜜罐平台，支持几十个蜜罐和无数可视化选项，使用 Elastic Stack、动画实时攻击地图和大量安全工具，以进一步改善欺骗体验。它部署了一系列协议特定的Docker容器，模拟了多种常见的网络服务，如HTTP、SSH、FTP等，从而诱骗攻击者。

该方案就像聪明的猎人巧妙布置的陷阱，旨在追踪和捕捉攻击者的行踪。然而，我们必须警惕，如果配置操作不当可能会适得其反。因为维护这类蜜罐系统的成本高，需要对其进行严格的隔离和妥善的保护。如果处理不当，不仅可能无法实现预期的效果，还可能给整个网络系统带来更大的风险和损失。

七、IDS系统为何无法杜绝DoS攻击？

各位读者可能会感到疑惑，防火墙和入侵检测系统都是网络安全设备，为何无法有效预防DDoS攻击呢？这背后主要有两个关键原因是需要大家掌握的。

1).IDS通常使用已知的攻击特征或模式来检测入侵行为。入侵检测系统存储了大量已知攻击的特征信息，一旦检测到与这些特征相匹配的网络流量，就会发出警报。然而DDoS攻击的特征多种多样，且攻击手段不断更新和变化，新型的DDoS攻击可能没有明显的特征，或者其特征与正常网络流量相似，难以被特征库识别。例如，一些DDoS攻击会利用合法的HTTP请求来进行攻击，这些请求在特征上与正常用户访问网站的行为非常相似，IDS很难通过特征匹配来区分它们。例如今年春节期间，漂亮国利用符合DDos方式攻击我国的Deepseek服务器，使其访问受限的案例。在这种大规模DDoS攻击中，异常流量与正常流量的界限变得模糊，很难准确判断哪些流量是攻击流量。

2).DDoS攻击通常来自多个不同的IP地址，这些IP地址可能分布在世界各地，形成了一个分布式网络。IDS很难同时处理来自多个攻击源的流量，尽管有IP信誉可以判断IP是否为恶意地址，但攻击流量可能来自合法用户的真实设备，如被僵尸网络控制的家庭路由器或智能设备，这使得IDS更难区分攻击流量和正常流量。

要有效防御DDoS攻击，需要综合运用各种安全设备，将路由器、防火墙、入侵检测系统(IDS)等安全设备协同起来共同防御DDoS攻击，减小损失。

八、总结

无论是出于报复、敲诈extortion的目的，还是为了发动更大规模的攻击，DoS(拒绝服务)或DDoS(分布式拒绝服务)攻击都构成了严重威胁。通常，DoS攻击并非旨在夺取系统控制权，而是通过Vulnerability exploitation，意图使系统陷入崩溃状态，无法对外服务，值得注意的是，本文所讨论的案例仅涉及DoS攻击的一种初级形式。大家今后遇到的问题会更复杂，尤其在现代DoS攻击中，攻击者更多地采用了反射攻击(例如DNS反射攻击、NTP反射攻击等)、应用层攻击(特别是针对HTTP/HTTPS服务的攻击)以及多向量攻击等复合型手段。这些Attack方式不仅更加隐蔽，而且防御难度显著增加。因此，我们必须不断探索和创新防御手段，以应对这些日益复杂的威胁。