虚假源地址网络攻击分析案例Word文件下载.docx

虚假源地址网络攻击分析案例Word文件下载.docx

《虚假源地址网络攻击分析案例Word文件下载.docx》由会员分享，可在线阅读，更多相关《虚假源地址网络攻击分析案例Word文件下载.docx（17页珍藏版）》请在冰豆网上搜索。

基本分析思路8

分析设备部署8

分析档案与方案选择8

分析过程9

总体分析9

数据包基本信息9

统计信息9

故障信息统计10

问题分析11

异常发现11

数据包分析13

DNS访问行为分析14

分析结论15

问题验证16

解决方法17

问题描述

某政府用户求助，其网络正在遭遇不明问题。

由于该用户承担重要的业务系统运营，因此，该问题对其业务稳定性有较大影响，需要尽快定位问题原因并做出相应对策。

从业务操作层面来讲，无论是内部用户还是外部用户，在访问其Web或其他服务器时，感受较慢；

从技术层面做简单的Ping测试，出现如下现象：

从上面的内网Ping测试结果来看，访问目标确实存在间歇性丢包现象。

从丢包结果明显看到，这与常见的网络拥塞等情况下的丢包状况不太一样。

以上信息证明，该网络的确存在问题，需要进一步分析原因。

网络与应用结构描述

在进行分析前，通过与技术负责人简单的交流，得知其网络大致结构如下：

上面的拓扑结构简明描述了用户的网络和应用部署结构，需要说明的几点有：

•IPS没有过多的策略定制；

•FW对所有流量均透明；

•流控设备仅对内部用户启用NAT，外网用户访问DMZ或DMZ流向外网数据均未做NAT；

•用户拥有103.16.80.0/129的公网IP地址，除了路由器和流控设备使用了2个外，其他的都用在DMZ区域。

内网用户访问方式描述

由于本次故障分析是在内网进行，所以有必要说明一下内网用户在访问DMZ区域的数据变化及流经过程。

如下图所示：

假如用户A要访问OA服务器E，其访问途径为上图红色标记的1-4。

其中，流控设备作为A的NAT设备，同时，A的数据会从流控B发送到C，然后再返回B到交换机D到E。

用户A在内网的访问IP地址变化如下：

•发送数据包：

AIP——>

B:

103.16.80.131——>

E:

103.16.80.189；

•返回数据包：

103.16.80.189——>

AIP；

其中用户A的IP为私有IP地址（内网用户均使用私有IP）。

分析方案及思路

基本分析思路

无论是外网还是内网对DMZ区域的主机Ping操作都呈现相同现象，而内网用户区域相互Ping测试则不存在问题，所以，建议先在DMZ区域交换机D上设置端口镜像并采集和分析。

如果在D设备上流量可以分析到相关问题原因或有所新的发现，则根据发现再进一步部署分析策略。

分析设备部署

如下图，将科来网络分析系统接入到交换机D的流量镜像端口。

由于未知丢包原因或目标（几乎所有DMZ主机都丢包），建议不设置任何过滤器，即捕获所有数据包。

分析档案与方案选择

在使用科来网络分析系统前，选择正确的分析档案和分析方案，这对分析效率及数据处理性能方面都有极大的优化作用。

这一步不可忽视。

根据用户的实际网络情况，以及对应问题特性，在进行数据捕获时，采用如下网络档案和分析方案，且不进行任何过滤器设置。

分析过程

分析过程包括数据捕获后的总体分析，异常发现和分析。

此部分对DMZ区域交换机D上捕获的数据进行分析。

总体分析

数据包基本信息

如下图，采集时间约55.5秒的数据包，包含25,003个数据包，未设置任何过滤器。

统计信息

从下图的统计信息可以查看到，流量分布基本正常；

数据包大小分布中，64-127字节的数据包数约为1024-1518字节数据包个数的3倍，这说明网络中小包数据过多。

从会话及应用信息的统计中看到，在55.5秒时间内，DNS查询和响应次数分别超过1400个，从数量来说较偏大。

故障信息统计

采用分析系统默认诊断定义，提示共有6658个诊断，分布在应用层到物理层不等，

其中最多的是传输层的数据包重传和重复确认，超过了6000个，这说明网络质量情况不佳。

另外，系统提示存在ARP请求风暴，通过分析，确认所有的ARP请求数据包均为正常数据包，且频率不高，不会对网络内主机造成影响或欺骗。

问题分析

问题分析部分，主要针对发现的异常现象进行分析和验证。

异常发现

在进行内部用户访问方式描述时曾提到，网关103.16.80.129的MAC地址为

00:

13:

7F:

71:

DD:

91，这个MAC只有当数据流经路由器时才会使用到。

见下图：

量，竟发送到了00:

91，甚至对有些不存在的103.16.80.0段地址的流量也发送到了这个MAC。

这与分析前了解到的情况并不一样。

另外，高亮部分只是从诊断发生地址中随机选择的一个地址的2个事件，该事件说明，103.16.80.130（DNS服务器）发向103.16.80.107的流量被发送到

91。

同理分析得到，上图红色矩形框选的地址都存在这种问题。

数据包分析

对事件深入分析，双击上图高亮事件，查看相关数据解码信息。

通过下图分析到，103.16.80.107向DNS服务器103.16.80.130发送域名解析请求，后者对前者响应，内容为“查询错误”。

且不管DNS应答错误原因，单从源IPMAC来看，说明其来源于广域网。

而经过确认，某些属于DMZ区域的IP也同样存在这种问题，其作为源IP地址从广域网来连接内部DNS服务器，且DNS服务器全部做了应答。

DNS访问行为分析

上面的分析发现，存在疑问的IP地址基本都向内部DNS发起域名解析请求，这里对DNS服务器的访问情况进行分析。

如下图，5.5秒时间，共有与DNS服务器同段的224个IP向DNS服务器发起解析请求，而这些IP地址都是从广域网发送过来。

分析结论

从上面的分析看到，客户遇到的网络问题其实是正在遭遇虚假源地址攻击，大量的假冒地址对内部DNS发起大量的请求。

然而，这并不能解释客户网络慢，Ping包丢失的原因，即这种网络攻击为什么会造成故障存在？

这里对可能的问题原因进行说明。

假设用户A正在对DMZ服务器103.16.80.189进行Ping操作，这时，虚假地址

103.16.80.189经过Router和FW访问DNS103.16.80.130，同时DNS服务器对该虚

假地址做出响应。

造成的影响为，防火墙会在其接口地址列表中记录：

103.16.80.189

地址是从源MAC地址为00:

91的接口转发过来。

这时，发往103.16.80.189的ICMP数据包被转发到了路由器，接着转发到广域网，结果石沉大海。

当Ping包无法到达目的地时（会返回来错误的ICMP协议报文），路由器更新新的路由信息后，则再发往路由器的Ping包会被重定向到正确位置，防火墙更新新的端口地址列表信息，Ping操作成功。

问题验证

为了进一步验证分析结果，以及确认问题是由虚假源IP访问内部DNS带来的网络

攻击。

在IPS和FW之间串接一个Hub，从以下位置捕获数据进行分析。

通过分析捕获到的数据，发现实际结果与分析得到的答案一致，如下图，内网用户对DMZ区域主机的Ping被发送到了Router。

解决方法

分析到问题的原因后，解决方法则变的较为简单。

在IPS上设置策略，禁止DMZ区域的IP作为源IP访问DNS服务器的流量通过IPS，

问题解决。