Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 Apr 1996 17:39:20 -0700 (PDT)
From:      Jon <jon@info.laosb.org>
To:        CyberPsychotic <fygrave@tigerteam.net>
Cc:        Robert Watson <robert+freebsd@cyrus.watson.org>, freebsd-security@FreeBSD.ORG
Subject:   Re: Detecting remote host type and so on..
Message-ID:  <Pine.LNX.3.95.960426172537.12707A-100000@info.laosb.org>
In-Reply-To: <Pine.LNX.4.05.9811301130020.1181-100000@gizmo.kyrnet.kg>

next in thread | previous in thread | raw e-mail | index | archive | help


On Mon, 30 Nov 1998, CyberPsychotic wrote:

> ~ As far as I can tell, it is almost impossible to disguise the operating
> ~ system that you are running.  Most platforms display distinctive banners,
> ~ have quirks in their IP implementation, or just made different design
> ~ choices that may be distinguished remotely (for example, choices about
> ~ timeouts, fragmentation issues, etc).
> 
> 
> yeap. That's what I was told, is used at netcraft.com software to figure
> the type of remote system. Also, I was told that port of FreeBSD utility :
> queso ( I haven't yet found it among the ports of my originally FreeBSD
> 2.2.6 machine,but searching the web now), which does the similar thing...
> hmm.. very interesting.

www.apostols.org/projectz/queso/
Above does what you want.  It should compile on FreeBSD (did on my
2.2.7-stable)


> 
> ~  While you can attempt to hide the
> ~ platform by disabling as many services as possible, removing banners, and
> ~ hiding behind a firewall that reformats packets and connections, there is
> ~ really not a whole lot to do.  I find leaving the information there is
> ~ often more useful than not -- attempting to exploit a bug doesn't require
> ~ knowledge of the OS/version (try all versions you have an exploit for :),
> ~ but having the version information there can be useful in debugging
> ~ interoperability problems.  
> 
> 
> Well, I still don't think that's a good idea to let outsiders know what
> type of system you're running.. it's like having the room with a bunch of
> bells and discussing the matter whether the light should be turned on or
> off. :) consider the following:

Whenever you use a stock system, you open yourself up to all the
vulnerabilities of said system.  If you had a custom system, you would not
be as readily vulnerable to various attacks.  Thus is the trade off of
using a commonly available system.

> 
>  if the attacker knows the type of my OS/architecture  he could just
> preinstall the similar and then find the vulneriabilities which could let
> him it. later on, he could use them just one by one till he either find an
> unclosed/unfixed one or is out of them... 
> now consider the attacker doesn't have this info... first thing he'd
> probably do is portscan. Then he'd try ALL_OS/architecture sploits to see
> if he could work it out, and that would definetely make more noise and
> attract addmin attention. This could be called 'security through
> obsurity(sp?)', but I am sure if you have even 10+ machines to manage, you
> can not keep them all up-to-date. (well, FreeBSD ones, yes, since you can
> make a cronjob for cvsup, but if they all are of different platform).

See above.

> 
> but having lots of noize in your logfile would definetely give you a hint
> that there's something not good with this service and should be urgently
> upgraded/fixed or closed till upgrade. Especially when you count in, that
> most of discovered security holes on most platfroms (except FreeBSD/Linux
> maybe some others, I am unaware of, since they have non-moderated security
> mailing lists) gets published about a WEEK after the discovery. Enough
> time to let people play with your box right? :)
> 

Hopefully those holes go public on bugtraq giving the admin's a fighting
chance.  One of the problems with security is that when a remote hole goes
public, dozens of attackers are awake whereas the one admin may be asleep
allowing a penetration.  Worse is when it does not go public...

> 
> 
> ~ Sort of like having the sendmail version there -- makes it easier to debug
> ~ problems, and lets you use wholesale network scanners to find old
> ~ versions; 
> 
> well.. yep.. that's also the matter..:) easier mainterance vs. strong
> security.  I guess SNMP is still would be the best here if you want to
> bias your setup to the former thing. However using SNMP you need to really
> care of firewalling and stuff, since it's very unsecure thing for
> open-wide network, so far I know.

Well personally, the way I see it is the only person who needs to know the
version is the admin but that leads into another mess...

> 
> 
> ~ but for someone to try to exploit a bug they just try it out.
> ~ If you care a whole bunch, it could probably be cleaned up a bit, but I'm
> ~ not sure its worth the trouble.  If you think the server says too much,
> ~ look at what your average WWW browser spews to the server :).
> 
> :) well, clients are usually  on lame Windog box.:) and there's always a
> way to spoof it by the way :)
> 
> 
> Fyodor
> 
> PS: Thanks alot to everyone else who responded in private way.
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-security" in the body of the message
> 


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?Pine.LNX.3.95.960426172537.12707A-100000>