cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
23664
Views
65
Helpful
26
Replies

Ask the Expert: Best Practices for Configuring the Email Security Appliance

ciscomoderator
Community Manager
Community Manager

Read the bioWith Woody Hardison

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn from Cisco expert Woody Hardison  about Cisco e-mail security appliance, configuration of the HAT, anti-spam, anti-virus and how to install and configure certificates.Woody Hardison is an Escalation Engineer at the Technical Assistance Center at Cisco's RTP campus in North Carolina. He has over 4 years experience configuring and troubleshooting the Cisco IronPort Email Security Appliance.  Woody is a Cisco IronPort Certified Security Professional.

Remember to use the rating system to let Woody  know if you have received an adequate response. 

Woody might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Ironport sub-community discussion forum shortly after the event. This event lasts through March 9, 2012. Visit this forum often to view responses to your questions and the questions of other community members.

26 Replies 26

Hi Philippe,

Thanks!

Your current TLS configuration actually looks good, using the ciphers you have listed is fine.  The IronPort does include quite a list of ciphers you can use, I counted 34

That being said, we do have some recommendations that we've published that will allow you to keep your cipher strengths in the medium/high strength category, and avoid using :ALL.

The following Knowledge Base article describes a short string you can use in 'sslconfig'

https://ironport.custhelp.com/app/answers/detail/a_id/1367

One thing we have to be concerned with when using TLS is that we include a cipher strength that the remote smtp server is going to be able to negotiate. As you know, picking just one cipher and ignoring all others would leave you in a position where plenty of TLS connections would fail due to non-negotiation.

Going with the highest ciphers is more cpu intensive on the IronPort, but going with the lowest ciphers might not allow you to connect to some institutions that do not allow less than 128bit, for instance.

The string shown in the KB article shows how we can: include medium and high cipher strengths, disable SSLv2 (which is becoming more commonplace due to some bugs found in SSL over the past years, but is certainly optional) and disallow anonymous ciphers.

     Inbound SMTP method: sslv3tlsv1

      Inbound SMTP ciphers: MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH

      Outbound SMTP method: sslv3tlsv1

      Outbound SMTP ciphers: MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH

To me, this represents a happy medium, where we can feel safe that we're using strong ciphers to protect our information, but not excluding too many ciphers that might cause us to run into negotiation issues with remote servers.

Hope that helps,

--Woody

Hi Doug,

     Thanks for the kind words. We do what we can    I'm glad to see you're getting a good, high stoppage

percentage from the appliance. Drop percentages in the 90%+ range are typical in my experience.

The config items you've provided seem fairly reasonable. Myself, being paranoid, I would probably extend the Unkownlist to +10 SBRS mark, and leave the Whitelist with an empty SBRS range, as it comes by default.

Because everyone's mail flow is different ( my company will receive different targeted spam than yours, for instance ), obtaining the maximum potential can be as much an art as a science.

Since we often are asked what extra steps can be taken to get the maximum potential out of your IronPort,

we've published an external Knowledge Base article that lists *several* things you can do to stop as much spam as possible:

https://ironport.custhelp.com/app/answers/detail/a_id/493

I cannot stress enough to use Step 11: Report mis-classified messages to IronPort.  Anytime you catch an email making it through our systems, we want to know. You cannot submit too many samples. (The same holds true for misclassifed HAM messages.)

I'd go through the checklist on the url above and put into place as many as you feel you can. These recommendations should help you get those extra percentage points you're looking for.

Hope that helps,

--Woody


Woody,

Thanks for the info.  I will review it and see what we can change.

Just a quick question on the submission of mis-classifed messages.  Is every message that is submitted review by someone or just when a "bunch" of the same message is received?  We use T-Bird and the MailSentry IronPort Spam Reporter add-on, which works very well.  We tell our users to report Spam that they are receiving using this add-on, but some are under the impression that "my reporting this one message won't matter".

Doug

Doug,

Absolutely, no problem.

I can't give away too much of our "secret sauce" , but rest assured every message is taken into account. As you can imagine, all this is more automated than human, but there are always engineers sampling and verifying submissions to enhance our antispam rulesets.

We appreciate all submissions we receive, and the fact that you are encouraging users to submit. Submissions make the system better, and that's what we're all striving for.

Let your users know that IronPort apppreciates the time it takes to submit false positives/negatives and that every one counts.

Thanks!

--Woody

Thanks Woody for the answer on TLS.

Another question: do you have best practices to share on the update of rules/filters created on the appliances? We have started a while ago to deploy Ironports, and have several hundreds of these rules, with probably a vast amount being not applicable anymore (such as rules for people who have left the company, anti-spoofing or whitelisting on server who don't exist anymore, ...).

How do you propose to deal with this, as it takes probably a lot of horsepower?

Hi Philippe,

It's true that the more rules you deploy, the more processing time and power needed to evaluate them all.

What I would recommend in a situation such as yours would be the usage of dictionaries to combine similar filter expressions, along with a single content or message filter to evaluate it.

This is explained in a Knowledge Base article here:

https://supportops.sfo.ironport.com/kb/index.php?cc=disp&id=640

Basically, if we took ex-employeees as an example, we could do the following.

1) Create a dictionary containing the email address of ex-employee ( one per line )

