Objective 3.7: Design Security for Servers that Have Specific Roles

The baseline security established on a Windows Server 2003 system is generated from the Setup security.inf template. Although this sets a known starting point, it s important to apply additional security templates based on the role of the computer. Earlier, we reviewed the security templates and discussed their use. In this section, we re going to discuss the types of server roles and which predefined templates might be most appropriate. Your company s network configuration might vary as will your security needs, but these default settings will provide security and will certainly be the topic of several exam questions. Each of the predefined security templates provided by Microsoft covers a specific security need, but there will be cases where you will want to modify a template (remember, always a copy of the original template, never the original) to meet your organization s specific needs. It is recommended that you follow these steps in creating a secure environment for your network:

1. Begin with Setup security.inf . If needed, apply sections of the template to computers that might have been upgraded or modified (versus a clean install, which applies the Setup security.inf template during install). Specific sections can be applied via the secedit command-line tool.

2. Apply the predefined templates to servers based on roles (we ll discuss this in detail in a moment) in a test environment.

3. Test security on the network. Use the Security Configuration and Analysis snap-in or the secedit command-line tool to analyze security on a particular computer. Use the Resultant Set of Policy snap-in to see the results when you apply security via group policy.

4. If you modified security settings via extensions in Group Policy, you might want to use the GPUpdate command-line tool to force refresh of Group Policy so you can see results immediately.

Now that you have a clear idea of the logical steps you would take in applying security to your servers, let s explore common server roles found in Windows Server 2003 and then discuss the specific details of security related to server roles.

Common Server Roles

Although every organization is a bit different, there are common roles that servers play in most organizations. In this section, we ll briefly review common server roles and how these roles are impacted by security considerations.

Microsoft Windows Server 2003 identifies these types of servers:

• File server

• Print server

• Application server

• Mail server

• Terminal server

• Remote Access/VPN server

• Domain controller

• DHCP server

• DNS server

• WINS server

• Steaming Media server

In the next section, we ll review the security considerations for computers in these different roles. You ll learn how to assess the appropriate level of security for the server as well as how to apply security templates to multiple servers in similar roles across the domain or OU.

Exam Warning  

Windows Server 2003 defines a number of different types of servers. Be familiar with these defined roles. You can be sure you ll see questions on the exam that refer to server roles, and knowing the specific differences can help you to understand the question more quickly and identify correct answers as well.

Designing & Planning
Defining, Implementing and Securing Server Roles

Although Windows Server 2003 documentation identifies specific server roles, it s quite common in the real world to see server roles mixed and matched a bit more. Certainly, large organizations often have the resources and the need to separate server roles very clearly. However, small and medium- sized companies often have to find a compromise between the cost of having servers dedicated to one function and the security concerns that arise when various server roles are combined on one computer.

To find the best compromise, you should first begin by identifying current server roles and any server roles you d like to add now or in the near future. Create a list of these server roles so you begin with a clear understand of what you have, what s needed immediately, and what will be needed in the future. Next, group these roles based on similarities in security needs. For example, you might need DCs, DNS servers, and DHCP servers. In a small firm, system performance and security considerations might allow you to place these services all on one computer. These services have similar security needs and they could logically be placed together. You could also group file, print, and application services (excluding IIS) on one server, again if performance permits . These types of services all have similar security needs and could be managed on one server.

Typically, any server that s going to connect to external resources, especially the Internet, needs very specific security. Keeping servers that face the public network safe is a challenge because these servers are common and highly visible targets for hackers and intruders. You might choose to group Internet-based services on one server if it is feasible and will maintain tight security.

Each of the servers should begin with a known security state, a baseline. This is applied via the predefined templates provided with Windows Server 2003. Once you ve defined the server roles for your organization, you can create incremental security templates for specific server roles ”IIS, DCs, print servers, and so forth. These incremental policies build on the predefined baselines and are specific to the security needs of that server role and your organization. You can download samples from the Microsoft Web site at www.microsoft.com/downloads/details.aspx?FamilyID=8a2643c1-0685-4d89-b655-521ea6c7b4db&DisplayLang=en. This download is the Windows Server 2003 Security Guide , which includes tools, templates, and scripts that can be used to manage security in the enterprise.

Placing similar servers in OUs will allow you to create specific GPOs that can be linked to these OUs, providing a fairly easy way to apply security across the enterprise for all server roles. You can then import the incremental security template for that server role into the GPO and it will be applied to the OU when policy is refreshed (or you can force the update by using the gpudate.exe command line utility).

As you can see, there are few hard-and-fast rules on what services you can run on a server. It depends greatly on the company s particular needs, financial resources, and the similarity of security needs. Clearly, it would not be appropriate to put file, print, and application sharing on a DC, although there are no doubt some companies out there configured in exactly that manner. Keeping similar functions isolated improves performance on the network, and dramatically improves security. The cost of a security violation could far outweigh the cost of another server or two, so make sure your budgeting process takes this into account when deciding on how to configure server roles.

 

Server Security Best Practices

Although we ve discussed best practices throughout this chapter, let s review best practices as it relates to server security here just so you re thoroughly familiar with these recommendations.

• Always control physical and network access to critical servers, especially DCs. Keep DCs in an access-controlled location.

• Always perform tasks on the servers with the least possible privileges. Do not perform tasks with Administrator privileges if possible. Use the Run As command when needed.

• Restrict user and machine access to groups that have loose security settings. Provide users and computers with the least possible permissions while still meeting their needs to access and use network resources.

• Secure the data on the computers using strong access control lists (ACLs) and, if needed, the syskey utility. The syskey utility provides protection against password-cracking software that targets the Security Access Management (SAM) database or directory services. It uses strong encryption that is much more difficult (if not close to impossible ) and time consuming to crack.

• Require the use of strong passwords via the Password Policy settings.

• Restrict the downloading and installation of programs that do not come from known, trusted sources.

• Maintain up-to-date virus protection on all systems.

• Keep all software patches up to date. Patches often address newly discovered security holes. Applying patches in a timely manner on all affected machines can prevent problems that are easily avoided.

When you first install Windows Server 2003, you will choose what role or function it will play. If you want to add or change roles after the operating system has been installed, you can use the Configure Your Server Wizard. This wizard opens automatically the first time you log on to the server with administrative credentials. Later, you can use the Configure Your Server Wizard to modify the configuration. In Exercise 2.06, you ll learn how to use the Configure Your Server Wizard to configure your server for a particular role.

Exercise 2.07: Using the Configure Your Server Wizard

Select a test server to work with that will not disrupt normal operations. Log onto your system using the Administrative account.

1. Click Start , select Administrative Tools , and then select Configure Your Server Wizard .

2. The Welcome screen is displayed. If you are unclear about server roles, you can click the link provided to the Configure Your Server wizard help file on server roles.

3. Click Next to begin. Clicking Help on any screen will open the Configuring Roles for Your Server Help file.

4. The next screen, Preliminary Steps, provides a list of steps you should take before continuing the server configuration. This includes having your Windows Server 2003 CD or network share available. When you re ready to proceed, click Next .

5. The next screen in the wizard shows what server roles are already configured on the server. If a server role is not listed, you can add it via the Add or Remove Programs link. Figure 2.15 shows the Server Role selection screen. You can remove roles from a server via this wizard by selecting a configure server role and clicking Next .

   
   Figure 2.15: Configure Your Server Wizard ”Select Server Role

6. Select the desired server role. For this exercise, select Application Server . Click Next .

7. The Application Server Options screen provides the opportunity to install two additional tools, FrontPage Server Extensions and ASP.NET . Select ASP.NET and then click Next .

