SPAM Prevention Using DNS Solutions - PowerPoint PPT Presentation

1 / 35
About This Presentation
Title:

SPAM Prevention Using DNS Solutions

Description:

Oct 1st ,2004 Microsoft, MSN and Hotmail will all start using Sender ID to ... formats, there is also the DeGroot hack from the book 'DNS & Bind' both work fine ... – PowerPoint PPT presentation

Number of Views:168
Avg rating:3.0/5.0
Slides: 36
Provided by: tvn2
Category:

less

Transcript and Presenter's Notes

Title: SPAM Prevention Using DNS Solutions


1
SPAM Prevention Using DNS Solutions
  • Implementing reverse domain name services (rDNS)
    and planning for SPF Classic
  • Presented by Ed Horley
  • Date May 2005

2
Overview
  • SPAM prevention is the primary reason that rDNS
    and SPF Classic will become de jure within
    approximately 1-2 years (IETF ratified)
  • Current methods for SPAM prevention are de facto
    solutions filtering, black/white lists, etc
  • Reverse DNS (rDNS) is a great quick check to
    determine if an MTA is being run and maintained
    correctly but it can be spoofed
  • Sender Policy Framework (SPF v1) or SPF Classic
    is being used by service providers to confirm
    that the mail servers they are receiving mail
    from are authorized to do so on behalf of the
    sending domain, these records are published by
    the sending domain

3
Overview Continued
  • Future additional solutions for SPAM prevention
    are Yahoos DomainKeys, Sender Verification and
    perhaps Microsofts Puzzle Solution (unlikely)
  • Sender ID has been rejected by the IETF as a
    proposed standard (de jure) due to inclusion of
    patented technology by Microsoft and Microsoft
    has modified it and resubmitted. It may or may
    not make it through this time depending on the
    dependencies the working committee see on the
    patented or protected intellectual property

4
Current Solutions Overview
  • Current de facto solutions
  • Blacklists (IP and DNS based)
  • rDNS (optional see RFC2505 2.5)
  • Anti-spam filtering (Bayesian and others)
  • Anti-spam services (Brightmail, Postini,
    Commtouch, etc)
  • Hardware appliance filters / services
  • Custom built scripts and applications
  • Sender Verification (Several different formats
    exist)
  • Whitelists (IP and DNS based)
  • SPF Classic (optional)

5
Solutions Used Today
  • Blacklists
  • SpamCop
  • MAPS
  • ORDB
  • SPAMhaus
  • Spews
  • SURBL
  • Mail-abuse
  • DSBL
  • DNSBL
  • DNSRBL
  • Client filters
  • Audiotrieve InBoxer
  • Cloudmark SpamNet
  • Lyris MailShield
  • McAfee SpamKiller
  • Aladdin SpamCatcher
  • Sunbelt IHateSpam
  • SpamBayes (open source)
  • Spam Bully
  • MailFrontier Matador
  • Cloudmark Spamnet

6
Solutions Used Today
  • Server filters
  • Exchange IMF (comes bundled with Exchange)
  • XWall
  • Vircom modusGate
  • Sophos PureMessage
  • Proofpoint Protection
  • SurfControl
  • Symantec
  • Trend Micro
  • GFI MailEssentials
  • Sybari Antigen (Microsoft Aquired Feb 2005)
  • Network Associates / Mcafee
  • SpamAssassin (open source)
  • Declude JunkMail
  • Hardware Appliances
  • Barracuda 300
  • BorderWare MXtreme
  • CypherTrust IronMail
  • IronPort C60
  • Mail Foundry
  • Sendio ICE Box
  • Tumbleweed
  • Subscription Services
  • Brightmail
  • Commtouch
  • Greenview Data
  • Katharion
  • Postini
  • PUREmail

