Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] DNS question about DNSENUM.PL



On 3/27/2013 1:13 PM, Derek Martin wrote:
> On Wed, Mar 27, 2013 at 10:12:28AM -0400, Rich Pieri wrote:
>> Security by obscurity is no security at all.
>
> This is a popular mantra of paid security professionals, but it is a
> fallacy, and in fact is a tool that those very same people employ
> every day (e.g. recommendations to run ssh servers on non-standard
> ports, configure servers to respond with non-default banners, etc.).
> The benefits of such measures often amount to foiling script kiddies
> who may otherwise compromise your otherwise vulnerable system with
> zero effort, but that itself can be a big win, since this is the
> overwhelming majority of attack traffic that most sites see.

When combined with port-knocking, having a non-standard port for a 
service like ssh
is an effective means of preventing port-scanning attacks. It doesn't 
prevent an
attacker from knocking on all ports that end in "21", before trying all 
ports that end
in "22", or from gaining root access to your server by exploiting a bug 
in Exim4, but it
_IS_ an effective tool when properly deployed.

There is a difference between putting the key to your home under a rock 
in the front
yard or giving it to a neighbor: while the local "Script kiddie" may be 
willing to beat
up your neighbor to obtain the key to your home, it is not "security via 
obscurity".
What we have to deal with instead is a tendency I call 
"security-by-stupidity", i.e., the
tendency of some executives to assume that M$ has it all under control.

> It's virtually impossible to completely harden your network against a
> very knowledgable and determined attacker.  So, PART of the point of
> securing your systems (passive measures) is to slow them down, to give
> you a chance to notice their activites, so you can react and do
> something about it (active measures).  Security through obscurity IS a
> useful tool to that end.

*/ALL/* security is an effort to slow an attacker down. Underwriters 
Laboratories
rates safes in terms of the length of time they can withstand well-known 
attacks: a
safe with a UL rating of TRTL-30 is able to withstand an attack by an 
experienced
safecracker, with a torch and tools, for thirty minutes.  It is 
impossible to harden
/*ANY*/ network completely: the Defender's Dilemma applies.

That doesn't mean that you put the family jewels in a disguise safe 
among your cooking
spices: every experienced criminal will always looks there. It /*DOES*/ 
mean that
any security effort has to combine evaluations of the risks, rewards, 
and costs of each
security measure. The Iranian nuclear specialists could have anticipated
  STUXNET: they were simply unable to do so because of a cultural bias that
prevented them from anticipating that their own employees might be part 
of a
virus-delivery system.


> It just needs to be understood that it is not sufficient, and it is
> one of the least effective methods... you need security in depth, and
> obscurity is a VERY SMALL part of that, but it is indeed a part.  The
> REAL gains you get from it are small, but they're often trivial to
> implement, so they're cost-effective.  In the end, security is about
> trading costs... just like buying insurance.

Well, I (obviously) disagree.  S-T-O might be part of a /sales/ effort, 
and I'm as likely
as the next salesman to take advantage of my customers' preconceived 
notions
about how Hollywood taught them everything they need to know about
computers, but it is /*NOT*/ part of a realistic security program.

Security-by-obscurity is, IMNSHO, the all-too-human tendency to dismiss 
certain
attacks as "impossible", merely because they seem improbable. That 
doesn't mean
that I will ignore them or minimize their risks to my customers, merely 
that I
will account for their tendency to underrate them, and recommend 
appropriate
alternatives, such as added insurance, in place of the defense-in-depth 
needed to
secure against them.

Bill

-- 
Bill Horne
339-364-8487




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org