wireshark分析ARP广播风暴 wireshark检测广播风暴

转载

技术领航舵手 2024-05-27 22:43:15

文章标签 wireshark分析ARP广播风暴 Wireshark 抓包分析工具 higlab.com 笔记 文章分类 架构后端开发

2.1二层Ethernet、LAN交换故障分析

Ethernet发现广播及错误风暴

1.广播及错误风暴是通信网络中最难解决的故障之一
	2.导致此类故障的原因有很多，比如二层环路、针对二层的攻击、网卡故障、某台主机上的某个服务持续不断向网络中发包等
	3.二层丢包现象，势必会导致TCP(四层协议)重传
	4.广播风暴是指在网络中传播的广播包的数量每秒高达数千乃至数万
	5.一般而言，广播风暴发生之日，便是网络瘫痪之时
	6.广播包数量过多和广播风暴完全是两码事
	7.网络中广播包的数量达到多少才算是过多呢？(1-2个/台/分钟)    --正常情况下，每台计算机每分钟1-2个广播包

广播风暴由某台设备主机所引起，通常具备以下典型特征：
	1.广播包速率极高(数千甚至上万个/秒)  --可以通过IO Graphs查看
	2.在绝大多数情况下，都源自于一个源IP，但遭受攻击除外
	3.广播包速率恒定，即Wireshark所抓取广播数据帧之间的时间间隔几乎完全相等
总结：
	1、在Ethernet中，第三层IP广播包在传播之前会被先封装为第二层MAC地址全为1的以太网帧
	2、IP网络中常见的广播包
		①配合TCP/IP协议运行的广播包：比如，ARP请求，DHCP请求
		②某些应用层协议生成的广播包：比如NetBIOS查询和通告包、NTP包等
		③某些应用程序：比如Dropbox、MNLB、或者证券期货类应用等

STP故障排除简介

1.生成树协议分成三个版本：STP(802.1D)、RSTP(802.1W)、MST(802.1S)
	2.解决生成树问题，先要确定网络中运行的是哪种STP版本
	3.再去确认故障显现的同时，发生过网络拓扑变更事件吗？拓扑变更在情理之中，但若发生的次数太多，则会对网络性能产生影响。
	
	所有生成树的BPDU数据包
	目标MAC地址为多播地址：01:80:c2:00:00:00
	源MAC地址是交换机的MAC地址
	
	STP(版本号0)  0x801d此交换机的1/13端口发出了BPUD   根桥ID和网桥ID一致且Cost为0，说明此交换机就是根交换机
	RSTP(版本号2)
	MST(版本号3)	拓扑变更的BPDU  0x8001  0/1接口发出的

VLAN问题分析

FCS校验失败的数据帧能不能被Wireshark抓到？

wireshark分析ARP广播风暴 wireshark检测广播风暴_higlab.com

抓不到，编辑–>首选项 ipv4的这个勾被去掉了

2.2三层协议故障分析

与ARP有关的连通性故障分析

①ARP的作用是什么？在哪些情况下用到ARP？
②ARP解析的全过程是什么？
③ARP的数据包格式是什么？
	request 0
	reply   1
④什么是免费ARP？

ARP扫描(ARP sweep)
	①ARP扫描：是指某台主机以发出各种ARP数据包的方式，来扫描整个网络，意在窃取信息或发动攻击
	②当面临扫描时应该关注三个问题：
		①ARP数据包的源MAC地址是什么？
			若请求数据包源于多个不同的MAC地址，则属于正常情况
			若请求数据包属于同一个MAC，则要查出到底MAC是谁
			若查不出单一MAC到底是谁，则网络正面临蠕虫或ARP中毒攻击
		②是ARP请求还是ARP应答数据包
			若是莫名其妙的ARP应答数据包现身于网络，则也可能面临中间人攻击
		③ARP数据包的数量级？
			每台IP设备每分钟生成1-2个ARP数据包纯属合理
			若网络100台设备，每分钟生成200-300或每秒3-4个ARP是合理的
			就算每秒钟5-10ARP，也不是问题，但需要仔细查找原因
ARP扩展思考题
	两台主机在同一个LAN，但各自的IP属于不同的子网，网关都指向各自的IP地址，
	请问，两台主机可以互相ping通吗      能
	
	不配网关，能不能通          不通

IP故障分析

