|
|
Posted by Michael Trausch on 04/04/06 01:12
David Haynes wrote:
>
> Mike:
>
> The following article discusses what I am trying to say in another
> way.
>
> http://www.bastille-linux.org/jay/obscurity-revisited.html
>
> In a nutshell: Security through obscurity is not necessarily a bad
> thing and may be part of a security plan.
>
> *Relying* on security through obscurity is a bad thing.
>
Perhaps that's the issue then. When I say "security through obscurity,"
I certainly do not mean "security solely though obscurity." The
practice of implementing it adds further burdens to future
administrators and programmers alike, not only within your organization,
but others.
As I highlighted in my previous post, when people are used to security
being practiced with means of obscurity in their way, they will merely
adapt their cracking programs to handle any potential obscurities that
they will come across. The consequences of that can be increased
cracking attempts, network traffic, and server load.
By minimizing the number of secrets that you retain in your scheme of
security, you are not only helping yourself and your fellow
admins/programmers, but you are helping a bigger picture. In addition,
it keeps the focus where it *should* be: On the strength of the one
item that *should* be kept secret: The key, or in this case, raw access
to data.
When you give attention to obfuscating things, you're taking attention
away from securing things, plain and simple. The human brain does not
work like a dual processor system, processing things in real time all at
once... and you can't work on two problems at once like that, as you (I
am guessing... but, this is just a guess <g>) only have two hands.
Also, keep in mind that we are talking about something that doesn't use
a PKI system. When you're working with PKI systems, the protocols, and
the information on the algorithms, are wide open (just as the
documentation for PHP and Apache are), and you're working with a
controlled access key (which takes a very long time to break), as
opposed to a mechanism running on a web server, which is insanely easy
to detect.
In the case of PHP, I can detect the presence of it by simply going to a
site, and seeing that there is a page there. Then I revisit the site,
adding something to the query string, and see if I get the PHP easter
egg image back:
http://php.net/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42
This works on every server I know of that is currently running PHP.
This will work for every machine I know of that is running PHP, save for
one where PHP was patched to prevent the easter eggs from showing up.
You can try to alleviate the problem by using .htaccess files as well,
to control the "expose_php" flag -- but only if your web application
provider allows you to, and so you can't assume that it is portable.
One thing that I'd like to highlight from the article:
> Does it hurt your site security at all? No, it really doesn't. Your
> good access control, in the form of strong authentication, is still
> present. All we've done is made the server slightly harder to find!
> See, so long as you understand that the server location and port
> number can't serve as a method of authentication, you haven't harmed
> your security in the slightest.
In this case that they're using in the article, they're making an
(accurate) assessment that hiding certain details does not harm your
security. I agree with this wholeheartedly. But given the nature of
the Internet, you've not really added anything beneficial to your
security, either.
In implementing intentional obscurity, you're hoping that it's not going
to be reversed. Unfortunately, with the number of machines that run on
the Internet today, and with many of them under the control of forces
that are out to assuredly do you no good, you've essentially
accomplished nothing. That makes it not only a waste of time, but in
time, every cracker on the planet will know what to look for and then
everyone who's attempting to do this is going to find that they've
wasted manpower to implement obscurity that is trivial.
Now, if your idea of obscurity is to require a plug-in that responds to
a challenge using a strong cryptographic cypher, before the server even
gives the time of day to the person on the other end, you have something
that is going to work, and was worth the time to implement.
In the end, in this situation, all you're doing is adding unnecessary
complexity. Security through obscurity -- especially this type of it --
is trivial, useless, and honestly, not going to help you out at all. I
stress it again: If you want security, you *must* look at all the right
criteria for security. The goal isn't to do something that "doesn't
harm" your security. The goal is to think like the cracker on the other
end, and do things that will _improve_ your security, at least somewhat
substantially. That's why I stress things like SQL injection.
Also, make sure that your algorithms that you use don't generate
unnecessary overhead. This can allow crackers to create substantial DoS
type outages, temporary though they may be.
Make sure you're not using CGI scripts that are vulnerable to buffer
overflows. Make sure that the application server's security and the
database server's security are the way they should be -- that none of
the services involved in that chain are exploitable that anyone is aware
of, and if they become so, that you upgrade them immediately.
Security is about doing things that improve your situation such that it
adds a non-trivial amount of complexity to the equation when trying to
crack a site. That's where the brainpower needs to stay totally focused
on, from initially writing the application, all the way through to
post-release support.
- Mike
Navigation:
[Reply to this message]
|