Lesson 2: Tuning Security for Server Roles

---

To be effective, security settings must be fine-tuned to the role that each computer serves on a network. Database servers, such as a SQL Server, must be configured to allow authorized user accounts to issue database queries. Messaging servers, such as a computer running Exchange Server, must be configured to authenticate messaging users and must have security configured to allow the exchange of messages with other systems.

Each network service that is added to a computer system inherently exposes another potential vulnerability. Although adding the DHCP Server role does not necessarily expose you to a vulnerability, configuring that role does cause the server to listen for an additional type of request from clients. Without the DHCP Server role installed, the server would simply ignore those types of requests. At some point in the future, if a vulnerability is discovered that can exploit DHCP servers, your computer could be vulnerable.

Although each additional role increases a computer’s attack surface, and thereby introduces an additional security risk, you as an administrator can do a great deal to mitigate that risk. Some of those mitigating steps, such as enabling packet filtering, are implemented by using tools provided by the operating system. Other steps can be taken by using the tools provided with the server role, such as limiting Web requests to those from specific internal networks.

This lesson describes the most common server roles used on enterprise networks and how to configure those roles to meet your organization’s security requirements.

After this lesson, you will be able to

• Use firewalls and perimeter networks to provide an additional layer of security for computers running Windows Server 2003.

• Customize security settings for infrastructure servers, such as DHCP servers, DNS servers, and domain controllers.

• Configure a Web server to serve content to the public Internet while minimizing the risk that the system will provide attackers with an entry point to the internal network.

• Describe the role an Internet Authentication server provides on a network, and describe the circumstances under which the RADIUS protocol should be used.

• Understand the risks and benefits of the two different authentication modes provided by SQL Server, and describe the authorization capabilities built into the database software.

• Describe the security implications of deploying an Exchange Server computer, and configure network security to minimize the exposure of your messaging server while still allowing all necessary network communications.

Estimated lesson time: 60 minutes

Firewalls

In the physical world, businesses rely on several layers of security. First, they rely on their country’s government and military forces to keep order. They also trust their local police to patrol the streets and respond to any crimes that occur. They further supplement these public security mechanisms by using locks on doors and windows, employee badges, and security systems. If all these defenses fail and a business is a victim of a crime, the business’s insurance agency absorbs part of the impact by compensating the business for a portion of the loss.

Unfortunately, the state of networking today lacks these multiple levels of protection. Federal and local governments do what they can to impede network crime, but they’re far less effective than police forces are at preventing physical crime. Beyond prevention, law enforcement generally responds only to the most serious network intrusions. The average Internet-connected business is attacked dozens of times per day, and no police force is equipped to handle that volume of complaints. Losses from computer crime are hard to quantify and predict, and as a result most business insurance policies do little to compensate for the losses that result from a successful attack.

The one aspect of physical security, however, that isn’t missing from network security is the equivalent of door locks: firewalls. Just as you lock your car and home, you need to protect your computers and networks. Firewalls are these locks, and, just like in the physical world, they come in different shapes and sizes to suit various needs.

Security Alert 

Like physical locks, firewalls are not impenetrable. No firewall, whether a host-based firewall or a several-thousand-dollar enterprise firewall array, will make your computers impervious to attack. Firewalls are merely barriers to attack. By making it difficult for attackers to get into your network, by making them invest lots of time, you can make your organization less attractive. However, it’s impossible to fully prevent every intrusion: As long as you must allow legitimate traffic through, the network connection can be misused for an attack. Additionally, all software has bugs, and someone might find an obscure bug in your firewall that allows them to launch an attack. In a nutshell, there’s no such thing as absolute security. How much you invest in firewalls should be a function of how much you have to lose if an attack is successful.

There are two main types of firewalls: network firewalls and host-based firewalls. Network firewalls, such as the software-based Microsoft Internet Security and Acceleration (ISA) Server or the hardware-based Nortel Networks Alteon Switched Firewall System, protect the perimeter of a network by monitoring traffic that enters and leaves. Host- based firewalls, such as Internet Connection Firewall (ICF), which is included with Windows XP and Windows Server 2003, protect an individual computer regardless of the network it’s connected to. Most businesses require a combination of both types of firewalls to meet their security requirements.

TCP/IP flow basics

To understand how firewalls determine whether to allow or deny traffic, you must understand how Transmission Control Protocol/Internet Protocol (TCP/IP) packages information. TCP/IP traffic is broken into packets, and firewalls must examine each packet to determine whether to drop it or forward it to the destination. Packets have three key sections: the IP header, the TCP or User Datagram Protocol (UDP) header, and the actual contents of the packet. The IP header contains the IP addresses of the source, which is the sender, and the destination, which is the receiver. The TCP or UDP header contains the source port of the sender and the destination port of the receiver to identify the applications that are sending and receiving the traffic. In addition, TCP headers contain additional information such as sequence numbers, acknowledgment numbers, and the conversation state. The destination TCP and UDP ports define the locations for delivery of the data on the server when the packet reaches its destination.

It’s important to appreciate the communication flow of a TCP/IP conversation when configuring the firewall. When a browser, for example, sends a Hypertext Transfer Protocol (HTTP) request to a Web server, the request contains the identity of the client computer, the source IP address, and the source port that the request went out on. The source port of the client identifies the client application that sent the request—in this case, the browser. When the Web server sends a response, it uses the client’s source port as the destination port in the response. The client operating system recognizes the port number as belonging to a session the browser application started and provides the data to the browser. The source port for a client is typically a value greater than 1024 and less than 5000.

Packet filtering

The primary purpose of a firewall is to filter traffic. Firewalls inspect packets as they pass through and, based on the criteria that the administrator has defined, allow or deny each packet.

By default, most firewalls block everything that you haven’t specifically allowed. Routers with filtering capabilities are a simplified example of a firewall. Administrators often configure them to allow all outbound connections from the internal network but to block all incoming traffic. So a user on the internal network would be able to download e-mail without a problem, but an administrator would need to customize the router configuration to allow users to connect to their work computers from their homes by using Remote Desktop.

You use packet filters to instruct a firewall to drop traffic that meets certain criteria. For example, you could create a filter that would drop all ping requests. You can also configure filters with more complex exceptions to a rule. For example, a filter might assist with troubleshooting the firewall by allowing the firewall to respond to ping requests coming from a monitoring station’s IP address. By default, ISA Server doesn’t respond to ping queries on its external interface. You would need to create a packet filter on the ISA Server computer for it to respond to a ping request.

The following are the main TCP/IP attributes used in implementing filtering rules:

• Source IP addresses

• Destination IP addresses

• IP protocol

• Source TCP and UDP ports

• Destination TCP and UDP ports

• The interface to which the packet arrives

• The interface to which the packet is destined

If you’ve configured the firewall to allow all traffic by default, you can use filters to block specific traffic. If you’ve configured the firewall to deny all traffic, filters allow only specific traffic through. A common packet-filtering configuration is to allow inbound DNS requests from the public Internet so that a DNS service can respond.

Some types of firewalls (but not ICF) can filter traffic based on source or destination IP address. Filtering based on source or destination address is useful because it enables you to allow or deny traffic based on the computers or networks that are sending or receiving the traffic. This enables firewalls to allow or deny traffic based on the computer sending the request. This allows administrators to disable instant messaging from the computer in one organization, while allowing the same protocol from a different set of computers.

Source filtering also allows you to give greater access to users on internal networks than to those on external networks. It’s common to use a firewall to block all requests sent to an internal e-mail server except for those requests from users on the internal network. You can also use source filtering to block all requests from a specific address, for example, to block traffic from an IP address identified as having attacked the network.

Advanced firewall features

Packet filtering based on IP address and port number is a fundamental feature of even the most basic firewalls. More advanced firewalls include features such as stateful packet inspection, application layer intelligence, intrusion detection, and VPN.

Stateful inspection is the process of inspecting packets as they reach the firewall and maintaining the state of the connection by allowing or disallowing packets to pass based on the access policy. Firewalls that lack support for stateful inspection simply forward any packets that are marked as participating in an existing connection. This can allow an attacker to send packets through a firewall, but it doesn’t necessarily allow the attacker to establish a connection with a system on the internal network. ICF supports stateful inspection.

Note 

Proxy servers and firewalls that support Network Address Translation (NAT) always provide stateful inspection.

