Technical How Outbound Spam Affects Cloud Hosting Providers By Ken Simpson | 6 minute read We recently implemented our transparent outbound spam protection solution with a provider of “cloud” or “virtual” hosting services. I thought I would write a blog post anonymously discussing some of the interesting results and observations we can make regarding their outbound spam problem. One day, I hope to form this into a case study, which we will publish on our web site. The Cloud Provides a Great Platform for Spammers We normally think of spam as originating from “botnets” of compromised personal computers. This is not a bad assumption to make, because it seems the majority of the world’s 300B spam messages do in fact still originated from compromised PCs. But botnets are not the only game in town. In fact, the emergence of cloud hosting services such as Amazon EC2, Rackspace Cloud, and others have provided a powerful, easy to use new platform for spammers to abuse. A cloud service typically provides a given unit of CPU, hard disk, and network resources at an hourly or monthly rental rate. In practice, this means a Linux machine instance hosted within a virtual machine of some sort. The cloud service provider chops up thousands of physical machines, hard disks, etc.. essentially selling them piecemeal to customers to reap a return on their capital investment. Here’s how spammers abuse cloud services: The blobs in Red indicate steps taken by the spammer, and the consequences of spamming. The blogs in blue indicate the hosting provider’s steps. Here’s the process in plain English: Spammer uses a stolen credit card to rent a quantum of cloud hosting infrastructure. The owner of the stolen credit card won’t likely find out about the fraud until his or her statement arrives in 6 to 8 weeks’ time. The spammer installs spamming software on the cloud hosting machine, and begins sending out spam. Huge volumes of spam are delivered from the hosting machine. We have seen single machine instances that send more than a million messages a day. The hosting provider receives spam complaints from the rest of the Internet (through feedback loop systems like AOL’s SCOMP and ARF messages from other providers). Eventually, the credit card holder complains about the fraudulent transaction the spammer made, and requests a chargeback from the credit card company. The chargeback costs the cloud hosting provider anywhere from $50 to $100 or more (smaller hosting providers can pay much more if the fraud rate increases). Credit card issuers can also require a “holdback” if fraud rates become particularly high; and this holdback amount can cripple the hosting provider by tying up valuable cash resources essentially on a permanent basis. How Hosting Spam Differs from Botnet Spam For spammers, the cloud hosting environment is in many ways superior to using a botnet, and in some ways is inferior. The superior features of a cloud hosting environment include: Static IP addresses: Cloud hosting providers will often offer static IP addresses, which are considered more reliable by email receivers because they are more reasonably associated with legitimate email servers; Great bandwidth: Cloud hosting providers offer awesome upstream network performance, easily beating the performance and throughput of any consumer-grade ISP network; A flexible and easy to use operating system: A cloud hosted server provides the spammer with a complete Linux operating system, on which sophisticated spamming tools can be installed. By contrast, a compromised PC presents a very challenging software platform because the spamming software must stealthily reside within an operating system that is designed for real-time use by an interactive user; and, 24×7 around the clock operation: Unlike compromised PCs, which are often turned off at night, cloud hosting services remain up 24 hours a day, 7 days a week. As a result, we can observe some marked differences between spam that is delivered from cloud hosting networks versus spam that is delivered via a botnet. To illustrate, let’s look at a couple of graphs to show how hosting networks are “24×7” whereas ISP networks operate mostly in the daytime – essentially giving a 16-hour advantage to the hosting networks as a spamming platform: First, here is a graph showing the sidereal (i.e. daytime-only) nature of SMTP traffic from an ISP’s subscriber network: This data is from a customer in Asia, so the time zone shifts things a bit to the right of where they would be if they were in our time zone here in Vancouver, Canada.. but you get the idea. People don’t generally have their computers turned on at night, and as a result, the spammers don’t have access to them to send email. In fact, this customer is located in a developing nation in Asia, where the daytime/night-time difference is even more dramatic than with ISPs in developed countries (because there literally isn’t power at night). Now, let’s look at a graph from a cloud hosting network: The hosting provider’s network sends email 24×7. The spikes in traffic show times when a single machine leveraged the enormous capacity of a cloud hosting instance to establish upwards of 8,000 SMTP connections per second. Conclusions and Recommendations Spammers threaten the viability of cloud hosting infrastructure by abusing these services and generating excessive customer support and fraud-mitigation costs. Having now seen a good sample of traffic from cloud hosting networks and comparing that against traffic from ISP networks, I think we can make the following recommendations to cloud hosting providers: It’s useful to have a real-time transparent spam filtering solution in place – waiting for feedback from the Internet about the spammers within a cloud hosting network introduces a delay that is exploited by spammers to great effect. If you can catch the spam in real-time — even if your filtering isn’t perfect — you’ll make your network less attractive to spammers. Reporting is really important – even with a transparent outbound spam filtering solution, you will still need to know which customers are the fraudsters. This is harder than it sounds, and I will try to cover this topic in a future blog post. Until then, I hope you enjoyed reading this post and look forward to your comments and questions. Regards, Ken