Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
I am regularly observing incorrect "tcpwrapped" results where the targeted service is simply killing the null probe connection before nmap itself does. (Most recently I have noticed it on ArubaOS Management WebUI, which is HTTPS-based and it terminates the connection after 5 seconds.)
Looking for a solution, I came across a year-old post that pinpoints the relevant nmap code and proposes an enhancement but the attached patch seems to be based on incorrect understanding of the nmap data structures.
The patch below follows the same enhancement logic (a service is considered "tcpwrapped" only if the connection is closed quickly) but the implementation is different than the original patch. In a nut shell:
While the patch seems working fine for me I have to admit that I am not very familiar with this area of nmap internals so the patch might not be up to snuff. I would very much appreciate feedback from more versed developers.
I am committing this patch with changes to support the algorithm we discussed, namely preserving the possibility of marking a service