firewalk meets nmap - TTL

From: Fyodor <fyodor () insecure org>Date: Sat, 4 Nov 2000 19:57:11 -0800 (PST)

On Thu, 2 Nov 2000, Lance Spitzner wrote:

firewalk meets nmap

Yeah, I enthusiastically agree that Nmap could benefit from sometraceroute-like exploration via TTL manipulation. That is one of thereasons I added a '<traceroute type="udp" port="41702">' section to theexample XML output I sent last August (http://lists.insecure.org/nmap-hackers/2000/Jul-Sep/0039.html ).

Now there are a couple obvious advantages to adding this traceroutefunctionality:

1) Traceroute output is deeply useful in mapping a network to determineits basic setup/architecture. Most people do traceroute anyway, and Nmapcould do it faster and in a more flexible fashion that has a higher chanceof getting through.

2) The XML output with traceroute would allow a smart frontend to draw anetwork graph representing the connections between networks as well asdifferent icons based on the machine type (a la Cheops). Or even aBallista-style Network fly-through :).

As Lance mentioned, the more subtle advantage lies in the use of TTL todeduce filtering characteristics. I consider this particularly importantin the case of UDP, where Nmap has trouble differentiating between portsthat are not responding because they are open and those that are notresponding because they are filtered. For example, lets scan some random@Home machine:

amy~# nmap -O -sUS 24.176.215.14Starting nmap V. 2.54BETA7 ( www.insecure.org/nmap/ )Interesting ports on c206945-a.sfmissn1.sfba.home.com (24.176.215.14):(The 3096 ports scanned but not shown below are in state: closed)Port State Service137/tcp filtered netbios-ns 137/udp open netbios-ns 138/tcp filtered netbios-dgm 138/udp open netbios-dgm 139/tcp filtered netbios-ssn 139/udp open netbios-ssn 520/udp open route 641/tcp open unknown 653/tcp open unknown 1080/tcp filtered socks

TCP Sequence Prediction: Class=trivial time dependency Difficulty=7 (Trivial joke)Remote operating system guess: Windows NT4 / Win95 / Win98

As you can see, @Home is apparently filtering some of the TCP ports. Butwhat about those 6 "open" UDP ports? Are they really open, or do theyjust appear open because @Home is silently dropping the packets?

Things really hit the fan when ISP's drop 31337/udp . I get panickedmails every week saying "ACK!!! Nmap says I am infected with BackOrifice!".

One solution would be to send application-specific probes to eachnon-responsive UDP port to elicit a response (eg Netbios queries to 139,SNMP queries to 161, etc). But coding this would be a huge effort, andit wouldn't work against services that require authentication info beforethey will respond.

Another approach is to play TTL games. As Lance noted, some (but notall) firewalls may apply the filtering rules to drop packets before theydecrement the TTL and apply the time exceeded test. This makes it easy todetermine filtering rules, since time exceeded messages are only returnedby the firewall for allowed ports.

In a similar vein, medium and large sized networks may apply the filtersseveral hops before the final destination machine. So a traceroute toUDP/137 may stop several hops before a traceroute to UDP/45000 . Thislikely means that 137 is filtered. This technique does not require thefiltering order in the approach above, but it does require that the filterallows outbound TTL exceeded messages.

So the change I was considering adding to Nmap would take the @Homeresults given above and:

1) Send traceroute probes to the "open" UDP ports ( 137,138,139,520,641,653) to determine the highest TTL that results in a time exceeded response.

2) Do the same to a known-closed UDP port (for example, port udp/1 in the above is "closed" even though it isn't shown because it is one of the 3096 Nmap omitted from output).

3) In the cases where the MAX TTL from a #1 port is less than that from step #2, that port can be marked filtered. Otherwise, we have to leave it as "open" (even though it is still possibly filtered).

So now, lets try this against the machine above to see if we can determinewhether 137/udp is open or filtered:

First we do a traceroute against 137/udp:

amy# hping -I eth0:0 -t 1 -2 -V -p 137 --traceroute24.176.215.14using eth0:0, addr: 208.184.74.98, MTU: 1500HPING 24.176.215.14 (eth0:0 24.176.215.14): udp mode set, 28 headers + 0 data bytes1->TTL 0 during transit from 208.184.74.97 (opium.lnxnet.net)2->TTL 0 during transit from 216.200.177.1 (sdsl-216-200-177-1.dsl.sjc.megapath.net)3->TTL 0 during transit from 209.249.140.3 (main4-209-249-140.sjc.above.net)

4->TTL 0 during transit from 208.184.102.193 (core5-main4-oc3-2.sjc.above.net)5->TTL 0 during transit from 208.184.102.206 (core3-core5-oc48.sjc2.above.net)6->TTL 0 during transit from 208.185.175.134 (athome-above.sjc2.above.net)7->TTL 0 during transit from 24.7.75.178 (bb3-pos3-1.rdc1.sfba.home.net)8->TTL 0 during transit from 10.0.254.243 (unknown host name)9->TTL 0 during transit from 10.84.17.10 (unknown host name)10->TTL 0 during transit from 24.9.239.185 (ubr1.sfmissn1.sfba.home.net)

So we saw up to 10 hops to port 137. Note the 10.* reservedinternal addresses. Way to go @Home! :).

Now lets try against a known-closed port (I'll use 1):

amy~# hping -I eth0:0 -t 1 -2 -V -p 1 --traceroute 24.176.215.14using eth0:0, addr: 208.184.74.98, MTU: 1500HPING 24.176.215.14 (eth0:0 24.176.215.14): udp mode set, 28 headers + 0 data bytes1->TTL 0 during transit from 208.184.74.97 (opium.lnxnet.net)2->TTL 0 during transit from 216.200.177.1 (sdsl-216-200-177-1.dsl.sjc.megapath.net)3->TTL 0 during transit from 209.249.140.3 (main4-209-249-140.sjc.above.net)4->TTL 0 during transit from 208.184.102.193 (core5-main4-oc3-2.sjc.above.net)5->TTL 0 during transit from 208.184.102.206 (core3-core5-oc48.sjc2.above.net)6->TTL 0 during transit from 208.185.175.134 (athome-above.sjc2.above.net)7->TTL 0 during transit from 24.7.75.178 (bb3-pos3-1.rdc1.sfba.home.net)8->TTL 0 during transit from 10.0.254.243 (unknown host name)9->TTL 0 during transit from 10.84.17.10 (unknown host name)10->TTL 0 during transit from 24.9.239.185 (ubr1.sfmissn1.sfba.home.net)ICMP Port Unreachable from 24.176.215.14 (c206945-a.sfmissn1.sfba.home.com)

So here again we have a maximum of 10 hops. D'oh! This does not give usenough evidence to conclude that filtering is in place (even though I am99% sure it is). For networks "vulnerable" to this type of filteringdetection, that second traceroute would show more hops than the first onebefore the port unreachables started.

But even though they aren't 100% effective (as demonstrated above), theTTL tricks are probably worth adding. I may get to them at some point. But the best way to lobby for their inclusion is to send me a patch :).

By the way, Nmap currently uses a random (per execution) TTL valuesthat various between 37 and 64 or so.

Cheers,Fyodor

--------------------------------------------------For help using this (nmap-hackers) mailing list, send a blank email to nmap-hackers-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).