Re: TCP Split Handshake and Nmap

[Fyodor <fyodor () insecure org>]

On Thu, Jun 03, 2010 at 01:19:15AM +0100, jah wrote:
> Hi folks,
>
> Has anybody read "The TCP Split Handshake: Practical Effects on Modern
> Network Equipment" published in the Macrothink Network Protocols and
> Algorithms journal [1]?  I thought section 8 regarding port scan
> detection of a split handshake was particularly interesting and reckon
> Nmap could easily handle a SYN or an ACK in response to a SYN probe in
> order to mark a port as open.

Hi Jah.  Thanks for the link[1], I enjoyed the paper.  It is
interesting that Nmap's connect scan (-sT) detect the
open-using-split-handshake ports because Linux's network stack handles
that, but our SYN scan didn't because we look for SYN/ACK.

At first I was a bit annoyed when the paper said "Port scanning is
most often associated with malicious network behavior", but then I
forgave them when they qualified that with "this stigma has faded
considerably over time" and especially when they proceeded to gush
that "Nmap is a highly portable, open source port scanner, and is
arguably the industry standard for network engineers and attackers
alike, as it offers a wide variety of options and several different
styles of scanning network environments." :)

I had to think for a couple minutes about whether we would even want
to support such a thing.  After all, this is a somewhat synthetic
technique because the author hasn't identified any servers which
respond this way.  But overall I think we _should_ handle it, since
most client operating systems seem to do so.  And not handling this
case would allow for the creation of a hidden service which looks
"filtered" to Nmap, but normal system applications can connect to it
just fine.

I think we can ignore the ACK packet the talk about in the beginning
of the paper as part of the five step split handshake (Figure 4).
Normal client operating systems don't seem to care about that either.
It is the SYN without an ACK that we should concern ourself with (step
three in Figure 4, step two in Figure 5).  We won't have an ACK number
to verify, but we should still make sure the dst and src ports match
the proper values.

I think this would be a very small change to Nmap.  Anyone want to
give it a shot?  It is important that you test the change--the paper
includes a simple ruby script (which you combine with an iptables
rule) to do this.  The patch should include a short comment noting why
this is being done, and providing a link to the paper[1].

Cheers,
Fyodor

[1] - http://www.macrothink.org/journal/index.php/npa/article/view/285
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/