Stories
Slash Boxes
Comments

NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

use Perl

All the Perl that's Practical to Extract and Report

use Perl Log In

[ Create a new account ]

MGLEE (4392)

MGLEE
(email not shown publicly)

If any of this makes any sense yes I probably am that person : anatomy, anat0010, AND, Banbury, bookstack, Bristol, Community, ebookers, Fitz, GDM, ghosts, IFSBM, mondus, naming company, ox.test, Oxford, Oxdigital, spam, statistics.

Journal of MGLEE (4392)

Wednesday September 24, 2003

10:51 AM

Distributed DNS blacklists

[ #14882 ]

Now that yet another DNS blacklist (monkeys) has been retired due to a continuing massive denial of service attack perhaps its time to rethink DNS blacklists.

Using DNS to rapidly query a server to check if an IP address is listed in it is a great idea. Its fast, little overhead involved, DNS is a well known and supported protocol. Querying against a single server allows the owners of the list to rapidly ammend the list when needed.BUT it also provides a single point of attack.

Somebody (maybe a spammer ?) has taken it upon themselves to launch continued denial of service attacks on the servers hosting the DNS lists. DNS wasnt designed to withstand such attacks, but surely with all the knowledge that has gone into designing distributed P2P networks there must be another way of distributing DNS blacklists.

Napster got taken out due to its client server architecture, Gnutella continues due to being entirely distributed. You can force a single server to go down through court action, or a DoS attack, but that will only affect a small part of the network, the rest continues unaffected.

So how can we apply this architecture to DNS blacklists ?

continued tomorrow...

List all Journal entries

Distributed DNS blacklists More | Login | Reply

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Without JavaScript enabled, you might want to use the classic discussion system instead. If you login, you can remember this preference.

P2P blacklists wouldn't work (Score:4, Interesting)

by gav (2710) on 2003.09.24 11:38 (#24502) Homepage Journal

The problem with a P2P blacklist is that you allow people into your network that you don't trust. Spammers would just get smart and use zombies to join the network and un-blacklist everything.

Reply to This
- Re:P2P blacklists wouldn't work (Score:2, Insightful)
  
  by MGLEE (4392)
  
  Yup, P2P networks have problems with concurrency, deciding which is the most upto date version of the list.
  Plus as you say, there is no authentication, anyone can post a file labelled sbl-blacklist.txt identical to the official file, but with completely different IP addressed.
  But they are very good at surviving denail of service attacks, which is a big problem with the DNS blacklists at the moment.
  - Re:P2P blacklists wouldn't work (Score:2, Interesting)
    
    by johnseq (1046)
    
    Doesn't a simple digital signature on the text file ensure it's authenticity? I believe the FSF is going to do this for their software after their FTP servers got cracked. This should prevent future rogue code injections, or at least prevent them from going unnoticed. The same should work to authenticate blacklists, no?
    - Re:P2P blacklists wouldn't work (Score:2)
      
      by gav (2710)
      
      If I was going to be evil, instead of serving a signed file I'd just join the network with as many machines as possible and have a distributed honeypot. Making the spam check timeout would work just as well as returning bad data. You could also run a DDOS on the root nodes.
      - Re:P2P blacklists wouldn't work (Score:1)
        
        by johnseq (1046)
        
        Wasn't freenet designed to withstand just such an attack?
        
        I think the idea is to not have a root node. Just a single public key you can validate the text file against. The blacklist could be distributed and mirrored using a variety of technologies -- http, ftp, nntp, irc, konspire, email, jabber, kazaa, freenet, etc. It's seems not just possible for pretty straightforward to have the original blacklist be periodically injected into the 'net, as opposed to having a dependency on a particular server bein
        
        Re:P2P blacklists wouldn't work (Score:1)
        
        by MGLEE (4392)
        
        Blacklists are dynamic; new IP addresses get added, some get delisted. A single authorative source is required, otherwise you have big problems with version control.
        Signed incremental updates are the way to go, but I'm still unsure about how you authenticate the identity of a signee (without resorting to blindly beleiving Verisign)(which would then leave Verisign as a single point of failure in the system).