Date: Tue, 23 Apr 2002 21:44:27 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: "Greg 'groggy' Lehey" <grog@FreeBSD.org>, Jordan Hubbard <jkh@winston.freebsd.org>, Oscar Bonilla <obonilla@galileo.edu>, Anthony Schneider <aschneid@mail.slc.edu>, Mike Meyer <mwm-dated-1019955884.8b118e@mired.org>, hackers@FreeBSD.org Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?) Message-ID: <Pine.NEB.3.96L.1020423213946.55944I-100000@fledge.watson.org> In-Reply-To: <3CC5F4BB.FF231884@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020423213946.55944I-100000>