wire shark抓包分析

wires hark基础知识

主窗信息

在这里插入图片描述

标题栏-----------------用于显示文件名称、捕获的设备名称和Wireshark版本号。

菜单栏-----------------Wireshark 的标准菜单栏。

工具栏-----------------常用功能快捷图标按钮。

显示过滤区域---------减少查看数据的复杂度。

Packet List面板-------显示每个数据帧的摘要。

Packet Details面板----分析封包的详细信息。

Packet Bytes面板------以十六进制和ASCII格式显示数据包的细节。

状态栏------------------专家信息、注释、包数和Profile。

认识数据包

在这里插入图片描述

   Frame------------------------------------物理层的数据帧概况
   Ethernet II------------------------------ 数据链路层以太网帧头部信息
   Internet Protocol Version 4:--------------互联网层IP包头部信息
   Transmission Control Protocol-------------传输层T的数据段头部信息，此处是TCP
   Hypertext Transfer Protocol---------------应用层的信息，此处是HTTP协议
   HTML Form URL Encoded---------------------这个是发往网站的表单信息

物理层的数据帧概况
数据链路层以太网帧头部信息
互联网层IP包头部信息
传输层TCP数据段头部信息

流量分析之错误统计

在这里插入图片描述

在wireshark里可以在分析—>专家分析,里面清楚看到抓包里面出现的错误等各种信息的统计

这次我打开BiliBili播放了一个视频，并抓取了整个过程的各种包，上图就是这次抓包里面的专家分析里的信息。

可以看见这里面有四个信息

对话（Chat）： 关于正常通信的基本信息
注意（Note）： 正常通信时的异常数据包
警告（Warning）： 不是正常通信中的异常数据包（个人理解为：非正常的通信产生的数据包）
错误（Error）： 数据包中的错误，或者解析器解析时的错误

在这个包里，可以看见ERROR信息有两种错误分别是

TLSCiphertext length MUST NOT exceed 2^14 +2048

从字面意思是说TLS密文长度不得超过 2^14 +2048

点开得到以下信息：

在这里插入图片描述所以这些协议传输的TLS密文的长度过长，且出现的数量为496

New fragment overlaps old data (retransmiaaion?)
这个出现的数量比较少，有17个包，这个错误是tcp里面的报文出现了重复传输。

在Warining信息里有10个类型的错误
在这里插入图片描述
其中Ignored Unknown Record占的比例最多，有38899个。通过查询资料发现出现这个情况的原因有以下的两点：

抓包迟了，部分SSL/TLS的协商数据没有获取，Wireshark无法识别和解析。
数据包使用了特殊的协议类型，Wireshark无法正确，等待后期Wireshark改进。

然后Previous segment not captured(上个报没有抓到)里也出现了527个
在这里插入图片描述

The frame is a out of order segment.(收到乱序的包)

当数据包被乱序接收时，会利用序列号进行检测

在Note信息里可以看到以下信息：

TCP重传（retransmission）：数据包丢失的结果。发生在收到重传的ACK,或者数据包的重传计时器超时的时候。
在这里插入图片描述

重复ACK（Duplicate ACK ）：当一台主机没有收到下一个期望序列号的数据包时，会生成最近一次收到的数据的重复ACK。

零窗口探查：在一个零窗口包被发送出去后，用来监视TCP接收窗口的状态。

保活ACK(ACK to Tcp keep-alive)：用来响应保活数据包
在这里插入图片描述

零窗口探查ACK：用来响应零窗口探查数据包。

窗口已满：用来通知传输主机接受者的TCP窗口已满。

在Chat窗口里面可以看到以下信息

NOTIFY * HTTP/1.1\r\n

这是通知
TCP window update

这是窗口更新：由接收者发送，用来通知发送者TCP接受窗口的大小已经发生变化。
POST /eapi/batch HTTP/1.1\r\n、

这是一个表单
Connection establish acknowledge (SYN+ ACK): server port 80

与端口80建立了连接，即浏览器
Connection establish request (SYN): server port 80

与端口80建立了连接，即浏览器
Connection finish (FIN)

连接完成

流量分析之IO图

通过统计—>I/O图，即可打开I/O图表

所有分组选择line样式，TCP错误分组选择bar样式：

X轴为时间间隔，每一小格为1秒；
Y轴是速率单位（Unit）：Packets/1秒。
通过放大可以看到，在第2秒时，传输packets速率的最大值为一秒1072个。7秒得时候为1026、在76秒又一次出现高峰969。在74秒是出现最低点140。
双击Y Axis后，会有一个下拉键，下拉后还能进一步对I/O表内数据进行处理：
选择I/O表自带的SUM功能可以得到每个单位时间内实际传输的IP数据包总字节数：

下面我选用了高级信息统计工具：

（1）TCP流图形—吞吐量：
在这里插入图片描述
统计单位时间内在某一指定方向上传输的数据包的字节数（左边的Y轴），以此统计出来的吞吐量只是某个方向上传输的应用程序数据（不含IP头与TCP头）的吞吐量，单位为字节/秒（右边的Y轴）。
左边的Y轴就是包中的Len值，对应的是深蓝色的点；
右边的Y轴对应的是咖啡色的斜线。
通过此图，不但能了解TCP连接的吞吐量，而且还能分析到此时TCP连接稳定。

（2）TCP流图形—时间序列（tcptrace）：
在这里插入图片描述

通过查阅资料可知：
斜线的角度越大，表示文件的传输速率很高，反之，文件传输缓慢。
一条连绵不断的斜线就表示正常的文件传输，而斜线时断时续，表示文件传输存在问题。我截到的两条斜线是接近平行的，几乎没有无效重传。这也与之前在捕获文件属性中我分析到的“无丢弃文件“这一条相吻合。上面一条表示TCP接收窗口，下面一条表示在单位时间内，受监控的TCP流在某个方向所传数据的字节流。通过查阅资料可知，当两条线之间空间较大的时候，表示接收主机尚有缓存。

流量分析之ARP漏洞

ARP（Address Resolution Protocol) 协议，即地址解析协议。该协议的功能就是将IP地址解析成MAC地址。

ARP基础知识

**ARP (Address Resolution Protocol,地址解析协议)**是根据IP地址获取物理地址的一个TCP/IP协议。由于OSI模型把网络工作分为七层，IP 地址在OSI模型的第三层，MAC地址在第二层，彼此不直接通信。在通过以太网发送IP数据包时，需要先封装第三层(32位IP地址)和第二层(48 位MAC地址)的报头。但由于发送数据包时只知道目标IP地址，不知道其MAC地址，而又不能跨越第二、三层，所以需要使用地址解析协议。使用地址解析协议后，计算机可根据网络层IP数据包包头中的IP地址信息对应目标硬件地址(MAC地址)信息，以保证通信的顺利进行。ARP的基本功能就是负责将-一个已知的IP地址解析成MAC地址，以便主机间能正常进行通信。如图10.1所示，假设PC1发送数据给主机PC2时，需要知道PC2的MAC地址。可是PC1是如何知道PC2的MAC地址的呢?它不可能知道每次所需要的MAC地址，即使知道也不可能全部记录下来。所以，当PC1访问PC2之前就要询问PC2的IP地址所对应的MAC地址是什么。这时就需要通过ARP请求广播实现。

ARP 工作流程

ARP工作过程分两个阶段，一个是ARP请求过程，一个是ARP响应过程。
工作流程如图：

在上图中，主机PC1的IP地址为192.168.1.1, 主机PC2的IP地址为192.168.1.2。当主机PC1和主机PC2通信时，地址解析协议可以将主机PC2的IP地址(192.168.1.2)解析成主机PC2的MAC地址。PC1和PC2的详细通信过程如下所示。

(1) 当主机PC1想发送数据给主机PC2时，首先在自己的本地ARP缓存表中检查主机PC2匹配的MAC地址。

(2) 如果主机PC1在缓存中没有找到相应的条目，它将询问主机PC2的MAC地址，从而将ARP请求帧广播到本地网络上的所有主机。该帧中包括源主机PC1的IP地址和MAC地址。本地网络上的每台主机都接收到ARP请求并且检查是否与自己的IP地址匹配。如果主机发现请求的IP地址与自己的IP地址不匹配，它将会丢弃ARP请求。

(3)主机PC2确定ARP请求中的IP地址与自己的IP地址匹配，则将主机PC1的地址和MAC地址添加到本地缓存表。

