How do I Configure Dual Delivery for the Agari Sensor with Ironport?

Agari Phishing Defense's (APD) anti-spear phishing solution is designed to work with Cisco IronPort email ingress and receiving infrastructure. APD employs Sensors to gather email traffic data for analysis. Establishing dual delivery, wherein email messages sent to the organization’s end users via IronPort are copied to one or more Agari Sensors, requires just a few simple configuration changes. (Background on Agari’s Sensors is available in the Sensor Deployment Requirements document.)

For more information on the general architecture of the Sensor, installation requirements, expected performance, monitoring, and testing see the Deployment Requirements and Installation Guide documents. 

High-level Summary:

1. Create a Bcc: Filter that will divert messages to the Sensor.
2. Configure bounce handling to properly manage unexpected delivery failures.
3. Confirm that any desired system alerts are in place to inform administrators of any problems.
4. Consider other whitelisted email streams.
5. Whitelist Agari’s alerts server to ensure that you and your users receive alerts.

An important consideration regarding the Authentication-Results header:

Agari depends on the presence of an accurate, uncorrupted Authentication-Results header to do its job. Typically, the perimeter MTA for your institution (meaning, the first point of entry into your institution from the foreign MTAs on the internet) will evaluate the incoming messages and add an Authentication-Results header, and any downstream MTAs in your institution will be carefully configured to preserve the integrity of this header (e.g. they must not overwrite it with their own header unless they are able to do so with accurate information, and they must not strip the header from the message.)

However, mail environments can be complex, and it’s not always practical to ensure the integrity of the header for every downstream MTA. To simplify the situation, Agari’s Sensors will first look for a duplicate of the header called X-Agari-Authentication-Results. If they find none, they will fall back to the Authentication-Results header.

This allows you to configure your perimeter MTA to create (or duplicate) the Authentication-Results header under an alternate name: it will stand a greater chance of making it through your various downstream MTAs without being corrupted. Agari provides instructions on how to do this for various MTA products.

If you have been pointed here for those specific instructions, you will find them at the end of this document.

If, instead, you are configuring your MTA for Dual-Delivery, please begin here:

Create a Bcc: Filter

• Log into the Cisco-IronPort ESA as an Administrator.
• Go to Mail Policies > Incoming Content Filters.
• (if your environment is 'Clustered', the rest of the directions should be completed at either the top-level Cluster tier or at a subgroup if the action is intended to only affect a certain set of ESA instances)
• Click Add Filter.
• Name the filter Agari_sensorB.
• Give the filter a reasonable description so that future administrators will understand what the filter is for, and who to contact about it.
  Example: "This is a filter to send a BCC stream of messages into an Agari Sensor, where certain aspects of the message headers and authentication data are saved and communicated to Agari."
• Typically the order of the filter should be such that it enables the sensor to communicate all messages which are going to be delivered to the end-user. So the default order of the new filter (last) will usually be correct.

• If you have some more advanced filtering uses where a filter triggers immediate delivery and circumvention of following filters, you should consider these and place the Agari_sensor filter appropriately for the desired result: a collection of all messages delivered to the user.

The filter may not need any Conditions. Depending on the installation environment, the filter can be associated with a specific Incoming Mail Policy (see later in these instructions) for certain recipients or domains. If there is filtering logic such that messages found to be AS+ or AV+ are not dropped (and are not delivered on to the user), then Condition logic will be necessary to cause the Agari_sensor filter to not match.  Again, the goal of the filter is to only work on messages which are going to be delivered directly to the end-user: add Conditions to this filter as necessary.

• Click Add Action to associate an action with this filter. In the Add Action window, select Add/Edit Header.
• Using the interface, direct the filter to add two new headers to the message, to indicate both the original recipients and original sender (which are not always correctly reflected in the visible message headers):
      Note: capitalization variance is intentional, as per Cisco ESA documentation
  
  • header name: X-Agari-Original-From  header data: $EnvelopeFrom
  • header name: X-Agari-Original-To  header data: $enveloperecipients
    If, and only if, your IronPort MTA is a perimeter gateway MTA, then also add:
    • header name: X-Agari-Authentication-Results
    • header data: $Header['Authentication-Results']

 