8. The next wizard screen confirms your selection and allows you to view the options chosen . In this case, the Summary list contains Install Internet Information Services (IIS), Enable COM+ for remote transactions, Enable Microsoft Distributed Transaction Coordinator (DTC) for remote access, and Enable ASP.NET If this is what you want to install, click Next . If not, click Back to go to the previous screen and make a different selection. This is shown in Figure 2.16. For this exercise, click Next .

   
   Figure 2.16: Configure Your Server Summary of Selected Options

9. The next action the wizard takes is to apply the selections you ve chosen. If needed, the Windows Components Wizard will automatically open to configure needed components. You might be prompted to insert your Windows Server 2003 CD or connect to a flat file or network share. The selected services and components are installed as shown in Figure 2.17.

   
   Figure 2.17: Installing Components and Server Role

10. Once the needed Windows components have been installed, the wizard will display a final screen indicating that the server role installation was completed successfully, as shown in Figure 2.18. In this case, it states This Server is Now an Application server. If it fails, read the error message and follow the directions. If you want to know about next steps, you can click the link View the next steps for this role. You can also check the log file by clicking the link Configure Your Server log. When you re ready to close the wizard, click Finish.

    
    Figure 2.18: Configure Your Server Wizard Complete

 

Configuring Security for Domain Controllers

DCs are the heart of any Windows-based network. As their name implies, they control activities on the domain. Their roles can be limited to just one function, or the DC can be configured to have several related functions. This decision is typically based on the size of the network and the number of users and processes that will access the DC. The larger the network, the more specialized DCs tend to become. Regardless of the specific configuration, it s critical that the DCs be well protected, since anyone or anything (computer process or application, for example) that can gain access to the DC can seriously disrupt or destroy network security. Basic security measures include:

• Physically securing the DC in an access-controlled location.

• Using the NTFS file system to protect data on the system volume(s).

• Requiring strong passwords on DCs to protect against unauthorized access.

• If possible, requiring smart card access on DCs. Using smart cards, passwords are generated randomly and encrypted using strong encryption methods .

• Removing all services that will not be used on the DC.

The DC typically authenticates domain logons and maintains the security policy as well as the master database for the domain. Although servers and DCs can validate user logons , only DCs manage changes to passwords or other changes to user and computer accounts. To configure security for the DCs in your network, you want to begin with a baseline ”a known state. When you promote a server to a DC, the DC security.inf template is applied. This provides the baseline security for DCs that is equivalent to the Setup security.inf for all other types of servers. There are two other predefined security templates that can be used on DCs ”the securedc.inf and the hisecdc.inf.

The securedc.inf template can be used if there are DCs or member servers in the domain that are not running Windows NT 4.0 SP4 or later. The securedc.inf file provides strong security but does not require SMB signing, strong encryption, or NTLM v2 authentication protocol use. This is not the most secure setting, but should provide a reasonable level of security in a mixed operating system environment. After applying and testing the securedc.inf template, you might find there are additional areas that can be secured without causing a disruption on the network. If so, make changes to a copy of the securedc.inf template and name the file something descriptive that will tell you what it does. For example, you might simply name it securedc2.inf.

If possible, consider applying the hisecdc.inf security template. Recall that the hisecdc.inf template requires strong passwords and SMB signing . Some down-level clients might not be able to connect to a DC with the hisecdc.inf template applied, so carefully test all scenarios before deploying this template on a DC in a mixed environment.

Common Threats to Domain Controllers

The most common threats to DCs are those that attempt to gain access to the security database on a DC. The DC contains all user accounts and passwords, so accessing this computer provides a hacker almost unlimited access to the network. Typical assaults include:

• Gaining physical access to the server to copy the security database onto removable media for later analysis.

• Gaining access to the security database to modify user rights to provide administrative access to unauthorized user(s).

• Gain access to the DC to modify computers on the domain to allow rogue computers to participate in the domain.

• Gain access to DC communications, via network connections, to monitor, capture, and exploit security information such as user accounts and passwords.

  Exam Warning  

  Changes to default settings should be implemented by creating a new GPO and linking that new GPO to an OU that contains DCs. This new GPO should be added above the level of the Default Domain Controllers GPO so that the modified settings will take precedence over the default settings.

Audit Backup and Restore Events

The Active Directory database on a DC is a virtual gold mine for hackers. In addition to physically restricting access to the DC itself, auditing backup and restore events can help you monitor activities that could result in unauthorized copies of the database being created by those who legitimately or otherwise have Administrative privileges. Setting the Local Policies Security Options Audit: Audit the use of Backup and Restore privilege can be enabled to help you monitor potential abuses . By default, this option is not defined in the DC security.inf template. It is defined but disabled in the securedc.inf and hisecdc.inf templates.

Restrict Access to Removable Media

Another method intruders might use is to take removable media from a sensitive server to a computer on which they have full administrative rights. From there, they can modify permissions, take ownership, and access the data on the removable media. Again, the first line of defense is to physically protect the server in an access-controlled location. However, you can also restrict the ability to format and eject removable media via group policy by modifying the following GPO: Devices: Allowed to format and eject removable media . This GPO is accessed via the Local Policies Security Options section of the DC security.inf, securedc.inf and hisecdc.inf templates.

This can be set to allow Administrators, Administrators and Power Users, Administrators and Interactive Users, or it can be left Not defined. The recommended setting is to allow only members of the Administrators group to format and eject removable media. You can also audit this event if you suspect there are problems with members of the Administrators group.

Restricting Anonymous Access

In Windows Server 2003, access that was available to the anonymous user in Windows NT is now only available to the Everyone and Guest accounts. However, you might still need to provide anonymous access, because some services in earlier versions of Windows require anonymous access to request user accounts from DCs and to list network shares. You might also need to allow use of the Anonymous account across trusts in a forest if an administrator in a trusting domain needs to access a list of users of a trusted domain in another forest.

Windows Server 2003 restricts the Anonymous account by default. If you need to use this account, you should thoroughly document which systems require Anonymous access and why. Examine each situation to determine if there is an alternate way to accomplish the task ”don t think that just because something has used Anonymous access in the past that it requires it. You can modify specific ACLs to include the Anonymous account, or you can make security policy changes that relax the default restrictions placed on the Anonymous account in Windows Server 2003. Once you ve determined where the Anonymous account is needed, use the guidelines in Table 2.13 to apply it appropriately to avoid relaxing security unnecessarily.

Table 2.13: Managing Anonymous Access in Windows Server 2003

Action	Pros	Cons
Edit the ACLs of any resources that require it to allow the Anonymous logon.	Most secure approach.	Administratively intensive . You must identify, modify, and document each resource for which you modify the ACL to allow Anonymous logon.
Use the Do not allow anonymous enumeration of SAM accounts and shares policy GPO.	Prevents attackers from using Anonymous logon to enumerate accounts and shares on a computer.	Might prevent legitimate users from another domain from locating resources. Do not use this if you are running Windows versions prior to Windows 2000, or if you have an outbound one-way trust with a domain in another forest as these both use services that require the Anonymous logon to locate resources.
Use the Let Everyone permissions apply to anonymous users GPO.	Changes security back to Windows NT model, if needed.	Do not apply this unless there is a very compelling reason to do so . If you must use this method, you should edit the ACLs on sensitive resources to not allow the Everyone or Anonymous to access those resources. The Everyone access level does not require authentication, which leaves those resources completely unprotected from attack.
Add Everyone and Anonymous to pre-Windows 2000 compatible access group.	If you have clients running pre-Windows 2000 operating systems and you need to allow users to change their passwords, add the Everyone and Anonymous groups to the compatible access group, which enables anonymous access. Membership in this group is determined by a user option when installing the first domain. You can modify group membership as needed.	Not the most secure setting, down-level clients.

Digitally Signing Authentication Traffic

When a computer is joined to a domain, a computer account is established. In order to communicate with the DC, it must be authenticated. Three settings can be used to determine whether signed and encrypted authentication is used. The three GPO settings that deal specifically with digitally signing authentication traffic are:

• Domain member Digitally encrypt or sign secure channel data (always)

• Domain member Digitally encrypt secure channel data (when possible)

• Domain member Digitally sign secure channel data (when possible)

These can be accessed via the three DC security templates in the Local Policies Security Options section of each template. If you enable Domain member:

Digitally encrypt or sign secure channel data (always) , the member computer will only use secure channel data for communicating with the DC. If you have DCs in the domain that are running an operating system prior to Windows NT 4.0 SP6a, you cannot use this setting. Doing so will make the DC unable to communicate with the member computer, because earlier operating systems do not support this security feature. Upgrading all DCs to at least Windows NT 4.0 SP6a is a wise step in improving domain security. If possible, use this setting to thwart potential attacks including man-in-the middle, replay, and other types of attacks that use this communication data between member computers and DCs.

Consideration must be given to authenticating down-level clients. Any DC that is authenticating users on any version of Windows prior to Windows NT 4.0 SP6a cannot require (via the always setting) digital encryption and signing because it was not supported until NT 4.0 SP6a. Thus, the when possible setting will request digital encryption and signing whenever possible and will not require it on down-level clients or with down-level DCs that do not support these functions. For better security, begin migrating down-level clients and servers to Windows 2000 or later to take advantage of the improved security features.

If you are unable to use the Domain member: Digitally encrypt or sign secure channel data (always) setting because of down-level clients or DCs, you should enable the other two settings: Domain member: Digitally encrypt secure channel data (when possible) and Domain member: Digitally sign secure channel data (when possible) . The effect of these two settings is that a DC or member computer with these settings will request the best possible security and will negotiate a common security setting. Thus, if the member computer has these two settings enabled and it is communicating with a Windows NT 4.0 SP4 DC, it can negotiate to secure the channel using the highest security enabled on the Windows NT 4.0 SP4 DC.

A related setting is the Domain controller: LDAP server signing requirements GPO setting. This determines whether the Lightweight Directory Access Protocol (LDAP) server requires LDAP clients to use data signing. There are three possible values for this object: none , require signature , and not defined . The none setting allows signing to be used if the client supports it but does not require it. The require signature setting requires that data signing be negotiated unless Transport Layer Security/Secure Sockets Layer (TLS/SSL) is used. The not defined option does not apply any setting for this object. While the most secure setting is to require signature , there are problems with using this setting with down-level clients. Any clients that do not support LDAP signing will then be unable to perform LDAP queries against the LDAP server. The fix for this is that computers running Windows 2000 should have Service Pack 3 installed. Other computers require changes to the Registry discussed in Microsoft Knowledge Base article 325465. If you have down-level clients that require LDAP support, you should set this GPO to none , which will allow signing if the client supports it.

Exam Warning  

DCs are likely to receive a lot of attention on the exam, so make sure you re comfortable with the role, risks, and security solutions available for Windows Server 2003 servers.

Securing the Internet Information Server (IIS) Role

The IIS role is one of the most vulnerable server roles due to its inherent exposure to the Internet. Whenever a server is connected to the public infrastructure, it is more visible and more vulnerable to external attacks. Windows Server 2003 includes significant changes to IIS that help protect it from attack. The most noticeable change is that IIS is no longer installed by default as it was in earlier Windows versions. When it is installed by the network administrator, the default permissions are locked down rather than left open. In earlier versions, the default settings were lax and administrators had to lock the server down. Failure to do this properly caused many security problems. The current model in Windows Server 2003 is to disable as many features and provide as few permissions as possible by default.

IIS was installed by default under Windows 2000 and, as a result, there were serious security flaws in most networks ”especially those that weren t actively using IIS services. One way to improve security is to audit your pre-Windows Server 2003 servers to determine if any are running IIS but not actually employed as IIS servers. Removing all unused IIS installations will greatly improve security. One recent virus, the Code Red worm, attacked IIS directly. Other viruses in the future will certainly make IIS a prime target, so removing unused installations and closely monitoring active installations will greatly enhance network security.

As with all other critical servers, you should first implement basic security measures. These were discussed in the domain controller section and are repeated here for your reference.

• Physically secure the IIS server in an access-controlled location.

• Use the NTFS file system to protect data on the system volume(s).

• Require strong passwords on the IIS server to protect against unauthorized access.

• If possible, require smart cards to access IIS servers for local administration purposes. Using smart cards, passwords are generated randomly and encrypted using strong encryption methods.

• Remove all services that will not be used on the IIS server.

  Test Day Tip  

  A new security feature in Windows Server 2003 is a new policy Prevent IIS from Installing, which allows administrators to control which servers running Windows Server 2003 can run IIS.

Using Configure Your Server to Set Up IIS

Since IIS is no longer installed by default, you must take steps to install it on a Windows Server 2003 computer. We ve already gone through the Configure Your Server Wizard to set it up as an application server earlier in this chapter. The application server role includes IIS, so your computer should already be configured as with IIS. You can check this via the Manage Your Server in Administrative Tools . If you want to manage the server role, you can select Manage this application server from the Manage Your Server interface.

The Application Server interface is displayed and includes the IIS Manager. Expanding the tree in IIS Manager will show the computer as well as these three areas: Application Pools, Web Sites and Web Service Extensions. By default, IIS is locked down and dynamic content will not work unless specifically enabled. This is done in the Web Services Extensions area. Features such as ASP, ASP.NET, Server-Side includes, Web Distributing Authoring and Versioning (WebDAV) publishing, and FrontPage Server Extensions will not work until and unless enabled. In the Web Service Extensions dialog, you can allow or prohibit specific service extensions as well as add new service extensions. Figure 2.19 show the default list of Web Service Extensions.

Figure 2.19: IIS Default Web Service Extensions

Basic Security for IIS

Once you ve configured the server to run IIS, you should take the basic steps to secure the server. Placing all IIS servers (if your firm is running more than one) into an IIS OU will help you manage GPOs related to securing and managing IIS servers across the organization. Remember to only install the necessary IIS components, including Web Service Extensions, that you ll use. For example, if you don t use FrontPage technologies, you should not install FrontPage Extensions.

Another security measure you can take specific to IIS servers is to place content on a dedicated volume. This prevents an attacker from accessing system files and other critical files that would otherwise be on the same volume as content you are providing to the public via Web services. Providing a dedicated volume with NTFS permissions will limit a hacker s access to critical files and information that could be used to get further into the network.

IPSec filters can be applied to the IIS server to block or permit specific IP traffic and to secure sensitive IP traffic. IPSec filters are discussed in detail in Chapter 5.

Using URLScan and IISLockdown

The URLScan tool restricts the types of HTTP request that an IIS server will process. URLScan 2.5 is not included with IIS 6.0 because IIS 6.0 has built-in features that provide security functionality that is equal to or better than the features of URLScan 2.5. However, if you are not running IIS 6.0, you should consider using URLScan 2.5.

Note  

You can download the URLScan utility from Microsoft s Web site at www.microsoft.com/technet/treeview/default.asp?url-/technet/security/_default.asp.

Note  

The IIS Lockdown tool can be downloaded from www.microsoft.com/downloads/release.asp?ReleaseID=43955.

URLScan allows the administrator to set rules for filtering incoming requests for the IIS server. By setting restrictions or rules, the administrator can filter out requests that might compromise the security of the IIS server or the network behind it. Intruders often use unusual requests to trick the server. Some common requests used by hackers include:

• Unusually long requests that can cause buffer overflow vulnerabilities

• Request an unusual action that might be incorrectly interpreted or responded to

• Be encoded by an unusual character set that might be incorrectly interpreted or responded to

