Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Jul 2002 10:11:16 -1000
From:      Clifton Royston <cliftonr@lava.net>
To:        freebsd-security@FreeBSD.ORG
Cc:        Asep Ruspeni <ruspeni@mti.itb.ac.id>, Laurence Brockman <laurence@fluxinc.com>
Subject:   (Correction) Re: hiding OS name
Message-ID:  <20020708101116.A22900@lava.net>

next in thread | raw e-mail | index | archive | help
A correction to my earlier email response (which I also misdirected):
> From: Clifton Royston <cliftonr@lava.net>
...
> On Mon, Jul 08, 2002 at 07:42:00AM -0700, security-digest wrote:
> > Date: Mon, 8 Jul 2002 08:11:37 -0600
> > From: "Laurence Brockman" <laurence@fluxinc.com>
> > Subject: Re: hiding OS name
> > 
> > I think that what the original poster was trying to get at was when being
> > scanned by something like nmap using the OS detection (Or other tools), it
> > would show no OS.
> > 
> > This would mean changing the way the networking layer responds to certain
> > packets (ICMP, tcp sequencing, etc) and I'm not sure if there is anything
> > out there for FreeBSD (Never bothered to look).
> > 
> > I know there are kernel patches for linux that actually change the stack to
> > emulate other OS's, thus fooling these OS detection tools.
> > 
> > Laurence
> 
> I believe some details of the TCP stack implementation were changed in
> 4.4 and above, which already makes the FreeBSD stack harder to
> identify.  Rebuilding your 4-x kernel with the following flag out of
> the LINT file will make it much harder to identify (and also immune to
> TCP sequence number prediction.)
 
My comment was incorrect; TCP sequence prediction is a completely
different issue and this is already dealt with correctly by the network
stack.  The following option, as it states, refers to the lower level
IP ID generation.

> # RANDOM_IP_ID causes the ID field in IP packets to be randomized
> # instead of incremented by 1 with each packet generated.  This
> # option closes a minor information leak which allows remote
> # observers to determine the rate of packet generation on the
> # machine by watching the counter.
> options         RANDOM_IP_ID
> 
> Unlike the TCP_DROP_SYNFIN flag which will somewhat impair the
> operation of your server, this one provides some actual, if minor,
> benefits against certain types of man-in-the-middle attacks.

My comment there is incorrect; probably the only benefit is closing the
information leak mentioned (of dubious value) and making it a little
harder to ID your operating system.

> Here's sample output from a fairly recent nmap (2.54BETA31) against a
> recently rebuilt 4-STABLE server under my control:
> 
> No exact OS matches for host (If you know what OS is running on it, see
> http://www.insecure.org/cgi-bin/nmap-submit.cgi).
> TCP/IP fingerprint:
> SInfo(V=2.54BETA31%P=i386-redhat-linux-gnu%D=7/8%Time=3D29DEDE%O=21%C=1)
> TSeq(Class=TR%IPID=RD%TS=100HZ)
> T1(Resp=Y%DF=N%W=E000%ACK=S++%Flags=AS%Ops=MNWNNT)
> T2(Resp=N)
> T3(Resp=Y%DF=N%W=E000%ACK=S++%Flags=AS%Ops=MNWNNT)
> T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
> T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
> T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
> T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
> PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=0%ULEN=134%DAT=E)
> 
> 
> Uptime 5.050 days (since Wed Jul  3 07:38:10 2002)
> TCP Sequence Prediction: Class=truly random
>                          Difficulty=9999999 (Good luck!)
> IPID Sequence Generation: Randomized

On a different machine running 4.4-R patched but without this flag the
OS is successfully identified:

Remote operating system guess: FreeBSD 4.3 - 4.4PRERELEASE
Uptime 7.868 days (since Sun Jun 30 13:04:36 2002)
TCP Sequence Prediction: Class=truly random
                         Difficulty=9999999 (Good luck!)
IPID Sequence Generation: Incremental


BTW, a valid reason for keeping people from knowing exactly what you're
running is to make it more likely that they will try the wrong version
of an OS-specific exploit like the recent "apache_scalp".  It might not
help that much, but it would be a *little* better to have people
running a Linux-specific exploit than a FreeBSD-specific exploit
against your FreeBSD box.

  -- Clifton

-- 
    Clifton Royston  --  LavaNet Systems Architect --  cliftonr@lava.net
"What do we need to make our world come alive?  
   What does it take to make us sing?
 While we're waiting for the next one to arrive..." - Sisters of Mercy

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020708101116.A22900>