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

[Kris Katterjohn <katterjohn () gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/04/2010 05:33 PM, David Fifield wrote:
> On Mon, Aug 02, 2010 at 04:24:22AM -0500, Kris Katterjohn wrote:
> > 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.

Thank you!

> 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.

That's a pretty good idea.  path-mtu is all ready capable of prioritizing
which protocols and states to use (for example it currently prefers TCP to
UDP), so that's a start.  It just has to do it separately and hope for the best.

A specific problem I have with using the ping probe is that UDP sends payloads
by default, which can affect the port state.  The problem is that if an open
UDP port happens to be the best ping probe, the script doesn't know what to do
with it because sending the data it currently sends won't (shouldn't) be
enough.  It still might not work if the proper payload is sent with the rest
appended to it, although this will probably vary.

For this reason, the list of probes for path-mtu is ordered tcp/open,
tcp/closed and udp/closed, totally avoiding udp/open (I quickly mention this
in a comment in getprobe() in the script).  I arbitrarily chose the prefer an
open TCP port to a closed, although reading the pingprobe_score() comment I
might rethink this.

Please correct me if I'm mistaken about anything here: I didn't delve too deep.

> 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.
<snip>
> 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

Thanks for testing.

I get replies and the script behaves correctly when I use scanme.  Did you
happen to test against any other host, on a LAN or out on the internet?  What
about using UDP?

> 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

Does Nping still work when you add a bunch of data to the mix?

Using "nping -c 1 --tcp --df -p 22 --data-length 1460 64.13.134.52":

SENT (0.0220s) TCP 192.168.10.6:5116 > 64.13.134.52:22 S ttl=64 id=45459
iplen=1500  seq=3298795002 win=1480
RCVD (0.0250s) ICMP w.x.y.z > 192.168.10.6 Fragmentation required
(type=3/code=4) ttl=29 id=3655 iplen=56

Which is just like I get using path-mtu.nse.  It's from my router who says its
next hop MTU is 1492 (due to PPPoE).

And this is with --data-length 1452 which gets through:

SENT (0.0230s) TCP 192.168.10.6:22175 > 64.13.134.52:22 S ttl=64 id=18525
iplen=1492  seq=1237883334 win=1480
RCVD (0.1440s) TCP 64.13.134.52:22 > 192.168.10.6:22175 SA ttl=44 id=0
iplen=44  seq=2745830071 win=5840 <mss 1452>


I don't think the amount of data is the problem given that path-mtu doesn't
get replies even when testing for low PMTUs, but hopefully mixing up
protocols, distances and data length will narrow it down some.

> David Fifield

Thanks again,
Kris Katterjohn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMWg47AAoJEEQxgFs5kUfuWWsQAMvFYnU3NiYXf6ZPgNOgDjWn
2i+FOUSkNR3mBh9zZyCXfEQ06ZEZJJN7hb3B9cjCo2UcOlQ2kQBlmzqsCrTfdAG/
TOcNQB03HNAfR73EOND4WaKoQ1vlJKiZRektQwJ5p8NvuUjsCFxIBGYSsS8SgU85
FF5xdiO/CewfeeXh2ukFRifcMGwDzb93pxBLBqjg+rZJbUSMvwDDae0UbDEKDoL3
VkVBCwg3sG/+GGO4/yrOITRq3qDE0+NVpW6LG6Z1gypkPTd1TvjcnqFPgEdlmvV7
01BPSPvBWpACHzrmB9+Rnzvp7TKZYwZe6uVis7UZu4uv95z/kaJU/n4BM3YoNw27
V5aVlGr4JCVlFQnpyp6o5KmMVqPq0b5FvALXhjs2hcwrx4wDUrDquXiANEV4b78N
3IH8mdgZVuuOGlLAcghwuyoXhvlwr2q7AmQ7yPlGz4OGYzKjhKvExy8UbcS7SSty
kBTzzN+o+DQZNV5lIrBAp+tIl0onreuIhT2nbZDQ0qnLuqjWHGa95STyJWlq7buS
4Nh+fqadmAhUAQF/yp/0wuKYiHH1q6ArB9XpeExXTsqdC/h+OL97P7U8foDdiMxf
4Uf7AsptuvcJxZfOVDBiGOIKbEAFxrHK7kZ0czHkD2LBaV7X2B5TRNUbXTT+gS3X
tC5rttWMaWbp7HofgU8O
=uJu1
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/