Cisco IronPort E-mail Security Appliance Best Practices : Part 2

This article is a continuation from part 1 of the IronPort ‘best practices’ series.

Here I will discuss:

  • Implementing DNS blacklists
  • DLP
  • Bounce profiles
  • LDAP queries

Implementing DNS Blacklists

So before I go in to the topic of DNS Blacklists, let me explain what they do and why you may want to implement a DNSBL.

A DNSBL is basically a list of ‘bad’ IP’s published by entities on the internet. These entities have honeypots set-up (some with the help of the community and email administrators) all over the internet. These honey pots are (at a very basic level) e-mail addresses that no legitimate person should ever know about. If the e-mail addresses start receiving mail then it is highly likely these e-mails and senders are spam/malicious. That is a very basic overview and if you want to know more, see here and here.

There are a list of DNSBL’s available at http://www.dnsbl.info/dnsbl-list.php

My tips are: you probably don’t want to use the ‘not-so-well-known’ lists. Examples of popular blacklists are BarracudaCentral, Spamhaus, SORBS, Spamcop, etc. Do your research!
Also, when choosing which blacklists you want to use, choose one or two. You don’t want to go overboard and have too many blacklists on your ESA. The more you have, the more chance of a false positive so it’s probably a good idea to just have one to begin with.

  1. Go to your HAT overview list and click on the BLACKLIST sender group
  2. Edit settings and under the DNS lists section add your chosen blacklists. I have configured mine with the following as of this post:
    b.barracudacentral.org, zen.spamhaus.org
  3. Monitor the blacklist activity by checking the mail.current log (System Administration — Log subscriptions — mail_logs) You should see something like this the below if a message has been dropped for matching a DNSBL:

DLP (Data Loss Prevention)

DLP is a very useful tool on the IronPort and I highly recommend you implement DLP in your organisation. In the context of the ESA, it will scan your outbound e-mails and attachments for specific keywords and take an action based on the keywords.

Firstly I recommend you speak to the key figures/management in your organisation to determine which files are confidential/private/internal and which ones shouldn’t be leaked outside the organisation.

For example, should someone be notified if a file containing employee salary and bonus details gets out? Probably – but it depends on your organisation and its policies. It’s usually not for IT to decide what is confidential and what isn’t; that’s a management decision to be made.

The Cisco IronPort has a lot of default DLP policies such as searching e-mails for credit card numbers, passport information, etc.

Another default that I like to use is called Suspicious Transmission – Documents to Webmail

I have configured mine so that any e-mails with attachments to public e-mail hosting domains (such as hotmail, gmail, etc) will be flagged up for me to look over. I do not quarantine any of the files as you can sometimes get false positives.

 

Bounce Profiles

Bounce profiles determine retry periods, maximum time in queue and other time limits for messages that have problems connecting to the recipient e-mail server. By default the IronPort doesn’t try to re-send e-mails more than a few times over a short period – to be fair, it isn’t designed to store e-mails but instead just process them.

Depending on your environment you may want e-mails to be queued for a longer period on your IronPort. We had an e-mail outage over the weekend a while ago and found that by Monday morning, almost all e-mails had hard-bounced. After this incident, I configured the IronPort to hold mail in the queue for 7 days before failing.

You can find the bounce profile settings under Network –> Bounce Profiles

Please see the latest user guide under the bounce profile section for a thorough explanation of all the bounce profile options. Start from page 623.

 

LDAP Queries

Setting up LDAP lookups on your IronPort is a very good idea as it can greatly reduce the number of spam e-mails your organisation receives as the IronPort will check (using LDAP) for a valid recipient before letting the connection through.

By using LDAP queries you can also prevent e-mail harvesting by stopping malicious bots/users from guessing all the valid users in your organisation.

I recommend configuring an LDAP profile on your IronPorts. Turn on SSL and lookup valid e-mail addresses using the query:

(|(mail={a})(proxyAddresses=smtp:{a}))

Configure the Directory Harvest Attack Prevention (DHAP) options in the HAT policies.

 

I hope that has been useful! I will continue to post anything useful I come across in the IronPort including more information about the content filters that I use in our environment.

6 thoughts on “Cisco IronPort E-mail Security Appliance Best Practices : Part 2”

  1. Hi,
    I have noticed an increase over the previous 3 months emails getting through our ESA devices as the sophos definitions not being new enough to identify the malware in particular.
    I have suggested enabling rDNS checking on the ESA but Cisco support keep on advising of the possibility of false positives being flagged. Do you find the reverse dns checking capturing genines email?

    1. Hey,
      I added the rDNS lookup to our ‘throttled’ policy as per point 7 in this document. If you add it to the throttled policy then you won’t really see false positives because the throttled policy doesn’t drop mail but instead limts the number of connections, recipients per message, etc so can curb the malicious e-mails to an extent but not that much.

      Have you implemented SPF checks to block e-mails that fail SPF? What about DNS blacklists? Also don’t forget to block ‘bad’ attachments as that can immediately stop the majority of malicious e-mails you receive.

      I plan on writing another IronPort article on all the content filters I use at my organisation as I think it may be useful to some.

Comments are closed.