Playing and Learning ICMP in Action

Published on Mar 15, 2014

ICMP协议是IP协议的一部分,虽然它的包被封装在IP包内,好像是IP上层的协议,但它确实是IP协议不可分割的一部分。ICMP协议非常复杂,它用来提供有关网络的消息。

ICMP通常被用来侦查网络。各种ICMP报文甚至可能绕过防火墙探查内网,探测访问控制列表等。

ICMP有时也会被利用来做路由重定向和DDOS等其它用途。

ping和traceroute

ping可以用来判断一个ip地址(当提供域名时一般会解析成ip)对应的机器是否在线。

traceroute则为了探测一个包到目的地所经过的路由。

=ping=利用了=ICMP echo request=和=ICMP echo reply=。而=traceroute=则利用了=ICMP time-exceeded error message=。

我们可以先=ping=和=traceroute=来实际看下,

 ~ ⮀ ping -c 1 baidu.com
PING baidu.com (220.181.111.86) 56(84) bytes of data.
64 bytes from 220.181.111.86: icmp_seq=1 ttl=50 time=2.07 ms

--- baidu.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.070/2.070/2.070/0.000 ms

 ~ ⮀ sudo tcpdump -X "icmp" 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:16:47.917236 IP 10.210.96.200 > 220.181.111.86: ICMP echo request, id 9095, seq 1, length 64
18:16:47.919293 IP 220.181.111.86 > 10.210.96.200: ICMP echo reply, id 9095, seq 1, length 64

如果用=wireshark=就能看得更加清楚了,懒得截图。

我们接着看看traceroute是什么样的。

 ~ ⮀ traceroute bbs.byr.cn
traceroute to bbs.byr.cn (10.3.18.66), 30 hops max, 60 byte packets
 1  10.210.96.193 (10.210.96.193)  3.360 ms  3.637 ms  3.919 ms
 2  10.2.100.1 (10.2.100.1)  1.511 ms  1.657 ms  1.825 ms
 3  10.2.1.1 (10.2.1.1)  1.834 ms  2.422 ms  2.809 ms
 4  10.0.10.1 (10.0.10.1)  0.512 ms  0.524 ms  0.531 ms
 5  10.0.13.2 (10.0.13.2)  1.719 ms  2.021 ms  2.139 ms
 6  10.3.18.66 (10.3.18.66)  0.946 ms  0.493 ms  0.483 ms

 ~ ⮀ sudo tcpdump -i eth0 "not udp and not arp"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
23:36:21.471441 IP 10.2.100.1 > 10.210.96.200: ICMP time exceeded in-transit, length 68
23:36:21.471566 IP 10.2.100.1 > 10.210.96.200: ICMP time exceeded in-transit, length 68
23:36:21.472026 IP 10.0.10.1 > 10.210.96.200: ICMP time exceeded in-transit, length 36
23:36:21.472089 IP 10.0.10.1 > 10.210.96.200: ICMP time exceeded in-transit, length 36
23:36:21.472106 IP 10.0.10.1 > 10.210.96.200: ICMP time exceeded in-transit, length 36
23:36:21.472113 IP 10.2.100.1 > 10.210.96.200: ICMP time exceeded in-transit, length 68
23:36:21.472120 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 udp port 33449 unreachable, length 68
23:36:21.472207 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 udp port 33450 unreachable, length 68
23:36:21.472218 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 udp port 33451 unreachable, length 68
23:36:21.472227 IP 10.2.1.1 > 10.210.96.200: ICMP time exceeded in-transit, length 36
23:36:21.472536 IP 10.210.96.193 > 10.210.96.200: ICMP time exceeded in-transit, length 68
23:36:21.472756 IP 10.2.1.1 > 10.210.96.200: ICMP time exceeded in-transit, length 36
23:36:21.472765 IP 10.210.96.193 > 10.210.96.200: ICMP time exceeded in-transit, length 68
23:36:21.473175 IP 10.210.96.193 > 10.210.96.200: ICMP time exceeded in-transit, length 68
23:36:21.473192 IP 10.2.1.1 > 10.210.96.200: ICMP time exceeded in-transit, length 36
23:36:21.473196 IP 10.0.13.2 > 10.210.96.200: ICMP time exceeded in-transit, length 68
23:36:21.473442 IP 10.0.13.2 > 10.210.96.200: ICMP time exceeded in-transit, length 68
23:36:21.473603 IP 10.0.13.2 > 10.210.96.200: ICMP time exceeded in-transit, length 68

可以用=wireshark=更详细的检查。

我们接着看看其它东西。

ping扫射和广播ICMP

ping扫射会=ping= 一个网段内所有的主机,判断ip所对应的主机是否在线。速度非常快

先试着一个ping sweep,在LAN下nmap如果不明确禁止,一定会使用arp来ping,所以要看看ICMP如何完成ping就禁用它, 然后抓包。

 ~ ⮀ sudo nmap -sP --disable-arp 10.210.96.0/27

