From owner-freebsd-hackers Wed Apr 24 2:49:24 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 2B4A137B427; Wed, 24 Apr 2002 02:49:12 -0700 (PDT) Received: from pool0066.cvx21-bradley.dialup.earthlink.net ([209.179.192.66] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 170JOF-00038s-00; Wed, 24 Apr 2002 02:48:43 -0700 Message-ID: <3CC67F5E.44FC802D@mindspring.com> Date: Wed, 24 Apr 2002 02:48:14 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson Cc: 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: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 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