Nmap Development mailing list archives
Re: nmap doesn't allow tracing of blocked ports
From: Daniel Miller <bonsaiviking () gmail com>
Date: Mon, 25 Sep 2017 15:12:24 -0500
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/
Current thread:
- nmap doesn't allow tracing of blocked ports Neil Mayhew (Sep 25)
- Re: nmap doesn't allow tracing of blocked ports Daniel Miller (Sep 25)
- Re: nmap doesn't allow tracing of blocked ports Daniel Miller (Sep 25)
- Re: nmap doesn't allow tracing of blocked ports Daniel Miller (Sep 25)