Re: [RFC] path-mtu.nse, host.interface_mtu, etc.

[David Fifield <david () bamsoftware com>]

On Mon, Aug 02, 2010 at 04:24:22AM -0500, Kris Katterjohn wrote:
> Soon after fixing the fragmentation options[1], I started playing around and
> ended up with the attached patch and NSE script.  The script's description
> sums it up pretty well, so here it is:
>
> 'Performs simple Path MTU Discovery to the target host.
>
> TCP or UDP packets are sent to the host with the DF (don't fragment) bit
> set and with varying amounts of data.  If an ICMP Fragmentation Needed
> is received, or no reply is received after retransmissions, the amount
> of data is lowered and another packet is sent.  This continues until
> (assuming no errors occur) a reply from the final host is received,
> indicating the packet reached the host without being fragmented.
>
> Not all MTUs are attempted so as to not expend too much time or network
> resources.  Currently the relatively short list of MTUs to try contains
> the plateau values from Table 7-1 in RFC 1191, "Path MTU Discovery".
> Using these values significantly cuts down the MTU search space.  On top
> of that, this list is rarely traversed in whole because:
>     * the MTU of the outgoing interface is used as a starting point, and
>     * we can jump down the list when an intermediate router sending a
>       "can't fragment" message includes its next hop MTU (as described
>       in RFC 1191 and required by RFC 1812)'
>
>
> So now when Nmap enumerates the available interfaces, it'll also store the MTU
> as retrieved via SIOCGIFMTU or libdnet.
>
> NSE scripts can obtain the MTU value as host.interface_mtu, which corresponds
> to host.interface.  This could be useful for future raw IP scripts, or if
> other link layers are supported like Ethernet currently is.
>
> The MTU is also printed in --iflist output:
>
> DEV  (SHORT) IP/MASK         TYPE        UP MTU   MAC
> lo   (lo)    127.0.0.1/8     loopback    up 33578
> eth0 (eth0)  192.168.10.6/24 ethernet    up 1500  00:0C:76:7D:90:33
> sl0  (sl0)   192.168.1.1/32  point2point up 296
>
>
> I've all ready committed the following related changes which aid the path-mtu
> script (and potentially any future NSE script utilizing raw IP) but also make
> sense otherwise:
>
> [r19378] Sendto() doesn't retry sending if errno is EMSGSIZE: sleeping for a
> few seconds won't shorten the packet.
>
> [r19379] IP packets are no longer fragmented if the DF bit is set, even if
> o.fragscan is set.  If a packet is built to explicitly avoid fragmentation,
> honor it.  No packets currently built in Nmap appear to set this bit.
>
>
> The script and patch contain (IMO) separately useful additions which happen to
> be related and somewhat intertwined, so it makes the most sense submitted
> together.  The patch is pretty simple anyway.
>
> I've tested this on Linux, NetBSD and Windows XP and all seems well.  If there
> are no objections, I'll commit later this week.

This looks really nice. I always have trouble thinking of new ideas for
scripts, but you have these incredibly creative ones.

It would be nice if the discovery could use the best timing ping probe
like traceroute does. The function pingprobe_score defines an ordering
for which probes are "better" than others, and the best probe for each
host is kept updated thoughout port scanning and host discovery. But
this isn't trivial because NSE would have to know how to send all those
specific types, and that information isn't available to NSE currently.

I tested the --iflist output and this is what I saw.

************************INTERFACES************************
DEV  (SHORT) IP/MASK         TYPE     UP MTU   MAC
lo   (lo)    127.0.0.1/8     loopback up 16436
eth0 (eth0)  192.168.0.21/24 ethernet up 1500  00:50:BF:16:11:61

The script isn't working for me with SYN probes. I'm not sure what's
wrong but tcpdump doesn't show any replies.

NSE: Starting path-mtu against 64.13.134.52.
Packet Tracing enabled.
SENT (3.3080s) TCP 192.168.0.21:51543 > 64.13.134.52:22 S ttl=128 id=0 iplen=1500  seq=1714636915 win=3072 <mss 1460>
SENT (6.3140s) TCP 192.168.0.21:59836 > 64.13.134.52:22 S ttl=128 id=0 iplen=1492  seq=424238336 win=3072 <mss 1460>
SENT (9.3090s) TCP 192.168.0.21:59836 > 64.13.134.52:22 S ttl=128 id=0 iplen=1492  seq=424238336 win=3072 <mss 1460>
SENT (12.3140s) TCP 192.168.0.21:22650 > 64.13.134.52:22 S ttl=128 id=0 iplen=1006  seq=1649760492 win=3072 <mss 1460>
SENT (15.3110s) TCP 192.168.0.21:22650 > 64.13.134.52:22 S ttl=128 id=0 iplen=1006  seq=1649760492 win=3072 <mss 1460>
SENT (18.3130s) TCP 192.168.0.21:18944 > 64.13.134.52:22 S ttl=128 id=0 iplen=508  seq=1189641421 win=3072 <mss 1460>
SENT (21.3120s) TCP 192.168.0.21:18944 > 64.13.134.52:22 S ttl=128 id=0 iplen=508  seq=1189641421 win=3072 <mss 1460>
SENT (24.3140s) TCP 192.168.0.21:31822 > 64.13.134.52:22 S ttl=128 id=0 iplen=296  seq=1350490028 win=3072 <mss 1460>
SENT (27.3140s) TCP 192.168.0.21:31822 > 64.13.134.52:22 S ttl=128 id=0 iplen=296  seq=1350490028 win=3072 <mss 1460>
SENT (30.3150s) TCP 192.168.0.21:24557 > 64.13.134.52:22 S ttl=128 id=0 iplen=68  seq=1102520059 win=3072 <mss 1460>
NSE Timing: About 0.00% done
SENT (33.3140s) TCP 192.168.0.21:24557 > 64.13.134.52:22 S ttl=128 id=0 iplen=68  seq=1102520059 win=3072 <mss 1460>
NSE: Finished path-mtu against 64.13.134.52.
Completed NSE at 16:24, 34.38s elapsed
Nmap scan report for scanme.nmap.org (64.13.134.52)
Host is up, received user-set (0.067s latency).
Scanned at 2010-08-04 16:24:07 MDT for 36s
PORT     STATE    SERVICE      REASON
21/tcp   filtered ftp          no-response
22/tcp   open     ssh          syn-ack
23/tcp   filtered telnet       no-response
25/tcp   closed   smtp         reset
80/tcp   open     http         syn-ack
110/tcp  filtered pop3         no-response
139/tcp  filtered netbios-ssn  no-response
443/tcp  filtered https        no-response
445/tcp  filtered microsoft-ds no-response
3389/tcp filtered ms-term-serv no-response

Host script results:
|_path-mtu: Error: Unable to determine PMTU (no replies)
Final times for host: srtt: 66760 rttvar: 28451  to: 180564

The packets that path-mtu are sending look like

16:30:14.594363 IP (tos 0x0, ttl 128, id 0, offset 0, flags [DF], proto TCP (6),
 length 1500)
    192.168.0.21.51543 > 64.13.134.52.22: Flags [S], seq 1714636915:1714638371,
win 3072, options [mss 1460], length 1456

Similar packets sent by Nping get a response.

# nping --tcp -p 22 64.13.134.52 --df
16:32:38.135869 IP (tos 0x0, ttl 64, id 33435, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.0.21.57093 > 64.13.134.52.22: Flags [S], cksum 0x78f4 (correct), seq 2445687109, win 1480, length 0
16:32:38.202608 IP (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    64.13.134.52.22 > 192.168.0.21.57093: Flags [S.], cksum 0x4e5e (correct), seq 33882044, ack 2445687110, win 5840, 
options [mss 1460], length 0
16:32:38.202700 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.0.21.57093 > 64.13.134.52.22: Flags [R], cksum 0x7eb9 (correct), seq 2445687110, win 0, length 0

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/