• Include unusual character sequences that might cause unspecified results

Windows Server 2003 includes IIS 6.0, which include the features of URLScan, although they differ slightly. If you re using a version of IIS prior to 6.0, you can download URLScan from the Microsoft Web site. URLScan will create a configuration file that can be modified from time to time. If you re running URLScan 2.0, you can upgrade to URLScan 2.5 without losing your current configuration files. The upgrade simply adds new security features without modifying your current configuration files. URLScan is also incorporated into another downloadable tool, IISLockdown, which we ll discuss in a moment.

The latest version of URLScan has three significant changes from previous versions. It allows you to change the directory location of the log file, it can log longer URLs (previous versions truncated anything over 1024 bytes), and you can limit the size, in bytes, of a request. URLScan uses role-based templates to assist in setting up appropriate rules.

IISLockdown is another tool used with IIS. The latest version also includes the URLScan 2.5 tool that we just discussed. The IISLockdown tool is primarily intended for IIS installations prior to Windows Server 2003. As discussed, Windows Server 2003 s IIS installation locks down IIS by default. The IISLockdown tool, now in version 2.1, removes services and lowers permissions to provide greater security for IIS. For example, IISLockdown removes or disables unused services such as FTP, HTTP, SMTP, and NNTP. Hackers often look for services that are enabled to exploit inherent properties of those services. When those services are not actively in use, they are often not being monitored or audited , leaving them vulnerable to attack. Disabling unused services improves security, and the IISLockdown tool can be used to do this.

Test Day Tip  

Remember this for test day: IISLockdown is intended to accomplish the same things for IIS 5.0 that Windows Server 2003 s default installation of IIS 6.0 does ”it locks down unused services, ports, and protocols. URLScan is used to set rules for accepting and processing requests on IIS servers.

Before modifying IIS security, determine how the Web server is to be used. The Application Server role allows you to run application pools and to run IIS to provide Web services. Depending on the types of data used on this server, you might need strong security. For example, if you re setting up a Web server that will allow users to log in from any location to check on their 401(k) contributions and settings, you need to configure the server to reliably authenticate authorized users and restrict access to only those users. For strong security, you should also convert FAT partitions on the server s disk to NTFS formatted partitions.

There are also a variety of settings available for Web site authentication, including Anonymous, Basic, Digest, Advanced Digest, Integrated Windows, Certificate, and .NET Passport authentication. IIS is covered later in this book and these topics are discussed in detail. You can also implement encryption, Secure Sockets Layer (SSL), certificates, and auditing for additional security.

Exam Warning  

You re not likely to run into a question about using URLScan or IISLockdown. You might run into questions that test your understanding of these tools and their use in an IIS 5.0 and IIS 6.0 environment. Be sure to be clear about the uses and features of each tool.

Configuring Security for POP3 Mail Servers

If you want to provide POP3 (Post Office Protocol) and SMTP (Simple Mail Transport Protocol) access to users and applications, you ll need to set your server up as a mail server. As with other server roles, this is done via the Configure Your Server Wizard located in Administrative Tools. POP3 provides e-mail retrieval , and SMTP provides e-mail transfer . POP3 accounts are used on the mail server to allow users to retrieve e-mail from the server using an e-mail client such as Microsoft Outlook.

As with IIS servers, POP3 servers are often targeted by hackers because these servers provide access to e-mail user accounts and passwords. There are two major considerations for POP3 servers: determine the proper level of security, and determine the authentication methods to be used.

Security Levels

Since POP3 servers are highly visible targets for hackers, it s recommended that you install and configure a firewall and that you use the IP Security Protocol version 6 (IPSec v6). A firewall is a software and hardware interface that prevents unauthorized access to internal networks from external locations by means of filtering and routing. The mail server should not be connected directly to the Internet without a reliable firewall in front of it. If your organization already has a firewall in place, you can typically add the mail server so that it routes traffic through the firewall.

Head of the Class
Microsoft Exchange Server 2003

Windows Server 2003 includes the ability to run the server as a POP3 server. Many organizations elect to install and use Microsoft Exchange Server 2003. Although outside the scope of this exam and topic, let s take a moment to look at Microsoft Exchange Server 2003 to understand a bit more about it as it relates to e-mail and security.

By default, if you install Exchange Server 2003, the Microsoft Exchange POP3 service, Microsoft Exchange IMAP4 service, and the Network News Transfer Protocol (NNTP) services are disabled . If you upgrade from an earlier version of Exchange Server, your settings will be preserved. Recall that this is a similar behavior to when you install Windows Server 2003. The security settings are very tight, and applications and services are locked down by default. Settings after upgrades are different from settings from clean installations.

In Exchange Server 2003, the Built-in Users group does not have the right to log on locally. If you re setting up Exchange Server 2003 on a DC, the built-in users group has already been removed from the Log on Locally policy setting for the local computer. As with Windows Server 2003, the Anonymous access is disabled by default. An additional security setting in Exchange Server 2003 is that the Everyone group and the Anonymous Logon group are not assigned permission to create top-level folder permissions on public folders. If you re upgrading from an earlier version of Exchange Server, and the Everyone group or Anonymous Logon group had these permissions, setup will remove them .

Exchange Server 2003 also limits the maximum size of file to 10MB and sets the default size of public folders to 10MB as well.

For new installations of Exchange Server 2003, the default POP3 virtual server, the default IMAP4 virtual server, and the default NNTP virtual server are configured to use both basic authentication and Integrated Windows authentication.

As you can see, the default settings in Exchange Server 2003 mirror the default settings in Windows Server 2003. By installing with the fewest possible permissions and by removing access by the Built-in Users group, the Everyone group, and the Anonymous Logon group, Exchange Server 2003 is more secure in both design and deployment.

 

IPSec v6 is used to secure IP traffic in certain situations. Although it can be employed to secure all IP traffic all the time, the use of this secure IP protocol dramatically reduces throughput because IPSec packets must be encrypted and decrypted at each end. This can have an adverse effect on network performance. Therefore, although it can be implemented for all network traffic, it is neither recommended or needed. Most network traffic is innocuous and does not need to be secured. Some down-level clients will not support IPSec, so that must be taken into consideration as well. IPSec can be configured to block or allow specific types of traffic based on any combination of source and destination addresses, specific protocols, and specific ports.

Authentication Methods

The authentication method can be changed only when there are no other mail servers in the domain. If you are establishing the first mail server, you will need to determine the desired authentication method. If the server is either a DC or a member server, the authentication method is the default method used by Active Directory. Otherwise, the authentication method that will be used is determined by local Windows accounts settings.

Securing Other Network Roles

DCs and IIS are two of the most critical and visible server roles and are ones that hackers target because of the potential gold mine of sensitive data on these servers. However, there are other very critical server roles in an organization, all of which must be properly secured against intended and unintended security breaches. In this section, we ll look briefly at other server roles, likely attack points and countermeasures that can be taken to keep the network secure.

Securing Network Infrastructure Servers

Network infrastructure servers are those that control network services, including Dynamic Host Configuration Protocol (DHCP), Domain Naming System (DNS) and Windows Internet Naming Service (WINS). When installed via the Configure Your Server Wizard in Windows Server 2003, the default Windows Server 2003 settings are applied. By default, then, each of these services is installed with the hardest security configuration, and it is up to the network administrator to modify those settings if applications or services do not work properly in this tighter security framework.

We ll discuss DHCP, DNS, and WINS servers separately. However, there are best practices that apply to securing any server running a network infrastructure service. These are delineated in Table 2.14.

Table 2.14: Securing Infrastructure Servers Best Practices

