Prototype Software Sniffs Out, Disrupts Botnets

coondoggie writes "Earlier this week researchers unveiled a system to identify and eradicate botnets in the wild. While currently only a prototype, Georgia Tech's BotSniffer would use network-based anomaly detection to identify botnet command and control channels in a LAN. The system wouldn't require any prior knowledge of signatures or server addresses. 'The researchers said their prototype, which was presented at the Internet Society's Network and Distributed System Security Symposium this week, is based on the fact that botnets engage in coordinated communication, propagation, and attack and fraudulent activities.'"

Comments

Useful but fundamentally flawed....

[DigitalisAkujin]

This will work for plain text IRC connections but what if the bot is on an encrypted IRC connection?

While this is a step in the right direction it will be out maneuvered quickly.

Re:Useful but fundamentally flawed....

[Anonymous Coward]

Don't be so quick to say that it won't work. We don't have enough information as to how it is designed and you don't understand anomaly based detection works. The idea behind network anomaly based detections is to identify communication between two or more host that aren't supposed to exist or that didn't in the past. That is the 5 cents explanation of it.

Re:Useful but fundamentally flawed....

[TubeSteak]

"For instance, at a similar time, the bots within a botnet will execute the same command -- obtain system information, scan the network -- and report to the command and control server with the progress/result of the task. Normal network activities are unlikely to demonstrate such a synchronized or correlated behavior." That is why it won't matter if the botnet is using encrypted communications or not.

Unfortunately, it wouldn't be much of a challenge to institute a randomized delay between receiving commands, executing them, and reporting back to the C&C. The C&C could even change the randomization factor depending on how many bots are in that specific subnet of IPs. More bots = more time delay to thwart the sniffer.

Re:Useful but fundamentally flawed....

[Professr3]

The very nature of botnet activities usually requires a coordinated effort. You can't DDOS a website with randomly-delayed attacks from each host, because then it wouldn't be a DDOS, just a slower increase in traffic. Spam campaigns usually only work for the first few minutes before services catch on, and then that particular spam campaign is over. Unless all the bots participate reasonably simultaneously, they can't accomplish their goals as well.

Re:Useful but fundamentally flawed....

[eonlabs]

This brings me to several questions:

What happens if a new host, or several new hosts are added to the network?
What happens if this is a public wifi where new hosts are added and dropped all the time?

If the functionality is as described in the article summary and it looks for coordinated communications, how will it interpret bittorrent style communications where a lot of different computers, some possibly infected, most not, transferring data to and from a single host trying to download?

It sounds like swarming algorithms are the kind of behavior it would be looking for.
Just thinking out loud...

Even easier way ... .

[Anonymous Coward]

Just run a web server where you allow things like .. .

    index.php?main=xxx

and then watch the attempts that come in for xxx, they will
all be scripts that trigger the botnets. grab the scripts
and you have the irc server, the channel, etc.

A recent one that I saw was one katana.webchat.org in channel
#msdos -- no idea if it is still running (ironic since webchat
is supposed to have a security team). I reported it, but never
heard anything back).

Here are a bunch of other ones, access to botnets, free of
charge.

http://www.forestfamily.org/garc/.php/meifase.txt
http://bialoka123.fileave.com/script9.txt
http://raptortx.googlepages.com/inc3.txt
http://snock.host.sk/spread.txt
http://bialoka123.fileave.com/script9.txt
http://members.lycos.co.uk/enviescraps/pbot.txt
http://gikowns.googlepages.com/BOTNET-GIKO.txt
http://www.ligseg.com.br/Etc/24.gif
http://76.162.170.34/Photos/pbot
http://www.hotjazz.xpg.com.br/ty.txt

Use at your own risk, and maybe, these folks will get off their rear ends and shut these things down.

Will it stop BitTorrent?

[Anonymous Coward]

At the traffic level, BitTorrent looks a lot like a bot net. It has a central controllers (the tracker) and makes random connections to other peers, which then trade large amounts of data.

So would this kill BitTorrent? I've heard network security people explain how peer-to-peer technologies are a dead end because they're impossible to run on a secure network since they do look like botnets. How does this deal with that?

Botnets are easy to detect and control

[colinmcnamara]

Botnets are easy to detect and control. The problem is that the majority of organizations have not taken the steps to stop both their communication and control channels, and their ability to launch attacks. What should everybody do ?

1. Deny IRC traffic at your firewalls. If there is a business need for IRC then setup a IRC proxy, or inline authentication. This simple step will stop many of the bots out there from phoning home.

2. Enable reverse path detection on your network devices. This forces your internal routers to check whether the source ip address that the bot is sending, is available out the interface that your comprimised host exists on.

3. Enable DHCP snooping on your edge switches. By configuring this feature the switchport that your host plugs into passively observes what IP address was given to your computer. If traffic is spoofed (a common occurrence for botnets) the switchport effectively shuts your host down.

4. Monitor your network. There many free and commercial products that will make it clear that your traffic profiles have changed. Some good free tools for this are Cacti - http://www.cacti.net/, Nagios - http://www.nagios.org/ and NTOP - http://www.ntop.org/

5. Utilize update antivirus technology, hopefully one that reports to a central console. These are simple steps, that frankly most people do not use in their networks. If they would the botnet issue would be greatly minimized.