Spam prevention using dns solutions
Download
1 / 35

SPAM Prevention Using DNS Solutions - PowerPoint PPT Presentation


  • 425 Views
  • Updated On :

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

Related searches for SPAM Prevention Using DNS Solutions

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'SPAM Prevention Using DNS Solutions' - Ava


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Spam prevention using dns solutions l.jpg

SPAM Prevention Using DNS Solutions

Implementing reverse domain name services (rDNS) and planning for SPF Classic

Presented by: Ed Horley

Date: May 2005


Overview l.jpg
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


Overview continued l.jpg
Overview Continued

  • Future additional solutions for SPAM prevention are Yahoo’s DomainKeys, Sender Verification and perhaps Microsoft’s 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


Current solutions overview l.jpg
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)


Solutions used today l.jpg

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

Solutions Used Today


Solutions used today6 l.jpg

Serverfilters

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

HardwareAppliances

Barracuda 300

BorderWare MXtreme

CypherTrust IronMail

IronPort C60

Mail Foundry

Sendio ICE Box

Tumbleweed

SubscriptionServices

Brightmail

Commtouch

Greenview Data

Katharion

Postini

PUREmail

Solutions Used Today


The proposed solutions l.jpg
The Proposed Solutions

  • Short term solutions:

    • Internet Engineering Task Force (IETF) draft rfc’s

    • 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?


What to do now l.jpg
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)


What is rdns l.jpg
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.


Why you should do rdns now l.jpg
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


What is spf classic l.jpg
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 MTA’s 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 IP’s are to receive mail (incoming) destined for your domain, SPF records says which IP’s are allowed to send mail (outgoing) on behalf of your domain


Why you should do spf now l.jpg
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)


What to know about spf classic l.jpg
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 MTA’s 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


What to know about sender id l.jpg
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/MUA’s 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


What to know about pra l.jpg
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 message’s purported responsible address.


What is coming in a few years l.jpg
What is coming in a few years

  • DomainKeys

    • A Yahoo! submitted draft rfc

      • http://www.ietf.org/internet-drafts/draft-delany-domainkeys-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 MTA’s 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


What is coming continued l.jpg
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 MTA’s 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


Future potential spam problems l.jpg
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


How rdns works l.jpg

Public ISP SMTP servers send e-mail to destination

Public SMTP servers receive e-mail and check rDNS

4

5

3

6

Public DNS servers supply reverse entries

Internal SMTP servers forwarding e-mail to public ISP SMTP servers

7

Internal SMTP servers take client e-mail

2

Colleague receives e-mail from Public SMTP servers

1

Worker sends e-mail to colleague

MX: mx1.ispA.net ->1.1.1.1

How rDNS works

MX: mx1.ispB.net -> 2.2.2.2

ISP A

Internet

ISP B

PTR: 1.1.1.1 -> mx1.ispA.net

PTR: 2.2.2.2 -> mx1.ispB.net


How to request rdns for sub 24 address blocks l.jpg
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


Setting up rfc 2317 rdns delegation l.jpg
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.


Setting up the rdns zone l.jpg
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

    ;

    @ IN NS ns1.j2global.com.

    @ IN NS ns2.j2global.com.

    ;

    @ 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.


Checking the rdns zone l.jpg
Checking the rDNS Zone

  • Example of checking the 64.94.106.40/29 configuration:

    ; <<>> DiG 2.1 <<>> @206.13.31.12 40.106.94.64.in-addr.arpa. PTR

    ; (1 server found)

    ;; res options: init recurs defnam dnsrch

    ;; got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 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.106.94.64.in-addr.arpa.

    40.40-47.106.94.64.in-addr.arpa. 86400 PTR 64.94.106.40.efax.com.

    ;; AUTHORITY RECORDS:

    40-47.106.94.64.in-addr.arpa. 86400 NS ns2.j2global.com.

    40-47.106.94.64.in-addr.arpa. 86400 NS ns1.j2global.com.

    ;; Total query time: 48 msec

    ;; FROM: us.mirror.menandmice.com to SERVER: 206.13.31.12

    ;; WHEN: Tue Jul 20 01:20:09 2004

    ;; MSG SIZE sent: 43 rcvd: 146


How spf classic works l.jpg

Public ISP SMTP servers send e-mail to destination

