Best practices for securing Windows Server 2003

If you've ever deployed Windows NT Server or Windows 2000 Server, you probably know that Microsoft designed those products to be unsecure by default. Although Microsoft has provided many security mechanisms, it's been up to you to implement them. But when Microsoft released Windows 2003 Server, the company switched philosophies. The new philosophy is that the server should be secure by default.

This is generally a good idea, but Microsoft didn't take it quite far enough. While a default Windows 2003 installation is certainly more secure than a default Windows NT or Windows 2000 installation, it is still anything but totally secure. Let's discuss some relatively easy measures that you can take to make Windows 2003 Server even more secure.

Know your role
Understanding the server's role (i.e., intended purpose) is absolutely critical to the security process. There are many roles for which a Windows Server can be configured. For example, a Windows 2003 Server can act as a domain controller, a member server, an infrastructure server, a file server, a print server, an IIS Server, an IAS server, a terminal server, and the list goes on. A server can even be configured to fill a combination of roles.

The problem with this is that each server role has its own security needs. For example, if your server is going to function as an IIS server, you need to enable the IIS services. However, if the server is going to function solely as a file and print server, enabling IIS would be a huge security risk.

The reason I'm telling you this is to point out that there is no way that I can just give you a set of steps to follow and expect those steps to work in every situation. A server's security needs vary tremendously by the server's role and by the server's environment.

Because there are many ways to harden a server, I'll discuss the steps necessary for configuring a server to act as a simple, but secure, file server. I'll try to point out some things that you might do differently if the server is filling an alternate role. Just please understand that this isn't intended as a comprehensive guide to securing every type of server.

Physical security
To achieve true security, your server must be in a secure location. Normally, this means placing the server behind a locked door. Physical security is extremely important because many administrative and disaster recovery tools exist that can double as hacker tools. Anyone with such tools and a minimal skill level can hack a server in a matter of minutes once they have physical access to the machine. Your only hope against preventing such attacks is to place the server in a secure area. This is true of any Windows 2003 Server, regardless of its role.

Creating a baseline
Aside from establishing good physical security, the best advice that I can give you when deploying a series of Windows 2003 Servers is to decide on your security requirements prior to deployment and to enforce those policies immediately after deployment.

The best way to do this is to create a security baseline. A security baseline is a list of documented and accepted security settings. In most cases, your baseline settings will differ considerably depending on the server's role. So the best thing to do is to create several different baselines that you can apply to various different types of servers. For example, you might have one baseline for file servers, another for domain controllers, and still another for IAS servers.

Windows 2003 contains a tool called the Security Configuration And Analysis Tool. This tool allows you to compare a server's current security policy against a baseline security policy contained within a template file. You can either create these templates yourself or use one of the included template files.

The security templates are a series of text based INF files stored in the %SYSTEMROOT%\SECURITY|TEMPLATES folder. The easiest way to examine or modify the individual templates is through the Microsoft Management Console (MMC).

To open the console, enter the MMC command at the Run prompt. When the empty console loads, select the Add/Remove Snap-in command from the File menu. This will cause Windows to display the Add/Remove Snap-in properties sheet. Click the Add button found on the properties sheet's Standalone tab and you will see a list of all of the available console snap-ins. Select the Security Templates snap-in from the list and then click the Add, Close, and OK buttons.

Once the Security Templates snap-in is loaded, you can view each of the security templates. As you navigate through the console tree, you will see that each template mimics the group policy structure. The template names reflect each template's purpose. For example, the HISECDC template is a high security domain controller template.

If you're trying to secure a file server, I recommend starting with the SECUREWS template. As you look through all of the template's settings, you will find that although the template can be used to make the server more secure than it currently is, it may not meet your needs. Certain security settings may be too strict or too relaxed. I would recommend either modifying the existing settings to meet your needs or creating a brand new policy. You can easily create a new template by right-clicking on the C:\WINDOWS\Security\Templates folder within the console and selecting the New Template command from the resulting menu.

Once you have created a security template that meets your needs, go back to the Add/Remove Snap-in properties sheet and add a snap-in called Security Configuration And Analysis. When the snap-in loads, right-click on the Security Configuration And Analysis container, then select the Open Database command from the resulting menu. Since no database currently exists, make up a name for the security database. Click Open, and the necessary database will be created using the name that you provided.

Next, right-click on the Security Configuration And Analysis container and select the Import Template command from the shortcut menu. You'll see a list of all of the available templates. Select the template that contains your security policy settings and click Open. After the template has been imported, right-click on the Security Configuration And Analysis container once again and select the Analyze Computer Now command from the shortcut menu. Windows will prompt you for a location to write the error log. Enter a file path and click OK.

