One of the single greatest things you can do to increase security of the com-munications between your front-end and back-end Exchange servers is to
secure the communications between them using IPSec. This security, how-ever, comes at the price of increased system utilization, as you might expect.
A common mistake that is made when configuring IPSec for use in this sit-uation is to attempt to use the Secure Server (Require Security) policy. By applying this policy to a computer, you are telling that computer that it is not allowed to create or accept any communications with other computers that are not also using IPSec and have matching encryption and authentication settings configured. The net result of this mistake in configuration is that your front-end and back-end servers will be able to communicate with each other, but not with any other hosts, including Internet clients (for the front-end servers) and domain controllers (for the back-front-end servers). Of course, you can also create a custom IPSec policy for your servers if you want. In any case, the Secure Server (Request Security) IPSec policy can be used (with minor modifications) to provide a secure communications tunnel between the front-end and back-end Exchange servers through the internal firewall.
You should also give consideration to implementing IPSec security between your front-end servers and your domain controllers and global catalog servers as well—after all, the communications between these servers are juicy pieces of information that attackers might like to get hold of as well.
But what exactly is an IPSec policy? An IPSec policy is a set of rules that defines how and when communication is secured between two endpoints.
This is done through the configuration of various rules. Each rule contains a collection of actions and filters that begin when they encounter endpoints that match.
Policies allow you to quickly and easily configure IPSec based on the settings required within your organization. Windows Server 2003 comes with the following three preconfigured IPSec policies that might or might not meet your needs:
➤Client (Respond Only)—This policy requires IPSec-provided security only when another computer requests it. This policy allows the computer to attempt unsecured communications first and switch to IPSec-secured communications if requested. This policy contains the default response rule, which creates dynamic IPSec filters for inbound and outbound traf-fic based on the requested protocol and port traftraf-fic for the communica-tion that is being secured. This policy, which can be used on worksta-tions and servers alike, provides the minimum amount of IPSec security.
➤Server (Request Security)—This policy requests security from the other computer and allows unsecured communication with non-IPSec-aware computers. The computer accepts inbound unsecured traffic, but always attempts to secure further communications by requesting IPSec security
from the sending computer. If the other computer is not IPSec-enabled, the entire communication is allowed to be unsecured. This policy, which can be used on workstations and servers alike, provides a medium level of IPSec security.
➤Secure Server (Require Security)—This policy is implemented on comput-ers that require highly secure communications, such as servcomput-ers transmit-ting sensitive data. The filters in this policy require all outbound com-munication to be secured, allowing only the initial inbound communica-tion request to be unsecured. This policy has a rule to require security for all IP traffic, a rule to permit ICMP traffic, and the default response rule to respond to requests for security from other computers. This poli-cy, typically used only on servers, provides the highest level of IPSec security on a network. This policy can also be used on workstation com-puters if you want. Non-IPSec-enabled comcom-puters cannot establish any communications with computers using this policy.
Before you start working with IPSec, you should understand a few key fea-tures of its implementation in Windows Server 2003:
➤IPSec in Windows Server 2003 is policy-based. It cannot be configured without an IPSec policy being in place, allowing an administrator to more easily apply settings to groups of objects, such as computers or users.
➤IPSec on Windows Server 2003 can use Kerberos v5, a digital certifi-cate, or a shared secret (string) for user authentication.
➤IPSec mutually authenticates computers prior to any data being exchanged.
➤IPSec establishes a security association (SA) between the two host com-puters involved in the data transfer. An SA is the collection of a policy and keys, which defines the rules for security settings.
➤IPSec encrypts data using Data Encryption Standard (DES) or Triple DES (3DES).
➤IPSec uses the MD5 or SHA1 algorithm for data hashing.
➤IPSec is invisible to users. IPSec operates at the Network level of the Open Systems Interconnect (OSI) model; therefore, users and applica-tions do not directly interact with the protocol. After an IPSec tunnel has been created, users can connect to applications and services as if they were on the local network and not on the other side of a public network.
Looking back at our sample front-end/back-end configuration after we’ve applied IPSec, you can see how traffic flows in Figure 6.25. Remember that all traffic travels over the same physical network; the different paths simply represent different protocols—or secured and unsecured traffic.
To learn more about IPSec, including how to implement and configure it to use cus-tom policies, be certain to read MCSE 70-293 Training Guide: Planning and Maintaining a Windows Server 2003 Network Infrastructure by Will Schmied and Rob Shimonski, Que Publishing, 2003.
OWA Client
Figure 6.25 You need to implement IPSec between your front-end servers and your back-end servers, domain controllers, and global catalog servers to increase security.