[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <40EF0F78.9090009@sdf.lonestar.org>
From: bkfsec at sdf.lonestar.org (Barry Fitzgerald)
Subject: No shell => secure?
Ron DuFresne wrote:
> [snip]
>
>
>
>>This is not security through obscurity. This is security through
>>incompatibility. The point of the idea is to make it necessary for an
>>attacker to rewrite an exploit for my system specifically. This is
>>something that over 99% of the potential attackers would not do, because
>>they don't care about my system. When you have an exploit that works
>>against all the RedHat boxes on the Internet, would you bother to
>>customize it so that it works against one single server of one single
>>random weirdo? It's not worth it.
>>
>>
>>
>
>beleive and redefine well known terms and methodologies as you wish, it
>remains none-the-less as I and others have pointed out nothing more then
>security via obscurity. and bears the dangers as some others have pointed
>out that you will most likely end up with an unusable system. On a number
>of vender OS', if the sh shell of csh shell, hooked to root user and
>startup scripts is not the expected defaults, those OS's fail to function
>properly on and tween reboots.
>
>
>
I think you guys need to stop arguing because you're both right.
Yes, changing the shell executable names is security through obscurity.
Yes, it's also security through incompatibility. If he builds the
system from scratch, it doesn't matter what other distributions do --
that's irrelivent at that point. It also doesn't matter if he breaks
the standard, he can choose to do that if he wants.
Doing this won't stop all potential attacks and it will stop many of the
automated attacks that exist in the wild.
Those are the facts as they boil down. I think we go a little bit
overboard when we say that security through obscurity is bad. I think
that we've gained this knee jerk reaction because people try to pass off
obscurity as security, but in the end, obscurity can be a useful
security tool.
Part of the reason that people deploy firewalls is for obscurity.
People munge headers for security. People rename user accounts for
obscurity. The very purpose of using encryption is to obscure data.
Do these actions stop crackers from gaining access to systems? Do they
make them less vulnerable? Not really. They do, however, cause the
attacker to increase the amount of time it takes to carry out a
successful attack - and that is worth something.
All theory aside, the fact of the matter is that if something takes too
much time it will deter *most* people from trying. (I say most people
because there's a class of cracker that is actually motivated by a
lengthy challenge, but if you've attracted their attention you'd have
been cracked regardless of whether obscurity was used.)
Relying on obscurity is bad. We know that closing the source code of a
program doesn't make the program more secure. We know that changing the
port of your HTTP server doesn't make it immune to compromise.
But, to go from that set of points and then to claim that there's no
value to any form of obscurity is to make a logical leap that is not
supported by strategic fact.
If he's willing to go through the trouble of maintaining his own flavor
of GNU/Linux so that he can have renamed programs, then that's his
prerogative. It will buy him something. I think tying that to never
having been rooted is a stretch, but it isn't of no value at all.
-Barry
p.s. No offense meant to any party.
Powered by blists - more mailing lists