Re: "tcpwrapped" false positives

[Daniel Miller <bonsaiviking () gmail com>]

On Tue, Feb 3, 2015 at 12:09 PM, <nnposter () users sourceforge net> wrote:

> 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?

Maybe we can compromise: have a short timeout which allows short-circuiting
the fingerprint process, like your patch implements; but also apply the
"tcpwrapped" designation if all the remaining probes receive a RST before
the longer totalwaitms. If we wanted to get really fancy, we could have a
stepped-down timeout  based on the rarity of the probe: As more and more
probes get sent (in order of rarity), the threshold for a RST to be
considered "tcpwrapped" goes up with it. Since the major point of concern
is the NULL probe (rarity 0), that gets the shortest threshold, meaning a
service must have a very short timeout indeed to result in false
"tcpwrapped" designation.

Do you think either of these would be a good approach?

Dan

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