Cisco Email Security - AntiSpam solution configuration

Note: I wrote this description for version 12.5.0-066. Version 13.0 build 314 has just appeared, which is however unsuitable for production deployment (Limited Deployment).

Note: Originally, I focused only on inbound mail in the article. Later, I added notes for outbound mail as well.

Comparison of Symantec and Cisco

When I compare Symantec Messaging Gateway (SMG) and Cisco Email Security Virtual Appliance (ESA) from my perspective, it seems to me that SMG has a clearer interface (for example, the graphs are interactive and display information about a given part when hovering) and the configuration is much more intuitive. ESA may offer more configuration options, but even simple things are set up unnecessarily complicated. An important feature is Message Tracking, in ESA I find it easier to enter search parameters, but the result seems clearer in SMG (ESA has a more detailed log). ESA has a really large number of reports.

Of course, the crucial aspect is identification of unsolicited mail and possibly viruses. During the period when Symantec Messaging Gateway was functioning, it filtered Spam very well, it can be said that no Spam was coming through at all. Unfortunately, it then suddenly stopped filtering Czech-written Spam (other languages still worked well) and some users received even dozens of messages daily. It almost never happened that it marked a legitimate message as Spam (False Positive). Virus detection didn't work very well, it found one or two viruses per week, while local antiviruses on users' stations identified dozens in received messages.

I started testing Cisco Email Security Appliance at a time when Spam was passing through SMG. The situation immediately improved and it can be said that Spam identification is very good (the same as SMG when it was functioning correctly). The situation with False Positives is slightly worse, there were several cases where a regular email was marked as Spam. For virus detection, I also tested the Advanced Malware Protection (AMP) module, the situation is somewhat better than with SMG, but overall I cannot evaluate it yet.

Documentation

For installation and configuration, the two main documents are:

Note: As it usually happens, I find the documentation confusing in many things, many things lack deeper explanation, some things are described in multiple places and each time differently, and in many places it's visible that it's an update of older documentation where not everything was corrected (Ironport, SendBase web vs. Talos are still used in some places, etc.)

Principles and Services

Main components that process and filter mail (if they are enabled for a given message).

SenderBase Reputation Service (SBR) is based on blocking (rejecting) or limiting traffic according to the connecting address of the remote host. The service returns a score for each IP address, which is based on the probability that the sent message will be Spam, we can verify at https://talosintelligence.com/
- IP Reputation Filtering - reputation of the sender's domain is determined by the Cisco SenderBase Reputation Service and indicated by the SenderBase Reputation Score (SBRS) from -10 to 10, determined by Talos
- Sender Domain Reputation Filtering (SDR) - extension of IP reputation, gathers additional information about the sender's domain and returns a verdict from Talos
Anti-Spam Scanning analyzes the content of messages and detects spam and suspected spam, can store these messages in quarantine
Anti-Virus Scanning uses Sophos or McAfee
Advanced Malware Protection (File Reputation and Analysis Services) uses reputation information from the cloud and behavioral analysis (sandboxing) for files in attachments. It protects against Zero Day and targeted file attacks in email attachments. The evaluation of an attachment can change even afterwards, and then an alert is sent to the administrator.
Outbreak Filters is a defense against new viruses by placing suspicious messages in quarantine until traditional AntiVirus is updated

In practice, the vast majority of unsolicited mail (more than 90%) is filtered out using bad reputation. This works the same for Symantec as for Cisco. It means that the network connection from a certain IP address is already rejected. The disadvantage is that we cannot find such messages in the log because the SMTP connection was not established at all, so we don't know the sender, recipient, etc. Also, we cannot find these messages in quarantine.

Processing of message flow using ESA is referred to as Email Pipeline and has three phases:

Receipt - receiving incoming email, has set limits and reception policies (whether a given IP address can send messages, verification of recipient address, etc.)
Work Queue - the work queue processes incoming and outgoing emails, performs filtering, safelist/blocklist, Antivirus and Antispam checks, Outbreak Filters and quarantine
Delivery - delivery of messages, limits and policies are applied again, for example, undeliverable messages are handled

Important functions on message receipt (Receipt):