7
The Proposed Solutions
  • Short term solutions
  • Internet Engineering Task Force (IETF) draft
    rfcs
  • Sender Policy Framework (SPF Classic)
  • Sender ID (SPF Classic PRA) Microsoft draft
    rfc (maybe?)
  • DomainKeys (Google and Yahoo have implemented)
  • Long term solutions
  • Internet Research Task Force (IRTF)
  • New version / next generation of SMTP?

8
What to do now?
  • SMTP mail gateway filters (hardware or software)
  • Consider a commercial service (depends on the
    amount and type of traffic you except to see for
    your environment)
  • Software e-mail client filters (Small business
    accounts)
  • Blacklists / Whitelists (Enterprise and Service
    Providers)
  • rDNS (anyone running an MTA that sends traffic to
    the Internet)
  • SPF Classic (anyone running an MTA that sends
    traffic to the Internet)
  • DomainKeys (Service Providers)

9
What is rDNS?
  • rDNS is an acronym for reverse DNS
  • It is a method of name resolution in which an IP
    address is resolved into a domain name
  • It is the opposite of the typical resolution
    method of DNS which resolves domain names into IP
    addresses
  • It utilizes the existing DNS infrastructure by
    using a special reserved domain name
    in-addr.arpa.
  • IP addresses are more specific left to right and
    domain names are more specific right to left,
    therefore the rDNS IP listings are reversed
  • Example 63.251.192.20 would have a reverse entry
    of 20.192.251.63.in-addr.arpa.

10
Why you should do rDNS now
  • Easy to implement
  • Because spammers often use invalid IP addresses
    (bogons) to send e-mails, rDNS will determine the
    authenticity of a domain name compared to the IP
    address from which it is originating
  • It is used as one of several de facto methods to
    determine the likelihood of a server being a SPAM
    relay
  • Most Internet Service Providers are using this to
    determine legitimate mail sources
  • Reduces probability of legitimate mail servers
    being added to a Blacklist

11
What is SPF Classic?
  • SPF Classic is used to identify mail servers that
    are explicitly permitted to send mail for a
    particular domain (think outgoing)
  • Domain owners identify permitted sending mail
    servers in DNS using TXT records
  • SMTP receivers verify the envelope sender address
    against the DNS information and can distinguish
    legitimate mail servers before any message data
    is transmitted
  • It is backward compatible with MTAs that are not
    patched with SPF filters or libraries (well,
    actually the old MTA just ignore it if that is
    considered backward compatible!)
  • Remember MX records publish which IPs are to
    receive mail (incoming) destined for your domain,
    SPF records says which IPs are allowed to send
    mail (outgoing) on behalf of your domain

12
Why you should do SPF now
  • Easy to implement (publish TXT records in DNS)
  • It is used by AOL, Symantec, EarthLink, Google
    and more as one of several de facto methods to
    determine trustworthiness of the mail sources
  • Most Internet Service Providers are currently or
    starting to use this to determine legitimate mail
    sources
  • Will move your mail to priority queues for
    processing for many providers including AOL, you
    can also submit to be added to the Whitelist for
    AOL
  • Reduces probability of being added to a Blacklist
  • Oct 1st ,2004 Microsoft, MSN and Hotmail will all
    start using Sender ID to prioritize incoming
    e-mail! (Sender ID is backward compatible with
    SPF Classic)

13
What to know about SPF Classic
  • Meng Wong created SPF Classic. It used to be
    called Sender Permitted From and was changed to
    Sender Policy Framework
  • SPF v1 (Classic) designates specific SMTP servers
    as being authorized to send for a FQDN
  • Uses the TXT fields in DNS to publish relevant
    information
  • Each sub-domain must be configured specifically
  • SPF will become de jure within approximately 1-2
    years most popular filters are flagging this
    already
  • Most MTAs support SPF Classic or have plug-ins
    available
  • Backward compatible with existing technology
  • It breaks e-mail forwarding! You'll have to
    switch from forwarding, where the envelope sender
    is preserved, to remailing, where the envelope
    sender is changed your MTA will have to support
    this