Wireshark软件会借用主机所配置的DNS服务器，来执行IP地址和域名之间的转换。某些情况下，把某些数据包的源目IP地址转换为名称来显示，能有助于发现规律性的异常流量。
wiresharkIP地址解析成域名
	①视图-->解析名称
	②统计-->端点    下载GeoIP的免费版GeoLite      https://dev.maxmind.com/zh-hans/geoip/legacy/geolite/
			编辑首选项
	
抓取分片数据包：
	1.主机打开CMD
	2.ping 172.16.88.102 -l 5000
	3.打开Wireshark抓取数据包
	数据包是如何分片的
		①同一个包ID相同
		②偏移大小(offset)
		③是否有更多的分片(more fragment)
	如何判断是否是IP报文分片导致连接异常缓慢
		①首先确保无其他网络层面的问题
		②用Wireshark抓取数据包流量，确认是否有IP分片，
		③当你怀疑是分片导致的问题，可以让DBA工程在服务器端调整参数，让数据不经过分片传送至网络
		④一般情况，在以太网IP数据包净载包含TCP包头，不应该超过1480字节，因此封装在TCP报文段后的不应该超过1460字节
		⑤某些时候，如果启用隧道技术，需要考虑增加的包头，控制数据在穿越网络的时候不发生分片。
	接收方靠什么重组分片的？
		IP数据包头，会有专门用来数据重组的相应字段flags，比如off、ID、MF等。
	TCP是如何避免被发送方分片的
		TCP可以避免被发送方分片，因此TCP会在三次握手的时候，协商最大的MSS，然后主动把数据分成小段在交给网络层。所以网络层不需要分片。但是UDP就没有MSS的概念，一股脑交给网络层，可能被网络层分片
	IP数据包分片的概念：
		最大传输单元(MTU):是指由IP包头和数据部分组成的IP数据包长度
		最大报文段大小(MSS):是指TCP报文段内数据净载的最大长度，即上层协议交付给TCP的每个数据单元的最大长度
	用IPSec-VPN传输需要增加新的报头

DHCP故障分析 (以下都是广播包)

1.DHCP Discover:广播的形式发送，UDP格式，源端口68、目标端口67
2.DHCP Offer：表明愿意提供IP地址的租用
3.DHCP Request：客户端请求DHCP服务器配置与本机有关的IP地址
4.DHCP ACK：其中包含服务器给客户端的IP地址、子网掩码、网关、DNS等IP配置信息

网络不通下：
	只有DHCP Discover包：DHCP挂了或者网路有问题
	4个包都有：说明IP地址有，可能是一个非法的DHCP发的IP地址
	0个包：网卡没开
	手动配IP地址能访问网络，不能自动获取地址：

ARP在什么时候发出广播解析(PC主机)

1.解析的目标IP和自己的网卡在同一网段(无所谓是否配网关)
2.只要配置网关(无所谓对错)，PC都可以发出ARP请求广播(8.8.8.8目标)

ARP在什么时候发出广播解析(路由器模拟PC主机)

1.关闭路由器的路由功能
	①不配置网关，也可以发出ARP请求广播
	②配置网关，发起的ARP请求广播将是请求网关的ARP(不会请求8.8.8.8目标)
2.不关闭路由器的路由功能
	①所有的转发完全按照路由表进行路由转发

2.3TCP、UDP故障分析

TCP连接故障排错思路

1.安装服务器端和客户端的软件是否都运行正常
2.检查网络是否连接正常，IP地址的正确检查
3.Ping测试(思考：Ping通代表应用能互访吗？)
4.启动Wireshark开始抓包分析，查看是否出现异常
	①客户端主机连发三次SYN位置1的TCP报文，服务器未做任何回应(应用程序自身问题)
	②客户端主机发出了SYN位置1的TCP报文，收到了RST位置1的TCP的确认报文(中间防火墙过滤流量)
故障现象：
	用户在内网主机10.1.1.1的浏览器内输入视频监控服务器，去监控远程站点，可以看到登录界面，但却无法登录进系统。
可能原因：
	1.验证数据包时TCP其他端口号(6036)
	2.中间流量放行问题
	3.NAT问题
	4.。。。。。。。
	
超时重传 		关窗口，开窗口(慢启动)
快速重传  		3个以上的重复ACK,触发

TCP报文段失序问题

–没有故障问题，只是Wireshark感知并生成的相关提示信息

Wireshark中报文失序的现象是什么
	1.Pervious segment lost
	2.Out-of-order packet
	3.Pervious segment not captured
导致TCP报文失序的原因是什么
	1.Wireshark打开抓包时机不对，没抓全数据包，这属于Wireshark自己的原因
	2.真的存在丢包情况
		①延迟和抖动：不同路径的时候，由于不同的延迟，可能出现先发后至
		②几个抓包问题：流量速率超出150M/S(需要商业抓包工具)、负责抓包的机器CPU内存不足，作镜像的交换机是瓶颈、用无线网卡抓包可能也会出现抓不全的现象
		
		
TCP Dup ACK    		重复ACK，通过它来确认发生的快速重传
TCP Retransmission  超时重传，最不愿看到的，因为对窗口大小消耗很大

TCP Zero Window：零窗口

TCP Zero Window可能的原因是什么
	1.问题一般都在数据接收方
	2.接收方主机配置太低
	3.接收方应用没有足够的缓存
TCP Zero Window的过程
	1.接收方发出窗口字段为0的报文
	2.发送方会发出TCP Zero Window Probe报文段，探测接收方窗口大小是否仍为0
	3.发送方会在特定的计时器内，向接收方发送2的数据包，直到探测出接收方的窗口不再是0为止
	4.如果在收到窗口字段值为0的TCP报文段之后，发送方仍然不管不顾，继续发送数据出去，这一举动被称为TCP Zero Windown Violation,Wireshark感知到这种行为，一般都表示相关应用程序的TCP实现方式存在瑕疵

TCP Window Update 告诉对方增大窗口
TCP Window Full：发送方告诉接收方，这是最后一个TCP报文段

Wireshark的提示总结

[Packet size limited during capture]	包没有抓全，一般由抓包方式引起的(例如：只抓前100字节)
[TCP Previous segment not captured]		中间有丢包
[TCP Dup ACK]			重复确认
[TCP Out-of-Order]		乱序
[TCP Zero Window]		零窗口
[TCP Window Full]		full窗口
[TCP segment of a ressembled PDU]		可以把拆散的数据包关联起来
[Continuation to #]		
[Time-to-live exceeded]				ttl超时
[TCP ACKed unseen segment]			抓包时间不正确，ack确认抓到，数据没抓到

TCP的效率真的低吗？(不管什么，来回7个包syn fin的包)

网络对它的性能影响很大

2.4DNS故障分析

几个经常用到的DNS显示过滤器的实例(一)：

1.dns.flags.response0(DNS查询消息)
2.dns.flags.response1(DNS响应消息)
3.Dns.flags.rcode0(显示RCODE字段值为0(Noerror)的DNS应答消息)
4.Dns.flags.rcode3(显示RCODE字段值为3(NXDomain,表示域名不存在)的DNS应答消息)
5.Dns.qry.name==“URL Name”(显示query section中的query name字段值匹配指定URL的DNS数据包)
6.Dns.qry.name contains “URL Name”(显示query section中的query name字段值包含指定URL的DNS数据包)

几个经常用到的DNS显示过滤器的实例(二)：

1.dns.flags.opcode0(只显示DNS常规查询消息，以及相应的DNS响应消息)
2.dns.flags.opcode1(只显示DNS逆向查询消息，以及相应的DNS响应消息)
3.dns.flags.opcode2(只显示DNS服务器状态请求查询消息，以及相应的DNS服务器状态响应消息)
4.dns.flags.opcode5(只显示DNS动态更新查询消息，以及相应的DNS动态更新响应消息)
6.dns.flags.recdesired1(RD标记位置1的DNS查询消息一般为主机发出，目的是要求接受该消息的DNS服务器执行递归查询)
7.dns.flags.recdesired0(只显示RD标记位置0的DNS递归反复查询及响应消息)

DNS故障分析

DNS故障分类
	1.无法解析域名			--ping测试网关和外网排错
	2.解析缓慢
无法解析域名的原因
	1.有待访问的Web站点不存在
		抓包特点：
			1.ID字段相同，意味着一问一答的DNS，例如都是0xee26
			2.一问一答存在延时，说明在递归查找
			3.看DNS回复报文段RCODE字段值为3，表示域名不存在
			4.也可以使用内置主机操作系统的nslookup工具，来尝试解析有带访问的web站点的域名
	2.DNS服务器不做回应
		抓包特点：	
			1.抓到了refused字样的DNS应答消息，这表示查询请求遭到了DNS服务器的拒绝
			2.抓到多条DNS查询消息，但却未抓到一条配套的DNS应答消息，这表示DNS服务器因某种原因没有回应查询请求
DNS解析缓慢的排错思路
	1.先通过前面介绍的方法排除是否是TCP的相关问题造成的
	2.如果不是，需要排除是否是DNS问题导致上网过慢
	3.最简单的方法是，在数据包列表内，选出一个隶属于DNS的数据流，点击右键，点击FollowUDP Stream，观察Time列，获取相关DNS域名解析时间
	4.另一种方法是，借助IO Graphs工具
	5.正常DNS解析在100ms以内，超过200ms就会感觉很卡

2.5HTTPS和HTTP故障分析

HTTP协议主要特点

1.支持客户端服务器模式
2.简单快速：超文本协议
3.灵活：允许任意类型的数据对象
4.无连接：限制每次连接只处理一个请求，收到ACK断开连接
5.无状态：HTTP服务器不保存客户机的任何信息

HTTP几种请求方法

1.OPTION：HTTP客户端可使用该方法让web服务器告知其所支持的功能
2.GET：HTTP客户端可使用该方法请求web服务器发送某个资源
3.HEAD：与GET方法类似。HTTP客户端可在不获取实际资源的情况下，让web服务器发送资源的概况信息
4.POST：HTTP客户端可利用该方法向web服务器传送数据
5.DELETE：借助于该方法，HTTP客户端可请求web服务器删除由URL指定的资源
6.PUT：HTTP客户端利用该方法向web服务器写入数据。一般要通过用户名和密码认证
7.TRACE：当HTTP客户端发起HTTP请求时，HTTP请求报文可能会穿越防火墙。代理服务器或网关等设备，这些设备
	可能会修改原始的HTTP请求数据包中的内容，借助TRACE方法，HTTP客户端就能让web服务器弹回一条
	TRACE响应报文，其中会携带后者实际收到的HTTP请求报文。HTTP客户端可借此了解原始HTTP请求报文是否被损坏或修改过
8.CONNECT：用来连接代理设备

HTTP 5类状态码：

类别		名称				含义
1XX			信息状态码			用来表示一般性信息
2XX			成功状态码			用来表示由HTTP客户端所请求执行的动作已被web服务器成功接收、接受或处理
3XX			重定向状态码		用来告知HTTP客户端使用其他位置来访问其所感兴趣的资源
4XX			客户端错误状态码	用来表示HTTP客户端错误
5XX			服务器错误状态码	用来表示HTTP错误

几个经常用到的HTTP显示过滤器的实例(一)

1.http.host =="www.baidu.com"	(只显示访问某指定域名的HTTP请求数据包)
2.http.host contains "baidu"	(只显示访问包含了指定字符串的域名的HTTP的请求数据包)
3.http.referrer=="www.baidu.com"	(只显示从此链接过来的所有HTTP请求数据包)
4.http.request.method==GET (只显示包含GET请求的所有HTTP数据包)
5.http.request 	(显示所有HTTP请求数据包)
6.http.response	(显示所有HTTP响应数据包)

网页打开过慢的排错步骤

1.确保Internet链路没有负载过大，排除没有通讯链路的问题
2.判断是否与TCP性能问题有关
3.判断是否归因于DNS故障
4.经过一番排查之后，发现与上述问题无关，请将目标对准HTTP协议
5.设法查明web站点传回的HTTP信息状态码

HTTP缺点

1.大多数网站会让客户端与多台服务器建立并发的TCP连接，这个方案不太完美，因为每个新建的TCP连接会处于慢启动状态中，传输效率也低，而过了慢启动阶段，速度终于变快了，数据却已经传完了
2.还可以用Pipelining技术优化，可惜不支持代理服务器
3.google推出的SPDY协议，在HTTP和TCP之间加了一层，从而支持多路复用等功能，目前几乎主流浏览器都支持SPDY，国外的主流网站也支持
4.HTTP2.0即将到来(还是基于TCP的，还是有改进的空间，比如TCP的三次握手和慢启动的负面影响任然存在
5.google开发的一种还没有流行起来的QUIC协议，可以完全跑在UDP上，可以完全消除网页应用的延迟)

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。