如何找出基于虚假源地址的攻击行为

攻击者为了躲避追踪,往往会模拟出虚假的地址,这让攻击定位难度非常高,甚至是无从下手,如何找出虚假的攻击地址,是解决攻击问题的关键。

 

13.1 问题描述

 

某政府用户反应其网络正在遭遇不明问题困扰。由于网络承担重要的业务系统运营,因此,该问题对其业务稳定性有较大影响。需要科来网络分析工程师,尽快帮助定位问题原因并做出相应对策。

从业务操作层面来讲,无论是内部用户还是外部用户,在访问其Web或其他服务器时,感受较慢;从技术层面做简单的Ping测试,出现如下现象。

图 13-1

从上面的内网Ping测试结果来看,访问目标确实存在间歇性丢包现象。从丢包结果明显看到,这与常见的网络拥塞等情况下的丢包状况不太一样。

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

13.1.1 网络与应用结构描述

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

图 13-2

上面的拓扑结构简明描述了用户的网络和应用部署情况,需要说明的有以下几点:

  • IPS没有过多的策略定制;
  • FW对所有流量均透明;
  • 流控设备仅对内部用户启用NAT;外网用户访问DMZ或DMZ流向外网数据,均未做NAT;
  • 用户拥有X.80.0/129的公网IP地址,除了路由器和流控设备使用了2个外,其他的都用在DMZ区域。

13.1.2 内网用户访问方式描述

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

图 13-3

假如用户A要访问OA服务器E,其访问途径为上图标记的步骤1-4。其中,流控设备作为A的NAT设备。同时,A的数据会从流控设备B发送到C,然后返回B再发送到交换机D到E。

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

  • 发送数据包:A的IP——>B:X.X.80.131——>E:X.X.80.189
  • 返回数据包:E:XX.X.80.189——>B:X.X.80.131——> A的IP

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

 

13.2 分析方案及思路

 

13.2.1 基本分析思路

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

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

13.2.2 分析设备部署

将科来网络分析系统接入到交换机D的流量镜像端口,如下图所示。由于未知丢包原因或目标(几乎所有DMZ主机都丢包),建议不设置任何过滤器,即捕获所有数据包。

图 13-4

13.2.3 分析档案与方案选择

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

根据用户的实际网络情况及问题特性,在进行数据采集时,拟采用如下网络档案和分析方案,且不进行任何过滤器设置,如下图所示。

图 13-5

 

13.3 分析过程

 

分析过程包括数据捕获后的总体分析、异常行为发现和分析。此部分主要对DMZ区域交换机D上捕获的数据进行分析。

13.3.1 总体分析

数据包基本信息:数据包采集耗时55.5秒,共采集到25,003个数据包,同时未设置任何过滤器。

统计信息:可以查看到流量分布基本正常;数据包大小分布中,64-127字节的数据包数约为1024-1518字节数据包个数的3倍,这说明网络中小包数据过多,如下图所示。

图 13-6

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

图 13-7

故障信息统计:采用分析系统默认的诊断定义,提示共有6658个诊断。分布在应用层到物理层不等,其中最多的是传输层的数据包重传和重复确认,超过了6000个,这说明网络质量情况不佳。

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

图 13-8

13.3.2 问题分析

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

异常发现:在进行内部用户访问方式描述时曾提到,网关X.X.80.129的MAC地址为00:13:7F:71:DD:91,这个MAC应该只有当数据流经路由器时才会使用到,如下图所示。

图 13-9

然而,在进行诊断分析时发现,DMZ内部服务器发送给应在DMZ区域内的IP的流量,竟发送到了00:13:7F:71:DD:91,甚至对有些不存在的地址段(如:X.X.80.0)发出的流量,也发送到了这个MAC。这与分析前了解到的情况并不一致。

图 13-10

上图右下方的标记内容证明了之前提到的MAC问题。

另外,黄色高亮部分,只是从诊断数据中随机选择的一个地址的2个事件。该事件说明,X.X.80.130(DNS服务器)发向X.X.80.107的流量,被发送到00:13:7F:71:DD:91。

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

数据包分析:对事件进行深入分析。双击上图高亮事件,查看相关数据解码信息。通过下图分析,X.X.80.107向DNS服务器X.X.80.130发送域名解析请求,后者对前者响应,内容为“查询错误”。

图 13-11

且不管DNS应答错误原因,单从源IP MAC来看,说明其来源于广域网。经过确认,某些属于DMZ区域的IP也同样存在这种问题,其作为源IP地址从广域网来连接内部DNS服务器,且DNS服务器全部做了应答。

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

在5.5秒时间内,共有与DNS服务器同段的224个IP向DNS服务器发起解析请求,而这些IP地址都属于广域网,如下图所示。

图 13-12

 

13.4 分析结论

 

13.4.1 分析结论

从上述分析可以看到,客户遇到的网络问题,是由于正在遭遇虚假源地址攻击而导致。大量的假冒地址,对内部DNS发起大量的请求。然而,这并不能解释客户网络慢,Ping包丢失的原因,即这种网络攻击为什么会造成故障存在?

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

假设用户A正在对DMZ服务器X.X.80.189进行Ping操作,这时,虚假地址X.X.80.189经过Router和FW访问DNS服务器X.X.80.130,同时DNS服务器对该虚假地址做出响应。由此造成的影响为,防火墙会在其接口地址列表中记录:X.X.80.189地址,是从源MAC地址为00:13:7F:71:DD:91的接口转发过来。这时,发往X.X.80.189的ICMP数据包,就被转发到了路由器,接着转发到广域网,结果石沉大海,如下图所示。

图 13-13

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

13.4.2 问题验证

为了进一步验证分析结果,以及确认问题是由虚假源IP访问内部DNS带来的网络攻击。在IPS和FW之间串接一个Hub,从以下位置捕获数据进行分析。

图 13-14

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

图 13-15

13.4.3 解决方法

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

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

 

13.5 价值

 

对上述问题的分析,采用了网络分析技术,做到了一步一步的验证,如果没有真实数据的分析,要解决虚假地址问题是非常难的。

免费测试申请及购买咨询

您的名字 :

您的手机 :

您的邮箱 :

公司名称 :

您的职位 :

公司地址 :

网络规模 :

购买用途 :

补充留言:

验证: