Inline:
----- Original Message -----
From: "David LeBlanc" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "'Mike Dieroff'"
<[EMAIL PROTECTED]>
Cc: <[email protected]>; <[EMAIL PROTECTED]>; "'Derick Anderson'"
<[EMAIL PROTECTED]>
Sent: Saturday, November 12, 2005 4:05 PM
Subject: RE: What server hardening are you doing these days?
All these "hardening" guides are something I get really weary of dealing
with. For example, I once reviewed a book on this (I'm not saying which in
public) that was guaranteed to leave the system nearly unusable, and
featured hardening steps where the functionality needed to perform the
step
was disabled in a previous step.
I also remember when we did the OpenHack 4 contest, one member of our
group
went a bit overboard on the SQL server and left it where you couldn't
administer it. So much of this stuff is guaranteed to break things.
I absolutely agree-- I too not only reviewed many of these guides (NSA
included) but I was also asked to contribute to some as well. They hit both
ends of the scale: In many instances, the "guide" was nothing more than a
listing of all possible security settings-- the recommendation simply being
the most stringent or restrictive configuration available. No thought was
given to the actual operational implications such a setting would have in a
production environment. Conversely, I was asked by the publishers of
another guide to contrive a configuration that could be globally applied to
any system (client or server) in any role that would secure the box without
breaking anything or causing issues with application operation. In the
prior example, the system was secure but could not be accessed at all --
needless to say in the case of the latter, about the best we could do was
put a "Please don't hack me" sticky note on the screen.
Systems need to be configured based on access-level and role. "What service
is this system providing, and who is accessing it?" SQL Server secures very
differently than Exchange. A DC secures differently than an IIS box. Each
service has its own security idiosyncrasies, threats, risks and
corresponding security configuration applications. Though "security in
depth" and "least privilege" transverse role in concept, their respective
implementation does not. I'm actually getting some Deja Vu regarding a SBS
vs. distributed services model conversation I recently had ;)
One thing that's nice is that the defaults have gotten so much better. I
personally don't do much tweaking any more - doing stuff like disabling
the
LM hashes is a nice touch if you have only current systems.
Great example in point- requiring NTLMv2 between clients and
authentication/peer servers is very strong-- even rainbow tables can't crack
NTLMv2. But, requiring it on a Win2k3 box with POP3 will break SPA logon
support. Servers and systems must be secured based on role.
A comment about another post in the thread - if you think localsystem
access
to anything is an issue, I'd suggest you think through it further.
Localsystem has the right to take ownership of anything, has backup and
restore rights, and even if you took all that away, it would have the
right
to put it back. If you can't trust localsystem, you can't trust that
computer, period.
*Thank you, sir* I know the post, and I was going to reply to it but I had
to head out the West Coast Security Conference. I could not have come up
with a more concise response if I tried (and I actually did, but just got
frustrated.) It is a perfect example of intelligent risk management to our
real-life threats: bleating on about mitigation strategies of LocalSystem
is the last thing on my mind; it's the caboose on the vulnerability train.
The various hardening guides are good, and do have the benefit of some
testing, but before you go off default in a production environment, I'd do
so step by step and evaluate carefully.
Another favorite rant is that so many people worry about tweaking things
when they actually have MUCH bigger problems. Do you have solid patch
management? How about vulnerability assessment? A good host-based IDS
system
sprinkled throughout the network AND someone to pay attention to the data?
A
response team? Do you understand what services are running where, and with
what privileges? A bunch of system service all running under the same
super-high level domain account makes a network that's impossible to
secure.
It's about like tweaking out your car engine when all the wheels have been
stolen. Once you have the fundamentals of security management in place,
THEN
worry about hardening, and then only do so in the context of understanding
what _real_ threat you're addressing, and why the tweak helps.
Where the hell have you been all this time? You need to get back on this
list more-- Your voice is that of mature perspective providing insight into
real life issues. Don't stay away so long next time ;)
t
---------------------------------------------------------------------------
---------------------------------------------------------------------------
