BotGraph: Large Scale Spamming Botnet Detection

Summary

This paper looks for correlations in bot activity to detect and stop botnet account registrations. The design uses two methods for detecting botnets: aggressive signup detection and login across different AS detection.

The aggressive signup detection uses an exponentially weighted moving average of signups. If the the number of signups jumps unexpectedly the system assumes it may be due to bot activity. This assumes that bot owners cannot slowly ramp up the signup rate due to high churn of bot machines.

BotGraph, also detects "stealthy bot-accounts." These are groups of bots that operate in a collaborative way. They authors assume that collaborative bots will login to a small number of accounts in many locations. This is justified by the fact that aggressive signup detection limits the number of available accounts. The proposed technique create a graph of users with an edge weight equal to the number of ASes both users have logged in from. They use this to look for clusters of users with high edge weights - these usually indicate bot accounts.

Thoughts

This paper makes many assumptions about the limitation of botnets. For example, I am not convinced that it is impossible to ramp up account creation from one node slowly enough to avoid the EWMA limit. Similarly, bot owners could simply assign one account per bot or one account per AS to defeat the stealthy bot detection algorithm. While the proposed techniques probably work well now, I suspect that when deployed widely botnets well adapt and overcome these protections.

Not-a-Bot: Improving Service Availability in the Face of Botnet Attacks

Summary

This paper aims to reduce botnet attacks by identifying humans through activity patterns. Specifically, the authors propose installing a secure, trusted piece of code which will detect "human activity" and attest that requests are coming from a human.

The proposed design uses an "Attester" which is loaded from a TPM chip before the OS. This code intercepts all mouse and keyboard activity. The attester could operate in one of two ways: either prompt the user to answer questions or guess that a human is making requests. The authors choose to guess when a human is making the requests because the alternative might lead to "always-click-OK" behavior. When keyboard or mouse activity is detected within a short time of an HTTP request, the Attester sends a cryptographically signed token along with the request. This token attests that a user made this request no a bot.

The key benefit of the proposed technique over CAPTCHA is that it attests that the originating requests come from a human at the requesting machine. CAPTCHA images can be sent to remote human solvers while the proposed attester is not susceptible to this.

Thoughts

I like the idea of using a trusted piece of code to ensure that the attestation comes from the requesting machine and has not been tampered with. However, I can't imagine this being widely used. Presumably, users install this voluntarily, so backwards compatibility would be required thus leaving an way for bots to operate. The second problem is that bots could become smarter and only send requests after user activity.

Skilled in the Art of Being Idle: Reducing Energy Waste in Networked Systems

Summary

This paper proposes the idea of sleeping networked desktops when they are idle. It analyzes the traffic normally seen by desktops during idle periods and concludes that a proxy is necessary to handle this traffic on behalf of the sleeping node.

The authors address three main problems:

1. How much energy can be saved by sleeping nodes when idle?
2. What network traffic do idle machines use?
3. How to design a proxy to handle traffic on behalf of sleeping nodes?

The authors find that enterprise desktops are idle over 50% of the time and most have power management disabled. Thus, there is an opportunity for large energy savings by sleeping nodes.

Next, the authors look at network traffic seen by idle machines. They find that office machines receive roughly 3 packets a second during idle times. Therefore, the periods of network inactivity are very small. The authors classify this traffic and find that over 50% of incoming traffic is multicast and broadcast. The majority of broadcast traffic is ARP and NetBIOS, while the majority of multicast is router traffic. A large part of this traffic can safely be ignored but some requests must be replied to.

The authors design a proxy that handles traffic on behalf of sleeping nodes. It responds to DHCP, ARP and NetBIOS traffic, it ignores router traffic, and wakes the node for all other incoming traffic.

Thoughts

The most interesting part of this paper was the classification of network traffic seen by idle machines. It is unfortunate that a proxy is required to handle traffic for sleeping nodes. It would be interesting to think about how protocols could be redesigned to support sleeping nodes without a proxy.

Cutting the Electric Bill for Internet-Scale Systems

Summary

The key idea of this paper is to shift load to data centers with lower energy costs. The authors make two observation that enable the proposed design:

1. Electricity prices vary. The price of electricity varies both in time and by location. For example, prices at night are generally less than during the day and prices for locations closer to generators are less than far away locations.
2. Large distributed systems already incorporate request routing and replication. Most internet services can easily route requests to one of multiple locations.

The savings in energy cost depends on the "energy elasticity" (also known as power proportionality) of clusters. In other words, how much does the energy consumption drop in response to a drop in load. The authors estimate that current servers use about 60% of peak power when idle, but they expect this number to improve.

The authors examine the price variations for energy over time and in various locations. They show that prices often vary by a factor of 2 with a day. They also show that prices are not correlated across different locations thus enabling savings by redirecting load.

Overall, the authors estimate that they can save 2% of energy costs now and that savings increase rapidly with system energy elasticity. In a fully elastic system they expect over 30% cost savings.

Thoughts

This paper presents a neat idea for cost savings, however, as the authors point out it hinges on the energy elasticity of servers. Without improvements in elasticity the savings would be fairly negligible. I suspect that this may be part of the reason companies don't bother to do this right now.