|
We recently had one of our users targeted in a sophisticated spear-phishing email. The spoofer knew a lot about the business and they spoofed the FROM header to our CEO's actual email address. I'm just a jack of all trades sysadmin so I had SPF setup for our domain but not DKIM or DMARC (I actually had never heard of DMARC prior to this incident) and I was under the assumption that SPF was enough to protect us. After investigating the incident, I determined that the SPF record passed because the spoofer's domain they sent the email from had SPF records setup and what I learned is that SPF acts on the "envelope from" and not the normal "message from". Therefore they were able to set the return email to their own domain and spoof the "message from" to our CEO's email address. I've been told that I should setup DKIM and DMARC in addition to SPF. Some information about our email situation: - We use Office 365 and all our mailboxes are here. We send and receive email here. - We use Mandrill for transactional email. We only send from here. - We use MailChimp for marketing campaign email. We only send from here. Here are the records in our DNS right now. SPF code:code:code:code:code:If SPF works on the envelope headers, that means a malicious domain with SPF records setup can still spoof the message headers. How does DKIM and DMARC work to stop message headers from being spoofed as well? I understand what DKIM is, just not how it prevents spoofing. My understanding is that the email server signs the email with a private key and the recipient server checks the DKIM header for a domain name which then checks the domain DNS for a DKIM record which then takes the public key from that DKIM record to check the validity of the DKIM signature/headers. Ok... but what if a spoofer just doesn't send a DKIM header, then DKIM is never checked and the FROM message header can still be spoofed, yes? Is this where DMARC comes into play? kiwid fucked around with this message at 03:13 on Oct 27, 2017 |
#
?
Oct 26, 2017 20:58
|
|
|
|
| # ? Apr 19, 2024 23:21 |
|
|
I think DKIM just lets you prove a mail was sent by you, but not prove that it wasn't sent by you. I don't know anything about DMARC for outbound mail. The only reason I know any of this was learning enough to explain to our hosting people who shouldn't need their customers to explain their own service.
|
|
#
?
Oct 27, 2017 18:37
|
|
|
I ended up figuring it all out with this training series: https://www.m3aawg.org/activities/training/dmarc-training-series The key was the second video. I didn't understand how DMARC alignment works but I do now. To answer my own question, DMARC requires that either SPF or DKIM passes (doesn't have to be both) and that it matches the "header from" or "message header" domain to either the envelope header if SPF passed, or the DKIM domain if DKIM passed which makes it almost impossible to be spoofed. The only way you could still be spoofed is that if one of your sending services (mail chimp, mandrill, etc.) allows another account to send as your domain which they won't because they require you to authenticate your domain. Or if you become compromised in another way (mail servers, dns, etc.). kiwid fucked around with this message at 21:45 on Oct 27, 2017 |
|
#
?
Oct 27, 2017 21:37
|
|
|
You're almost there -- but DMARC is the final sauce that tells other email servers what to do in response to your DKIM/SPF checks. With code:After running for a while and checking the DMARC reports your postmaster will get emailed back from other mail servers, you'll want to check that there aren't other email services that might be running out there besides with the ones you listed. Once you're confident you can start moving into p=quarantine which will flag as spam and ramp the percentage up with the code:Hope that made sense. I'm a jack of all trades sysadmin too, learned about it about the same way you do, hope I'm not wrong about this, but, I've been running it for a year now. Also, be prepared to deal with external agencies in the future that understand it far less than you already do!
|
|
#
?
Oct 27, 2017 22:30
|
|
|
SPF is to whitelist what servers can send mail. DKIM is to sign each and every outgoing mail. DMARC is for receiving feedback from other servers on ham and spam from your domain and tell recipients what to do with spam. MrMoo fucked around with this message at 15:34 on Oct 28, 2017 |
|
#
?
Oct 28, 2017 15:30
|
|
|
As Wil said, you want to be in reporting mode only while you make sure everything in your org is SPF/DKIM ready and find any issues before you start telling people to reject. https://dmarc.postmarkapp.com/ is a nice free tool offered by Postmark for doing exactly this. Very easy to setup, you configure your dmarc feedback to go here, they consolidate it into a nice report that shows you what you may be missing. Once you get reports that show full alignment from everything you know is legit then you can start blocking. You can then leave it on just to monitor for suspicious activity. Really though, if somebody is trying to spearfish you, this doesn't really help. Our pentesters always go out and buy some slight variation of our domain and fish from there.
|
|
#
?
Oct 30, 2017 14:23
|
|
|
Might be worth implementing something like this as well, which will help provide some additional warning and you're in Office 365: https://gcits.com/knowledge-base/warn-users-external-email-arrives-display-name-someone-organisation/
|
|
#
?
Oct 30, 2017 16:37
|
|
|
|
| # ? Apr 19, 2024 23:21 |
|
|
WilWheaton posted:With Nukelear v.2 posted:As Wil said, you want to be in reporting mode only while you make sure everything in your org is SPF/DKIM ready and find any issues before you start telling people to reject. Ah yes, I was aware of that and forgot to mention it. We're actually still in "p=none" mode right now but since all incoming email is at one source (Office 365) I setup a mail transport rule (below screenshot) that basically turns it into a "p=quarantine" for inside the organization and "p=none" for outside the organization. Once we monitor the reports for a while, we're definitely going to slowly ramp up the policy until we're eventually at "p=reject" with 100%. Office 365 Rule:  Maneki Neko posted:Might be worth implementing something like this as well, which will help provide some additional warning and you're in Office 365: Thanks, I'll check this out.
|
|
#
?
Oct 31, 2017 16:05
|
|