CSNA网络分析认证专家实战案例(科来软件)章 (29)
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
以上信息证明,该网络的确存在问题,需要进一步分析原因。
5
29.1.2 网络与应用结构 在进行分析前,通过与技术负责人简单的交流,得知其网络
大致结构如图29-2所示。
6
图29-2 7
上面的拓扑结构简明地描述了用户的网络和应用部署结构, 需要说明的有
(1) IPS没有过多的策略定制。 (2) FW对所有流量均透明。 (3) 流控设备仅对内部用户启用NAT,外网用户访问DMZ或 DMZ流向外网数据均未配置NAT。 (4) 用户拥有103.16.80.0/129的公网IP地址,除了路由器 和流控设备使用了2个外,其他的都用在DMZ区域。
9
用户A在内网的访问IP地址变化如下: (1) 发送数据包:A: IP——>B:103.16.80.131—— >E:103.16.80.189。 (2) 返回数据包:E:103.16.80.189—— >B:103.16.80.131——> A: IP。 其中,用户A的IP为私有IP地址(内网用户均使用私有IP)。
12
29.2.2 分析设备部署 如图29-4所示,将科来网络分析系统接入到交换机D的流量
镜像端口。由于未知丢包原因或目标(几乎所有DMZ主机都丢包), 建议不设置任何过滤器,即捕获所有数据包。
13
29.2.3 分析档案与方案选择 在使用科来网络分析系统前,选择正确的分析档案和分析方
案对分析效率及数据处理性能都有极大的优化作用,这一步不可 忽视。根据用户的实际网络情况以及对应的问题特性,在进行数 据捕获时采用如图29-5所示的网络档案和分析方案,且不进行任 何过滤器设置。
2
从业务操作层面来讲,无论是内部用户还是外部用户,在访 问其Web或其他服务器时,感觉较慢;从技术层面做简单的Ping 测试,出现如图29-1所示的现象。
3
图29-1 4
从上面的内网Ping测试结果来看,访问目标确实存在间歇性 丢包现象。从丢包结果明显看到,这与常见的网络拥塞等情况下 的丢包状况不太一样。
同理分析可知,上图黑色矩形框选中地址都存在这种问题。
28
2. 数据包分析 对事件进行深入分析,双击图29-10中的高亮事件,查看相 关数据解码信息。通过图29-11可以分析得知,103.16.80.107向 DNS服务器103.16.80.130发送域名解析请求,后者对前者响应, 内容为“查询错误”。
然而,在进行诊断分析时发现,DMZ内部服务器发送给本应 在DMZ区域内IP的流量竟发送到了00:13:7F:71:DD:91,甚至有些 不存在的103.16.80.0段地址的流量也发送到了这个MAC。这与分 析前了解到的情况并不一样,如图29-10所示。
26
图29-10 27
图29-10中高亮部分证明了上面提到的MAC问题。另外,高亮 部分只是从诊断发生地址中随机选择的一个地址的2个事件,该 事件说明103.16.80.130(DNS服务器)发向103.16.80.107的流量 被发送到00:13:7F:71:DD:91。
10
图29-3 11
29.2 分析方案及思路
29.2.1 基本分析思路 无论是外网还是内网,对DMZ区域的主机Ping操作都出现相
同现象,而内网用户区域相互Ping测试则不存在问题。所以,建 议先在DMZ区域交换机D上设置端口镜像并采集数据和分析。如果 在D设备上,根据流量可以分析到相关问题原因或有新的发现, 则根据发现再进一步部署分析策略。
35
当Ping包无法到达目的地时(会返回来错误的ICMP协议报文), 路由器更新新的路由信息后,则再发往路由器的Ping包会被重定 向到正确位置,防火墙更新新的端口地址列表信息,Ping操作成 功。
36
图29-13 37
29.4.2 问题验证 为了进一步验证分析结果,以及确认问题是由于虚假源IP访
问内部DNS带来的网络攻击造成的,在IPS和FW之间串接一个Hub, 从图29-14所示位置捕获数据并进行分析。
38
图29-14 39
通过分析捕获到的数据,发现实际结果与分析得到的答案一 致,如图29-15所示,内网用户对DMZ区域主机的Ping被发送到了 Router。
40
图29-15 41
14
图29-4 15
图29-5 16
29.3 分 析 过 程
分析过程包括数据捕获后的总体分析和问题分析,主要是针 对DMZ区域交换机D上捕获的数据。
17
29.3.1 总体分析 1. 数据包基本信息 采集时间约55.5秒,包含25 003个数据包,未设置任何过滤
器。 2. 统计信息 从图29-6所示的统计信息可以看到,流量分布基本正常;数
8
29.1.3 内网用户访问方式 由于本次故障分析是在内网进行,所以有必要说明一下内网
用户在访问DMZ区域的数据变化及流经过程,如图29-3所示。 假如用户A要访问OA服务器E,其访问途径为图29-3中标记的
1和4。其中,流控设备作为A的NAT设备,同时A的数据会从流控B 发送到C,然后再返回到B,再到交换机D和E。
第Hale Waihona Puke 9章 虚假源地址网络攻击 分析案例
➢29.1 故障描述 ➢29.2 分析方案及思路 ➢29.3 分析过程 ➢29.4 分析总结
1
29.1 故 障 描 述
29.1.1 故障现象 某政府用户求助,其网络出现不明问题。由于该用户承担重
要的业务系统运营,因此该问题对其业务稳定性有较大影响,需 要尽快定位问题原因并作出相应对策。
据包大小分布中,64~127 B的数据包数约为1024~1518 B数据 包个数的3倍,这说明网络中小包数据过多。
18
图29-6 19
从图29-7所示的会话及应用信息的统计中看到,在55.5秒时 间内,DNS查询和回应次数均超过1400个,数量偏大。
20
图29-7 21
3. 故障信息统计 采用分析系统默认诊断定义,提示共有6658个诊断,分布在 应用层到物理层不等,其中最多的是传输层的数据包重传和重复 确认,超过了6000个,这说明网络质量不佳。另外,系统提示存 在ARP请求风暴,通过分析,确认所有的ARP请求数据包均为正常 数据包,且频率不高,不会对网络内主机造成影响或欺骗,见图 29-8。
32
图29-12 33
29.4 分 析 总 结
29.4.1 分析结论 从上面的分析看到,客户遇到的网络问题其实是正在遭遇虚
假源地址攻击,大量的假冒地址对内部DNS发起大量的请求。然 而这并不能解释客户网络慢、Ping包丢失的原因,即这种网络攻 击为什么会造成故障存在?
34
假设用户A正在对DMZ服务器103.16.80.189进行Ping操作, 这时,虚假地址103.16.80.189经过Router和FW访问DNS 103.16.80.130,同时DNS服务器对该虚假地址作出响应,造成的 影响是防火墙会在其接口地址列表中记录103.16.80.189地址是 从源MAC地址为00:13:7F:71:DD:91的接口转发过来的。这时,发 往103.16.80.189的ICMP数据包被转发到了路由器,接着转发到 广域网,结果石沉大海,如图29-13所示。
29
图29-11 30
且不管DNS应答错误原因,单从源IP的MAC来看,可知其来源 于广域网。而经过确认,某些属于DMZ区域的IP也同样存在这种 问题,其作为源IP地址从广域网来连接内部DNS服务器,且DNS服 务器全部作了应答。
31
3. DNS访问行为分析 上面的分析发现,存在疑问的IP地址基本都向内部DNS发起 域名解析请求,这里对DNS服务器的访问情况进行分析。 如图29-12所示,5.5秒时间内共有与DNS服务器同段的224个 IP向DNS服务器发起解析请求,而这些IP地址都是从广域网发送 过来。
22
图29-8 23
29.3.2 问题分析 问题分析部分主要是针对发现的异常现象进行分析和验证。 1. 异常发现 在图29-3中可以看到,网关103.16.80.129的MAC地址为
00:13:7F:71:DD:91,这个MAC只有当数据流经路由器时才会使用 到,见图29-9。
24
图29-9 25
29.4.3 解决方法 找到问题的原因后,解决方法则变得较为简单。在IPS上设
置策略,禁止DMZ区域的IP作为源IP访问DNS服务器产生的流量通 过IPS,问题得到解决。
42
感谢
43
谢谢,精品课件
资料搜集
44
5
29.1.2 网络与应用结构 在进行分析前,通过与技术负责人简单的交流,得知其网络
大致结构如图29-2所示。
6
图29-2 7
上面的拓扑结构简明地描述了用户的网络和应用部署结构, 需要说明的有
(1) IPS没有过多的策略定制。 (2) FW对所有流量均透明。 (3) 流控设备仅对内部用户启用NAT,外网用户访问DMZ或 DMZ流向外网数据均未配置NAT。 (4) 用户拥有103.16.80.0/129的公网IP地址,除了路由器 和流控设备使用了2个外,其他的都用在DMZ区域。
9
用户A在内网的访问IP地址变化如下: (1) 发送数据包:A: IP——>B:103.16.80.131—— >E:103.16.80.189。 (2) 返回数据包:E:103.16.80.189—— >B:103.16.80.131——> A: IP。 其中,用户A的IP为私有IP地址(内网用户均使用私有IP)。
12
29.2.2 分析设备部署 如图29-4所示,将科来网络分析系统接入到交换机D的流量
镜像端口。由于未知丢包原因或目标(几乎所有DMZ主机都丢包), 建议不设置任何过滤器,即捕获所有数据包。
13
29.2.3 分析档案与方案选择 在使用科来网络分析系统前,选择正确的分析档案和分析方
案对分析效率及数据处理性能都有极大的优化作用,这一步不可 忽视。根据用户的实际网络情况以及对应的问题特性,在进行数 据捕获时采用如图29-5所示的网络档案和分析方案,且不进行任 何过滤器设置。
2
从业务操作层面来讲,无论是内部用户还是外部用户,在访 问其Web或其他服务器时,感觉较慢;从技术层面做简单的Ping 测试,出现如图29-1所示的现象。
3
图29-1 4
从上面的内网Ping测试结果来看,访问目标确实存在间歇性 丢包现象。从丢包结果明显看到,这与常见的网络拥塞等情况下 的丢包状况不太一样。
同理分析可知,上图黑色矩形框选中地址都存在这种问题。
28
2. 数据包分析 对事件进行深入分析,双击图29-10中的高亮事件,查看相 关数据解码信息。通过图29-11可以分析得知,103.16.80.107向 DNS服务器103.16.80.130发送域名解析请求,后者对前者响应, 内容为“查询错误”。
然而,在进行诊断分析时发现,DMZ内部服务器发送给本应 在DMZ区域内IP的流量竟发送到了00:13:7F:71:DD:91,甚至有些 不存在的103.16.80.0段地址的流量也发送到了这个MAC。这与分 析前了解到的情况并不一样,如图29-10所示。
26
图29-10 27
图29-10中高亮部分证明了上面提到的MAC问题。另外,高亮 部分只是从诊断发生地址中随机选择的一个地址的2个事件,该 事件说明103.16.80.130(DNS服务器)发向103.16.80.107的流量 被发送到00:13:7F:71:DD:91。
10
图29-3 11
29.2 分析方案及思路
29.2.1 基本分析思路 无论是外网还是内网,对DMZ区域的主机Ping操作都出现相
同现象,而内网用户区域相互Ping测试则不存在问题。所以,建 议先在DMZ区域交换机D上设置端口镜像并采集数据和分析。如果 在D设备上,根据流量可以分析到相关问题原因或有新的发现, 则根据发现再进一步部署分析策略。
35
当Ping包无法到达目的地时(会返回来错误的ICMP协议报文), 路由器更新新的路由信息后,则再发往路由器的Ping包会被重定 向到正确位置,防火墙更新新的端口地址列表信息,Ping操作成 功。
36
图29-13 37
29.4.2 问题验证 为了进一步验证分析结果,以及确认问题是由于虚假源IP访
问内部DNS带来的网络攻击造成的,在IPS和FW之间串接一个Hub, 从图29-14所示位置捕获数据并进行分析。
38
图29-14 39
通过分析捕获到的数据,发现实际结果与分析得到的答案一 致,如图29-15所示,内网用户对DMZ区域主机的Ping被发送到了 Router。
40
图29-15 41
14
图29-4 15
图29-5 16
29.3 分 析 过 程
分析过程包括数据捕获后的总体分析和问题分析,主要是针 对DMZ区域交换机D上捕获的数据。
17
29.3.1 总体分析 1. 数据包基本信息 采集时间约55.5秒,包含25 003个数据包,未设置任何过滤
器。 2. 统计信息 从图29-6所示的统计信息可以看到,流量分布基本正常;数
8
29.1.3 内网用户访问方式 由于本次故障分析是在内网进行,所以有必要说明一下内网
用户在访问DMZ区域的数据变化及流经过程,如图29-3所示。 假如用户A要访问OA服务器E,其访问途径为图29-3中标记的
1和4。其中,流控设备作为A的NAT设备,同时A的数据会从流控B 发送到C,然后再返回到B,再到交换机D和E。
第Hale Waihona Puke 9章 虚假源地址网络攻击 分析案例
➢29.1 故障描述 ➢29.2 分析方案及思路 ➢29.3 分析过程 ➢29.4 分析总结
1
29.1 故 障 描 述
29.1.1 故障现象 某政府用户求助,其网络出现不明问题。由于该用户承担重
要的业务系统运营,因此该问题对其业务稳定性有较大影响,需 要尽快定位问题原因并作出相应对策。
据包大小分布中,64~127 B的数据包数约为1024~1518 B数据 包个数的3倍,这说明网络中小包数据过多。
18
图29-6 19
从图29-7所示的会话及应用信息的统计中看到,在55.5秒时 间内,DNS查询和回应次数均超过1400个,数量偏大。
20
图29-7 21
3. 故障信息统计 采用分析系统默认诊断定义,提示共有6658个诊断,分布在 应用层到物理层不等,其中最多的是传输层的数据包重传和重复 确认,超过了6000个,这说明网络质量不佳。另外,系统提示存 在ARP请求风暴,通过分析,确认所有的ARP请求数据包均为正常 数据包,且频率不高,不会对网络内主机造成影响或欺骗,见图 29-8。
32
图29-12 33
29.4 分 析 总 结
29.4.1 分析结论 从上面的分析看到,客户遇到的网络问题其实是正在遭遇虚
假源地址攻击,大量的假冒地址对内部DNS发起大量的请求。然 而这并不能解释客户网络慢、Ping包丢失的原因,即这种网络攻 击为什么会造成故障存在?
34
假设用户A正在对DMZ服务器103.16.80.189进行Ping操作, 这时,虚假地址103.16.80.189经过Router和FW访问DNS 103.16.80.130,同时DNS服务器对该虚假地址作出响应,造成的 影响是防火墙会在其接口地址列表中记录103.16.80.189地址是 从源MAC地址为00:13:7F:71:DD:91的接口转发过来的。这时,发 往103.16.80.189的ICMP数据包被转发到了路由器,接着转发到 广域网,结果石沉大海,如图29-13所示。
29
图29-11 30
且不管DNS应答错误原因,单从源IP的MAC来看,可知其来源 于广域网。而经过确认,某些属于DMZ区域的IP也同样存在这种 问题,其作为源IP地址从广域网来连接内部DNS服务器,且DNS服 务器全部作了应答。
31
3. DNS访问行为分析 上面的分析发现,存在疑问的IP地址基本都向内部DNS发起 域名解析请求,这里对DNS服务器的访问情况进行分析。 如图29-12所示,5.5秒时间内共有与DNS服务器同段的224个 IP向DNS服务器发起解析请求,而这些IP地址都是从广域网发送 过来。
22
图29-8 23
29.3.2 问题分析 问题分析部分主要是针对发现的异常现象进行分析和验证。 1. 异常发现 在图29-3中可以看到,网关103.16.80.129的MAC地址为
00:13:7F:71:DD:91,这个MAC只有当数据流经路由器时才会使用 到,见图29-9。
24
图29-9 25
29.4.3 解决方法 找到问题的原因后,解决方法则变得较为简单。在IPS上设
置策略,禁止DMZ区域的IP作为源IP访问DNS服务器产生的流量通 过IPS,问题得到解决。
42
感谢
43
谢谢,精品课件
资料搜集
44