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:22:42 -0500
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/
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)