Re: nmap doesn't allow tracing of blocked ports

[Daniel Miller <bonsaiviking () gmail com>]

Neil,

I just remembered another method you can use with Nmap: the firewalk NSE
script [1]. Scan the target with some host discovery option that succeeds
(either the default or some other non-blocked port number with -PS) and put
the blocked port number in the list of ports to scan with -p. You also have
to use the --traceroute option so that the script knows how many hops to
expect. Here's my example using port 445:

nmap -p445 --script firewalk scanme.nmap.org -n --traceroute

Starting Nmap 7.60SVN ( https://nmap.org ) at 2017-09-25 15:17 CDT
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.086s latency).

PORT    STATE    SERVICE
445/tcp filtered microsoft-ds

Host script results:
| firewalk:
| HOP  HOST         PROTOCOL  BLOCKED PORTS
|_1    192.168.1.1  tcp       445

TRACEROUTE (using port 443/tcp)
HOP RTT       ADDRESS
1   5.91 ms   192.168.1.1
2   33.28 ms  10.100.96.1
3   35.49 ms  68.13.10.146
4   36.57 ms  68.13.9.249
5   68.55 ms  68.1.2.109
6   70.43 ms  184.105.41.69
7   106.71 ms 184.105.64.221
8   105.17 ms 184.105.80.182
9   ...
10  120.26 ms 173.230.159.13
11  101.47 ms 45.33.32.156

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

Note that this takes a fair amount of time, since it walks backwards from
the target to find the last responding hop. In this case, it's blaming my
router because it doesn't get any replies for hops past that point. So use
your judgment when interpreting results.

Dan

On Mon, Sep 25, 2017 at 3:12 PM, Daniel Miller <bonsaiviking () gmail com>
wrote:

> Neil,
>
> You may be able to use the Nping tool that is bundled with Nmap. It has a
> traceroute feature, though the output may be a little tricky to read.
> Here's an example run where my ISP is blocking port 445 just beyond my home
> router:
>
> nping --traceroute --tcp -p 445 scanme.nmap.org
>
> Starting Nping 0.7.60SVN ( https://nmap.org/nping ) at 2017-09-25 15:06
> CDT
> SENT (0.1146s) TCP 192.168.1.58:62865 > 45.33.32.156:445 S ttl=1 id=24490
> iplen=40  seq=3547188085 win=1480
> RCVD (0.2978s) ICMP [192.168.1.1 > 192.168.1.58 TTL=0 during transit
> (type=11/code=0) ] IP [ttl=64 id=48565 iplen=68 ]
> SENT (1.1149s) TCP 192.168.1.58:62865 > 45.33.32.156:445 S ttl=3 id=24490
> iplen=40  seq=3547188085 win=1480
> SENT (2.1161s) TCP 192.168.1.58:62865 > 45.33.32.156:445 S ttl=3 id=24490
> iplen=40  seq=3547188085 win=1480
> SENT (3.1174s) TCP 192.168.1.58:62865 > 45.33.32.156:445 S ttl=4 id=24490
> iplen=40  seq=3547188085 win=1480
> SENT (4.1187s) TCP 192.168.1.58:62865 > 45.33.32.156:445 S ttl=5 id=24490
> iplen=40  seq=3547188085 win=1480
>
> You can see that each successive SENT probe has its TTL increased by 1.
> The first one reaches my router (192.168.1.1), times out, and sends back an
> ICMP Time Exceeded message. The second one reaches the first ISP hop, which
> drops it without responding. Subsequent tries are also dropped, so the
> problem hop is the very next one past my router.
>
> You would have to combine this with a successful traceroute to see which
> IP is actually the one dropping the traffic. If some hop is spoofing RST or
> ICMP Admin Prohibited messages, it will set the source address as your
> intended target, even though it comes from a nearer hop. So run a regular
> traceroute to see the expected path, then compare that to what Nping shows.
>
> Dan
>
> On Mon, Sep 25, 2017 at 1:18 PM, Neil Mayhew <neil () neil mayhew name>
> wrote:
>
> > My use-case is public WiFi networks that block port 22. I need to find
> > out where the blocking is occurring so that I can submit an unblocking
> > request to the appropriate administrator.
> >
> > My problem is that nmap's traceroute can't be used with TCP ports that
> > are blocked, because nmap refuses to run a trace to closed ports even when
> > I request it explicitly. For example,
> >
> > $ sudo nmap --traceroute -PS22 -sn gitlab.com
> > ...
> > TRACEROUTE (using port 22/tcp)
> >
> > $ sudo nmap --traceroute -PS2200 -sn gitlab.com
> > ...
> > Note: Host seems down. If it is really up, but blocking our ping probes,
> > try -Pn
> >
> > $ sudo nmap --traceroute -PS2200 -sn -Pn gitlab.com
> > ...
> > TRACEROUTE (using proto 1/icmp)
> >
> > This is a catch-22 situation: the port is closed because it's being
> > blocked but I then can't run a TCP traceroute to it to find out where.
> >
> > I can of course use the regular traceroute utility but I need to have the
> > local WiFi administrator run the test before he'll talk to people upstream,
> > and he's a Windows user. nmap is the friendliest option for a Windows user,
> > and I think it should be able to do what the regular Linux traceroute can
> > do. [tracetcp][1] is a TCP traceroute specially for Windows, but it's
> > obscure compared with nmap, and administrators are understandably cautious
> > about installing random utilities suggested by someone they don't know.
> >
> > [1]: http://simulatedsimian.github.io/tracetcp.html
> >
> > _______________________________________________
> > Sent through the dev mailing list
> > https://nmap.org/mailman/listinfo/dev
> > Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/