计算机网络抓包实验报告Word格式文档下载.docx

计算机网络抓包实验报告Word格式文档下载.docx

《计算机网络抓包实验报告Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《计算机网络抓包实验报告Word格式文档下载.docx（28页珍藏版）》请在冰豆网上搜索。

IMPECHO报文

ICMPECHOREPLY报文：

（2）找出上述报文对应MAC帧的源MAC地址、目的MAC地址、类型、数据长度，附

上与原始数据的对应图。

ARP请求报文

ARP响应报文

ICMPECHOREPLY报文

（3）找出ICMPECHO和ECHOREPLAY报文的首部长度、总长度、生存时间、协议、

首部校验和、源IP地址、目的IP地址，计算单次成功ping的时间，附上与原始数据

的对应图。

ICMPECHO报文数据包如下：

可看到时间标记为10：

28：

06.312741400

ECHOREPLAY报文：

时间标记为10：

06.314322400

单次成功ping的时间=10：

06.314322400-10：

06.312741400=0.002570000s

所以单次成功ping的时间0.00257秒

（4）找出ARP请求报文希望获得的MAC地址及其对应的IP地址，附上对应截图。

从图中可以知道ARP请求报文希望获得的MAC地址为50:

7B:

9D:

07:

D0:

B2。

它对应的IP地址为：

192.168.0.100。

因为此时是IP地址为192.168.0.150在ping192.168.0.100，所以是192.168.0.150给192.168.0.100发送ARP请求报文，所以捕获到的目的IP地址为192.168.0.100。

（5）举例说明MAC帧、IP包、ICMP报文的关系。

用我们抓取的ICMPEcho报文举例说明：

从第0字节到第77字节是一个完整的MAC帧，总长度78字节。

去掉MAC帧的首部（第0到13个字节）和尾部（FCS共4字节），保留的从第14字节到第73字节是一个完整的IP包。

再去掉IP包首部（第14到33字节），保留的为ICMP报文，即MAC帧包含IP包，IP包包含ICMP报文。

二、实践容2

1.PC机的默认网关配置为192.168.0.x,x在250-254之间。

配置默认网关为192.168.0.251，如图所示：

2.两台PC通过交换机或网线互相ping通。

注：

ping命令不带-t参数。

3.先执行arp–d命令，开始抓包，然后执行ping192.168.0.255命令。

请根据抓包结果分析此ping命令执行过程中数据报文的传输情况，并附上相应截图。

在进行这一步实验时，我们组发现如果是两台电脑用网线相连，无论是哪台电脑执行ping192.168.0.255命令，都会请求超时。

而当我们用交换机将全部4台电脑（IP地址分别为192.168.0.100，192.168.0.150，192.168.0.77，192.168.0.88）连在一起时，再执行ping192.168.0.255命令，IP地址为192.168.0.150，192.168.0.77，192.168.0.88的三台主机均会有如下显示，而192.168.0.100的主机执行ping192.168.0.255命令后依然为请求超时。

192.168.0.150执行ping192.168.0.255命令后结果

之后我们抓取ARP与ICMP报文进行分析，IP地址为192168.0.150的主机抓取的报文如下（只截取了一部分）：

将抓包结果与之前ping结果对照，可以发现每执行一次ping命令，会收到4次来自192.168.0.100的回复，从抓包结果中可以将每次回复的过程找出来如下所示：

从中可以看出MAC地址为80:

62:

66:

E4:

E5:

12的主机先向以太网广播发送了一条APR请求报文，之后IP地址192.168.0.150向以太网广播的IP地址192.168.0.255发送了一条ICMPEcho报文，由IP地址为192.168.0.100的主机向192.168.0.150回复了一条ICMPEchoReply报文；

之后MAC地址为50:

B2主机连续向02:

32:

63:

44:

12发送了5次ARP相应报文。

按常规来说如果主机都通过交换机连接，那么如果一个主机执行ping192.168.0.255命令，那么他应该收到来自所有其它主机的回复，而在我们组的实验中只能收到同一主机（192.18.0.100）的回复，收不到其他两台主机的回复。

这个问题可能是由于我们另外三台主机的默认网关配置的一样，而与另一台不一样，在执行ping192.168.0.255命令时会无视同为192.168.0.251相同默认网关的另外两台主机，只能收到默认网关为192.168.0.250的主机的回复。

还有一种可能性是交换机接口的配置不同，导致ping192.168.0.255命令时的结果不同。

因为时间原因，我们组也没有对这个问题进行进一步探讨。

4.先执行arp–d命令，开始抓包，然后执行ping202.115.32.36命令。

我们四台主机连在交换机上执行ping202.115.32.36命令均请求超时。

所以可知此连接不通。

5.主机A、B、C共同连在交换机上，主机C配置为主机A的网关。

主机ApingB，B抓取ARPResponse报文，ping通后主机A执行arp–a。

然后，主机B利用抓包工具软件修改抓取的ARPResponse报文，仅修改ARPResponse报文中B的MAC地址（注：

不是MAC帧首部的B的MAC地址），修改后发送（发送10次以上），在主机A上再执行arp–a。

对比两次的arp–a的结果，分析原因，附上相应截图。

B继续持续发送修改后的ARPResponse报文，在主机A上pingB，记录ping的情况，附上截图，并分析原因。

因为我们组没有交换机，所以整个实验是两台电脑用网线连接做的。

第一次ApingB的结果：

A执行arp–a的结果：

从图中可看到B的IP地址为192.168.0.150，MAC地址为50-7B-9D-07-D0-B2。

此时B抓取ARPResponse报文：

