At 06:50 PM 09/26/2003, Pete McNeil wrote:
At 02:30 PM 9/26/2003 -0700, you wrote:
> I've said it before, I'll say it again. It's time to leverage the power
> of the network agianst abuse on that same network.
Pete,
You are preaching to the choir ;)
When will it be ready?
Pedaling as fast as I can...
Anybody know how to eliminate the need for sleep?
From CNN:
Stay-awake pill
The maker of a pill that helps people stay awake hopes government regulators will OK wider use of the drug. CNN medical correspondent Dr. Sanjay Gupta spoke with CNN�s Bill Hemmer about the pill. �The drug is called Provigil and it's been around for some time now. � There�s going to be an FDA advisory committee that's going to suggest that it be used for shift workers, for people who have obstructive sleep apnea -- that's people who have a breathing difficulty that keeps them up at night -- MS as well, and insomnia. � I think what people are really rallying behind is the fact that [the drug] is not a stimulant. � In fact, [they�re saying] the side effects are actually less than that of even caffeine.�
Wow - thanks.
That said, here is a solution if somebody wants to pound it (I can't do it right now, sorry). I can lay out a quick architecture - it moves fast, keep up :-)
Take a look at entropy. (http://entropy.stop1984.com/en/home.html). This is not perfect, but it exists and it's good enough to start with.
The key piece of this technology is that it is a distributed file system - distributed meaning there is no single node to attack. This also means that it scales well because, presumably, anybody using the service would be operating as one of the nodes - so the load of all queries would be split/balanced among all of the participants.
Segments of zone files can be stored into this distributed network with file names matching the first two octets of the IP... so, File MyFavoriteBL-216.88 would be a binary file containing say 64K bytes - represented by a two byte array address for the next two octets. A ( 0 ) byte means no result. A ( 2 ) byte means block this (analagous to 127.0.0.2). Any other values would be defined by the provider (in this case MyFavoriteBL). A non-existent file also means that the zone doesn't exist. (I know I'm using zone the wrong way - but it's a handy term for this work).
Trouble is this: This is a publicly available file so if you can get to the key for the file you will/may be able to alter it. Spammers would simply hack up the files - useless. What to do.
Solution: This is very much like r&d work I've been doing on a secure, distributed database architecture - what is required is more than one key where each key is able to access the file (or file segment) with specific access rights.
For this application there are only two key types required.
If you access the data through one path (user key) then you have read-only access. If you access the data through the second path (admin key) then you have write access. The publisher then uses the admin key to publish their data from any accessible node on the 'net. Subscribers can only read.
Next, publication with the admin key may not be performed at the source of the request. (This prevents hacking). Instead, write requests are handled by having a peer generate a random challenge - the challenge is added to he admin key by the source of the write request and the sha1 of that result (the access key) is added to the segments of the file that are sent to that peer. The access key is recalculated at the peer containing the data segment in question. If the access key matches then the write is performed. If not then the request is rejected. If more than some limit of rejections occurs then the requesting node is expelled from the network.
There are two nearly identical file segments maintained in the file system. The read access segment is encrypted only with the read access key. The write segment is encoded with the write access key.
When a write access segment is overwritten/created, the read segment is cloned from that segment. The read access key is encoded/replicated within the write access segment to facilitate this.
The segments are encoded using an odd-even byte split, and encrypted with a convolution stream encryption (like Mangler (see Sniffer2 source)) with the key at the end of the segment so that it acts like a CRC - specifically, if a segment is altered (or read bad from a disc) then it will not be successfully decrypted - and a brute force attack requires that the entire segment be decrypted with each trial-key before validation can be achieved.
--- I tried not to be too technical - hope this is enough to get the ball rolling.
If a version of Entropy (or another similar p2p engine) can be modified to implement the above publish/subscribe protocols then we create an environment where a publisher can access a widely distributed network of peers maintained by the subscribers.
The publisher can create the file and nobody can modify it except for the publisher.
Subscribers can reliably read the file(s) and the system is largely immune to DDoS attacks - because there is no central point of failure and because any attempt to mount the attack would essentially create so many additional peers as to thwart the attempt. (BYOB = Bring Your Own Bandwidth).
We will be bringing a version of our system out of the lab on or about V4 of Message Sniffer, but you folks should not wait for that. Entropy is close enough that with a few tweaks the system could be up and running.
(I know the changes are not trivial, but they're not rocket science either - so this should be doable - even doable quickly relatively quickly.)
Note that w/ the publish/subscribe controls in place there is now a conduit where the publisher of MyFavoriteBL can retrieve spamtrap/log/etc data from their friends - again without intrusion - this prevents those resources from becoming a point of attack.
Hope this helps,
_M