14
What to know about Sender ID
  • SPF Classic PRA Sender ID (basically now the
    MTA (think Exchange) checks SPF AND the MUA
    (think Outlook) check the PRA or Purported
    Responsible Address)
  • Meng Wong and Microsoft submitted a draft rfc
    merging both solutions and called it Sender ID
    was just turned down as a standard by the IETF
    due to Microsoft patent issues it is back on
    the table again!
  • Uses the TXT fields in DNS to publish relevant
    information same as SPF but uses a new version
    number
  • Each sub-domain must be configured specifically
    just like SPF
  • Microsoft will be updating the MTA/MUAs to
    support PRA (or Sender ID) think Outlook,
    Outlook Express and Exchange
  • Backward compatible with existing technology
  • It breaks e-mail forwarding! You'll have to
    switch from forwarding, where the envelope sender
    is preserved, to remailing, where the envelope
    sender is changed just like SPF
  • SPF v2

15
What to know about PRA
  • A purported responsible address is determined as
    the first from the following list of items
  • the first Resent-Sender header in the message,
    unless (per the rules of RFC2822) it is preceded
    by a Resent-From header and one or more Received
    or Return-Path headers occur after said
    Resent-From header and before the Resent-Sender
    header (see 3.6.6. of RFC2822 for further
    information on Resent headers),
  • the first mailbox in the first Resent-From header
    in the message,
  • the Sender header in the message, and
  • the first mailbox in the From header in the
    message
  • The purported responsible domain of a message is
    defined to be the domain part of the messages
    purported responsible address.

16
What is coming in a few years
  • DomainKeys
  • A Yahoo! submitted draft rfc
  • http//www.ietf.org/internet-drafts/draft-delany-d
    omainkeys-base-00.txt
  • Basically public/private keys for authenticating
    client mail and the servers along the path
  • Acts as a chain of custody from the source client
    machine to the destination client machine
  • Will require a major re-write of all MTAs to
    work 5 to 10 years if at all?
  • Backward compatible with existing technology
  • Google and Yahoo have already deployed!
  • Has promise to be a great standard if adoption is
    quick enough

17
What is coming continued
  • Puzzle Solution
  • Microsoft proposal
  • Assumed for small businesses that cannot afford
    certificate services
  • Sending mail server has to perform time consuming
    calculation for each mail sent
  • Assumes spammers cannot afford the computational
    costs to send out large bulk mailings or the cost
    of the bulk certificate services
  • Will require a major re-write of all MTAs to
    work 5 to 10 years if at all?
  • Backward compatible with existing technology
  • Solution has serious shortcomings
  • Microsoft has little published on this solution

18
Future potential SPAM problems
  • Disposable domain names, certificates and
    registrars
  • Country Sanctioned Activity (Governments allowing
    for profit activity or turning a blind eye to
    problem spammers) in order to generate s
  • Large Zombie Farms controlling clients with legit
    relay access (Think large University or poorly
    managed corporate environments)
  • Spyware agents that provide relay capabilities
    similar to Zombie configurations
  • IPv6 and Mobile IP devices becoming more
    prevalent
  • Potential exploits that could turn large
    peer-to-peer networks into relays

19
How rDNS works
MX mx1.ispA.net -1.1.1.1
MX mx1.ispB.net - 2.2.2.2
ISP A
ISP B
Internet
PTR 1.1.1.1 - mx1.ispA.net PTR 2.2.2.2 -
mx1.ispB.net
20
How to request rDNS for sub /24 address blocks
  • You will have to contact your ISP to request rDNS
    delegation do this via e-mail so you have a
    written trail of correspondence
  • You will likely have to talk to several
    departments to figure out who can actually do
    this for you, first contact your account manager
  • Typically, the DNS group handles the
    sub-delegation but not always sometimes it is
    the networking group
  • You will need to be patient but firm inform
    them that you need it for Anti-SPAM reasons for
    your mail server, to be RFC 2505 compliant
  • RFC 2317 describes standard methods for rDNS sub
    /24 delegation formats, there is also the DeGroot
    hack from the book "DNS Bind" both work fine

