Welcome:
Login
|
Sign Up
|
About CircleID
Follow:
|
|
|
|
||
|
||
In Taking Back The DNS I described new technology in ISC BIND as of Version 9.8.0 that allows a recursive server operator to import DNS filtering rules in what ISC hopes will become the standard interchange format for DNS policy information. Later I had to decry the possible use of this technology for mandated content blocking such as might soon be the law of the land in my country. I’m a guest at MAAWG this week in San Francisco and one of the most useful hallway discussions I’ve been in so far was about the Spamhaus DROP list.
The Spamhaus people do a lot of reputation research and some of us subscribe to their online services in a way that causes us to reject e-mail traffic from network neighborhoods of purportedly low reputation. This is a dangerous way to operate one’s network, since any mistake on Spamhaus’s part could cause us to reject nonmalicious traffic. As the creator of the first Realtime Blackhole List (RBL) back at MAPS in the mid 1990’s I am well acquainted with both the risks and benefits. For my home office those risks and benefits are well aligned. My long term use of the Spamhaus SBL has helped me reject a lot of e-mail spam that would otherwise have landed in my family’s inboxes, but as I add more communications tools (not just e-mail any more) I find myself wishing for a reputation tool that is not e-mail specific. The Spamhaus DROP list is such a tool, it’s a list of networks that Spamhaus recommends us Do Not Route or Peer (so, D-R-O-P.) However, wiring something like the DROP into my router or firewall is more work than I’m willing to do.
The Shoe Drops
Today I realized that the Response Policy Zone (RPZ) DNS filtering technology in BIND9 (9.8.0) could be used to represent the Spamhaus DROP list. The effect will simply be that various domain names return a fake NXDOMAIN result (this means, “there’s no such place”) if the address that DNS would otherwise return is listed on the Spamhaus DROP. That would prevent my family from accidentally visiting those locations with a web browser or other communications tool. Freakishly enough it will also prevent my e-mail server from accepting e-mail from those locations since my e-mail server will not accept an e-mail message if it cannot successfully look up all of the domain names in the envelope and header.
So I took a copy of the Spamhaus DROP list, wrote a short Perl script to translate it from “lasso” format into “RPZ” format, and looked for some test data. The ISC Passive DNS system gave me a long list of domain names whose address records fell inside one of the entries I saw in the middle of the Spamhaus DROP, so I looked up each one of these to find one that has not yet been killed by its registrar or abandoned by its registrant—in other words something still living that my RPZ could kill off. Testing… testing… it works! There’s no way to do forward or reverse DNS at my house any more for any address listed on the Spamhaus DROP.
Example Data
Since the Spamhaus DROP is publically and freely available, there’s no secrecy around the data I used. Still, it bothers me to name names (and to name addresses) since I have no personal knowledge of any misdeeds by the operator of the domain names or IP addresses involved. So, I’m going to anonymize here. The input data from the Spamhaus DROP file looks like this:
yyy.xxx.212.0/22 ; SBLzzzzz
The output data from my Perl script, in RPZ format now, looks like this:
$ORIGIN dns-policy.example.com.
22.0.212.xxx.yyy.rpz-ip CNAME .
*.212.xxx.yyy.in-addr.arpa CNAME .
*.213.xxx.yyy.in-addr.arpa CNAME .
*.214.xxx.yyy.in-addr.arpa CNAME .
*.215.xxx.yyy.in-addr.arpa CNAME .
I’ve sent the Perl script to Spamhaus in case they wish to publish it along with their DROP list.
Conclusion
Because of the ease with which criminals can “frequency hop” among many possible IP addresses, I’ve been rethinking my old position on IP source address based reputation systems. Criminals will always need identifiers for their traffic and content and there’s a vibrant market of providers who want to make those identifiers as cheap and plentiful as possible—but more and more I think domain identifiers are going to be where the reputation industry puts most of their research effort. Still, I find it heartening that all of my family’s communication tools rely on accurate DNS for every IP address they see—and so by using a domain-based filtering approach I can achieve an IP address based filtering result.
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byCSC
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byRadix
A World-Renowned Source for Internet Developments. Serving Since 2002.
Paul - how is your view further substantiated (or not) in an IPv6 world where IPs are nearly limitless? What changes do you foresee with respect to spam filtering in this world?
I can share three perspectives on this.
First, in an IPv6 world we’ll see even more frequency hopping by criminals. The bottom 64 bits of an Ethernet connected IPv6 host are generally computed using EUI64 and tend to look a lot like MAC addresses, but they can be anything, and we will indeed see everything—malware will rewrite these bits to evade detection and/or filtering. That means effective filtering will be done at the /64 level—whole Ethernet segments will be added to the “rejection list” even if it’s a shared Ethernet having a mix of infected and non-injected hosts (or malicious and non-malicious users). I’m not advocating this, just observing the ways in which victims will protect themselves. IPv6 is coming to the fore just as the Internet population is increasingly willing to inflict and absorb collateral losses in order to prevent even more targetted and damaging attacks. (For a non-Internet example, see the PATRIOT act in my country.)
Second, criminals need domain names, both to anchor their content and to connect their traffic to their content. The use of raw IP addresses in places where domain names would usually be seen (like in URL’s, for example , make both content and traffic look “spammy” and criminals want to avoid looking spammy. Of course there’s a market both broad and deep for providing domain names so cheap that they can be thrown away after a single hour of use, so criminals who need domain names can get all they need. That’s why I developed the Response Policy Zone technology that will let information security providers kill these cheap domains as fast as the criminals can create them. If a criminal is using DNS then we should be able to shut them down or at least keep them contained even when they migrate to IPv6 which as you point out has a vastly larger pool of addresses than IPv4.
Third, I think there’s an opportunity to uplevel our e-mail reputation game during the transition from IPv4 to IPv6. In IPv4 the e-mail reputation industry has mostly been using the “realtime blackhole list” (RBL) technology that we developed at MAPS back in the mid 1990’s but it’s clear that spammers know how to get around this kind of blocking. To the extent that it remains effective or useful to reject incoming traffic based on IP source address, your point about IPv6 is very well taken, we will need something better than dynamic lists of bad-reputation networks and hosts. I wrote down some thoughts the other day about using Two Stage Filtering for IPv6 Electronic Mail and it’s possible that this same approach could be adapted for other types of traffic not just e-mail.
Thanks for this interesting question.
To convert from Spamhaus DROP “lasso” format into RPZ format you will need a conversion utility similar to this.
Update: I added the Team Cymru fullbogons list to my personal RPZ using the same Perl conversion script that worked for the Spamhaus DROP and it works fine. I spoke to Rob Thomas of Team Cymru who thought it a fine idea. He agrees with me that spammers are unlikely to use this address space to source spam, yet it provides another layer of protection against such shenanigans. As with any living list, we both strongly recommend you automate the updates to avoid blocking legitimate traffic.