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

2. 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

3. Outline
The botnet problem
Detecting bots
An approach to handling bots

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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?

13. 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

14. 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

15. 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

16. 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 . . .

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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?

23. 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

24. 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?

25. 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

26. 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

27. Infamy in Operation

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

29. 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

30. 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

31. 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

32. 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?

33. 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?

34. 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?

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

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