Prudence avec nmap -T5
J’utilise nmap depuis plusieurs années et depuis le début j’ai toujours utilisé le paramettre -T5. Cette option permet, entre autre, de régler la vitesse du scanning de services, c’est utile si vous ne voulez pas attirer l’attention ou si à l’inverse vous voulez terminer un scan le plus rapidement possible.
Au boulot, je sais où se trouve les IDS et lorsque la voie est libre je vais pas hésiter à utiliser -T5 (la valeur 5 représente le niveau le plus élevé d’agressivité/vitesse lors du scan)
L’autre jour, j’utilisais nmap pour scanner quelque services de l’autre coté d’un tunnel afin de vérifier qu’ils étaient joignables. J’ai eu ceci comme résultat :
[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
Pas grand chose d’interessant à raconter la dessus. On constate qu’une machine est joigable sur le port tcp/443 et que l’autre machine semble ne pas répondre sur le port tcp/3299. Pas de soucis, j’écrits à l’équipe en charge de gérer les règles de firewall présent à l’autre bout du tunnel VPN, pour leur demander d’authoriser le port. Seulement voila, de leur coté ils me répondent que tout est déjà bien validé et que si il y a une erreure elle est surement de mon coté.
Je fais une capture sur le firewall ASA de mon coté qui monte le tunnel VPN. Je veux juste vérifier que les paquets à destination de 10.16.68.164 entrent bien dans le tunnel VPN. Je ne m’attend pas à voir autre chose que des paquets SYN sans réponse mais…
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
Ben voila la journée s’anime, non seulement le serveur 10.16.68.164 renvoie bien un ack, mais en plus mon nmap semble le voir puisqu’il envoie un Reset 1ms après…
Pour confirmer mes observations je lance tcpdump sur la machine depuis laquelle je lance mes scans nmap et je me retrouve avec les même résultat que sur la capture ASA. Pas de doute, le ‘ACK’ arrive bien sur la machine de scan.
Mais pourquoi nmap indiquerait un port “filtered” alors qu’il a bien reçu le ‘ACK’ prouvant le contraire ?
En bidouillant un peu les paramètres, j’ai fini par effectuer un nmap avec -T4 à la place de -T5 et euh…
[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 ~]$
Bon, ça suffit, c’est l’heure d’aller faire un tour dans la doc nmap. Apparement, une des raisons pour lesquelles est si rapide pur scanner lorsque l’option -T5 est utilisé est que n
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