Starting Nmap 6.25 ( http://nmap.org ) at 2014-03-21 19:29 CST
Nmap scan report for 10.210.96.1
Host is up (0.0014s latency).
Nmap scan report for 10.210.96.13
Host is up (0.0023s latency).
Nmap done: 32 IP addresses (2 hosts up) scanned in 1.97 seconds

 ~ ⮀ sudo tcpdump "icmp"
 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
 19:29:07.205871 IP 10.210.96.200 > 10.210.96.1: ICMP echo request, id 15450, seq 0, length 8
 19:29:07.205895 IP 10.210.96.200 > 10.210.96.2: ICMP echo request, id 39828, seq 0, length 8
 19:29:07.205901 IP 10.210.96.200 > 10.210.96.3: ICMP echo request, id 26191, seq 0, length 8
 19:29:07.205907 IP 10.210.96.200 > 10.210.96.4: ICMP echo request, id 27927, seq 0, length 8
 19:29:07.205911 IP 10.210.96.200 > 10.210.96.5: ICMP echo request, id 40326, seq 0, length 8
 19:29:07.205917 IP 10.210.96.200 > 10.210.96.6: ICMP echo request, id 20451, seq 0, length 8
 19:29:07.205923 IP 10.210.96.200 > 10.210.96.7: ICMP echo request, id 54339, seq 0, length 8
 19:29:07.205930 IP 10.210.96.200 > 10.210.96.8: ICMP echo request, id 662, seq 0, length 8
 19:29:07.205934 IP 10.210.96.200 > 10.210.96.9: ICMP echo request, id 44505, seq 0, length 8
 19:29:07.205940 IP 10.210.96.200 > 10.210.96.10: ICMP echo request, id 53250, seq 0, length 8
 19:29:07.207182 IP 10.210.96.1 > 10.210.96.200: ICMP echo reply, id 15450, seq 0, length 8
 19:29:07.207295 IP 10.210.96.200 > 10.210.96.13: ICMP echo request, id 2073, seq 0, length 8
 19:29:07.207305 IP 10.210.96.200 > 10.210.96.14: ICMP echo request, id 4397, seq 0, length 8
 19:29:07.209792 IP 10.210.96.13 > 10.210.96.200: ICMP echo reply, id 2073, seq 0, length 8
 19:29:07.209912 IP 10.210.96.200 > 10.210.96.17: ICMP echo request, id 19920, seq 0, length 8
 19:29:07.209922 IP 10.210.96.200 > 10.210.96.18: ICMP echo request, id 34999, seq 0, length 8
 19:29:07.306658 IP 10.210.96.200 > 10.210.96.21: ICMP echo request, id 29270, seq 0, length 8
 19:29:07.306681 IP 10.210.96.200 > 10.210.96.22: ICMP echo request, id 7671, seq 0, length 8
 19:29:07.306689 IP 10.210.96.200 > 10.210.96.23: ICMP echo request, id 9104, seq 0, length 8
 19:29:07.306696 IP 10.210.96.200 > 10.210.96.24: ICMP echo request, id 81, seq 0, length 8
 19:29:07.306704 IP 10.210.96.200 > 10.210.96.25: ICMP echo request, id 32155, seq 0, length 8
 19:29:07.306712 IP 10.210.96.200 > 10.210.96.26: ICMP echo request, id 63858, seq 0, length 8
 19:29:07.306720 IP 10.210.96.200 > 10.210.96.27: ICMP echo request, id 26777, seq 0, length 8
 19:29:07.306727 IP 10.210.96.200 > 10.210.96.28: ICMP echo request, id 13494, seq 0, length 8
 19:29:07.306733 IP 10.210.96.200 > 10.210.96.29: ICMP echo request, id 44984, seq 0, length 8
 19:29:07.308869 IP 10.210.96.200 > 10.210.96.0: ICMP echo request, id 17227, seq 0, length 8
 19:29:07.310989 IP 10.210.96.200 > 10.210.96.11: ICMP echo request, id 34317, seq 0, length 8
 19:29:07.311005 IP 10.210.96.200 > 10.210.96.12: ICMP echo request, id 61365, seq 0, length 8
 19:29:07.406811 IP 10.210.96.200 > 10.210.96.16: ICMP echo request, id 55350, seq 0, length 8
 19:29:07.406822 IP 10.210.96.200 > 10.210.96.19: ICMP echo request, id 35677, seq 0, length 8
 19:29:07.406828 IP 10.210.96.200 > 10.210.96.20: ICMP echo request, id 65464, seq 0, length 8
 19:29:07.406835 IP 10.210.96.200 > 10.210.96.30: ICMP echo request, id 15331, seq 0, length 8
 19:29:07.406840 IP 10.210.96.200 > 10.210.96.31: ICMP echo request, id 29903, seq 0, length 8
 19:29:07.406864 IP 10.210.96.200 > 10.210.96.15: ICMP echo request, id 9883, seq 0, length 8
 19:29:08.307498 IP 10.210.96.200 > 10.210.96.2: ICMP echo request, id 62949, seq 0, length 8
 19:29:08.307516 IP 10.210.96.200 > 10.210.96.3: ICMP echo request, id 12243, seq 0, length 8
 19:29:08.307524 IP 10.210.96.200 > 10.210.96.4: ICMP echo request, id 31452, seq 0, length 8
 19:29:08.307532 IP 10.210.96.200 > 10.210.96.5: ICMP echo request, id 31537, seq 0, length 8
 19:29:08.307540 IP 10.210.96.200 > 10.210.96.6: ICMP echo request, id 54651, seq 0, length 8
 19:29:08.307549 IP 10.210.96.200 > 10.210.96.7: ICMP echo request, id 50610, seq 0, length 8
 19:29:08.307559 IP 10.210.96.200 > 10.210.96.8: ICMP echo request, id 62664, seq 0, length 8
 19:29:08.307569 IP 10.210.96.200 > 10.210.96.9: ICMP echo request, id 13459, seq 0, length 8
 19:29:08.307578 IP 10.210.96.200 > 10.210.96.10: ICMP echo request, id 62077, seq 0, length 8
 19:29:08.407677 IP 10.210.96.200 > 10.210.96.14: ICMP echo request, id 55829, seq 0, length 8
 19:29:08.407686 IP 10.210.96.200 > 10.210.96.17: ICMP echo request, id 53285, seq 0, length 8
 19:29:08.407691 IP 10.210.96.200 > 10.210.96.18: ICMP echo request, id 21378, seq 0, length 8
 19:29:08.407696 IP 10.210.96.200 > 10.210.96.21: ICMP echo request, id 23904, seq 0, length 8
 19:29:08.407701 IP 10.210.96.200 > 10.210.96.22: ICMP echo request, id 64314, seq 0, length 8
 19:29:08.407707 IP 10.210.96.200 > 10.210.96.23: ICMP echo request, id 27486, seq 0, length 8
 19:29:08.407712 IP 10.210.96.200 > 10.210.96.24: ICMP echo request, id 20894, seq 0, length 8
 19:29:08.407717 IP 10.210.96.200 > 10.210.96.25: ICMP echo request, id 32853, seq 0, length 8
 19:29:08.407722 IP 10.210.96.200 > 10.210.96.26: ICMP echo request, id 45739, seq 0, length 8
 19:29:08.507898 IP 10.210.96.200 > 10.210.96.13: ICMP echo request, id 11633, seq 0, length 8
 19:29:08.507952 IP 10.210.96.200 > 10.210.96.0: ICMP echo request, id 11677, seq 0, length 8
 19:29:08.507991 IP 10.210.96.200 > 10.210.96.15: ICMP echo request, id 42356, seq 0, length 8
 19:29:08.507996 IP 10.210.96.200 > 10.210.96.16: ICMP echo request, id 49147, seq 0, length 8
 19:29:08.508006 IP 10.210.96.200 > 10.210.96.20: ICMP echo request, id 57762, seq 0, length 8
 19:29:08.508014 IP 10.210.96.200 > 10.210.96.27: ICMP echo request, id 10613, seq 0, length 8
 19:29:08.508768 IP 10.210.96.13 > 10.210.96.200: ICMP echo reply, id 11633, seq 0, length 8
 19:29:08.508823 IP 10.210.96.200 > 10.210.96.11: ICMP echo request, id 61920, seq 0, length 8
 19:29:08.508830 IP 10.210.96.200 > 10.210.96.12: ICMP echo request, id 46304, seq 0, length 8
 19:29:08.508835 IP 10.210.96.200 > 10.210.96.19: ICMP echo request, id 49607, seq 0, length 8
 19:29:08.508840 IP 10.210.96.200 > 10.210.96.28: ICMP echo request, id 1352, seq 0, length 8
 19:29:08.508844 IP 10.210.96.200 > 10.210.96.29: ICMP echo request, id 46670, seq 0, length 8
 19:29:08.508860 IP 10.210.96.200 > 10.210.96.30: ICMP echo request, id 53472, seq 0, length 8
 19:29:08.508863 IP 10.210.96.200 > 10.210.96.31: ICMP echo request, id 58278, seq 0, length 8
 19:29:08.508985 IP 10.210.96.200 > 10.210.96.19: ICMP time stamp query id 26454 seq 0, length 20
 19:29:08.511101 IP 10.210.96.200 > 10.210.96.30: ICMP time stamp query id 49439 seq 0, length 20
 19:29:08.511108 IP 10.210.96.200 > 10.210.96.31: ICMP time stamp query id 20408 seq 0, length 20
 19:29:08.511113 IP 10.210.96.200 > 10.210.96.0: ICMP time stamp query id 47435 seq 0, length 20
 19:29:08.511132 IP 10.210.96.200 > 10.210.96.5: ICMP time stamp query id 44739 seq 0, length 20
 19:29:08.511138 IP 10.210.96.200 > 10.210.96.6: ICMP time stamp query id 62544 seq 0, length 20
 19:29:08.511142 IP 10.210.96.200 > 10.210.96.7: ICMP time stamp query id 60818 seq 0, length 20
 19:29:08.511153 IP 10.210.96.200 > 10.210.96.11: ICMP time stamp query id 8734 seq 0, length 20
 19:29:08.511157 IP 10.210.96.200 > 10.210.96.12: ICMP time stamp query id 42535 seq 0, length 20
 19:29:08.608151 IP 10.210.96.200 > 10.210.96.17: ICMP time stamp query id 4191 seq 0, length 20
 19:29:08.608157 IP 10.210.96.200 > 10.210.96.18: ICMP time stamp query id 60313 seq 0, length 20
 19:29:08.608161 IP 10.210.96.200 > 10.210.96.20: ICMP time stamp query id 30447 seq 0, length 20
 19:29:08.608165 IP 10.210.96.200 > 10.210.96.21: ICMP time stamp query id 34293 seq 0, length 20
 19:29:08.608169 IP 10.210.96.200 > 10.210.96.22: ICMP time stamp query id 45789 seq 0, length 20
 19:29:08.608172 IP 10.210.96.200 > 10.210.96.23: ICMP time stamp query id 20615 seq 0, length 20
 19:29:08.608175 IP 10.210.96.200 > 10.210.96.24: ICMP time stamp query id 39416 seq 0, length 20
 19:29:08.608178 IP 10.210.96.200 > 10.210.96.25: ICMP time stamp query id 43274 seq 0, length 20
 19:29:08.610367 IP 10.210.96.200 > 10.210.96.19: ICMP time stamp query id 37423 seq 0, length 20
 19:29:08.610545 IP 10.210.96.200 > 10.210.96.2: ICMP time stamp query id 8441 seq 0, length 20
 19:29:08.610552 IP 10.210.96.200 > 10.210.96.3: ICMP time stamp query id 3578 seq 0, length 20
 19:29:08.610557 IP 10.210.96.200 > 10.210.96.4: ICMP time stamp query id 3637 seq 0, length 20
 19:29:08.610560 IP 10.210.96.200 > 10.210.96.8: ICMP time stamp query id 21670 seq 0, length 20
 19:29:08.610563 IP 10.210.96.200 > 10.210.96.9: ICMP time stamp query id 59923 seq 0, length 20
 19:29:08.610565 IP 10.210.96.200 > 10.210.96.10: ICMP time stamp query id 44321 seq 0, length 20
 19:29:08.612656 IP 10.210.96.200 > 10.210.96.0: ICMP time stamp query id 2542 seq 0, length 20
 19:29:08.612681 IP 10.210.96.200 > 10.210.96.5: ICMP time stamp query id 52004 seq 0, length 20
 19:29:08.612689 IP 10.210.96.200 > 10.210.96.6: ICMP time stamp query id 50499 seq 0, length 20
 19:29:08.612705 IP 10.210.96.200 > 10.210.96.7: ICMP time stamp query id 49428 seq 0, length 20
 19:29:08.612725 IP 10.210.96.200 > 10.210.96.11: ICMP time stamp query id 36 seq 0, length 20
 19:29:08.612732 IP 10.210.96.200 > 10.210.96.12: ICMP time stamp query id 44368 seq 0, length 20
 19:29:08.612745 IP 10.210.96.200 > 10.210.96.30: ICMP time stamp query id 34029 seq 0, length 20
 19:29:08.612750 IP 10.210.96.200 > 10.210.96.31: ICMP time stamp query id 8416 seq 0, length 20
 19:29:08.708321 IP 10.210.96.200 > 10.210.96.17: ICMP time stamp query id 22579 seq 0, length 20
 19:29:08.708327 IP 10.210.96.200 > 10.210.96.18: ICMP time stamp query id 44220 seq 0, length 20
 19:29:08.708331 IP 10.210.96.200 > 10.210.96.20: ICMP time stamp query id 9032 seq 0, length 20
 19:29:08.708343 IP 10.210.96.200 > 10.210.96.21: ICMP time stamp query id 35831 seq 0, length 20
 19:29:08.708347 IP 10.210.96.200 > 10.210.96.22: ICMP time stamp query id 2301 seq 0, length 20
 19:29:08.708350 IP 10.210.96.200 > 10.210.96.23: ICMP time stamp query id 38652 seq 0, length 20
 19:29:08.708353 IP 10.210.96.200 > 10.210.96.24: ICMP time stamp query id 48909 seq 0, length 20
 19:29:08.708356 IP 10.210.96.200 > 10.210.96.25: ICMP time stamp query id 56868 seq 0, length 20
 19:29:08.710492 IP 10.210.96.200 > 10.210.96.26: ICMP time stamp query id 11131 seq 0, length 20
 19:29:08.710505 IP 10.210.96.200 > 10.210.96.27: ICMP time stamp query id 21052 seq 0, length 20
 19:29:08.710515 IP 10.210.96.200 > 10.210.96.28: ICMP time stamp query id 51363 seq 0, length 20
 19:29:08.710518 IP 10.210.96.200 > 10.210.96.29: ICMP time stamp query id 64922 seq 0, length 20
 19:29:08.710521 IP 10.210.96.200 > 10.210.96.14: ICMP time stamp query id 38360 seq 0, length 20
 19:29:08.710527 IP 10.210.96.200 > 10.210.96.16: ICMP time stamp query id 40280 seq 0, length 20
 19:29:08.710531 IP 10.210.96.200 > 10.210.96.15: ICMP time stamp query id 22775 seq 0, length 20
 19:29:08.712621 IP 10.210.96.200 > 10.210.96.2: ICMP time stamp query id 14586 seq 0, length 20
 19:29:08.712632 IP 10.210.96.200 > 10.210.96.3: ICMP time stamp query id 52979 seq 0, length 20
 19:29:08.712639 IP 10.210.96.200 > 10.210.96.4: ICMP time stamp query id 55009 seq 0, length 20
 19:29:08.712646 IP 10.210.96.200 > 10.210.96.8: ICMP time stamp query id 48655 seq 0, length 20
 19:29:08.712652 IP 10.210.96.200 > 10.210.96.9: ICMP time stamp query id 12270 seq 0, length 20
 19:29:08.712657 IP 10.210.96.200 > 10.210.96.10: ICMP time stamp query id 52019 seq 0, length 20
 19:29:08.811539 IP 10.210.96.200 > 10.210.96.14: ICMP time stamp query id 38654 seq 0, length 20
 19:29:08.811554 IP 10.210.96.200 > 10.210.96.15: ICMP time stamp query id 36060 seq 0, length 20
 19:29:08.811559 IP 10.210.96.200 > 10.210.96.16: ICMP time stamp query id 54453 seq 0, length 20
 19:29:08.811564 IP 10.210.96.200 > 10.210.96.26: ICMP time stamp query id 58198 seq 0, length 20
 19:29:08.811569 IP 10.210.96.200 > 10.210.96.27: ICMP time stamp query id 58807 seq 0, length 20
 19:29:08.811574 IP 10.210.96.200 > 10.210.96.28: ICMP time stamp query id 25994 seq 0, length 20
 19:29:08.811578 IP 10.210.96.200 > 10.210.96.29: ICMP time stamp query id 43528 seq 0, length 20

看样子ping扫射时发了一个=ICMP echo request=不过瘾,又发了一次=ICMP time stamp query=。

广播ping也可以试着找出局域网内的机器。但通常windows机器都不会响应,安卓也不会响应地址是广播地址的ICMP echo request。

我们还可以看看广播地址的icmp echo request

如果伪造发送者ip,ping广播地址可以是潜在的DDOS。

 ~ ⮀ ping -b 192.168.1.255
WARNING: pinging broadcast address
PING 192.168.1.255 (192.168.1.255) 56(84) bytes of data.
64 bytes from 192.168.1.102: icmp_seq=1 ttl=64 time=83.8 ms
64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=87.6 ms (DUP!)

额……发现两个iphone。。。

 ~ ⮀ sudo nmap -sS 192.168.1.102

Starting Nmap 6.25 ( http://nmap.org ) at 2014-03-15 14:34 CST
Nmap scan report for localhost (192.168.1.102)
Host is up (0.0040s latency).
Not shown: 999 closed ports
PORT      STATE SERVICE
62078/tcp open  iphone-sync
MAC Address: F1:DD:08:AF:CB:E9 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 41.44 seconds

 ~ ⮀ sudo nmap -sS 192.168.1.107

Starting Nmap 6.25 ( http://nmap.org ) at 2014-03-15 14:37 CST
Nmap scan report for localhost (192.168.1.107)
Host is up (0.0053s latency).
Not shown: 999 closed ports
PORT      STATE SERVICE
62078/tcp open  iphone-sync
MAC Address: 83:48:4C:DD:5B:96 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 42.11 seconds

但安卓就不对广播ICMP request echo响应了。可以参考著名的ICMP Usage in Scanning,很详细的文档,虽然年头早了些。

ICMP Timestamp query

接下来试试timestamp request

 ~ ⮀ sudo nmap -sP -PP --disable-arp-ping bbs.byr.cn

Starting Nmap 6.25 ( http://nmap.org ) at 2014-03-15 14:48 CST
Nmap scan report for bbs.byr.cn (123.127.134.62)
Host is up (0.0044s latency).
Nmap done: 1 IP address (1 host up) scanned in 0.23 seconds

15:02:20.679449 IP 10.109.20.127 > 10.3.18.66: ICMP time stamp query id 6291 seq 0, length 20
15:02:20.682487 IP 10.3.18.66 > 10.109.20.127: ICMP time stamp reply id 6291 seq 0: org 00:00:00.000, recv 07:09:19.107, xmit 07:09:19.107, length 20

不是所有的机器都会响应。

 ~ ⮀ sudo nmap -sP -PP --disable-arp-ping 10.109.20.1

Starting Nmap 6.25 ( http://nmap.org ) at 2014-03-15 15:00 CST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 2.20 seconds


15:00:53.309360 IP 10.109.20.127 > 10.109.20.1: ICMP time stamp query id 48585 seq 0, length 20
15:00:54.310449 IP 10.109.20.127 > 10.109.20.1: ICMP time stamp query id 60795 seq 0, length 20

ICMP address netmask request

这是个已经废弃的东西,现在推荐使用dhcp,不过看学校的一些路由器还是支持的

 ~ ⮀ sudo nmap -sP -PM --disable-arp-ping 10.109.20.1

Starting Nmap 6.25 ( http://nmap.org ) at 2014-03-15 14:59 CST
Nmap scan report for 10.109.20.1
Host is up (0.0025s latency).
MAC Address: 00:00:E0:60:00:00 (Hangzhou H3C Technologies Co.)
Nmap done: 1 IP address (1 host up) scanned in 0.16 seconds


✘ ⮀ ~ ⮀ sudo tcpdump -i wlan0 "icmp"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:59:49.589370 IP 10.109.20.127 > 10.109.20.1: ICMP address mask request, length 12
14:59:49.591828 IP 10.109.20.1 > 10.109.20.127: ICMP address mask is 0xfffffc00, length 12

谁会响应我们的非echo ICMP请求?

  • 监听状态的机器。
  • 实现这个标准的操作系统。
  • 配置为支持这个ICMP请求。
  • 没有被防火墙墙掉。

大多数机器对折中非echo的ICMP请求是没响应的。

~ ⮀ sudo nmap -sP -PM/E/P --disable-arp-ping 10.109.23.255

Starting Nmap 6.25 ( http://nmap.org ) at 2014-03-15 15:07 CST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 2.18 seconds

ICMP Parameter Problem Error messages

让目标机器生成ICMP参数错误消息的方法有:

  • 搞乱IP头:
  • 头长度域
  • IP报文option部分
  • 在IP头中使用无效的域值
  • 在IP头中使用有效的域值
  • 滥用分片
  • UDP扫描主机探测方法。

IP中伪造而不会被无声丢弃的域:

  • ihl
  • option
  • proto尝试不使用的

我们先试试改头长度域的:

我们造个ihl有问题的包(=ihl=的值是32位即一个字的个数):

 ~ ⮀ sudo scapy
Welcome to Scapy (2.2.0)
>>> ip = IP()/ICMP()
>>> ip.dst='10.3.18.66'
>>> ip.ihl=6L
>>> ip.show()
###[ IP ]###
  version= 4
  ihl= 6L
  tos= 0x0
  len= None
  id= 1
  flags= 
  frag= 0
  ttl= 64
  proto= icmp
  chksum= None
  src= 10.210.96.200
  dst= 10.3.18.66
  \options\
###[ ICMP ]###
     type= echo-request
     code= 0
     chksum= None
     id= 0x0
     seq= 0x0
>>> send(ip)
.
Sent 1 packets.

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:45:29.035948 IP 10.210.96.200 > 10.3.18.66: [|icmp]
14:45:29.039536 IP 10.210.96.193 > 10.210.96.200: ICMP parameter problem - octet 21, length 12

为啥会参数错误,因为解析包的程序会把ICMP报文部分当成options处理。

同样,我们往options部分塞些奇奇怪怪的东西也可以完成同样效果。

 ~ ⮀ sudo scapy
Welcome to Scapy (2.2.0)
>>> ip = IP()/ICMP()
>>> ip.dst='10.3.18.66'
>>> ip.show()
###[ IP ]###
  version= 4
  ihl= None
  tos= 0x0
  len= None
  id= 1
  flags= 
  frag= 0
  ttl= 64
  proto= icmp
  chksum= None
  src= 10.210.96.200
  dst= 10.3.18.66
  \options\
   |###[ IPOption ]###
   |  copy_flag= 1
   |  optclass= control
   |  option= extended_security
   |  length= None
   |  value= ''
###[ ICMP ]###
     type= echo-request
     code= 0
     chksum= None
     id= 0x0
     seq= 0x0
>>> ip.options=IPOption(copy_flag=1,optclass=0,option=5,value='')
>>> send(ip)

大快人心的是途中的路由返回的参数错误

 ~ ⮀ sudo tcpdump -i eth0 "icmp"
 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
 15:13:30.787605 IP 10.210.96.200 > 10.3.18.66: ICMP echo request, id 0, seq 0, length 8
 15:13:30.790656 IP 10.0.10.1 > 10.210.96.200: ICMP parameter problem - octet 20, length 40

 ~ ⮀ traceroute 10.3.18.66 
traceroute to 10.3.18.66 (10.3.18.66), 30 hops max, 60 byte packets
 1  10.210.96.193 (10.210.96.193)  2.537 ms  2.798 ms  3.158 ms
 2  10.1.10.1 (10.2.100.1)  1.260 ms  1.423 ms  1.425 ms
 3  10.1.2.1 (10.2.1.1)  0.824 ms  1.197 ms  1.614 ms
 4  10.0.10.1 (10.0.10.1)  0.504 ms  0.534 ms  0.542 ms
 5  10.0.13.2 (10.0.13.2)  4.714 ms  4.895 ms  5.053 ms
 6  10.3.18.66 (10.3.18.66)  0.477 ms  0.428 ms  0.414 ms

在wireshark中可以看的更清楚:

Extended Security (with option length = 2 bytes; should be >= 3)

我们发了一个奇怪的包= =

ICMP Usage in Scanning中详述了使用这些技术探测ACL(访问控制列表)的神奇应用。

接着我们试试奇葩的protocol字段:

>>> ip.proto=155
>>> ip.show()
###[ IP ]###
  version= 4
  ihl= None
  tos= 0x0
  len= None
  id= 1
  flags= 
  frag= 0
  ttl= 64
  proto= 155
  chksum= None
  src= 10.210.96.200
  dst= 10.3.18.231
  \options\
###[ UDP ]###
     sport= domain
     dport= domain
     len= None
     chksum= None
>>> send(ip)
.
Sent 1 packets.

产生了一个destination unreachable(protocol unreachable)的错误报文。

 ~ ⮀ sudo tcpdump -i eth0 "icmp"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:43:14.737608 IP 10.3.18.231 > 10.210.96.200: ICMP 10.3.18.231 protocol 155 unreachable, length 36

该技术可用于主机发现,用nmap也可以结合各种协议来进行ACL的探测。

sudo nmap -sO 10.3.18.66

这是部分抓到的包:

 ~ ⮀ sudo tcpdump "icmp"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:51:15.618473 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 protocol 15 unreachable, length 28
15:51:16.719654 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 protocol 241 unreachable, length 28
15:51:17.820941 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 protocol 176 unreachable, length 28
15:51:18.922155 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 protocol 126 unreachable, length 28
15:51:19.427885 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 protocol 184 unreachable, length 28
15:51:20.434376 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 protocol 45 unreachable, length 28
15:51:21.455654 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 protocol 59 unreachable, length 28
15:51:22.466907 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 protocol 37 unreachable, length 28
15:51:23.478382 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 protocol 233 unreachable, length 28
15:51:24.492506 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 protocol 162 unreachable, length 28
15:51:25.531125 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 protocol 72 unreachable, length 28
15:51:26.452325 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 protocol 255 unreachable, length 28
15:51:27.473618 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 protocol 58 unreachable, length 28
15:51:28.415352 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 protocol 25 unreachable, length 28
15:51:29.435785 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 protocol 169 unreachable, length 28
15:51:30.456992 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 protocol 206 unreachable, length 28
15:51:31.478499 IP 10.3.18.66 > 10.210.96.200: ICMP 10.3.18.66 protocol 28 unreachable, length 28
15:51:31.527789 IP 10.210.96.200 > 10.3.9.4: ICMP 10.210.96.200 udp port 48089 unreachable, length 72
15:51:31.527806 IP 10.210.96.200 > 10.3.9.4: ICMP 10.210.96.200 udp port 55862 unreachable, length 72

ICMP Ip Reassembly Time Exceeded

我们可以故意把发送不完整的IP分片。来探测主机,当对一个网络实行这个伎俩时,就可以探测整个网络拓扑。

>>> ip = IP()/TCP()/"abcdefg"
>>> ip.flags=1
>>> ip.dst='10.3.18.66'
>>> ip.show()
###[ IP ]###
  version= 4
  ihl= None
  tos= 0x0
  len= None
  id= 1
  flags= MF
  frag= 0
  ttl= 64
  proto= tcp
  chksum= None
  src= 10.210.96.200
  dst= 10.3.18.66
  \options\
###[ TCP ]###
     sport= ftp_data
     dport= http
     seq= 0
     ack= 0
     dataofs= None
     reserved= 0
     flags= S
     window= 8192
     chksum= None
     urgptr= 0
     options= {}
###[ Raw ]###
        load= 'abcdefg'
>>> send(ip)
.
Sent 1 packets.

过了好久好久,返回一个重组分片超时IMCP错误

~ ⮀ sudo tcpdump -i eth0 "icmp"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:29:22.186723 IP 10.3.18.66 > 10.210.96.200: ICMP ip reassembly time exceeded, length 52

不是所有主机都会对这个响应。我试了试局域网内有的设备就没反应= =。

但这个端口不需要打开,试试81端口(确认此台机器没有打开81端口)也是直接返回ICMP超时错误。操作系统会直接处理报文并返回错误消息。

我又试了试UDP:

不管你是不是扫描打开的端口,都返回同样的超时错误:

>>> ip[1]=UDP()
>>> ip.show()
###[ IP ]###
  version= 4
  ihl= None
  tos= 0x0
  len= None
  id= 1
  flags= MF
  frag= 0
  ttl= 64
  proto= udp
  chksum= None
  src= 10.210.96.200
  dst= 10.210.96.195
  \options\
###[ UDP ]###
     sport= domain
     dport= domain
     len= None
     chksum= None
>>> ip[1].dport=80
>>> ip.dst
'10.210.96.195'
>>> ip.dst='10.3.18.66'
>>> send(ip)
.
Sent 1 packets.
>>> ip[1].dport=81
>>> send(ip)
.
Sent 1 packets.

 ~ ⮀ sudo tcpdump -i eth0 "host 10.3.18.66"   
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:46:46.455970 IP 10.210.96.200.domain > 10.3.18.66.http: [|domain]
16:47:16.455677 IP 10.3.18.66 > 10.210.96.200: ICMP ip reassembly time exceeded, length 36
16:47:29.237026 IP 10.210.96.200.domain > 10.3.18.66.hosts2-ns: [|domain]
16:47:59.236648 IP 10.3.18.66 > 10.210.96.200: ICMP ip reassembly time exceeded, length 36

这和前文提到的ICMP Usage in Scanning所说的不一样!!!!!

我懒得再试其它机器和封装个ICMP包的例子了。

好吧,还是试了试,一个没反应。一个对开放端口(22)和非开放端口(23)都返回同样值。

>>> ip.dst='10.210.96.210'
>>> send(ip)
.
Sent 1 packets.
>>> ip.dst='10.210.96.195'
>>> ip[1].dport=22
>>> send(ip)
.
Sent 1 packets.
>>> ip[1].dport=23
>>> send(ip)
.
Sent 1 packets.

16:58:25.736005 IP 10.210.96.200.ftp-data > 10.210.96.195.ssh: Flags [S], seq 0, win 8192, length 0
16:58:55.765861 IP 10.210.96.195 > 10.210.96.200: ICMP ip reassembly time exceeded, length 44
16:59:15.097094 IP 10.210.96.200.ftp-data > 10.210.96.195.telnet: Flags [S], seq 0, win 8192, length 0
16:59:45.171689 IP 10.210.96.195 > 10.210.96.200: ICMP ip reassembly time exceeded, length 44

和文档描述的不相同,但只要有ICMP报文返回,说明主机是打开的。(好像没什么用…)

UDP扫描

结合各种协议和端口,探测内网拓扑。

比如,我们可以先用nmap ping 扫射下某网段,然后分别试着尝试协议端口。

>>> ip[1]=UDP()
>>> ip.show()
###[ IP ]###
  version= 4
  ihl= None
  tos= 0x0
  len= None
  id= 1
  flags= 
  frag= 0
  ttl= 64
  proto= udp
  chksum= None
  src= 10.210.96.200
  dst= 10.3.18.66
  \options\
###[ UDP ]###
     sport= domain
     dport= domain
     len= None
     chksum= None
>>> send(ip)
.
Sent 1 packets.

 ~ ⮀ sudo nmap -sP 10.3.18.66/24 
Nmap scan report for 10.3.18.213
Host is up (0.00052s latency).
Nmap scan report for 10.3.18.231
Host is up (0.00052s latency).
Nmap scan report for 10.3.18.232
Host is up (0.00038s latency).

>>> ip.dst='10.3.18.230'
>>> send(ip)
.
Sent 1 packets.
>>> ip.dst='10.3.18.231'
>>> send(ip)
.
Sent 1 packets.

只有=10.3.18.231=这个活着的机器有返回destination unreachable(Port unreachable)报文。

 ~ ⮀ sudo tcpdump -i eth0 "icmp"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:39:12.697553 IP 10.3.18.231 > 10.210.96.200: ICMP 10.3.18.231 udp port domain unreachable, length 36

分片与MTU

我的意思是,恰巧目标网络的MTU比上一跳网络的MTU小,如果我们设置DF标志为1,同时让IP数据包的值介于两者之间,然后倒霉的内网路由器就会发回Fragmentation Needed ICMP报文。

该死的我没找到比我更小的MTU网段了。现在无线网没人用了?

Inverse Mapping

大多数防火墙不过滤ICMP reply。

假设我们的ip是=10.210.96.200=,=10.210.97.195=是存在的。而=10.210.97.196=不在线。

>>> icmp = IP()/ICMP()
>>> icmp.dst='10.210.97.195'
>>> icmp.show()
###[ IP ]###
  version= 4
  ihl= None
  tos= 0x0
  len= None
  id= 1
  flags= 
  frag= 0
  ttl= 64
  proto= icmp
  chksum= None
  src= 10.210.96.200
  dst= 10.210.97.195
  \options\
###[ ICMP ]###
     type= echo-reply
     code= 0
     chksum= None
     id= 0x0
     seq= 0x0
>>> send(icmp)
.
Sent 1 packets.

 ~ ⮀ sudo tcpdump -i eth0 "host 10.210.97.195"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:51:47.187719 IP 10.210.96.200 > 10.210.97.195: ICMP echo reply, id 0, seq 0, length 8
22:51:47.188369 IP 10.210.97.195 > 10.210.96.200: ICMP 10.210.97.195 protocol 1 unreachable, length 36

发现=10.210.97.195=竟然尼码响应了!!!!!!协议不可到达!!

不存在的ip地址则没有响应!这尼码完全和上文提到的ICMP Usage in Scanning说的相反好么!!!

>>> icmp.dst='10.210.97.196'
>>> send(icmp)
.
Sent 1 packets.

~ ⮀ sudo tcpdump -i eth0 "host 10.210.97.196"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:56:15.725836 IP 10.210.96.200 > 10.210.97.196: ICMP echo reply, id 0, seq 0, length 8

不过后来找到个在线的=10.210.97.200=也不响应。

>>> icmp.dst='10.210.97.200'
>>> send(icmp)
.
Sent 1 packets.

 ~ ⮀ sudo tcpdump -i eth0 "host 10.210.97.200"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:59:10.235963 IP 10.210.96.200 > 10.210.97.200: ICMP echo reply, id 0, seq 0, length 8

 ~ ⮀ ping 10.210.97.200
PING 10.210.97.200 (10.210.97.200) 56(84) bytes of data.
64 bytes from 10.210.97.200: icmp_seq=1 ttl=63 time=0.520 ms
64 bytes from 10.210.97.200: icmp_seq=2 ttl=63 time=0.559 ms

丧心病狂,说明路由存在ip就转发了,不存在就默默丢弃了。至于=10.210.97.195=是什么毛病会给我个协议不可达(它可能是个路由器)……=Who can tell me…=

ICMP与操作系统探测

ICMP Usage in Scanning的作者也是xprobe的作者,我不打算继续玩ICMP这项深坑了:

# eix xprobe
* net-analyzer/xprobe
     Available versions:  ~0.3
     Homepage:            http://sys-security.com/blog/xprobe2
     Description:         Active OS fingerprinting tool - this is Xprobe2

ICMP source quench

应该被废弃的(2012年的RFC6633)协议,流量控制应该交给TCP来做。如果要伪造需要猜测TCP序号,端口号等(前八字节)。

我试着发了发包……看样子路由比我的网卡强大太多了。

ICMP 重定向

扔一个参考资料,用hping的How To – Poison Route Cache Using ICMP Redirect

待我哪天土豪了再说吧……最起码现在我的安卓功能受限,总之我没模拟出来啥效果。反正我在一个网段试了试完全没动静。其实我觉得应该现在操作系统都会检查ICMP报文中的IP报头和IP报文数据前八字节吧。那又得猜TCP端口号和序列号了不是?

FIXME:ICMP Tunnel,有空试试。