Application layer firewalls can analyze the data within the traffic flowing through them and allow or deny traffic based on the content. For example, an application layer firewall positioned in front of a Web server could check each page that a user requests and determine whether that user is allowed to request that particular page from the Web server. While this type of filtering could also be done on the Web server itself, performing the filtering in a firewall provides an additional layer of protection.

Firewalls that include intrusion detection capabilities search through traffic and look for telltale signs of an attack taking place. They can then respond in real time by notifying an administrator, blocking access from the attacker’s network, or issuing a counterattack. Intrusion detection is also useful because it includes extensive logging, which might be useful when identifying or prosecuting an attacker.

Firewalls with VPN capabilities simplify remote access and can allow remote networks to connect to each other across the Internet. While VPN capabilities are built into Windows Server 2003, relying on a separate firewall for VPN functions reduces the load on your server. Additionally, combining VPN and firewall functionality allows the firewall to perform filtering and analysis on traffic contained within the encrypted VPN tunnel.

See Also 

For more information on VPNs, refer to Chapter 8, “Planning and Configuring IPSec,” and Chapter 9, “Deploying and Troubleshooting IPSec.”

Perimeter Networks

Most organizations use their Internet connection to make one or more services available to the public Internet. At a minimum, Simple Mail Transfer Protocol (SMTP) services are exposed to allow inbound e-mail. You can use filtering and port forwarding to allow this traffic through a firewall, but many organizations require a perimeter network, also known as a demilitarized zone (DMZ). The purpose of a perimeter network is to offer a layer of protection for the internal network in the event that one of the servers on the perimeter network is compromised.

To provide protection, the perimeter network is made up of:

• A firewall that protects the front-end servers from Internet traffic.

• A set of “security-hardened” servers that support the services the application provides. You set up these servers so that dangerous Internet services, such as file sharing and Telnet, are disabled.

• A firewall that separates the back-end servers from the corporate networks and enables communication between the back-end servers and a few servers within the corporate network.

Figure 4.3 shows a network with the Web, e-mail, and DNS servers placed in a single- layer perimeter network separate from the internal network.

Figure 4.3: Services placed in a single-layer perimeter network

A perimeter network is an important element for securing a site. You need to take additional security measures to protect data that the back-end servers store. You can also store extremely sensitive data or data that’s needed elsewhere in your enterprise outside the perimeter network, although doing so has negative performance implications and runs the risk, however small, of opening your corporate network to an attacker.

A multilayer perimeter network consists of front-end servers, back-end servers, and firewalls. The firewalls protect the front-end servers from the public network and filter traffic between the corporate network and the back-end servers. A perimeter network provides a multilayer protection system between the Internet and the internal network of an organization.

Security for DHCP Servers

Dynamic Host Configuration Protocol (DHCP) is an IP standard designed to reduce the complexity of administering address configurations. DHCP servers enable an administrator to assign TCP/IP configurations to client computers automatically upon startup. When a client computer moves between subnets, its old IP address is freed for reuse. The client reconfigures its TCP/IP settings automatically when the computer is restarted in its new location.

Note 

Packet filtering isn’t much of a concern with DHCP servers, since DHCP requests are broadcast messages and don’t cross a router unless specifically configured to do so.

Configuring the DHCP Server role

You can install DHCP by clicking Add/Remove Windows Components in the Add Or Remove Programs dialog box, clicking Networking Services, clicking the Details button, and then selecting Dynamic Host Configuration Protocol. However, the simplest way to install and configure DHCP is to install the DHCP Server role by using the Manage Your Server window:

1. Click Start, and then click Manage Your Server.

2. Click Add Or Remove A Role. The Configure Your Server Wizard appears.

3. Click Next, click DHCP Server, and then click Next twice. The New Scope Wizard appears.

4. Click Next, and follow the wizard prompts to configure your DHCP scope.

Authorizing DHCP servers

Although the role of a DHCP infrastructure server might seem mundane, a DHCP server can actually be used maliciously to compromise the security of DHCP client computers. DHCP clients trust the DHCP server that assigns an IP address to provide them with information about the default gateway and DNS servers. An attacker could place a DHCP server on a network segment and replace the default gateway and DNS server information with the IP addresses of computers owned by the attacker. These computers could then intercept all traffic from the client, allowing the traffic to be analyzed for confidential information and enabling man-in-the-middle attacks.

Physical and network security is the only way to ensure that an attacker does not place a rogue DHCP server on your network. However, Windows Server 2003 can limit the risk of a user unintentionally starting a Windows-based DHCP server on your network, which could result in DHCP clients getting incorrect address information and not being able to access network resources. Active Directory contains a list of IP addresses available for the computers that you authorize to operate as DHCP servers on your network, and supports detection of unauthorized DHCP servers and prevention of their starting or running on your network.

Security Alert 

Microsoft Windows NT 4.0 and earlier Windows operating systems do not check for DHCP server authorization.

To authorize a computer as a DHCP server, first log on as an enterprise administrator. Then launch the DHCP console, right-click the server, and click Authorize. When a DHCP server is authorized, the server computer is added to the list of authorized DHCP servers maintained in the directory service database. You can verify that a server has been authorized by right-clicking the DHCP node in the DHCP console and clicking Manage Authorized Servers. The Manage Authorized Servers dialog box appears, as shown in Figure 4.4.

Figure 4.4: Managing authorized DHCP servers

A DHCP server running Windows Server 2003 uses the following process to determine whether Active Directory is available. If an Active Directory domain is found, the server validates its own authorization by following one of the procedures presented below, depending on whether it is a member server or a standalone server:

For member servers (a server joined to a domain that is part of an enterprise), the DHCP server queries Active Directory for the list of authorized DHCP server IP addresses. If the server finds its IP address in the authorized list, it initializes and starts providing DHCP service to clients. If it does not find itself in the authorized list, it does not initialize and stops providing DHCP services. When installed in a multiple forest environment, DHCP servers seek authorization from within their forest only. After being authorized, DHCP servers in a multiple forest environment lease IP addresses to all reachable clients. Therefore, if clients from another forest are reached using routers with DHCP/BOOTP forwarding enabled, the DHCP server leases IP addresses to them. If Active Directory is not available, the DHCP server continues to operate in its last known state.

For standalone servers (a server not joined to any domain or part of an existing enterprise), when the DHCP service starts, it sends a DHCP information message (DHCPINFORM). This message includes several vendor-specific option types that are known and supported by other DHCP servers running Windows Server 2003. When received by other DHCP servers, these option types enable the query and retrieval of information about the root domain. When queried, the other DHCP servers reply with DHCP acknowledgement messages (DHCPACK). If the standalone server receives no reply, it initializes and starts providing DHCP services to clients. If the standalone server receives a reply from a DHCP server that is authorized in Active Directory, the standalone server does not initialize and does not provide DHCP services to clients.

Authorized servers repeat the detection process at a default interval of 60 minutes. Unauthorized servers repeat the detection process at a default interval of 10 minutes. Efforts to detect unauthorized servers are noted as “Restarting rogue detection” entries in the audit log.

Dynamic DNS updates

DHCP and DNS are closely related, because you can configure the DHCP server to perform updates on behalf of its DHCP clients to any DNS servers that support dynamic updates. This is an important concept to understand for security reasons, because network services such as IIS might use DNS when authorizing requests. Additionally, network services that create usage or auditing log files might store DNS information about clients. Therefore, having DNS information for every computer on the network increases your network security by enabling you to more easily trace IP communications back to the correct computer.

The DHCP server can be used to register and update the pointer (PTR) and host (A) resource records on behalf of its DHCP-enabled clients. The PTR record resolves the client’s IP address to its hostname, and the A record resolves the fully qualified domain name (FQDN) to the IP address. Although end-users rely on A records to find services on the network, PTR records are more useful for security-related tasks such as filtering incoming requests based on the client’s domain name.

By default, Windows Server 2003 registers and updates client information with the authoritative DNS server of the zone in which the DHCP server is located according to the DHCP client request. In this mode, the DHCP client can request the manner in which the DHCP server performs updates of its host (A) and pointer (PTR) resource records. If possible, the DHCP server accommodates the client request for handling updates to its name and IP address information in DNS. This is the default setting, but it can lead to DHCP clients not having DNS records updated, because the client is trusted to register its own DNS records. To select this setting, view the properties of the DHCP server or a DHCP scope. Click the DNS tab, and select the Dynamically Update DNS A And PTR Records Only If Requested By The DHCP Clients check box.

