Handling Botnets CS 236 Advanced Computer Security Peter Reiher April 15, 2008

Groups for This Week Golita Benoodi, Vishwa Goudar, Kuo-Yen Luo Darrell Carbajal, Aaron Hall, Ioannis Pefkianakis Andrew Castner, Jih Fan, Hootan Nikbakht Chia-Wei Chang, Nikolay Laptev, Min-Hsieh Tsai Chien-Chia Chen, Abishek Jain, Zhen Huang Yu Yuan Chen, Chen-Kuei Lee, Peter Wu Dae-Ki Cho, Chieh-Ning Lien, Faraz Zahabian Michael Cohen, Jason Liu, Peter Peterson

Outline The botnet problem Detecting bots An approach to handling bots

The Botnet Problem A botnet is a collection of compromised machines Under control of a single person Using distributed system techniques Used to perform various forms of attacks Usually those requiring lots of power

What Are Botnets Used For? Spam Distributed denial of service attacks Hosting of pirated content Hosting of phishing sites Harvesting of valuable data From the infected machines Much of their time spent on spreading

Botnet Software Each bot runs some special software Often built from a toolkit Used to control that machine Generally allows downloading of new attack code And upgrades of control software Incorporates some communication method To deliver commands to the bots

Botnet Communications Originally very unsophisticated All bots connected to an IRC channel Commands issued into the channel Starting to use peer technologies Similar to some file sharing systems Peers, superpeers, resiliency mechanisms Storm’s botnet uses peer techniques Stronger botnet security becoming common Passwords and encryption of traffic

Botnet Spreading Originally via worms and direct break-in attempts Increasingly through phishing and Trojan Horses E.g., the Mega-D and Pandex botnets Regardless of details, almost always automated

Characterizing Botnets Most commonly based on size Reliable reports of botnets of tens of thousands of nodes Less reliable reports of botnets with hundreds of thousands Controlling software also important Other characteristics less examined

Footprint vs. Effective Size Most botnets aren’t as powerful as their reported sizes suggest Only part of the botnet is available at any time Some machines go offline Control servers reach capacity Some machines are cleaned up Footprint is total size Effective size is how many machines are on-line at once

What Do You Do About Botnets? A very good question Without any good answers, so far Hot topic for research for some years Without commensurate good answers coming from the research community

Why Are Botnets Hard to Handle? Scale Anonymity Legal and international issues Fundamentally, if a node is known to be a bot, what then? How are we to handle huge numbers of infected nodes?

An Important Characteristic of Most Bots They belong to legitimate users Who typically are unaware of infection Legitimate user still uses machines for legitimate purposes Proportion of total traffic representing the bot activities could be small

A Consequence of This Characteristic Nuking bots is not an attractive option Either disabling the machines Or dropping all their packets You throw out the baby with the bath water Many sites would prefer to see traffic from known bot sites

Possible Approaches to Handling Botnets Clean up the nodes Can’t force people to do it Interfere with botnet operations Difficult and possibly illegal Shun bot nodes But much of their activity is legitimate And no good techniques for doing so

Identifying Bots An important first step How can we determine which nodes are bots? And which belong to which botnets? The most successful area of current botnet research Other than building them . . .

Core of the Common Approach Use honeypots/honeynets Seek to “become infected” Watch behavior of your infected machine Especially network communications Also, analyze bot code for hints

For Example, Bots often communicate via IRC For given botnet, which IRC channel? At which IRC server? Both can be determined by watching “captured” bot’s communications

Bots and Crypto Some bots have started to encrypt communications Captured bot might have the key stored internally, though Similarly, might have password required to contact other bots

Another Approach Predict which nodes will become bots By understanding how likely they are to be recruited Based on how “uncleanly” a network they live in Badly managed networks tend to have compromised machines

How Well Does This Work? Generally very accurate at positive identifications Usually not wrong when a bot is identified Those doing the watching are typically looking at small part of Internet So they might be missing stuff Also might be missing “stealth” bots Though no data to suggest that

So, What Do We Do About Bots? Nothing special, they aren’t really a new threat Clean up as many machines as possible Get inside them and rot them from within Attack back? Drop all their packets?

Another Solution Inspired by RFC 3514 Which introduced what is commonly called “the evil bit” Required (by standard) that attackers set a particular bit in their attack packets Allowing the network to identify them This RFC released April 1 2003 . . .

But Think About It Wouldn’t it be nice if bad packets did have an evil bit set? It’s ridiculous to assume attackers will set it But maybe someone else can? Perhaps by knowing which nodes send evil packets?

Bot Identification and Packet Marking We’re good (relatively) at identifying bots Why not use that knowledge to help us identify dangerous packets? By having a router on the path mark the bits Based on lists of known bots

Infamy A proposed system to do this Lives “somewhere in the network” Maybe at ingress point Maybe at egress point Maybe in the core Gets reliable list of bot addresses Marks all packets from those addresses

Infamy in Operation 1.2.3.4 1.2.3.4 1.36.7.125 1.133.2.8 1.2.3.4

And What Do We Do With That? Drop it Whatever we want Ignore the mark and accept it Examine it carefully

Advantages of Infamy Doesn’t mandate handling of packet Customizable for different situations More tolerant of false positives Can be located at many places in network Would allow those who care to be protected from botnet nodes

Possible Infamy Network Locations Near ingress Mark packets as they leave your network In core Mark packets in transit Near egress Mark packets as they enter your network

What’s The Mark? At the simplest, one bit Chosen from a couple of reserved bits But it could be more complicated Could steal the IP identification field Like everyone else Giving 16 bits of info

Issues for Infamy Where do you get the botnet identities? Specifics of design for various locations Especially in core routers How do you use multiple bits of mark? What interesting things can you do with a marked packet?

Obtaining Botnet Identities One oracle? Where’s it get its knowledge? Distributed system How do you combine listings? Trust issues? Do you age the list? At oracle? At Infamy marking site? How do you handle mistakes?

Design Specifics Scaling and other table design issues Degree of aggregation Can you mark fast enough? If not, is inaccuracy OK? What kinds and how much?

Using Multiple Bits What for? Certainty? Age? Degree of evil? “Flavor” of evil Spam vs. DDoS vs. scanning vs. . . . Type of botnet?

What Do You Do With Marks? Nothing Drop marked packets Deliver to IDS system In series or parallel Use at application level? How?