Nmap Development mailing list archives
Re: "tcpwrapped" false positives
From: nnposter () users sourceforge net
Date: Tue, 3 Feb 2015 18:09:25 +0000
Daniel Miller wrote:
Second, I'm not sure that 2 seconds is an appropriate time. Here's how a tcpwrappers rejection works, and why it's not an instant rejection: 1. We open a TCP connection to the host. I'm not certain of whether the handshake time counts toward the time left for the probe, but I think it does, since Nsock is asynchronous. 2. The host checks our address against its black- and white-lists. This oftentimes requires a reverse DNS lookup, and may even include an ident lookup. This is the primary source of delay. 3. The host resets the connection: half a round-trip for the RST packet to reach us.
I understand Dan's reasoning but the reality is that there is no substantial wiggle room if 2 seconds is deemed not enough and 5 is definitely too much. If arbitrarily adopting a mid-point of 3-4 seconds is not palatable then it might be worth contemplating a question whether the value of having this heuristic detection of TCP wrappers is worth the mis-detections of impatient services. To put it bluntly, would it be worth supporting a 25 years old relic at the expense of not supporting more prevalent services? Cheers, nnposter _______________________________________________ Sent through the dev mailing list https://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- "tcpwrapped" false positives nnposter (Jan 02)
- Re: "tcpwrapped" false positives Daniel Miller (Jan 14)
- Re: "tcpwrapped" false positives nnposter (Feb 03)
- Re: "tcpwrapped" false positives Daniel Miller (Feb 03)
- Re: "tcpwrapped" false positives Daniel Miller (Feb 04)
- Re: "tcpwrapped" false positives nnposter (Feb 03)
- Re: "tcpwrapped" false positives Daniel Miller (Jan 14)