(4)主机PC2将包含其MAC地址的ARP回复消息直接发送回主机PC1 (这个数据帧是单播)。

(5)当主机PC1收到从主机PC2发来的ARP回复消息时，会将主机PC2的IP和MAC地址添加到自己的ARP缓存表。本机存是有生存期的，默认ARP缓存表的有效期是120s。当超过该有效期后，将再次重复上面的过程。主机PC2的MAC地址一旦确定，主机PC1就能向主机PC2发送IP信息了。

ARP缓存表

ARP缓存中包含一个或多个表，它们用于存储IP地址及其经过解析的MAC地址。在ARP缓存中的每个表又被称为ARP缓存表。下面将介绍ARP缓存表的由来、构成及生命周期等。

**１.**ARP缓存表的由来
ARP协议是通过目标设备的IP地址查询目标设备的MAC地址，以保证通信的顺利进行。这时就涉及到一个问题，一个局域网中的电脑少则几台，多则上百台，这么多的电脑之间，如何能记住对方电脑网卡的MAC地址，以便数据的发送呢?所以，这就有了ARP缓存表。

２.ARP缓存表维护工具ARP命令

显示和修改地址解析协议(ARP)使用的“IP 到物理”地址转换表。

ARP -s inet_addr eth_addr [if_addr]
ARP -d inet_addr [if_addr]
ARP -a [inet_addr] [-N if_addr] [-v]

-a 　　通过询问当前协议数据，显示当前 ARP 项。
　　如果指定 inet_addr，则只显示指定计算机的 IP 地址和物理地址。如果不止一个网络接口使用 ARP，则显示每个 ARP 表的项。
-g 　　与 -a 相同。
-v 　　在详细模式下显示当前 ARP 项。所有无效项和环回接口上的项都将显示。
inet_addr 指定 Internet 地址。
-N if_addr 显示 if_addr 指定的网络接口的 ARP 项。
-d 　　删除 inet_addr 指定的主机。inet_addr 可以是通配符 *，以删除所有主机。
-s 　　添加主机并且将 Internet 地址 inet_addr与物理地址 eth_addr 相关联。物理地址是用连字符分隔的 6 个十六进制字节。该项是永久的。
eth_addr 指定物理地址。
if_addr 　如果存在，此项指定地址转换表应修改的接口的 Internet 地址。如果不存在，则使用第一个适用的接口。
示例:

arp -s 157.55.85.212 00-aa-00-62-c6-09… 添加静态项。
arp -a … 显示 ARP 表。

下图是本机的ARP缓存表，WAN接口IP地址是192.168.1.101
在这里插入图片描述

开始捕获ARP协议包

打开wires hark，捕获WLAN接口（因为本机使用的是无线网连接），通过IPCONFIG的查询得知自己的IP地址为
在这里插入图片描述

－－＞点击开始捕获

最后得到３０００个包，然后搜索ARP协议得到如图的信息
在这里插入图片描述

可以从该界面Protocol列看到其中有3个响应包，其它都是请求包

分析ARP协议包

首先先看一下ARP请求报文格式
在这里插入图片描述

该表中每行长度为４个字节，即３２位。表中灰色的部分是以太网（Ethernet　II类型）的帧头部。这里共３段文字，分别如下所示。

第1个字段是广播类型的MAC地址: 0XFF-FF-FF-FF-FF-FF, 其目标是网络上的
所有主机。
　第2个字段是源MAC地址，即请求地址解析的主机MAC地址。
　第3个字段是协议类型，这里用0X0806代表封装的上层协议是ARP协议。接下来是ARP协议报文部分，其中各个字段的含义如下。
　硬件类型:表明ARP协议实现在哪种类型的网络上。
　协议类型:表示解析协议(上层协议)。这里一般是0800，即IP。
　硬件地址长度: MAC地址长度，此处为6个字节。
　协议地址长度: IP 地址长度，此处为4个字节。
　操作类型:表示ARP协议数据报类型。1表示ARP协议请求数据报，2表示ARP协议应答数据报。
　源MAC地址:发送端MAC地址。
　源IP地址:表示发送端协议地址(IP地址)。
　目标MAC地址:目标端MAC地址。
　目标IP地址：表示目标端协议地址（IP地址）

