Chapter 8. Security Filtering
In this chapter, you will learn the following:
• Security filtering engines that are available on the Email Security Appliance
• Technology underlying each filtering engine
• Enabling and configuration actions taken on identified messages
Overview
Security filtering is clearly the sine qua non of a product called the Email Security Appliance (ESA). This chapter explores the security filtering features—like anti-spam and antivirus—in depth. It also covers the zero-day virus capabilities of the Cisco Outbreak Filters feature and the use of other features, like content filters for security purposes.
The goal is to eliminate all kinds of unwanted messages from the environment entirely. At the very least, these junk messages are time-wasting, aggravating, and intrusive. At worst, they can be extremely dangerous—malicious software attached to, or linked from, email messages can be used for security breaches, allowing an attacker inside access to networks and servers in your organization.
Email spam has been a part of the Internet since the early days of Simple Mail Transfer Protocol (SMTP). Because the protocol doesn’t require authentication of sending addresses or any other part of message content, it can be forged, hiding the identity of the sender or allowing them to continually shift their sending identity. Spam, and the battle against it, has taken the form of an arms race, with each side developing new measures and countermeasures to combat the other’s techniques.
The Criminal Ecosystem
In general, security for email means dealing with unsolicited commercial email (UCE, or spam) and computer viruses or other malicious software (generally lumped together as malware). The two threats are typically related: Some spam messages propagate viruses, which infect systems and put them under the control of a botnet. There are thousands of botnets running on the Internet at any time, and there is competition among them for resources. Botnet systems are used to send out more spam and viruses.
In most jurisdictions, sending unsolicited commercial email is illegal. Unfortunately, the cross-jurisdictional nature of the Internet and the stolen resources by which the messages are propagated makes it extremely difficult to enforce these laws. Effective steps have been taken in some cases to stop the payment process that ultimately provide the profit for spam, but the senders have found means to continue their operations through front organizations, and operating in jurisdictions that have no laws or lax enforcement.
Spam typically makes money for the senders in one of a few ways. Advertisements promoting product sales are common, typically for pharmaceuticals or diet drugs, which can be legitimate but still illegally sold, or the drugs themselves can be imitation, placebo, or a dangerous substitute. Some spam is straight-up fraud, engaging in an email conversation with the recipient to extract funds. Other fraudulent messages seek to have users provide access credentials to email accounts, banking sites, or other websites by purporting to be an account or fraud alert, or by offering free products, gift cards, coupons, or rebates. These fraud messages are called phishing, but all the variants are fraud, and ESA doesn’t try to distinguish between one form of junk and another.
Computer viruses aren’t new, but the growth of Internet email made their spread much easier. Combining a malicious attachment with a message using various social engineering techniques has been an effective means of transmitting malicious software. Simply asking individuals to download and install software has been such an effective technique, in fact, that it’s difficult to describe this kind of software as a virus, as they are not self-propagating. Cisco describes any unwanted software, whether attached to email, hiding inside a useful software package, or downloaded from the web, as malware.
Reputation Filters and SenderBase Reputation Scores
Reputation filters refers to the process where the ESA makes a decision about accepting connections from remote SMTP clients based on a lookup criteria that occurs as the connection starts. Essentially, the ESA categorizes each incoming SMTP connection into groups and applies a policy to all the connections in that group. The primary criterion for this grouping is the Cisco SenderBase database, using a rating system called the SenderBase Reputation Score (SBRS).
SenderBase tracks the history of email-sending IP addresses on the public Internet. Not every IP address has a score, but virtually all IPs that have made connections on port 25 in the last 30 days are listed.
The process of categorizing IPs and applying the relevant connection policy happens in the Host Access Table (HAT). From Chapter 3, “ESA Email Pipeline,” you know that the HAT is the first part of the ESA pipeline, affecting the TCP connection and SMTP conversation. The policy that you apply also continues to affect message processing later in the pipeline, for messages that have been accepted by the ESA.
Enabling Reputation Filters
If you set up an ESA using the System Setup Wizard (SSW) and chose the option to accept incoming mail, you already have a basic HAT with groups and policies that use SBRSs. Figure 8-1 shows the default HAT that results from the SSW.
Figure 8-1. Default HAT, Including Reputation Score Ranges
The HAT is easily customizable. You can adjust the score ranges that each group represents, or even create your own groups with different score ranges. It’s always a good idea to overlap your reputation score ranges (for example, a BLACKLIST with the range –10.0 to –3.0 and a SUSPECTLIST of –3.0 to –1.0). In such a scenario, an IP with exactly –3.0 SBRS falls into the first matching policy, which is the BLACKLIST in the default table.
Reputation Scores
Reputation scores range from –10.0 to +10.0, with –10.0 being the worst. An IP address that scores –10.0 is a certain, confirmed source of junk mail. The scores are calculated as real numbers, rounded to the nearest tenth of a point. So, although an IP can have a reputation score of -3.4867, you only see scores like –3.5 in the WUI reports, message tracking, and mail logs.
Connection Actions
Once a connection is grouped, the corresponding policy is applied. The grouping decision and policy application is final; connections are not reevaluated later in the pipeline, although certain features can change the outcome of the SMTP conversation. Mail flow policies, as part of the HAT, are created by default when you run the SSW, but can be modified any time after that. All mail flow policies boil down to four possible actions, as detailed in Chapter 3: TCP Refuse, Reject, Accept, and Relay. I recommend against using TCP Refuse; it’s not part of any default policy, so you’re really left with Reject, Accept, or Relay.
A Reject, or refuse, action is immutable. Even when using the optional Delayed HAT Reject option, a connection that has a Reject action applied never allows messages in. In fact, the ESA doesn’t even allocate a full SMTP server thread to handle the connection: Although it looks like an SMTP server, the ESA is just servicing the connection with the absolute minimum resources.
From the perspective of the HAT, Accept and Relay are nearly the same thing: They allow the SMTP conversation to continue. The difference comes with the Recipient Access Table (RAT), where recipients are either validated against the table or not, and then against LDAP if available. After the connection is accepted, only a few things can change the outcome of the SMTP conversation:
• Envelope sender verification can reject the SMTP MAIL FROM address if it fails DNS checks. This feature must be enabled.
• RAT and LDAP Accept queries can reject one or more SMTP RCPT TO addresses.
• Messages that exceed the maximum size allowed by the mail flow policy can be rejected. This is not the only place message size limits can have an effect, and in fact, it’s fairly rare. In most cases, ESMTP clients parse the SIZE extension that the ESA provides in response to EHLO and not deliver messages that exceed the ESA’s maximum advertised size. Some senders ignore this or only support standard SMTP HELO and attempt to deliver large messages.
Of course, the HAT mail flow policies can all have different settings, so the behavior that a given SMTP client sees varies with the policy applied. You can find out which sender group and policy is applied to a given sender from the Incoming Mail reports, message tracking, or the mail logs.
HAT Policy Recommendations
The default HAT created by the SSW, or when you create a new public listener, has sensible groups and policies. These defaults are designed to provide good security with low false positives and a minimum of rate limiting. More restrictive filtering is possible and recommended if you understand the implications of tightening some of the controls. Here are some things to keep in mind while modifying HAT settings:
• Don’t WHITELIST. If you can, avoid the temptation to bypass anti-spam scanning for any senders whatsoever. Even with a good reputation, a known sender can suddenly become a spam or virus source because of compromised hosts in their network. Reputation and anti-spam can handle these outbreaks, but not if you manually bypass these security features explicitly for certain senders. As an alternative, consider modifying the TRUSTED policy so that it performs anti-spam scanning while maintaining the higher connection limits that are part of the default.
• Don’t set your connection limits too high. The default for most policies is to allow ten simultaneous connections from a given SMTP source. This is actually very high, and I recommend setting this lower—to just 1 or 2 per sender. Even a single connection is enough for a sender to deliver many, many messages in a short period. Save the high bandwidth settings for the TRUSTED policy.
• Overlap your SBRS ranges. Notice that the defaults include ranges like –10.0 to –3.0 for BLACKLIST and –3.0 to –1.0 for SUSPECTLIST. This is intentional. A score of –3.0 falls into the BLACKLIST, but don’t be tempted to set the SUSPECTLIST lower bound to –2.9. SBRS scores are only granular to one-tenth of a point today, but they are actually calculated to three digits or more. If Cisco decided that there was a need to publish more granular scores, you could find senders that would go unclassified.
• Decide on the organization’s email message size limit and consistently apply it. It’s frustrating to troubleshoot message-size delivery problems if one policy is set to allow 10 MB messages while the others allow 20 MB.
Once established, a HAT policy should not require constant tending. If you find yourself manually adding senders to the BLACKLIST to manage spam and virus sources, consider making your policies more aggressive based on SBRS. If you are manually WHITELISTing senders, consider opening the default restrictions to avoid inflicting rate limits on legitimate senders.
IronPort Anti-Spam (IPAS)
Anti-spam filtering means simply to stop any message with unwanted content from entering your environment. It sounds simple, but what’s obvious to a human being reading a message is not something a machine system understands. What machines are good at is processing a lot of simple comparisons, very quickly. A good anti-spam engine processes many, many rules very quickly and updates those rules very often.
Most spam filter engines work in roughly the same way: They open and examine messages, decoding attachments if necessary, and apply a series of tests. The series of tests, in total, produce a spam score, and the engine arrives at a verdict based on the score. The difference, then, is in the quality of the rules and the throughput of the engine.
When examining a spam filter, it’s typical to talk about how effective it is—how well it identifies spam. The catch rate or false negative (FN) rate refers to the number of spam messages that the rules fail to identify as such. Filters with low catch rate let a lot of spam through, so this is an important measure, and a good filter should let less than 1% of spam messages through. On the other side, the dirty secret of anti-spam filtering is how often a given engine reaches a spam verdict on a legitimate message. This false positive (FP) rate is the other key number by which to measure the effectiveness of a spam filter. Many spam-filtering technologies have low FN rates, but unfortunately also have high FP rates. In other words, they catch a lot of spam, but at the expense of catching legitimate messages, too. An accurate spam filter should have an FP rate lower than 1-in-1000.
The IPAS design goal is to exceed a 99% catch rate, while maintaining a 1-in-1 million (0.0001%) false positive rate.
Enabling IPAS
If you have a new ESA that you’ve run the SSW, IPAS will be enabled automatically unless you uncheck the box during setup.
If IPAS is currently disabled, or the feature key expired, you may need to enable the engine from the Security Services menu under the IronPort Anti-Spam page. If you previously configured IPAS, and the key expired or the feature was manually disabled, your earlier settings will be preserved. If this is the first time you enabled it, you are given a default policy for IPAS.
The global options page for IPAS is shown in Figure 8-2.
Figure 8-2. IPAS Global Options
All the security engines have only their global options enabled under the Security Services menu.
The configuration for anti-spam settings, like thresholds, verdicts, and actions, is on individual mail policy pages. If you’re starting from a new ESA setup, you’ll have only a default incoming and outgoing mail policy. The incoming default will have a basic IPAS configuration; outgoing will have anti-spam disabled. Because all the thresholds and actions are configured on a per-policy basis, you can have different spam settings for different groups of users.
The default IPAS policy page is shown in Figure 8-3.
Figure 8-3. Anti-Spam Policy Settings
IPAS Verdicts
The IPAS engine computes a numerical score (hidden) for each message. The numerical scores are then compared with the verdict thresholds. There are three possible spam verdicts: not spam (clean), suspected spam, and spam.
There’s another verdict that’s possible, if the message is considered not spam: marketing. IPAS distinguishes between the illegal, and fraudulent, spam messages, and the legal marketing and advertising that is often sent in bulk. Because it is legal, it’s not considered spam, but you may not want these messages delivered to your users. The marketing verdict is the way to treat these messages separately from clean messages.
IPAS does not render a separate verdict for phishing, fraud, 419 scam, or adult content. In general, if it can be described as bulk and unsolicited, or outright illegal, it will be classed as spam. If you have a need to filter legal adult content, for acceptable use policies, you need to consider using content filters and content dictionaries.
As IPAS evaluates its current rule set against each message, a total score is computed and a verdict rendered. Messages then pass into the actions specified for that verdict category. For performance, the IPAS engine always seeks an early exit, evaluating the lowest cost, but highest capture rules first, and exiting after a definitive match is made.
IPAS Actions
By default, clean messages continue in the next stage of the pipeline with no further action taken.
All messages that pass through the IPAS engine will have two headers added to them. These record the fact that IPAS scanned them, and an encoded header records the message verdict. If you examine the headers of an IPAS scanned message, you see these:
X-IronPort-Anti-Spam-Filtered:
X-IronPort-Anti-Spam-Result:
The anti-spam result header is encoded with rule hits so that the information can be used for improving results if it is submitted to Cisco. For example, if the message was found to be clean, but is submitted as spam, The Cisco Security Intelligence Operations (SIO) team can examine the results header to see why it scored low. It’s especially critical for examining false positives, so that the offending rules can be revised or removed.
There are four basic actions you can take on messages that fall into a particular verdict category:
• Drop: Immediately stops all processing and discards the message. Log entries record the verdict and the drop. Unless you choose to archive the message, it is lost forever. Because these messages do not continue in the pipeline, they are not checked by antivirus and cannot be acted on by content filters. Because messages continue no further, this option is good for performance.
• Deliver: Allows the message to continue, potentially with modification, and proceed through the pipeline to antivirus, content filters, and outbreak filters. If you choose not to modify the message, the only indication of the verdict will be in the encoded X-IronPort-Anti-Spam header, which cannot be decoded other than by Cisco.
• Spam Quarantine: Schedules the message to be delivered to the on-box or centralized end-user quarantine. Under the hood, this action only modifies the delivery destination, so the message continues through the pipeline to the other security engines.
• Bounce: Sends an NDR back to the envelope sender address, and drops the original message. Although this may seem useful, providing notification to the sender in the case of false positives, it is an extremely bad idea. Simply put: You should never use this option, because it creates backscatter—you become a spam relay system back to the envelope addresses. Because spam senders forge these addresses, you’ll be sending notifications to innocent third parties, and will likely end up with your external IPs on a DNS blacklist. Frankly, this setting is so problematic that it shouldn’t even be available in the product.
Note that IPAS actions apply to all messages that pass through the relevant mail policy; per-user and per-group actions are possible by using multiple incoming or outgoing mail policies. More complex actions can be achieved by using content filters.
Content Filters and IPAS
Content filters can be used to act on messages that have passed through the IPAS engine, because content filters are evaluated near the end of the work queue pipeline, after anti-spam and antivirus. To distinguish between the verdicts, however, you have to use the IPAS options to modify the message by adding a header and looking for that header with a content filter. There is no native condition to check the IPAS verdict on a message, and no way to access the numerical score of the message. So, you must combine a message markup with a filter condition that checks for that markup.
This interaction between filters and IPAS comes up when using dictionaries in a content filter for scanning messages for words and phrases. Suppose your organization has a policy against using profanity in email messages, and your naughty words are organized into a dictionary. Further, you want to redirect, or just drop, these profanity-laden messages. At the same time, your IPAS policy is to send spam to the spam quarantine. It seems simple: Set your IPAS policy to quarantine and create a simple content filter like the one shown in Figure 8-4. This one redirects the profanity to an administrator.
Figure 8-4. Simple Profanity Filter
If you were to use this filter, however, you would find that some spam messages are being redirected, because a lot of spam contains profanity. This example doesn’t have to be profanity; it could be any kind of content you’re looking for in messages. Attachment filters are affected, too. If you’re using the spam quarantine action, you are allowing the spam to continue through the pipeline for further filtering, and that may not be what you want.
The solution is to keep the quarantine action, but use the Advanced actions in each verdict configuration to add a header to the message. This is shown in Figure 8-5, where I use a header called X-AS with a value of True for both positive and suspect verdicts.
Figure 8-5. Advanced Settings for Spam-Handling Actions
The filter needs to be modified to handle this header as well. It now has an additional condition, checking that the spam header wasn’t added. The updated content filter is shown in Figure 8-6.
Figure 8-6. Updated Content Filter
Recommended Anti-Spam Settings
If you’ve run the ESA SSW and turned IPAS on, the default settings closely match the recommendations I would make for you in a new Cisco email security deployment. The spam capture rate is high, with a focus on keeping false positive rates low.
If you are transitioning to the Cisco Email Security technology from another product, you may want to create a policy that closely matches your current environment. IPAS has settings and options that are analogous to those in other products and services. Because of the very high accuracy of IPAS, you may be able to get more aggressive with spam filtering than you are with other products.
Spam Thresholds
The default spam thresholds classify scores of 90–100 as positive spam and 50–90 as suspected spam. These are good settings, if a bit conservative. They focus on providing good capture rates but maintaining a low false positive rate.
If you want to be more aggressive, you should lower the thresholds. I recommend doing so incrementally, by no more than 5 points per shift. From the default, that would make the first step to move the spam positive lower bound to 85, and the spam suspect to 45.
When you do have need for more aggressive settings, another option is to create an aggressive spam filter policy, and add users to it as requested. In many organizations, the preference for ultra-aggressive spam filtering is limited to a few vocal users. You can even create an LDAP group for these squeaky wheels so that their email is automatically treated with the more aggressive settings.
Actions for the Bold
If your focus is on removing as much spam as possible, an aggressive anti-spam policy is pretty simple: Set your spam positive and spam suspect actions to drop. IPAS is accurate enough that you will not miss the dropped messages, and throwing away these messages has advantages for performance.
Removing the messages from the environment means that you, as an administrator, don’t have to deal with them in your environment, and end users don’t have to deal with them in the inbox. Dropping the messages also means avoiding the spam quarantine, both for administrators and end users.
Slightly less aggressive would be to drop spam positive but quarantine or deliver suspected spam.
In the world of anti-spam, the ideal technology would always catch every spam message, never catch a legitimate message, and never require that users review and release messages. IPAS with a drop action is as close to this technology nirvana as you can get, and it’s very close.
Actions for the Middle-of-the-Road
If you’ve come to trust the IPAS verdicts, as I have, but want to have a recovery option, or if you want to be more aggressive and test lower spam thresholds, you should quarantine the messages. You can quarantine locally on the ESA or on an SMA, if you have one in your environment.
When using the spam quarantine, you can choose whether you allow end users to manage their own messages, or leave it strictly administrator access only. The middle-of-the-road approach is to leave the quarantine admin-only, sparing end users the burden of having to sort messages, but giving your administrators a means of retrieving messages should a legitimate message be caught as spam.
The drawback of an admin-only quarantine is additional work in the IT department to search for and release these messages, and for end users, the additional time it takes to have a message released.
Actions for the Conservative
If your organization must simply never encounter an unrecoverable false positive, you should configure the ESA to use the deliver or spam quarantine actions. Delivering the messages allows end users to deal with messages as they prefer. In most environments, the strategy is to deliver the message with a specific Subject or other header modification, allowing end users or administrators to create client mail user agent (MUA) rules to folder or delete messages. Some MUAs support flexible filtering rules that are applied at the time of final delivery; these rules can act on header presence or values or specific strings in the Subject.
The end-user quarantine always provides administrative oversight and optionally, end user access and periodic summary digest notifications. Messages are stored in the spam quarantine until either they expire or the quarantine storage space is exceeded.
Outgoing Anti-Spam Scanning
In environments where the end users are not under organizational control, spam leaving your organization from infected machines or compromised account credentials can be a serious problem. For example, service providers for residential or mobile broadband servers and higher education are often in a role of providing outgoing mail services, but don’t control the devices and software used to send email.
IPAS can be used on outgoing policies, but should not be the only security policy for controlling infected clients. Filtering effectiveness for outgoing mail originating in RFC 1918 address spaces is lower than for incoming mail. It’s more effective and much lower overhead to use HAT mail flow policies to rate limit individual clients. We cover this and other architectural solutions to compromised internal clients in Chapter 14, “Recommended Configuration.”
Sophos and McAfee Antivirus (AV)
Antivirus (AV) is the examination of email attachments for malicious content. Modern AV engines use a wide range of techniques to detect malicious content, and rely on regular updates to the rules packages that they operate on. You can think of AV as a test platform, with the message as subject and the downloaded rules as the test. The rules are generally dubbed signatures and are routinely updated. In fact, what distinguished AV today between the different vendors is how quickly a signature is created when a new virus type is identified.
The ESA provides two signature-based AV engines on the platform, each from a different vendor: Sophos and McAfee. Both products use both industry-standard and their own proprietary techniques for analyzing messages. Dynamic updates allow both the rules engine, and the rules themselves, to be updated at any time. As an ESA administrator, you can choose to run one, or the other, or both, provided you have a license key.
The motivation behind virus writing has changed. Gone are the days of graffiti and other electronic vandalism that served to enhance the author’s reputation. Virus writing has moved out of the world of motivated amateurs and into professional criminal operations. With the rapid growth of Internet usage and e-commerce, a lot of money is at stake and so has come the rapid growth of criminal activity. Computer systems running malware can be remotely controlled, with such computers being called bots organized into botnets. These bots then send out more infected messages or host landing pages for fraudulent activity or for spreading more viruses.
Because of the ubiquity of email, the credulousness of users, and the amount of money at stake, it makes a compelling infection vector for the criminals behind such activity.
As of this writing, another change in the nature of email viruses is under way. There’s a shift away from malware email attachments and a move to messages that contain a URL. This URL serves as a call to action in the message, enticing users to click on the link using social-engineering techniques. The link—usually to a website hosted on a botnet—actually delivers the malware, infecting the user through known browser exploits, or more simply, encouraging them to download and install the software, hiding the malware behind a purportedly useful package. The Cisco focus on web security and URL reputation provides the information that allows the anti-spam engine to recognize malicious URLs in email messages.
Enabling AV
As with all the security engines, the global options are available on the Security Services menu, but the individual mail policies control the actions taken by the engine for a given message. Just like with anti-spam, you can specify AV policies on a per-group or per-user basis, but there’s hardly ever a call to do so. Most organizations have a single, global AV policy.
The only configurable option on the Security Services menu is the global AV scanning timeout, in seconds. The AV engine gives up scanning a message after this amount of time, to protect the engine and the ESA from corrupted or deliberately malformed attachments, like zip bombs, that would otherwise continue scanning forever.
On a new configuration from the SSW, some sensible defaults for AV are created, and AV is enabled for both incoming and outgoing mail policies. If AV is not enabled during the SSW, you can do so by clicking the Enable button on the individual engine pages under the Security Services menu or by using the CLI antivirusconfig command. You must have a valid feature key to enable AV.
The mail policy options for Anti-Virus are shown in Figure 8-7 and Figure 8-8. You have a choice of engines, depending on which engines are keyed and enabled. You can choose Sophos, McAfee, or both. From there, you have two choices for scanning: scan for viruses only or scan and repair. Although it seems like repairing messages is a good idea, it just creates noise and confusion for end users, so I recommend the Scan for viruses only option. I go into details about this recommendation later in this chapter.
Figure 8-7. AV Scanning Options and Repaired and Encrypted Actions
Figure 8-8. AV Scanning Options: Encrypted, Unscannable, and Virus Detected
I recommend against using the Drop infected attachments option. It sounds like a good idea to drop infected attachments, but it’s a better idea to just drop the entire message.
AV Verdicts
The AV engines can arrive at one of five possible verdicts for a message:
• Not viral: The message and all attachments were scanned and found clean. The engine was able to complete scanning of all attachments, reaching a definitive verdict. No timeout or other errors were encountered. You can’t configure any actions for this verdict, as it is not available on the AV policy page. Clean messages continue without any further action other than to add a header indicating the message was scanned.
• Repaired: The message contained an attachment with a virus, but the message or the attachment was modified to remove that virus. This could mean that a macro virus was removed from a document or spreadsheet. I do not recommend using the settings that allow the AV engine to repair messages, because macro viruses are virtually nonexistent today, and a message with a viral executable attachment cannot be repaired.
• Encrypted: At least one part of the message or attachment was encrypted in some way, preventing the AV engine from fully scanning all message parts. This verdict is reached for a large variety of conditions and attachments. For example, archives with passwords, protected documents, and even spreadsheets with protected cells will return an encrypted verdict. It does not mean that the message contains a virus or that it’s even likely; it just means that the engine could not scan every byte of the message because some portion of it is encrypted. If you have no other AV scanning in the environment or have an absolutely zero-tolerance virus policy, you might consider quarantining these, but doing so will catch many legitimate nonviral messages.
• Unscannable: For some unknown reason, the engine could not fully scan the message. This could be because some portion of the message or attachment was corrupted or truncated, an internal AV engine error, or that the message exceeded the maximum scanning timeout. If you continually receive this verdict on large messages during busy periods, you can increase the AV scanning timeout. Like encrypted messages, most unscannable verdicts are NOT viral, and quarantining these results in many legitimate messages being halted. In daily operation, an unscannable verdict should be extremely rare, except in cases where the ESA is overburdened.
• Virus Infected: The message was found to contain one or more attachments that matched a virus signature.
The same verdicts are available regardless of which AV engine is used. If you have both enabled, only one engine has to arrive at a viral verdict for the entire message to be considered viral.
AV Actions
Just like anti-spam, you have a choice of actions for each verdict that the AV engine can reach. Those actions are
• Deliver As Is: Delivers the message exactly as it was received. You have the option of modifying the message subject, adding a header, delivering to an alternate recipient or host, and generating a notification about the message.
• Deliver As Attachment to New Message: Delivers the original message as either a text/plain or rfc822 MIME attachment to a new message.
• Quarantine: Delivers the message to the virus system quarantine. The message is delivered to the local system quarantine where it can be reviewed, released, or deleted by an administrative user. The system quarantines are not accessible to end users.
• Drop: All message processing halts and the message is discarded. You can choose to archive a copy. Because the message does not continue in the pipeline, you cannot act on these messages in content filters.
The actions available differ slightly depending on the verdict. For example, Drop is not available as an action for repaired messages.
When you use the Drop action, you have the additional option of archiving a copy of the message on disk in a log archive format. This can be a peace-of-mind last resort for dropped messages.
AV Notifications
Sending automated notifications is a common need for virus verdicts, and the ESA makes special provisions to support notifications for this task. Like all notifications, the text of an AV notification is controlled through a template that you create and manage in the Text Resources page of the Mail Policies menu or in the CLI textconfig command. The system-generated notifications are in U.S. English, but you can use a custom notification to craft messages in any language.
There are two types of text resources associate with anti-virus: container templates and notification templates. Container templates are only used when you choose a Deliver As Attachment to New Message action. Notification templates are the messages sent in place of the original message.
Like any other text notification, you can use action variables that are substituted with system and message values when the notification is generated. Action variables start with a $. For AV, some additional action variables are supported, which are above and beyond the normal notifications. Table 8-1 lists these antivirus action variables. The most informative variables are the various TABLEs that can be added, and I recommend that you use these for human-readable notifications.
Table 8-1. AV Notification Action Variables
Notifications should be used on outgoing virus positive messages, alerting IT security that a user or host is sending infected messages through your email environment. The notification should include enough information from the original message to allow you and your team to identify the source and type of the virus.
Content Filters and AV
You can act on messages that have been scanned by the AV engines in content filters in much the same way that you can act on spam filtered messages. By default, the AV verdict on a message is not recorded anywhere in the headers, but you can use the AV message modification options to easily add such a header.
One example of AV and content filter interaction is to augment the ability of the ESA to detect encrypted content. If your organization restricts the use of encrypted content, you can use the ability of the AV engine alongside the ESA’s native encryption detection.
Figure 8-9 shows an example of such a content filter. This example shows a quarantine action being taken on these messages, but any of the content filter actions are available. You could drop, redirect, BCC the messages, add disclaimers, send notifications, or add a custom log entry. You could also bounce the messages, but that results in your ESA sending potentially viral messages back to some third party whose address has been forged, which is obviously not recommended.
Figure 8-9. Content Filter for Acting on Messages That Are Encrypted
This content filter requires that you add an X- header to the message using the action in the Encrypted Messages verdict in the AV policy. To do this, click the AV settings in the appropriate policy to get to the Antivirus Settings page. Scroll down to the section for Encrypted Messages. Click Advanced to reveal the message modification options and click Yes to Add Custom Header to Message. Be sure to use the same header name and value in the AV settings and in the content filter.
Figure 8-10 shows the Advanced header option in the Encrypted verdict of the AV settings.
Figure 8-10. Adding a Header to Encrypted Messages
IronPort Outbreak Filters (OF)
Antivirus that uses binary signatures to identify malicious messages is an absolute necessity in modern email environments. At times, though, binary signatures aren’t enough, either because the virus is brand new and signatures aren’t published yet, or the message doesn’t actually contain any viral attachments, instead using a URL that brings the user to viral content on the web.
The Cisco Outbreak Filters (OF) engine covers these corner cases and makes intelligent judgment about potentially viral content or URLs. It is not a signature engine and cannot replace the McAfee or Sophos engines on the ESA; in fact, it’s a complement to these technologies, offering an advanced zero-day protection while relying on the verdicts from the AV engines for final action.
Because it’s not a signature engine, and it is possible that OF rules will catch legitimate content, the filtering approach is wait-and-see: Quarantine matching messages until the AV engines have a chance to update, or until the outbreak passes and the content can be confirmed non-threatening and released. In this way, additional threat messages can be stopped without much of a penalty for false positives. Messages are rescanned when AV signatures are updated, allowing the system to release or drop as soon as the threat is identified. When messages are released from quarantine, they are scanned again, giving the anti-spam and antivirus engines a second chance to render a verdict.
Enabling OF
It’s the same story with OF as it was for the other engines: Enable it on the Security Services menu, but configure the verdicts and actions on the individual mail policies.
The global outbreak filters options page shows you the global settings, along with a status report of the latest rule and engine updates. The page also shows the actual rule identifiers and descriptions so you can understand what outbreaks are underway. Note that this page lists all active outbreak rules, whether those threats are being encountered in your environment or not. If you want to see only the threats affecting your environment, look at the Outbreak Filters report on the Monitor tab.
Figure 8-11 shows the global OF options for editing. You can enable or disable the engine, set a maximum message size to scan, and opt in to email alerts. The email alerts are a nice feature, but in most environments, they will be very noisy—several to dozens per day.
Figure 8-11. Global OF Options
The other option is whether to enable adaptive rules. Adaptive OF rules can be described as “local” outbreak rules that are always active. Instead of using the global information, they examine volume trends on attachments locally, focusing on typically dangerous attachments like executables, or archives that contain executables. These rules can help protect against an outbreak that effects your environment, like a compromised host or account that begins sending virus attachments to emails. When a large volume of executables is sent in an atypical pattern by one host or user, the adaptive rules can key in on that threat and quarantine the messages.
OF Verdicts
There are, effectively, only two possible verdicts for messages when it reaches OF: clean or suspicious. Clean messages move on to the rest of the pipeline. Suspicious messages are quarantined, in a special system quarantine called Outbreak, where they are held for re-evaluation. Messages can also, optionally, be modified to alter malicious URLs, or mark up the message to make end users aware of the potential threat.
The thresholds that you configure in OF are related to the threat level published by Cisco for a given outbreak rule. Throughout the day, new outbreak rules are published that include
• An outbreak ID that uniquely identifies the rule set.
• An outbreak threat level that indicates the severity of the outbreak. Most will use threat level 3; higher is more dangerous.
• An attachment filename, file extension, or other attributes. For example, a rule might specify that it is for bat, pif, scr, or an archive type, like zip(exe). You can see these attachment details in the WUI.
• Suspicious threat URLs. If the outbreak is for messages that use a URL to malicious files instead of an attachment, the rule will include those URL patterns. The actual URLs are not available in the WUI.
You must decide for your environment at what threat level the ESA should take action on these messages. Threat level 3 is the default, and there isn’t much reason to change this. Very few slightly suspicious rules (threat levels 1 and 2) are ever published, and by the time an outbreak reaches level 4 or 5, you likely have missed some viruses. I recommend leaving this set to 3; if you’re extremely concerned about zero-day or phishing messages, lower it to 2.
OF Actions
The OF actions are, like the verdicts, simple: Quarantine the suspicious messages, potentially modifying them when they’re released. Your policy choices then are not so much what to do with messages (you can only quarantine), but rather to determine how long to quarantine for. The default is to quarantine suspected viral content for 1 day, and all other threats for 4 hours. Note that these are only the defaults; messages may actually spend more or less time in quarantine, depending on several possible events:
• When entering quarantine, the rule that determined the suspicious nature may recommend a quarantine period that is shorter than the default.
• Updates to outbreak rules may cause a reevaluation of the quarantined content. This occurs most often when an outbreak is confirmed viral and an AV signature is available, allowing the message to be released and rescanned. It’s also possible that an outbreak continues, without a determinate solution, and the message continues to be held.
• Administrative release. Any administrative user with appropriate privileges can release messages manually.
After the release, messages pass through IPAS and AV engines again, giving those engines a chance to render another verdict. Messages with suspicious URLs, like click-to-download Trojans, phishing, or 419 scam fraud are caught by IPAS. The AV engines catch viral attachments.
The Outbreak Filters mail policies page is shown in Figure 8-12.
Figure 8-12. Outbreak Filters Settings
You also have the option of bypassing outbreak filter scanning for particular file extensions. Outbreak rules for a given extension will not be evaluated when configured. You would generally use this capability if you have a strong concern about false positives and want to be certain that attachments, like spreadsheets, are never held for quarantine. Because OF has an extremely low false positive rate to begin with, and bypassing defeats the central idea behind OF, creating a security hole, I recommend against it.
Message Modification
Message modification is a new OF action, and it’s specifically designed to eliminate the threat from messages containing URLs to malicious content. If such a message is released from quarantine and is not caught by the IPAS engine after that release, it can go to the user with its URLs modified.
The modification rewrites the URLs so that the original link, when requested through a click from the user, is first passed through the Cisco-hosted security service before being delivered to the end user.
Message modification of URLs is only possible in HTML format messages or multipart messages with an HTML section. An original URL that looks like
http://fraud.example.com/mal.js
is rewritten so that the original URL is part of a new Cisco URL:
http://outbreak.cisco.com/url=fraud.example.com/mal.js
Note that this URL is just for example. It’s not actually a valid URL for this service. The valid URL depends on your software version, the Cisco infrastructure, and other conditions. When a user clicks the new URL, though, the end user’s browser contacts Cisco, not the original web server. This allows Cisco to filter the content, if necessary, before delivering it to the end user. In the case of harmless content, the end user notices no difference, but if the content is malicious, they’ll be given an error page. Think of it as antivirus scanning long after the message has been scanned by the ESA.
There are just a couple of configurable options for message modification:
• Skipping signed messages. Modifying messages that have been cryptographically signed, as with S/MIME, will result in the signature no longer providing a match. Because this will probably cause errors for the end users, it’s recommended to leave this to enable only for unsigned messages.
• You can disable URL modification for certain domains. You might consider this for your own intranet or corporate pages, or any URL that is not reachable from the public Internet. The Cisco filtering service can only act on URLs that are publicly available.
The ESA uses a standard text notification at the top of modified messages to inform the end users of the risk. You can customize this as you would other notifications on the system.
Content Filters and OF
Because outbreak filters occur in the pipeline near the end after content filters, you can’t act on OF verdicts in filters. However, you can use content filters to affect their OF processing.
When OF is enabled, you’ll be able to use the Bypass Outbreak Filter Scanning action in content filters, or the skip-outbreakcheck action in message filters. Skipping OF is the only control that you have, and there’s not much call for it: Skipping the engine creates a slight but real security hole. If you want to skip OF for certain attachment types only, do that with the OF policy settings. If you want to skip OF for certain senders or recipients, do that with an appropriate incoming or outgoing mail policy for those users.
Recommended AV Settings
AV seems like a simple policy decision: Get rid of the bad stuff. Depending on your organization’s security stance, though, there may be more to it than that. If the ESA is the only place for virus-scanning email messages, you may want to take action on unscannable or encrypted messages on the off chance these contain some viral content. If you have anti-virus scanning at other layers, like groupware and desktop client, you may choose to deliver everything except virus positive verdicts.
The first question for AV policy is: to repair or not? Repairing messages seems like a good idea, as it could allow an infected, but otherwise valid, document sent from a legitimate sender to be received. In practice, though, this kind of repairable message has disappeared from email altogether. You’re not likely to ever see a message that can be repaired.
Dropping infected attachments is also problematic. When you remove the infected attachment, the remaining clean portion of the message is delivered to the original recipient. When the rest of the message is a spam-like, plain-text message enticing the user to open the attachment, confusion results. This husk of the message is useless and confusing to the end user. Better to throw the whole thing away and forget about it.
In short, my recommendation closely matches the default:
• Don’t repair messages. You’re not likely to see repairable messages.
• Don’t drop infected attachments. This just leaves the empty message remnants to confuse the end user.
• Drop virus-infected messages. Don’t send notifications to sender because that causes backscatter, and don’t send notifications to recipients because that causes confusion.
• Deliver encrypted messages. These are rarely, if ever, viral and dropping encrypted messages will result in many legitimate messages being lost.
• Deliver unscannable messages. You should consider sending a notification about this verdict to an administrator. Unscannable can indicate a bug, malformed message, or a timeout.
Incoming AV Recommendations
Incoming email viruses are, unfortunately, a fairly common occurrence. The messages are typically short, plain text or HTML with some form of Windows executable attached. Because they have absolutely no value at all, with or without their attachment, I recommend that you simply drop all messages that reach a viral verdict, without notification either to the sender or the recipient. Notifications to the sender will not actually go to the source; the sender addresses on these messages have been forged, and your notification will go to an innocent third party. Notifications to the recipient often result in the user calling for help or support, or replying to the message over the confusion. Some users will see a familiar sender or attachment name and demand that the original message be restored to them, even though it contains a virus.
If your organization requires a conservative stance, or if you have a morbid curiosity, quarantine the virus-infected messages. Be aware, however, that the message is still dangerous if it’s released. Some desktop AV clients will even alert or interrupt your browser if you’re viewing the quarantined message. The ESA WUI doesn’t actually execute any of the binary content or pass it to your workstation for execution, but the match of byte patterns is often enough to trigger the AV client. It’s safe to examine viral content through the browser to the WUI.
You should use OFs on inbound mail policies, for all policies, with the default threat level of 3. Don’t skip any attachment types. You might be interested in the outbreak email alerts, but the volume of these alerts means that you’ll quickly turn it off. The beauty of OF is that it runs, quietly, and quarantines the suspicious threats. It’s rarely wrong, so the typical OF suspect is released from quarantine and dealt with by anti-spam or antivirus on the second pass.
Outgoing AV Recommendations
An infected message in your outgoing mail stream is more of a concern: It could be the result of a virus-infected or otherwise compromised host, or could be sent by an automated mail source that itself has been compromised. Either way, it’s important to investigate any outgoing email viruses.
For this reason, I recommend quarantining virus-positive outgoing messages and sending a notification to an administrator or administrative alias. The notification should include enough information that you can track down the source and should include the MID, sending host, and email address, the date and time, and the type of viral content. Example 8-1 shows the text listing of such a notification.
Example 8-1. Administrative AV Notification
A virus was detected in outgoing MID $MID:
Sender: $EnvelopeFrom
Source: $remotehost
Timestamp: $Date $Time
Subject: $Subject
Filenames: $filenames
Verdict: $AV_VERDICT
Viruses: $AV_VIRUSES
Virus detail:
$AV_VIRUS_TABLE
Infected parts:
$AV_INFECTED_PARTS
Encrypted detail:
$AV_ENCRYPTED_PARTS
Unscannable detail:
$AV_UNSCANNABLE_PARTS
Because of the possibility of local infected hosts, it’s also a good idea to enable OF on outgoing mail policies, if available.
Using Content Filters for Security
In many environments, custom-written rules form an important part of email security. I’m not going to strongly recommend against doing so, but I put a warning here that using content filters to do the jobs that anti-spam and antivirus do is administratively intense and can affect the performance of the ESA.
That being said, there are a couple of filters you should consider if you want to be preemptive about security. The first to start with are attachment filters. Virtually every organization restricts attachments to email in some way, because the reality is that many attachment types have no legitimate use in email, and their presence almost always indicates a threat.
Attachment Conditions and Actions
There are a few ways that the ESA can identify attachments, and you’ll likely want to use more than one approach combined:
• Filename: ESA compares the filenames reported in the MIME part for each attachment against the regular expression that you supply. Because this matches against the filename supplied in the message itself, it will not recognize files correctly if the sender modified the filename. For example, if a win32 executable has been renamed “photo.jpg,” a regular expression .exe will not detect it.
• File type: The ESA decodes the attachments and compares the file to a database of known magic numbers that identify many common file types. Because this identification compares the bytes of the attachment, it will detect attachments that have been renamed.
• File MIME type: This is the file type as reported in the email MIME headers. It consists of a general type and a specific type indicator, like audio/mp3 or text/html. Many binary attachments will use a generic type of application/octet-stream limiting the use of filters to stop attachments by MIME type. You can specify rules with wildcards, like video/*, which will match any general MIME type that starts with video.
Once identified, you have a few good choices for the action you can take:
• Drop: You can simply throw away the message.
• Quarantine: This parks the message in a system quarantine that requires an administrator to review and release it. If it’s possible that your end users may come looking for these messages, and your organization permits them to request its release, quarantine with a notification is a good choice.
• Strip the attachments: This modifies the message body, removing the attachments that match the filename, file type, or MIME type specified, replacing it with a custom message. Because these actions do both the comparison and the strip, you don’t need to have the attachment conditions in the same filter.
• Bounce: I strongly recommend against this. Bouncing messages, for any reason, is almost never a good idea.
My recommendation is to use both the filename and file type detection methods, and then either drop or quarantine the message. For incoming messages, if you worry that your users will miss these messages, send them a notification with the message details. For most of the potentially harmful attachment types, the message will have no value whatsoever, and the end user will be confused if he receives a modified message.
If your organization restricts the use of attachments that have some legitimate use, like ZIP archives, but prevent the use of executables, you may want to compose separate filters for the likely harmful and possibly harmful but useful attachment types.
Figure 8-13 shows a content filter that identifies likely harmful types and drops the message silently.
Figure 8-13. Likely Harmful Attachment Types Filter
Figure 8-14 shows a content filter that identifies possibly harmful types and quarantines the message while sending the recipient a notification.
Figure 8-14. Possibly Harmful Attachment Types, with Quarantine and Notify
Figure 8-15 shows a content filter that strips various file types from the message. The notification to the end user is in the form of a text string that replaces the original attachment.
Figure 8-15. Attachment Stripping
Filtering Bad Senders
In every environment, some email senders are not welcome, above and beyond the spam and virus senders. These could be disgruntled ex-employees, an employee’s significant other, or a hostile outsider. Any motivated group or individual can use email as a means of harassing employees in your organization. It’s likely that in your environment, you will, from time to time, have to respond to requests to completely block these senders.
If the sender is a group using a dedicated domain or specific Message Transfer Agents (MTA), the simple solution is to simply add that domain, or the IP range of the sending MTAs, to the HAT’s built-in blacklist. This will often be the case with organized letter-writing campaigns and websites with the specific purpose of offering anonymous email-sending services. If you can narrow down the offending senders to specific IPs, and those IPs aren’t used for other legitimate mail, this is the right solution.
Unfortunately, most harassing senders use accounts with major ISPs or webmail service providers that you cannot add to a blacklist. In that case, you must use policies or filters that examine the sending email addresses.
My recommended approach is to create a Blocked Senders policy on incoming mail, with the senders in question as members of the policy. When adding users, make sure to click the Sender radio button. Figure 8-16 shows an Incoming Mail Policies table with such a policy at the top.
Figure 8-16. Incoming Mail Policies with a Blocked Senders Policy at the Top
Note that I disabled the standard content filters for this policy, and instead added a single filter called quarantine_all. The purpose of that filter is, as you’d expect, to quarantine all messages that are processed by that policy. The result is that all of my blocked sender’s messages will funnel into this policy and be quarantined. In the event of another problematic email sender, simply add the address to the policy; there’s no need to modify the content filter.
There are other approaches to filtering bad-sender addresses, namely with content filter conditions that match the envelope sender against a regular expression or a dictionary, but managing those is more hassle than simply modifying a policy.
I want to caution you against using this sender-filtering approach for spam filtering: Addresses are easily forged and constantly changing, so blocking an individual spam sender is completely ineffective.
Filtering Subject or Body
If you have a security situation that requires that messages be filtered by some content in the message—in a header, or in a subject, or in the body or attachments of messages—you should think carefully before doing so. Using content filters as a security mechanism suffers from many problems:
• Performance. Examining the body of every message, and its attachments, is an expensive operation. The more terms that have to be searched, the lower the performance. There are some techniques for optimizing body scanning, but it is almost always a performance drain. If your filtering needs can be met by blocking source IPs, sender or recipient addresses, or headers, you should take that approach first.
• Maintenance. Filters require maintenance. When a filter is no longer matching any messages, it should be removed so that it’s not a drain on resources. It’s easy to forget why a filter was added, and so the filters and conditions pile up, leading to performance problems.
• Regular expression mistakes. It is easy for even experienced filter writers to make mistakes, especially with regular expressions. A mistake that simply fails to catch messages is not a big problem, but an overly broad expression can result in hundreds, or thousands, of matches, potentially dropping or quarantining a lot of legitimate messages. Take care.
These aren’t limitations or problems of ESA content filtering per se, it’s just the nature of trying to filter junk messages with words, phrases, and regular expressions. If, despite all these drawbacks, you still find that a content (or message) filter is required, I recommend following a few guidelines:
• Use dictionaries and dictionary match rules, even if you only intend to filter on a few keywords or phrases. Performance is better because only a single regular expression call is made by a content filter condition that matches against a dictionary. Maintenance is easier, because the content filter does not need modification—only the dictionary changes. It’s easy to add or remove terms from a dictionary.
• Apply these filters sparingly. If they can be limited to a specific mail policy (and therefore to a subset of users), they’ll be less of a performance drain and have less impact in the case of false positives.
• Maintenance. Take care not to let filters or dictionaries get too long or contain too many terms. Once the particular filtering need passes, the terms should be removed. Consider a policy for a 30-day filter window; every 30 days, clear the filter or dictionary of all terms and start over.
• Be careful with regular expressions. Avoid using expensive wildcards and make use of anchors and search minimum/maximum regex controls to avoid searching the entirety of every message body.
Summary
We covered the configuration of the ESA security engines and explored some techniques for security using content filters. For the most part, the actual spam and virus identification is handled by rules that are automatically updated, so the configuration work is focused on deciding on the actions to take for various message verdicts. It’s important to know the differences between the verdicts and the repercussions of using the various verdicts.
Some of the configuration settings, like spam thresholds, affect security, and you have to decide which of the risks we covered warrant more or less open policies. We also covered creating custom security rules, and the best way to craft policies and filters to address common organization security needs.
The next chapter explores some options for controlling the ESA and retrieving its data using external tools that access the CLI and WUI.