官方说明:

https://wiki.wireshark.org/Home

https://www.wireshark.org/docs/wsug_html_chunked/

# 着色规则

在 wireshark 监控界面上,不同的报文会显示不一样样的颜色,它们分别表示不同的含义;而这些颜色,都是是由着色规则设置的:

image-20221006162351042

在默认的着色规则中,一般黑色背景代表报文的各类错误,红色背景代表各类异常情景,其它颜色代表正常。

官方的说明可以看:https://www.wireshark.org/docs/wsug_html_chunked/ChCustColorizationSection.html

着色规则分析:

1、Bad TCP: tcp.analysis.flags && !tcp.analysis.window_update && !tcp.analysis.keep_alive && !tcp.analysis.keep_alive_ack

即 TCP 包损坏,通常表示为重传,乱序,丢包,重复响应等都在此条规则的范围内。具体看第三大点。

参看:https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html

2、HSRP State Change: hsrp.state != 8 && hsrp.state != 16

HSRP 即热备份路由协议(Hot Standby Router Protocol),这条规则表明当前报文状态非 Standby 和 Active。

HSRP 的状态值可以是以下几种:

  • 0 - Initial
  • 1 - Learn
  • 2 - Listen
  • 4 - Speak
  • 8 - Standby
  • 16 - Active

参考:https://www.rfc-editor.org/rfc/rfc2281

3、Spanning Tree Topology Change: stp.type == 0x80

当生成树协议的状态标记为 0x80 ,表示着生成树拓扑发生变化。即 STP 协议数据单元 (BPDU) 的 flag 字段发生变化(使用 IEEE-802.1d):

img

参考:https://techhub.hpe.com/eginfolib/networking/docs/switches/5980/5200-3921_l2-lan_cg/content/499036672.htm

4、OSPF State Change: ospf.msg != 1

OSPF(Open Shortest Path First,开放式最短路径优先协议)的 msg 类型不是 Hello 报文。

OSPF 报文的类型,有下面几种类型:

  • 1:Hello 报文;
  • 2:DD 报文;
  • 3:LSR 报文;
  • 4:LSU 报文;
  • 5:LSAck 报文。

参考:http://www.023wg.com/message/message/cd_feature_ospf_message.html

5、ICMP errors: icmp.type eq 3 || icmp.type eq 4 || icmp.type eq 5 || icmp.type eq 11 || icmpv6.type eq 1 || icmpv6.type eq 2 || icmpv6.type eq 3 || icmpv6.type eq 4

ICMP 协议错误,协议的 type 字段值错误。

6、ARP: arp

即 ARP 协议。

7、ICMP: icmp || icmpv6

即 ICMP 协议。

8、TCP RST: tcp.flags.reset eq 1

TCP 流产生 reset。

9、SCTP ABORT: sctp.chunk_type eq ABORT

SCTP(即流控制传输协议)发生中止。

参考:https://www.rfc-editor.org/rfc/rfc4960#section-3.3.7

10、TTL low or unexpected: ( ! ip.dst == 224.0.0.0/4 && ip.ttl < 5 && !pim && !ospf) || (ip.dst == 224.0.0.0/24 && ip.dst != 224.0.0.251 && ip.ttl != 1 && !(vrrp || carp))

TTL (Time-To-Live) 指解析记录在本地 DNS 服务器中的缓存时间。该规则表示 TTL 产生异常。

在 IP 组播中,通过 TTL 控件来管理转发数据包的范围,按照惯例:

  • 0 - 仅限于同一主机上
  • 1 - 被限制在同一个子网内
  • 32 仅限于同一站点
  • 64 - 仅限于同一区域
  • 128 - 仅限于同一大陆
  • 255 - 不受限制

参考:https://www.techtarget.com/searchnetworking/definition/time-to-live

11、Checksum Errors: eth.fcs.status == "Bad" || ip.checksum.status == "Bad" || tcp.checksum.status == "Bad" || udp.checksum.status == "Bad" || sctp.checksum.status == "Bad" || mstp.checksum.status == "Bad" || cdp.checksum.status == "Bad" || edp.checksum.status == "Bad" || wlan.fcs.status == "Bad" || stt.checksum.status == "Bad"

条件中的各类协议的 checksum 出现异常。

12、SMB: smb || nbss || nbns || netbios

Server Message Block 类协议。

13、HTTP: http || tcp.port == 80 || http2

Hyper Text Transfer Protocol(超文本传输协议),这是很简陋的识别方法。

14、DCERPC: dcerpc

即 DCE/RPC,分散式运算环境 / 远端过程调用(Distributed Computing Environment / Remote Procedure Calls)协议。

15、Routing: hsrp || eigrp || ospf || bgp || cdp || vrrp || carp || gvrp || igmp || ismp

