Re: Any way to P-T-P Distribute the RBL lists?
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"
Re: Any way to P-T-P Distribute the RBL lists?
At 07:08 AM 9/25/2003, Rich Braun wrote: But generating the blocklist requires real-time reporting back to a central server. Even if the server is decentralized, it will still require a relatively small handful of accessable IP addresses. I seem to recall a distributed server network, something called USENET, uses NNTP for sharing data with other servers in the network... Last I heard there were over 30,000 such servers netwide/worldwide, all sharing data with one or more neighbors, automagically sharing data that is input into one system to all systems in a relatively and reasonably short amount of time. I propose that a private spamrbl nntp server system be established. Only allow feeds from those you know, use PGP authentication for all feeds and all submissions. If there is a personally verifiable web of trust built around personally verified signed PGP keys, it should prevent spammers from infiltrating the system. Perhaps the only way you can get approved/added to the network is to be approved by your upstream or a peer, and so they are held accountable for letting you into the system. This system could house a number BLs, each as a "newsgroup", allowing each network to then utilize the BLs that they want to implement in their network at any given time. Some of the newsgroups could be open, anyone can add a listing, others would be moderated (e.g. Monkeys or Spamhaus) and only the moderator(s) could add or remove listings. It seems too easy. I must be overlooking something really stupid and obvious about why this won't work. jc
Re: Any way to P-T-P Distribute the RBL lists?
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
Re: Any way to P-T-P Distribute the RBL lists?
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
Re: Any way to P-T-P Distribute the RBL lists?
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
Re: Any way to P-T-P Distribute the RBL lists?
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. [-]
Re: Any way to P-T-P Distribute the RBL lists?
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. [-]
Re: Any way to P-T-P Distribute the RBL lists?
On Thu, 25 Sep 2003 13:44:59 -0600 (MDT) Aaron Dewell <[EMAIL PROTECTED]> 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
Re: Any way to P-T-P Distribute the RBL lists?
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. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Any way to P-T-P Distribute the RBL lists?
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
Re: Any way to P-T-P Distribute the RBL lists?
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.
Re: Any way to P-T-P Distribute the RBL lists?
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. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Any way to P-T-P Distribute the RBL lists?
On Thu, 25 Sep 2003, Rich Braun wrote: > > Drew Weaver <[EMAIL PROTECTED]> inquired: > >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? > > Fedex. "Never underestimate the bandwidth of a station wagon loaded with DLT > cartridges barreling along the highway at 70mph"... > > Seriously, as has already been pointed out, the distribution side of the > equation is the easy part. Server admins can use an out-of-band technique > like ordinary dialup to get access to the blocklist. But generating the > blocklist requires real-time reporting back to a central server. I respectfully disagree. What it requires is some mechanism to get updates back to "authorized" server(s), and those "authorized" servers need to determine what to do with the reports. This does not need to be real-time. Near-time would suffice IMO. The interesting issue with regards to this component is indeed not the transport mechanism, but rather dealing with the influx of reports, and mitigating DOS's through floods of bogus reports. This is where things like the "web-of-trust" concept comes in handy. Sorry, but this is definitely getting off the operational charter of NANOG, so I'll stop. :-) There are a few people that have expressed interest in exploring this further. If anyone is interested drop me a line privately. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Asking the wrong questions is the leading cause of wrong answers \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Re: Any way to P-T-P Distribute the RBL lists?
Drew Weaver <[EMAIL PROTECTED]> inquired: >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? Fedex. "Never underestimate the bandwidth of a station wagon loaded with DLT cartridges barreling along the highway at 70mph"... Seriously, as has already been pointed out, the distribution side of the equation is the easy part. Server admins can use an out-of-band technique like ordinary dialup to get access to the blocklist. But generating the blocklist requires real-time reporting back to a central server. Even if the server is decentralized, it will still require a relatively small handful of accessable IP addresses. An out of band layer-2 network could be created for that at the peering points, so as to prevent outside attack. Probably worth doing among major ISPs. Wouldn't scale to end users, of course. But end users could still subscribe to the blocklist through periodic updates. The other obvious thing that could be done would work pretty much like caller ID: create a set of SMTP enhancements that allow email recipients to accept mail from those who have provided traceable ID to the ISPs that participate, and who have agreed to acceptable-use policies that place strict limits on bulk email. Wait, hasn't that been done? The pre-1987 ARPAnet? Oh yeah, we've outgrown that... Public humiliation might also work. Bring back the stockades so we can place spammers out front of courthouses everywhere. Too bad society's outgrown that too... -rich
Re: Any way to P-T-P Distribute the RBL lists?
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 [EMAIL PROTECTED], 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 <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Any way to P-T-P Distribute the RBL lists?
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 > >
Re: 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? 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
Re: Any way to P-T-P Distribute the RBL lists?
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 [EMAIL PROTECTED]
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
