特例-MTU路径的发现过程

特例-MTU路径的发现过程
ICMP“需要存储碎片但不设定比特碎片”和 MTU发现进程
当一个主机给另一个主机发送数据的时候，数据是在一连串的IP数据包中被传播。我们希望数据包是沿着从消息提供者对目的地的路径的最大块。
由IP层的分裂产生的一些问题:
﹒如果某数据包的一段数据丢失，我们需要转播整个数据包。
﹒在路由器上需要存储碎片。
因为一些更简单的防火墙为一个更高的层协议过滤掉他们不包含头信息，所以将阻塞所有的片段。
﹒最大转移单位(MTU)是对单个传输的数据字节最大号码限制的链接层。
﹒在2个主机之间当前路径上的任何最小的MTU链接被称为路径MTU。
2.3.1? MTU路径的发现过程
我们使用非碎片比特在IP头信息作为动态地发现一条给定的线路的路径MTU标记。消息提供者承担一条路径的PMTU是已知的MTU的第一个中断段。
他需要发送所有的数据包并且设置非段位。
如果沿着目的主机的路径，有一路由器需要数据包到片段为了把它传递给下一个中断段,如果非段位被设置，将产生一条ICMP错误消息(类型3代码4“段需要和DF设置”)。
当发送主机收到ICMP错误消息时应该减少假定的PMTU。
当估计的PMTU是足够低的数据包不成碎片时进程能结束。在一些时候形成碎片的数据包，消息提供者自己能停止该过程。DF位通常被加装在所有的数据包,如果一条路由变化成目的主机，并且PMTU降低,我们就能发现借此发现它。?????
因为在路由上拓扑的变化，一条路径的PMTU可能会增加。为了能够检测到它，发送主机应为此链接周期性地增加假定的PMTU。在ICMP中的MTU链接领域 " 碎片存储需要和DF设定 "的错误信息携带MTU跳跃,使来源主机能够知道他需要设置PMTU那条路径以外允许数据包的传送的准确的值(路由器)没有碎片。
2.3.2?? 主机说明
一台主机必须为相关的路径收到需要并且DF位“被错误发送消息的ICMP”碎片时减少他估计的PMTU。RFC 1191不描述发送主机预期的详细行为,因为不同的应用可以有不同的要求，并且不同的实现体系结构可以支持不同的策略。
唯一要求的行为是一个主机必须试图避免与同样的PMTU在不久的将来送更多的消息。一台主机也能停止在IP头信息的碎片存储位的设定(并且路由器在此方法下允许碎片)或减少数据包尺寸。
因为碎片将引起更多的交通并且消费更多的因特网资源，所以好一些的策略是降低消息数据包尺寸。MTU路径的减少使用PMTU发现过程的一个主机必须尽可能快检测到。一台主机可以通过发送大于当前PMTU的数据包检测路径 MTU 的增加,这样PMTU一般不增加，而被一些路由器在路径上拒绝到一个目的主机。
从这将产生传输回到主机，因此必须在很短的时间间隔内增加检查。
RFC 规定检测增加的尝试不能因为目的主机接收的数据包太大而少于10分钟或在已经尝试成功后的2分钟之前.发送主机必须知道怎么处理被不知道怎么处理 PMTU 协议并且不在错误消息包括下一跳跃 MTU 的一台设备发送的“分裂需要和DF位误差消息"的ICMP 。
有一些方法是可以实现的:
﹒PMTU 应该在当前被假定了的 PMTU 之间被设置到最小并且在 576? 16 。
﹒DF 位不应设置在传输未知数据包的路由上.
﹒为一条路径上的PMTU 寻找最准确值。
﹒我们保持在降低的PMTU设置下直到不再收到ICMP错误的DF位发送数据包。
﹒一台主机不能在低与68个字节下面减少路径 MTU 值的估算。
﹒一台主机不能在数据包太大信息的反映上增加路径 MTU 的估计。
?2.3.3 路由器说明
?因为它超过了下一跳跃网络的 MTU ，路由器不能提交一个数据包并且碎片位没被设置时,他被要求产生一 ICMP目标不能到达的信息到数据交换的来源，该数据报源带有合适的代码显示“需要的破碎以及碎片位没被设置”。
在错误消息中路由器必须在错误消息内包括 16bit 的MTU。
0??????????????????? 8????????????????? 16????????????????????????? 31
Type=3?Code=4?Checksum
Unused(zero)?Link MTU
IP header*64 bits of original data of the datagram
插图11: ICMP存储碎片与 MTU连接的要求
? 下一跳跃 MTU字段值应该 在能被提交的最大的数据包的字节上被设置大小,沿着原来的数据包的路径，没被路由器支离破碎的。大小包括 IP 数据报头和IP数据以及没有下部的标准报头。因为每个路由器应该能在没有分裂的情况下提交68个字节的数据包,连接 MTU 域不应该少于 68的值 。
2.3.4 MSS(最大的段长度大小)选择和MTU路径发现过程
RFC 规定除非收到主机的允许，正在做路径 MTU 发现的主机不能送比 576 个字节大的数据包。
当我们正在建立 TCP 时，连接双方在应该被远程系统一最大的段长度大小发送的信息包方面规定数据的最大的数量,MISS(如果结束之一没有定义MSS,它到 536 将没有比它的数量更多的其他结束的允许)。产生的信息包将是通常比SS大40个字节; IP 头的 20 个字节和 TCP 头的 20 个字节。
大多数系统规定MSS是由MTU接口而决定的,该接口是一种远程系统与系统的通信。每个端口一收到其它端口的MSS不应该发送比MSS更大的帧 ,不考虑 PMTU 。在收到以后，路径MTU寻找过程将开始受到影响。
我们将发送IP信息包,该信息包带有允许我们在到目的路径上认出点的位设置 ,目的路径不能处理同目的宿主机加40个字节更大的信息包。
当这样的ICMP错误消息到达时，我们应该降低PMTU到一条路径(根据连接MTU资源，或如果不使用了,关于原实现使用规则)并且重新发送。
MTU的连接值不能是比目的主机的MSS高. 当发生ICMP类型3代码4错误消息而发生重发时，WINDOWS窗口的拥挤不会改变,但是开始会变的缓慢。进程继续直到我们调整一条正确的 PMTU 路径(不收到从中间的路由器发送的ICMP错误消息),它将允许我们到在比IP层更有效的TCP层下的段。
使用ICMP的3.0主机检测协议，主机可以检测出在因特网上一个恶意的计算机攻击者可到达指明的网络上主机关键的信息. 这个过程属于扫描层上集合在一起的信息的第一层中的一个过程。在这个层之间被收集的信息可以导致指向一个(或更多)网络计算机尝试被截断。如果收集的信息足够多将为恶意的计算机攻击者提供可能。
在这段我将讨论主机使用ICMP协议检测方法。我也将给大家介绍一些这方面的技术。现在的操作系统内部没有集成ICMP检测请求消息工具，所以我们将使用第三方的应用程序来实现这个功能。不同的ICMP操作系统核心检测机制通常由操作系统调用而不是被一个用户调用。如果ICMP的检测和回复机制被操作系统启用，操作系统核心将会回答询问。我们可以通过一个很好的示例来解释地址屏蔽的检测和回复。
3.1 ICMP的响应（类型8）和响应回复（类型0）
我们可以使用ICMP响应判断一个目标IP地址是否是激活的响应数据包,判断方法是通过发送一个简单ICMP响应18(ICMP类型8)数据包到目的系统并且等待看ICMP响应回复( ICMP 类型 0 )是否被收到。如果一个ICMP响应回复收到，这将显示目标是激活的(因为一般防火墙很少欺骗从受保护的主机的 ICMP 回响答复); 如果没有回复则意味着发送到P因特网目标设备的ICMP被阻止从受保护的网络或过滤的设备内得到的回响数据包阻止开始的答复0或目标设备已经停止.如果一台目的主机是可达到的，则使用“PING”这种机制的实用程序.在下一个例子 2 台 Linux 机器表明“PING”的用法。一个基于核心 2.4.2 ( 172.18.2.201 ),另一个基于核 心2.2.16 ( 172.18.2.200 )：
[root@godfather /root]# ping 172.18.2.200 PING 172.18.2.200 (172.18.2.200) from 172.18.2.201 : 56(84) bytes of data. 64 bytes from 172.18.2.200: icmp_seq=0 ttl=255 time=617 usec 64 bytes from 172.18.2.200: icmp_seq=1 ttl=255 time=2.489 msec
64 bytes from 172.18.2.200: icmp_seq=2 ttl=255 time=2.499 msec 64 bytes from 172.18.2.200: icmp_seq=3 ttl=255 time=2.499 msec
--- 172.18.2.200 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.617/2.026/2.499/0.813 ms

