Sadly, it is now time for security workers to start using self-replicating anti-bots.

Above comment is exactly what I thought...although I don't see anything sad about it.

It is fairly common in counter-insurgency efforts for security forces to adopt guerrilla tactics, or, if you prefer, attacking a mesh network with a decentralized, autonomous (or in this case, automated) approach. I am surprised that it has taken this long for other people to come to that conclusion; it is the most effective way and ultimately, probably the only way to counter sophisticated, decentralized botnets spread by tricking unwitting users.

Considering the fact that our own bodies' immune systems do this anytime a pathogen is introduced into our system, I see nothing morally or ethically wrong with this so long as the anti-botnet, anti-virus does not itself compromise the unwitting host computer. Most people do not pay attention to what sites they visit or what links they click, and if their computer is compromised without them knowing it, we have to also assume that they will not know enough to check for trojans, etc. So...you can go after the botnet hubs, or you can take advantage ot people's ignorance/carelessness by tricking them into uploading anti-virus programs that will detect and uninstall malware, etc.

I think it is a great idea to have internet pathogens - but then they could be subject to gurrilla warfare too, turned about and used against us.

What about a sort of community updated swarm?

Reduces the potential for contaminated pathogens to live for very long.

The problem with writing a bot-attacking "antibody" is that it can create a very big mess by itself. There have been a few sysadmins who've gone to jail for their good intentions. I remember one instance where the fix itself left a gaping security hole.

As for users getting a clue about proper PC administration, I don't think they will ever do that. My landlord was paranoid of MS' yellow update shield icon, so he wasn't clicking on it for updates.

Probably the best defense is for ISPs to monitor for bad traffic. Comcast already does something like this, but it does it to line its own pockets. VPN traffic is de-prioritized unless you pay an extra service rate. They should be monitoring for mal-traffic and shutting down ports.

As tempting as a white hat VX is, does anyone remember the Nachia/Welchia worm? Fighting fire with fire doesn't always help.

But I suppose you could try to use the decentralized nature of the fast flux against them. What's stopping a computer from acting as if it's part of the botnet, and then claiming to be one of the redirecting servers, poisoning the stream? If the white hat systems can't tell which head of the hydra is the root, how would the others? If you have this at the ISP level, only a handful of moles in each subnet, the IPs of the moles would be random enough that later botnets can't filter them out without excluding a major portion of their 'market'.

That way, unlike Nachia, which flooded the network indiscriminately, the poison pill is only going to those already infected and listening in, and not infecting innocents.

A Viable solution could be to persuade or coerce several telecoms who do the Internet data transfer to block bots. When blocked consumers call to complain they will be delightfully informed that their computer has been infected, and has been used by others illegally and will not be allowed onto the network until their computer is no longer a threat to the outer world, not unlike a vehicle that fails emissions testing

The data can be obtained simply by tracing individual bots themselves post DOS attack or trace them through the website they support (such as the Chinese fishing Website.)

If the botnets continue to evolve over the next decade they will become a serious security threat, surely to treat the malware problem we should release "viral cleansing goodware" aka Web antibiotic or Web disinfectant which zeroes/trashes the bios on unpatched win3.11, win98, winME, win....(insert name of actually vulnerable OS here) etcetera. Might have to pass a few (non)liability laws first to get round the odd hospital, nuclear reactor that is 'doing fine' with NT3.51, but that the 'goodware' takes-out, you could even envisage a global viral Linux-type SHUTDOWN broadcast.....

"Your PC will be trashed in 5 days 3 hours and 27 seconds, please patch NOW"

I've been spotting some of these, but it is just so hard trying to get the domain registrars of the name server to blackhole the nameserver involved. Even when you give clear evidence of lots of spam, lots of spam domains using the nameserver and show the nameserver has no legitimate use, the registrars fail to take the proper action. I've submitted reports for weeks as have lots of other people for some name servers.

Instructions for a registrar to shutdown a name server are given here:

http://www.spamtrackers.eu/wiki/index.php?title=Registrar_Advice

http://www.spamtrackers.eu/wiki/index.php?title=Suspending_an_EPP_name_server_domain

It's so hard to get them to do this critical first stage involving the glue records.

1. Change the name server's address record to a nonroutable black hole address.

A black hole address is one such as 0.0.0.0 or 61.61.61.61.

Apply the following status to the domain:

2. Ensure that the address record for the name server cannot be changed back.

ClientUpdateProhibited

3. Prevent the name server's domain from leaving to an abuse-friendly registrar.

ClientDeleteProhibited

ClientTransferProhibited

4. Ensure that the name server's domain does not resolve at the registry.

ClientHold

Silly question - have the authorities not had the option of acquiring infected machines before now, and to they not have the skills to reverse engineer them ?

Surely if you picked up one of the control servers - and I'm sure at least one must have given itself away by now, bearing in mind how often they're accessed from around the world - you could reverse engineer the malware on it in order to disable the botnet as the compromised machines "phoned home" for their instructions.

A bot herder could lose many machines before he was made aware of the problem AND lose one or more of his work-horses in the process. Personally I would be happy to "donate" an infected machine to the relevant authorities if I found one in my inventory.

"It is fairly common in counter-insurgency efforts for security forces to adopt guerrilla tactics or, if you prefer, attacking a mesh network with a decentralized, autonomous (or in this case, automated) approach. I am surprised that it has taken this long for other people to come to that conclusion; it is the most effective way and ultimately, probably the only way to counter sophisticated, decentralized botnets spread by tricking unwitting users."

Even if that worked, you would almost certainly run into legal difficulties. You can't just copy a criminal's tactics action for action, because your aims and justification are totally different (real life counter-insurgency has no direct way of responding to suicide bombings for example).

If a law enforcement agency starts putting its own "anti-bot" bots on private computers and servers, it will be breaking all kinds of privacy laws, not to mention upsetting innocent people who don't want their computers interfered with by the government. Of course you could start to dismantle those laws, at least partially, but then you open the door for general spying by law enforcement agencies supposedly to stop botnets but (in some cases) for completely different reasons.

Aren't the bots already vulnerable to exploits? We know that the bots can be attacked by other malware, as reported by El Reg. Why not have a law enforcement variety of trojan that causes the infected bot to report back to the agency, or a simple kill script that drops the bot off the network?

Many enterprise AV packages support this type of functionality off the shelf, so another option is for service providers to include a managed AV solution to secure their client base.