Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Date: Mon Jul 08 2002 - 17:11:35 CDT
I dont know if anyone has mentioned this yet but i came across this in
;login from May 2002
Xprobe is a tool automating the X logic.
X is a logic developed from the various Active Operating System
Fingerprinting methods discovered during the "ICMP Usage In
Scanning" research project.
It fingerprints your OS by ICMP datagrams instead of TCP and only needs
upto four packets to do its job. Anyone know how to hide yourself from
this besides blocking all ICMP traffic?
Also off topic can anyone suggest a good way to do remote logging via a
ssh tunnel? I have looked at syslog-ng but i would like to use the base
tools that come with freebsd (i.e openssh and syslogd)
> A correction to my earlier email response (which I also misdirected):
>> From: Clifton Royston <cliftonrlava.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" <laurencefluxinc.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:
>> 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 -- cliftonrlava.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 majordomoFreeBSD.org
> with "unsubscribe freebsd-security" in the body of the message
To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message