Date: Wed, 24 Apr 2002 11:54:14 +0200 From: Andy Sporner <sporner@nentec.de> To: Terry Lambert <tlambert2@mindspring.com> Cc: Robert Watson <rwatson@FreeBSD.ORG>, "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: <3CC680C6.2020608@nentec.de> References: <Pine.NEB.3.96L.1020423213946.55944I-100000@fledge.watson.org> <3CC67F5E.44FC802D@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CC680C6.2020608>