21
Setting up RFC 2317 rDNS Delegation
  • Example of 64.94.106.40/29 configuration in the
    providers servers
  • ORIGIN 106.94.64.in-addr.arpa.
  • zone delegation of 64.94.106.40/29
  • 40-47. IN NS ns1.j2global.com.
  • 40-47. IN NS ns2.j2global.com.
  • 40. IN CNAME 40.40-47.106.94.64.in-addr.arpa.
  • 41. IN CNAME 41.40-47.106.94.64.in-addr.arpa.
  • 42. IN CNAME 42.40-47.106.94.64.in-addr.arpa.
  • 43. IN CNAME 43.40-47.106.94.64.in-addr.arpa.
  • 44. IN CNAME 44.40-47.106.94.64.in-addr.arpa.
  • 45. IN CNAME 45.40-47.106.94.64.in-addr.arpa.
  • 46. IN CNAME 46.40-47.106.94.64.in-addr.arpa.
  • 47. IN CNAME 47.40-47.106.94.64.in-addr.arpa.

22
Setting up the rDNS Zone
  • Example of 64.94.106.40/29 configuration in your
    servers
  • ORIGIN 40-47.106.94.64.in-addr.arpa.
  • zone delegation of 64.94.106.40/29
  • _at_ IN NS ns1.j2global.com.
  • _at_ IN NS ns2.j2global.com.
  • _at_ IN TXT "j2 Global Communications, Inc."
  • 40 IN PTR 64.94.106.40.efax.com.
  • 41 IN PTR 64.94.106.41.efax.com.
  • 42 IN PTR 64.94.106.42.efax.com.
  • 43 IN PTR 64.94.106.43.efax.com.
  • 44 IN PTR 64.94.106.44.efax.com.
  • 45 IN PTR 64.94.106.45.efax.com.
  • 46 IN PTR 64.94.106.46.efax.com.
  • 47 IN PTR 64.94.106.47.efax.com.

23
Checking the rDNS Zone
  • Example of checking the 64.94.106.40/29
    configuration
  • DiG 2.1 _at_206.13.31.12
    40.106.94.64.in-addr.arpa. PTR
  • (1 server found)
  • res options init recurs defnam dnsrch
  • got answer
  • -HEADERid 10
  • flags qr rd ra Ques 1, Ans 2, Auth 2,
    Addit 0
  • QUESTIONS
  • 40.106.94.64.in-addr.arpa, type PTR, class
    IN
  • ANSWERS
  • 40.106.94.64.in-addr.arpa. 43200 CNAME 40.40-47.10
    6.94.64.in-addr.arpa.
  • 40.40-47.106.94.64.in-addr.arpa. 86400 PTR 64.94.1
    06.40.efax.com.
  • AUTHORITY RECORDS
  • 40-47.106.94.64.in-addr.arpa. 86400 NS ns2.j2globa
    l.com.
  • 40-47.106.94.64.in-addr.arpa. 86400 NS ns1.j2globa
    l.com.
  • Total query time 48 msec
  • FROM us.mirror.menandmice.com to SERVER
    206.13.31.12
  • WHEN Tue Jul 20 012009 2004

