网络4——网络层 下

1、因特网的路由选择协议

2、ICMP协议

什么是ICMP协议
    ICMP是“Internet Control Message Protocol”（Internet控制消息协议）的缩写。它是TCP/IP协议族的一个子协议，用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。
　　我们在网络中经常会使用到ICMP协议，只不过我们觉察不到而已。比如我们经常使用的用于检查网络通不通的Ping命令，这个“Ping”的过程实际上就是ICMP协议工作的过程。还有其他的网络命令如跟踪路由的Tracert命令也是基于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风暴”，使得目标主机耗费大量的CPU资源处理，疲于奔命。

    对于“Ping of Death”攻击，可以采取两种方法进行防范：第一种方法是在路由器上对ICMP数据包进行带宽限制，将ICMP占用的带宽控制在一定的范围内，这样即使有ICMP攻击，它所占用的带宽也是非常有限的，对整个网络的影响非常少；第二种方法就是在主机上设置ICMP数据包的处理规则，最好是设定拒绝所有的ICMP数据包。

　　设置ICMP数据包处理规则的方法也有两种，一种是在操作系统上设置包过滤，另一种是在主机上安装防火墙。

ICMP协议中的TTL

第一个问题，为什么要有生存周期这个概念?
　　很显然，一个package从一台机器到另一台机器中间需要经过很长的路径，显然这个路径不是单一的，是很复杂的，并且很可能存在环路。如果一个数据包在传输过程中进入了环路，如果不终止它的话，它会一直循环下去，如果很多个数据包都这样循环的话，那对于网络来说这就是灾难了。所以需要在包中设置这样一个值，包在每经过一个节点，将这个值减1，反复这样操作，最终可能造成2个结果：包在这个值还为正数的时候到达了目的地，或者是在经过一定数量的节点后，这个值减为了0。前者代表完成了一次正常的传输，后者代表包可能选择了一条非常长的路径甚至是进入了环路，这显然不是我们期望的，所以在这个值为0的时候，网络设备将不会再传递这个包而是直接将他抛弃，并发送一个通知给包的源地址，说这个包已死。
　　其实TTL值这个东西本身并代表不了什么，对于使用者来说，关心的问题应该是包是否到达了目的地而不是经过了几个节点后到达。但是TTL值还是可以得到有意思的信息的。
　　每个操作系统对TTL值得定义都不同，这个值甚至可以通过修改某些系统的网络参数来修改，例如Win2000默认为128，通过注册表也可以修改。而Linux大多定义为64。不过一般来说，很少有人会去修改自己机器的这个值的，这就给了我们机会可以通过ping的回显TTL来大体判断一台机器是什么操作系统。
　　以我公司2台机器为例
　　看如下命令
　　D:Documents and Settingshx>ping 61.152.93.131
　　Pinging 61.152.93.131 with 32 bytes of data:
　　Reply from 61.152.93.131: bytes=32 time=21ms TTL=118
　　Reply from 61.152.93.131: bytes=32 time=19ms TTL=118
　　Reply from 61.152.93.131: bytes=32 time=18ms TTL=118
　　Reply from 61.152.93.131: bytes=32 time=22ms TTL=118
　　Ping statistics for 61.152.93.131:
　　Packets: Sent = 4， Received = 4， Lost = 0 (0% loss
　　Approximate round trip times in milli-seconds:
　　Minimum = 18ms， Maximum = 22ms， Average = 20ms

　　D:Documents and Settingshx>ping 61.152.104.40
　　Pinging 61.152.104.40 with 32 bytes of data:
　　Reply from 61.152.104.40: bytes=32 time=28ms TTL=54
　　Reply from 61.152.104.40: bytes=32 time=18ms TTL=54
　　Reply from 61.152.104.40: bytes=32 time=18ms TTL=54
　　Reply from 61.152.104.40: bytes=32 time=13ms TTL=54
　　Ping statistics for 61.152.104.40:
　　Packets: Sent = 4， Received = 4， Lost = 0 (0% loss
　　Approximate round trip times in milli-seconds:
　　Minimum = 13ms， Maximum = 28ms， Average = 19ms

　　第一台TTL为118，则基本可以判断这是一台Windows机器，从我的机器到这台机器经过了10个节点，因为128-118=10。而第二台应该是台Linux，理由一样64-54=10。
　　了解了上面的东西，可能有人会有一些疑问，例如以下：
　　1，不是说包可能走很多路径吗，为什么我看到的4个包TTL都是一样的，没有出现不同？
　　这是由于包经过的路径是经过了一些最优选择算法来定下来的，在网络拓扑稳定一段时间后，包的路由路径也会相对稳定在一个最短路径上。具体怎么算出来的要去研究路由算法了，不在讨论之列。
　　2，对于上面例子第二台机器，为什么不认为它是经过了74个节点的Windows机器？因为128-74=54。
　　对于这个问题，我们要引入另外一个很好的ICMP协议工具。不过首先要声明的是，一个包经过74个节点这个有些恐怖，这样的路径还是不用为好。
　　要介绍的这个工具是tracert（*nix下为traceroute），让我们来看对上面的第二台机器用这个命令的结果
　　D:Documents and Settingshx>tracert 61.152.104.40
　　Tracing route to 61.152.104.40 over a maximum of 30 hops
　　1 13 ms 16 ms 9 ms 10.120.32.1
　　2 9 ms 9 ms 11 ms 219.233.244.105
　　3 12 ms 10 ms 10 ms 219.233.238.173
　　4 15 ms 15 ms 17 ms 219.233.238.13
　　5 14 ms 19 ms 19 ms 202.96.222.73
　　6 14 ms 17 ms 13 ms 202.96.222.121
　　7 14 ms 15 ms 14 ms 61.152.81.86
　　8 15 ms 14 ms 13 ms 61.152.87.162
　　9 16 ms 16 ms 28 ms 61.152.99.26
　　10 12 ms 13 ms 18 ms 61.152.99.94
　　11 14 ms 18 ms 16 ms 61.152.104.40
　　Trace complete.

　　从这个命令的结果能够看到从我的机器到服务器所走的路由，确实是11个节点（上面说10个好像是我犯了忘了算0的错误了，应该是64-54+1，嘿嘿），而不是128的TTL经过了70多个节点。
　　既然已经说到这里了，不妨顺便说说关于这两个ICMP命令的高级一点的东西。
　　首先是ping命令，其实ping有这样一个参数，可以无视操作系统默认TTL值而使用自己定义的值来发送ICMP Request包。
　　例如还是用那台Linux机器，用以下命令：
　　D:Documents and Settingshx>ping 61.152.104.40 -i 11
　　Pinging 61.152.104.40 with 32 bytes of data:
　　Reply from 61.152.104.40: bytes=32 time=10ms TTL=54
　　Reply from 61.152.104.40: bytes=32 time=13ms TTL=54
　　Reply from 61.152.104.40: bytes=32 time=10ms TTL=54
　　Reply from 61.152.104.40: bytes=32 time=13ms TTL=54
　　Ping statistics for 61.152.104.40:
　　Packets: Sent = 4， Received = 4， Lost = 0 (0% loss)，
　　Approximate round trip times in milli-seconds:
　　Minimum = 10ms， Maximum = 13ms， Average = 11ms
　　D:Documents and Settingshx>
　　这个命令我们定义了发包的TTL为11，而前面我们知道，我到这台服务器是要经过11个节点的，所以这个输出和以前没什么不同。现在再用这个试试看：
　　D:Documents and Settingshx>ping 61.152.104.40 -i 10
　　Pinging 61.152.104.40 with 32 bytes of data:
　　Reply from 61.152.99.94: TTL expired in transit.
　　Reply from 61.152.99.94: TTL expired in transit.
　　Reply from 61.152.99.94: TTL expired in transit.
　　Reply from 61.152.99.94: TTL expired in transit.
　　Ping statistics for 61.152.104.40:
　　Packets: Sent = 4， Received = 4， Lost = 0 (0% loss)，
　　Approximate round trip times in milli-seconds:
　　Minimum = 0ms， Maximum = 0ms， Average = 0ms
　　D:Documents and Settingshx>

　　可以看到，结果不一样了，我定义了TTL为10来发包，结果是TTL expired in transit.就是说在到达服务器之前这个包的生命周期就结束了。注意看这句话前面的ip，这个ip恰好是我们前面tracert结果到服务器之前的最后1个ip，包的TTL就是在这里减少到0了，根据我们前面的讨论，当TTL减为0时设备会丢弃包并发送一TTL过期的ICMP反馈给源地址，这里的结果就是最好的证明。
　　通过这里再次又证明了从我机器到服务器是经过了11个节点而不是70多个，呵呵。
　　最后再巩固一下知识，有人可能觉得tracer这个命令很神奇，可以发现一个包所经过的路由路径。其实这个命令的原理就在我们上面的讨论中。
　　想象一下，如果我给目的服务器发送一个TTL为1的包，结果会怎样？
　　根据前面的讨论，在包港出发的第一个节点，TTL就会减少为0，这时这个节点就会回应TTL失效的反馈，这个回应包含了设备本身的ip地址，这样我们就得到了路由路径的第一个节点的地址。
　　因此，我们继续发送TTL=2的包，也就受到第二个节点的TTL失效回应
　　依次类推，我们一个一个的发现，当最终返回的结果不是TTL失效而是ICMP Response的时候，我们的tracert也就结束了，就是这么简单。
　　顺便补一句ping命令还有个-n的参数指定要发包的数量，指定了这个数字就会按照你的要求来发包了而不是默认的4个包。如果使用-t参数的话，命令会一直发包直到你强行中止它。