Action	Comments
Place all infrastructure servers in an OU.	This allows you to apply group policy to infrastructure servers in a consistent manner.
Use NTFS on all drives .	NTFS provides file and folder security.
Install any service packs or updates for infrastructure services.	Keeping servers up to date on service packs and updates is critical, because service packs and updates often address critical security issues.
Install virus protection software.	Prevents malicious attacks via viruses, worms, and Trojan horse attacks.
Secure well-known accounts.	Rename the Administrator and Guest accounts, change their descriptions, and use complex passwords. Do not use the same name and password on all servers to prevent an attacker from gaining universal access if he or she can successfully crack one name/password set. The Guest account is disabled by default; ensure this setting is in place.
Secure service accounts.	Configure services to run outside the domain account realm. This prevents access to domain-level information such as domain passwords.
Implement IPSec filters.	Depending on the role of the server, you can apply IPSec filters to filter out unauthorized traffic, including source and destination ports and
Implement auditing of events related to infrastructure services.	Depending on the role of the server, you can enable auditing to monitor meaningful events and alert you to possible intrusion. Useful auditing might include auditing use of privileges, change events, and system events, among others.

In addition, a DC can be assigned the role of Infrastructure Operations Master in Active Directory. In this role, the DC updates the group-to-user reference any time group membership changes. It replicates these changes across the domain. It s important to note that the Infrastructure Operations Master role can be assigned only to one DC in a domain. As mentioned earlier, you can download additional security templates from the Microsoft Windows Server 2003 Web site, including incremental Infrastructure Server policies. Alternately, you can create incremental policies based on predefined security templates that are applied to servers in specific roles. Once you ve defined the server roles and security needs, you can modify predefined templates or create additional templates that incrementally improve security provided by the predefined templates.

Securing DHCP Servers

DHCP servers manage a set of DHCP addresses, called a scope , and assigns addresses to computers in a dynamic fashion. This important role lacks many of the vulnerabilities compared to other server roles. However, in highly secure settings such as financial institutions, DHCP can be more securely configured. Doing so takes a fair amount of administrative work and almost reverts back to static IP addressing, so you would want to thoroughly assess the risk to your DHCP servers within your organization to decide what level of security is most appropriate.

To lock DHCP down, first require that all client computers use DHCP. Next, configure the DHCP server with a reservation for each client computer. By providing just enough IP addresses in the scope, via reservations , you ensure that no unidentified or unauthorized computers can gain an IP address from the DHCP server. This prevents a hacker from being assigned an IP address from the server or from grabbing all the IP addresses via one network interface on a computer to which the hacker has administrative rights. Although an intruder could try to identify an IP address that will work and that isn t currently in use, configuring the DHCP server in this manner will make that task more difficult for would-be intruders.

Another way to help prevent DoS attacks is to implement DHCP servers in pairs and divide their scopes between the two. Place 80 percent of the IP addresses for a scope on DHCP server 1, and the remaining 20 percent of the IP addresses from that scope on DHCP server 2. Split the scope on the DHCP server 2 in just the same way ”80 percent on the server and 20 percent on the other server. This helps ensure that if one DHCP server is brought offline, either due to a malfunction or due to a malicious attack, users will still be able to acquire an IP address.

In general, the security provided by the DC security.inf template provides an excellent baseline. In some cases, the securedc.inf or hisecdc.inf templates can be implemented, depending on the clients using the DHCP servers. Certainly, DHCP servers should be behind the firewall, and unnecessary services should be disabled or uninstalled . Other basic security measures, including controlling access, using NTFS, removing unused services, securing critical accounts, and enabling auditing, should be employed as well.

Securing DNS Servers

The DNS Server service provides the means for computers, users, and applications to resolve names (fully qualified domain names , or FQDN) to IP addresses. Windows Server 2003 s DNS Service, Dynamic DNS (DDNS), accepts dynamic DNS record registrations from computers that have dynamic IP addresses (via DHCP). DDNS provides the ability for all computers to be listed accurately in the DNS database.

There are four common threats to DNS servers:

• Footprinting Footprinting occurs when someone is essentially able to reverse engineer your DNS structure by capturing DNS zone data, including domain names, computer names, and IP addresses for network resources.

• Denial-of-service A denial-of-service (DoS) attack is one in which the server is hit with so many requests (legitimate or bogus ) for service that it must deny service until it processes the requests in the queue. Often, hostile queries are unusually long or contain special characters in an attempt to jam the queue. This typically ends up denying service for legitimate users.

• Data modification Data modification is another method used by intruders. If footprinting is successful, the intruder can use legitimate IP addresses within a packet to attack the network. If successful, the packet appears to have originated on the internal network. This is known as IP spoofing .

• Redirection Redirection occurs when DNS data is redirected to an intruder after the intruder somehow gains control of DNS data. This can be done by polluting the DNS cache data with incorrect DNS data that will cause information to be redirected to the intruder. This is typically only possible when using nonsecure dynamic DNS updating. In Windows Server 2003, DNS cache pollution protection is enabled by default. This prevents DNS records in cache that originate from any place other than authoritative DNS servers. Although this setting might increase DNS queries, it will prevent redirection via DNS cache pollution.

As with other critical servers, basic security measures should be taken to eliminate common security holes. To secure DNS servers that are attached to the Internet, you can take several precautions to mitigate some of the risk:

• Place the DNS server in a perimeter network. A perimeter network is also known as a screened subnet or a demilitarized zone (DMZ) and is an IP segment that allows you to isolate services that are exposed to the external network without exposing internal resources.

• Add a second DNS server on another subnet to protect against DoS attacks.

• Encrypt zone replication traffic via IPSec or VPN tunnels to secure names and IP addresses during transmission.

• Configure firewalls to enforce packet filtering on UDP and TCP ports 53. UDP port 53 is used for the Domain Name Server, and TCP port 53 is used for the Domain Name.

• Restrict the number of DNS servers permitted to initiate a zone transfer.

• Monitor DNS logs and servers on a regular basis.

For DNS servers that are not exposed to the Internet, the following practices will help reduce security risks:

• Allow only secure dynamic updates and limit the list of DNS servers that are allowed to obtain a zone transfer.

• Implement Active Directory-Integrated zones with secure dynamic update.

• Monitor DNS logs and servers on a regular basis.

WINS Servers

The WINS Service is needed to resolve NetBIOS names to IP addresses for clients that cannot use Active Directory services. WINS servers are required unless all domains have been upgraded to Active Directory, all clients are running Windows 2000 or later, and there are no applications that rely on WINS for name resolution in order to run properly.

The biggest security risk to WINS is that information is sometimes replicated across public networks. Transmitting NetBIOS names and IP addresses across a public network creates a vulnerability that can be addressed by implementing IPSec v6 (discussed earlier) or by using Virtual Private Networks (VPN) tunnels for secure communications. Security measures are similar to other infrastructure servers and include the following recommendations.

• Use the strongest level of encryption possible to secure data transmissions.

• Configure Routing and Remote Access service (through which WINS can replicate across the Internet) to use IPSec (signing and/or encryption) with VPN tunnels to secure data communication.

• Use Kerberos v5 or other certificate-based authentication to ensure that identities are verified prior to establishing communication. Kerberos is used by default in Windows Server 2003, and IPSec can be configured to use the Kerberos authentication.

Another suggestion for securing WINS servers that need to replicate data across a public network is to place them on a perimeter network. In this case, placing a WINS server on a perimeter network will provide replication or resolution across the public network without exposing NetBIOS or IP information for internal network resources.

It s important to protect WINS-enabled networks to make sure that unauthorized users do not have physical or wireless access to the network. When a user connects to a network running WINS, user credentials are not required before requesting a name service from the WINS server. A malicious user with physical (or wireless) access can exploit this by launching a DoS attack, which can prevent other users from access the WINS Service.

