Last year I accidentally invented a potential "Grand Unified Solution" for spam, viruses, zombie-nets and practically every other nasty internet behaviour.
It goes something like this.
The problem is not that any particular host is $bad, but that it is doing something $wrong. Some things doing $wrong are _also_ $bad, but not always so.
Spam filtering and so on is only fixing the result of the bad behaviour, not dealing with the source. It is just cleaning up the mess.
What if we tried to stop the bad host while it was still doing $wrong, and _only_ while it is doing wrong. This limits damage when you arn't doing $wrong. It also means we don't have to maintain $state globally.
We'd need to do this threat response fast. As soon as a zombie starts a spam run, we want to catch it in under 10 seconds. (preferably 1 second)
This response needs to be very flexible and distributed. Anything that detects bad behaviour should be able to trigger a response from wherever appropriate. Having a distributed solution also allows for evolution of the most appropriate version of the solution, and helps it adapt to improved $wrong weaponry.
So, all we really need, is a way of letting anything that can detect trouble tell anything that can respond to it to go into action.
In other words, a gigantic, decentralised, low cost, medium-high volume and FAST 1-to-many messaging system.
Luckily for us, such a messaging system already exists in the form of IRC.
Yes, IRC. The ThreatNet proposal consists of a set of rules that can be implemented for any program to allow it to connect to a small or large IRC network and swap messages with other programs.
That way, Randal's grey-listing secondary-MX detector can feed messages to BillN's adaptive firewall, and anything else that it is interested.
If a zombie starts spamming, as soon as Randal gets spammed and responds by blocking the host, BillN is safe from their spam also, and anyone else connected to the ThreatNet is free to respond any way they like also.
All I hope to define is way to define ThreatNet message protocols (and provide a basic default protocol) and define the behaviour of an individual bot (and provide a toolkit for building them).
You can join a global open network, a protected commercial network, a network for your local Linux Users Group or local business group, or set one up across the various parts of your own company. The deployment method is up to you.
This deployment flexibility allows the concept to adapt and evolve policies for handling bad behaviour and trust issues.
Unfortunately, the idea never went anywhere... until today. BillN has said he's now working as a security person for his company dealing with firewall logs and so on, and is keen to help develop the idea. Anyone else that wants to help, feel free to join in.
You can see the very early trivial modules in the ThreatNet:: namespace in CPAN, or join us in FreeNode #threatnet. The original ThreatNet specification can be located at http://ali.as/devel/threatnetwork.html
Re:Scalability?
Alias on 2005-03-21T00:36:07
In order for the concept to work at all, I need a decentralised, stateless, near-real-time and many-to-many communications system.
Anything that fits this profile will suffice. Unfortunately, DNS doesn't. Any centralised system is subject to attack, both techical and legal.
IRC _does_ meet the profile, although you are correct that it might not scale as far as I might like. But 10,000 members passing around 10,000,000 threat messages a day is a good start. I'm sure once we start to hit such limits, someone will provide a better solution for the carrier.
Re:Abuse protection?
Alias on 2005-03-21T00:39:29
Luckily, that isn't my problem. The problem of trust is one that each network operator will have to deal with.
All I can do is to not mandate a particular solution, and instead to let evolution decide.
On my company-internal ThreatNet, I simple have the server only allow connections from IPs inside my network.
On a commercial one, perhaps we use SIRC, passworded accounts and certificates to verify validated users.
I imagine there are a number of different solutions to the trust problem.
