-----Original Message-----
From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
[mailto:sbradcpa@pacbell.net]
Sent: Friday, November 11, 2005 4:28 PM
To: Derick Anderson
Cc: focus-ms@securityfocus.com
Subject: Re: What server hardening are you doing these days?
Software Restriction Policy
Grab that Windows 2003 Security guide I think they talk about
this in there.
Software Restriction Policies How To...: Security Policy; Security
Services:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003
/library/ServerHelp/a94f7b8b-37f0-4039-b6d7-bb20daabdad2.mspx
There is so much that the operating systems can do these days
that we do not take advantage of it's not funny.
I've seen this in Group Policy and am planning to use it to restrict
program execution for user workstations: set up a restriction policy to
whitelist company-approved programs (Office, Acrobat, etc.) and rely on
the default filesystem permissions which deny write privileges to
Program Files and %SYSTEMROOT%. So the user can only run exe's that I
allow, and they can't write exe's to directories on the whitelist. The
same idea could be applied to servers as well, I imagine.
I'd also like to comment on the Unix/Linux filesystem comparisons that
I've read (and this is not directed at anyone in particular).
In my moderate amount of experience with both systems, I think the
default permissions for Linux users (non-root) and Windows' User account
(NOT Power user, mind you), are conceptually the same. The difference is
in how permissions can be applied to the filesystem, and Windows is more
flexible. I would not use *nix for filesystems which require complex
permission sets.
An example: I set up a set of folders for private transfers of files
between users. The permissions allow any authenticated user to write
files into the directory and read and delete files they create there.
But they can't read or delete files that OTHER users create there. So if
I have to transfer Sensitive Document A to User 1, User 2 can't read it,
copy over it, delete it or append to it, while still having permissions
to write their own files in the same folder.
You can't do that in *nix, as far as I know.
Others have said this, but I think first you have to inform yourself on
how the system works before you can secure it. The Windows Server 2003
guides (what I've read of them) are very helpful in this respect. Once
the understanding is there, you can use what applies to YOUR specific
situation to harden a Windows server.
Derick Anderson
Derick Anderson wrote:
In light of how quickly the Zotob/etc. worms spread after
MS05-039 was
released (6 days, was it?), I think it's safer to stick to
Microsoft-tested ACLs and templates and push down patches
quickly. I
usually have all my machines patched the weekend after the patches
come out. I can do that because I don't mess with ACLs for an
operating system I don't fully understand.
Theoretically, I like the idea of perfect file ACLs and mandatory
access control. However, in the real world, security must
be realistic
to the situation. All the file ACLs in the world can't help an
unpatched machine. MAC can't do much with a privilege-elevation
exploit on a system executable. I try to assess the risk
based on what
I see in the real world, and #1 on that list is unpatched Windows
boxes getting owned. Since I don't let anyone but sys admins on my
production servers, file ACLs aren't as big of an issue.
What I'd like to see from Microsoft is executable
whitelisting turned
on by default: no program runs unless it is part of the
system or an
admin has explicitly installed it (and thus adding it to the
whitelist). Since regular users are denied write access to anything
other than their own directories we are halfway there.
Let me also say that I am not a raving Microsoft fanatic. If I can
accomplish my goals using a non-GUI Debian (that's a Linux
distro for
the uninitiated =) ) server, I will. Unfortunately, Linux
has a ways
to go when it comes to shared file access (Active Directory groups)
and centralized domain-wide policy management (Group Policy). I use
the product that is best suited for the need.
Derick Anderson
-----Original Message-----
From: Depp, Dennis M. [mailto:deppdm@ornl.gov]
Sent: Friday, November 11, 2005 7:06 AM
To: tux@911networks.com; Derick Anderson
Cc: focus-ms@securityfocus.com
Subject: RE: What server hardening are you doing these days?
While I agree the NSA guides are more secure. There is also the
Center for Internet Security http://www.cisecurity.org.
The problem with these templates is I'm not sure Microsoft
uses them
when they do regression testing for hotfixes and service
packs. This
means I have to do more complete testing for hotfixes and service
packs. This translates into longer deployment time for a hotfix.
Each organization has to decide if the additional security
of the NSA
or CIS guides provides is worth the additional problems in patch
deployment.
Dennis
-----Original Message-----
From: Syv Ritch [mailto:tux@911networks.com]
Sent: Thursday, November 10, 2005 6:34 PM
To: Derick Anderson
Cc: focus-ms@securityfocus.com
Subject: Re: What server hardening are you doing these days?
Derick Anderson wrote:
I also stick to Microsoft best practices when it comes to
Microsoft
servers, it's just safer that way. I haven't yet implemented the
Windows
2003 Security guide templates (for fear of breaking our production
environment) but I plan to do that after I've taken care of
some other
more basic issues (domain split, network split, user
lockdown, etc.).
Maybe you should reconsider. There is lot better than MS when it
comes to advising on security.
http://www.nsa.gov/snac/downloads_all.cfm
The NSA. They have both guides and templates. It actually
works and
is far more secure than the MS advice.
--
Thanks
http://www.911networks.com
When the network has to work Cisco/Microsoft
--------------------------------------------------------------
----------
---
--------------------------------------------------------------
----------
---
----------------------------------------------------------------------
-----
----------------------------------------------------------------------
-----
--
Letting your vendors set your risk analysis these days?
http://www.threatcode.com
---------------------------------------------------------------------------
---------------------------------------------------------------------------