To configure the DHCP server to always update the DNS records for a client, view the properties of the DHCP server or a DHCP scope, click the DNS tab, and select the Always Dynamically Update DNS A And PTR Records check box. In this mode, the DHCP server always performs updates of the client’s FQDN, leased IP address information, and both its A and PTR resource records, regardless of whether the client has requested to perform its own updates. If you prefer to trust the clients to update their own DNS records, you can clear the Enable DNS Dynamic Updates According To The Settings Below check box.

Although all recent versions of Windows are capable of registering their own DNS records, including Windows 2000, Windows XP, and Windows Server 2003, earlier versions of Windows such as Windows 98 do not have this capability. Configure the DHCP server to register DNS records on behalf of these clients by selecting the Dynamically Update DNS A And PTR Records For DHCP Clients That Do Not Request Updates check box, as shown in Figure 4.5.

Figure 4.5: DHCP dynamic update options

Security Alert 

Although being able to look up the PTR record registered to a particular IP address can be useful when tracking down the source of a request, it’s hardly a reliable tool when attempting to identify an attacker. An attacker would either use an IP address without registering with the DHCP server or would spoof another user’s IP.

Known DHCP server security risks

The DHCP protocol itself, an open Internet standard, has several known security vulnerabilities. First, DHCP is an unauthenticated protocol. When a user connects to the network, the user is not required to provide credentials to obtain a lease. An unauthenticated user can, therefore, obtain a lease for any DHCP client whenever a DHCP server is available to provide a lease. Any option values that the DHCP server provides with the lease, such as Windows Internet Naming Service (WINS) server or DNS server IP addresses, are available to the unauthenticated user. If the DHCP client is identified as a member of a user class or vendor class, the options that are associated with the class are also available.

Malicious users with physical access to the DHCP-enabled network can instigate denial-of-service attacks on DHCP servers by requesting many leases from the server, thereby depleting the number of leases that are available to other DHCP clients. Additionally, such a denial-of-service attack can also impact the DNS server when the DHCP server is configured to perform DNS dynamic updates.

Tip 

When clients running Windows XP use 802.1X-enabled LAN switches or wireless access points to access a network, authentication occurs before the DHCP server assigns a lease, thereby providing greater security for DHCP.

To mitigate these risks, ensure that unauthorized persons do not have physical or wireless access to your network, and enable audit logging for every DHCP server on your network, as described in the next section. Configure DHCP servers in pairs, splitting DHCP server scopes between servers so that 80 percent of the addresses are distributed by one DHCP server and 20 percent by another to ensure that clients can continue receiving IP address configurations in the event of a server failure.

Logging considerations

Enable audit logging for every DHCP server on your network. Regularly check audit log files and monitor them when the DHCP server receives an unusually high number of lease requests from clients. Audit log files provide the information that you need to track the source of any attacks made against the DHCP server. The default location of audit log files is %systemroot%\system32\dhcp. You can also check the system event log for explanatory information about the DHCP Server service.

By default, the DHCP service only logs startup and shutdown events in the Event Viewer. A more detailed log can be enabled on the DHCP server by following these steps:

1. Start the DHCP console, right-click the DHCP server, and then click Properties.

2. Click the General tab, and then select Enable DHCP Audit Logging.

Use the DHCP audit logs to monitor DNS dynamic updates by the DHCP server. The Event ID 30 represents a dynamic update to a DNS server. Event ID 31 means that the dynamic update failed, and Event ID 32 means the update was successful. The IP address of the DHCP client is included in the DHCP audit log, providing the ability to track the source of the denial-of-service attack.

DHCP clients are often difficult to locate in log entries because the only information that is stored in most event logs is computer names, not IP addresses. The DHCP audit logs can provide one more tool for locating the sources of internal attacks or inadvertent activities. However, the information in these logs is not by any means foolproof, since both host names and media access control (MAC) addresses can be forged or spoofed. (Spoofing is the practice of making a transmission appear to come from a user other than the user who performed the action.) Nevertheless, the benefits of collecting this information by far exceed the costs incurred by enabling logging on a DHCP server. Having more than just an IP address and a machine name can be of great assistance in determining how a particular IP address was used on a network.

By default, Server Operators and Authenticated Users have read permissions to these log files. To best preserve the integrity of the information logged by a DHCP server, it is recommended that access to these logs be limited to server administrators. The Server Operators and Authenticated Users groups should be removed from the ACL of the %systemroot%\system32\dhcp folder.

Security for DNS Servers

DNS is the TCP/IP name resolution service that is used on the Internet. The DNS service enables client computers on your network to register and resolve user-friendly DNS names. It also allows network services to resolve IP addresses to host names, a common, but unreliable, method of filtering requests. Most network applications rely on DNS, and, as a result, a successful attack against DNS can have serious consequences.

Configuring the DNS Server role

You can install DNS by clicking Add/Remove Windows Components in the Add Or Remove Programs dialog box, clicking Networking Services, clicking the Details button, and then selecting Domain Name System. However, the simplest way to install and configure DNS is to install the DNS Server role by using the Manage Your Server window. To install the DNS Server role:

1. Click Start, and then click Manage Your Server.

2. Click Add Or Remove A Role. The Configure Your Server Wizard appears.

3. Click Next, click DNS Server, and then click Next again. Follow the prompts to configure the new role.

Securing DNS servers

If a DNS zone is not stored in Active Directory, secure the DNS zone file by modifying permissions on the DNS zone file or on the folder in which the zone files are stored. The zone file or folder permissions should be configured to allow Full Control only to the System group. By default, zone files are stored in the %systemroot%\System32\Dns folder. Also secure the DNS registry keys. The DNS registry keys can be found in the registry under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS.

On DNS servers that do not respond to DNS clients directly and are not configured with forwarders, disable recursion. A DNS server requires recursion only if it responds to recursive queries from DNS clients or is configured with a forwarder. The DNS server will use iterative queries to communicate with other DNS servers. To disable recursion:

1. Open the DNS console.

2. In the console tree, right-click the applicable DNS server, and then click Properties.

3. Click the Advanced tab.

4. Under Server Options, select the Disable Recursion check box, and then click OK.

If your DNS server will not be resolving Internet names for clients, configure the root hints to only point to the DNS servers hosting your root domain. By default, the root hints contain a list of Internet DNS servers to enable any public domain names to be resolved. To update root hints on the DNS server:

1. Open the DNS console.

2. On the Action menu, click Properties.

3. Click the Root Hints tab.

4. Modify server root hints as follows:

   • To add a root server to the list, click Add, and then specify the name and IP address of the server to be added to the list.

   • To modify a root server in the list, click Edit, and then specify the name and IP address of the server to be modified in the list.

   • To remove a root server from the list, select it in the list, and then click Remove.

   • To copy root hints from a DNS server, click Copy From Server, and then specify the IP address of the DNS server from which you want to copy a list of root servers to use in resolving queries. These root hints will not overwrite any existing root hints.

Security considerations for Active Directory–integrated DNS

Safeguarding DNS servers is essential to any environment with Active Directory because clients use DNS to find their Active Directory servers. When a DNS server is attacked, one possible goal of the attacker is to control the DNS information being returned in response to DNS client queries. In this way, clients can be misdirected to computers controlled by the attacker. Cache poisoning is an example of this type of attack. To use cache poisoning in an attack, an attacker inserts false information into the cache of a DNS server. This results in a legitimate DNS server returning incorrect results, thereby redirecting clients to unauthorized computers.

The Windows Server 2003 DNS client service supports Dynamic DNS updates, which allow client systems to add DNS records directly into the database. Dynamic DNS (DDNS) servers can receive malicious or unauthorized updates from an attacker using a client that supports the DDNS protocol if the server is configured to accept unsecured updates. At a minimum, an attacker can add bogus entries to the DNS database; at worst, the attacker can overwrite or delete legitimate entries in the DNS database. Using secure DDNS updates guarantees that registration requests are processed only if they are sent from valid clients in an Active Directory forest. This greatly limits the opportunity for an attacker to compromise the integrity of a DNS server.

