Any way to P-T-P Distribute the RBL lists?
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 sent with specific characteristics can be filtered to trigger the update (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. On Wed, 24 Sep 2003, Drew Weaver 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?
Disregard this if im totally out of line, but it would seem to me that this would be possible.
Thanks,
-Drew
-- William Leibzon Elan Networks william@elan.net
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 ? Disregard this if im totally out of line, but it would seem to me that this would be possible. Thanks, -Drew
Distribute the RBL list via Freenet ( http://freenet.sourceforge.net/ ) It's slow, but nearly impossible to suppress... At 10:30 PM 9/24/2003 -0400, you 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?
Disregard this if im totally out of line, but it would seem to me that this would be possible.
Thanks,
-Drew
On Wed, 24 Sep 2003, Eric Kuhnke wrote: : 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). -- -- Todd Vierling <tv@duh.org> <tv@pobox.com>
on 9/24/2003 9:30 PM Drew Weaver 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. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Thu, 25 Sep 2003, Eric A. Hall 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. Aaron
on 9/25/2003 2:44 PM Aaron Dewell wrote:
So why couldn't you follow this plan without the VPN and anycast?
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. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Thu, 25 Sep 2003, Eric A. Hall wrote:
on 9/25/2003 2:44 PM Aaron Dewell wrote:
So why couldn't you follow this plan without the VPN and anycast? Multiple anycast channels would make distributed attacks ineffective, since each source would be attacking its closest target.
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 -- [-] Omae no subete no kichi wa ore no mono da. [-]
On Thu, 25 Sep 2003 13:44:59 -0600 (MDT) Aaron Dewell <acd@woods.net> wrote:
On Thu, 25 Sep 2003, Eric A. Hall 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).
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
On Thu, 25 Sep 2003, Jay Kline wrote:
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 -- [-] Omae no subete no kichi wa ore no mono da. [-]
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
Aaron Dewell wrote:
On Thu, 25 Sep 2003, Eric A. Hall 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
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:
On Thu, 25 Sep 2003, Eric A. Hall 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.
Aaron
On Wed, Sep 24, 2003 at 10:30:16PM -0400, Drew Weaver wrote: 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. -- Sabri Berisha "I route, therefore you are" "Wij doen niet aan default gateways" - anonymous engineer bij een DSL klant.
On Thu, Sep 25, 2003 at 09:41:07PM +0200, Sabri Berisha wrote:
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.
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"
participants (13)
-
Aaron Dewell -
Andy Smith -
Dan Hollis -
Drew Weaver -
Eric A. Hall -
Eric Kagan -
Eric Kuhnke -
Jay Kline -
Matthew Sullivan -
ratul mahajan -
Sabri Berisha -
Todd Vierling -
william＠elan.net