I know you all have probably already thought of this, but can anyone think of a feasible way to run a RBL list that does not have a single point of failure? Or any attackable entry?
Disregard this if im totally out of line, but it would seem to me that this would be possible.
Thanks,
-Drew
Send RBL lists & updates by email 
I'm mostly serious - rbl lists can be easily incorporated as special filter
for email or it can run internal rbl (rbldns is very small code), emails
(all such emails would need to be signed and signature can be verified by
recepient mail server to be one on its allowed rbl list). Any attempts to
DoS origin of such email updates would be useless as origin can be changes
very easily and the updates do not depend on working dns. Blacklist's
websites would still be subject to DoS attacks, but that is separate
issue and would not stop with blacklist actual use.
I know you all have probably already thought of this, but can anyone think of a feasible way to run a RBL list that does not have a single point of failure? Or any attackable entry?
Subscription based and / or firewalled by approved IP ?
Distribute the RBL list via Freenet ( http://freenet.sourceforge.net/ )
It's slow, but nearly impossible to suppress...
: Distribute the RBL list via Freenet ( http://freenet.sourceforge.net/ )
:
: It's slow, but nearly impossible to suppress...
If you're on SPAM-L@PEACH.EASE.LSOFT.COM, someone has created a whole
proposal about this. I offered Entropy (http://entropy.stop1984.com/) as a
possible alternative or additional distribution network; it's written in C,
much faster, and still presents the same user-facing client protocols (FCP
and http).
Easy. Have the master server only be reachable by replication partners
through a VPN connection, and have dozens of secondaries advertising
through multiple anycast addresses.
Hi,
I know you all have probably already thought of this, but can
anyone think of a feasible way to run a RBL list that does not have a single
point of failure? Or any attackable entry?Disregard this if im totally out of line, but it would seem to me that this
would be possible.
Whatever you come up with, it practically always has a downside:
spammers can get the whole list as well.
Image an open-proxy-dnsbl being distributed via peer to peer or via
distributed means as usenet. Spammers would love it as they no longer
have to scan for themselves, same for open relays.
For some form of dnsbls, such as the geographical ones, it might be
useful to simply have everyone generate their own copy using the code
the creators use.
An option could be to setup large DNS servers on various IXP's like is
being done for other nameservers so you 'distribute' the same nameserver
on different geographical locations.
So why couldn't you follow this plan without the VPN and anycast? Have a
couple of master servers totally unpublished (nobody except the secondaries
know about it), then have dozens of secondaries that are the ones actually
used (or AXFR'd off of). You can't attack all the secondaries at once if
there are enough of them, and the master server is unknown (hopefully).
You could certainly improve on that system with a VPN, but the service is
reasonable without it. Make your secondaries be volunteers who sign an
agreement to never tell anyone what your master IP addresses are. If they
get out, shift the master files to a secondary, notify the other secondaries
by secure channels, and you're back in business.
Even better - Publish all the servers, nobody knows who the masters are of
this list of N servers, and rotate it when needed or every so often.
I'd be a secondary/rotating master in that setup. I'm sure you'd get a
bunch of volunteers.
Aaron
Multiple anycast channels would make distributed attacks ineffective,
since each source would be attacking its closest target.
VPNs can give you ~password protection for the master.
> > I know you all have probably already thought of this, but
> > can anyone think of a feasible way to run a RBL list that does not have
> > a single point of failure? Or any attackable entry?
>
> Easy. Have the master server only be reachable by replication partners
> through a VPN connection, and have dozens of secondaries advertising
> through multiple anycast addresses.So why couldn't you follow this plan without the VPN and anycast? Have a
couple of master servers totally unpublished (nobody except the secondaries
know about it), then have dozens of secondaries that are the ones actually
used (or AXFR'd off of). You can't attack all the secondaries at once if
there are enough of them, and the master server is unknown (hopefully).
Its been said before, security through obscurity isnt security at all. There
should be a way where every can know the ins and outs of a system, and still
not compromise it.
Even better - Publish all the servers, nobody knows who the masters are of
this list of N servers, and rotate it when needed or every so often.
How about publishing a list of servers, but use the PGP web of trust model to
allow updating of each other? That way there is no centralized source. If a
group of admins dont like the updates coming from a server, dont trust it any
longer. If you make this more like a social network, you dont have to have a
central authority.
The trick then will be to have as many different participants as possible,
and to have each participant share who it thinks the other participants are
(or explicitly are not). Then if you take out one node, the others are not
prevented from functioning.
Jay
script kiddies can easy amass zombie nets of several 10k's, widely
distributed enough to kill an entire anycast system.
also, the individual anycast targets likely wouldnt be very happy when
they do get ddosed.
this talk about architectures of static targets really has got to stop.
start thinking outside the box, mmkay?
-Dan
How about publishing a list of servers, but use the PGP web of trust model to
allow updating of each other? That way there is no centralized source. If a
group of admins dont like the updates coming from a server, dont trust it any
longer. If you make this more like a social network, you dont have to have a
central authority.
exactly. to be immune from ddos you MUST remove any centralized source.
The trick then will be to have as many different participants as possible,
and to have each participant share who it thinks the other participants are
(or explicitly are not). Then if you take out one node, the others are not
prevented from functioning.
the problem is that automated crawlers could amass a list of nodes to
attack. i shy away from automated discovery.
-Dan
Aaron Dewell wrote:
> > I know you all have probably already thought of this, but
> > can anyone think of a feasible way to run a RBL list that does not have
> > a single point of failure? Or any attackable entry?
>
> Easy. Have the master server only be reachable by replication partners
> through a VPN connection, and have dozens of secondaries advertising
> through multiple anycast addresses.So why couldn't you follow this plan without the VPN and anycast? Have a
couple of master servers totally unpublished (nobody except the secondaries
know about it), then have dozens of secondaries that are the ones actually
used (or AXFR'd off of). You can't attack all the secondaries at once if
there are enough of them, and the master server is unknown (hopefully).You could certainly improve on that system with a VPN, but the service is
reasonable without it. Make your secondaries be volunteers who sign an
agreement to never tell anyone what your master IP addresses are. If they
get out, shift the master files to a secondary, notify the other secondaries
by secure channels, and you're back in business.Even better - Publish all the servers, nobody knows who the masters are of
this list of N servers, and rotate it when needed or every so often.I'd be a secondary/rotating master in that setup. I'm sure you'd get a
bunch of volunteers.
All well an good until the DDoSer systematically DDoSes each secondary in order as has happened with SPEWS and SORBS.
Further, what's the point of having a DNSbl if the blocked parties cannot get to the website to:
1/ Find out why they are blocked.
2/ Get delisted when they have fixed the issue.
When it comes to SPEWS - that isn't so much of an issue, with SORBS it is the main part of the system.
/ Mat
Jay Kline wrote:
The trick then will be to have as many different participants as possible,
and to have each participant share who it thinks the other participants are
(or explicitly are not). Then if you take out one node, the others are not
prevented from functioning.
Again, the problem is if you are the secondary or distribution point that is having it's turn at being DDoSed are you going to be happy with 100M of targetted crap being aimed at your ip space?
Are you going to come back online as soon as the DDoSer moves to the next target?
The problem here is the amount of DDoS traffic is significant for the upstreams to say "we're not going to carry this, fix it or we'll drop you" - except in the cases of nodes in various IX's - however there aren't many willing to put nodes in IX's (and certainly not for free).
/ Mat
something not very far from the discussion on this thread was proposed last year by some researchers at columbia. for those of you who like reading academic papers: http://www1.cs.columbia.edu/~danr/publish/2002/Kero2002:SOS-camera.pdf
-- ratul
Aaron Dewell wrote:
Most of the large open proxy dnsbls in existence already offer their
zones to essentially anyone via rsync.
http://abuse.easynet.nl/proxies.html skip down to "rsync"