Finally, you can reserve static IP addresses for mission-critical WINS servers (and other servers or machines whose name-address mapping on the network needs to remain stable). This prevents other computers from grabbing the WINS server s IP address and redirecting WINS traffic for the purposes of gaining access to computer names and IP addresses on the network. However, this adds to administrative overhead, so use this only for mission-critical servers.

Securing File, Print, and Member Servers

Securing file, print, and member servers is simplified in Windows Server 2003 because many IIS is no longer installed by default on these computers. This eliminates a number of potentially serious security holes. All other services not being used on a file, print, or member server should be removed or disabled. In addition, remember to implement the NTFS file system format on all system volumes , and secure well-known accounts (especially Guest and Administrator). Always keeps system updates and patches up to date to address known security issues, and, of course, install and maintain a strong virus protection program. Make sure you update the virus signature file on a regular basis. While this is true for every computer in your company, it s especially important for file, print, and member servers to which users often have greater access.

The security best practices described earlier in this chapter are the best set of security measures that can be taken to secure a file, print, or member server. If internal intrusion is a concern, these servers can be kept in a secure access-controlled location along with other more sensitive servers. Although these servers might not require controlled-access locations, they should be kept in locations that provide some security, as they hold all the information the company uses on a daily basis. It is acceptable to locate these servers outside controlled-access areas, but they should still be out of the path of heavy traffic to prevent intentional and unintentional mishaps. One of the best measures, which is part of security best practices, is to make sure that users have the fewest possible permissions. Members of the Power Users group usually have sufficient permissions to manage the day-to-day tasks of file, print, and member servers. However, you should monitor membership in the Power Users group, and audit any attempts by Power Users to use that authority inappropriately.

Securing Terminal Servers

Terminal Server is used for two primary functions ”one is to allow remote users to connect to applications and files without running them on their own computers. The second use is remote administration of other computers. In Windows Server 2003, you no longer need to use Terminal Server for remote administration. Instead, you can use the Remote Desktop for Administration (RDA), formerly Terminal Services in Remote Administration mode . RDA is installed by default on computers running Windows Server 2003.

Although outside the scope of this chapter, it s important to note that when you configure your server to run Terminal Server, you must properly configure licensing information, or unlicensed clients will be unable to connect after an initial evaluation period. However, once Terminal Server is properly installed and configured, you can activate Internet Explorer Enhanced Security Configuration settings. If activated, IE applies the following security settings to administrators: high security to Internet and Local intranet security zones, and medium security settings to Trusted sites zones. These settings disable scripts, ActiveX controls, and the Microsoft Virtual Machine (VM) that can be the source of security holes. The IE Enhanced Security Configuration settings can be modified via the Manage Your Server interface. Additionally, make sure the server is using NTFS so that you can set file permissions.

Terminal Server allows for two security modes: Full Security and Relaxed Security. Relaxed Security is compatible with legacy applications that require, for example, access to the Registry in order to run properly. Use Full Security whenever possible; otherwise, users will have access to Registry and file system locations. Although this might be required to run legacy applications, it also creates vulnerability. The security mode can be accessed via Start Administrative Tools Terminal Services Configuration .

Determining what level of encryption will be used is another critical step in securing Terminal servers. By default, Windows Server 2003 uses 128-bit encryption, which is considered High security. There are four levels of security available and they must be matched to the Terminal server clients capabilities. These four levels are FIPS Compliant, High, Client Compatible, and Low. Table 2.15 describes each of these encryption levels.

Table 2.15: Encryption Levels in Terminal Services

Encryption Level (most secure to least secure)	Description
FIPS Compliant	The Federal Information Processing Standard (FIPS) describes cryptography requirements used by the U.S. government. This level of encryption uses only 3DES encryption and SHA1 for hashing requirements . If FIPS has been implemented by enabling the GPO System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing , the Administrator for Terminal Services cannot change this in Terminal Services configuration or by using the Set client connection encryption level in Terminal Services.
High (default)	This is the default setting and encrypts data sent from the client to server using 128-bit encryption, which is often referred to as strong encryption. With this setting, any client that cannot support 128-bit encryption will be unable to connect to the Terminal server.
Client Compatible	This setting is used to support down-level clients that do not support 128-bit encryption. This setting uses the strongest encryption the client is capable of supporting.
Low	This is the least secure method. Data sent from the client to the server is encrypted using 56-bit encryption. Data sent from the server to the client is not encrypted.

One new addition to Windows Server 2003 that helps mitigate this problem of legacy clients (which is one common reason for implementing Terminal Server) is to use the Remote Desktop Web Connection, which when installed uses an ActiveX control in Internet Explorer (5.0 or later). It s useful for roaming clients and works on a variety of platforms. However, it is an optional component of the World Wide Web service in IIS and must be installed and enabled via a Web server.

By default, members of the Administrators group and the Remote Desktop Users group can use Terminal Services connections to connect to a remote computer. The Remote Desktop Users group is empty by default, so you need to decide which groups or users should have permission to log on remotely. Users or groups must be members of the Remote Desktop Users group to have permissions to make Terminal Services connections to remote computers. Also be aware of the fact that membership in the Remote Desktop Users group does not also put the user in the local Users group. Determine which users or groups also need to be added to the local Users group.

Securing Remote Access Servers

Remote Access Servers (RAS) are used to provide access to the network for users who are not physically located in the same place as the network. The most typical scenario, as you can imagine, is with users who travel. Clearly, the first step in securing a RAS is to carefully determine who requires remote access. Granting remote access only to users who require it will greatly enhance security. If you re using the server as a router as well (often referred to as Routing and Remote Access Server, or RRAS), there are additional security considerations for securing the routing function.

There are essentially three elements to securing a RAS: the server, the network traffic, and the authentication. Each element is discussed in turn .

Securing the Server

Securing the server is clearly the first element in security. As you re read repeatedly, if there is any question at all about internal security, place the server in an access-controlled location. In any case, the server should be in a secure location within the building, even if access-control measures are not in place. The server s system volumes should be formatted with NTFS to protect files and folders on the system. Removing or disabling unused services and protocols is very important to prevent intruders from leveraging these to attack the system and gain access to network resources. Well-known accounts should be secured, especially the Guest and Administrator accounts. Requiring users to use strong and complex passwords will also help secure the RAS environment by eliminating easily guessed passwords.

Securing Network Traffic

You can secure network traffic, or in this case, traffic between the RRAS server and the remote user, via the use of signing, encryption, and tunneling. Users should be required to use the highest level of encryption supported as well. For Windows XP and Windows Server 2003 clients, 128-bit encryption keys can be used. This can be implemented via Remote Access policies. You can create a policy based on three different encryption levels: Basic, Strong, and Strongest, each described in Table 2.16.

Table 2.16: Remote Access Policy Encryption Options

Encryption Level	Description
Basic	Uses IPSec 56-bit DES or MPPE 40-bit encryption
Strong	Uses IPSec 56-bit DES or MPPE 4-bit encryption
Strongest	Uses IPSec 3DES or MPPE 128-bit encryption

IPSec can use different levels of encryption and is discussed in detail later in this book. Data Encryption Standard (DES) is used throughout Windows Server 2003. It employs a 56-bit key (the key is 64-bits, but 8 are used for error checking, resulting in 56 bits used for the encryption key). 3DES, or triple DES, uses the 56-bit key and processes each block three times, encrypting it with Key 1, decrypting it with Key 2, and encrypting it again with Key 3. The process is reversed on the receiving end. Microsoft Point-to-Point Encryption (MPPE) encrypts data in a Point-to-Point (PPP)-based connection. MPPE can use 128-bit, 56-bit, or 40-bit encryption. The 40-bit encryption is also called MPPE standard encryption.

Strong Authentication

