Re: "tcpwrapped" false positives

[Daniel Miller <bonsaiviking () gmail com>]

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

> Daniel Miller wrote:
> > 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.
>
> This makes a lot of sense because it can cover the long DNS lookups
> and/or ident. If I got this right, in pseudo-code:
>
> tcpwrapped := true
> for each probe in (ordered list starting with Null probe)
>     if (probe received data)
>         tcpwrapped := false
>     if not (probe terminated with server RST)
>         tcpwrapped := false
>     if tcpwrapped and probe == (Null probe) and (probe time spent) <
> TCPWRAPPED_TIMEOUT
>         break
>     do_probe_matching
> end
> return tcpwrapped
Yes, this is basically the idea I wanted to get across. You also clearly
encoded an important point: we shouldn't mark something tcpwrapped if it
closes the connection quickly for some non-null probe if the null probe did
not cause a premature closing. Some service may decide after a couple bytes
that Nmap is not speaking its protocol and shut down immediately.

Also, though I used RST to describe what happens, it could just as well be
a FIN; Nmap's current code handles both cases, as far as I can tell.


> > 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.
>
> I confess my ignorance here. I see the objective to bail out of the
> probing as soon as we are reasonably sure about the presence of a TCP
> wrapper but I do not follow the reasoning for tying the gradual
> increase in TCPWRAPPED_TIMEOUT to the probe rarity or number of
> executed probes.

I was just brainstorming here, and I think I was wrong. Because of the
issue I described above (valid service terminates early based on
incompatible probe), we don't want to end with
PROBESTATE_FINISHED_TCPWRAPPED for any single probe but Null (as the
current code does), though we could do so for the sum of all probes, which
was the proposal that you put into pseudocode.

Dan

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