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
Scalability? (Score:2)
Re:Scalability? (Score:1)
Abuse protection? (Score:1)
Re:Abuse protection? (Score:1)
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.