How an I prevent spoofed email using IronPort C160?

[keithsauer507]

As part of Security Awareness training and testing we contracted a company called knowbe4 to initiate some random spoofed e-mail tests into our domain.  Normally I would have figured this would fail because when email comes into the C160 and it has our @domainname.com on it, it needs to validate the DKIM signature, and if it was not sent from our organization, IronPort would not have signed it, correct?

Anyway the security awareness organization was able to successfully send an e-mail inbound and make it appear as if it came from CEO@domain.com (which we do not have a mailbox with that name, but I'm sure he certainly could have done research and used our real CEO's email address.).  In Outlook it does appear as CEO@domain.com in the from box, but when you search message tracking for emails coming from that address you get nothing.  Upon further inspection of the e-mail headers, the message actually came from bounces+78188-4be9-username=domain.com@pstemail.knowbe4.com.  So it matched policy DEFAULT for inbound mail policies and eventually it was successfully signed with domain key profile and DKIM profile matching CEO@domain.com, then queued for delivery.

How can an email arriving from one server "morph" into another?  Is there some sort of vulnerability that this organization is taking advantage of, perhaps some kind of active script that the IronPort ends up acting upon to alter the email address and sign it so it passes through?  This was a test today, but we need to plug this hole because the bad guys are going to use this technique to make phishing emails look legitimate coming from internal users.

[Paul Cardelli]

I use knowbe4 as well, great phishing test templates, and what I found to work best to fight Domain spoofing are the following:

- Implement DMARC/SPF/DKIM DNS records and keys - You will want to set these to passive initially. I personally recommend using dmarcian.com they have tools to help with implementation. Initially you will just want to be in monitor mode then start suggesting actions that gateways should take based on your DNS records. (This will protect your domain from being spoofed to gateway or provider that has DMARC/SPF/DKIM enabled)

- Maintain your DNS SPF records (these are to used to help you authorize who can send emails from as your domains)

- Here is a good how-to video for configuring your appliance to block domain spoofing. You will want to add any providers you want to allow to spoof such as ADP, training, and other third party vendors that generally spoof your domain to send emails to your employees. https://supportforums.cisco.com/video/11932126/configure-spoof-protection-exception-lists

- Create a second mail flow policy similar to your allowspoof one, but turn off spam filtering, I called mine KnowBe4.

- Create a new HAT and call that KnowBe4 and point it to the new policy. Add all the Knowbe4 or who ever your phishing simulation provider is to this HAT table. I suggest adding a description so you will know which ones to delete later on.

You should now have taking care of e-mail spoofing, you will want to monitor this closely. Also if you are using Email Encryption you need to make sure the vendor's (even if using Cisco) gateways are added to your SPF record and your HAT table AllowSpoof list.

Finally I would recommend enabling DMARC feature in your appliance, this will help filter out and report to email providers and gateways who is spoofing their domains, it will also increase your filtering power, but it does not stop all spam just one more thing to eliminate low hanging fruit.

Knowbe4's test phish is a good way to test for spoofing, and your employees.

[keithsauer507]

Question on that video, which was very informative...

They put domain names in the new HAT Policy allow spoof.  Right now we have an inbound content filter ballec blockspoof and it basically says
If mail-from --"@ourdomain.com"

and if remote ip !="12.173.x.x"

and if remote ip !="206.71.x.x"

and if remote ip !="66.132.x.x"

Then the action is Quarantine("Policy")

This seemed to work fine for our domain and other providers / applications that need to send email that appears from us, but for some reason it did not work for knowbe4.

[Paul Cardelli]

Yeah, that is what I call an negative filter list we used to do that as well, but found that the HAT table method with the exception table worked best. Also make sure that your listeners are setup right you should have a Private listener for interal and a Public listener for external. This was our only catch during our migration as someone had set both of our listeners to public.

Knowbe4 is very good at what they do, and can craft a good phishing email. The filter you are using does not catch their spoofed email because they are not spoofing all the way. There is spoofing it at the message or the envelope. I found that the filter only checks one of these. I could be wrong, but following the videos method seemed to work best for us. Also a lot easier to keep track of and clean up then using the filter method.

Use the message tracking and you can see what the filter is and is not triggering off of.

By the way I didn't delete my filter, I just don't have it applied to a policy. This way I can look back at my old filter to make sure I did not miss one of the systems. Also cleaned up a lot of old vendors gateways. MXtoolbox.com and ipvoid.com were my friends in identifying all the old hosts.

[keithsauer507]

" Also make sure that your listeners are setup right you should have a Private listener and a Public listener. This was our only catch."

I'd like to clarify this.  Our listener is called AllMail.  It is a Public listener.  Under Network > Listeners this is the only one listed.  Do you think this is why that video you posted that I followed stopped all mail and I had to quickly undo?  Or maybe because I put the SPOOFALLOW at the bottom of the HAT table (and not directly above whitelist)?

I'd like to see some documentation on the differences between public and private listeners and see if there is a better way to setup our IronPort.  

[Paul Cardelli]

Yes, you should have two listeners and not just one. There is wizard to create them before you apply them to the interface. I found by having two listeners the filtering is working much better. On ours we were using two public listeners and when I made the change I had the same results as you. Thats why I warned about the listeners being configured correctly.

I went through the installation process in the manual from scratch and found that they recommend a private listener for your inside mail servers and a public listener for your public facing part. The listeners can still be on the same physical interface, ours are not. 

The biggest difference for the private listeners is that the default HAT tables are very simple. You have your relay and blocked. So I'm guessing that when we switched to the new private listener we cleaned out some of the misconfigured HAT Tables and Mail Flow Policies that were blocking our domain from sending out e-mails based on the exception table. 

Now when we are configuring Mail flow policies or HAT tables it is very obvious that we are configuring the right listener.

[Ken Stieers]

Grab the 8.5 user guides.  The advanced one covers listener config in depth.

Basically, the "private" listener is "inside" and is the one your mail system talks to.

The "public" listener is "outside" and is the one exposed to the internet.  In our case, they're on the same subnet in the DMZ with different firewall rules, etc.

It makes things logically easier to deal with.

[keithsauer507]

Thanks Ken. I think we will toy with this.  The second interface is not connected right now.

I think we will eventually migrate to a private listener on 192.168.2.x subnet (DMZ2) and we will just reconfigure the public listener on our 192.168.1.x subnet (DMZ1).

In the firewall we can change the configuration so our exchange servers forward mail to the new 192.168.2.x ip we end up choosing for the private listener.

In the video referenced above, I am almost certain that is why that procedure worked (he had an Internal Mail and External Mail listener).

[Paul Cardelli]

Email spoofing is not new. It is up to the email admin to properly configure DMARC/SPF/DKIM and their email appliance to prevent it. Hopefully the information I provided will help point you in the right direction. I recommend plugging that whole all the way, and slowly as their are legitimate reason to spoof e-mails.

Legit Spoofing email examples:

- Hotel and travel reservation systems

- Tracking Packages with UPS, FedEx, USPS

- Social media notifications

I may not agree with email domain spoofing, especially because it causes Phishing and Spam issues. When you start to implement DMARC you may be surprised who is also sending e-mails as you. Some good some very bad.