Date: Tue, 23 Apr 2002 16:56:43 -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: <3CC5F4BB.FF231884@mindspring.com> References: <Pine.NEB.3.96L.1020423162058.64976n-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > "Securing telnet is hard; let's turn it off and go shopping". 8-). > > Or maybe, > > Few people use telnet any more, so we'll spend some time fixing it, but > we'll also disable it by default, since many of the reports of > compromise come from people who weren't even using it, but left it > turned on since it was the default. "Few people will use telnet, particularly after we turn it off and go shopping. We can avoid vulnerability reports by reducing the number of systems running the code." 8-) 8-) 8-). > Conservative defaults help you with risk you believe is present, > but where you can't necessarily make the material improvement that you'd > like to. "Obscuring the location of the password file by putting it in a hidden directory statistically reduces the risk that the password file will be compromised." > 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. > > 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. 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. -- 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?3CC5F4BB.FF231884>