From owner-freebsd-hackers Wed Apr 24 2:55:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gate.nentec.de (gate2.nentec.de [194.25.215.66]) by hub.freebsd.org (Postfix) with ESMTP id 17F8837B41D; Wed, 24 Apr 2002 02:55:44 -0700 (PDT) Received: from nenny.nentec.de (root@nenny.nentec.de [153.92.64.1]) by gate.nentec.de (8.11.3/8.9.3) with ESMTP id g3O9sG304711; Wed, 24 Apr 2002 11:54:16 +0200 Received: from nentec.de (andromeda.nentec.de [153.92.64.34]) by nenny.nentec.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g3O9sEm12069; Wed, 24 Apr 2002 11:54:14 +0200 Message-ID: <3CC680C6.2020608@nentec.de> Date: Wed, 24 Apr 2002 11:54:14 +0200 From: Andy Sporner User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:0.9.8) Gecko/20020204 X-Accept-Language: de-at, de, en, en-us MIME-Version: 1.0 To: Terry Lambert Cc: Robert Watson , "Greg 'groggy' Lehey" , Jordan Hubbard , Oscar Bonilla , Anthony Schneider , Mike Meyer , hackers@FreeBSD.ORG Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?) References: <3CC67F5E.44FC802D@mindspring.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I hate to jump into this fray, but if this is going to be a public thread, will everybody make the reply to the list??? :-) So far I only see Terry's emails. Thanks! Andy Terry Lambert wrote: >Robert Watson wrote: > >>On Tue, 23 Apr 2002, Terry Lambert wrote: >> >>>>The reality is that reducing exposure is an important part of any security >>>>posture. >>>> >>>This is an argument for security through obscurity. >>> >>>If we are talking risk reduction, then we can easily achieve it >>>statistically through obscurity. In fact, this is exactly what FreeBSD >>>does through its choice of TCP sequence numbers. >>> >>"Security by obscurity" refers to a behavioral phenomena in system design >>and delivery, not to a technical design principle. For example, it refers >>to using a secret algorithm, but does not refer to using a secret key with >>a published algorithm. So disabling services in a default configuration >>reduces risk by reducing exposure, but it's not security by obscurity. >> > >However, if the goal is risk reduction, then "securty by >obscurity" arguably reduces risk. > > >>When shipping third party code, or our own code, we accept that some code >>is more at risk than other code. That risk might be the result of >>complexity, privilege, exposure, ... Whatever the reason, it's >>disingenuous to sweep it under the rug ("all our code is good, so we ship >>it all turned on") rather than select safe defaults and let people turn on >>what they need. >> > >This somewhat drops us into the "What is UNIX?" argument. I >don't think you want to go there. > > >>>Application state is not necessary for incoming connections which are >>>self-identified by source and destination IP and port; the existing >>>stateless firewall code can handle them completely, without introducing >>>problems. >>> >>X arguments that disable the X11 protocol over TCP will work regardless of >>the configured TCP port for XFree86. Firewall rules won't. Also, >>firewall rules may interfere with other applications, where X11 >>configuration won't. Both have their place. >> > >I can run sendmail on another port as well. At some point, you >have to accept that there are Schelling points where policy and >implementation can rendesvous. It's not reasonable to argue that >an external mechanism is unusable because someone *might* start >X11 with a different port. They *might* start it with the argument >that reenables TCP. The coupling argument you are making here is >specious: the default model for firewall protection is "disable >everything by default, and enable only that which is explicitly >permitted". > >The point is that there is already a model for TCP service protection, >and adding another frob on the side of each server for it really >obfuscates the application of a uniform model to the problem. > >If we grant for a moment your argment "complexity := vulnerability", >then this increase of complexity is a problem, isn't it? > > >>>Actually, it would be more useful to concentrate on so-called "stealth >>>firewall" technology, so that OS identification due to port scans, etc., >>>is impossible, and so it looks as if there is no machine there >>>whatsoever, if there are no services actively listening AND access is >>>permitted to the source machine. >>> >>No doubt an interesting area to explore. >> > >Mostly, it boils down to dropping packets instead of sending RSTs >or ACKs. > >-- Terry > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message