The snort trace 19 :
05/14/01-11:55:30.171542 172.18.2.201 -> 172.18.2.200 ICMP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF Type:8 Code:0 ID:58628 Seq:768 ECHO 82 9D FF 3A 5C 9E 02 00 08 09 0A 0B 0C 0D 0E 0F ...:/........... 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F ................ 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F !"#$%&'()*+,-./ 30 31 32 33 34 35 36 37 01234567
05/ ICMP TTL:255 TOS:0x0 ID:769 IpLen:20 DgmLen:84 14/01-11:55:30.171542 172.18.2.200 -> 172.18.2.201
Type:0 Code:0 ID:58628 Seq:768 ECHO REPLY 82 9D FF 3A 5C 9E 02 00 08 09 0A 0B 0C 0D 0E 0F ...:/........... 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F ................ 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F !"#$%&'()*+,-./ 30 31 32 33 34 35 36 37 01234567
0???????? 4????????? 8?????????????????? 16????????????????????????? 31
Type?Code=0?Checksum
identifier?SequenceNumber
Data
插图13：ICMP响应请求和回复的报文格式
反措施:在边界路由器或防火墙向你的网络由因特网发来的ICMP块回响请求 20 。你能也设置主机不回答 ICMP响应响请求。
3.2? ICMP 扫描(“PING"扫描)
主机的多重查询使用ICMP响应请求是基于“ICMP扫描”（Ping扫描）的。
“PING”为一小型网络到中继是到这种主机检测的一个可接受的解决方案,但是与大网络(例如A类或完整的B类 )这种检测是相当慢的， 因为在持续到下一个可疑的IP地址指向的IP地址，“PING”需要等待一个回复(或回复到达已经超时)。
Fping 21 是UNI操作系统下能并行发送ICMP响应请求的一种实用程序，这样他比普通的“PING”工具要快很多，它也能其附加的工具 gping 用IP地址封装。gping 用来产生以后被封装进fping的IP地址的一张表或直接产生于从一个文件,施行ICMP扫描。如果使用fping也能解决探查的机器的主机名- d 选择问题。另外一个UNIX工具能在并行方式下进行ICMP扫描，解决探查的机器的主机名,它保存到一个文件且大多是 nmap? 22 ,由 Fyodor 编写。为 Microsoft Windows 操作系统一著名的 ICMP 打扫工具是 Rhino9 23 的 Pinger ,它能做fping 和 nmap所做的这种扫描，并试着解决探测机器以发现攻击者的IP地址在探察到使用了的恶意的计算机,使用指向的网络的权威的 DNS 服务器的记录文件。
下一个例子表明 nmap 的用法施行一 ICMP 对一个C类网络的扫描。我们的实验室包含若干给予 Microsoft Windows 2000 的测试用机器和一些 基于Linux的机器，并且都使用了联网设备将它们联合起来。
-sP 选择指示 nmap 施行“PING”扫描。
- PI 选择指示 nmap 仅发送真实的 ICMP 响应请求。
缺省设置是使用- sP 选择与响应请求固定的ICMP包括 TCP? ACK 主机检测技术的用法。
[root@godfather /root]# nmap -sP -PI 172.18.2.1-254
开始 nmap V. 2.54beta22 ( www.insecure.org/nmap/ ) 主机t (172.18.2.29) appears to be up. hostx30.sys-security.com (172.18.2.30) appears to be up. Host x31.sys-security.com (172.18.2.31) appears to be up. Host x32.sys-security.com (172.18.2.32) appears to be up. Host x34.sys-security.com (172.18.2.34) appears to be up. Host x35.sys-security.com (172.18.2.35) appears to be up. Host x36.sys-security.com (172.18.2.36) appears to be up. Host (172.18.2.38) appears to be up. Host x40.sys-security.com (172.18.2.40) appears to be up. Host x41.sys-security.com (172.18.2.41) appears to be up. ...
Nmap 运行完成 -- 254 IP 地址 (93个主机) 在59秒内完成扫描，如果扫描失败我们只能看到IP地址。如果 nmap成功解决主机的IP，我们就能同时在输出看到主机名和IP地址。如果我们希望避免自动解决，我们应该使用- n 选择。
[root@godfather /root]# nmap -n -sP -PI 172.18.2.1-254
Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ ) Host (172.18.2.29) appears to be up. Host (172.18.2.30) appears to be up. Host (172.18.2.31) appears to be up. Host (172.18.2.32) appears to be up. Host (172.18.2.34) appears to be up. Host (172.18.2.35) appears to be up. Host (172.18.2.36) appears to be up. Host (172.18.2.38) appears to be up. Host (172.18.2.40) appears to be up. Host (172.18.2.41) appears to be up. ...
Nmap运行完毕-- 254 个IP地址( 93个主机)在32秒内扫描完成，我们可以看到这个结果比没有自动解决时快了很多。
ICMP 扫描应该容易被一个侵入检测系统检测( IDS )到是否在常规的方法下发送,或在一个并行方法下使用了。反措施：发来ICMP 回应请求在你的边界路由器或防火墙有因特网发送到你的网络。你也能设置主机不回答 ICMP 响应请求。
?3.3 ICMP广播
向网络上已激活主机的目的映射可以同过一个简单的办法-向整个网络发送ICMP响应请求广播，该请求将在指向的网络上广播到所有的主机。激活的主机将发送一个 ICMP 回响答复到探测的源IP地址(附加条件在此适用)，而恶意的计算机攻击者只能发送仅一个包来实施这种行为。主机检测的这种技术仅仅对一些 UNIX 和类似UNIX的操作系统适用。基于 Microsoft Windows的机器将不产生 ( ICMP 响应答复)到一 ICMP 响应请求，而是对广播地址或在他们所在的网络的网络地址回复。他们被设置为不回答那些询问(这适用于微软所有的操作系统以及 Microsoft Windows NT 4.0 接受的所有的 Microsoft Windows )。如果我们发送一个ICMP响应到一IP地址的请求广播或IP 的反常的行为多点传送时主机可以丢弃IP地址，这在RFC1122 24个状态里不是一种反常行为。
下一个例子表明当发送一个 ICMP响应请求到他们所在的网络的广播地址时，主机所应实施的行为。
这是我们实验室里基于LIUNX的机器的查询回复：
(172.18.2.200, 172.18.2.201),网络设备
(172.18.2.29, 172.18.2.254).? Microsoft Windows 2000和 Microsoft Windows 2000 （SP1补丁）忽略请求：
[root@localhost /root]# ping -b 172.18.2.255 WARNING: pinging broadcast address PING 172.18.2.255 (172.18.2.255) from 172.18.2.201 : 56(84) bytes of data. 64 bytes from 172.18.2.201: icmp_seq=0 ttl=255 time=6.380 msec 64 bytes from 172.18.2.200: icmp_seq=0 ttl=255 time=6.444 msec (DUP!) 64 bytes from 172.18.2.254: icmp_seq=0 ttl=255 time=6.469 msec (DUP!) 64 bytes from 172.18.2.29: icmp_seq=0 ttl=64 time=6.493 msec (DUP!) ...
--- 172.18.2.255 ping statistics --- 5 packets transmitted, 5 packets received, +15 duplicates, 0% packet loss round-trip min/avg/max/mdev = 5.629/5.875/6.493/0.299 ms
在下一个例子里我向一个网络目的地址发送了一个ICMP响应请求，这里我们能看到一个稍微不同的行为的模式被生产。我们使用Linux 机器，当其它联网设备这次没产生一个回复时，Cisco 催化剂 6500 交换机( 172.18.2.254 )回答了我们的询问：
[root@godfather /root]# ping -b 172.18.2.0 WARNING: pinging broadcast address PING 172.18.2.0 (172.18.2.0) from 172.18.2.201 : 56(84) bytes of data.
64 bytes from 172.18.2.201: icmp_seq=0 ttl=255 time=5.755 msec 64 bytes from 172.18.2.200: icmp_seq=0 ttl=255 time=6.034 msec (DUP!) 64 bytes from 172.18.2.254: icmp_seq=0 ttl=255 time=6.286 msec (DUP!) ...
--- 172.18.2.0 ping statistics --- 3 packets transmitted, 3 packets received, +6 duplicates, 0% packet loss round-trip min/avg/max/mdev = 4.395/5.185/6.286/0.648 ms
?
当低于列表10时一个相当精确的操作系统列表针对他们自己的网络（或广播）可能会回复一个ICMP响应请求，但是究竟是哪个操作系统可以回复那个已瞄准的网络所发的ICMP响应请求呢？
反措施: IP 指导的块在你的边界路由器上广播。你也能设置主机不回答他们的网络的广播地址瞄准了的 ICMP 响应请求。

???????????????????????????????????????

?

?

?