Recently, Microsoft has been publicizing the idea that in order to have the highest possible level of network security, there are five primary areas in which security needs to be addressed, including perimeter defenses, network defenses, host defenses, application defenses, and data defenses. One of the most important of these security areas is host defenses. In this article, I’ll explain what host defenses are and how to enhance your existing host defenses.
What are host defenses?
Host defenses involve every host on your network, making sure that each is as secure as possible. Of course, performing a thorough security audit on every server and on every workstation is no small undertaking. However, by combining the examination process with the implementation of centralized policies designed for specific host roles, the project becomes more manageable.
Obviously, no matter what you do, examining every single machine is still a really big job. Don’t feel like you have to complete the entire thing in a single weekend. Remember that the key to good security is constant assessment. Therefore, as soon as you finish the task of enhancing your host defenses, you should ideally be ready to start all over again.
One of the biggest things that any good security administrator will tell you is that simplicity is the key to good security. The more code running on a machine, the greater the chance that some of the code could contain a bug that allows a weakness in the code to be exploited and security to be breached.
If you don’t believe me, think of all of the potential vulnerabilities constantly being discovered in Microsoft Office and in Internet Explorer. Now, think back about ten years or so. Back then you hardly ever heard of someone using a hole in Microsoft Office to breach security. Part of the reason is that Microsoft Office was much simpler than it is now, and no one in his or her right mind would have thought of using Office to break into a network.
It therefore stands to reason that the first step toward achieving good host-level security is to simplify your machines. To do so, you must define exactly what role each machine needs to fill, and make sure that the machine is performing only the designated role. For example, if a server is functioning as a Web server, it shouldn’t also be functioning as a domain controller. Of course, this is an extreme example, but it gets the point across.
There are six main roles that I’ll be discussing in this article, including:
- Domain controller
- Application server
- File and print server
- Infrastructure server
- IIS server
These six roles represent the primary roles that you can define with Windows 2000 or Windows XP. Obviously, there are other possible roles, but they tend to build on the six roles that I’ve defined. For example, a possible role would be an Exchange Server. However, Exchange 2000 rides on top of Windows 2000 and IIS. Therefore, an Exchange 2000 server would be considered a hybrid of an application server and an IIS server.
Even without additional server components such as Exchange or SQL, it’s possible for a server to perform multiple roles. For example, a server could function as an application server and as a file server. If your servers play multiple roles, then you’ll have to adjust your security settings appropriately. However, you’ll always achieve the best possible security by having machines performing only a single role.
Defining the roles
The easiest way to achieve the role-based security that I just described is to use the power of the Active Directory. The idea is to create an Organizational Unit (OU) for each role, and then assign group policy objects to each OU. In this section, I’ll show you how to prepare the Active Directory for role-based security. As I do, keep in mind that the model I’m using assumes that you’re working within a single domain. If you need to secure multiple domains, you’ll have to either repeat this procedure in each individual domain or set up security at a higher level.
To define the various roles, open the Active Directory Users And Computers console and navigate to the domain in which you want to define the roles. Right-click on the domain, then select New | Organizational Unit. When you do, you’ll be asked to enter the name for the new OU. Enter the words Member Servers and click OK. At this point, an OU called Member Servers will be created. Now, repeat the process and create OUs named Application Servers, File And Print Servers, Infrastructure Servers, and IIS Servers. When you’re done, the domain should look something like the one shown in Figure A, although the domain shown in the figure has a couple of OUs that you won’t have (Mounts and ForeignSecurityPrinciples). You might have noticed that you didn’t create OUs for domain controllers or workstations. That’s because a Domain Controllers container already exists. Likewise, all of the workstations fall within a preexisting container called Computers.
|Create an OU for each security role.|
Once you’ve created the necessary OU structure, you must apply the necessary security to the OUs, and then move the various computer or server objects into the appropriate OU. In this section, I’ll demonstrate how to apply a template to your domain controllers. The technique is identical for the other roles except that you’ll be applying a different template file to the other OUs. Because of this, I’ll walk you through the process of securing your domain controllers step by step. To avoid repetition, I’ll simply show you where securing the other OUs differs from the technique that I’m about to show you.
Although Windows 2000 does come with quite a few security templates, which can be found in the \%SYSTEMROOT%\Security\Templates folder, the default templates aren’t really good enough for the task at hand. Because of this, the first thing you must do is download some new templates. You can acquire the new templates from Microsoft’s Security Guide Scripts Download Web site.
You’ll be downloading a self-extracting file. The extraction program will create a directory structure in the location to which you extract the file. The templates will be found in the \SecurityOps\Templates folder.
When you’ve downloaded the necessary security templates, open Active Directory Users And Computers, right click the Domain Controllers OU, and select Properties. When the Domain Controller Properties sheet appears, select the Group Policy tab. Click New.
You’ll be prompted to enter the name for a new group policy object. Enter the words BaselineDC Policy and press [Enter]. Right-click on the BaselineDC Policy that you just created and select the No Override command from the resulting shortcut menu. This will ensure that another group policy doesn’t override the domain-level group policy that you’re applying to the domain controllers. Generally, it’s considered bad style to use the No Override option, but since this is a top-level policy for the domain, the No Override option is appropriate in this particular case.
Next, select the BaselineDC Policy and click Edit. This will open the Group Policy console for the policy. A bug in Windows 2000 prevents the option that you’re going to need from being available the first time that you open the group policy. Therefore, close the Group Policy console, then click Edit again to reopen it.
At this point, navigate to Computer Configuration | Windows Settings | Security Settings. Right-click the Security Settings container and select Import Policy. You must now specify the security policy that you want to apply. Remember, this article assumes that each server is running only a single role. If your servers are running more than one role, the policy you’re about to import may not be appropriate for your environment. With that in mind, import the BaselineDC.inf file found in the \SecurityOps\Templates folder. Then close the Group Policy window and click the Close button.
Other servers’ types
As I stated earlier, the procedure for implementing policies for other types of servers is identical to implementing the policies on domain controllers, with a few exceptions. As you might have guessed, these exceptions include the OU that you’re working with, the new group policy name, and the template that you’re importing. Other than those factors, the procedure is identical regardless of what role you’re defining. Here are the exceptions:
In the case of application servers, you’ll want to create a new group policy named Application Servers within the application servers OU. After creating this template, import the Baseline.inf security template.
File and print servers
In the case of file and print servers, you’ll want to create a new group policy named File And Print Servers within the file and print servers OU. After creating this template, import the Baseline.inf security template. Unlike application servers, which use only the Baseline.inf template, file and print servers build upon the baseline. Therefore, after importing the Baseline.inf template, perform the template import procedure a second time, but this time you’ll be importing the File And Print Incremental.inf template.
In the case of infrastructure servers, you’ll want to create a new group policy named Infrastructure Servers within the infrastructure servers OU. After creating this template, import the Baseline.inf security template. Like the file and print servers, infrastructure servers build upon the Baseline.inf template. Therefore, after importing the Baseline.inf template, perform the template import procedure a second time, but this time you’ll be importing the Infrastructure Incremental.inf template.
In the case of IIS servers, you’ll want to create a new group policy named IIS Servers within the application servers OU. After creating this template, import the Baseline.inf security template. Like the file and print servers, IIS servers build upon the Baseline.inf template. Therefore, after importing the Baseline.inf template, perform the template import procedure a second time, but this time you’ll be importing the IIS Incremental.inf template.
The process of configuring the workstation role (associated with the Computer container) is quite a bit different from the server-based roles that I’ve been looking at so far. There are a couple of reasons for this difference. First, the templates that you downloaded earlier don’t include a workstation-related template. Second, there may not be any such thing as a standard workstation configuration in your organization. Finally, differences in operating systems may prevent you from creating a standard workstation policy.
You’re going to be on your own when creating a workstation policy, but I can give you some helpful guidelines. Begin the process by creating a group policy object called Workstation in the Computers container in the same manner as you’ve been doing for server-based roles. After doing so, import a workstation template from the default Windows 2000 templates. The default templates are located in the \%SYSTEMROOT%\Security\Templates folder. The BASICWK.INF template will provide you with basic workstation security, while the HISECWS.INF file is designed to be a secure workstation template. Importing one of these templates will give you a place to start.
The next thing you need to do is get a feel for how the workstations are being used. I recommend running the Belarc Advisor against all of your workstations. The Belarc Advisor generates a complete hardware and software audit and displays the information within a Web browser, as shown in Figure B.
|The Belarc Advisor performs a full PC audit within a Web browser.|
Once you have the information, I recommend doing some house cleaning. Remove any outdated or unauthorized applications. I also recommend upgrading the workstation’s OS to either Windows 2000 or Windows XP Professional. This will allow the workstations to take full advantage of the security policy that you’re developing.
Once you think that all of your workstations are up to date and well configured, I recommend running the Microsoft Baseline Security Analyzer against them. This utility is primarily designed for servers, but works well on Windows 2000- and Windows XP-based workstations. You can see an example of this in Figure C. This utility will point out any known security problems and will also tell you which hot fixes still need to be applied.
|The Microsoft Baseline Security Advisor will help you to spot potential security vulnerabilities.|
By the time you’ve updated all of the machines, you should have a really good knowledge of how those machines are being used. You can use this knowledge to edit the group policy you’ve related for the workstations in a way that suits the needs of your individual organization.
When you’re done
After you finish defining all of the various group policies, you must wait for the replication cycle to complete. Once all domain controllers have been received by the updated group policies, you must reboot each machine affected by the new policies one at a time, beginning with the domain controllers.