24
How SPF Classic works
MX mx1.ispA.net -1.1.1.1 TXT "vspf1 a mx -all"
MX mx1.ispB.net - 2.2.2.2 TXT "vspf1 a mx
-all"
ISP A
ISP B
Internet
TXT vspf1 a mx all MX mx1.ispA.net A
mx1.ispA.net - 1.1.1.1
25
SPF Classic Syntax
  • Some common SPF options in the TXT field
  • a the A record entry for example.com sends
    e-mail on behalf of example.com
  • mx the published MX record entries for
    example.com do not only receive e-mail on behalf
    of example.com but send e-mail also
  • ptr approve any host that ends in example.com
    as part of its FQDN
  • a a list of A record entries that are
    permitted to send e-mail on behalf of example.com
  • mx a list of mx record entries that are
    permitted to send e-mail on behalf of example.com
  • ip4 a list of ip addresses that are permitted
    to send e-mail on behalf of example.com (CIDR)
  • include a different domain that may send
    e-mail on behalf of example.com (relay through
    your service provider)
  • -all (fail) everything in the SPF record are
    the ONLY hosts/networks permitted to send
    (strictest policy dont do unless you know all
    the ramifications)
  • all (soft fail) everything in the SPF record
    are the ONLY hosts/networks permitted to send
    (middle ground)
  • ?all not sure (technically neutral) if
    everything in the SPF record are the ONLY
    hosts/networks permitted to send (start
    publishing with this one first as it is the most
    liberal policy)
  • Please see http//spf.pobox.com/mechanisms.html
    for a more detailed description and see
    http//spf.pobox.com/whitepaper.pdf for an
    excellent whitepaper

26
Setting up SPF Classic
  • Configuration of example.com SPF
  • ORIGIN example.com.
  • Leaving out the SOA info for space reasons
  • NS records
  • _at_ IN NS ns1.example.com.
  • _at_ IN NS ns2.example.com.
  • MX records
  • _at_ IN MX 10 mx1.example.com.
  • _at_ IN MX 20 mx2.example.com.
  • A records
  • mx1 IN A 1.1.1.1
  • mx2 IN A 2.2.2.2
  • TXT SPF records
  • _at_ IN TXT "vspf1 a mx -all"
  • mx1 IN TXT "vspf1 a -all"
  • mx2 IN TXT "vspf1 a -all"

27
Register your SPF domain
  • Once you have configured SPF for your domain you
    should confirm your configuration at
  • www.dnsstuff.com
  • Then put the logo on your site!

28
Testing SPF Classic
  • Testing of example.com SPF
  • http//www.dnsstuff.com/pages/spf.htm
  • Dummy Sample Output from dnsstuff
  • SPF lookup of sender droid_at_example.com. from IP
    1.1.1.1
  • SPF string used vspf1 mx -all. ? Obtained the
    TXT record via DNS for example.com
  • Processing SPF string vspf1 mx -all. ?
    Checking against the TXT record
  • Testing 'mx' on IP1.1.1.1, target domain
    example.com, CIDR 32, defaultPASS. MATCH!
  • Testing 'all' on IP1.1.1.1, target domain
    example.com, CIDR 32, defaultFAIL.
  • Result PASS

29
Impact on the Internet
  • These solutions will help reduce overall
    architecture problems of Authentication,
    Authorization, and Accounting with e-mail (back
    to AAA)
  • 68B e-mails daily of which approx. 42.8B are spam
    or 69 spam!1
  • Estimated 1,400 annual savings per employee from
    lost productivity currently due to spam2
  • 1 The Radicati Group and Brightmail
  • 2 - Vircom

30
Resource Links
  • rDNS
  • http//www.ietf.org/rfc/rfc2317.txt
  • http//www.ietf.org/rfc/rfc2505.txt
  • http//www.arin.net/registration/lame_delegations/
    index.html
  • http//kbase.menandmice.com/view.html?rec31
  • http//www.microsoft.com/windows2000/techinfo/resk
    it/en-us/default.asp?url/windows2000/techinfo/res
    kit/en-us/cnet/cncf_imp_dewg.asp
  • http//dedicated.pacbell.net/custcare/dns_workshee
    t.html
  • DNS tools
  • http//www.dnsstuff.com/
  • http//us.mirror.menandmice.com/cgi-bin/DoDig
  • http//network-tools.com/
  • http//www.squish.net/dnscheck/
  • http//www.dns.net/dnsrd/tools.html
  • http//www.dnsreport.com/
  • http//www.samspade.org/t/
  • General references
  • http//www.spamanatomy.com/