路由类协议。

**16、TCP SYN/FIN: ** tcp.flags & 0x02 || tcp.flags.fin == 1

TCP 连接的起始和关闭。

17、TCP: tcp

TCP 协议。

18、UDP: udp

UDP 协议。

19、Broadcast: eth[0] & 1

广播数据。

20、System Event: systemd_journal || sysdig

系统调用及系统事件等系统活动。

# 专家信息

在报文的信息栏中,通常也有颜色限定,如下图:

image-20221006185352059

而这次的颜色区别是属于对应的信息条目的:

image-20221006185105048

每个专家信息项都有一个严重性级别。使用以下级别,从最低到最高。Wireshark 使用不同的颜色标记它们:

  • 聊天(蓝色)

    有关常用的工作流程信息,例如设置了 SYN 标志的 TCP 数据包;数据包都符合常规流量的特征,包括 SYN、FIN、RST 以及各种状态码的 HTTP 事件。

  • 注意(青色)

    值得注意的事件,例如应用程序返回了一个常见的错误代码,例如 HTTP 404;数据包中有可能会引发故障的异常现象,例如 TCP 重传、重复确认、快速重传等现象。

  • 警告(黄色)

    警告,例如应用程序返回异常错误代码,如连接问题。

    与 TCP 窗口有关的事件 TCP window full 或 TCP zero window,一般是连接设备忙不过来所致。

    与 TCP 报文段丢失或失序有关的事件,丢失是因为未抓全某个 TCP 数据流的所有 TCP 报文段;失序是因其感知到了 TCP 报文段未按发出的顺序到达接收主机。

  • 错误(红色)

    严重的问题。

    校验和错误:Ethernet 及 IP 校验和错误。

    伪造的数据包:一般涉及具体的应用层协议。

参看:https://www.wireshark.org/docs/wsug_html_chunked/ChAdvExpert.html

# TCP Info

参看:https://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers

# A、ACK 信息

1、TCP ACKed unseen segment

表示 Wireshark 发现该条 ACK 在整个网络包中找不到所对应的 Seq(排除了乱序),就会提示。

image-20221012210009741

如图,在这组网络中,第 296 号包出现这种情况,然后在上面的包中是找不到它所对应的 Seq 的。

2、TCP Dup ACK <frame> #<acknowledgement number>

重复 ACK 包,当收发不稳定时,会出现重复响应的情况;而这种情况就是响应端会向请求端回复重复 ACK。 # 符号前面的数字表示对应的重复包号,后面的数字表示确认次数,也可以说是出现的次数。

image-20221012221850769

如图,在第 31191 号包的信息中可以看到提示是说跟第 31188 号包出现重复,通过查看第 31188 号包,而这一包其实是为了响应第 31187 号的。

3、TCP Fast Retransmission

标志着前面接收到重复的 ACK 包(即出现了 [TCP Dup ACK] )达 3 个或 3 个以上,进而触发了 TCP 的快速重传(这是 RFC 的规定)。

image-20221012224854822

如图, [TCP Dup ACK] 出现了 3 次,而且都是对应第 1309 号包,因此触发快速重传包第 1330 号包,重传了第 1309 号包所响应的请求包第 1245 号包,如下图:

image-20221012230828693

然后通过对比原包第 1245 号包和快速重传包第 1330 号包,你会发现并不相同,实际上原始数据应该是相同的,只不过数据加密了,才出现不同的现象。

# B、保活探测

4、TCP Keep-Alive

这个应该不陌生,一般 TCP 长链接时,如果启用保活功能,则在特定时间段没有数据交互,那么将会传输一条保活字段,如下图:

image-20221012233735152

5、TCP Keep-Alive ACK

作为上一点 [TCP Keep-Alive] 的响应包,例图看上一张。

# C、乱序 or 丢包

6、TCP Out-Of-Order

标志着 TCP 传输出现乱序。

image-20221013201521709

如图,在 TCP 传输过程中(不包括三次握手和四次挥手),同一台主机发出的数据包应该是连续的,即后一个包的 Seq 号等于前一个包的 Seq + Len;也可以说,后一个包的 Seq 会大于或等于前一个包的 Seq。当 Wireshark 发现后一个包的 Seq 值小于前一个包的 Seq + Len 时,就会认为是乱序了,因此标志 [TCP Out-of-Order]。

在连续传输数据过程中,可以看到从第 330 号包一直到第 337 包被标志为乱序这几个包,应当是连续的,但是可以发现第 336 号包跟第 337 号包调转了,因此第 336 号包被标志为上一包未捕获,而第 337 号包则被标志为乱序。

