Microsoft Exchange and Blackberry Server Specialists

Exchange Server

Exchange 2003

Securing an SMTP Relay Server

In an ideal world, all users of an Exchange system would collect their email via the full Outlook client. This would be connected to the Exchange server either directly when on the LAN or private dial up, or by using a VPN or RPC/HTTPs when remote.

However we don't live in an ideal world and some occasions you need to allow users to collect email via POP3. This also means they will need an SMTP server to relay through, which means allowing email to be relayed through your Exchange server. This makes it a potential target for spammers.

Securing SMTP Authenticated Users Relay

Exchange 2000 and higher is open relay secure "Out of the box". However a common attack at the moment is for spammers to attempt to find an account that they can get the password to. Once they have an account they can rely email through your server as Exchange 2000 and 2003 allows Authenticated users to relay email by default.

The best way to get round this is to not allow relaying through your internet SMTP virtual server. Disable all the options.
Then create a second one that is only available internally and make the users VPN in to the network to send email. However using a VPN isn't always practical.

Therefore you need to limit the risk.

One way to limit the risk is to limit the number of accounts that are able to relay.

  1. Create a new AD group called "POP3 Relay" or something similar.
  2. Add all the users that you want to relay to this group. Exclude "administrator" and any other accounts that have easily guessed usernames - especially if the account is a domain admin.
  3. Then go in to the SMTP virtual server, Access tab, then relay.
  4. Click on the "users" button and add the group "POP3 Relay" to the list.
  5. Enable both "submit" and "relay" permissions.
    Leave the "Authenticated users" permissions alone - don't be tempted to change their permissions - people have got caught adding "deny" to the relay for authenticated users. Deny overwrites all other permissions, so an authenticated user would not be able to relay even if a member of the "POP3 Relay" group.

Password Encryption

One of the major concerns with SMTP is that usernames and passwords are sent across in the clear - which is the default behaviour. However Exchange does support the use of an SSL certificate and TLS encryption to provide a secure means of authentication. The email client will also need to support this feature - which Outlook Express does.

If you have an SSL certificate already, use the same certificate and import it in to the SMTP virtual server through ESM. Then enable the "Require TLS encryption" option. Leave the other settings alone and regular inbound email should not be affected.

Be aware that this is an "all or nothing" feature. If you enable TLS support, any client which does not support it will be unable to relay through this virtual server. If you need to support clients with and without TLS support then you should have a separate SMTP virtual server for the insecure clients to use.

Disable Authenticated Relaying

If you would like to disable the ability for any users, even authenticated ones, to relay through your server, then you need to disable access. This does not affect the ability of your Outlook users to send email, nor the ability to receive email.

  1. Expand ESM, Admin Groups, <your admin group>, Servers, <your server>, Protocols, SMTP.
  2. Right click on "Default SMTP Virtual Server" and choose Properties.
  3. Click on the "Access Tab" and then the "Relay" button at the bottom.
  4. Ensure that "Only the list below" is enabled and there are no servers list.
  5. Deselect the next option "Allows all computers which successfully authenticate to relay, regardless of the list above."
  6. Click Apply/OK to exit from this option.

Restart the SMTP Server Service

After enabling these options, restart the SMTP Server Service in Services for them to take full effect.

Related Articles

Usernames Tried During Authenticated User Attack (blog posting - opens in new Window).
This blog posting outlines some of the usernames that were tried during an authenticated user attack.

http://blog.sembee.co.uk/post/Usernames-Tried-During-Authenticated-User-Attack-Updated.aspx (blog posting - opens in new Window).
A second attack on the same server, produced an updated list of usernames