Threats and Countermeasures
Chapter 11: Additional Countermeasures
This chapter describes how to implement some additional countermeasures, such as securing accounts. This chapter also provides general background, references, and configuration guidance for using IP Security (IPsec) filters as an effective countermeasure against network attacks. On This Page
Member Server Hardening ProceduresAlthough you can apply most of the countermeasures that are discussed in this guide through Group Policy, there are additional settings that are difficult or impossible to apply through Group Policy. The following sections provide guidance about how to implement these additional settings for domain member servers. Securing the AccountsMicrosoft® Windows Server™ 2003 with Service Pack 1 (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. VulnerabilityBy 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. You should rename the built-in Administrator account and alter its description to 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. CountermeasureRename the Administrator account and change the password to a long and complex value on every server. Note: You can rename the built-in Administrator account through Group Policy. The baseline policies that are included with the Windows Server 2003 Security Guide do not implement this setting because every organization should choose a unique name for this account. To rename the account, configure the Rename administrator account setting in Group Policy at the following location: Potential ImpactThe users who manage the computers must keep track of what account name is assigned to each computer. Users who need to log in to a particular server with the local Administrator account will have to refer to this secured documentation to find out what the user name and password is for the server. NTFSThe NTFS setting partitions support access control lists (ACLs) and, optionally, encryption—by means of the Encrypting File System (EFS)—at the file and folder levels. This support is not available with the file allocation table (FAT), FAT32, or FAT32x file systems. FAT32 is a version of the FAT file system that has been updated to permit significantly smaller default cluster sizes and support hard disks of up to two terabytes in size. FAT32 is included in Microsoft Windows® 95 OSR2, Windows 98, Windows Me, Windows Server 2003, and Windows XP. VulnerabilityFiles that you cannot protect with ACLs can be easily viewed, changed or deleted by unauthorized users who can access them locally or over the network. Other files can be protected with ACLs, but encryption provides much more protection and is a viable option for files that only need to be accessible to a single user. CountermeasureFormat all partitions on every server with NTFS. Use the convert utility to non-destructively convert FAT partitions to NTFS, but remember that the utility configures the ACLs for the converted drive to Everyone: Full Control. For Windows Server 2003 and Windows XP–based computers, apply the following security templates locally to configure the default file system ACLs:
Refer to Chapter 12, "The Bastion Host Role," in the Windows Server 2003 Security Guide for instructions about how to apply security templates locally. Note: The default domain controller security settings are applied when a server is promoted to a domain controller. Potential ImpactThere is no negative impact. Important: Proper configuration of NTFS permissions will help protect your organization's data from exposure or unauthorized modifications, but it is critical that you do not forget about physical security. An attacker who has gained physical control of a computer can boot it to an alternate operating system with a bootable CD-ROM or floppy disk. An attacker who has removed a hard disk from one of your organization's computers can move it to a different, unmanaged computer. After the attacker has complete physical control of the storage media, it is very difficult to keep that data secure. This fundamental problem of computer security also exists for the file systems of other operating systems. After an attacker has physical access to the disk, the NTFS permissions—and most other safeguards—can be easily bypassed. Obvious physical security measures your organization can implement include restricted access to buildings, installation of magnetic locks on server rooms, use of locks in server racks, and use of docking station locks for laptop computers. In addition to these security measures, Microsoft recommends the following additional technologies that can help lessen the impact of these types of attacks:
Data and Application SegmentationIt has long been considered a best practice to locate data, applications, and operating system files on separate storage devices to improve computer performance. If you segregate these types of files on servers you also help protect the applications, data, and operating systems from directory traversal attacks. VulnerabilityTwo types of vulnerabilities are exposed if you locate applications, data, and log files on the same storage volume as the operating system. One vulnerability is the potential for a user or users to accidentally or deliberately fill an application log file or upload files to the server and fill the storage volume with data. The second vulnerability is known as a directory traversal exploit, in which an attacker takes advantage of a bug in a network service to navigate the directory tree to the root of the system volume. The attacker may then search through the operating system file folders to execute a utility remotely. There are thousands of variations on directory traversal attacks that exploit vulnerable applications and operating systems. IIS has been vulnerable to several such attacks in recent years. For example, the NIMDA and Code Red worms used a buffer overflow exploit to traverse Web site directory trees and then remotely execute Cmd.exe to gain access to a remote shell and execute additional commands. CountermeasureWhenever possible, relocate Web content, applications, data, and application log files to a partition that is separate from the system volume. Potential ImpactFor organizations that build and maintain servers in a consistent manner, the impact should be minimal. For organizations that do not maintain this information, the impact will be somewhat greater because administrators will have to investigate how each computer is set up. Configure SNMP Community NameThe Simple Network Management Protocol (SNMP) is a network management standard that is widely used in TCP/IP networks. SNMP provides a way to manage network nodes—servers, workstations, routers, bridges, and hubs—from a centrally located host. SNMP performs its management services through a distributed architecture of management systems and agents. Computers that run network management software are referred to as SNMP management systems or SNMP managers. Managed network nodes are referred to as SNMP agents. The SNMP service provides a rudimentary form of security by means of community names and authentication traps. You can restrict SNMP communications for agents and allow them to communicate with only a specific list of SNMP management systems, and community names can be used to authenticate SNMP messages. Although a host can belong to several communities at the same time, an SNMP agent does not accept requests from a management system in a community that is not on its list of acceptable community names. There is no relationship between community names and domain or workgroup names. A community name can be thought of as a password that is shared by SNMP management consoles and managed computers. It is your responsibility as a system administrator to create hard-to-guess community names when you install the SNMP service. VulnerabilityThe SNMP protocol is inherently weak with regard to security. The single biggest vulnerability with SNMP is that almost all vendors set a default community string name, and these default community names are well known. For example, Microsoft uses the word Public. A second vulnerability is more difficult to overcome. Because SNMP traffic is sent in plaintext, the community string is transmitted across the network without being encrypted or hashed when an SNMP management device connects to an SNMP client. To address this second vulnerability, you can encrypt all traffic between servers. However, this countermeasure is beyond the scope of this guide. CountermeasureConfigure the SNMP community string for read access on all computers to a random alphanumeric value. To configure the SNMP community string
Leave write access through SNMP disabled. Note: The community name is stored in the registry as a registry value with a DWORD value of 4, so you could automate this change by creating a script or adding a line to a security template and importing the template into a domain-based Group Policy. The value is stored in: HKLM\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ValidCommunities. Potential ImpactYou must also reconfigure the community string on all management tools that use the SNMP protocol. Disable NetBIOS and SMB on Public Facing InterfacesThis section discusses specifically designed recommendations for servers that are located in networks that cannot be fully controlled, such as publicly accessible Web servers and e-mail gateways. These types of servers are often referred to as bastion hosts. If you have any such servers, you should consider the recommended procedures in this countermeasure. However, you should test each change thoroughly and ensure that you understand that it will be a challenge to manage computers on which NetBIOS has been disabled. VulnerabilityTo help secure a bastion host, you can greatly reduce its attack surface if you disable server message block (SMB) and NetBIOS over TCP/IP. It will be difficult to manage servers that operate under this configuration, and they will be unable to access folders shared on the network. However, these measures effectively protect the server from compromise through the SMB and NetBIOS protocols. Therefore, you should disable SMB and NetBIOS over TCP/IP for network connections on servers that are accessible from the Internet. CountermeasureSMB communication will not be prevented if you disable NetBIOS. SMB will use TCP port 445 (referred to as SMB Direct Host or the Common Internet File System (CIFS) port) in the absence of standard NetBIOS ports. As a result, explicit steps must be taken to disable both NetBIOS and SMB separately. NetBIOS uses the following ports:
SMB uses the following ports:
On servers that are accessible from the Internet, complete the following procedures to remove File and Printer Sharing for Microsoft Networks and Client for Microsoft Networks. To disable SMB
To disable NetBIOS over TCP/IP
These steps disable the SMB direct host listener on TCP/445 and UDP 445. Note: This procedure disables the Nbt.sys driver. Although it disables the NetBIOS Session Service (which listens on TCP port 139), it does not disable SMB completely. To do so, follow the steps in the earlier "To disable SMB" procedure. Potential ImpactNo computers will be able to connect to the server through SMB. The servers will be unable to access folders shared on the network. Management tools that depend on NetBIOS or SMB for connectivity will be unable to connect to the servers. Configure Terminal Services PortTerminal Services is a useful tool for network administrators because it enables remote server and end-user computer management. The Remote Desktop client installs by default on all Windows Server 2003 and Windows XP computers, and it is available as an optional component on the Windows 2000 Server installation media. There is also a downloadable Microsoft ActiveX® client that runs within Internet Explorer or the Microsoft Management Console (MMC). The Remote Desktop and ActiveX clients are collectively known as the Terminal Services Advanced Client (TSAC). VulnerabilityTerminal Services listens on TCP port 3389 by default, and all versions of the Remote Desktop clients attempt to connect to this port. Although the entire session (including the user authentication) is encrypted, Terminal Services clients do not perform server authentication. An attacker who was able to spoof a legitimate Terminal Services server could trick users and cause them to connect to the attacker's server instead of the genuine server. To achieve this deception, the attacker could alter DNS records to redirect users to their server or use some other means. CountermeasureChange the TCP port that is used by Terminal Services, or implement an IPsec policy to require trust and negotiate either Authentication Header (AH) or Encapsulation Security Payload (ESP) using IPsec transport mode (not IPsec tunnel mode). In some scenarios, it may be feasible to isolate the Terminal Server behind a VPN gateway so that either Point-to-Point Tunneling Protocol (PPTP) or L2TP/IPSec-secured VPN tunnels are required to gain access to the Terminal Server. For information about how to change the port that is used by Terminal Services and the Remote Desktop Client, see the Microsoft Knowledge Base article "How to Change Terminal Server's Listening Port" at http://support.microsoft.com/?scid=187623. This article explains how to change the listening port for the regular desktop client. To do so in the Terminal Services Advanced Client Web client, you need to add the following script line to the Web page: MsRdpClient.RDPport = xxx (xxx represents the desired TCP port number.) For more information about how you can use and customize Remote Desktop Web Connection to run Terminal Services sessions within Microsoft Internet Explorer, see "Providing for RDP Client Security" at http://msdn2.microsoft.com/en-us/library/Aa382994. Potential ImpactImplementation of IPsec with AH will have a negligible impact on computer performance, but it will introduce new overhead to manage client and server IPsec configuration. Additional overhead is also required to manage a mutual trust method between client and server computers that are used by Internet Key Exchange (IKE) security negotiation before IPsec security associations are established. The IPsec policy should be designed either to protect all traffic to the server, or to require IPsec just for connections to TCP port 3389. If you require IPsec on the server side, client computers that do not have a compatible IPsec configuration and trust will be denied access. See the “Configure IPsec Policies” section later in this chapter for more information about how to use IPsec policies to negotiate security for TCP/IP traffic. If you change the default ports on Terminal Services servers and clients, legitimate users who do not have their client software configured to use the new port will not be able to connect to computers whose port assignments have been changed. Also, there is no way to change the TCP port in the current version of TSAC. Disable Dr. Watson: Disable Automatic Execution of Dr. Watson System DebuggerSystem debuggers facilitate the troubleshooting of computers and applications. These programs gather data and present it to the system administrator or application developer while the computer is running. The Dr. Watson tool that is included with Windows Server 2003 and Windows XP is an automated system debugger that records information about the system state and applications that are active at the time that a program fault occurs. VulnerabilitySome organizations may feel that no debuggers should be installed on critical production computers. There are no known Dr. Watson-related exploits that can be executed bv users who do not have administrative privileges. In other words, an attacker would need to belong to the local Administrators group to use Dr. Watson as an attack tool against other users or processes. An attacker who has already gained administrative privileges has complete control of the computer, so attackers could still pursue other paths if you disable Dr. Watson. CountermeasureFor instructions about how to disable the Dr. Watson system debugger, see the Microsoft Knowledge Base article "How to Disable Dr. Watson for Windows" at http://support.microsoft.com/?kbid=188296. Potential ImpactNo system debugger will run, and no report will be automatically created if programs crash. Systems administrators and developers will have less information available to them to diagnose the cause of such problems, and the error reporting feature will not work. Disable SSDP/UPNP: Disable SSDP/UPNPIf you disable the Universal Plug and Play (UPnP™) host service, other applications such as Windows Messenger will still be able to use the Simple Service Discovery Protocol (SSDP) discovery service discovery process to identify network gateways or other network devices. For more information, see the Microsoft Knowledge Base article "Traffic Is Sent After You Turn Off the SSDP Discover Service and Universal Plug and Play Device Host" at http://support.microsoft.com/?kbid=317843. VulnerabilityThe UPnP features included with Windows XP and Windows Server 2003 can be extremely useful for home users and small businesses because they can automate the installation and configuration of UPnP devices when they are attached to the local network. Some organizations may want to ensure that no UPnP or SSDP traffic travels across their network. Although there are no known vulnerabilities with these features right now, a major problem was discovered in Windows XP a couple of years ago that required application of a hotfix. CountermeasureTo ensure that no applications use the SSDP and UPnP features that are included with Windows XP, you can add a REG_DWORD registry value called UPnPMode to the following registry key: HKEY_LOCAL_MACHINE\Software\Microsoft\DirectPlayNATHelp\DPNHUPnP\ and configure its value to 2. Potential ImpactUPnP and SSDP features will be completely disabled. When UPnP devices are attached to the network you will have to configure and manage them manually. Configure IPsec PoliciesIPsec (available in the Windows 2000, Windows XP, and the Microsoft Windows Server 2003 operating systems) is a tool that allows network security administrators to permit, block, or negotiate security for TCP/IP traffic. IPsec is independent of and transparent to applications. The design goal for Windows 2000 was to provide a way to secure network traffic with the IPsec protocol’s AH format or the ESP format. IPsec policy provides static TCP/IP traffic filters (also called selectors) that are necessary to negotiate security through IKE Chapter 6, "Deploying IPsec," in the Windows Server 2003 Deployment Kit: Deploying Network Services provides more in-depth information about the latest capabilities of IPsec. The section titled "Determining Your IPSec Needs" identifies uses for IPsec. The deployment kit is available for download at www.microsoft.com/downloads/details.aspx? For most applications, the Windows Firewall component provides adequate host-level protection against malicious inbound traffic. The Security Configuration Wizard (SCW) in Windows Server 2003 with SP1 greatly simplifies the setup and management of Windows Firewall settings for large deployments. IPsec should be used to secure host-to-host and host-client traffic where appropriate, and Windows Firewall should typically be widely deployed within most organizations as an additional defensive layer. VulnerabilityAlthough most network security strategies focus on how to prevent attacks from outside an organization's network, a great deal of sensitive information can be lost by internal attacks that interpret data on the network or that exploit design or implementation weaknesses in upper layer protocols to gain access to a computer. Attackers may use NetBT null sessions to gain information that could be used to compromise administrator passwords (if other security settings are not used or accidentally turned off). Attackers simply need to locate one vulnerability in one application port to gain access and potentially full control of a computer. As noted, because many types of data are not protected when they travel across the network, employees, support staff members, or visitors may be able to copy data for later analysis. Firewalls that are located between the internal network and the Internet offer no protection against such internal threats. Internal firewalls often cannot provide authenticated access controls that are necessary to protect clients and servers, nor can they provide end-to-end security of network traffic between computers. CountermeasureIPsec filters recognize TCP/IP traffic by source and destination IP address, by IP protocol type, and by TCP and UDP ports. IPsec filters help contain and control the spread of malicious code because they block worm and virus traffic. Also, IPsec can make it very difficult for an attacker to use remote shells or other attack utilities to gain access to the computer from within a compromised application. For more details about how an IPsec policy can be applied in Windows 2000 to block ports, see the Microsoft Knowledge Base article “How to block specific network protocols and ports by using IPSec” at http://support.microsoft.com/?scid=813878. Also, the white paper "Using IPSec to Lock Down a Server" at www.microsoft.com/technet/itsolutions/network/security/ipsecld.mspx provides step-by-step configuration guidance for Windows Server 2003 IPsec permit/block filtering that is similar to this guidance. However, the NoDefaultExempt registry settings that are recommended by the Knowledge Base article should be added for Windows 2000. Windows Server 2003 provides the MMC IPsec Policy Management snap-in, which is a graphical user interface (GUI) that you can use to manage IPsec policy. This tool is very similar to the one for Windows 2000 and Windows XP. Windows Server 2003 provides the MMC IPsec Monitor snap-in and the NETSH IPsec command-line utility to show the IPsec policy filters as they are applied on the computer. Permit and block filters appear in IKE Quick Mode configuration—IKE Quick Mode generic filters are the filters as defined in the assigned IPsec policy. IKE Quick Mode-specific filters result from the application of policy to the particular IP configuration of the computer. Note that the IKE Quick Mode-specific function Find Matching Filters cannot be used to match permit and block filters, only filters that have a negotiate action. The following terms are discussed in the rest of this section:
An easy way to record this information is in a table called a network traffic map. A network traffic map contains basic information about the server role, the direction of network traffic, the destination of the traffic, the IP address of the interface, IP protocol, the TCP port, and the User Datagram Protocol (UDP) port that is involved. A sample network traffic map is shown in the following table. A network traffic map helps you understand what types of network traffic enter and exit particular servers. Before you create IPsec policies, it is essential for you to understand what traffic is required for the server to function properly. Failure to do so may cause you to create filters that are too strict, which can cause application failures. To create a traffic map
If you start with the most restrictive IPsec filters and open up additional ports only as needed, the highest possible level of security can be achieved with these settings. This process is much easier if you divide the services into client and server services. The server services should be defined for any service that the computer provides to other hosts. Table 11.1 Sample Network Traffic Map
In this sample traffic map, the Web server will provide HTTP and HTTPS services to computers from any source IP address, so appropriate traffic is permitted. The ME destination is interpreted by the IPsec service to create a filter for each of the IP addresses on the computer. Each of these filters will be mirrored to permit the traffic to return to the computer from which it originated. This approach effectively means that the HTTP Server rule will permit traffic that originates from any host on any source port to connect to port 80 on the IIS server. The mirror of this rule will permit TCP traffic from port 80 of the IIS server to go to any port on any host. A client service can be any service that the computer performs in which the policies use another host. For example, in the sample traffic map, the server may need DNS client services to perform name lookups for one of the Web applications. In this example, a filter was created to permit traffic to and from the DNS server(s). Windows Server 2003 provides policy enhancements over Windows 2000 Server for this type of configuration to permit traffic to the DNS and other infrastructure servers. In Windows 2000, the IPsec policy must contain each of the DNS server IP addresses in the policy. In Windows Server 2003, the policy can use the logical name DNS, which will be expanded into a filter for each DNS server IP address based on the local IP configuration of the server. Note: IPsec policies that use Windows Server 2003 features such as this one should not be assigned to Windows 2000 or Windows XP computers. The mirrored block filter from Any IP to My IP Address will block all other unicast IP traffic to or from an IP address on the computer. This filter is more general than the protocol and port-specific filters that were defined for DNS, HTTP, and HTTPS. Because the default exemptions were removed for Windows Server 2003, this filter will match and therefore block outbound multicast and broadcast packets—because the source IP is My IP Address and the destination address matches Any IP address. However, note that inbound multicast and broadcast traffic is not matched by this filter. The source address would be Any IP, but the destination address of a multicast or broadcast packet is not a specific IP address on the computer—it is a multicast or broadcast IP address. Therefore, this rule will not block inbound multicast or broadcast traffic on Windows Server 2003. This filter definition is also supported by Windows 2000 and Windows XP. However, it will only match unicast IP traffic. Those platforms were not designed to match broadcast and multicast packets against IPsec filters. Therefore, outbound and inbound multicast and broadcast packets will be permitted even though this filter is applied on Windows 2000 and Windows XP computers. The last rule, Block Everything, demonstrates another filter enhancement for Windows Server 2003. This rule is not supported by Windows 2000 or Windows XP. This rule blocks both inbound and outbound multicast and broadcast traffic as well as all other unicast traffic that does not match a more specific filter. If this rule is used, the previous “Any IP to Me” rule is not needed. It is important to note that if such a policy were enforced, the computer could not communicate to its DHCP server to renew a lease, to domain controllers, to WINS servers, to CRL revocation sites, or to server monitoring stations. Also, this policy does not allow remote management by administrators who use RPC-based MMC snap-ins or a Remote Desktop client connection. Note also that if the example IIS server had two network interface cards—one for Internet access and one for internal access—all traffic over both interfaces would be filtered in the same manner. Therefore, this policy needs to be significantly customized to accommodate production environments. Network traffic should be filtered differently for the internal IP address or subnet. Filter rules that are used to require IPsec-encrypted remote management from specific management stations also should be used whenever possible so that other compromised servers cannot gain access to servers through the internal interface or capture administrative logon network traffic for offline attacks. If a client service is required that cannot be restricted to connections with a particular destination server or a limited number of destination servers, the level of security provided by IPsec filters may be greatly reduced. In the following sample network traffic map, one rule is added so that an administrator can use a Web browser to access any Internet site for help information and to download patches. This capability requires a mirrored outbound static permit filter for TCP destination port 80 traffic. Table 11.2 Sample Network Traffic Map that Allows Outbound Web Browsing
Although this sample traffic map seems like a proper configuration, the result is that the entire policy now provides no security against an attacker who initiates an inbound connection from Any IP address through TCP source port 80. This attacker could access any open TCP port through the inbound permit filter, and the reply is allowed through the outbound permit filter back to TCP destination port 80. Any of the following solutions could be used to block the inbound attack:
The sample traffic map in the following table uses additional IPsec filters to block any attempts to access open ports from port 80. First, the Netstat –ano command is used to determine what TCP ports must be open on the server that the attacker could connect to. The output of this command is similar to the following: C:\Documents and Settings\testuser.domain.000>netstat -ano Active Connections Proto Local Address Foreign Address State PID TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 740 TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING 884 TCP 0.0.0.0:1046 0.0.0.0:0 LISTENING 508 TCP 192.168.0.5:139 0.0.0.0:0 LISTENING 4 UDP 0.0.0.0:445 *:* 4 UDP 0.0.0.0:500 *:* 508 UDP 0.0.0.0:1026 *:* 816 UDP 0.0.0.0:1029 *:* 508 UDP 0.0.0.0:1051 *:* 452 UDP 0.0.0.0:4500 *:* 508 UDP 127.0.0.1:123 *:* 884 UDP 192.168.0.5:123 *:* 884 UDP 192.168.0.5:137 *:* 4 UDP 192.168.0.5:138 *:* 4 The rule is then defined to block the specific attack from TCP source port 25 to each open TCP port, as shown in the following table: Table 11.3 Revised Sample Network Traffic Map that Allows Outbound Web Browsing
This example demonstrates how to create one-way filters to block traffic with a source port of 80 to any active ports on the computer, which would block an inbound attack. It prevents the ability to spoof a source port of 80 to connect to the ports that are required by RPC, NetBT, and SMB (CIFS). You can apply IPsec policies in several ways:
It is possible to distribute the IPsec policies based on Group Policy. However, when IPsec policies must be tailored to specific computers, it may be better to use local policies. Alternatively, a mix of local or domain based policy and NETSH IPsec-scripted persistent policy may be the most manageable. In particular, NETSH must be used to set persistent policy that provides security during computer startup. For more detailed information, see the section "Assigning Domain-based, OU-Level, and Local IPSec Policies" in Chapter 6, "Deploying IPSec" in the Windows Server 2003 Deployment Kit: Deploying Network Services. Negotiating IPSec Protection for TrafficThe IKE protocol integration with IPsec filtering permits policy-based, automatic negotiation of IPsec cryptographic protection for unicast IP traffic that matches the IPsec filters. IPsec-protected packets can either use the AH format or the ESP format with security options determined by policy configuration. The use of IPsec policies to negotiate IPsec-secured transport for upper layer protocols and applications provides the following benefits:
Potential ImpactIPsec is one tool that you can use to harden a server against network attack. It should not be viewed as the only tool or a complete solution. IPsec filtering was not designed to replace the need for a full-featured perimeter firewall or router filters. It is recommended only for simple packet filtering scenarios to harden clients and servers where static filters can be effective. Also, IPsec filtering was designed for a directory-based policy to apply to many computers. Therefore, the MMC IPsec Policy Management snap-in cannot provide detailed information during the configuration process about how a policy will be applied to a specific computer. Limitations of IPsec filtering include the following:
When IPsec (or other network device) filtering blocks network traffic, unusual application behavior and event messages may result. IPsec filtering does not provide an easy-to-read log of dropped inbound and outbound traffic. Network Monitor (Netmon) captures of network traffic cannot view outbound traffic that is blocked. Although Netmon can view inbound traffic that is blocked, there is no indication in the capture file that a particular packet is dropped. Effective diagnostics depend upon the knowledge of normal application behavior, events, and network traffic flows when IPsec policy is not assigned. Furthermore, the proper design of IPsec filters for application traffic may depend upon detailed analysis of network traffic flows to understand how the application uses the network. For example, the SMB protocol uses TCP port 139 for file transfer, file sharing, and print sharing. If this port is blocked by IPsec, SMB can also use TCP port 445. Another example is when an application requires multiple network traffic flows to different destinations. SMB and other protocols typically authenticate the user, which can transparently cause the computer to locate and exchange Kerberos traffic with the domain controller. The Kerberos protocol uses DNS UDP 53 or TCP 53 to discover a list of domain controller IP addresses, then LDAP UDP 389 and UDP and TCP port 88 to potentially any of the domain controller IP addresses. Therefore, a print failure may actually be caused by a blocked packet to the domain controller. Some protocols, such as RPC, use a wide range of TCP ports that are dynamically determined when a computer starts, or at the time an application is executed, which means that RPC applications cannot be effectively controlled by static filters on ports except when the RPC application provides the configuration to require the use of a static port. In Windows 2000 and Windows XP, default exemptions to filters that are specified in the policy configuration were designed for IP network traffic types that either cannot be secured with IKE (broadcast and multicast IP packets), must be exempt for quality of service (QoS) to be provided for IPsec traffic (RSVP protocol), and must be required by the IPsec system to function (IKE itself and the Kerberos protocol as an IKE authentication method). Although a registry key was provided to remove them, these exemptions were often not disabled when IPsec filters were used for permit and block firewall scenarios. Therefore, Windows Server 2003 only provides an exemption for IKE traffic. Microsoft recommends that you remove the default exemptions for all IPsec scenarios that use Windows 2000 and Windows XP. For more information about default exemptions, see the Microsoft Knowledge Base article "IPSec Default Exemptions Can Be Used to Bypass IPSec Protection in Some Scenarios” at http://support.microsoft.com/?kbid=811832 and Microsoft Knowledge Base article "IPSec default exemptions are removed in Windows Server 2003" at http://support.microsoft.com/?kbid=810207. When a Windows 2000 computer is connected to the Internet, a mirrored outbound permit filter (such as for port 80, which was explained earlier in this chapter) allows an attacker to gain access to any open TCP port on the server from the Internet through the source port. Therefore, a mistake in IPsec configuration may result in loss of expected security. Configurations should be tested to ensure that they provide the expected security and protection from attacks. A security compromise that allows an attacker to obtain either Local Administrator or Local System access could allow them to disable or change the IPsec policy. IPsec in Windows 2000 does not provide complete filtering during computer startup. There is a small window of time in which the TCP/IP stack is responsive. An automated attack could potentially access application ports that the IPsec policy would otherwise block. In most cases, applications have not been able to start processing connections before IPsec filtering was in place. To achieve the highest level of security when using IPsec filtering, you should disconnect the computer from the network during restart. Windows Server 2003 provides an initial startup policy that the IPsec driver uses when loaded by TCP/IP during computer startup. When the IPsec service starts, it immediately applies persistent policy. Then, when a local or domain policy assignment can be determined, the service applies this policy assignment in addition to the persistent policy. Therefore, a NETSH IPsec script that configures a secure default persistent policy (for example, block all traffic except management traffic) can provide complete protection during transition from startup to local or domain-assigned IPsec policy. More information is available in the Windows Server 2003 online Help and in the deployment kit. However, neither Windows 2000 nor Windows Server 2003 is designed to allow you to configure service dependencies on the IPsec Policy Agent service startup. Configuration of a service dependency does not effectively guarantee that the filters are in place before the dependent service starts. Windows Server 2003 and Windows XP with SP2 provide the Windows Firewall service, which performs stateful filtering for outbound traffic and provides basic controls for inbound access to ports and ICMP message types. Windows Firewall also provides a readable log of inbound and outbound blocked packets. Administrators should investigate Windows Firewall capabilities to determine if it better suits their needs for filtering traffic. The stateful filtering that is provided by Windows Firewall can be used in combination with IPsec filtering to protect scenarios in which IPSec must be configured to use mirrored outbound filters to permit traffic. Front-end router or firewall filtering should be used as the first line of defense when feasible. A host-based intrusion detection system and other antivirus systems are worth consideration to detect and potentially defend against infection and attacks within permitted network traffic and applications. A third party host–based or edge firewall may provide the best solution for complex filtering needs. Negotiating IPsec Protection for TrafficAlthough IPsec end-to-end protection can greatly enhance security, if you deploy IPsec-secured communications on your network you will incur additional training and administrative costs. It may also involve additional hardware costs if you need to purchase IPsec hardware, offload network adapters, or increase CPU capacity. Therefore, before you deploy IPsec for any specific scenario, you should carefully consider and document the potential security threats that IPsec is intended to address, your security requirements, the costs of IPsec deployment, and the expected business benefits. Implementation of IPsec with AH introduces new overhead to manage a client/server IPsec configuration as well as to manage a mutual trust method between client/server computers. If the two computers are always in the same domain or mutually trusted domains, then Group Policy can deliver the necessary IPsec policy settings and Kerberos authentication can establish trust for IPsec security associations. If computers are not able to use Kerberos authentication, then either computer certificates or a preshared authentication key may be used. However, this guide does not recommend preshared authentication keys because the key value is stored unprotected in the IPsec policy configuration. Although the local IPsec policy can only be read by administrators who defined the policy, policy that is stored in Active Directory needs to be accessible by all domain computers. Therefore, it is difficult to maintain privacy of the preshared key value. Microsoft recommends the use of digital certificates when the Kerberos protocol cannot be used for IKE authentication. IPsec policy should be designed to either protect all traffic, or to negotiate IPsec just for specific TCP or UDP ports. IPsec policy on the client side typically must be configured with the server’s static IP address. If you require IPsec on the server side, access would be denied to client computers that did not have a compatible IPsec policy configuration and mutual trust method. For more information about the Windows IPsec implementation, see the Windows 2000 IPsec Web site at www.microsoft.com/technet/prodtechnol/windows2000serv/howto/ispstep.mspx. Configuring Windows FirewallAn Internet firewall can help prevent outsiders from accessing your computer through the Internet. Windows XP with SP2 and Windows Server 2003 with SP1 include the Windows Firewall, a built-in firewall that can provide for many organizations an additional layer of protection against network-based attacks such as worms and denial-of-service attacks.
Windows Firewall does not have the rich feature set that is provided by many third-party products, because it is intended only as a basic intrusion prevention feature. Windows Firewall does not allow people to gather data about the PC and blocks unsolicited connection attempts. However, Windows Firewall does not do extensive outbound filtering. Windows Firewall adds several key improvements over the Internet Connection Firewall (ICF) that was included in earlier versions of Windows. In particular, Windows Firewall can be centrally managed through Group Policy. For information about available management tools and settings, see the "Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2" white paper at www.microsoft.com/downloads/details.aspx? More InformationThe following links provide additional information about additional hardening measures for Windows Server 2003 and Windows XP:
|
In This Article
|