DNS servers provide a mechanism called a zone transfer to replicate information about a DNS zone between servers. A DNS server that is not configured to limit who can request zone transfers will transfer the entire DNS zone to anyone who requests it. Unfortunately, this can make the entire domain’s DNS dataset available, including which hosts are serving as domain controllers, Web servers, and databases.

Logging considerations

The DNS service generates logging information that is useful for determining whether an attack occurred and how it was carried out. DNS logging is enabled by default and can be modified from the Event Logging tab of the DNS server properties dialog box. To view the DNS server logs, open the DNS console, expand Event Viewer, and then click DNS Events. DNS events will appear in the right pane. Alternatively, you can view DNS events by using the standard Event Viewer console.

Protecting DNS servers with firewalls

As this section has made clear, a great deal of damage can be done to an organization if a DNS server is compromised. To mitigate this risk, limit access to your DNS server to only those clients that should be making DNS requests. Use packet filtering to block all traffic from DNS clients, except for packets transmitted by means of UDP or TCP port 53. If you plan to receive DNS requests from the public Internet, you will have to allow requests on UDP and TCP port 53 from all addresses. However, you should use packet filtering to block all other traffic destined to your DNS servers from the public Internet.

Security for Domain Controllers

Domain controllers are responsible for authenticating users on your network. In essence, they hold the keys to the kingdom. If an attacker compromises a domain controller, the attacker can use the information contained in Active Directory to map out network resources and might be able to use the information to access those resources.

See Also 

For information on controlling authorization for Active Directory objects, refer to Chapter 2, “Planning and Configuring an Authorization Strategy.”

Configuring the Domain Controller role

The simplest way to install and configure Active Directory on a server is to install the domain controller role by using the Manage Your Server window. To install the domain controller role:

1. Click Start, and then click Manage Your Server.

2. Click Add Or Remove A Role. The Configure Your Server Wizard appears.

3. Click Next, click Domain Controller, and then click Next again. Follow the prompts to configure the new role.

The Active Directory database

Safeguarding the Active Directory database and log files is crucial to maintaining directory integrity and reliability. Moving the Ntds.dit, Edb.log, and Temp.edb files from their default locations will help to conceal them from an attacker if a domain controller is compromised. Furthermore, moving the files off the system volume to a separate physical disk will also improve domain controller performance.

If an attacker does gain access to a domain controller, it is likely that the attacker will attempt to discover user credentials by using password-cracking software. The System Key utility (Syskey) provides an extra line of defense against offline password-cracking software by using strong encryption techniques to secure account password information. By default, Syskey is enabled on all computers running Windows Server 2003 in Mode 1 (obfuscated key). There are many reasons to recommend using Syskey in Mode 2 (console password) or Mode 3 (floppy storage of Syskey password) for any domain controller that is exposed to physical security threats.

To create or update a system key:

1. Click Start, click Run, type syskey, and then click OK.

2. Click Encryption Enabled, and then click Update.

3. Click the desired option, and then click OK.

Logging considerations

Like DNS servers, Active Directory servers add event logs that can be viewed by using the Event Viewer console. Besides the DNS Server log, adding the Domain Controller role adds the Directory Service and File Replication Service roles. To ensure that these log files can store an adequate amount of information, consider increasing the maximum size of the log files. If you discover that you were attacked days, weeks, or months in the past, having a sufficiently large event log will allow you to review the logs from the period of the attack. Increasing the size of the Directory Service and File Replication Service log files from the 512-kilobyte (KB) default to 16 megabytes (MB) is generally sufficient.

Protecting domain controllers with firewalls

You should use a firewall to limit the opportunity an attacker has to connect to your domain controllers. Use packet filtering to block all unnecessary traffic to and from your domain controllers. Domain controllers use several different protocols for communicating with clients and peers. Whenever possible, limit the communication so that only the necessary ports are opened between a domain controller and another computer. Table 4.1 shows common domain controller communications and the port numbers used.

Table 4.1: Ports Used by Active Directory

Active Directory communication	Traffic required
A user network logon across a firewall	Microsoft-DS traffic (445/tcp, 445/udp) Kerberos authentication protocol (88/tcp, 88/udp) Lightweight Directory Access Protocol (LDAP) ping (389/udp) DNS (53/tcp, 53/udp)
A computer logon to a domain controller	Microsoft-DS traffic (445/tcp, 445/udp) Kerberos authentication protocol (88/tcp, 88/udp) LDAP ping (389/udp) DNS (53/tcp, 53/udp)
Establishing a trust between domain controllers in different domains	Microsoft-DS traffic (445/tcp, 445/udp) LDAP (389/tcp or 686/tcp if using SSL) LDAP ping (389/udp) Kerberos authentication protocol (88/tcp, 88/udp) DNS (53/tcp, 53/udp)
Trust validation between two domain controllers	Microsoft-DS traffic (445/tcp, 445/udp) LDAP (389/tcp or 686/tcp if using SSL) LDAP ping (389/udp) Kerberos (88/tcp, 88/udp) DNS (53/tcp, 53/udp) Netlogon

Security for Internet Information Services

Internet Information Services (IIS) 6.0 is a complete Web server available in all versions of Windows Server 2003. Designed for intranets, the Internet, and extranets, IIS 6.0 makes it possible for organizations of all sizes to quickly and easily deploy powerful Web sites, applications, and Web services. In addition, IIS 6.0 provides a high-performance platform for applications built using the Microsoft .NET Framework.

See Also 

Controlling access to Web content in IIS is done by using restrictive file permissions. For information about restricting file permissions, refer to Chapter 2, “Planning and Configuring an Authorization Strategy.”

Changes since Windows 2000

Earlier versions of IIS have been popular security targets, and vulnerabilities in IIS have caused many Windows computers to be compromised. In order to reduce the Web infrastructure attack surface, IIS 6.0 is not installed by default on Windows Server 2003. You must explicitly select and install IIS 6.0 on all members of the Windows Server 2003 family, except for Windows Server 2003, Web Edition. This means that now it does not need to be uninstalled after Windows has been installed. IIS 6.0 will also be disabled when a server is being upgraded to Windows Server 2003, unless the IIS 5.0 Lockdown Tool has been installed prior to upgrade, or unless a registry key has been configured. If IIS isn’t being used, you should explicitly disable it by using Group Policy settings.

IIS 6.0 is configured in a locked-down state when installed. After installation, IIS 6.0 accepts requests for only static files until configured to serve dynamic content, and all time-outs and settings are set to aggressively secure defaults. Programmatic functionality provided by Internet Server API (ISAPI) extensions or Common Gateway Interfaces (CGI) must be manually enabled by an IIS 6.0 administrator. ISAPI and CGI extend the functionality of your Web pages, and for this reason they are referred to as Web service extensions. For example, to run Active Server Pages (ASP) with this version of IIS 6.0, the ISAPI that implements ASP.dll must be specifically enabled as a Web service extension. Microsoft FrontPage Server extensions and Microsoft ASP.NET also have to be enabled before their functionality will work. Using the Web Service Extensions feature, Web site administrators can enable or disable IIS 6.0 functionality based on the individual needs of the organization. This functionality is globally enforced across the entire server. IIS 6.0 provides programmatic, command-line, and graphical interfaces for enabling Web service extensions.

By default, IIS 6.0 worker processes, which run Web service extensions, run as a Network Service account. The Network Service account is a new built-in account with exactly seven privileges:

• Adjust memory quotas for a process.

• Generate security audits.

• Log on as a service.

• Replace process-level token.

• Impersonate a client after authentication.

• Allow logon locally.

• Access this computer from the network.

Running as a low-privileged account is one of the most important security principles. The ability to exploit a security vulnerability can be contained effectively if the worker process has very few rights on the underlying system. Administrators can configure the application pool to run as any account (Network Service, Local System, Local Service, or a configured account) if desired.

See Also 

For information about IIS authentication options, refer to Chapter 1, “Planning and Configuring an Authentication Strategy.”

Configuring the Application Server role

You can install IIS by using Add/Remove Windows Components and installing the Application Server component. However, the simplest way to install and configure the security settings for IIS is to install the Application Server role from the Manage Your Server window. Application Server is a new server role for Windows Server 2003 that combines IIS 6.0, the .NET Framework, ASP.NET, ASP, Universal Description Discovery and Integration (UDDI) Services, COM+, and Microsoft Message Queuing (MSMQ). To install the Application Server role:

