We had a Social Engineering vulnerability assessment performed recently and one of the parts of this assessment was a spoofed e-mail with a link to a fake website. It was a test to see how many employees would click on the link and go to this website and put their windows password in.
The spoofed e-mail came from our vendor, but in the e-mail headers they made it look like it came from us HR@xyzcompany.com for example, if we are xyzcompany.com.
Is there a way on the IronPort to prevent this type of spoofed e-mail coming inbound? I don't see why any e-mail from our domain should be coming inbound. E-mail with our domain in it should only be coming from internally going outbound.
I think the old Barracuda e-mail filter that we used to use prior to IronPort did this, but I forget the terminology or what the setting was called.
Here is some information below that may help. Normally you shouldn't see inbound mail where the sender is from your domain, because like you said, when one employee sends to another employee, it should all reside in Exchange.
However, there may be a case where an employee goes to nytimes.com, reads a good article and wants to email themselves the article for later reading.
What they do, is put in their work email address as both the sender and the recipient, and that's how that situation would arise.
1. How do I stop people from spoofing mail from my domain?
Good point, well maybe then I wonder if we can use DKIM to validate if the e-mail was generated by us or not, and if not, we could prepend something to the subject like (possible spam).
My understanding is that all of our e-mail comes out of exchange and goes into IronPort. From there it adds dkim or whatever other policies we have, plus anti-virus and anti-spam. Then from there it goes to it's destination.
Well if some hacker is using an open relay to pretend they are us, they send into our ironport, perhaps there will be no DKIM infromation, since they don't have that half of the DKIM key, so they didn't generate it and stick it in their mail headers.
Therefore IronPort can say, hey, this is a hardfail, it does not pass dkim. Then apply whatever processing we want (move to a quarrentine queue, or prepend something to the subject, etc...).
I don't think I wan to scan all incoming e-mail for DKIM, because not all ISP's support it. So I don't want to see a high percentage of misrepresented "possible spam". Therefore I'll do the check in two stages.. if the header "says" it's coming from our domain (easy to spoof), it has to pass dkim (because we apply dkim), or else prepend the subject line.
Any DKIM experts out there that could verify this? I'm trying to find an open mail relay somehwere to test it.
We've had a content filter to help identify spoofed e-mail since we implemented the ironports. I have two listeners setup on the ironport, so the content filter is something like this:
if receiving listener = external listener and envelope sender ends with @compay.com
I setup the qurantine, so we could monitor what was getting caught. This helped in identifying the exceptions we had to add, which is normally by IP address.
Recently, we noticed that the envelope address wasn't being spoofed, but the FROM address was. I added an additional content filter that searches the FROM header, and checks to see if it's spoofed. For the second content filter, we alter the subject by adding a disclaimer that this message was not originated by us, but it contains a from address of our company. This filter catches things like craigslist adds that people are sending themselves, and any external distribution lists like yahoo/google groups. This allows people to still receive the messages, but they can visually see the subject line is altered and it provides them a warning.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...