Host Access Table (HAT) - determines which hosts (senders) can connect to the listener and which are blocked, consists of Sender Groups, which group senders into groups (we can enumerate, choose an external source or classify according to SenderBase Reputation Score), and assigned Mail Flow Policies, which determine behavior
Recipient Access Table (RAT) - for incoming emails, it determines the list of (domains) recipients for which messages are accepted, we don't have to enter only domains, but also individual addresses and other variants that identify the recipient

Notes from Installation

I deployed a virtual machine (Virtual Appliance) on VMware ESXi. A classic Deploy OVF Template is performed.

Typically, the AntiSpam gateway is placed in the DMZ (Demilitarized Zone) and sends cleaned communication to the mail server in the internal network.

The VM has 3 network adapters created, which are internally called Management, Data 1 and Data 2. We can use a deployment where we have 2 data adapters (each must have an address from a different subnet) and thus one listener towards the internet and another to the internal mail server. Or only one, through which mail comes from the internet and goes to the internal network (i.e., connection to one subnet).

Note: I later found out that it's possible to configure where one network adapter (Ethernet Port) is used and multiple IP interfaces (IP Interface) are created on it, these can have addresses from the same range. We can then create a listener on each.

One option is to access management through the data interface, in which case we use only one network adapter. But in this case, the configuration wizard cannot be completed, for it we must have 2 adapters and we can change the configuration additionally.

Note: A separate management network or at least interface seems like a good solution to me. But on ESA, each interface must have addresses from a different subnet, so we would really need to have a separate network and if this was also for the internal environment, it bypasses the firewall and compromises security.

Initial Setup

After creating the VM, we need to perform basic configuration. If we have DHCP in the given network, the management interface will get an assigned IP address and we can access the web. More commonly, we need to set basic network parameters through the console.

The default user is admin and the password is ironport (Factory Default Username and Passphrase), using which we connect to the CLI. Using the interfaceconfig command, we set the IP address, mask, name, hostname, allowed services (telnet, SSH, FTP, cluster, HTTP, HTTPS, AsyncOS API), certificate on the interface. If necessary, we also configure the gateway setgateway.

To apply the settings, we must use commit.

Note: After logging into the CLI, a recommendation to run systemsetup is displayed, but this cannot be done until the license is uploaded.

License Upload

Working with licenses is another inconvenient area, as is often the case with Cisco. In the case of Symantec, we receive an email with a license file, which we upload through the web interface and that's it. Cisco sends us a PDF by email (or preferably several), where we find the Product Authorization Key (PAK) and PIN. On the website https://www.cisco.com/go/license, we must log in with our account and go through a complex Get Licenses From New PAK wizard. For Virtual Appliance, there's a special step where SN/Virtual Device Identifier should be entered, but it doesn't work. For the first license, we must leave it blank and a VLN is generated. After completing the wizard, the license can be downloaded from the website, but it contained empty XML. I had to wait for an email where the correct file arrived. Another error is that I received 5 files, by comparison I found that the content is identical.

It's important that when we upload a license to ESA, it overwrites (deletes) all previous ones. If we have multiple licenses, we must go through the wizard again, where we select the existing VLN. The new license is then added to the original one and a joint XML is generated.

License upload cannot be done via web, but we must connect to CLI (e.g. SSH). Here we use the command loadlicense, option 1 and copy the content of the entire license XML and paste it into the command line. At the end, we confirm agreement and license information is displayed. We can also view these using the commands.

showlicense
featurekeys

Web Wizard

When first connecting to the web interface, the System Setup Wizard starts (it can be run anytime in the menu System Administration - System Setup). The wizard performs basic setup of the entire system. All values can be changed or set later (we just need to find them).

In the first step, we accept the license. In the second, we enter the hostname, NTP server and time zone, we must enter a new admin password (Passphrase). In the third, network parameters, i.e. gateway, DNS (either servers or using Root Hints), network interfaces, where we must enter management and at least one data interface. On each interface, we can allow whether it accepts incoming mail (incoming) or mail leaves through it (relay email - outgoing). If we allow Accept Incoming Mail, we enter for which domain it accepts mail (Domain) and to which mail server it forwards it (Destination - SMTP Route), if we don't enter, DNS MX record is used. We can enter multiple domains, but we can define everything additionally. In the wizard, we must define one interface for receiving mail, otherwise we cannot continue.