然后来分析一下,例如第 337 号包的 Seq = 83518,Len = 1380,那么 Seq + Len = 84898,可以发现其实该包列栏中 Sequence Number83518 数据对应 Seq, NextSequence Number84898 数据对应 Seq + Len。根据上面的结论,在发生错误前的第 335 号包它的 NextSequence Number 表明下一包第 336 号包的 Seq 值应当是 83518 ,但是实际上第 336 号包的 Seq 值为 84898 ,当到了第 337 号包的时候,才出现理应对应的值 83518 ,这时 Wireshark 通过对比在发生错误前的第 335 号包至理论连续的第 337 号包之间看是否有出现调转包,有则标志 [TCP Out-of-Order]。一般出现 [TCP Out-of-Order] 时都会伴随出现 [TCP Previous segment not captured] 。

7、TCP Previous segment not captured

在 TCP 传输过程中,同一台主机发出的数据段应该是连续的,即后一个包的 Seq 号等于前一个包的 Seq + Len(三次握手和四次挥手是例外)。如果 Wireshark 发现后一个包的 Seq 值大于前一个包的 Seq + Len,就知道中间缺失了一段数据。

依然沿用上一张图,在发生错误前的第 335 号包 Seq + Len 值为 83518 ,但下一包的 Seq 值为 84898 ,因此出现后一个包的 Seq 值大于前一个包的 Seq + Len,而非等于,所以预示着该数据包的上一个包未捕获到,但后面我们也有发现虽然显示上一个包未捕获到,实际紧随它的后一个包就是它们之间的数据包,只是调转了包而已。

# D、端口

8、TCP Port numbers reused

这个死活没捕捉出来,就简单说一下吧。

当发送 SYN 标志时(不是 SYN + ACK),如果已经存在一个使用相同地址和端口的现有会话,那么将会被 Wireshark 标记 [TCP Port numbers reused]。

# E、重传

9、TCP Spurious Retransmission

TCP 虚假重传,意味着发送端认为发送的包已经丢失了,然后就重传了,尽管此时接收端已经发送了对这些包的确认(确认还没收到或者已经丢失了)。

image-20221013232224434

如图,第 459 号包出现虚拟重传现象,实际为第 453 号包的重传,可从显示来看第 453 号包是已经是得到接收端的 ACK 响应了,理论来讲是不会重传的,但前面也有说到了,可能会出现接收端确认了请求(已经发出去了),发送端却还没收到或者已经丢失了,那么发送端将会重传数据,而由于这时这段数据包在初包发送后接收端有回一次请求,这次重传相当于接收端又回了一次请求(即重复了两次响应,可以看到第 460 号包标志为 [TCP Dup ACK] 了),所以对于这种有回 ACK 还重传的数据包将被标志为 [TCP Spurious Retransmission] 。然后至于为什么是重传了第 453 号包,可以看到第 460 号包的信息提示,这是 ACK 响应第 459 号包的,但同时也是跟第 454 号包重复,而第 454 号包对应响应第 453 号包的,那自然而然地得到第 459 号包为第 453 号包的重传。

10、TCP Retransmission

TCP 重传,与上面不同的是如果一个包不确定是否丢了,但它又没有像上面 [TCP Spurious Retransmission] 那样得到接收端的 ACK 响应,那它大概率就是丢包了,就不会快速重传;而针对这种情况,发送方也就只好等到超时了再重传,此类重传包就会被 Wireshark 标志 [TCP Retransmission] 。

image-20221014221501852

如图,第 33 号包被标志为 [TCP Previous segment not captured],预示着有可能出现丢包,并且在后面一段时间内也没有像前面那样有标志 [TCP Out-Of-Order] 提示的包,排除了乱序情况,最终等待超时,重传数据包,于是第 33 号重传包就有了 [TCP Retransmission] 标志。TCP 重传是 TCP 通讯中常有的事情,有时候看到一大堆黑漆漆一片的 error 事件,可能就是这种情况。

# F、TCP Window

11、TCP Window Full

顾名思义,就是窗口已满,指的发送端发送的数据已经达到的接受窗口的上限;那么发送端暂停发送,等待新的接收窗口的通告。

image-20221014235639055

如图,在这组数据中,从第 526323 号包开始,出现了 [TCP Window Full] 表明发送数据达到上限了,同时还有另一个 [TCP Spurious Retransmission] 表明了虚假重传,但可惜的是接收端后续都没有响应,最终导致在发送 RST 报文后,关闭 TCP 连接。

12、TCP Window Update

TCP 协议允许随时改变窗口的大小,并且通过发送标识有 WindowUpdate 的报文通知对端;或者当接收端的应用程序消耗完了已经从 RX 缓冲区接收到的数据时,也会发生 WindowUpdate,以指示缓冲区中现在有更多可用空间;以上这些数据包将被标志 [TCP Window Update]。[TCP Window Update] 是 TCP 通信中的一个状态,它可以发生的原因还有有很多,通常在 TCP ZeroWindow 条件发生后看到。