• Make sure all header names are free of typing errors.
• Before clicking Submit, we need to create the primary action for this filter: to BCC the entire message into the Sensor instance.
• The Email Address for the BCC action can be a routable address that will reach the sensor, or you can specify the sensor directly (see below).
• The Subject of the Bcc: the message should be the same as original, so leave the Subject field as $Subject.
• The Return Path entry should initially be set to an appropriate address where bounces are either entirely ignored, or monitored for failure to deliver into the Sensor. Do not leave this field blank - doing so could expose the original message sender to bounce-backs in case of problems delivering to the Sensor. Once you are certain that your configured delivery is doing the right thing, you may change the Return-Path entry to be "<>", causing any explicit delivery failures to be immediately deleted from the queue.
• If the domain specified in the Bcc email address will not result in the message being delivered to the appropriate desired destination, the Alternate Mail Host entry may be used - the result of this setting will be such that the delivery attempt will be made directly to the specified host rather than to whatever is specified by MX of the Email Address or the MGA's SMTP routes feature. In other words, you can use this field to directly specify the host or IP address of the Agari sensor (IP addresses should be enclosed in square brackets, e.g. [123.123.45.67]).
  Note that the domain used in the Email Address specified above is still relevant to Bounce handling, as described below.

• Click OK.

An example screenshot showing the above filter completed, prior to submission (some details differ):

• Remember: the above image shows the X-Agari-Authentication-Results header being added: this should only be done if your IronPort MTA is a perimeter gateway MTA. If your IronPort MTA is downstream from the perimeter gateway(s), then do not add this header.
• Click Submit to save the new filter.
• Associate the filter with an appropriate Incoming Mail Policy. Go to Mail Policies > Incoming Mail Policies, and in the Content Filters column, for the appropriate row, edit the assigned Content filters to make use of the newly created filter. You may need to Enable Content Filters for that Policy in the process.
  The modified Policy may look like this:

You could now Commit the changes by clicking on the yellow Commit Changes > button, but note that after doing so mail will begin to route to the Agari sensor. If there is an issue with messages bouncing, your system may be burdened. Thus, you may wait to Commit until completing the Bounce handling steps that follow.

Bounce handling

In order to minimize a sapping of ESA system resources, it is desirable to fail bounces rapidly if the Sensor delivery fails. In order to accomplish this safely, follow these steps:

• the email address to which the Bcc: is delivered should be within a unique domain or subdomain which is accepted by the destination host (Alternate Mail Host should take care of the message being directed to that server, no need for extra DNS work for the email address's domain).  For the purposes of this example, we will continue to use the “sensor.host” for the domain.
• a Bounce Profile to rapidly fail bounces must be created: go to Network > Bounce Profiles and create a new entry with Add Bounce Profile to match the following screenshot:

• Next, you will instantiate a specific Destination Control for the unique sensor domain described above (sensor.host, in this example) making use of the Bounce Profile which we have named 'Impatient'.  Go to Mail Policies > Destination Controls and create an entry to match the following screenshot:
  
  
  (Note that the Bounce Profile has been set to “Impatient”.)
  
• If your Sensor is not inside your protected network and you would like to encrypt the stream of mail going to it, you can change the TLS Support option to Required. IronPort will now connect securely to the remote Sensor (over port 25 via “STARTTLS”).
• Once properly configured and submitted, click Commit Changes.

System Alerts

It would be wise to confirm (under System Administration > Alerts) that System and Hardware alerts will be sent to an attended address in case of any issues with the Dual Delivery setup.

Consider other whitelisted email streams

You may have firewall rules in place that whitelist upstream MTAs sending mail to your IronPort system. This is usually done with the Host Access Table (the “HAT”) which delivers the message and skips any subsequent Content Filters. Assuming you have configured Dual Delivery as described in this document, such messages will thus fail to be copied to the Agari Sensor (because the Dual Delivery mechanism is part of a Content Filter.)

Addressing this issue will depend on the particulars of your email flow, but one possible method is to use a Content Filter to whitelist senders, instead of using the HAT. You can instead create a Content Filter rule that matches on the sender’s IP address, sends a copy to the Agari Sensor (using the same configuration described in this document), and then triggers the message to be delivered without further filtering (using the Skip Remaining Content Filters action). You could then deactivate the HAT entry for that sending IP.

Whitelist the Agari alerts server

When Agari deems an email suspicious, the Agari alerts server will send you (or a role account) and, optionally, the recipient of the email, an email-based alert message regarding the perceived threat. Besides identifying the threatening message, the alert email may contain additional information about the type or severity of the threat.  Furthermore, in case of operational problems, the Agari alerts server may also send out alerts regarding your Sensor and the overall health of your Advanced Threat Protection service. Given the importance and utility of these alerts, Agari recommends that you whitelist the Agari alerts server to ensure that your system does not block, quarantine, or otherwise interfere with these messages.

The messages that the Agari alerts server sends may sometimes contain portions of the content of the original messages. Since the original messages may contain spam or otherwise be perceived as suspicious by email filtering software, it’s possible that the Agari alerts may themselves accidentally be perceived as threats. Thus it is doubly important to whitelist the Agari alerts server to prevent the triggering of “false positives” in the filtering software. If there are intermediate steps filtering your email stream before it gets to the system we are configuring with this document,. Example other intermediate MTAs, or other anti-phishing solutions that filter your email stream, they should also be configured to whitelist the Agari alerts server. Agari’s Sales Engineering and Customer Success teams can assist with this if needed; it is generally a straightforward process.

These instructions will detail adding the Agari alerts server to your whitelist. In the administration web interface for your server, open the Mail Policies menu, and select the HAT Overview menu option.

This will open the Host Access Table configuration which will allow you to add the alerts server to the list of trusted senders.

The configuration pane will look something like this:

Your configuration may look different in various ways, and you may need to adjust these instructions to suit your particular environment. For example, you may need to repeat this configuration for each “Listener” that you use, if more than one is involved. Assuming you have the default Sender Groups in place, click on WHITELIST. If you have alternate Sender Groups, simply use the one that maps to a TRUSTED Mail Flow Policy, or it's equivalent.

On the window that appears, find and click the Add Sender button in the Sender List: Display All Items in List section. This will bring up a pane that allows you to enter the IP address of the Agari alert server. In the Sender field enter the IP address 198.2.132.180. In the Comment field enter whatever you like; perhaps Whitelist Agari alerts server. The fields should look something like this:

After double-checking the IP address and checking for typos, click Submit. Back on the Sender Group pane, the window should look something like the following (again, note that your configuration may vary in sensible ways; simply confirm that the IP address is now present in the Sender List section):

 

Important: in order for these changes to take effect, you must now click Commit Changes in the upper-right of the screen.

(As seen above, the IP address of the Agari alerts server is 198.2.132.180. While in the directions above the IP address was explicitly listed, a possible option for you will be instead to reference the alert server by its hostname outbound.agari.com. However, you should only do this if you are certain that the system will act upon the client IP address of the message, and that only a forward DNS lookup is used on the Agari alert server's hostname. If you have any doubt, use the IP address.)

Once everything is configured, you should see data appear in the Agari Phishing Defense Dashboard within an hour. You can then confirm the traffic flow by logging into the Agari Phishing Defense portal and navigating to the Sensors status page.

Configure IronPort to add an X-Agari-Authentication-Results header

This section is intended only in cases where the IronPort system your are configuring is a perimeter gateway and is not being used for Dual-Delivery. If you are using your IronPort system to generate the Dual Delivery stream, then do not use this section, and instead follow the above instructions, which include the proper way to add the X-Agari-Authentication-Results header in that case.

If your IronPort system is a perimeter gateway and you want to add the X-Agari-Authentication-Results header, these instructions will assist you:

• Log into the Cisco-IronPort ESA as an Administrator.
• Go to Mail Policies > Incoming Content Filters.
• (if your environment is Clustered, the rest of the directions should be completed at either the top-level Cluster tier or at a subgroup if the action is intended to only affect a certain set of ESA instances).
• Click Add Filter.
• Name the filter Agari_auth_header.
• Give the filter a reasonable description: Add the X-Agari-Authentication-Results header to all incoming email.
• Typically the order of the filter should be such that it adds the header to all incoming email, so it should probably be at or near the top of the list: consider its placement with respect to your existing filters.

The filter may not need any Conditions. Depending on the installation environment, the filter can be associated with a specific Incoming Mail Policy (see later in these instructions) for certain recipients or domains.

• Click Add Action to associate an action with this filter. In the Add Action window, select Add/Edit Header.
• Using the interface, direct the filter to add two new headers to the message, to indicate both the original recipients and original sender (which are not always correctly reflected in the visible message headers):
  • header name: X-Agari-Original-From  header data: $EnvelopeFrom

  • header name: X-Agari-Original-To  header data: $enveloperecipients
    
    Note: capitalization variance is intentional, as per Cisco ESA documentation)

• Using the interface, direct the filter to duplicate the Authentication-Results header:
  • Header Name: X-Agari-Authentication-Results

        Specify Value for New Header: $Header['Authentication-Results']

• Make sure the header name and value is free of typos.
• Click OK.

An example screenshot showing the above filter completed, prior to submission:

Click Submit to save the new filter.

Now associate the filter with an appropriate Incoming Mail Policy.  Go to Mail Policies > Incoming Mail Policies, and in the Content Filters column, for the appropriate row, edit the assigned Content filters to make use of the newly created filter. You may need to Enable Content Filters for that Policy in the process.

The modified Policy may look like this:

You should now Commit the changes by clicking on the yellow Commit Changes button.

That should be all that is required to add the important header. You should also confirm that the evaluation of SPF, DKIM, and any other authentication mechanisms (Sender ID, DMARC, etc.) is actually enabled so that the X-Agari-Authentication-Results header is actually populated with useful information. Please get in touch with a support representative if you have any questions about this process.

Thank you for using Agari Phishing Defense. Don’t hesitate to contact us (at support@agari.com) if you have any questions about or suggestions for improving this document.