Troubleshooting Microsoft Exchange Server 2003 : Troubleshooting Security

Troubleshooting Connectivity Across Firewalls

You can secure network applications and services by restricting connections to their associated ports. TCP port filtering on a firewall enables you to control the type of network traffic that reaches your Exchange Server 2003 servers and network devices. Correctly configured firewalls are stable and sturdy devices, invisible to the legitimate user, but a barrier to the attacker. However, like everything else, firewalls may not do what you intended them to, and troubleshooting is required.

Therefore, many organizations implement light (or no) firewall protection between front-end servers and the outside world and strong firewall protection to protect back-end servers and other sensitive parts of the intranet. The front-end servers are then said to be in a demilitarized zone (DMZ), also known as a perimeter network.

Troubleshooting firewall connections requires that you allow only essential connections. If you allow a TCP port to connect, ensure that only the hosts that need to make a connection are allowed through the firewall. If you have to err at all, err on the side of blocking access rather than enabling it. 

In addition to opening and closing ports, firewalls also filter traffic by blocking or allowing specific addresses, ranges of addresses, and domains. Selected protocols can also be blocked. It is, for example, common practice to block ICMP packets. Incoming traffic often has different filtering conditions to outgoing traffic. Also, filtering can be set up on connectors and virtual servers, and on routers. Blocking and filtering can therefore be complex, and it can be difficult to determine where it has been incorrectly configured. The key to troubleshooting in this area (as in most others) is good documentation that records all the configuration changes that you make.

Network Address Translation

Network Address Translation (NAT) is often implemented by the firewall, although Routing and Remote Access servers can also provide this service. The computers in your DMZ, including front-end Exchange Server 2003 servers, need public Internet IP addresses to communicate externally. They also need private IP addresses to communicate with your intranet. Because the public IP addresses of these computers should not change, your NAT service needs to permanently associate a public address with each private address allocated to them. This allocation is known as a special port. If external users report disruption in accessing your Exchange Server 2003 organization, then check that NAT has been set up correctly. The IIS server that hosts your organization’s public Web page also requires a special port. If external users also report problems accessing this Web site, then incorrect NAT configuration is probably the problem.

Virus Protection

Virus protection can be implemented on your firewall, on your servers, and on your clients. You should check virus logs on a daily basis. Microsoft does not offer any antivirus products, so the format and content of your virus logs will depend upon the third-party antivirus product that you choose.

Firewall Logs

Firewall devices, and software firewall programs, produce logs. These are invaluable in troubleshooting inappropriate firewall operation and also for detecting attempts to attack your system. The logs give you details of attempts to communicate through blocked ports and various Transmission Control Protocol/User Datagram Protocol (TCP/UDP) probes that the firewall has intercepted. Attempts on the same set of ports from a number of sources on the Internet probably indicate that your organization is being subjected to a decoy scan. One of these attempts is an attack; the others are not. Firewall logs can also detect Trojan horse probes, such as GirlFriend (port 21544) or GateCrasher (port 6969). SubSeven (ports 1243, 6711, and 27374) is a particularly powerful probe widely used by hackers.

If details of such probes appear in your firewall log, then your firewall is doing its job and is blocking them. However, such entries indicate that your organization is under attack, and you need to find out more about the attackers. There is not sufficient space in this book to cover this topic fully, but an Internet search for “firewall logs” is highly recommended.

Troubleshooting Permissions

You can use the Exchange Administration Delegation Wizard in Exchange System Manager to control access to the Exchange objects contained within your Exchange organization or administrative group. These objects include public folder trees, address lists, message databases (MDBs), protocols, and connectors. Exchange Server 2003 uses Active Directory permissions such as read, write, and list contents, and Exchange extended permissions such as Create Public Folder and View Information Store Status. If you look at an object’s permissions, Active Directory permissions are listed first, followed by Exchange extended permissions.

Permissions may be inherited from a parent object, or applied directly to an Exchange object. Because permissions give considerable flexibility, they can also introduce complexity. You need to troubleshoot permissions when you first set up your Exchange Server 2003 organization, and again if the organization changes significantly and new objects are added. You can make your permissions structure more robust by allowing permissions to groups rather than individual users and by using deny permissions as sparingly as possible.

An example of a permission problem is when two organizations are unable to send authenticated messages to each other over SMTP connectors. The problem is that the required Send As permission has not been granted on the SMTP virtual servers in both organizations for the account used for authentication. Without this additional permission, messages sent between the servers will be denied, because the server performs a check to see if the authentication account has permissions to send as the user who sent the mail.

You can view the permissions that a user or group has on any Exchange object by navigating to that object in Exchange System Manager and then accessing the Security tab in the object’s Properties dialog box. If the Allow and Deny check boxes for a permission are shaded, the object has inherited permissions from its parent object. You can change inherited permissions, or you can click Advanced and block inheritance. If you choose to do the latter, then you have the option of either removing all the inherited permissions or copying them so that the object retains its permission settings, but they are no longer inherited. Figure 1 illustrates this option.

One of the most common errors when setting permissions is that the administrator decides that the inherited permissions are not appropriate, blocks inheritance, removes all the inherited permissions, sets a required permission, but neglects to restore those inherited permissions that are essential for correct operation. If you are changing permissions, and especially if you are delegating that task, then all changes must be carefully documented.

Troubleshooting Encryption and Digital Signatures

Exchange Server 2003 uses Transport Layer Security (TLS) to encrypt and digitally sign SMTP communications. Other Internet protocols use SSL. Both TLS and SSL require certificates that you obtain from a certification authority (CA). A certificate consists of a public key, which can be made available to anyone, and a private key known only to its owner.

If you use basic authentication, then a user’s username and password will be transmitted in plain text unless the entire communication is encrypted. Encryption protects the contents of a message from being intercepted and read, and from being altered in transit. The sender encrypts the message using the recipient’s public key and the recipient decrypts it using his or her private key. Only the recipient can decrypt the message.

A sender digitally signs a message using his or her private key. The recipient uses the sender’s public key to validate the signature. Only the sender could have sent the message because only the sender has the private key.

Encryption and digital signatures can fail for the following reasons:

• The certificate has been revoked Typically, certificates are revoked if an administrator believes they may have become compromised. If, for example, a third party has obtained a private key, the certificate is no longer secure.

• A key has been corrupted A user’s private key is stored in that user’s profile and can become corrupt. In this case, an administrator needs to revoke the certificate and issue a new one.

• The certificate is not accepted If you have Certificate Services installed in a server in your Active Directory domain, then you can issue certificates. Such certificates can be used within your organization but are unlikely to be trusted externally. To encrypt and digitally sign Internet mail, you need a third-party certificate from a trusted supplier such as VeriSign.

Practice: Checking That E-Mail is Encrypted

In this practice, you send an e-mail from Server01 to Server02 and capture the contents using Network Monitor. You then obtain a certificate and use this to encrypt outgoing mail. You then send another e-mail and check that the contents are encrypted. The practice assumes that Network Monitor has been installed and that this is not the first time it has been used. If this is the first use of Network Monitor, you need to instruct it to monitor Local Area Network when prompted.

The practice also assumes that you have not already obtained a certificate and encrypted e-mails. If so, use the certificate wizard to remove the certificate before you start. Finally, the practice assumes that Certificate Services is installed on Server01.

Exercise 1: Capture an Unencrypted E-Mail Message

To capture an unencrypted e-mail, perform the following steps:

1.	On Server01, open Network Monitor.
2.	On the Capture menu, click Start.
3.	Open Outlook and send a message to [email protected]. In the message body, type Now is the time for all good men to come to the aid of the party.
4.	On the Capture menu, click Stop And View.
5.	In the details pane (the top pane), scroll through the captured frames until you locate the message, as shown in Figure 2. Figure 2. An intercepted, unencrypted e-mail message
6.	Close Network Monitor. Do not save the capture.

Exercise 2: Obtain a Certificate and Configure Encryption

In this exercise, you obtain a certificate and configure encryption. You then test that e-mail traffic is encrypted.

To secure your e-mail traffic by using encryption, perform the following steps: