Protecting Hosts

Server and client protection is a fascinating area of security. When people think about protecting (or hardening) hosts, they are usually thinking about security configuration changes, or tweaks. On a Windows system, this typically involves applying some form of "security template" containing a number of security tweaksprimarily Registry changes. These templates can also contain access control lists (ACLs), service modifications, privilege settings, and so on. On a non-Windows system, a similar set of procedures is followed, albeit not with templates.

The problem is that security tweaks are not the be all and end all of security. Nor is security configuration going to be able to stop you from getting hacked. That does not make security tweaks meaningless and does not mean that you should avoid them. You should absolutely consider them, but only after you have performed a number of other steps that are required. To level the playing field a little, we do not devote this tutorial to explaining all the security settings. Instead, we start out by trying to dispel some of the myths around security configuration. It is very important to understand what you gain, and do not gain, from security changes. Note that there is a lot of opinion belonging to the authors in here. Many of the issues we discuss are basically ongoing debates that have no right answer, although we are, of course, partial to our opinions!

After discussing the myths surrounding security configuration, we jump into a section discussing the top 10 client and server security tweaks. These are the 10 (more or less) things that we believe make a significant enough security difference to consider modifying. We discuss each in some level of detail as well as address where we know things break when using this setting (or settingssome consist of several settings). The list is, however, different from clients to servers, because the threats are different. Keep in mind too, while reading this list, that none of the changes make sense unless you have first established a threat model for your environment and know what you are trying to protect against.

There is also a section of changes you do not want to make. These are settings that degrade security, that degrade functionality (without a corresponding improvement in security), or that we just do not like for one reason or another.

That means that we will not discuss how to actually make security changes. This is discussed in great lengths in the various security guides. If you have not already done so, you should immediately go and download the guides. They are available in the Security Guidance Center at http://www.microsoft.com/security/guidance. We do, however, give some guidance to how to choose between the guides and a really interesting new tool called the Security Configuration Wizard (SCW).

Security tweaks usually fall into the following categories:

• Registry hacks
• Registry ACLs
• File system ACLs
• Service startup configuration
• Service ACLs
• User rights assignment
• Password policy
• Audit policies

Some of these, particularly the ACL settings, should be used with more caution than others. We cover that at some length in the sections on settings you should and should not make. Typically these guides implement the settings using security templatesan INF file that can be imported into either Group Policy or another tool for application on a system. Using the guides and the SCW to roll out security policy is considerably easier if you have Group Policy, but even without that, they are still highly useful.