If possible, you should require remote users to be running Windows 2000, Windows XP, or Windows Server 2003. These operating systems have security enhancements not found in earlier operating systems. If users are running these later operating systems, you can then require the use of stronger, more secure authentication methods such as Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2) or Extensible Authentication Protocol (EAP). Each of these is more secure than earlier authentication protocols used in operating systems prior to Windows 2000. These less secure protocols include Password Authentication Protocol (PAP), Shiva Password Authentication Protocol (SPAP), and Challenge Handshake Authentication Protocol (CHAP).

If you plan to run more than one RAS server, you should consider implementing Remote Authentication Dial-In Service (RADIUS) rather than Windows Authentication. RADIUS provides for centralized administration authentication, authorization, and auditing of remote access connections. For further security, RADIUS traffic can be secured via IPSec. In Windows Server 2003, RADIUS is implemented in a Microsoft framework called the Internet Authentication Service, or IAS. As a RADIUS server, IAS provides the centralized authentication, authorization, and auditing services. As a RADIUS proxy, IAS forwards authentication and accounting messages to other RADIUS servers.

By using Remote Access Policies, you can consistently and accurately apply security settings to remote access, including restricting users, user groups, times, or client configurations. To configure Remote Access policies, perform the following actions.

1. To configure Remote Access Policies, open Routing and Remote Access in Administrative Tools .

2. In the tree in the left pane, locate the desired server and locate the node Remote Access Policies .

3. To add a remote policy, right-click and choose New Remote Access Policy, or click Action on the menu and select New Remote Access Policy. The New Remote Access Policy Wizard will launch, stepping you through the process of creating a new Remote Access policy.

4. To modify existing policies, double-click the policy shown in the right pane, or right-click and select Properties from the menu.

Remote Access Policies only allow you to specifically allow or deny policies. Each policy is applied in order, and the order is also shown in the Routing and Remote Access console.

Streaming Media Server

The last specific server role we ll look at is the streaming media server. In the role of a streaming media server, Windows Server 2003 uses Windows Media Services to stream audio and video to internal (network) or external (Internet) clients. Windows Media servers proxy, cache, and redistribute content. Windows Media Services is not available on Windows Server 2003 64-bit versions, nor is it available in the Windows Server 2003 Web Edition.

As with all other server roles, examining default service settings will help determine if there are additional services you can disable to maintain higher security. In addition, using NTFS to secure the data storage is recommended on all servers. As with all servers, the Setup security.inf security template is applied when Windows Server 2003 is installed as a clean installation. If it s upgraded from a prior version, you should audit your security settings by using the Security Configuration and Analysis tool in Administrative Tools or the secedit.exe command-line tool.

In Windows Media servers, authentication and authorization plug-ins control access to content. The two options for authentication are anonymous and network. Anonymous authentication does not exchange challenge/response information with the media player. If you are streaming content to the general public, this authentication method is fine. Network authentication plug-ins authenticate users based on logon credentials and is used to secure access to streaming content to authorized users only.

After a user is authenticated, the user must be authorized to connect to the server. Windows Media Server can use the NTFS Access Control Lists (ACL) plug-in, IP Address Authorization plug-in, and the Publishing Points ACL Authorization plug-in. The Publishing Points ACL allows you to assign read, write, and create permissions for users and groups. By default, the Everyone group has read permissions, and the Builtin\Administrators group has full permissions. This type of plug-in is useful when you want to set restrictions on all content on a specific publishing point or server, or when the publishing point content is a live stream.

Exam Warning  

Although Microsoft exams do tend to focus on new features in the operating system, the security-related exams tend to focus heavily on scenario questions involving a mix of operating systems, which mirrors real-world configurations. Make sure you re comfortable with the security considerations in Windows Server 2003 and with the security risks, configurations, and solutions for working with down-level computers in a networked environment. Your ability in this area will determine how well you do on the exam and on the job as well.

Windows Server 2003 can be configured to run in the server roles just listed. Table 2.17 summarizes the server roles and the services that are installed with each. Although these services can be installed without configuring the specific server role, administration is less complicated when services are installed via the Configure Your Server role. This also increases security by grouping services by role.

Table 2.17: Summary of Services for Server Roles

Server Role	Related Services
DC, DHCP, DNS, WINS	File system security, DHCP protocol, DNS, WINS (networking services), Certificate Services, TCP/IP
IIS	(Part of Application server role), Internet Authentication Service (networking services), Certificate Services, NNTP, FTP, SMTP
File server	Indexing Service, Remote Storage (network file and print services)
Print server	Fax Services (network file and print services)
Application server	IIS, Terminal Server, ASP.NET, Message queuing, UDDI Services
E-mail	POP3 (e-mail services), SMTP (e-mail services), RRAS (default Window Server 2003 component)
Terminal server	Terminal Server, Remote Desktop
Streaming media	Windows Media Services

Objective 3.7.2: Modifying Baseline Security Templates According to Role

In this chapter, we ve looked at the predefined security templates provided in Windows Server 2003. You learned that this version of the operating system comes locked down by default and that modifications to the security templates often mean relaxing security a bit to allow users, services, or applications to function properly. In the past, security had to be tightened against the out of the box settings.

In this section, we re going to briefly recap server roles and discuss the templates that would most likely be used with them. Then, we ll discuss the specifics of how to roll these templates out to an enterprise that involves multiple domains and OUs in a manner that maintains tight security and reduces administrative overhead.

Table 2.18 shows a recap of server roles and security templates that can be applied to each role. As you plan your server security, you ll need to logically group your servers based on roles. Since each organization might implement server roles slightly differently, the data in the table is simply one model. Moreover, although Microsoft s predefined templates set security in a consistent and cumulative manner, you might still need to modify the predefined templates to meet your company s specific security needs. Remember that each template addresses seven specific security areas: account policies, local policies, event log, restricted groups, system services, Registry, and file system. Each server role in your organization might need specific settings in one (or more) of the seven security areas that are not part of the predefined templates settings. In many cases, though, these predefined templates will meet a wide array of security needs for many different types of firms. Although you can modify security settings without using the templates, the templates (both predefined and those you create) provide an excellent tool for managing security settings by providing a consistent framework in which to work. The key is planning, testing, evaluating, and documenting changes before implementing them in the enterprise.

Table 2.18: Server Roles and Recommended Security Templates

Server Role	Security Template(s)	Comments
Domain controller	DC Security.inf (default), Securedc.inf, hisecdc.inf	When a server is promoted to a DC, the Default Domain Controller Security template is applied. Additional security can be applied via the securedc.inf template and the hisecdc.inf template. However, there might be connectivity issues with downlevel clients, including Windows NT 4.0 and earlier. Establishing strong passwords, audit and account lockout policies increases security.
IIS 6.0	Setup security.inf (default), IIS Lockdown Wizard s customized templates for each IIS server role, secure*.inf	Unlike earlier versions, Windows Server 2003 does not install IIS by default, significantly reducing exposure to security threats. When installing IIS, download Microsoft s IIS Lockdown Wizard, which provides customized templates for IISspecific security needs. Securing communication with IPSec, limiting the server role to IIS, and selecting appropriate authentication methods will increase security.
Application servers	Setup security.inf (default), secure*.inf, compat*.inf	The Application server role installs IIS. Some applications require the ability to modify Registry settings, and the compat*.inf template provides those settings.
Mail servers	Setup security.inf (default)	Mail servers should be evaluated in a manner similar to IIS, since they also interact with the public network infrastructure. Implement IPSec, close all unused ports, select appropriate authentication, and use firewall or perimeter network.
Infrastructure servers	Setup security.inf (default), secure*.inf, hisec*.inf	Infrastructure servers include those that provide DHCP, DNS, and WINS services to the domain. Each has specific security considerations. Logically group infrastructure servers by function and set security via GPOs. Using secure and hisec templates might impact down-level clients and applications.
File, Print and Member servers	Setup security.inf (default), secure*.inf, hisec*.inf, compat*.inf	File, print, and member servers should use NTFS to protect the file system (as should other server types). Auditing should be enabled to alert network admins to potential abuse of user rights, especially in groups to which administration has been delegated. Using secure and hisec templates might impact down-level clients and applications. The compat*.inf template might be needed to allow access to functionality for down-level clients.
Terminal server	Setup security.inf (default), secure*.inf	Review default settings for services, and disable any that are unused. Configure Internet Explorer Enhanced Security, and use group policy to manage users, applications, and local settings.
Remote Access server	Setup security.inf, plansecure*.inf, hisec*.inf	Begin with thorough planning for granting remote access permissions. Remove all services not in use. Consider requiring remote access users to upgrade to Windows 2000 or later. Use strong passwords, encryption. Implement IPSec or VPN tunneling. Enable appropriate auditing. Implement via group policy. Run on separate IP segment.
Streaming Media server	Setup security.inf (default), secure*.inf	Security via authentication and authorization based on logon credentials. User firewalls, perimeter networks, DMZs, and so forth. If providing external access, run on separate IP segment. Closely monitor permissions to place content on the server and audit-related events.

