Lesson 4: Troubleshooting Security

Security troubleshooting can be a complex and difficult process. Traffic can be filtered at a firewall, at a router, or at a virtual server. If a particular type of traffic or traffic from a particular source is getting through when it should not or is not getting through when it should, then it can be difficult to locate the problem. Troubleshooting permissions can also be problematic. Permission inheritance is a very useful function, but sometimes it is not easy to discover the level at which a permission is defined. The use of security certificates is typically invisible to the ordinary user, but you need to know what to do if a certificate is compromised or corrupted.

After this lesson, you will be able to

• List the protocols and services that you may want to pass through your firewall and their associated ports

• Describe the functions of firewall and virus logs

• Troubleshoot permissions and permission inheritance

• Describe the uses of public and private keys and troubleshoot encryption and digital signatures

Estimated lesson time: 60 minutes

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.

Real World: Good and Bad Firewall Problems

Your users will probably not agree with this, but there are good and bad firewall problems. Good problems are when the good guys cannot get past the firewall to do what they need to do. They may be unhappy, but you can solve their problems. Bad firewall problems are when the bad guys get past your firewall and do unpleasant things to your intranet. Accept the criticism you get for limiting the good guys. Concentrate on foiling the bad guys.

Back-end servers contain private stores and sensitive public stores and need strong protection. Front-end servers typically require weaker protection and more functionality. 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. Table 14-1 is taken from Chapter 11, "Microsoft Exchange Server 2003 Security," and is important enough to reproduce in this chapter. These are the ports that Exchange Server 2003 server might need. Open as few of them as possible.

Table 14-1: Exchange Server 2003 Ports and Services

Port	Service
25	SMTP
80	HTTP
88	Kerberos
102	Message Transfer Agent (MTA)-X.400 connector over TCP/IP
110	POP3
119	NNTP
135	Client/server communication RPC Exchange administration
143	IMAP4
389	Lightweight Directory Application Protocol (LDAP)
443	HTTP using Secure Sockets Layer (SSL)
563	NNTP using SSL
636	LDAP using SSL
993	IMAP4 using SSL
995	POP3 using SSL
3268 and 3269	Global catalog lookups

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. Virus protection is discussed in depth in Chapter 11.

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.

Real World: Honeypots

A honeypot is when you set up what appears to be a vulnerable Web presence and then analyze the methods used to attack it. This can give you information about the attackers and also diverts them away from your real organization. There is not sufficient space here for a full discussion of this topic, but an Internet search is 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 14-12 illustrates this option.

Figure 14-12: Copying or deleting inherited permissions

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. The instructions for installing Network Monitor are given in Chapter 13. 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

This exercise is similar to a section of the troubleshooting lab in Chapter 13. Nevertheless, it is only a short exercise and is required for the remainder of the practice.

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 [e-mail]. 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 14-13.

   
   Figure 14-13: 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 email traffic is encrypted.

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

1. On Server01, start Exchange System Manager.

2. Navigate to Administrative Groups\First Administrative Group\Servers\Server01 \Protocols\SMTP\Default SMTP Virtual Server.

3. Right-click Default SMTP Virtual Server and click Properties.

4. On the Access tab, click Certificate.

5. The Web Server Certificate Wizard opens. Click Next.

6. Select Create A New Certificate, and then click Next.

7. Select Send The Request Immediately To An Online Certification Authority, and then click Next.

8. Click Next again to accept the defaults on the Security Name And Settings page.

9. Ensure that the Organization is Tailspintoys and the Organizational Unit is Administration. Click Next.

10. Ensure the Common Name is Server01. Click Next.

11. Ensure that the Geographical Information is correct. Click Next.

12. Select a certificate authority to process your request, as shown in Figure 14-14.

    
    Figure 14-14: Selecting a certificate authority

13. Click Next. Click Next again to submit the request.

14. Click Finish to close the wizard.

15. The Communication button on the Access tab of the Default SMTP Virtual Server Properties dialog box no longer appears dimmed. Click that button.

16. Configure the security settings to use a secure channel, as shown in Figure 14-15.

    
    Figure 14-15: Specifying security settings

17. Click OK. Click OK again to close the Properties dialog box.

18. Repeat the procedure in Exercise 1 to send an identical e-mail message to [e-mail] and capture that message. This time, however, you should be unable to read the message body contents in Network Monitor.

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 then try the question again. You can find answers to the questions in the "Questions and Answers" section at the end of this chapter.

1. Kim Akers sends an encrypted e-mail message to Don Hall. Which of the following statements is true?

   1. The message is encrypted using Don's public key and decrypted using Don's private key.

   2. The message is encrypted using Kim's private key and decrypted using Kim's public key.

   3. The message is encrypted using Don's private key and decrypted using Don's public key.

   4. The message is encrypted using Kim's public key and decrypted using Kim's private key.

2. You suspect that someone is attacking your organization with Trojan horse probes. Where would you look to confirm this suspicion and to find out what ports are under attack?

Lesson Summary

• A firewall can block all incoming or outgoing traffic (or both) through a port. It can also filter traffic depending upon the source.

• Firewall and virus logs contain information about attacks that have been made on your organization. You should check them regularly.

• Permissions and permissions inheritance can cause problems. You need to know what permissions are assigned at what level and what permissions are inherited from a higher level. Take care to document all permission changes.

• Problems with encryption and digital signatures are often due to certificates being revoked or reaching their expiration dates. Internally issued certificates may not be accepted by other organizations.