如何找出基于虚假源地址的攻击行为 -10bet十博欢迎您
攻击者为了躲避追踪，往往会模拟出虚假的地址，这让攻击定位难度非常高，甚至是无从下手，如何找出虚假的攻击地址，是解决攻击问题的关键。
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 价值
对上述问题的分析，采用了网络分析技术，做到了一步一步的验证，如果没有真实数据的分析，要解决虚假地址问题是非常难的。