Date: Wed, 24 Apr 2002 02:48:14 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Robert Watson <rwatson@FreeBSD.org> 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: <3CC67F5E.44FC802D@mindspring.com> References: <Pine.NEB.3.96L.1020423213946.55944I-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CC67F5E.44FC802D>