> -----Original Message----- > From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 09, 2005 4:23 PM > To: [email protected] > Subject: What server hardening are you doing these days? > > > Steve Riley's WebLog : When security breaks things: > http://blogs.technet.com/steriley/archive/2005/11/08/414002.aspx > > Are folks doing additional hardening to their servers these > days and if so, what guidance are you using? > > Interesting blog post about the impact of such hardening and > not supported ACL adjusting. > > -- > Letting your vendors set your risk analysis these days? > http://www.threatcode.com >
Most of the hardening that I do revolves around using Group Policy to restrict user access (Interactive Logon, Terminal Services) and force the use of strong encryption in protocols (NTLMv2 only, etc.). I read Steve's blog and agree that XP and 2003's ACLs are vastly improved over 2000. I plan to use those ACLs to harden user workstations along with Software Restriction policies (and IE lockdown). My goal is that a non-power user will not be able to execute anything that I haven't approved for install. My other approach to server hardening is quite simple: let as few people on them as possible (physical security too!), run as few services as possible, change as little as possible (other than moving logs to a separate partition). I firmly believe that once a user is given access to a machine, it is not a matter of if, but when they can find a way to elevate privileges, whether it's Windows 2003 or Linux. 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.). Particular to my company (application service provider) is the rule that production software changes to fit the environment, and not the other way around. If the production software does not work with the current ACLs and security policy, then it's up to the developers to find another way. Fortunately my CIO backs me on this, SAS70 compliance being a great catch-all reason for making the right choice. Derick Anderson --------------------------------------------------------------------------- ---------------------------------------------------------------------------
