From owner-freebsd-hackers Tue Apr 23 18:44:50 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2E00A37B41B; Tue, 23 Apr 2002 18:44:43 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g3O1iRw36388; Tue, 23 Apr 2002 21:44:27 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 23 Apr 2002 21:44:27 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Terry Lambert 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?) In-Reply-To: <3CC5F4BB.FF231884@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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. 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. > > > FWIW: I wouldn't object to a firewall rule that disallowed remote TCP > > > connections to the X server by default, if the firewall is enabled. I > > > think we already have this... > > > > The firewall code serves a useful function, but one of its great > > detriments is a lack of application awareness. The current placement of > > the policy seems most reasonable to me, but might be supplemented by such > > a rule if desired. > > 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. > 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. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message