image-20221014234941548

13、TCP ZeroWindow

如图,当接收窗口值大小为零(Win = 0)且非 SYN、FIN 或 RST 数据时设置。

image-20221014223515008

在每个 TCP 报头中的窗口字段表明着接收端可以接受的数据量大小;如果接收端不能接受任何数据,它将把窗口值设置为零,这告诉发送端暂停其传输。在某些特定情况下,这是正常的,例如,打印机可能会在加载或翻转一张纸时使用零窗口暂停打印作业的传输;然而,在大多数情况下,这表明接收端存在性能或容量问题。恢复暂停的连接可能需要很长时间 (有时需要几分钟),即使导致零窗口的底层条件很快就会清除。

14、TCP ZeroWindowProbe

当通信的一方接收到 TCP ZeroWindow 报文后,会定时发送 TCP ZeroWindowProbe 报文进行探测;探测报文是需要发送下一字节数据,然后通过接收端的响应,由此来判断接收端窗口值是否仍然为 0,如果接收方回复窗口大小仍然为零,则发送端继续探测。ZeroWindowProbe 它有助于证明发送端已经确认到接收端其 TCP 窗口大小为零,但仍试图让数据继续交互而非关闭通讯。

img

15、TCP ZeroWindowProbeAck

作为 [TCP ZeroWindowProbe] 的 ACK 应答,结合 TCP ZeroWindowProbe 理解。ZeroWindowProbeAck 数据包的存在也表明网络正在传递数据包并且设备没有关闭。

# G、交互

16、TCP Conversation Completeness

  • SYN
  • SYN-ACK
  • ACK
  • DATA
  • FIN
  • RST

img

# 常见表达式

1、运算符

英文写法别名C-like描述例子
eqany_eq==相等(如果超过一个)ip.src == 10.0.0.5
neall_ne!=不相等(如果多于一个,则全部)ip.src != 10.0.0.5
all_eq===相等(如果多于一个,则全部)ip.src === 10.0.0.5
any_ne!==不相等(如果多于一个,则任意)ip.src !== 10.0.0.5
gt>大于frame.len > 10
lt<小于frame.len < 128
ge>=大于或等于frame.len ge 0x100
le<=小于或等于frame.len <= 0x20

2、逻辑符

英文写法C-like描述例子
and&&逻辑与ip.src==10.0.0.5 and tcp.flags.fin
or||逻辑或ip.src==10.0.0.5 or ip.src==192.1.1.1
xor异或tr.dst[0:3] == 0.6.29 xor tr.src[0:3] == 0.6.29
not!逻辑非not llc

3、协议过滤

ip.proto == xxx

note: xxx表示为对应的协议,如 TCP:ip.proto == TCP
  • TCP: 只显示 TCP 协议的数据流
  • UDP: 只显示 UDP 协议的数据流
  • HTTP: 只显示 HTTP 协议的数据流
  • ICMP: 只显示 ICMP 协议的数据流
  • ARP: 只显示 ARP 协议的数据流
  • DNS: 只显示 DNS 协议的数据流

4、IP 过滤

  • ip.addr == 192.168.116.138 ,只显示 IP 地址192.168.116.138 有关的数据流
  • ip.src == 192.168.116.138 ,只显示源 IP 地址192.168.116.138 的数据流
  • ip.dst == 192.168.116.138 ,只显示目标 IP 地址192.168.116.138 的数据流

5、端口过滤

  • tcp.port == 80 ,只显示 80 端口 TCP 数据流
  • udp.prot == 67 ,只显示 67 端口 UDP 数据流
  • tcp.srcport == 80 , 只显示源地址的 80 端口数据流
  • tcp.dstport == 80 ,只显示目的地址 80 端口数据流

6、过滤 HTTP 协议

  • http.request.method == "GET" ,显示 GET 请求
  • http.request.method == "POST" ,显示 POST 请求
  • http.request.code == 404 ,显示状态码为 404

参看:https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html

# 列信息增删

1、增加列信息

在报文的信息栏,选着想要显示的信息,右键点击添加:

image-20221006221325561

2、删除列信息

在监控报文栏,选择不需要的列,右键选中:

image-20221006221434994

3、隐藏列信息

同样在监控报文栏操作,随便选择一列,右键选中,然后把想要隐藏的列去掉勾选,这里就不放图了。

更新于 阅读次数

请我喝[茶]~( ̄▽ ̄)~*

夏沫の浅雨 微信支付

微信支付

夏沫の浅雨 支付宝

支付宝