At this point, Windows will compare your server's existing security settings against those in the template file. You can see the results of the comparison by navigating through the Security Configuration And Analysis console. Each group policy setting displays both the current setting and the template setting.

Once you've had a chance to look through the list of discrepancies, it's time to enforce the security policy based on the template. To do so, right-click on the Security Configuration And Analysis container one last time and select the Configure Computer Now command from the shortcut menu. The tool will then modify your computer's security policy to match the template policy.

Group policies are hierarchical in nature. A group policy may be applied at the local computer level, the site level, the domain level, or the OU level. When you implement security based on a template, you're modifying the computer-level group policy. Other group policies aren't directly affected, although the final policy may reflect a change due to a setting in the computer policy being inherited by higher level policies.

Modifying built-in accounts
For years, Microsoft has been preaching that you need to rename the Administrator account and disable the Guest account to achieve good security. In Windows Server 2003, the Guest account is disabled by default, but renaming the Administrator account is still a good idea because it's common for attackers to try to compromise the Administrator account.

There are a number of hacker tools that reveal the Administrator account's real name by examining the account's SID. Unfortunately, you can't change this account's SID and there is really no way of preventing such a tool from determining the Administrator account's real name. Even so, I encourage everyone to rename the Administrator account and to change the account's description for two reasons.

First, less sophisticated hackers may not know of the existence of such tools or have access to them. Second, renaming the Administrator's account to a unique name makes it easy for you to monitor attacks against the account.

Another tip pertains to member servers. Member servers have their own built-in local administrative account that is completely separate from the domain Administrator account. You can configure every member server to use a different administrator account name and password. The idea is that if someone were to figure out the local administrator account name and password on one member server, you wouldn't want them to be able to use those credentials to hack your other servers too. Of course, if you have good physical security in place, no one should be able to gain access to a server to be able to use a local account.

Service accounts
Windows Server 2003 is designed in a way that minimizes the need for service accounts. Even so, some third-party applications absolutely insist on a traditional service account. If possible, always use a local account as the service account instead of using a domain account, because if someone were to gain physical access to the server, they could dump the server's LSA secrets, and compromise the password. If you use a domain password, the password can be used from any computer within the forest to gain access to the domain. If a local account is used, though, the password is useless from anywhere other than the compromised machine and doesn't provide any access to the domain.

System services
There is a fundamental law of computing that states that the more code running on a system, the greater the chance that the code will contain a security vulnerability. One of the primary security strategies that you should focus on is to reduce the amount of code running on your server. Doing so reduces security risks and will also improve the server's performance.

In Windows 2000, there were a lot of services that were running by default, but were totally unnecessary in most environments. In fact, a default installation of Windows 2000 even included a fully operational IIS server. In Windows Server 2003, Microsoft turned off most of the services that aren't absolutely necessary. Even so, there are some services that are running by default, but are open to debate.

One such service is the Distributed File System (DFS) service. The DFS service was primarily designed to make a user's life easier. DFS allows an administrator to create a logical name space containing resources from multiple servers or partitions. To a user, all of these distributed resources appear to exist within a single folder.

I personally like DFS, especially because of its fault tolerance and scalability features. However, if you were to not use DFS, you would force users to know the actual path to a specific resource instead of being able to access all resources through a single path. In some environments, this may translate to better security. In my opinion, though, the rewards of DFS far outweigh the risks.

Another such service is the File Replication Service (FRS). The FRS is used to replicate data between servers. This is a mandatory service on domain controllers because it's responsible for keeping the SYSVOL folder synchronized. For member servers, however, this service isn't mandatory unless you are running DFS.

If you have a file server that isn't a domain controller and isn't using DFS, I recommend disabling the FRS. Disabling the FRS decreases an attacker's ability to replicate a malicious file across multiple servers. The FRS is enabled by default.

Another service worth taking a look at is the Print Spooler service. The Print Spooler manages all local and network print queues and controls all of the print jobs within these queues. The Print Spooler is required for all printing operations, and is enabled by default.

The flip side to this is that not every server requires printing capabilities. Unless a server is acting as a print server, you should disable the print spooler. After all, why should a dedicated file server run the print spooler? Normally, no one should be sitting at the server console working, so there should be no need to print locally or from across the network.

I realize that often during disaster recovery operations, it might become necessary to print an error message or an event log. However, I recommend simply turning on the Print Spooler Service when it is needed rather than leaving it on all the time for non-print servers.

Believe it or not, the Print Spooler is one of the most heavily exploited Windows components. There are countless Trojans that work by replacing the Print Spooler's executable file. The reason for such an attack is that the Print Spooler operates as a system-level service and, therefore, has a high level of privileges. So any Trojan posing as the print spooler can also gain these high-level privileges. To protect your server from such an attack, just prevent the Print Spooler service from running.

TechRepublic originally published this article on 20 October 2003.