Re: Preventing remote OS detection

From: routeat_private
Date: Mon Feb 22 1999 - 15:57:49 PST

  • Next message: unknownat_private: "Re: Process table attack (from RISKS Digest)"

    [Patrick Gilbert wrote]
    |
    | There are many other ways to determine the operating system as well,
    | most of which are described in a fairly recent phrack article (number 54
    | if I am correct)
    
        You are correct.  Phrack 54-09.  http://www.phrack.com
    
    | How can we mask our operating system from these tcp/ip stack
    | fingerprinting tools while still being functional?
    |
    | The answer can be found in the latest security improvement module at:
    |
    | http://www.pgci.ca/fingerprint.html
    
        While this article does offer some good advice towards risk mitigation,
        there are a few key points I'd like to bring to the table.
    
        The proposed Solaris solution (to change the default MSS to a larger value)
        is still easily fingerprintable.  Perhaps experimenting with psuedo-random
        values within a `safe` threshold would be a bit better, but this too can
        be fingerprinted.
    
        The article does mention a few TCP fingerprint techniques, but not TCP
        options, many of which are very stack specific.
    
        The article doesn't touch down on the prevention of IP or ICMP related
        fingerprinting.  There's a probably good reason for this.  It's somewhat
        difficult and very implementation specific.
    
        Filtering fringe packets will work to dissuade certain fingerprint checks,
        others are based off of `normal` packets.  For example, ICMP unreachable
        packets are often filled with stack specific information.  And the Solaris
        stack seems to be one of the only ones out there that does path MTU
        discovery by default (this is easily noticable by the presense of the DF
        bit in the IP header).
    
        The fact of the matter is that most of these fixes are stopgap measures and
        not very extensible.  The proper fix is standards compliance and ubiquitous
        support.  Of course the question then becomes which standards do we adhere
        to, and what is to be done if there isn't standard defined behavior for
        some instance...?  That's a good one.  I say, close the Internet for
        repairs.
    
    
    --
    I live a world of paradox... My willingness to destroy is your chance for
    improvement, my hate is your faith -- my failure is your victory, a victory
    that won't last.
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:37:22 PDT