Nmap Development mailing list archives

OS detection


From: Angelo Dell'Aera <buffer () antifork org>
Date: Tue, 7 Feb 2006 20:30:08 +0100



I was reading the interview published on SecurityFocus about Nmap 4.00
and read about the new techniques for OS detection. Few years ago while
working on the Linux TCP congestion control code I noticed in the code
something which could be useful for this purpose I think. This code was
still there the last time I took a look at it... five minutes ago! :)

Taking a look at net/ipv4/tcp_input.c we can see how Linux handles the
situation in which a SYN with data is received on a LISTENING port. I
think the comments are self-explaining.


case TCP_LISTEN:
        [..]

        if(th->syn) {
                if(tp->af_specific->conn_request(sk, skb) < 0)
                        return 1;

                /* Now we have several options: In theory there is
                 * nothing else in the frame. KA9Q has an option to
                 * send data with the syn, BSD accepts data with the
                 * syn up to the [to be] advertised window and
                 * Solaris 2.1 gives you a protocol error. For now
                 * we just ignore it, that fits the spec precisely
                 * and avoids incompatibilities. It would be nice in
                 * future to drop through and process the data.
                 *
                 * Now that TTCP is starting to be used we ought to
                 * queue this data.
                 * But, this leaves one open to an easy denial of
                 * service attack, and SYN cookies can't defend
                 * against this problem. So, we drop the data
                 * in the interest of security over speed.
                 */
                 goto discard; 
        }
[..]    


What do you think about it?


Regards,

-- 

Angelo Dell'Aera 'buffer' 
Antifork Research, Inc.         http://buffer.antifork.org
Metro Olografix

PGP information in e-mail header




_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev

Current thread: