"tcpwrapped" false positives about nmap HOT 3 CLOSED

FWIW, these changes did remediate the original false-positives that lead to submitting this issue. Kudos to Dan for coming up with architecturally clean way to address the problem.

from nmap.

This issue deserves more discussion. I replied on the development mailing list here: http://seclists.org/nmap-dev/2015/q1/52

from nmap.

I am committing this patch with changes to support the algorithm we discussed, namely preserving the possibility of marking a service tcpwrapped if it closes the connection within the longer totalwaitms without sending data for every probe attempted. Also, I chose 3000 ms as the default timeout for tcpwrapped, to be a bit more conservative. I tested with these ncat commands:

• tcpwrapped with a short timeout: ncat -k -l -v --sh-exec "sleep 2" 8888
• tcpwrapped with a longer timeout: ncat -k -l -v --sh-exec "sleep 4" 8888
• Not tcpwrapped, just listens "forever": ncat -k -l -v --sh-exec "sleep 7" 8888
• Not tcpwrapped, but delay before banner: ncat -k -l -v --sh-exec "sleep 4;echo 'SSH-2.0-'" 8888
• Not tcpwrapped, but shorter read timeout: ncat -k -l -v --sh-exec "sleep 4; read x && echo 'SSH-2.0-'" 8888

from nmap.