Public SMTP servers receive e-mail - checks SPF info

4

5

3

6

Public DNS servers supply TXT, MX and A records

Internal SMTP servers forwarding e-mail to public ISP SMTP servers

7

Internal SMTP servers take client e-mail

2

Colleague receives e-mail from Public SMTP servers

1

Worker sends e-mail to colleague

MX: mx1.ispA.net ->1.1.1.1

TXT: "v=spf1 a mx -all"

How SPF Classic works

MX: mx1.ispB.net -> 2.2.2.2

TXT: "v=spf1 a mx -all"

ISP A

Internet

ISP B

TXT: “v=spf1 a mx –all”

MX: mx1.ispA.net

A: mx1.ispA.net -> 1.1.1.1


Spf classic syntax l.jpg
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 – don’t 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


Setting up spf classic l.jpg
Setting up SPF Classic

  • Configuration of example.com SPF

    $ORIGIN example.com.

    ; Leaving out the SOA info for space reasons

    ; NS records

    @ IN NS ns1.example.com.

    @ IN NS ns2.example.com.

    ; MX records

    @ IN MX 10 mx1.example.com.

    @ 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

    @ IN TXT "v=spf1 a mx -all"

    mx1 IN TXT "v=spf1 a -all"

    mx2 IN TXT "v=spf1 a -all"


Register your spf domain l.jpg
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!


Testing spf classic l.jpg
Testing SPF Classic

  • Testing of example.com SPF

    • http://www.dnsstuff.com/pages/spf.htm

    • Dummy Sample Output from dnsstuff:

      SPF lookup of sender [email protected] from IP 1.1.1.1:

      SPF string used: v=spf1 mx -all.  Obtained the TXT record via DNS for example.com

      Processing SPF string: v=spf1 mx -all.  Checking against the TXT record

      Testing 'mx' on IP=1.1.1.1, target domain example.com, CIDR 32, default=PASS. MATCH!

      Testing 'all' on IP=1.1.1.1, target domain example.com, CIDR 32, default=FAIL.

      Result: PASS


Impact on the internet l.jpg
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


Resource links l.jpg
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?rec=31

    • http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?url=/windows2000/techinfo/reskit/en-us/cnet/cncf_imp_dewg.asp

    • http://dedicated.pacbell.net/custcare/dns_worksheet.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/

    • http://www.declude.com/Articles.asp?ID=97


Resource links31 l.jpg
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

  • Microsoft’s PRA (E-mail Caller ID):

    • http://www.microsoft.com/downloads/details.aspx?FamilyID=9a9e8a28-3e85-4d07-9d0f-6daeabd3b71b&displaylang=en

  • Sender ID – the merged PRA and SPF:

    • http://www.microsoft.com/presspass/press/2004/may04/05-25SPFCallerIDPR.asp

    • http://www.microsoft.com/presspass/press/2004/jun04/06-24SIDSpecIETFPR.asp

    • http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx

  • Yahoo! DomainKeys:

    • http://antispam.yahoo.com/domainkeys

    • http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-00.txt

    • http://boycott-email-caller-id.org/


A look at some service provider s records l.jpg
A look at some Service Provider’s records

  • aol.com. 300 IN TXT "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all“aol.com. 300 IN TXT "spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all“

  • cisco.com. 86400 IN TXT "v=spf1 ptr"

  • earthlink.net. 1800 IN TXT "v=spf1 ip4:207.217.120.0/23 ip4:207.69.200.0/24 ip4:209.86.89.0/24 ?all“

  • efax.com. 86400 IN TXT "v=spf1 ptr ?all"

  • google.com. 300 IN TXT "v=spf1 ptr ?all“

  • hotmail.com. 3600 IN TXT "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all“

  • microsoft.com. 3600 IN TXT "v=spf1 mx redirect=_spf.microsoft.com"

  • msn.com. 900 IN TXT "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all“

  • netzero.net. 600 IN TXT "v=spf1 ptr:untd.com ptr:netzero.net ptr:juno.com ?all“

  • symantec.com. 18000 IN TXT "v=spf1 ip4:198.6.49.0/24 ip4:65.125.29.0/25 ip4:206.204.57.47 ?all“



About ed horley l.jpg
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.


Contact info l.jpg
Contact Info

Ed Horley [email protected]


ad