One of the problems with public IaaS is that we sometimes lose visibility over security. In other words, most security analysts regularly check their perimeter for signs of compromise, but how many take the time to check their cloud server instances as well? Are you the one in control of your public VMs? Are you sure? I plan on doing a series of blog posts to highlight just how much malicious activity is taking place in public IaaS. My hope is that the data will help motivate people to focus more on security within public cloud. In this blog entry I will strictly focus on SSH.
I collected data for a week across eight VMs located in two public IaaS clouds. I specifically ensured that each server ended up in different subnets, to help avoid multiple hits during the same scan. I wanted to start with SSH, as anyone who can successfully break in will have command line access and potentially do whatever they want to the system. The data ignores simple port scans and focuses on the number of logon attempts made to the SSH port. This will help weed out the curious from the folks with malicious intent.
During testing, each server received approximately 1,300 SSH login attempts per day. Some IP’s would make three password tries on root and then leave, while others would bang away for days trying to get in, using multiple common accounts (oracle, cvs, test, etc.). It is this latter group that is the most concerning since any account with a dictionary based password may eventually fall.
Figure 1 is a breakdown of the attempts based on the country of the source IP address. Any country responsible for a minimal number of probes was parsed out.
SSH by country
For anyone who’s tracked malicious activity, the above chart will not be all that surprising. It is not uncommon to see China and the US top the scales as the source of malicious attacks. Noticeably missing is Russia, from which I saw very few attempts. Also note that sometimes geolocation data is faulty, so the source may actually be a bordering country. Also note that the chart describes the source of the attack, not necessarily the the physical location of the attacker attempting to break in.
I decided to dig a little deeper on the US traffic and was pretty surprised when I started identifying a distinct pattern. Most of the login attempts originating from the US were coming from other public cloud VM instances. The breakdown is shown in Figure 2. Historically, the top US source has been home computers located on cable or DSL networks. This is the first time I’ve noticed a change to that pattern.
Figure 2: SSH US Breakdown
Just as interesting, was that an overwhelming majority of the public VMs appeared to be legitimate servers carrying on some form of business or personal activity. I found Web servers, game servers, application servers and even database servers. I did not attempt to enumerate OS or patch level, as I wanted to minimize the amount of suspicious traffic I was generating.
Public IaaS servers are being compromised and then used for malicious intent. Note that since most public providers charge for network utilization, the owners of these VMs are paying in real money for their lack of security. The greater the number of attacks being launched by the compromised server, the larger the bill the tenant will receive at the end of the month. It is entirely possible that the attacker is also making use of local CPU time, thus driving costs up even higher.
What you can do:
- Run GhostPorts so your SSH server cannot even be seen by those with malicious intent.
- Install a tool such as Fail2ban to limit the number of brute force attempts an attacker can make. Just don’t set the threshold so low that you inadvertently ban legitimate users.
- Force users to use SSH public/private key authentication. This will not stop people from trying to get in, and it will not protect you from potential buffer overflows, but it does prevent attackers from password guessing their way into your server.