1. Click Start, and then click Manage Your Server.

2. Click Add Or Remove A Role. The Configure Your Server Wizard appears.

3. Click Next, click Application Server, and then click Next again.

4. The Application Server Options page appears. As shown in Figure 4.6, you can choose to install the FrontPage Server Extensions and ASP.NET support. Select either option only if you have already determined that the option is required by your application. Both options carry the risk of introducing additional security vulnerabilities. You can always enable the options later if you need to. Click Next.

   
   Figure 4.6: Configuring Application Server options

5. On the Summary page, click Next.

6. After Windows Server 2003 configures the Application Server role, click Finish.

IIS subcomponents

When using the Add/Remove Windows Components tool, you have a great deal of control over which IIS subcomponents will be installed. Understanding which of these components is required for your application to function is critical. Without a necessary component, parts of a Web application will simply not work. If unnecessary components are enabled, you are exposing the server to unnecessary risk. Table 4.2 describes the available IIS subcomponents and lists whether each component is automatically installed when you add the Application Server role.

Table 4.2: IIS Subcomponent Roles

Subcomponent	Description	Default setting
Background Intelligent Transfer Service (BITS) server extension	A background file transfer mechanism used by Windows Update and Automatic Update. This component is required when Windows updates or automatic updates are used to automatically apply service packs and hotfixes to an IIS server.	Disabled
Common Files	Files required by IIS. They must always be enabled on IIS servers.	Enabled
File Transfer Protocol (FTP) Service	Allows IIS servers to provide FTP services. This service is not required for dedicated IIS servers.	Disabled
FrontPage 2002 Server Extensions	Provides FrontPage support for administering and publishing Web sites. Disable on dedicated IIS servers when no Web sites use FrontPage extensions.	Disabled
Internet Information Services Manager	Administrative interface for IIS.	Enabled
Internet Printing	Provides Web-based printer management and allows printers to be shared over HTTP. This is not required on dedicated IIS servers.	Disabled
NNTP Service	Distributes, queries, retrieves, and posts Usenet news articles on the Internet. This component is not required on dedicated IIS servers.	Disabled
SMTP Service	Supports the transfer of e-mail. This component is not required on dedicated IIS servers.	Disabled
World Wide Web Service	Provides Web services and static and dynamic content to clients. This component is required on dedicated IIS servers.	Enabled

IP address and domain name restrictions

IIS can deny or allow incoming requests based on the source IP address, the network from which the request originated, or the source IP address’s domain name. Although these techniques can be used for increasing the Web site’s security, they are hardly impenetrable. Source IP addresses can be spoofed, and domain name lookups are only as secure as the DNS server hosting the reverse lookup domain. Nonetheless, they can be useful as part of a layered security strategy when used in conjunction with other security mechanisms.

To configure IP address and domain name restrictions for IIS:

1. Open the Internet Information Services Manager.

2. Right-click the Web site and click Properties.

3. Click the Directory Security tab.

4. Under IP Address And Domain Name Restrictions, click Edit.

5. To list IP addresses and domains that will be allowed and deny all other requests, click Denied Access. To list only those IP addresses and domains that should be ignored, click Granted Access.

6. Click the Add button.

7. Click Single Computer, Group Of Computers, or Domain Name. Provide the IP address, network ID and subnet mask, or domain name, and then click OK. Figure 4.7 demonstrates how to filter requests for the private network 192.168.1.0.

   
   Figure 4.7: Filtering IIS requests by network

8. Repeat step 7 for each filter required.

9. Click OK twice to return to the Internet Information Services Manager.

If you restrict access by domain name, IIS has to perform a reverse DNS lookup for every new source IP address that sends a request. This slows down the responsiveness of the first page, which will probably upset your Webmaster. Additionally, if you have a busy site, all those DNS requests can really bog your DNS server.

Logging considerations

By default, IIS logs information about each incoming request to a text-based log file located within %systemroot%\System32\LogFiles\W3SVCx. These log files are completely separate from the logs viewable in Event Viewer. Each Web site creates a separate log file that includes information such as the source IP address, the number of bytes sent and received, the user name (if provided by the browser), and the type of browser used to make the request. Following is an example of a single log entry created when the Administrator user requested the page /autoupdate/administration/default.asp:

2003-07-28 13:38:34 127.0.0.1 GET /autoupdate/administration/default.asp   80 DOMAIN1\Administrator 127.0.0.1 Mozilla/ 4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+.NET+CLR+1.1.4322) 200 0 0

The information in this log file is primarily intended for nonsecurity-related analysis of Web site traffic. For example, members of the marketing team could use this information to determine which partner Web site was directing the highest number of users to the site. You should be familiar with IIS log files, however, because Web sites are a frequent point of entry for attackers, and analyzing IIS log files can reveal that you were attacked by a malicious user, the method the attacker used, and information about the attacker’s identity.

Real World

If you host a public Web site, you are going to get attacked. In fact, you are probably going to get attacked dozens of times per day. There are thousands of systems infected with worms that perform automated attacks against random Web servers, and many of those worms are specifically seeking out earlier, non- updated versions of IIS. Because of this, you should regularly review your IIS logs. If you don’t have software specifically designed to analyze IIS logs and notify you about attacks, you can manually browse through the log files looking for unusual patterns. Look for requests for files that don’t exist and requests that repeat on a regular basis.

If you discovered that someone had been coming to your home and trying to enter your house several times a day, you’d probably call the police. On the Internet, though, there are far too many attacks to notify the authorities about every single one. If and when you do find traces of a Web-based attack, you don’t need to panic. First, examine the requests from that user’s IP address to determine whether the attack originated from a worm. If it did, just make sure your system isn’t vulnerable to attacks from that worm, and continue on with your day. You’ll never be able to chase down every worm-infected host on the Internet.

If you determine that an attack originated from an actual attacker targeting your computer systems, such as an ex-employee or a competitor, you should follow up on the attack. If you decide that the attacker should be punished, you should report the attack to an appropriate law enforcement agency. The Department of Justice’s How to Report Internet-Related Crime page is a useful reference, located at http://www.cybercrime.gov/reporting.htm.

If an attack is not serious enough to report to law enforcement, but you’d like to report it to the user’s Internet service provider (ISP), find the user’s IP address in the IIS log file and look it up at http://whois.arin.net. The American Registry for Internet Numbers (ARIN) site will tell you the ISP or organization that owns that IP address range, and usually provides an e-mail address and phone number for reporting abuse. It’s up to the ISP whether, and how, they will deal with your complaint. They might choose to send the user a warning letter, ban the user completely, or simply do nothing.

IIS usage log information can also be sent directly to a database. This is useful if you manage multiple Web servers. Additionally, this improves the security of the log files. If an attacker compromises your Web server, the attacker will have to gain access to a second system, the database server, in order to erase traces of the attack present in the log file. Furthermore, logs can be written to a remote share over a network using a full Universal Naming Convention (UNC) path. Remote logging allows for administrators to set up centralized log file storage and backup. However, writing the log file over the network could negatively impact server performance.

Note 

IIS 6.0 creates a %systemroot%\System32\LogFiles\Httperr folder for log files with information about application errors. However, it is unlikely to be used for the purpose of identifying security incidents.

SSL encryption

Though IPSec can be configured to encrypt almost any type of network communication, IIS supports Hypertext Transfer Protocol Secure (HTTPS), an extension to HTTP that provides encryption by using a Secure Sockets Layer (SSL) certificate. If you host your own certification authority, you can create your own SSL certificate. However, if your certification authority is not a public authority that is trusted by your visitors’ Web browsers, visitors will receive a warning message that your certificate is not from a trusted authority. To avoid this warning message, purchase an SSL certificate from a certification authority that is trusted by default by popular Web browsers.

To configure an IIS Web site with an SSL certificate:

1. Open the IIS Manager.

2. Right-click the Web site and click Properties.

3. Click the Directory Security tab.

4. Click Server Certificate.

   The Web Server Certificate Wizard appears.

5. Click Next.

6. Follow the prompts to create or import the SSL certificate for this site. When the wizard completes, click Finish.

See Also 

For more information about SSL certificates, refer to Chapter 11, “Deploying, Configuring, and Managing SSL Certificates.”

Web site permissions

