Sunday, 14 August 2011

Securing Mail Relays

Open mail relays (SMTP gateways) with direct connections to the Internet are particularly vulnerable to attack. These systems are goldmines for Spammers and organized crime. What most organizations do not realize is that they are liable for spam and fraudulent statements that are forwarded using an insecure system for. Not only this, but many attackers use such systems to hide defamatory e-mails and to send abusive messages.

When configuring eight SMTP mail gateway consider the following:
1. Disable open relaying. Do not allow any domain and any address to send e-mail to from any location. This is not a difficult concept. The purpose of an organization’s e-mail server is not to provide free access to e-mail for the entire world. It is designed such that it can send and receive its own e-mail and it should be restricted for this purpose. Even free e-mail services such as Hotmail do not allow people to send and receive non-Hotmail related e-mails.

2. Disable commands such as VRFY and EXPN. VRFY (Verify) is designed to test the existence of an account. EXPN (expand) is used to expand e-mail groups to see who was a member of the group. For example, sales@company.com could have the entire sales department as a member. There is no need to allow spammers to test whether users exist or not. Allowing these commands on the mail gateway is asking for spam. There are worse problem is that could also occur.

3. Limit file transfer size. No matter what size files your users think they should be able to send there is always a limit. Apart from loss of information and critical information that can be sent via e-mail there are simple issues such as denial of service. If your e-mail server is running on a server with a 10 Gb disk it is unlikely that you would like to accept an 11Gb attachment. always place a limit on the maximum size of an e-mail.

4. Limit system access. Limit (by IP address) those addresses that can send mail to different addresses. If you only allow internal e-mail from inside your organization and do not allow Internet addresses to use your internal domain.

5. Scan for malware. Always check both incoming and outgoing content for malware. Most people understand the need to scan incoming e-mails. The issue is with e-mail that is going to other places. Just because an e-mail is leaving your organization does not mean you do not need to scan it. If a virus leaves your organization and infects another and you have not taken precautions, your organization will be liable for damages you have caused. It can be argued that they should have had their own antivirus solution, but the fact of the matter is that your organization is the root cause and you liable for the damages. Remember how damage much the “I love you” virus was estimated to have caused in 2000[1].

6. Implement content filtering. First there is the issue of what is both coming into and leaving your organization. E-mail is a common way for both staff and attackers to remove protected information. Worse, abusive or defamatory e-mails leave the organization liable to damages. The range of issues that can impact an organization through e-mail covered in subsequent and previous posts concerning the legal issues and tortious liability (such as negligence).

7. Add a legal disclaimer to all e-mails. All e-mails, both incoming and outgoing should have a disclaimer. This is a simple thing to add to an e-mail that will save a lot of grief down the track. It may not stop something bad from happening but least it limits the liability of the organization to a small extent.

8. Block mail from open relay blacklists and specific domains. There are blacklists containing the addresses of known spammers. In addition, if your system is constantly being attacked, block it. There is no necessity to accept e-mail from anywhere in the world. Look at where you expect to get e-mail from and what you need.

9. Use encryption where possible. Where possible encrypt the transmission of e-mail and the access to it. In particular, it is possible to use encrypted communications between internal divisions (such as Interstate or international e-mail servers) and it is potentially possible to encrypt e-mail between business partners.

10. Test the system regularly. Eicar files can be used to test that the virus signature is working. On top of this vulnerability testing tools such as Nessus can be used to ensure that no new vulnerabilities have appeared. These can also be automated so that they can report on new vulnerabilities as well. In some cases, sending an actual virus can be more effective than an Eicar file - But it can also be far far more dangerous.

Eicar files. An Eicar file is a test file that is designed to validate the functioning of an antivirus server. Of course, all antivirus engines put a lot of effort into testing Eicar files.


[1] The “I love You” virus (actually a worm) was estimated to have caused around US$ 10 billion worth of damages. See http://money.cnn.com/2000/05/05/technology/loveyou/ and http://library.thinkquest.org/04oct/00460/ILoveYou.html for more information.

2 comments:

Fred K. said...

Certainly provides food for thought...

Fred K. said...

Certainly provides food for thought...