"tcpwrapped" false positives

[nnposter () users sourceforge net]

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 an old post [1] 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.

[1] http://seclists.org/nmap-dev/2013/q3/574

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:

1. Defines TCPWRAPPED_TIMEOUT=2000. Connections closed after this
timeout expires are not considered "tcpwrapped".

2. Implements new method ServiceNFO::probe_timemsused(), which
returns how long the probe connection lasted. The method is a logical
complement of existing sibling probe_timemsleft(). This old method
has been reimplemented as well to avoid code duplication.

3. Adds check probe_timemsused() < TCPWRAPPED_TIMEOUT in two locations.

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.


Cheers,
nnposter



Patch against r33886 attached.

Attachment: service-false-tcpwrapped.patch
Description:

_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/