2) Create a single content filter to evaluate if the recipient of the message is contained in that dictionary, and process it accordingly ( bounce, drop, respond with a template stating the address is no longer valid)

Dictionaries make it exceptionally easy to aggregate multiple filters into one filter which is basically scanning a text file for information on what to search for.

Now, along the lines of singular filters, which wouldn't benefit from using a dictionary, I can only recommend standard maintenance. The IronPort's gui is quite effective as removing/disabling Content Filters which are no longer needed. Unfortunately ( or not, depends on how you look at it ) , Message Filter administration is still a CLI-only process.

That being said, you would generally always have more Content Filters than Message Filters. Given their nature, Message Filters are more suited for broad actions; eg: drop any message coming from my external listener with my domain name as the sender.  Content Filters are more fine-grained, allowing for splintering of recipients, which allow singular recipients to be acted upon in a multi-recipient message.

Hope that helps,

--Woody

Another question: what are the best practices to manage configuration files within clusters? I've read the KB articles regarding this, and it is quite limited! However we frequently have to do massive changes to our clusters, and modifying programmatically the XML is sometimes easier than to do big changes manually.

Thanks in advance for any tip!

Philippe,

Unfortunately the KBs are limited as there is currently no support for loading/reloading configuration files from/to clustered appliances. As you've problably seen, the configurations get quite complex as each new machine is added to the cluster.

That doesn't mean it cannot always be done, as you've found.  If I were to attempt large changes on a cluster, I would probably take the route you already use, and do it programmatically.

Thanks,

--Woody

John Ventura
Level 1
Level 1

Hi Woody,

I have the following two questions:

What is an intermediate SSL certificate, and why would I need one?

How can I verify that an SSL certificate has been signed with the correct key?

Let me know the answers when you can.

thanks,

-John

Hi John,

Good questions!

1A)

An intermediate certificate is a "subordinate" certificate issued by the trusted root Certificate Authority (CA) specifically to issue end-entity server certificates. The Certificate Authority can be thought of as a central repository that can be checked against to verify identity.

When you purchase an SSL cert, what you are really paying for is a certificate chain that begins at the trusted root CA, through the intermediate and ending with the SSL certificate issued to you. Such certificates are called chained root certificates.

Intermediate certs are important because creating certificates directly from the CA root certificate increases the risk of root certificate compromise. If the CA root certificate is compromised, the entire trust infrastructure built by the SSL provider will fail. The usage of intermediate certificates for issuing SSL certificates to end entities provides an added level of security.

Keep in mind that using intermediate certificates does not cause installation, performance, or compatibility issues.

2A)

To verify that your cert is signed with the correct key is fairly straightforward. All you need is an openssl binary for your workstation's operating system. Generally, this is included in Linux/Unix, but is available for download for Windows at http://www.openssl.org

Once you have SSL installed on your workstation, you can run the following two commands to check the certificate against the key. Basically, we are looking for the ouput to be *exactly* the same. If it is, you can

be confident that you have the correct cert/key pair.

If it is not, then you should consider redownloading the certificate from your issuer, and ensuring you are using the correct key ( check the file's timestamp, etc.... )

Run the following command for the cert:

openssl x509 -noout -modulus -in server.crt | openssl md5

Run the following command for the private key:

openssl rsa -noout -modulus -in myserver.key

*The modulus results for the cert and key should be the same.*

Example:

OpenSSL> rsa -noout -modulus -in xyz.key

Modulus=E7308831C44B4C464CF620DD9D1BE12961EF308490F7F7A6F5B0F6F6E58733D2FFAA2A77

4C21335DE48A753A8398F0965E5C55570F551EE9B70725241742BCB5F857ED2347D49384E10F86E1

3E2BD3E8E2CDE11FA91062D08A522DA3E01D48A50175F2B50C9C8821202B1482CD453243E429842A

E65BFDE72F92E8071FC5466631EBCB84E0814059FDDD9B2A8E780E58E4F0F530069989335249E32C

8AD8628231B67DD3076EF51FC430453901F7645B04B68D94F6721FBABDB07D18792584C6E57793E6

AF012BB6FE20484D440FCE7DB2D9347F62BB8AD797839E2D42C144BEFA2DCB6CA8C8E7B220890C81

C8E7050EB5638CBE4D81AEF0D6803BF06153A405

OpenSSL> x509 -noout -modulus -in xyz.crt |md5

Modulus=E7308831C44B4C464CF620DD9D1BE12961EF308490F7F7A6F5B0F6F6E58733D2FFAA2A77

4C21335DE48A753A8398F0965E5C55570F551EE9B70725241742BCB5F857ED2347D49384E10F86E1

3E2BD3E8E2CDE11FA91062D08A522DA3E01D48A50175F2B50C9C8821202B1482CD453243E429842A

E65BFDE72F92E8071FC5466631EBCB84E0814059FDDD9B2A8E780E58E4F0F530069989335249E32C

8AD8628231B67DD3076EF51FC430453901F7645B04B68D94F6721FBABDB07D18792584C6E57793E6

AF012BB6FE20484D440FCE7DB2D9347F62BB8AD797839E2D42C144BEFA2DCB6CA8C8E7B220890C81

C8E7050EB5638CBE4D81AEF0D6803BF06153A405

Hope that helps

--Woody

Thank you for the response. In regards to TLS:

How can I verify that the recipient's server is accepting my TLS connections?

Can you explain the difference between TLS Preferred and TLS Verify?

Thanks

- John

Hi John,

Excellent questions! Let's take them one by one.

1A)

