Re: nmap doesn't allow tracing of blocked ports

[Daniel Miller <bonsaiviking () gmail com>]

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/