Applying Security Across the Enterprise

So far, you ve learned about the default settings in Windows Server 2003 and the predefined security templates that are provided. You re seen how these templates can be applied to a variety of server roles. You ve also learned that you can modify the security settings, but that you must also be cautious in making modifications and you should thoroughly document changes you make. You ve seen that applying these security settings has a cumulative effect and that they can be analyzed prior to implementation using the secedit.exe command-line tool or the MMC snap-in Security Configuration and Analysis. In the last section, you saw that placing servers into logical groupings will allow you to configure security for each type of server. Again, you might be able to use the predefined templates, or you might need to modify these settings. When modifying settings, always work from a copy so you can preserve the original settings in the predefined templates.

So, now that you ve evaluated server roles and created appropriate security templates, how can you roll these settings out across the enterprise without going to each and every machine? What s the best way to apply these settings to those servers that might be in many different locations? Let s look at how to best accomplish that.

As we ve discussed, you can apply security to a single computer using the Security Configuration and Analysis snap-in, but that doesn t help with rolling it out to several or several hundred computers. Once you ve analyzed settings in the Security Configuration and Analysis snap-in, you can export the database into a security template. This template can then be deployed automatically via one of two methods: via the secedit.exe command or via group policy. We ve talked about both options throughout this chapter, but let s bring it all together now to figure out exactly when you would use each tool.

You can use the secedit.exe command-line tool to apply an entire template or sections of a template, as discussed earlier in this chapter. By using a batch program or script, you can apply security settings when the batch program or script runs. These can be logon scripts or batch programs set to run at computer startup, for example. The secedit.exe command-line tool itself does not have the capability to automatically run at a certain time or in certain circumstances. For that, you ll need to use a batch program or script. If you re not using an Active Directory domain, this is the only way to automatically roll out security settings across the enterprise.

However, the easiest way to apply security settings in an Active Directory domain is to use group policy. You can create a new GPO, import a security template, link the GPO to a site, OU, or domain, and the new settings will be applied the next time the GPO is replicated. When using this method, do keep in mind that GPOs are applied in a set order: site, domain, and then OU. In the last exercise of this chapter, you ll walk through the process of creating an OU and applying a template to that OU.

Exercise 2.08: Applying Security Templates via Croup Policy

This exercise, like others in the chapter, should be done on a test computer in a lab environment and not on a live or production system. In this exercise, you ll create a new OU and apply a security template to that OU.

1. Click Start Administrative Tools and select Active Directory Users and Computers.

2. Locate the domain name, right-click, and select New then select Organizational Unit .

3. In the New Object “ Organizational Unit dialog box, type in TestSecurity in the Name: box. Click OK to accept.

4. The TestSecurity OU is displayed in the left pane. Locate that OU and right-click. Select Properties .

5. The TestSecurity Properties dialog box is displayed with four tabs: General, Managed By, COM+, and Group Policy. Select the Group Policy tab by clicking it.

6. Notice there are no GPO links because we created a new OU. To create a new group policy to link to the OU, click the New button.

7. If you have installed the Group Policy Management snap-in, the Group Policy tab is no longer used and the Group Policy tab button is labeled Open , as shown in Figure 2.20. Clicking the Open button will launch the Group Policy Management snap-in. The Group Policy Management snap-in is not installed in Windows Server 2003 by default. This snap-in is discussed in more detail in later in this book.

   
   Figure 2.20: Creating a New Group Policy Link to OU

8. If you have not installed GPMC, the new GPO will be displayed. Replace the default name with the name TestSecurity and press Enter to accept the name.

9. If you have installed the GPMC, the GPMC will open. From this snap-in, you can perform the same tasks. In this case, click Action on the menu and select Create and Link a GPO Here . (If you wanted to link an existing GPO, you can select Action Link an Existing GPO in the GPMC console.)

10. Now that we have a GPO link, we need to edit the properties. With TestSecurity still selected (in the dialog box), click Edit . If you re using GPMC, right-click TestSecurity and select Edit .

11. When you click Edit , you ll notice that the Group Policy Editor launches and your display changes to the GPE. In the left pane, you ll see Computer Configuration and User Configuration . Expand the Computer Configuration node by clicking the + sign to the left of the node, if it s not already expanded. Below the Computer Configuration node, three additional nodes are displayed: Software Settings, Windows Settings and Administrative Templates.

12. Expand the Windows Settings to display the Security Settings node. Although this node is expandable, at this point, do not expand it, but right-click on the node. Click Import Policy from the menu.

13. The Import Policy From dialog box will open and default to the default templates location on your computer. Figure 2.21 shows this step.

    
    Figure 2.21: Import Policy Dialog

14. If you have a custom template you ve created, you can select it at this time. Otherwise, you can choose from the predefined templates displayed. Remember, you should not apply the Setup security.inf template via Group Policy. Select any other template. For the purpose of this exercise, select the securews.inf template. Select the Clear This Database before Importing check box. This box clears out any remaining settings in the database so that the template settings will be applied properly in this database. After placing a check mark in the check box (by clicking on it), click Open .

15. The security settings have been imported into the TestSecurity Group Policy object.

16. In the left pane, expand the Security Settings node, locate and expand the Account Policies node, and then locate and expand the Password Policies node. Notice that the settings from the template have been applied.

17. Close the Group Policy Editor by clicking File and selecting Exit .

18. The Active Directory Users and Computers console is displayed with the TestSecurity Properties dialog box still open. Click the Options button.

19. If you wanted to examine the effects of the GPO, click the Properties button and then click the Security tab to review users and associated permissions. You can also review links via the Links tab to search for sites, domains, and other OUs that use this GPO. Since we just created this GPO, there will be no links. Click Cancel to exit. If you make changes that you want to preserve, click OK .

20. Click Close to close the TestSecurity Properties dialog. Click File Exit to close the Active Directory Users and Computers console.

 

Using the steps described in Exercise 2.08, you can apply security templates to sites, domains, and OUs based on the security plan you ve established. This is the easiest way to apply security settings to computers across a large network, and is the method recommended by Microsoft because it provides safe, secure, and consistent application of security. By using the predefined (or customized) templates, security management follows a logical framework that makes analyzing and troubleshooting security much easier. Although you ll have to be constantly vigilant in maintaining security, starting out with a clear baseline and a consistent method of applying security settings will give you a strong starting point in the never-ending task of maintaining secure network.

Exam Warning  

If the Clear This Database check box is not selected prior to importing a security template, the settings will be merged with those already existing in the GPO. Watch for this on the exam, as security settings can differ radically depending on whether this check box is selected.