Programming and Hosting Environments

I develop harvesters and the harvester servers in either a WAMP or LAMP environment, where Ubuntu is my Linux distribution of choice. (I have no particular technical preference for Ubuntu; it's mostly a matter of familiarity.) I've written bots in Perl, Java, Visual Basic, and even Tcl/Tk. For the last 12 years, however, I've programmed exclusively in PHP. In addition to the simplicity of the language, PHP interfaces well with libcurl [5], which makes downloading web pages easy. In addition to the open source tools I described earlier, the only other tool I use is a text editor, usually jEdit [6].

Over the years, I've deployed my projects in various production environments. Initially, my production servers were all based on FreeBSD. Later, I moved to cheap, hosted Linux environments, where the operative word is "cheap." My experience is that hosted solutions costing as little as UK£ 3.00 or US$ 5.99 a month are more than adequate for hosting harvester servers. The reason I can get by with minimal hosting is that because my botnets provide a very task-specific benefit, they have few human users. Lately, I've been enjoying the flexibility and cost advantages of cloud-based Linux solutions, primarily in Amazon's EC2, where Ubuntu is the standard distribution.

Benefits of the Botnet Architecture

The classic botnet architecture offers many benefits. The most obvious is that it is easy to scale the capacity of the architecture by simply adding harvesters. The prospect of hosting harvesters in a cloud environment is especially attractive for this reason alone. Multiple harvesters also provide opportunities for redundancy and let you use multiple IP addresses. As seen in the example of the sniper botnet, botnet technology leads to obvious competitive advantages. In the case of the example, my client was vastly more competitive than other automotive dealerships that didn't deploy a botnet.

You might be wondering whether applying botnets to business problems is fair. In the case of the example – a car-buying botnet – the alternative was to fill a room with sales and administrative personnel and instruct each of them to repeatedly refresh their browsers until the cars they were assigned were available for purchase. Using the human approach, the same amount of server resources (or more) were expended, but at a higher cost and with a poorer result for my client. The one difference is that my botnet approach used less labor.

With the botnet, the website that offered the cars still made their sales. In fact, the botnet might have even saved the seller money because the process was automated. As such, opportunities for error in payment or shipping were drastically reduced. For the year that project ran, the botnet never caused an error that cost the sales website any money or lost time.

The true danger in dismissing nontraditional ideas such as commercial botnets is the risk of discouraging developers from using their skills in innovative ways.

Living in the Shadows

Even when everything is legal and aboveboard, it is still advantageous for botnet developers not to show all their cards. The only reason I'm using an actual example in this article is because the application's natural life came to an end years ago, and I got specific permission from my client to write about this project; otherwise, I'm quite tight-lipped about the projects I develop. The reason to effectively "live in the shadows" is to hide any clues that I'm developing technology to solve a problem that everyone else handles traditionally. This policy is best because you never know who reads server logs, and you never know who knows your client's competitors.

Although many botnets depend on proxies to cloak their path, I think the best way to develop stealthy botnets is to simulate human activity as closely as possible. Ways to make a botnet look human include:

• inserting random delays;
• limiting interaction with the target website;
• using multiple user accounts (if possible or necessary); and
• running your botnet during peak usage periods.

The last point is often overlooked, but if you want your botnet to look like a person, it's best to run it when everyone else is using the targeted website. Running a botnet during peak periods will also make the log entries of your server less conspicuous.