Beware of nmap -T5

I have been using nmap for a very long time and almost since the beginning I have been using the -T5 paramater. In a nutshell this option allows you to set the speed of nmap scanning, it is useful if you do not want to draw attention or if you just don’t care and want the scan to be finished asap.

Since most of the time I know there is no IDS in the way, I choose to use the -T5 (5 is for “insane”, it is the most agressive and quickest scan).

The other day, I was just scanning servers to test if some of their services were reachable at the other end of a VPN tunnel when I ended up on this :

[fabien@SADMIN ~]$ nmap -Pn -T5 -n -p 3299 10.16.68.164
Starting Nmap 7.70 ( https://nmap.org ) at 2023-01-27 22:39 PKT
Nmap scan report for 10.16.68.164
Host is up.

PORT     STATE    SERVICE
3299/tcp filtered saprouter

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

[fabien@SADMIN ~]$ nmap -Pn -T5 -p 443 192.168.16.63
Starting Nmap 7.70 ( https://nmap.org ) at 2023-01-27 22:40 PKT
Nmap scan report for 192.168.16.63
Host is up (0.13s latency).

PORT    STATE SERVICE
443/tcp open  https

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

Not very much to say, one machine is reachable on tcp/443 port and the other appears to drop tcp/3299 packets. No big deal, I wrote to the team in charge of the firewall at the other side of the VPN tunnel asking them to whitelist this IP address and this port. They replied that their firewalls did not block that traffic and that something must be wrong on my side.

I started to investigate and did a capture on the closest node I had before entering the VPN tunnel which happen to be the ASA where the tunnel is mounted on my side. I was expecting to see only the SYN packet from the nmap attempt and nothing else but…

PK-KHI01-FWA001/INTERNET/pri/act# show capture sap

6 packets captured

   1: 01:33:00.590759       802.1Q vlan#3211 P0 10.32.11.50.33710 > 10.16.68.164.3299: S
   2: 01:33:00.841219       802.1Q vlan#3211 P0 10.32.11.50.33712 > 10.16.68.164.3299: S
   3: 01:33:00.874756       802.1Q vlan#3211 P0 10.16.68.164.3299 > 10.32.11.50.33710: S ack
   4: 01:33:00.875092       802.1Q vlan#3211 P0 10.32.11.50.33710 > 10.16.68.164.3299: R
   5: 01:33:01.125786       802.1Q vlan#3211 P0 10.16.68.164.3299 > 10.32.11.50.33712: S ack
   6: 01:33:01.125985       802.1Q vlan#3211 P0 10.32.11.50.33712 > 10.16.68.164.3299: R
6 packets shown

Now that is this interesting, there is definitly an ‘ACK’ from the server and worst of all it appears nmap saw it because it sent a reset right after. And all of that happened twice !

I immediatly ran a tcpdump on the machine where I used nmap and the result were the same as the ASA capture. Why would nmap says the port is filtered when it received the ack of the TCP 3-ways handshake ?

As I was trying different parametters values, I ended up changing -T5 for -T4 and…

[fabien@SADMINP ~]$ nmap -Pn -T4 -n -p 3299 10.16.68.164
Starting Nmap 7.70 ( https://nmap.org ) at 2023-01-27 22:40 PKT
Nmap scan report for 10.16.68.164
Host is up (0.29s latency).

PORT     STATE SERVICE
3299/tcp open  saprouter

Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds
[fabien@KARSADMINP02 ~]$

Ok… It was definitly the time to check nmap documentation. Turns out that one of the reasons -T5 is so quick to scan is because it will not wait as long as other Timing Template before moving to the next service/host to scan. And if the host did not send ‘ack’ before that timer expire then nmap will assume that the host service is not willing to reply (even though the ‘ack’ is received right after).

Have a look at the table below (from https://nmap.org/book/performance-timing-templates.html)

You can see that a scan of a TCP port will timeout if the iRTT (time it takes to send a SYN plus receiving the ‘ACK’) if higher than 250 ms.

That is why my nmap scan did not work with -T5, there is too much lag with the server to allow the iRTT to be under 250 ms.

If you look again at the ASA capture we can calculate the iRTT

(timestamp for packet 3 - timestamp for packet 1) = 283 ms.

But it is not to much for -T4 as the timeout is 500 ms for ‘Agressive’ scan.

More information : https://nmap.org/book/man-performance.html