ARP应答协议报文和ARP请求协议报文类似。不同的是，此时以太网帧头部的目标MAC地址为发送ARP协议地址解析请求的MAC地址，而源MAC地址为被解析的主机的MAC地址。同时，操作类型字段为2,表示ARP协议应答数据报，目标MAC地址字段被填充为目标MAC地址。ARP应答协议报文格式如下表所示。
在这里插入图片描述
接下来分析一下ARP请求包

ARP请求包

在这里插入图片描述
由上图可以得出该请求是询问谁有ip地址为192.168.1.1的MAC地址，知道的告诉IP地址192.168.1.101

这是第52帧的数据报的详细信息。其中该包的大小为42字节

这是表示以太网帧头部信息。其中源MAC地址为18:56:80:01:d6:2d,目标MAC地址为24:69:68:cf:52:9c
在这里插入图片描述
这是表示地址解析协议内容，request表示该包是一个请求包。在该包包括有ARP更加详细的字段信息，如下所示：
通过以上内容的介绍，可以确定这是一个在以太网上使用IP的ARP请求。从该内容中，可以看到发送方的IP（192.168.1.101）和MAC 地址（18:56:80:01:d6:2d),以及接收方的IP地址（192.168.1.1）MAC地址（24:69:68:cf:52:9c)（由于该包是ARP的请求包，所以按理来说应该是不知道MAC地址即地址应该为全零的，这里出现这个情况有点奇怪）

关于以上的ARP头部内容和前面介绍的ARP请求报文格式是相对应的，如下表所示。
在这里插入图片描述
同理ARP的响应包如下图：

这是回应刚才的请求包给他的回应是IP地址（192.168.1.1）的MAC地址（24:69:68:cf:52:9c）

针对刚刚请求包出现的问题，我有查看了其他的请求包
在这里插入图片描述

这里现象比较正常，但是却没有此包的响应包。

问题分析

针对这个问题，由于这个IP 地址是内网的，所以我通过登陆到路由器的网关查了一下

$C:\Users\Xiang0712\Desktop\QQ截图20191017235742.png$
在这里插入图片描述
发现这个地址是我们使用的一个智能音箱，可能是由于它没有响应的原因所以一直都在请求。

针对为什么ARP请求包里的目的MAC地址是可见的，我的猜测是可能这个地址在电脑的ARP缓存表里有记录，所以就可见了。

为了验证我的猜测，首先查看了ARP缓存表
在这里插入图片描述
可以看见ARP缓存表确实存了192.168.1.1的MAC地址。由于刚刚我使用ping 192.168.1.111，所以它的MAC地址也是可见的。这里的192.168.1.1是网关地址，192.168.1.255是广播地址。

然后发现刚才的包里出现了请求获得192.168.1.105
$C:\Users\Xiang0712\AppData\Roaming\Typora\typora-user-images\1571328720438.png$

所以用这个IP做实验，在CMD里ping一下这个地址，并同时抓一下这个包
在这里插入图片描述
得到上图的结果，此时的请求包依然是正常的，即MAC地址是不可见的

觉得可能是由于缓存表可能没有反应过来，依然坚持我的猜想，再抓了一次包
$C:\Users\Xiang0712\AppData\Roaming\Typora\typora-user-images\1571329388187.png$
这里的显示依然正确
那么到底是出现什么问题了呢，再次看了刚刚出现的问题，总结这个问题为：主机知道默认网关MAC地址为什么还要发ARP请求？

为了解决这个问题查阅了相关文献，在RFC 1122—>Requirements for Internet Hosts – Communication Layers里的25页里找到了与这个相关的知识，就是

Unicast Poll – Actively poll the remote host by periodically sending a point-to-point ARP Request to it, and delete the entry if no ARP Reply is received from N successive polls. Again, the timeout should be on the order of a minute, and typically N is 2.

https://tools.ietf.org/html/rfc1122

大致意思就是单播轮询：通过定期向其发送点对点ARP请求来主动轮询远程主机，如果从N次连续的轮询中未收到ARP答复，则删除该条目。同样，超时时间应为一分钟左右，通常N为2。

所以这就解释了为什么我的主机明明有网关的MAC地址为什么还要向它发送请求，因为ARP缓存表只是缓存，动态的ARP地址要不断的更新，单播轮询就是它更新的一种方式。