31
Resource Links
  • SPF
  • http//spf.pobox.com/howworks.html
  • http//spf.pobox.com/rfcs.html
  • http//spf.pobox.com/wizard.html
  • http//www.ietf.org/internet-drafts/draft-mengwong
    -spf-01.txt
  • http//www.dnsstuff.com/pages/spf.htm
  • Microsofts PRA (E-mail Caller ID)
  • http//www.microsoft.com/downloads/details.aspx?Fa
    milyID9a9e8a28-3e85-4d07-9d0f-6daeabd3b71bdispla
    ylangen
  • Sender ID the merged PRA and SPF
  • http//www.microsoft.com/presspass/press/2004/may0
    4/05-25SPFCallerIDPR.asp
  • http//www.microsoft.com/presspass/press/2004/jun0
    4/06-24SIDSpecIETFPR.asp
  • http//www.microsoft.com/mscorp/twc/privacy/spam_s
    enderid.mspx
  • Yahoo! DomainKeys
  • http//antispam.yahoo.com/domainkeys
  • http//www.ietf.org/internet-drafts/draft-delany-d
    omainkeys-base-00.txt
  • http//boycott-email-caller-id.org/

32
A look at some Service Providers records
  • aol.com. 300 IN TXT
    "vspf1 ip4152.163.225.0/24 ip4205.188.139.0/24
    ip4205.188.144.0/24 ip4205.188.156.0/23
    ip4205.188.159.0/24 ip464.12.136.0/23
    ip464.12.138.0/24 ptrmx.aol.com ?allaol.com.
    300 IN TXT "spf2.0/pra
    ip4152.163.225.0/24 ip4205.188.139.0/24
    ip4205.188.144.0/24 ip4205.188.156.0/23
    ip4205.188.159.0/24 ip464.12.136.0/23
    ip464.12.138.0/24 ptrmx.aol.com ?all
  • cisco.com. 86400 IN TXT
    "vspf1 ptr"
  • earthlink.net. 1800 IN TXT
    "vspf1 ip4207.217.120.0/23 ip4207.69.200.0/24
    ip4209.86.89.0/24 ?all
  • efax.com. 86400 IN TXT
    "vspf1 ptr ?all"
  • google.com. 300 IN TXT
    "vspf1 ptr ?all
  • hotmail.com. 3600 IN TXT
    "vspf1 includespf-a.hotmail.com
    includespf-b.hotmail.com includespf-c.hotmail.co
    m includespf-d.hotmail.com all
  • microsoft.com. 3600 IN TXT
    "vspf1 mx redirect_spf.microsoft.com"
  • msn.com. 900 IN TXT
    "vspf1 includespf-a.hotmail.com
    includespf-b.hotmail.com includespf-c.hotmail.co
    m includespf-d.hotmail.com all
  • netzero.net. 600 IN TXT
    "vspf1 ptruntd.com ptrnetzero.net ptrjuno.com
    ?all

33
Questions and Answers
34
About Ed Horley
  • Ed Horley is a Sr. Network Engineer for j2 Global
    Communications, better known as eFax. Ed
    currently designs, supports and maintains j2's
    58 international and domestic collocation sites
    along with j2's core data center IP
    infrastructure. He is experienced in e-commerce
    web content delivery, large scale e-mail
    delivery, firewalls, IPSec VPN's, and specializes
    in routing and switching and DNS issues.
  • Ed is a Cisco Certified Network Professional
    (CCNP), a Microsoft Certified Professional (MCP)
    and a Microsoft Most Valuable Professional (MVP).
    Ed graduated from the University of the Pacific
    in 1992 with a BS in Civil Engineering.
  • When he is not playing on network gear you can
    find him out on the lacrosse field as an Umpire
    for Women's Lacrosse. He is currently married to
    his wonderful wife Krys and has two children,
    Briana and Aisha. He lives and works in Walnut
    Creek, CA.

35
Contact Info
  • Ed Horley ehorley_at_gmail.com
Write a Comment
User Comments (0)
About PowerShow.com