1 / 92

Protecting Email with DMARC

Protecting Email with DMARC. Tim Draegen, February 26th & 27th 2014. What we’re trying to fix. Introduction. About The Presenter. mid/late- 80’s: Apple IIe programming, FidoNet early 90’s: x86 programming (fractals!) mid 90’s to 2000: intern->employee @ 

dandre
Télécharger la présentation

Protecting Email with DMARC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Protecting Email with DMARC Tim Draegen, February 26th & 27th 2014

  2. What we’re trying to fix. Introduction

  3. About The Presenter • mid/late-80’s: Apple IIeprogramming, FidoNet • early 90’s: x86 programming (fractals!) • mid 90’s to 2000: intern->employee @  • 2000-2004: three 1-year stints at startups (BSD) • 2004-2008: IronPort/Cisco (email security) • 2009-2010: Nominum (large DNS software) • 2010-2012: Co-founded email intel company • 2013-now: • Message Bus (email@scalesoftware) • dmarcian.com

  4. About The Presenter • mid/late-80’s: Apple IIeprogramming, FidoNet • early 90’s: x86 programming (fractals!) • mid 90’s to 2000: intern->employee @  • 2000-2004: three 1-year stints at startups (BSD) • 2004-2008: IronPort/Cisco (email security) • 2009-2010: Nominum (large DNS software) • 2010-2012: Co-founded email intel company • 2013-now: • Message Bus (email@scalesoftware) • dmarcian.com

  5. Email’s Fundamental Flaw • Anyone can pretend to be you.

  6. Let The Receivers Figure It Out?

  7. An Insidious Situation • Blocking legitimate email is really bad: • Support costs = ouch! • Heads might roll depending on recipient • In ISP-world, users go somewhere else • There is a terribly thin line between the sloppiest legitimate email and expertly crafted phishing. • ∴ the most effective fraud gets through.. • ..and criminals are incentivized to get better!

  8. Whoops!

  9. What’s The Worst That Can Happen? • A sample of spear-phishing: RSA Hack • RSA supplies most of the world with 2-factor authentication systems (“SecurID”) to protect sensitive data. • Attackers targeted EMC (parent company of RSA) HR teams and used spear-phishing to successfully install malware within RSA. • Result? • $66m RSA loss, • Stolen SecurID data • Used to attack: http://www.f-secure.com/weblog/archives/00002226.html http://www.theregister.co.uk/2011/07/27/rsa_security_breach/

  10. Can The Flaw Be Fixed? • Yes!

  11. Technology That Fixes This.. • ..is called email authentication. Two forms: • SPF (Sender Policy Framework) • Allows receivers to determine legitimacy based on where the email comes from. • “path based” • DKIM (DomainKeys Identified Mail) • Allows receivers to determine legitimacy based on content of email. • “signature based”

  12. Lessons Learned From SPF & DKIM • No consistency to how DKIM and SPF are deployed. • Receivers used whatever was deployed/available. • Senders tried hard to check the box. • Receivers couldn’t rely on accuracy of Sender’s auth. • As a rule, Senders failed to cover all email, significantly reducing utility. • Senders had no visibility into email domains usage. • Impossible to discover usage through auditing process. • ROI or “email authentication” didn’t add up

  13. Just How Big Is Email? http://blogs.smartertools.com/2011/08/29/the-value-of-email/ Email is really big. No centralized control, used by everyone all the time. Lots of people have been trying to fix this thing for a long time. ..and it’s actually changing!

  14. Time Sender Adoption Receiver Adoption How Long To Fix? 2003-2006: building blocks (SPF, DomainKeys, DKIM) “I’ve heard this helps” Nice to have as anti-spam input, not reliable 2007-2009: prototype authenticated email model PayPal innovates, Financial Services publishes recommendations Yahoo & Gmail reject fake PayPal email, other big providers take note 2010-2011: make it work at internet scale PayPal funds/organizes effort to standardize the model Big webmail providers commit to support and implement 2012-2013: early adopters Senders with fraud and clean infrastructures deploy Big consumer mailboxes and those that can roll their own deploy 2014: ??? More at: http://forums.dmarcian.com/discussion/25/brief-history 14

  15. Complementary Standards SPF DKIM Is the messenger (server) permitted? Is the signature authentic? Path-based (RFC 4408) Authorized servers published via simple DNS record Very low deployment cost Forwarding breaks SPF Signature-based (RFC 6376) Requires cryptographic operation by email gateways Public keys published via DNS Can survive forwarding

  16. SPF DKIM DMARC • Overlay – Leverages SPF and DKIM as authentication mechanisms • Describes how to deploy SPF and DKIM… consistency • Visibility – Describes new feedback mechanism • Gives senders visibility into how receivers process their email • Protection – Senders can declare how to process auth-failing email • Specifies a DNS-based policy model that incorporating SPF + DKIM results Is the messenger (server) permitted? Is the signature authentic? Path-based (RFC 4408) Authorized servers published via simple DNS record Very low deployment cost Forwarding breaks SPF Signature-based (RFC 6376) Requires cryptographic operation by email gateways Public keys published via DNS Can survive forwarding

  17. DMARC Meets “Lessons Learned” • No Consistency to how DKIM and SPF are deployed. • Receivers used whatever was deployed/available. • Senders tried hard to check the box. • Receivers couldn’t rely on accuracy of Sender’s auth. • As a rule, Senders failed to cover all email, significantly reducing utility. • Senders had no visibility into email domains usage. • Possible to discover usage through auditing process. • ROI or “email authentication” adds up

  18. DMARC Adoption BIG RECEIVERS: “ORGANIC” RECEIVERS: From: https://dmarcian.com/dmarc_adoption/

  19. What DMARC Can (and Cannot) Do • DMARC fixes a fundamental flaw: • Is this email really from where it says it’s from? • DMARC makes Domain Identifiers a reality: • This email really does come from EXAMPLE.ORG! • So what: • Strong exact-domain anti-phishing (“Reject the fakers”) • + telemetry that powers “take down” services (“mitigation providers”) • Domain reputation, finally! (“Do my users want this email?”) • Build on it. EG: webmail clients with “Meta inbox” for customer notifications only

  20. DMARC As Phishing Prevention • Less malicious email being delivered: • PayPal: customer reports of suspicious email dropped in US by > 70% in 2013 • Microsoft: Outlook.com customer reports of phishing dropped > 50% in 2013 • Blocked When It Matters: • PayPal: DMARC stopped ~25 million attacks during holiday buying season • Google: reduction of 5000% in spoofing of major corporation during their busiest season. • Twitter: 45 days monitoring = 2.5 billion spoofing emails. Now all rejected. • Adoption: • December 2013, Google reported > 90% of email received by Gmail users is now authenticated by DKIM or SPF. > 80,000 domains publishing DMARC allowing reject. http://dmarc.org/news/press_release_20140218.html

  21. Fraud post-DMARC • When DMARC controls are put into place, criminals move away from your protected domains. Fraud moves to: • Look-a-like domains* • Cousin domains* • Softer targets • Some have argued that this diminishes the value of DMARC, that investing heavily into exact-domain anti-phishing is not worth it if criminals will simply move on to other targets or exploit look-a-like or cousin domains. • These are valid arguments if DMARC is only an exact-domain anti-phishing measure. (If so, run “p=none” forever and collect fraud intel for analysis, shutdown, and prosecution.) * Check with your organization to see if domains have been defensively registered – DMARC reject policy prevents abuse.

  22. BREAKING NEWS!! DMARC Is Not Just Anti-Phishing • Advanced receivers are finally connecting the dots for email senders: • Authentication is required if you’re sending email and expect it to be delivered. This means DMARC-compliant email. • The From:-domain is the reputation building block for the post-anti-spam world. From:-domain cannot be trusted unless authenticated, and this means DMARC-compliant email. • Goal is email authentication for all email. This means delivery of unauthenticated email will only continue to get more difficult, with the solution being “authenticate your email”. • Invest heavily in exact-domain anti-phishing via DMARC? Maybe not. • Invest in sending DMARC-compliant email? If you want your email to be delivered! • (and get exact-domain anti-phishing anyway) https://support.google.com/mail/answer/81126?hl=en

  23. Break

  24. Internet primers for the rest of us. Basics

  25. Domain Name System (DNS) Basics • Giant distributed key/value store: • You ask for specific type of resource for key(label) • “give me X resource for Y label… get back Z answer” • Resources can be: • A, AAAA, MX, TXT… • Labels can be: • Dot-separated chunks of 64-byte strings • EG: this.is.a.label.com • Answers are based on resource.

  26. The DNS Is Very Big • Where can I find server for site.com? • Enormous amount of traffic • X # of root servers. They tell you where to go for answers, EG: dk.example.org: • Dear Root Server, please tell me which server answers for DK.EXAMPLE.ORG • ROOT SERVER: no problem, talk to ORG-NAME-SERVER • Dear ORG-NAME-SERVER, please tell me which servers answers for DK.EXAMPLE.ORG • ORG-NAME-SERVER: I can’t tell you about DK.EXAMPLE.ORG, but I can tell you which server is responsible for EXAMPLE.ORG. That would be…. EXAMPLE-NAME-SERVER • Dear EXAMPLE-NAME-SERVER: please tell me which servers answers for DK.EXAMPLE.ORG • EXAMPLE-NAME-SERVER: sure thing, DK.EXAMPLE.ORG can be found at 1.2.3.4 • The thing asking questions is called a resolver. Usually libraries, found everywhere. • The things providing answers are called name servers. Some are authoritative. • Because traffic volumes can be enormous, resolvers cache results to avoid hammering name servers. Tradeoff with ability to rapidly change DNS entries.

  27. Simple Mail Transport Protocol (SMTP) Basics • SMTP describes how email moves around the Internet. It goes like this: • User writes a piece of email to friend@example.org, hits SEND. • Email client connects to outbound server (smtp.sample.net). • Outbound server agrees to deliver email for user. • Server determines where email is going -> the recipient’s domain. • Server issues MX query for EXAMPLE.ORG, gets back list of accepting servers. • Server connects to MAIL.EXAMPLE.ORG. • ..SMTP conversation now begins..

  28. SMTP Conversation Outbound Email Server (smtp.sample.net) Receiving Server (mail.example.org) HELO smtp.sample.net 250 mail.example.org MAIL FROM: <foe@sample.net> 250 sender <foe@sample.net> ok RCPT TO: <friend@example.org> 250 recipient <friend@example.org> ok DATA 354 go ahead (email content here) 250 ok: Message 17763873 accepted QUIT 221 mail.example.org (email now subject to anti-spam and then delivery)

  29. Email Content • Composed of 2 things: • Headers • Body Return-Path: <foe@sample.net> Delivered-To: friend@example.org Authentication-Results: mail.example.org; spf=pass (example.org: domain of foe@sample.net designates 1.2.3.4 as permitted sender) smtp.mail=foe@sample.net; dkim=pass header.i=@sample.net Received: from .. DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sample.net; s=february_2014; i=@sample.net; q=dns/txt; h= .. ; bh= .. ; b= .. Date: Wed, 19 Feb 2014 12:39:06 -0500 From: “Fred“ <foe@sample.net> To: “Frank Riend” <friend@example.org> Subject: REMINDER – don’t mess this up, Frank! Hi, please don’t forget about the meeting. It’s very important! Your friend, Fred

  30. DMARC Identifiers • DMARC keys off of: • From: domain • And looks to reconcile the key with: • DKIM “d= domain” • SPF results

  31. Identifiers In Content Return-Path: <foe@sample.net> Delivered-To: friend@example.org Authentication-Results: mail.example.org; spf=pass (example.org: domain of foe@sample.net designates 1.2.3.4 as permitted sender) smtp.mail=foe@sample.net; dkim=pass header.i=@sample.net Received: from .. DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sample.net; s=february_2014; i=@sample.net; q=dns/txt; h= .. ; bh= .. ; b= .. Date: Wed, 19 Feb 2014 12:39:06 -0500 From: “Fred“ <foe@sample.net> To: “Frank Riend” <friend@example.org> Subject: REMINDER – don’t mess this up, Frank! Hi, please don’t forget about the meeting. It’s very important! Your friend, Fred DKIM d= domain From: domain

  32. Identifiers in SMTP Conversation Outbound Email Server (smtp.sample.net) Receiving Server (mail.example.org) HELO smtp.sample.net 250 mail.example.org MAIL FROM: <foe@sample.net> 250 sender <foe@sample.net> ok Envelope domain RCPT TO: <friend@example.org> 250 recipient <friend@example.org> ok DATA 354 go ahead (email content here) 250 ok: Message 17763873 accepted QUIT 221 mail.example.org (email now subject to anti-spam and then delivery)

  33. Real World Complications • Email flows from the user straight to the destination, right? • Unfortunately, no. • Forwarders.. • Mailing lists.. • Forwarding from old accounts to new • (perhaps to take advantage of newer UIs) • Fraud.. • Anti-spam engines.. • Destination down.. • Transient errors..

  34. Real World Complications • Email flows from the user straight to the destination, right? • Unfortunately, no. • Forwarders.. • Mailing lists.. • Forwarding from old accounts to new • (perhaps to take advantage of newer UIs) • Fraud.. • Anti-spam engines.. • Destination down.. • Transient errors..

  35. Break

  36. Domain-based Message Authentication, Reporting & Conformance DMARC

  37. Policy Key • An email’s “From:-header” domain is the policy key for DMARC. • Lots going on when email is delivered. • Only thing that should be present in email all the time. • (data shows that it is, when it is not, its malformed junk) • What about Sender: ? • Ignored by DMARC. • Multiple policy keys is a broken concept. • No way to give control to domain owner otherwise. • From: = most stable thing around • ..and as close to user-visible as possible

  38. Authenticated Identifiers • SPF and DKIM return stable domain-level identifiers. • Not all email uses these technologies today, but they are readily available. • SPF and DKIM checks are easy to perform. • When checks have been made and results are available to inspect..

  39. Authenticated Identifiers Return-Path: <foe@sample.net> Delivered-To: friend@example.org Authentication-Results: mail.example.org; spf=pass (example.org: domain of foe@sample.net designates 1.2.3.4 as permitted sender) smtp.mail=foe@sample.net; dkim=pass header.i=@sample.net Received: from .. DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sample.net; s=february_2014; i=@sample.net; q=dns/txt; h= .. ; bh= .. ; b= .. Date: Wed, 19 Feb 2014 12:39:06 -0500 From: “Fred“ <foe@sample.net> To: “Frank Riend” <friend@example.org> Subject: REMINDER – don’t mess this up, Frank! Hi, please don’t forget about the meeting. It’s very important! Your friend, Fred Outbound Email Server (smtp.sample.net) Receiving Server (mail.example.org) HELO smtp.sample.net 250 mail.example.org DKIM authenticated identifier MAIL FROM: <foe@sample.net> 250 sender <foe@sample.net> ok From: domain RCPT TO: <friend@example.org> 250 recipient <friend@example.org> ok DATA 354 go ahead SPF authenticated identifier (email content here) 250 ok: Message 17763873 accepted QUIT 221 mail.example.org

  40. Identifier Alignment • Why? Receivers need simple way to understand if authentication is relevant.

  41. Identifier Alignment • Why? Receivers need simple way to understand if authentication is relevant.

  42. Identifier Alignment • Why? Receivers need simple way to understand if authentication is relevant.

  43. Identifier Alignment • Why? Receivers need simple way to understand if authentication is relevant.

  44. Identifier Alignment • Why? Receivers need simple way to understand if authentication is relevant.

  45. Identifier Alignment • Why? Receivers need simple way to understand if authentication is relevant.

  46. Identifier Alignment • Why? Receivers need simple way to understand if authentication is relevant.

  47. Identifier Alignment • Why? Receivers need simple way to understand if authentication is relevant.

  48. DMARC Record Discovery • Receiver gets piece of email, From:-domain = EXAMPLE.ORG. Receiver makes DNS query for TXT record at label: _dmarc.example.org • DMARC records are discovered in 1 of 2 ways: • Directly: _dmarc.europe.engineering.example.org • If no DMARC record at _dmarc.europe.engineering.example.org: • Check the Organizational Domain: • _dmarc.example.org • No more than 2 DNS queries to determine DMARC records, even if label is huge.

  49. DMARC Records • Simple list of tag/values, eg: • v=DMARC1; p=none; rua=mailto:reports@example.org

  50. DMARC Record Options

More Related