With Infrastructure as a Service, companies can create servers, storage and networking resources with just a few...
mouse clicks. However, of all the cloud models, IaaS is the one where companies have the most responsibility for maintaining security. Major IaaS providers like Amazon Web Services and Rackspace Hosting Inc. have secured the lower-level infrastructure, but what happens if the server your company manages is not properly secured? What types of risks are servers exposed to on these virtual infrastructures? To find the answers, I conducted an experiment by setting up a standard virtual server utilizing Rackspace. The test illustrates the security measures companies should take to ensure IaaS security.
IaaS security test settings
For the experiment, I provisioned a Fedora 13 Linux server to host standard services like Apache, SSH and FTP, simulating potential services present on any standard company server. Rackspace offers many different options for the configuration of network security, but they are not enabled by default. I left this default network security setup from Rackspace in place to simulate a configuration oversight error, and installed the Snort open source intrusion detection system using both the registered and emerging-threats rulesets in order to monitor the results. I purposefully avoided services that tend to attract a lot of attention from hackers, such as SMTP (mail) or Samba (Windows file sharing), as there would be too many probes to make this a manageable test. I installed all available Fedora security patches, with the primary goal to simulate and monitor a server setup by competent IT staff who just forgot about the Rackspace security configuration.
SSH and brute force attacks
The first detected probes were what any experienced Linux server administrator has seen many times: Automated bots quickly detected the SSH ports, followed by brute force attempts against the user accounts on the server. This type of attack dominated the results of the experiment with over 66% of the attacks directed against the SSH protocol. These brute force attempts weren’t sophisticated, looking only for common account names and default passwords; none succeeded. However, they did generate many system logs that needed to be managed. Had there been any default accounts or weak passwords, this system would have been compromised. The lesson here: SSH can take a lot of abuse and should be secured in a cloud environment just as in a hosted environment.
The next probes were much more specific and surprising; they targeted VoIP (Voice over IP) systems using an open source security suite called SIPVicious. This tool was originally designed to help administrators audit their internal VoIP systems and fix the detected security issues. However, like many other security tools, it’s also used by hackers to exploit VoIP systems over the Internet. Obviously, the test server at Rackspace did not have any VoIP services installed that could be exploited. This probe was just a type of automated bot that scanned the Internet looking for vulnerable phone systems. However, this technique must have been successful at some point for the authors to have created this automated bot. Obviously, there is a strong motivation for criminals to be able to anonymously use a corporate VoIP phone system. The lesson here: Use strong measures to protect VoIP systems that are exposed to the Internet.
The next most numerous probes tended to be looking for database systems to exploit: Microsoft SQL, Oracle and MySQL installations. Some of these were simple attempts to connect on the native service ports for these database systems --1433, 1521 and 3306. Others were actual attempts to perform denial-of-service attacks against the Rackspace host or bounce to other targeted hosts. Surprisingly, there were even instances of the old SQL Slammer worm trying to infect the Rackspace host, more than eight years after the malware’s creation. The lesson here: Limit Internet exposure of databases as much as possible to prevent these types of attacks.
Countries of origin
So where did all of these intrusions originate? To answer this, I analyzed the intrusions logs using both whois records and geographic IP mapping when available. IP addresses can be spoofed or attacks proxied through unknowing hosts in other areas, but, this information can still be useful in determining where the attack originated.
Surprisingly, South Korea was the top intruder with over 10,000 attacks originating from that country’s IP address blocks. The majority of these attacks were SSH brute force attempts. This type of attack would generate many intrusion events as it worked through possible user and password combinations. Russia came in second, but generated about 1,300 intrusion events (see Figure1). The emerging threats rule set used in this experiment also triggered alarms indicating many of these Russian IP addresses belong to the Russian Business Network. This group has allegedly been involved in many different criminal cyber activities, including spam, malware and bot networks. What was their interest in the test server hosted at Rackspace?
The U.S. came in third with nearly 1,000 intrusions originating from it.. The attacks came from all over the country, including Ohio, Illinois, Texas and Arizona. They could be simply coming from machines infected with malware, but it’s difficult to determine from the intrusion data. However, it’s clear the United States generates its fair share of cyberattacks.
The next country that showed up as a source of attacks was China. This country has been blamed for many cybersecurity incidents in the last several years including Titan Rain, which compromised many American companies and government agencies. These allegations have never been proven substantially, and China denies any involvement in cyber activities, including the rumors that it developed a cyber-army in the Guangdong province. However, the Rackspace server experienced more than 600 events originating from not just Chinese IP addresses, including some located in the Guangdong province.
The IaaS model offers incredible convenience over older hosted models, but information security threats still loom and can be easily overlooked. Companies using this model need to develop strong policies and procedures to configure and validate the provisioning of these virtual resources for IaaS security. If companies fail to secure these resources, the unforgiving nature of cyberspace will quickly detect and exploit any misconfigured system.
About the author:
Joseph Granneman, CISSP, has over 20 years in information technology and security with experience in both healthcare and financial services. He has been involved in the Health Information Security and Privacy Working Group for Illinois, the Certification Commission for Health Information Technology (CCHIT) Security Working Group, and is an active InfraGard member.