Chapter 12: The Bastion Hosts Role

Published: December 31, 2003   |   Updated: April 26, 2006

Overview

This chapter focuses on how to harden bastion hosts that run Microsoft® Windows Server™ 2003 with Service Pack 1 (SP1) in your environment. Bastion hosts are secure but publicly accessible computers that are located on the public-facing side of an organization’s perimeter network (also known as DMZ, demilitarized zone, and screened subnet). Bastion hosts are unprotected by a firewall or filtering router, which makes them fully exposed to attack. To minimize the possibility of compromise, bastion hosts need to be carefully designed and configured.

Bastion hosts are commonly used as Web servers, DNS servers, File Transfer Protocol (FTP) servers, Simple Mail Transfer Protocol (SMTP) servers, and Network News Transfer Protocol (NNTP) servers. Ideally, bastion hosts are dedicated to just one of these functions, because the more functions that a server provides the greater the likelihood that a security hole will be overlooked. It is easier to secure a single service on a single bastion host than it is to secure multiple services. Organizations that can afford multiple bastion hosts can greatly benefit from this type of network architecture.

Secure bastion hosts are configured very differently from typical hosts. All unnecessary services, protocols, programs, and network interfaces are disabled or removed, and then each bastion host is configured to fulfill a specific role. If you use this method to harden bastion hosts you can limit potential methods of attack.

The following sections of this chapter describe various security settings that will help secure bastion hosts in any environment. The steps that are included in this chapter will help you create an SMTP bastion host. You will need to modify the configuration files that are included with the guide to add any additional functionality.

Bastion Host Local Policy

The server roles that are described earlier in this guide used Group Policy to configure servers. Group Policy cannot be applied to bastion host servers because they are configured as stand-alone hosts that do not belong to an Active Directory® directory service domain. Because they are exposed and not protected by other devices, only one level of guidance is prescribed for bastion host servers in the three environments that are defined in this guide. The security settings that are described in this chapter are based on the Member Server Baseline Policy (MSBP) for the SSLF environment that is defined in Chapter 4, "The Member Server Baseline Policy." The settings are included in a security template that must be applied to the Bastion Host Local Policy (BHLP) of each bastion host.

Table 12.1 Bastion Host Server Security Templates

Legacy Client Enterprise Client Specialized Security – Limited Functionality

SSLF-Bastion Host.inf

SSLF-Bastion Host.inf

SSLF-Bastion Host.inf

Audit Policy Settings

The BHLP Audit policy settings for bastion hosts are included in the SSLF-Bastion Host.inf file. These settings are the same as those specified in the SSLF-Member Server Baseline.inf file. For more information about the MSBP, see Chapter 4, "The Member Server Baseline Policy." The BHLP settings ensure that all relevant security audit information is logged on all bastion host servers.

User Rights Assignments

The SSLF-Bastion Host.inf file includes the BHLP user rights assignments for bastion hosts. These policy settings are based on those that are specified in the SSLF-Member Server Baseline.inf file in Chapter 4, "The Member Server Baseline Policy." The information in the following table summarizes the differences between the BHLP and the MSBP. Detailed information is provided in the text that follows the table.

Table 12.2 Recommended User Rights Assignments Setting

User Rights assignment Setting

Deny access to this computer from the network

ANONOYMOUS LOGON; Built-in Administrator; Support_388945a0; Guest; all NON-Operating System service accounts

Deny access to this computer from the network

Note: ANONOYMOUS LOGON, Built-in Administrator, Support_388945a0, Guest, and all NON-operating system service accounts are not included in the security template. These accounts and groups have unique security identifier (SIDs). Therefore, you need to add them manually to the BHLP.

This policy setting determines which users cannot access a computer over the network. It denies a number of network protocols, including server message block (SMB)-based protocols, NetBIOS, Common Internet File System (CIFS), HTTP, and Component Object Model Plus (COM+). This policy setting overrides the Access this computer from the network setting when a user account is subject to both policies. If you configure this user right for other groups, you could limit the ability of users to perform delegated administrative tasks in your environment.

In Chapter 4, "The Member Server Baseline Policy," this guide recommends that you include the Guests group in the list of users and groups that are assigned this user right to provide the highest possible level of security possible. However, the IUSR account that is used for anonymous access to IIS is a member of the Guests group by default.

The Deny access to this computer from the network setting is configured to include ANONOYMOUS LOGON, Built-in Administrator, Support_388945a0, Guest, and all NON-Operating System service accounts for bastion hosts in the SSLF environment that is defined in this guide.

Security Options

The BHLP security options settings for bastion hosts are the same as those specified in the SSLF-Member Server Baseline.inf file in Chapter 4, "The Member Server Baseline Policy." These BHLP settings ensure that all relevant security options are uniformly configured on all bastion host servers.

Event Log Settings

