From owner-freebsd-security Mon Nov 30 00:09:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA01208 for freebsd-security-outgoing; Mon, 30 Nov 1998 00:09:09 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from info.laosb.org (info.laosb.org [206.170.208.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA01203 for ; Mon, 30 Nov 1998 00:09:08 -0800 (PST) (envelope-from jon@info.laosb.org) Received: from localhost (jon@localhost) by info.laosb.org (8.8.5/8.8.5) with SMTP id RAA28277; Fri, 26 Apr 1996 17:39:20 -0700 Date: Fri, 26 Apr 1996 17:39:20 -0700 (PDT) From: Jon To: CyberPsychotic cc: Robert Watson , freebsd-security@FreeBSD.ORG Subject: Re: Detecting remote host type and so on.. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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