修改抓取的ARPResponse报文，仅修改ARPResponse报文中B的MAC地址。

所以选择第14个数据包进行修改，将其设置为要发送的数据包，在工具栏中点击“编辑要发送的数据包”，把B的MAC地址改为52-22-22-22-22-22如下图：

连续不断点击发送按钮，在主机A上再执行arp–a，结果如下：

从途中可以看出IP地址192.168.0.150对应的MAC地址变为了52-22-22-22-22-22，即为修改后的值，再在主机A上pingB，结果如下：

会看到主机A已经ping不通B（192.168.0.150）了，这是因为B将修改后的ARP响应报文发送给A后，主机A中默认的B的MAC地址发生了改变，执行ping192.168.0.150时，默认的192.168.0.150对应的MAC地址修改为52-22-22-22-22-22，而本身192.168.0.150对应的MAC地址为修改之前（50-7B-9D-07-D0-B2）的值，所以当然不会ping通。

三、实践容3

访问因特网上的web站点，抓取TCP连接的三次握手和四次挥手过程，附上相应截图，并分析三次握手和四次握手的详细过程，包括源、目的IP，源、目的端口号，序号和确认序号的变化情况，标志位SYN、FIN和ACK的值等。

关闭无用软件后，用电脑访问.baidu.，同时用omnipeek软件抓取TCP数据包。

从中可以找到TCP连接的三次握手和四次挥手过程。

找到三次握手的数据包如下：

四次握手的数据包如下：

现进行具体分析。

1.第一次握手

数据包容如下：

第一次握手：

建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认。

客户端向服务器发送连接请求包，标志位SYN（同步序号）置为1，序号为X=1812017573。

从数据包中可以看到：

源IP地址：

222.18.0.78

目的IP地址：

117.78.58.31

源端口号：

51835

目的端口号：

8089

序号：

1812017573

确认序号：

标志位：

SYN=1ASK=0FIN=0

2.第二次握手

服务器收到客户端发过来报文，由SYN=1知道客户端要求建立联机。

向客户端发送一个SYN和ACK都置为1的TCP报文，设置初始序号Y=0，将确认序号设置为客户的序列号加1，即X+1。

3698809199

1812017574为第一次握手的序号+1

SYN=1ASK=1FIN=0

3.第三次握手

客户端收到服务器发来的包后检查确认序号是否正确，即第一次发送的序号加1（X+1=1）。

以及标志位ACK是否为1。

若正确，服务器再次发送确认包，ACK标志位为1，SYN标志位为0。

确认序号=Y+1=0+1=1，发送序号为X+1=1。

客户端收到后确认序号值与ACK=1则连接建立成功，可以传送数据了。

1812017574为第一次握手的序号+1

3698809200为第二次握手的序号+1

SYN=0ASK=1FIN=0

所谓的“三次握手”即对每次发送的数据量是怎样跟踪进行协商使数据段的发送和接收同步，根据所接收到的数据量而确定的数据确认数及数据发送、接收完毕后何时撤消联系，并建立虚连接。

为了提供可靠的传送，TCP在发送新的数据之前，以特定的顺序将数据包的序号，并需要这些包传送给目标机之后的确认消息。

TCP总是用来发送大批量的数据。

当应用程序在收到数据后要做出确认时也要用到TCP。

4.第一次挥手

客户端给服务器发送TCP包，用来关闭客户端到服务器的数据传送。

将标志位FIN和ACK置为1，序号为X，确认序号为Z。

3698809311

1812018535

SYN=0ASK=1FIN=1

5.第二次挥手

服务器收到FIN后，发回一个ACK（标志位ACK=1）,确认序号为收到的序号加1，序号为收到的确认序号=Z。

1812018535为第一次挥手的确认序号

3698809312为第一次挥手的序号+1

6.第三次挥手

服务器关闭与客户端的连接，发送一个FIN。

标志位FIN和ACK置为1，序号为Y，确认序号为X=2。

7.第四次挥手

客户端收到服务器发送的FIN之后，发回ACK确认（标志位ACK=1）,确认序号为收到的序号加1，序号为收到的确认序号X=2。

3698809312为第一次挥手序号+1

1812018536为第一次挥手确认序号+1

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。

这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。

收到一个FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。

首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

（1）TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送。

（2）服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。

和SYN一样，一个FIN将占用一个序号。

（3）服务器关闭客户端的连接，发送一个FIN给客户端。

（4）客户端发回ACK报文确认，并将确认序号设置为收到序号加1。

在实验中，我发现在四次挥手时客户端与服务端反了，这与我们在课堂上学到的结论不符，经过几次重复试验后，我们发现无论如何找到的三次握手与四次挥手的客户端与服务端都是反的，但其他的标志位的变化及序号与确认序号的变化都是正确的，所以我们猜测是在访问.baidu.后目标网页对客户端与服务端进行了调换，或者是目标网址先执行了四次挥手操作。

四、课后实践

实践1

抓取大学教务系统账号密码，打开教务处网页输入学号20与密码271518，用omnipeek软件抓取TCP数据包，结果如下：

在图中找到相应的数据包。

成功获取输入的账号和密码（明文）。

实践2

登录163，账号为163.

同时用抓取TCP数据包，抓到的数据包如下：

图中红框所示的两个数据包均能得到163账户。

1582号数据包：

1583号数据包：

分析：

教务系统使用的http协议，而网易使用的https协议。

https在http和TCP之间

加了安全层（TSL或SSL），对访问的数据流进行了安全保护，所以通过普通的抓包软件我们不能获取用户的登录密码。