To determine if the recipient's server is accepting my TLS connections:

Our first step is to determine a host we want to verify TLS against.

This may be as simple as searching your message tracking for connections to

a particular domain, or you may have to use a tool such as `dig` or `nslookup`

to determine the mx record for the domain you wish to check.

I'll use cisco.com as an example.

test.box> dig mx cisco.com

; <<>> DiG 9.4.3-P2 <<>> cisco.com MX

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18084

;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;cisco.com.                     IN      MX

;; ANSWER SECTION:

cisco.com.              86400   IN      MX      10 rcdn-mx-01.cisco.com.

cisco.com.              86400   IN      MX      15 ams-mx-01.cisco.com.

cisco.com.              86400   IN      MX      15 rtp-mx-01.cisco.com.

cisco.com.              86400   IN      MX      15 alln-mx-01.cisco.com.

---

In my scenario, I'd like to verify that I can negotiate a TLS connection to

rtp-mx-01.cisco.com.

In the current versions of AsyncOS, there is a built-in command called

`tlsverify` which will automate this for us.

Once we have the domain and mail exchanger for that domain, we can plug

them into `tlsverify` and the IronPort will do all the work for us

---

test.box> tlsverify

Enter the TLS domain to verify against:

[]> cisco.com

Enter the destination host to connect to.  Append the port (example.com:26) if you are not connecting on port 25:

[cisco.com]> rtp-mx-01.cisco.com

Connecting to 64.102.255.47 on port 25.

Connected to 64.102.255.47 from interface 1.1.1.1.

Checking TLS connection.

TLS connection established: protocol TLSv1, cipher RC4-SHA.

Verifying peer certificate.

Verifying certificate common name rtp-mx-01.cisco.com.

TLS certificate match rtp-mx-01.cisco.com

TLS certificate verified.

TLS connection to 64.102.255.47 succeeded.

TLS successfully connected to rtp-mx-01.cisco.com.

TLS verification completed.

---

Success! We can now be confident that if we do set TLS to preferred or required,

that our connections to this mail host will be successful. As a precautionary measure,

we shoiuld check all 4 MX records to ensure we receive the same successful results.

---

If we should happen to check a domain that does not negotiate TLS with our IronPort,

`tlsverify` will show us the error so we know why our connection failed.

---

Would you like to verify another domain? [Y]>

Enter the TLS domain to verify against:

[cisco.com]> bigfakedomain.org

Enter the destination host to connect to.  Append the port (example.com:26) if you are not connecting on port 25:

[rtp-mx-01.cisco.com]> mail.bigfakedomain.org

Connecting to 2.2.2.2 on port 25.

Connected to 2.2.2.2 from interface 1.1.1.1.

Checking TLS connection.

STARTTLS command not supported at 2.2.2.2.

TLS was required but could not be successfully negotiated.

Failed to connect to mail.grapeape.org.

TLS verification completed.

----

From the output above, we see that the STARTTLS command is not supported on the

remote host. This tells us they are not advertising TLS, and it is not possible

to negotiate a TLS connection with that host.

2A)

When configuring your listeners, you can choose from three states for TLS:

1.  Off  - No TLS connections are attempted

2.  Preferred: TLS can negotiate from the remote MTA to the Cisco IronPort appliance. However, if the remote MTA does not negotiate (prior to receiving a 220 response), the SMTP transaction will continue "in the clear" (not encrypted). No attempt is made to verify if the certificate originates from a trusted certificate authority. If an error occurs after the 220 response is received the SMTP transaction does not fall back to clear text.

3. Required: TLS must be negotiated from the remote MTA to the Cisco IronPort appliance. No attempt is made to verify the domain's certificate. If the negotiation fails, no email is sent through the connection. If the negotiation succeeds, the mail is delivered via an encrypted session.

Hope that helps,

--Woody

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: