"tcpwrapped" false positives #39
Closed
Comments
This issue deserves more discussion. I replied on the development mailing list here: http://seclists.org/nmap-dev/2015/q1/52 |
I am committing this patch with changes to support the algorithm we discussed, namely preserving the possibility of marking a service
|
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: