CISCO IRONPORT AND EXCHANGE 2016

I’ve always been using Exchange Edge Transport servers in front of my Mailbox servers
for message hygiene purposes. My last (well known) environment looked like this:

There are two Mailbox servers (Exchange 2013 and Exchange 2016) and two Edge
Transport servers (also Exchange 2013 and Exchange 2016). MX records point to both
Edge Transport servers and there are two Edge Synchronizations. And the Edge
Transport servers were capable for DKIM signing (as posted in a previous blogpost), but
lacked DKIM verification and DMARC validation.

The most important part in the Edge Transport server is the Real Time Blocklist,
configured to use Spamhaus for connection filtering. While this works pretty well (there
still is quite some spam that gets delivered into mailboxes) there is always room for
improvement. I have been looking at cloud solution, but they didn’t always deliver what
was expected.

A couple of my customers are using Cisco Email Security Appliance (previously known
as IronPort) solutions on-premises and are happy with it, so time to start testing a Cisco
Email Security Appliance (ESA) in my own environment.
Setting up the ESA
The ESA is available as a physical device, but also as a virtual device. Unfortunately
(says the Microsoft consultant in me) only as a vmware VM, but since I also have a
vmware server running that’s not a problem. Deploying the virtual machine is because
of the OVF solution a piece of cake. Connect three NICs (management, internal and
external) and you’re good. My Cisco contact told me it’s a common practice to use a
one arm deployment, but I did a two arm deployment, resulting in a configuration like
this:

The management network is (by default) 192.168.42.42, the internal network is

configured to use my 10.38.96.0/24 network while the external network is configured
with the 176.62.196.244 address. The FQDN of the device is smtphost.exchangelabs.nl,
in DNS this points to the above mentioned IP address and I have PTR records
configured for this IP address.

After the initial setup (where entering the license file via PUTTY in the CLI was the most
challenging) you can continue with the System Settings in the GUI. The default domain
is exchangelabs.nl, enter a reporting address and a time server as shown in the
following screenshot:
After entering the system settings you can continue with the network configuration.
Enter a default gateway (on the public interface), a public and internal IP address and
enter a forwarding address for inbound messages (i.e. the Exchange 2013 and
Exchange 2016 servers) as shown in the following screenshot:

The last step is to configure the message security options like enabling the Reputation
filtering, IronPort anti-spam, Sophos anti-virus and outbreak filters as shown in the
following screenshot:
After reviewing the configuration you’re good to go and once accepted the device
configures itself. This took only a few minutes, and I immediately started receiving
configuration messages from the ESA. Some of these made no sense, it looks like the
device starts sending out messages before the device is fully configured, but at least it
worked well.

The next step is to create a Send Connector in the Exchange configuration, using the
ESA as a smarthost. All outbound mail is routed through the ESA, since this has a
proper FQDN, IP address and PTR record other servers on the Internet will accept my
email messages.

Adding additional domains

Besides my test domain I want my jaapwesselius.com and jaapwesselius.nl domains to
use the ESA. First is to add the domains in the Recipients Address Table (RAT) so that
the ESA will accept messages for this domain. The second (and last) step is to
configure an SMTP route for these domains so the messages will be delivered on my
Exchange servers. Note to self: use the commit changes button after entering the

domain configuration data

When checking inbound email on my platform (using Remote Connectivity Analyzer)
you can clearly see that mail is going through the ESA:

Message Hygiene
To understand message hygiene in the ESA we have to take a closer look at the mail
flow in the ESA. This is called the Email pipeline and consists of three parts:

 Receipt – this is the initial step in receiving a message, i.e. accepting the connection, check
for policies and validate the recipient
 Work queue – when connected the message enter the work queue where filtering,
safelist/blocklist, anti-spam/anti-virus, outbreak filtering and quarantining takes place.
 Delivery – responsible for delivering the incoming message to the Exchange server.
One of the most important parts on any email security solution is connection filtering,
you want to make sure that you only accept messages from trusted sources. Messages
coming from sources known as spammers should not be accepted. On an Exchange
Edge Transport server you can configure Realtime Block Lists (RBL) and I often use
SpamHaus for this, as explained in my blogpost about configuring the Edge Transport
Server.
The ESA is using Sender Reputation Filtering to achieve this. Sender Reputation
Filtering is using SenderBase Reputation Service which is using the SenderBase
affiliate network. The SenderBase Reputation Service assigns a SenderBase
Reputation Score (SBRS) to email senders based on complaint rates, message volume
statistics, and data from public blacklists and open proxy lists. The SenderBase
Reputation Score helps to differentiate legitimate senders from spam sources. The
SBRS can vary between -10 (most likely to be spam) to +10 (most likely to be
legitimate).
After working with this for a couple of week now (in default configuration) I have to admit
it is working extremely well. I haven’t received any spam messages so far, the only
message I don’t want to receive are legitimate messages from primarily vendor sales
departments.

TLS
By default, the ESA is configured with a self-signed certificate. This certificate is only
used for accessing the ESA (for management purposes). To use TLS on this server you
have to request (or import) a 3rd party SSL certificate.
After importing the SSL certificate you have to configure the listener and the mail flow
policies on the Host Address Table (HAT). When configured you can use
the http://checktls.com site to check if your site is TLS ready:
If you check the incoming TLS messages (the next day) you can see how many TLS
encrypted messages are received. Personally I am a bit surprised that I still received 21
unencrypted messages yesterday (an average Tuesday).

Reporting
Reporting is always interesting, and the ESA sends out reports (in PDF) every day. One
of these reports is about incoming messages. As can be seen in the following
screenshot a lot of messages are blocked by the Sender Reputation Filtering:
In the same PDF you can see an overview of the sending (threat message) domains:

Outbound messages
The ESA can (should?) also be used for outbound messages. The mailflow in my
environment is changed, the Edge Transport servers are no longer used. Instead, a
Send Connector is created and the ESA is configured as a smart host on the Send
Conector.
During installation, the 2nd network interface was configured to relay outbound
messages, and the FQDN of outbound messages is configured to use
smtphost.exchangelabs.nl so outbound messages appear to come from
smtphost.exchangelabs.nl.
I have configured a reverse DNS entry, so when using http://misk.com/tools I can check if
this is correct:

So, when a receiving SMTP host does a reverse lookup on my sending IP address they
will see that there’s a match with my FQDN. So far I haven’t heard any complaints about

messages not being delivered

Summary
The Exchange Edge Transport servers can be used for connection filtering and content
filtering using keywords can be configured as well. Besides this the Edge Transport
servers are not really an anti-spam solution. Most of the times I see Edge Transport
servers they are used as a mail relay server sitting in the network’s DMZ.

For message hygiene there are several solutions, and the last couple of weeks I have
been playing with the Cisco Email Security Appliance (running on Vmware). I must say,
I am VERY IMPRESSED by the appliance. Installation was very easy to do, and using

the ESA User Manual (consisting of 1216 pages ) you can do a real deep dive into
message hygiene.
At this moment I have an almost default configuration for inbound and outbound
mailflow (including multiple domains and mailboxes) and I haven’t seen any spam since
the installation.