计网实验四补充自用

[TOC]

1.关于PING报文长度

linux（Debian12 ping本地windows）56数据+20+8=84字节

(base) root@kokomi:~# ping 192.168.2.2
PING 192.168.2.2 (192.168.2.2) 56(84) bytes of data.
64 bytes from 192.168.2.2: icmp_seq=1 ttl=128 time=0.843 ms
64 bytes from 192.168.2.2: icmp_seq=2 ttl=128 time=1.17 ms
64 bytes from 192.168.2.2: icmp_seq=3 ttl=128 time=0.852 ms
64 bytes from 192.168.2.2: icmp_seq=4 ttl=128 time=0.883 ms
64 bytes from 192.168.2.2: icmp_seq=5 ttl=128 time=1.12 ms
64 bytes from 192.168.2.2: icmp_seq=6 ttl=128 time=0.918 ms
64 bytes from 192.168.2.2: icmp_seq=7 ttl=128 time=0.942 ms
64 bytes from 192.168.2.2: icmp_seq=8 ttl=128 time=0.927 ms
64 bytes from 192.168.2.2: icmp_seq=9 ttl=128 time=0.862 ms
^C
--- 192.168.2.2 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8051ms
rtt min/avg/max/mdev = 0.843/0.946/1.170/0.111 ms

AI解释：

---

ICMP Echo 请求（即ping）的默认数据部分通常是56个字节，这与UNIX系统和许多网络工具中的传统有关。这个选择并不是强制性的，而是历史惯例和一些实际考虑的结果。

ICMP Echo 请求报文结构

一个完整的ICMP Echo 请求报文由以下几个部分组成：

1. IP头部（通常20字节）
2. ICMP头部（8字节）
3. 数据部分（可变长度，默认情况下为56字节）

因此，一个典型的ICMP Echo 请求报文总大小是84字节（20 + 8 + 56），但这不包括任何额外的选项或填充。

为什么是56个字节？

• 历史原因：早期的ping实现中，数据部分被设置为56字节。随着时间的推移，这个值成为了默认标准，并在很多操作系统和网络工具中得到了广泛采用。

• 实用性：56字节的数据部分足够大，可以包含一些有用的信息，如时间戳或者序列号，同时又不会太大以至于增加不必要的网络负载。它提供了一个良好的平衡点，在大多数情况下都能满足需求。

• 显示格式：当使用命令行工具如ping时，输出通常会提到“字节=56”，这是因为它指的是ICMP Echo 请求的数据部分大小。实际上，加上ICMP头部后的整个ICMP报文是64字节（8 + 56）。

• MTU考量：以太网的最大传输单元（MTU）通常是1500字节。对于大多数局域网内的通信来说，一个小于MTU的包可以避免分片问题。56字节的数据部分确保了即使加上IP和ICMP头部，整个包仍然远小于MTU，从而减少了网络复杂性和延迟。

总结

56字节的数据部分是一个约定俗成的标准，它既保持了向后兼容性，又提供了足够的灵活性来适应各种应用场景。当然，如果你需要发送不同大小的数据部分，可以在编写自己的ICMP Echo请求时调整这个数值，但要注意不要超过网络路径上的最小MTU以避免分片问题。此外，某些网络设备或防火墙可能对ICMP报文有特定的限制或处理方式，这也可能是维持默认56字节的原因之一。

---

但windows抓包得到：98

明白了！你已经找到了问题的关键：Wireshark显示的98字节长度确实包括了以太网数据帧的头部信息。让我们具体解析一下这个长度是如何构成的。

以太网帧结构

一个典型的以太网II帧（最常见的类型）包含以下部分：

1. 目的MAC地址 (6字节)
2. 源MAC地址 (6字节)
3. 类型字段 (2字节，对于IPv4为0x0800)
4. 数据（即IP数据包）
5. 帧校验序列 (FCS) (4字节)

ICMP Echo 请求报文结构

ICMP Echo 请求报文（ping请求）在IP层上的结构如下：

1. IP头部 (通常20字节)
2. ICMP头部 (8字节)
3. 数据部分 (默认情况下为56字节)

因此，一个标准的ICMP Echo 请求报文总大小是84字节（20 + 8 + 56），但这不包括IP头部可能包含的选项或填充。

计算总长度

当你使用Wireshark抓取来自Linux系统的ICMP Echo请求时，看到的长度为98字节，可以这样解释：

• 以太网帧头：

  • 目的MAC地址：6字节
  • 源MAC地址：6字节
  • 类型字段（0x0800表示IPv4）：2字节
  • 总计：14字节

• IP数据包：

  • IP头部：20字节
  • ICMP头部：8字节
  • ICMP数据部分：56字节
  • 总计：84字节

将这两部分相加，我们得到：

14字节（以太网帧头） + 84字节（IP数据包） = 98字节

这正是你在Wireshark中看到的长度。需要注意的是，Wireshark通常不会包含帧校验序列（FCS）在显示的数据包长度中，因为FCS是在物理层添加的，并且在大多数情况下对上层协议分析不是必需的。

总结

所以，98字节的长度确实是由于Wireshark显示了完整的以太网帧内容，包括以太网帧头中的目的MAC地址、源MAC地址和类型字段（0x0800），以及后续的IP数据包。如果你只关心IP层的数据包长度，可以在Wireshark中查看IP分组的具体信息，或者通过过滤器来专注于特定层次的内容。

---

ICMP攻击

ICMP攻击
ICMP攻击
ICMP协议对于网络安全具有极其重要的意义。ICMP协议本身的特点决定了它非常容易被用于攻击网络上的路由器和主机。例如，在1999年8月海信集团悬赏“50万元人民币测试防火墙”的过程中，其防火墙遭受到的ICMP攻击达334050次之多，占整个攻击总数的90%以上。可见，ICMP的重要性绝不可以忽视。
比如，可以利用操作系统规定的ICMP数据包最大尺寸不超过64KB这一规定，向主机发起“Ping of Death”（死亡之Ping）攻击。“Ping of Death” 攻击的原理是：如果ICMP数据包的尺寸超过64KB上限时，主机就会出现内存分配错误，导致TCP/IP堆栈崩溃，致使主机死机。（操作系统已经取消了发送ICMP数据包的大小的限制，解决了这个漏洞）
此外，向目标主机长时间、连续、大量地发送ICMP数据包，也会最终使系统瘫痪。大量的ICMP数据包会形成“ICMP风暴”，使得目标主机耗费大量的CPU资源处理，疲于奔命。

ICMP报文的长度本身并不会直接导致其被丢弃

ICMP（Internet Control Message Protocol）报文的最短长度取决于其头部和所携带的数据。对于最常见的ICMP Echo Request和Echo Reply消息，最小长度是由头部决定的，因为数据部分可以为空。

### ICMP 报文结构

一个典型的ICMP报文包括：

1. **ICMP头部**：8字节
   - **Type** (1字节)：表示ICMP消息类型。
   - **Code** (1字节)：提供关于Type的额外信息。
   - **Checksum** (2字节)：用于错误检测。
   - **Identifier** (2字节) 和 **Sequence Number** (2字节)：主要用于Echo Request/Reply中。

2. **数据部分**：可变长度，默认情况下为56字节，但可以更短或更长。

因此，不包含任何数据的ICMP Echo Request或Echo Reply报文的最小长度是8字节（仅头部）。

### IP 层考虑

在实际网络传输中，ICMP报文被封装在一个IP数据包中，所以还需要考虑IP头部：

- **IP头部**：通常20字节（没有选项的情况下）

这意味着，一个不包含任何数据的ICMP Echo Request或Echo Reply报文，在IP层的最小总长度是：


20字节（IP头部） + 8字节（ICMP头部） = 28字节


### 以太网帧最小长度

值得注意的是，以太网帧有一个最小长度要求，即64字节（包括以太网帧头和FCS）。如果整个IP数据包（包括IP头部和ICMP报文）小于这个值，网络设备会在数据部分添加填充字节以满足最小帧大小的要求。这确保了即使是最小的ICMP报文也能符合物理层的传输标准。

### 总结

- **ICMP报文本身**的最短长度为8字节（ICMP头部）。
- **加上IP头部**后的最小长度为28字节。
- **考虑到以太网最小帧大小**，实际在网络上传输时，最小长度可能达到64字节（包括以太网帧头、IP头部、ICMP头部以及必要的填充）。

如果你使用Wireshark抓取这样的最小ICMP报文，你会看到的数据包长度会是64字节，这是因为以太网帧的最小长度要求所致。

2.关于FTP主动模式

在FTP的主动模式（也称为PORT模式）中，客户端会告知服务器它所选择的数据传输端口。这是通过发送一个特定的命令来实现的，即PORT命令。这个命令告诉服务器客户端希望用于数据连接的IP地址和端口号。

