9.4 Threat: Forgery, spoofing, and relay

An attacker forging messages to appear as if they came from someone or somewhere else can spread false information throughout an organization or, in worse cases, trick users into releasing sensitive information. As an example, suppose you received a message from your boss instructing you to send the detailed plans and design of your network infrastructure to a third party. The message may appear authentic, and you mostly likely would simply follow your boss’s instructions and forward the information to the outside party. Suppose this third party was actually a competitor instigating a forgery attack against your organization to get the information you just provided. In the early days of the Internet, basic SMTP/sendmail servers made this quite easy (the original versions of SMTP have no authentication mechanisms at all). While this type of attack is more difficult today, the threat of forgery using this and other means is still very real. Therefore, we must also ensure that, when desired, the system can guarantee a user’s identity when sending and receiving messages. For organizations requiring the highest level of security, methods of nonrepudiation must be available. Nonrepudiation ensures that the message can be proven to be from the source indicated and also ensures that the message has not been tampered with along the way. The most common method available to protect against this threat is digital signatures. Digital signatures validate a user’s identity so that message recipients can be assured that message senders are who they claim to be. Digital signatures also provide further protection by ensuring that the message has not been tampered with during transit (the signature no longer would be valid if the message had been altered). We will discuss digital signatures later in the chapter as we focus on locking down the Exchange environment.

Exchange 2000/2003 Server has a feature that prevents third parties from relaying mail through your server. Relaying is a vulnerability that allows unauthorized systems to use an SMTP server to route (relay) mail. Relay control allows you to specify a list of incoming remote IP address and mask pairs with permission to relay mail through your server. Exchange checks an incoming SMTP client’s IP address against the list of IP networks allowed to relay mail. If the client is not allowed to relay mail, only mail addressed to local recipients is allowed. In addition, you can configure the Exchange server to match incoming SMTP clients against part of a domain name. Each time a message to be submitted through your SMTP virtual server is received, the FROM address can be validated using reverse DNS lookup. Reverse DNS lookup verifies the sender’s domain name and checks your list of approved relay domains. If the address is not authorized to relay mail, the server does not accept the incoming message. Internet users who send unsolicited mail can use the domain names of other organizations as the return address. SMTP does not always include verification of the FROM address in mail to be delivered. This makes it easy for those who wish to impersonate your domain by sending messages in the name of your domain. Using an SMTP server to submit messages, these malicious Internet users can send hundreds or thousands of messages to users over the Internet using your domain name as the FROM address. These messages can be traced to your organization, even if a user in your organization did not send the mail.