在查询资料的过程中我发现ARP协议有简单、易用的优点，但是因为没有任何安全机制而容易被攻击发起者利用。目前ARP攻击已经成为局域网安全的一大威胁，针对常见的ARP攻击行为，如仿冒用户、仿冒网关、ARP泛洪攻击等。
所以在我们使用未知的无线网连接的时候一定要小心，或者尽量不要使用免费的无线网。

流量分析之音频包

RTP基础知识

RTP英文名是Real-Time Stream Protocol,顾名思义是一种实时性很高的协议。这种协议和http协议很类似，都是纯文本来发送消息的，不同的是rtp是有状态的，http是没有状态的。怎么理解呢?http协议发了之后，连接就断开了，而且下一次发与上一次没有什么依赖关系，而RTP协议需要知道现在是个什么状态，可以发送什么消息…

RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由RTCP来提供。

RTP: Real-time Transport Protocol,实时传输协议，一般用于多媒体数据的传输。

RTCP: RTP Control Protocol，实时传输控制协议，同RTP一起用于数据传输的监视，控制功能。

RTSP: Real Time Streaming Protocol,实时流协议，用于多媒体数据流的控制，如播放，暂停等。

RTP/RTCP相对于底层传输层，和RTSP，SIP等上层协议一起可以实现视频会议，视频直播等应用。

为什么要搭配这些协议呢？RTP位于传输层（通常是UDP）之上，应用程序之下，实时语音、视频数据经过模数转换和压缩编码处理后，先送给RTP封装成为RTP数据单元，RTP数据单元被封装为UDP数据报，然后再向下递交给IP封装为IP数据包。这么说RTP是没有保证传输成功的，

那怎么保证呢？就要用到rtcp。

RTCP消息含有已发送数据的丢包统计和网络拥塞等信息，服务器可以利用这些信息动态的改变传输速率，甚至改变净荷的类型。RTCP消息也被封装为UDP数据报进行传输。

TP协议的应用

RTP用于在单播或多播网络中传送实时数据。

1：简单的多播音频会议.语言通信通过一个多播地址和一对端口实现，一个用于音频数据rtp，一个用于控制包rtcp

2:音频视频会议.这两种媒体将分别在不同的RTP会话中传送，同步的话就需要根据RTCP包中的计时信息了（network time protocol）

音频包的抓取

首先打开一个进行实时传输视频的软件，同时进行抓包
在这里插入图片描述
然后点击右键选择Decode As，选择Transport,选择里面的RTP，然后点击“OK”即可完成转换。

点击ok，即可看到如下内容： $C:\Users\Xiang0712\AppData\Roaming\Typora\typora-user-images\1571389457197.png$
这里的G.711A是国际电信联盟ITU-T制定出来的一套语言压缩包标准，采样率为每秒8000，计算方式如下：

如下图的音频时延=(1788669046-1788669286)/8000=0.03s即30ms
在这里插入图片描述
音频包的播放，上一步做完以后，点击Telephony，选择RTP，然后选择Stream analysis

打开RTP Stream Analysis页面后，点击player，在这里面可以看到码流的Sequence Num、Delay、Jitter、Status等等信息，可以对这个码流的Payload另存、刷新、图形化、播放等操作。
在这里插入图片描述
点击play按钮后，出现页面如下图：然后在点击Decode

点击Decode以后如下图：勾选From……选项，点击play就可以播放听到声音了。

但是听到的声音噪音很多，可能是数据包丢失的有点多，和出现了乱码的情况。

抓包应用抓取网站密码

http协议：明文协议

https协议: 加密协议

在百度上找到使用HTTP协议的网站：http://www.chiaoyo.com.tw/alogin.asp
在这里插入图片描述
该账号是我注册的，但是由于长期未使用，所以不知道密码是多少，所以现在我想使用wires hark通过抓包，来找到密码是多少。

首先打开wires hark -->点击开始抓取
然后打开网站，点击登陆，登陆完成后就停止抓包
最后得到抓的包：
在这里插入图片描述由于我同时开了几个网站，所以包有一点多
然后输入http,进行过滤得
我们要获取得是post(表单请求)，所以点开第一个包

所以我们点开HTML Form URL Encoded，

就得到
userid（用户id）：xiang0712
password（密码）：147258