PORT命令格式

PORT命令的格式如下：

PORT h1,h2,h3,h4,p1,p2

• h1,h2,h3,h4：代表客户端机器的IP地址，每个字节之间用逗号分隔。
• p1,p2：这两个8位数字组合成16位的端口号，计算方法是p1 * 256 + p2。

例如，如果客户端的IP地址是192.168.1.100，并且它想要使用端口49153进行数据传输，则对应的PORT命令将是：

PORT 192,168,1,100,192,1

这里，49153分解为两个8位数192和1，因为192 * 256 + 1 = 49153。

流程

1. 客户端向服务器发送一个FTP命令，比如LIST列出目录内容或RETR下载文件。
2. 在发送实际的数据请求之前，客户端通过PORT命令通知服务器它将使用的数据端口。
3. 服务器接收到PORT命令后，准备建立到客户端指定端口的数据连接。
4. 当服务器准备好开始数据传输时，它会在控制连接上发送一个回复给客户端，通常是一个三位数的状态码，如150表示文件状态好，准备打开数据连接。
5. 服务器然后主动建立到客户端指定端口的数据连接，并开始传输数据。
6. 数据传输完成后，服务器关闭数据连接，并在控制连接上发送另一个状态码给客户端，如226表示关闭数据连接，请求的操作已完成。

请注意，在现代网络环境中，由于防火墙和NAT的存在，主动模式可能会遇到问题，因此被动模式(PASV)更常被使用。

例如：

56	3.040820	10.30.218.110	10.60.128.222	FTP	80	Request: PORT 10,30,218,110,48,57

$ 48*256+57=12345 $

---

tracert（在Linux和macOS中称为traceroute）命令是网络诊断工具，用于确定IP数据包到达目标主机所经过的路由路径。它通过发送一系列ICMP Echo请求或UDP数据报文到目标地址，并逐步增加这些数据报文的TTL（生存时间）值来实现这一功能。每个中途路由器都会将TTL减1，当TTL达到0时，路由器会丢弃该数据包并向发送端返回一个ICMP“超时”消息，这包括了该路由器的IP地址。通过这种方式，tracert可以收集从源到目的地之间所有路由器的信息。

设计原理

• TTL递增：tracert从TTL=1开始发送数据包，每收到一次超时响应就增加TTL值，直到最终抵达目标主机或达到最大TTL限制。
• ICMP回应：每当一个中间路由器因为TTL为0而丢弃数据包时，它会向源主机发送一个ICMP Time Exceeded消息，其中包含该路由器的IP地址。
• 最终确认：当数据包成功抵达目标主机时，目标主机会返回一个ICMP Echo Reply，表明路径追踪完成。

获取路径信息的准确性

tracert获取的路径信息通常是可以信赖的，因为它直接基于实际传输过程中各路由器的行为。然而，存在一些情况可能影响结果的准确性：

• 防火墙和NAT设备：某些网络设备可能会阻止ICMP消息或者改变数据包的路径。
• 负载均衡和多路径路由：在大型网络中，不同的数据包可能被路由到不同的路径上，导致tracert显示的路径不一致。
• 缓存路由：有些路由器可能会缓存之前的数据包路径，这可能导致后续的tracert测试无法反映出最新的网络拓扑变化。

获取网关信息

• 发送端网关IP和MAC地址：tracert命令本身并不提供获取网关MAC地址的功能，但可以通过抓包工具如Wireshark来捕获ARP请求/响应以获得本地网关的MAC地址。对于网关的IP地址，tracert的第一个跳点通常是发送端所在的局域网网关。

• 目的端网关IP和MAC地址：tracert只能报告到达目的端之前的每一跳路由器的IP地址。要获取目的端所在网络的网关IP地址，通常需要在目的网络内部执行命令，或者由目的端主机提供相关信息。至于MAC地址，由于MAC地址仅在同一个二层网络（如同一局域网）内有效，跨多个路由器后，原始的MAC地址信息会被新的下一跳路由器的MAC地址覆盖，因此tracert无法直接提供目的端网关的MAC地址。

综上所述，tracert能够有效地追踪从发送端到目的端之间的路径，并且可以间接帮助识别发送端的网关IP地址。但是，它不能直接提供目的端所在网络的网关IP地址或MAC地址，后者需要依赖其他方法或工具来获取。