Cisco Email Security - System Setup Wizard

In the last step are security settings, where we enable features for AntiSpam and AntiVirus. This is followed by a summary of entered settings and then changes are applied.

Basic ESA Configuration

Very brief points of what we might need to set up. Everything is described in detail in the User Guide for AsyncOS for Cisco Email Security Appliances (the documentation is long, yet in my opinion it could be better).

Note: To apply the made setting change, we must always perform Commit Changes.

Note: For a few actions, ESA contains a wizard that guides us through the configuration. It is located in the middle of the page on the right How-Tos.

Enabling Message Tracking Log

Security Services - Message Tracking

Logging for message tracking is initially disabled. I don't quite understand why (only due to disk space, but that is also divided strangely), it's a basic function that we probably always need. We enable the service, typically choose Local Tracking, optionally enable logging for rejected connections as well (so we can easily search for source IP addresses that didn't pass based on reputation).

We can increase the disk space allocated for message tracking System Administration - Disk Management.

For the subject of messages to be logged, we must enable it System Administration - Log Subscriptions at the bottom part Global Settings and Edit Settings.

The documentation states that for attachment names to be logged, it's necessary to create at least one process that scans the message body, such as Message Filter or Content Filter.

Active Directory - LDAP

System Administration - LDAP

For checks of existing recipients (addresses), determining group members, logging into quarantine and more, we must set up connection to the directory. Ideally, we use LDAPS and an authentication account for reading.

Accept Query - used for recipient validation (Recipient Validation)
Group Query - group membership
Spam Quarantine End-User Authentication Query - logging into quarantine, Designate as the active query must be checked
Spam Quarantine Alias Consolidation Query - when a user has multiple email addresses, they receive a joint email from quarantine (works only for addresses assigned to their account)

Certificates and Authorities

Network - Certificates

We can manage trusted certification authorities (CA) and upload our own certificates, which we then set for HTTPS or SMTP encryption.

Network Interfaces

Network - IP Interfaces

We can change interface settings (and create and remove), assign Ethernet port, set address, hostname (important, displayed when connecting to SMTP), assigned certificate (we first upload our own), allowed services on this interface. We can also allow users to connect to quarantine on the interface, choose port and define URL (sent in emails), the certificate should match.

ESA has several ports (Ethernet Port). IP Interfaces are bound to a port, if they are on a different port, they must have an IP address from a different subnet. Multiple IP Interfaces can be assigned to one port, then they can have addresses from the same range. Multiple interfaces allow us to split services that listen on different IP addresses (and run multiple same services on the same port, but different IP address, for example SMTP if we create multiple Listeners).

Listeners - Incoming SMTP Services

Network - Listeners

On the network interface, we create Listeners that handle incoming SMTP connections and process mail. We can define parameters that incoming connections or messages must meet to be accepted. We can create

Public Listener, which processes email messages from the internet, i.e. accepts connections from many hosts and routes to a limited number of recipients
Private Listener, which accepts messages from internal systems (mail server), i.e. a limited number of hosts and sends to many recipients on the Internet

The binding is such that on a physical Ethernet interface (port) we create an IP interface that has an assigned IP address, and on it a Listener that has an assigned port (there can be more with a different port).

Cisco Email Security - Interfaces, Listeners

On the Listener we set two important tables that affect communication with the SMTP server. These are the Host Access Table (HAT), which hosts (IP addresses of senders) can connect, and the Recipient Access Table (RAT), accepted recipient domains (recipients in general).

On the adapter, we also select LDAP query that we defined earlier in the LDAP section. The main one is

Accept Query - accepted addresses (if the recipient in the domain doesn't exist, ESA rejects and doesn't forward to the mail server), we can choose whether the check is performed during the SMTP conversation or during work queue processing

Splitting Listeners for Receiving and Sending Mail

We can have only one Listener (of type Public) if we're only dealing with incoming mail. Even in the case when we're also dealing with outgoing mail, we can make do with one Listener. But in HAT we must add Sender Group RELAYLIST and to it Mail Flow Policy RELAYED (with behavior Relay). It's simpler to create a second Listener of type Private, HAT and policies are automatically created for us.

Listener for incoming mail has defined HAT, which accepts everything (exceptions are defined for what is blocked), and RAT, which accepts messages for local domains and rejects everything else. Listener for outgoing mail has HAT, which relays for local domains (sending server) and blocks everything else, and doesn't use RAT.

When ESA has two Listeners, it has two IP addresses. Then it's important which address is used for which service, and which address ESA uses for establishing outgoing communication. In various places, we can set which interface should be used for communication (for example for LDAP traffic). The default state is auto.

Communication on Listeners is clear, we connect to Private from internal mail servers to send messages outside the organization. Public receives mail from the internet (our MX record points here). Interestingly, according to logs, incoming mail (Public listener) leaves for internal servers from the Private listener. But outgoing mail that comes through the Private listener also leaves through this to the internet.

HAT Mail Flow Policies

Mail Policies - Mail Flow Policies

In the Host Access Table (HAT), we assign a defined Mail Flow Policy to Sender Groups. Each policy determines the basic behavior, whether to accept or reject connections, as well as a number of other parameters for connection, SMTP, mail flow limitation, security (enabling detection of Spam, viruses, SPF, DKIM, encryption, etc.) and sender verification. If we want to apply a setting globally, we can modify the Default Policy Parameters; changes in individual policies can alter the default settings.

In these policies, basic parameters such as the maximum size of received messages (Max. Message Size) and the maximum number of recipients per message (Max. Recipients Per Message) are also set.

Cisco Email Security - Mail Flow Policies

Mail server where messages are forwarded - SMTP Routes

Network - SMTP Routes

If we entered a domain and its destination in the initial wizard, a record was created here. We can have different mail servers for individual domains. Usually, there will be one, so we can define in bulk that everything (Receiving Domain: All Other Domains) is forwarded to our mail server (Destination Hosts), of which there can be multiple with different priorities. This applies to incoming messages that we want to forward to the internal mail server. For outgoing mail, we usually want to use MX DNS records, in which case we must leave the All Other Domains item empty.

Sending notifications

System Administration - Alert

Disk space allocation

System Administration - Disk Management

Time settings

System Administration - Time Zone
System Administration - Time Settings

Setting timeout for web and ssh interfaces

System Administration - Network Access

Advanced Malware Protection (AMP) - File Reputation

Security Services - File Reputation and Analysis - Edit Global Settings

Here we can set some AMP parameters, for example, which types of files are sent for analysis. It can be quite useful to set the port (protocol) used to connect to the cloud File Reputation Service. By default, it's a connection to port 32137, but SSL (443) can be set. We expand Advanced Settings for File Reputation and check Use SSL (Port 443) in the SSL Communication for File Reputation section.

If the communication doesn't work, we get errors:

The File Reputation service is not reachable.

Advanced ESA Configurations

Some features that I think are worth configuring at the beginning.

Detection of marketing and bulk messages - Graymail

The configuration wizard for this feature is located in How-Tos. It's about marking messages that aren't unsolicited mail, but still not standard email (it should be a legitimate service where a person has subscribed). Cisco refers to them as Graymail. The categories are Marketing, Social Network, and Bulk.

Briefly, it involves enabling Graymail Detection in Security Services - IMS and Graymail. And setting the policy in Mail Policies - Incoming Mail Policies section Graymail, where we enable individual parts, choose to deliver (Deliver) and add (Prepend) text.

Verifying incoming messages using SPF (Sender Policy Framework)

The configuration wizard is located in How-Tos, for SPF, SIDR, DKIM, and DMARC. Info Overview of SPF and SIDF Verification.

The configuration involves enabling it in Mail Policies - Mail Flow Policies, section Default Policy Parameters. In the Security Features section, SPF/SIDF Verification is enabled.

Then we create content filters Mail Policies - Incoming Content Filters, one or more if we want to react differently. As a condition, we choose SPF Verification and assign the verification result. As an action, we can choose to modify the header Add/Edit Header and, for example, add the text [SPF Fail] to the beginning of the subject (Header Name: Subject). Other options are to quarantine or delete (Drop).

Finally, we assign filters to the policy Mail Policies - Incoming Mail Policies section Content Filters.

To check which content filters were used, we can look at the report Monitor - Content Filters. For a certain period, we see filters where there was a match (they were used) and how many times. We can click through to individual messages in Monitor - Message Tracking (where we can also filter messages where a certain content filter was used). As a drawback, I find that in the detailed message log, the event performed by the filter (for example, changing the subject of the message) is not visible.

Cisco Email Security - Mail Flow Policy: Defaults

Verifying signatures of incoming messages using DKIM (DomainKeys Identified Mail)

Identical to SPF, DKIM verification is set up (and it's also possible to set up signing of outgoing messages), the wizard is located in How-Tos. Info How to Verify Incoming Messages Using DKIM.

The configuration involves enabling it in Mail Policies - Mail Flow Policies, section Default Policy Parameters. In the Security Features section, DKIM Verification is enabled. We can create different profiles in Mail Policies - Verification Profiles.

Then we create content filters Mail Policies - Incoming Content Filters, one or more if we want to react differently. As a condition, we choose DKIM Authentication and assign the verification result. As an action, we can choose to modify the header Add/Edit Header and, for example, add the text [DKIM Fail] to the beginning of the subject (Header Name: Subject). Other options are to quarantine or delete (Drop).

Finally, we assign filters to the policy Mail Policies - Incoming Mail Policies section Content Filters.

Signing outgoing messages using DKIM (DomainKeys Identified Mail)

If our outgoing mail passes through ESA, we can enable DKIM signing of messages. First, we need a private key Mail Policies - Signing Keys. We can generate it here or insert it in text form. Subsequently, we can display the public key. Then we need to create a domain profile Mail Policies - Signing Profiles. We define a profile for a specific domain whose messages we want to sign, and enter DKIM parameters. Here we also assign the key for signing. On the list of profiles, we can also have the DNS record of the public key generated. After creating it in DNS, we can also perform a test to see if the values are correct.

The last step is enabling signing on the Mail Flow Policy for outgoing mail Mail Policies - Mail Flow Policies. We select the outgoing Listener and the RELAYED policy (or Default Policy Parameters). In the Security Features section, we enable DomainKeys/DKIM Signing.

Cisco Email Security - Domain Signing Profiles

Verifying incoming messages using DMARC (Domain-based Message Authentication, Reporting and Conformance)

An extension of SPF and DKIM is DMARC, whose verification we can also easily set up, the wizard is located in How-Tos. Info DMARC Verification.

First, we modify the global settings of DMARC and the Verification Profile in Mail Policies - DMARC. In the profile, we determine the behavior for various situations when the DMARC policy is set to reject (Reject) or quarantine (Quarantine) and the verification fails. Options are to do nothing, place in a specific quarantine (this is a Policy quarantine Monitor - Policy, Virus and Outbreak Quarantines) or reject SMTP. And further if an error occurs.

We enable DMARC verification in Mail Policies - Mail Flow Policies, either for a specific policy or rather in the Default Policy Parameters section. In the Security Features section, DMARC Verification is enabled. We can choose a profile and enable sending of daily aggregate reports (RUA). We can set the address for sending reports in System Administration - Return Addresses.

To check and see statistics on how DMARC checks are performed, we can look at the report Monitor - DMARC Verification.

Sender Verification - checking the validity of the sending domain

Mail Policies - Mail Flow Policies - Default Policy Parameters

Cisco recommends enabling, as the first step of protection against fake email domains, verification of the sending domain (Sender Verification). Based on the domain in the sender's address (Envelope Sender), it checks that an MX record exists and for it an A record in DNS. If it doesn't exist, the connection is rejected. The setting is best in the default policy in the Sender Verification section (Envelope Sender DNS Verification).

Using quarantine (Spam Quarantine)

Monitor - Spam Quarantine

As safer than immediately deleting identified Spam, it's to use its placement in quarantine so that False Positive can be checked. Info Chapter: Spam Quarantine.

Quarantine configuration is done in Monitor - Spam Quarantine. The main settings are enabling quarantine and the retention period for messages. We can also choose to send a copy of the message to Cisco when we release it from quarantine.

Usually, we want users to be able to view messages that have been placed in quarantine and possibly release them from quarantine. Therefore, we must enable End-User Quarantine Access. Authentication against AD DS is done using LDAP. In the System Administration - LDAP settings, we must create a Spam Quarantine End-User Authentication Query (and it must be set as an active query). Quarantine must be enabled on some IP Interface and a port for access must be specified.

Another useful feature, so that users do not have to constantly connect to quarantine, is to send them an email report once a day if they have any messages in quarantine. We enable Spam Notifications, choose the report parameters and its scheduling. We can also enable Enable login without credentials for quarantine access.

Finally, we must specify which messages are placed in quarantine. This means modifying Mail Policies - Incoming Mail Policies, in the Anti-Spam section, we choose the action Spam Quarantine for identified spam.

Administrator can see all messages in quarantine and can filter them. The link to quarantine is located in several places, or we can use the direct quarantine address, for example, Monitor - Spam Quarantine in the Messages column shows the total number of messages in quarantine, and clicking it opens a new quarantine window. Similarly, the administrator can view the content of all users' Safelists / Blocklists. In the top right menu Options and either Safelists or Blocklists, we see what exceptions are set for which address.

Policy Configuration - Incoming Mail Policies

Mail Policies - Incoming Mail Policies

ESA uses Mail Policies to enforce rules on incoming and outgoing messages. Here we focus on incoming mail, i.e., Incoming Mail Policies.

Cisco Email Security - Incoming Mail Policies

We can manage with just one policy - Default Policy, where we set common behavior for all senders and recipients. Or create multiple policies, where, for example, we define different behavior for a group of users (e.g., instead of placing spam in quarantine, messages are directly deleted).
Each policy has specific areas that we can configure

Anti-Spam - enable, action for identified spam and messages suspected as spam, threshold for determining spam from a score of 1 - 100
Anti-Virus - enable, scan only vs. cure, behavior for encrypted or unscannable messages, and if a virus is found
Advanced Malware Protection (AMP) - enable File Reputation and File Analysis, behavior for various situations, we can set that messages undergoing analysis are placed in quarantine (not delivered to the user), in the File Analysis Quarantine parameters we set the time after which messages are released (and then the test result is checked)
Graymail - enable (or unsubscribe), action for various categories
Content Filters - assign content filters created in Incoming Content Filters
Outbreak Filters - enable quarantine placement and parameters, possible message modifications

When creating a policy, the first thing we determine is which users it will apply to. It can be all or specified recipients or senders. Addresses can be manually listed or LDAP groups can be used. Policies are processed from top to bottom, and the first one where the conditions match (sender and recipient) is applied (First Match Wins), and no further processing occurs.

Addresses can be entered not only as complete storm@company.com, but also parts storm@ or @company.com.

On the page with the list of policies, we also have search by email address, which shows us which policy applies to the given recipient or sender.

Message Filters

Message Filters scan the content of messages, attachments, etc., and identify messages based on defined conditions and perform subsequent actions. They also have access to metadata (such as incoming listener, sender IP, SBRS). Filters are written in text form as a script and use regular expressions. The basic format is

name:
if (condition) {
 action
}

We can only configure them in the command line (CLI), where we create the filter and enter it in text form.

Content Filters

Mail Policies - Incoming Content Filters

A special variant of Message Filters are Incoming and Outgoing Content Filters. They use the same scripting language but only a subset of rules. These are rules that serve to identify messages based on content. We can easily define them using a wizard in the web interface (GUI).

Message Filters are applied as the first step of policy processing. When an action is applied, it affects all recipients of the message (applies to the entire message). Content Filters are applied last, after the message has been split into separate copies according to Mail Policies (by recipient groups).

Sender Domain Reputation (SDR) Filtering

Security Services - Domain Reputation

In Message Filters or Content Filters, we can use Sender Domain Reputation for filtering messages. By default, SDR is not used.