The BHLP event log settings for bastion hosts are the same as those specified in the SSLF-Member Server Baseline.inf file in Chapter 4, "The Member Server Baseline Policy." These BHLP settings ensure that all relevant event log settings are uniformly configured on all bastion host servers.

Additional Security Settings

The security settings that the BHLP applies significantly enhance the security of bastion host servers. However, there are a few additional settings that should be considered. These settings cannot be applied through local policy, and must therefore be completed manually on all bastion host servers.

Manually Adding Unique Security Groups to User Rights Assignments

Most user rights assignments that are applied through the MSBP have the proper security groups specified in the security templates that accompany this guide. However, there are a few accounts and security groups that cannot be included in the templates because their security identifiers (SIDs) are specific to individual Windows Server 2003 domains. The user rights assignment setting in the following table must be configured manually.

Warning: The following table contains values for the built-in Administrator account. This account is not to be confused with the built-in Administrators security group. If the Administrators security group is added to the specified “Deny access” user right you will need to log on locally in order to correct the mistake. Also, the built-in Administrator account may have been renamed, as recommended in Chapter 4, "The Member Server Baseline Policy." When you add the Administrator account to a user right, ensure that you specify the renamed account.

Table 12.3 Manually Added User Rights Assignments

Setting Legacy Client Enterprise Client Specialized Security – Limited Functionality

Deny access to this computer from the network

Built-in Administrator; Support_388945a0;

Guest; all NON-Operating System service accounts

Built-in Administrator; Support_388945a0;

Guest; all NON-Operating System service accounts

Built-in Administrator; Support_388945a0;

Guest; all NON-Operating System service accounts

Important: “All non-operating system service accounts“ includes service accounts that are used for specific applications across an enterprise, but does NOT include LOCAL SYSTEM, LOCAL SERVICE or the NETWORK SERVICE accounts (the built-in accounts that the operating system uses).

Securing Well-Known Accounts

Windows Server 2003 with SP1 has a number of built-in user accounts that cannot be deleted but can be renamed. Two of the most well-known built-in accounts in Windows Server 2003 are Guest and Administrator.

By default, the Guest account is disabled on member servers and domain controllers. This configuration should not be changed. Many variations of malicious code use the built-in Administrator account in an initial attempt to compromise a server. Therefore, you should rename the built-in Administrator account and alter its description to help prevent compromise of remote servers by attackers who try to use this well-known account.

The value of this configuration change has diminished over the past few years since the release of attack tools that specify the security identifier (SID) of the built-in Administrator account to determine its true name and then break into the server. A SID is the value that uniquely identifies each user, group, computer account, and logon session on a network. It is not possible to change the SID of this built-in account. However, your operations groups can easily monitor attempted attacks against this Administrator account if you rename it with a unique name.

To secure well known accounts on bastion host servers

  • Rename the Administrator and Guest accounts, and then change their passwords to long and complex values on every server.
  • Use different names and passwords on each server. If the same account names and passwords are used on all servers, an attacker who gains access to one server will be able to gain access to all others.
  • Change the account descriptions to something other than the defaults to help prevent easy identification of the accounts.
  • Record any changes that you make in a secure location.

Error Reporting

Table 12.4 Recommended Error Reporting Settings

Setting Legacy Client Enterprise Client Specialized Security – Limited Functionality

Turn off Windows Error Reporting

Enabled

Enabled

Enabled

This service helps Microsoft track and address errors. You can configure this service to generate reports for operating system errors, Windows component errors, or program errors. It is only available in Windows XP Professional and Windows Server 2003.

The Error Reporting service can report such errors to Microsoft through the Internet or to an internal file share. Although error reports can potentially contain sensitive or even confidential data, the Microsoft privacy policy with regard to error reporting ensures that Microsoft will not use such data improperly. However, the data is transmitted in plaintext HTTP, which could be intercepted on the Internet and viewed by third parties.

The Turn off Windows Error Reporting setting controls whether the Error Reporting service transmits any data.

You can configure this policy setting in Windows Server 2003 at the following location within the Group Policy Object Editor:

Computer Configuration\Administrative Templates\System\Internet Communications Management\Internet Communications settings

Configure the Turn off Windows Error Reporting setting to Enabled in the BHLP for all three environments that are defined in this guide.

Creating the Policy Using SCW

To deploy the necessary security settings, you must use both the Security Configuration Wizard (SCW) and the security templates that are included with the downloadable version of this guide to create a server policy.

When you create your own policy, be sure to skip the "Registry Settings" and “Audit Policy” sections. These settings are provided by the security templates for your chosen environment. This approach is necessary to ensure that the policy elements that are provided by the templates take precedence over those that would be configured by SCW.

You should use a new installation of the operating system to begin your configuration work, which helps ensure that there are no legacy settings or software from previous configurations. If possible, you should use hardware that is similar to the hardware that is used in your deployment to help ensure as much compatibility as possible. The new installation is called a reference computer.

During the server policy creation steps you will probably remove the File server role from the list of detected roles. This role is commonly configured on servers that do not require it and could be considered a security risk. To enable the File server role for servers that require it, you can apply a second policy later in this process.

To create the bastion host policy

  1. Create a new installation of Windows Server 2003 with SP1 on a new reference computer.
  2. Install the Security Configuration Wizard component on the computer through Control Panel, Add/Remove Programs, Add/Remove Windows Components.
  3. Install and configure only the mandatory applications that will be on every bastion host. Examples include antivirus or antispyware utilities.
  4. Launch the SCW GUI, select Create new policy, and point it to the reference computer.
  5. Ensure that the detected server roles are appropriate for the bastion host (for example, Web server). Remove all other server roles.
  6. Ensure that the detected client features are appropriate for your environment. Remove all unnecessary client features. For example, you should remove the Microsoft networking client and the DHCP client features to reduce the server’s attack surface.
  7. For maximum protection, remove all administrative options except for Windows Firewall. Additional options will increase the manageability of the bastion host, but will also increase its attack surface. Carefully weigh the benefits of any options that are not crucial to the proper operation of the bastion host against the potential security risks they might pose.
  8. Ensure that any additional services that are required by your baseline, such as backup agents or antivirus software, are detected.
  9. Decide how to handle unspecified services in your environment. For extra security, you may wish to configure this policy setting to Disable. You should test this configuration before you deploy it to your production network because it may cause problems if your production servers run additional services that are not duplicated on your reference computer.
  10. Ensure the Skip this section checkbox is unselected in the "Network Security" section, and then click Next. The appropriate ports and applications identified earlier are configured as exceptions for Windows Firewall. Uncheck all ports except those that are required for the bastion host function.
  11. In the "Registry Settings" section, click the Skip this section checkbox and then click Next. These policy settings are imported from the supplied INF file.
  12. In the "Audit Policy" section, click the Skip this section checkbox and then click Next. These policy settings are imported from the supplied INF file.
  13. Include the appropriate security template (for example, SSLF-Bastion Host.inf).
  14. Save the policy with an appropriate name (for example, Bastion Host.xml).

Test the Policy Using SCW

After you create and save the policy, Microsoft strongly recommends that you deploy it to your test environment. Ideally, your test servers will have the same hardware and software configuration as your production servers. This approach will allow you to find and fix potential problems, such as the presence of unexpected services that are required by specific hardware devices.

Because computers in the bastion host role are not connected to a domain, you must apply the settings with SCW. You cannot use Group Policy without a domain.

The policy is tested to ensure that the application of this policy to the target servers will not adversely affect their critical functions. After you apply the configuration changes, you should begin to verify the core functionality of the computer. For example, if the server is configured as a certification authority (CA), ensure that clients can request and obtain certificates, download a certificate revocation list, and so on.

When you are confident in your policy configurations, you can use Scwcmd as shown in the following procedure to convert the policies to GPOs.

For more details about how to test SCW policies, see the Deployment Guide for the Security Configuration Wizard at https://technet2.microsoft.com/WindowsServer/en/Library/5254f8cd-143e-4559-a299-9c723b3669461033.mspx and the Security Configuration Wizard Documentation at https://go.microsoft.com/fwlink/?linkid=43450.

Implement the Policy

After you thoroughly test the policy, complete the following steps to implement it:

  1. Launch the SCW GUI.
  2. Select Apply an existing security policy.
  3. Select the XML file that you created earlier. For example, Bastion Host.xml.
  4. Complete the SCW wizard to apply the settings.

Note that if the SCW security policy file contains Windows Firewall settings, Windows Firewall must be active on the local computer for this procedure to complete successfully. To verify that Windows Firewall is active, open Control Panel and then double-click Windows Firewall.

You should now perform a final test to ensure that SCW applies the desired settings. To complete this procedure, confirm that the appropriate settings were made and that functionality is not affected.

Summary

Because bastion host servers that run Windows Server 2003 with SP1 are not protected by other devices such as firewalls, they are exposed to outside attacks. They must be secured as much as possible to maximize their availability and to minimize the possibility of compromise. The most secure bastion host servers limit access only to highly trusted accounts, and enable only those services that are necessary to fully perform their functions.

This chapter explained settings and procedures that can be used to harden bastion host servers and make them more secure. Many of the settings can be applied through local Group Policy. Guidance about how to configure and apply manual settings was also provided.

More Information

The following links provide additional information about topics that relate to hardening bastion host servers that run Windows Server 2003 with SP1.

This accelerator is part of a larger series of tools and guidance from Solution Accelerators.

Download

Get the Windows Server 2003 Security Guide

Solution Accelerator Notifications

Sign up to stay informed

Feedback

Send us your comments or suggestions