Although file permissions are used to restrict which users can access particular files, IIS uses Web site permissions to determine what HTTP actions can occur within a Web site, such as allowing script source access or directory browsing. Unlike file permissions, Web site permissions can be defined for Web sites or directories, but they cannot apply to individual files. Additionally, Web site permissions apply to all users who access the site.

Use the Internet Information Services Manager to specify Web site permissions. Valid choices are:

• Read. Users can view the content and properties of directories or files. This permission is selected by default.

• Write. Users can change content and properties of directories or files.

• Script Source Access. Users can access source files. If Read is also enabled, users can read source code; if Write is also enabled, users can change the source code.

• Directory Browsing. When a user requests a directory and a default file does not exist, IIS will generate a list of the directory contents that can be viewed in a browser.

• Log Visits. A log entry is created for each visit to the Web site.

• Index This Resource. Allows Indexing Service to index resources.

• Execute. The following options determine the level of script execution for users:

  • None. Does not allow scripts or executable files to run on the server.

  • Scripts Only. Allows only scripts to run on the server.

  • Scripts And Executables. Allows both scripts and executable files to run on the server.

Protecting IIS with firewalls

Web servers are commonly targeted by attackers, and, as a result, it is common practice to place a firewall between a Web server and end-users. If a simple port-filtering firewall is used, such as the Internet Connection Firewall, you will need to allow traffic using the port numbers you specify for each Web site in IIS Manager. By default, you should allow TCP port 80 for HTTP communications and TCP port 443 for encrypted HTTPS communications.

Application firewalls can provide greater security for IIS than that offered by simple packet-filtering firewalls. ISA and other application firewalls can examine inbound requests to your Web server, and outbound responses to Web clients, and use complex criteria to determine whether the request should be allowed or denied. For example, an application firewall could be configured to drop requests for confidential pages that originate from the public Internet. IIS can be configured similarly, but specifying the rules both within IIS and at the firewall provides a double-layered security combination that remains in place even if the security settings within IIS are changed.

Security for Internet Authentication Service

Internet Authentication Service (IAS) is a mechanism for authenticating users, not unlike Kerberos. IAS is also capable of providing user authorization and accounting for connection times, however. IAS acts as a Remote Authentication Dial-in User Service (RADIUS) server and proxy that provides compatibility with a wide variety of non- Microsoft hardware and software, including wireless routers, authenticating switches, remote access dial-up servers, and VPN connections.

IAS is often used to allow a third-party ISP to authenticate dial-in users against an organization’s Active Directory database. This enables users to dial-in to an ISP by using their Active Directory user names and passwords, even if the ISP doesn’t maintain the Active Directory service. RADIUS, like the Internet protocols Windows Server 2003 supports, is an Internet Engineering Task Force (IETF) standard.

Configuring IAS

IAS cannot be installed by using Manage Your Server. Instead, use Add/Remove Windows Components to install IAS:

1. Open Add Or Remove Programs in Control Panel.

2. Click Add/Remove Windows Components.

3. In the Windows Components Wizard, click Networking Services, and then click Details.

4. In the Networking Services dialog box, select Internet Authentication Service, click OK, and then click Next.

5. After IAS is installed, click Finish.

After IAS is installed, you can configure it by using the Internet Authentication Service console in the Administrative Tools program group.

RADIUS message authenticators

When you configure IAS for a RADIUS client, you configure the IP address of the client. If an incoming RADIUS Access-Request message does not originate from at least one of the IP addresses of configured clients, IAS automatically discards the message, providing protection for an IAS server. However, as discussed earlier, source IP addresses cannot be relied upon for authentication because they can be spoofed.

Shared secrets are used to verify that RADIUS messages, with the exception of Access- Request messages, are sent by a RADIUS-enabled device that is configured with the same shared secret. Shared secrets also verify that the RADIUS message has not been modified in transit (this is known as message integrity). Finally, the shared secret is used to encrypt some RADIUS attributes, such as User-Password and Tunnel-Password. To provide verification for messages, you can enable use of the RADIUS Message Authenticator attribute, as shown in Figure 4.8.

Figure 4.8: Using shared secrets and the Message Authenticator attribute

Note 

If you specify RADIUS clients by using an IP address range, all RADIUS clients within the address range must use the same shared secret.

Account lockout

You can use the remote access account lockout feature to specify how many times a remote access authentication can fail against a valid user account before the user is denied access. Remote access account lockout is especially important for remote access VPN connections over the Internet. An attacker on the Internet can attempt to access an organization intranet by sending credentials (valid user name, guessed password) during the VPN connection authentication process. During a dictionary attack, the attacker sends hundreds or thousands of credentials by using a list of passwords based on common words or phrases.

To enable remote access account lockout, you must set the MaxDenials value in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\ Parameters\AccountLockout registry key to 1 or greater. MaxDenials is the maximum number of failed attempts that can occur before the account is locked out. By default, MaxDenials is set to 0, which means that remote access account lockout is disabled.

To modify the amount of time that passes before the failed attempts counter is reset, you must set the ResetTime (mins) entry in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout registry key to the required number of minutes. By default, ResetTime (mins) is set to 0xb40, or 2,880 minutes (48 hours).

To manually reset a user account that has been locked out before the failed attempts counter is automatically reset, delete the HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout\ domain:user registry key that corresponds to the user’s account name.

Quarantine control

A remote access user provides credentials to demonstrate that he or she is a valid user, which offers some proof that the user is not an attacker. Authenticating a user does not determine whether that user’s computer contains malicious software, such as a Trojan horse, a worm, or a virus. Fortunately, IAS provides quarantine control to help provide a way to determine whether a remote access user’s computer is safe, which can prevent a user from unknowingly spreading worms and viruses into an otherwise secure network.

Network Access Quarantine Control, a new feature in Windows Server 2003, delays normal remote access to a private network until the configuration of the remote access computer has been examined and validated by an administrator-provided script. When a remote access computer initiates a connection to a remote access server, the user is authenticated and the remote access computer is assigned an IP address. However, the connection is placed in quarantine mode, in which network access is limited. The administrator-provided script is run on the remote access computer. When the script notifies the remote access server that it has successfully run, and the remote access computer complies with current network policies, quarantine mode is removed and the remote access computer is granted normal remote access.

The quarantine restrictions placed on individual remote access connections consist of a set of quarantine packet filters that restrict the traffic that can be sent to and from a quarantined remote access client, and a quarantine session timer that restricts the amount of time the client can remain connected in quarantine mode before being disconnected. Tools for configuring and implementing quarantine control are included with the Windows Server 2003 Resource Kit, available from http://www.microsoft.com/windowsserver2003/techinfo/reskit/resourcekit.mspx.

Logging considerations

IAS is capable of logging authentication requests and accounting requests. This information is vital for tracking when users attempt to connect and for identifying successful and unsuccessful attacks. To configure IAS logging:

1. Start the Internet Authentication Service console from the Administrative Tools program group.

2. Click the Remote Access Logging node in the left pane.

3. In the right pane, right-click Local File, and then click Properties.

   The Local File Properties dialog box appears.

4. Select Accounting Requests, Authentication Requests, and/or Periodic Status to enable logging for those items.

When IAS logging is enabled, log files are located by default in the %systemroot%\System32\LogFiles folder. The access control list on the LogFiles folder provides the best security for the IAS log files. The access control list is a list of users and groups that can access the folder. In addition, each user or group is assigned specific permissions that determine what actions the user or group can take with the folder. As with IIS, IAS logging can also be sent to a database server.

Protecting IAS with firewalls

If a firewall is positioned between the IAS server and a client or another IAS server, ports must be opened in the firewall. Authentication traffic uses UDP ports 1645 and 1812. Accounting traffic uses UDP ports 1813 and 1646. The notification and listener components of quarantine control use port 7250 by default. Therefore, you must allow network traffic on port 7250 through the firewall to enable the client computers to communicate with the remote access server listener.

Security for Exchange Server

Many enterprises build their messaging infrastructure on Exchange Server. Exchange provides a scaleable, reliable, Active Directory–integrated messaging platform. Exchange Server 2003 enables users to gain access to critical business communications almost whenever and wherever they need to, and it is designed to deliver greater security, availability, and reliability than other messaging platforms, and even earlier versions of Exchange.

Exam Tip 

Adding members to the Pre-Windows 2000 Compatible Access group always weakens security. For the exam, you should understand the implication for Exchange Server: Members of the Pre-Windows 2000 Compatible Access group can view a member list for mail- enabled groups that would otherwise be hidden.

Exam Tip 

This exam will not require detailed knowledge of Exchange Server. However, you should be familiar with the role Exchange Server and other messaging servers fulfill on the network, understand the potential vulnerabilities associated with this role, and be aware of the tools used to configure security for Exchange Server.

Security Alert 

Exchange Server is not built into Windows Server 2003. Therefore, you cannot rely on Windows Update to deliver security patches. Instead, visit http://www.microsoft.com/exchange/downloads to recieve the latest updates.

Exchange enables users to access their e-mail from a Web browser by connecting to an Outlook Web Access (OWA) server. OWA uses IIS; therefore, you must understand IIS to know how to configure security for OWA. After Exchange Server is installed, you manage it by using the System Manager in the Microsoft Exchange program group.

See Also 

For detailed information on securing Exchange, including security templates, read the Security Operations Guide for Exchange 2000 Server at http://www.microsoft.com/technet/security/prodtech/mailexch/opsguide.

Network encryption

Exchange uses the Transport Layer Security (TLS) protocol, which is based on and interoperable with SSL, to encrypt network communications. SSL is used by IIS and earlier versions of Exchange, including Exchange Server 5.5. To require TLS encryption:

1. Open the System Manager console.

2. Expand the Servers node, expand your server node, expand Protocols, and then expand SMTP.

3. Right-click the virtual server and then click Properties to open the Properties dialog box.

4. Click the Access tab.

5. Click Authentication. Select the Require TLS Encryption check box, as shown in Figure 4.9. Click OK.

   
   Figure 4.9: Exchange TLS encryption

6. Click the Delivery tab, and then click Outbound Security.

7. Select the TLS Encryption check box.

8. Click OK twice to return to System Manager.

Turning on TLS protects messages traveling between mail servers using SMTP but doesn’t protect traffic traveling from clients to the server. To encrypt communications between Web browsers and OWA, enable the use of SSL on the Web server. Post Office Protocol version 3 (POP3) or Internet Message Access Protocol version 4 (IMAP4) users should use a client that supports the use of SSL with POP3 and IMAP4, such as Microsoft Outlook Express. Alternatively, you can use IPSec to encrypt all traffic between clients and servers. IPSec encryption is transparent to both Exchange and the client application.

Logging considerations

Exchange is capable of logging almost every activity that occurs within the messaging server, including detailed information about messages sent to and from the server, by using the Message Tracking Center. While these logging options are essential for troubleshooting messaging problems, they are not likely to be used for security purposes (unless your server is being misused to transfer spam, which does happen).

The built-in auditing capabilities of Exchange are extremely useful for tracking use and misuse, however. Auditing in Exchange is implemented by means of the same mechanisms Windows Server 2003 uses, and auditing events will appear in the event log. To enable auditing in Exchange Server 2003:

1. Start System Manager, and expand the Servers node.

2. Right-click an auditable object, such as an address list, server, or mailbox store, and then click Properties.

3. Click the Security tab, and then click Advanced.

4. Click the Auditing tab.

5. Click the Add button, and then select users for whom you would like to audit actions.

6. The Auditing Entry dialog box appears. Select the auditing you want to enable, and then click OK.

   Notice that the Access list contains messaging-specific options such as Open Mail Send Queue, Send As, and Receive As.

7. Click OK twice to return to System Manager.

After enabling auditing, you can review auditing events in the Security event log by using the Event Viewer console.

Protecting Exchange Server with firewalls

You should use a firewall to stop unnecessary traffic from reaching your Exchange Server computers. Exchange Server computers can use several different protocols for communicating with clients and other mail servers. Whenever possible, limit the communication so that only the necessary ports are opened between an Exchange Server computer and another computer. Table 4.3 shows common domain controller communications and the port numbers used.

Table 4.3: Ports Used by Exchange Server

Network communication	Traffic required
Communications with domain controllers	LDAP standard protocol (389/tcp, 636/tcp if using SSL) Site Replication Service LDAP communications (379/tcp) Global Catalog LDAP communications (3268/tcp, 3269/tcp if using SSL)
Outgoing DNS queries to a DNS server	DNS (53/tcp and 53/udp)
Message transfer between servers	SMTP traffic (25/tcp, 465/tcp if using TLS) SMTP Link State Algorithm (691/tcp)
Client downloading e-mail using POP3	POP3 (110/tcp, 995/tcp if using SSL)
Client downloading e-mail using IMAP4	IMAP4 (143/tcp, 993/tcp if using SSL)
Client using newsreader	NNTP (119/tcp, 563/tcp if using SSL)
Web browsers downloading e-mail from OWA	HTTP protocol (80/tcp, 443/tcp if using SSL)
Clients using instant messaging	RVP (80/tcp and ports above 1024/tcp)
Clients using chat protocol	IRC/IRCX (6667/tcp, 994/tcp if using SSL)

Security for SQL Server

SQL Server is a popular database that acts as a back-end data store for many business applications that will run on Windows Server 2003. After SQL Server is installed, you manage it by using the Enterprise Manager in the Microsoft SQL Server program group.

Exam Tip 

Applications often store confidential information in a SQL Server database, and, as a result, knowing how to harden the security of a SQL Server computer is important both in the real world and for this exam. However, this exam will not require detailed knowledge of SQL Server. There are other certification exams dedicated to SQL Server. You should be familiar with the role SQL Server and other databases fulfill on the network, understand the potential vulnerabilities associated with this role, and be aware of the tools used to configure security for SQL Server.

Security Alert 

SQL Server is not built into Windows Server 2003. Therefore, you cannot rely on Windows Update to deliver security patches. Instead, visit http://www.microsoft.com/sql/downloads to retrieve the latest updates.

Authentication

SQL Server supports two modes of authentication: Windows Authentication Mode and Mixed Mode. Windows Authentication Mode is the default authentication mode in SQL Server 2000. In Windows Authentication Mode, SQL Server 2000 relies solely on the Windows authentication of the user. Windows users or groups are then granted access to the SQL Server database resources.

Whenever possible, you should require Windows Authentication Mode for connections to SQL Server. This simplifies administration, provides single sign-on for users, and enables you to use Windows security enforcement mechanisms such as stronger authentication protocols and mandatory password complexity and expiration. Also, credentials delegation (the ability to bridge credentials across multiple servers) is only available in Windows Authentication Mode. On the client side, Windows Authentication Mode eliminates the need to store passwords, which is a major vulnerability in applications that use standard SQL Server logons.

In Mixed Mode, users can be authenticated by either Windows Authentication or by SQL Server Authentication. Users who are authenticated by SQL Server have their user name and password pairs maintained within SQL Server. If the client accessing the SQL Server database is unable to use a standard Windows logon, SQL Server requires a user name and password pair and compares this pair against those stored in its system tables.

To select an authentication mode by using Enterprise Manager:

1. Start Enterprise Manager.

2. Right-click a server, and then click Properties.

3. Click the Security tab, and then, under Authentication, click Windows Only or SQL Server And Windows, as shown in Figure 4.10.

4. Click OK.

   
   Figure 4.10: Configuring SQL Server authentication

When using Mixed Mode, you must be aware of an account named sa. The sa account in SQL Server is similar to the Administrator account in Windows; it is both highly privileged and built-in. Because it is built into SQL Server, it is the target of many SQL Server attacks. To decrease the risk of being exploited by such an attack, assign a strong password to the sa account. To assign the sa password:

1. Expand a server group, and then expand a server.

2. Expand Security, and then click Logins.

3. In the details pane, right-click SA, and then click Properties.

4. In the Password box, type the new password.

Authorization

SQL Server provides three authorization mechanisms: object permissions, statement permissions, and implicit permissions. Object permissions in SQL Server provide granular control over authorization to databases, tables, and even rows and columns of data contained within tables. You control access to these objects by granting, denying, or revoking the ability to run particular statements or stored procedures. For example, you can grant a user the right to SELECT information from a table, but deny the right to INSERT, UPDATE, or DELETE information in the table.

Note 

SELECT, INSERT, UPDATE, and DELETE are Structured Query Language (SQL) commands.

Statement permissions control administrative actions, such as creating a database or adding objects to a database. Only members of the System Administrators role and database owners can assign statement permissions. By default, normal logons aren’t granted statement permissions, and you must specifically grant these permissions to logons of users that aren’t administrators. For example, if a user needs to be able to create views in a database, you would assign permission to execute CREATE VIEW.

Only members of predefined system roles or database/database object owners can assign implied permissions. Implied permissions for a role can’t be changed or applied to other accounts (unless these accounts are made members of the role). For example, members of the System Administrators server role can perform any activity in SQL Server. They can extend databases and kill processes. You can’t revoke or assign these rights to other accounts individually.

Owners of databases and database objects also have implied permissions. These permissions allow them to perform all activities with either the databases or the objects they own, or with both. For example, a user who owns a table can view, add, change, and delete data. That user can also alter the table’s definition and control the table’s permissions.

Logging considerations

SQL Server includes its own authentication mechanism. To provide auditing of logon attempts for SQL Server logons, SQL Server can be configured to add events to the Application event log. This setting is set from the Security tab of the server properties dialog box. You can choose from four different auditing levels:

• None.No authentication logging is performed.

• Failure.Events are added to the Application event log when a user attempts to authenticate but fails.

• Success.Events are added when a user is successfully authenticated.

• All.Events are added with each authentication attempt, successful or unsuccessful.

Even if you enable authentication auditing to the Application log, you won’t find details in the logs about certain user activities, such as which tables users access, which queries users run, and which stored procedures users invoke. To log details about these kinds of activities, use the Profiler tool, which can be started from within the SQL Server program group. Profiler can be used to create a trace of almost every activity that happens within a SQL Server database, including the exact queries submitted by users, as shown in Figure 4.11. If you believe you are being actively attacked, recording the queries submitted to SQL Server can provide you with a great deal of information about the attacker.

Figure 4.11: SQL Server trace data

Protecting SQL Server with firewalls

SQL Server databases should never be connected to the Internet without at least a packet-filtering firewall in place. Connecting a SQL Server database to even an internal network is risky, because other internal systems might become infected with a worm that could infect a system that accepts incoming database connections. To allow database clients to submit queries to the database server, you must allow packets with a TCP port of 1433 to be passed. However, because of the risk of worms that attempt to connect to this port, you should use a firewall to drop packets that are not from authorized database clients.

Practice: Hardening Servers and Analyzing Traffic

In this practice, you will configure packet filtering for a domain controller and analyze queries submitted to a computer running SQL Server.

Exercise 1: Configure packet filtering

In this exercise, you will configure packet filtering on Computer1 to reduce the network services that can be contacted to those required by the domain controller role.

1. Log on to the cohovineyard.com domain on Computer2 using the Administrator account.

2. Open a command prompt, and execute the command Ping Computer1. You should see four replies from Computer1, demonstrating that Computer1 is listening for and responding to ping requests.

3. Log on to the cohowinery.com domain on Computer1 using the Administrator account.

4. Click Start, click Control Panel, click Network Connections, right-click Local Area Connection, and then click Properties.

5. In the Local Area Connection Properties dialog box, click the Advanced tab.

6. Select the Protect My Computer And Network By Limiting Or Preventing Access To This Computer From The Internet check box.

7. Click the Settings button.

8. In the Advanced Settings dialog box, click Add. Fill in the values in the dialog box with the values in the first row of Table 4.4, and then click OK. Repeat this step for each row in Table 4.4.

   Table 4.4: Active Directory Network Services

   Description of service	Name or IP address	External and internal port number	TCP/UDP
   DNS-TCP	127.0.0.1	53	TCP
   DNS-UDP	127.0.0.1	53	UDP
   Kerberos-TCP	127.0.0.1	88	TCP
   Kerberos-UDP	127.0.0.1	88	UDP
   LDAP-TCP	127.0.0.1	389	TCP
   LDAP-UDP	127.0.0.1	389	UDP
   Microsoft-DS-TCP	127.0.0.1	445	TCP
   Microsoft-DS-UDP	127.0.0.1	445	UDP
   LDAP-SSL-TCP	127.0.0.1	686	TCP

   Note 

   Remember, 127.0.0.1 refers to the local computer.

9. Click OK, and then click OK again to close the Advanced Settings dialog box. Click OK a third time to finalize the changes to the firewall configuration.

10. Return to the command prompt on Computer2, and repeat the Ping Computer1 command. This time, no replies will be returned successfully. Ping uses the Internet Control Message Protocol (ICMP) protocol, which was not enabled when we configured the firewall on Computer1.

11. To ensure that future exercises work correctly on Computer1, disable the firewall. Click Start, click Control Panel, click Network Connections, right-click Local Area Connection, and then click Properties. In the Local Area Connection Properties dialog box, click the Advanced tab. Clear the Protect My Computer And Network By Limiting Or Preventing Access To This Computer From The Internet check box.

Exercise 2: Perform a trace on a SQL Server computer (optional)

In this exercise, you will perform a trace on a SQL Server computer to view the exact queries being submitted by database clients. To perform this exercise, you must have a Windows Server 2003–based computer with SQL Server 2000 installed, and active database clients. Do not perform this exercise on a production system, because performing a trace has a negative performance impact.

1. Log on to the SQL Server computer using an account that has administrator access to the database.

2. Start the SQL Profiler by clicking Start, clicking All Programs, clicking Microsoft SQL Server, and then clicking Profiler.

3. Click the File menu, click New, and then click Trace.

4. In the Connect To SQL Server dialog box, select your authentication method. If your account has administrator access to the database, click Windows Authentication, and then click OK. If you must connect using a SQL Server account, click SQL Server Authentication, provide your logon name and password, and then click OK.

5. In the Trace Properties dialog box, type Security Audit in the Trace Name box. Click Run.

6. Wait for a query to execute. Then, on the File menu, click Pause Trace.

7. Click each event, and examine the event details in the lower pane.

8. After you have familiarized yourself with the level of detail provided by the SQL Profiler tool, close it.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the “Questions and Answers” section at the end of this chapter.

1. Which of the following types of servers should have traffic allowed on UDP port 53? (Choose all that apply.)

   1. DHCP servers

   2. DNS servers

   3. Domain controllers

   4. Web servers

   5. RADIUS servers

   6. Database servers

   7. Messaging servers

2. Which of the following types of servers should have traffic allowed on TCP port 1433?

   1. DHCP servers

   2. DNS servers

   3. Domain controllers

   4. Web servers

   5. RADIUS servers

   6. Database servers

   7. Messaging servers

3. Which of the following types of servers create a dedicated event log that can be viewed by using Event Viewer? (Choose all that apply.)

   1. DHCP servers

   2. DNS servers

   3. Domain controllers

   4. Web servers

   5. RADIUS servers

   6. Database servers

   7. Messaging servers

4. Which of the following protocols can be used to encrypt traffic between a Web browser and an IIS computer?

   1. TLS

   2. EFS

   3. CHAP

   4. SSL

   5. RADIUS

Lesson Summary

• There are two major types of firewalls: host-based firewalls and network firewalls. Host-based firewalls, such as Internet Connection Firewall, protect a single system. Network firewalls, such as Microsoft Internet Security And Acceleration Server, can protect an entire network.

• Perimeter networks are used to provide multiple layers of network security for computers exposed to the public Internet. Internet-facing services such as mail servers and Web servers should be placed on a perimeter network, with a firewall protecting the systems from the Internet and a second firewall protecting the internal network from the perimeter network.

• Server roles that are often connected to the Internet, such as Web servers, DNS servers, and e-mail servers, are frequently subject to attacks. Security configuration is particularly important for these types of infrastructure servers.

• The security of DHCP and DNS servers is closely related because DHCP servers are often relied upon to register DNS names for clients. Both DHCP and DNS servers are vulnerable to denial-of-service attacks because they must accept requests from clients without authentication.

• Domain controllers store a map of the entire network and a complete set of user credentials. As a result, they are frequently the subject of attacks and must be protected at all costs. If a domain controller is compromised, the attacker might be able to gain access to many other resources on the network.

• SQL Server and Exchange Server are not built into Windows Server 2003. Nevertheless, both applications are frequently deployed on Windows Server 2003 networks, and they both often contain a great deal of confidential information. No security initiative is complete unless database and messaging systems have been protected.

---