Securing Infrastructure-as-a-Service Public Clouds Using Security Onion

Abstract

The shift to Cloud computing has brought with it its specific security challenges concerning the loss of control, trust and multi-tenancy especially in Infrastructure-as-a-Service (IaaS) Cloud model. This article focuses on the design and development of an intrusion detection system (IDS) that can handle security challenges in IaaS Cloud model using an open source IDS. We have implemented a proof-of-concept prototype on the most deployed hypervisor—VMware ESXi—and performed various real-world cyber-attacks, such as port scanning and denial of service (DoS) attacks to validate the practicality and effectiveness of our proposed IDS architecture. Based on our experimental results we found that our Security Onion-based IDS can provide the required protection in a reasonable and effective manner.

1. Introduction

Cloud computing is a model for delivering on-demand computing services over the Internet [1]. It allows individuals and businesses to run applications on shared data centers instead of running them in private data centers. These shared data centers can be accessed by connecting to the Cloud network, making the application process starts quicker and more cost effective.

Although Cloud computing is providing numerous benefits, there are some barriers hindering its complete adoption by most organizations. The main concern of these organizations is the security and privacy of their data and information [2,3,4,5]. Cloud computing is a combination of various other technologies: Virtualization, service-oriented architecture (SOA), and Web 2.0 [6]. As well as the benefits of these underlying technologies, their security limitations are also inherited [7].

The framework of Cloud computing supports distributed service-oriented models, multi-domain and multi-user administrative infrastructure; as a result, it is very prone to various security threats and vulnerabilities. Because Cloud computing is based on a distributive architecture and is a relatively new computing paradigm, there is a reservation surrounding how security at all level (i.e., network, host, application and data levels) can be achieved [5,7]. This reservation has led company executives to remark that security of information is the biggest concern with Cloud computing [8].

A standard security mechanism to protect a Cloud computing environment is by the use of intrusion detection system (IDS). An IDS monitors enterprise computing and network environment and gives alerts on suspicious activities [9]. Traditionally, most IDS are host-based (HIDS) where IDS closely monitor specific host machines in a network. Another type of IDS is the network-based (NIDS) where IDS identifies an intrusion on main network nodes. While the use of an IDS does not guarantee and cannot be considered an absolute defense against intruders, it can play a major role in the security architecture of Cloud computing.

In this article, we propose and evaluate an approach to secure customer assets (data and information) in a Cloud computing environment by implementing an open-source IDS. In particular, we study how an IDS can be positioned in an Infrastructure as a Service (IaaS) public Cloud to monitor inter-virtual machine (inter-VM) operations. The IaaS public Cloud is the most widely used Cloud model deployment. In a public Cloud, the cloud service provider (CSP) provides different services and facilities to the general public via the Internet. In an IaaS public Cloud, the Cloud user is able to deploy and run any software and operating system (OS) in the Cloud. The user is also able to deploy IDS to add a layer of security to protect its data and information. Security and privacy in public IaaS model are especially a concern due to different users can have their virtual machines (VMs) reside on the same physical machine. We also design and implement a proof-of-concept of the proposed architecture. IaaS public Cloud technologies provide networking mechanisms that are used to configure virtual switches and experiment with new functionalities, such as traffic forwarding. Consequently, we want to assess how different virtual networking techniques can be employed in the context of securing the Cloud environment.

The remainder of the article is organized as follows. Section 2 provides background information on Cloud computing and Cloud security. Section 3 discusses the related work. In Section 4, we discuss the method implemented in securing Cloud computing with emphasis on IaaS public cloud. In Section 5, the results from our experiments are discussed and evaluated in line with real-world scenarios. In Section 6, we offer our depth analysis on the experiment results. Finally, a conclusion is highlighted in Section 7.

2. Background

2.1. Virtualization

The underlying technology of Cloud computing is virtualization [10]. The initial idea behind the creation of virtualization by IBM Corporation in the 1960s was to partition large mainframe computers into several logical instances and to run them on one physical mainframe hardware (host). In recent years, virtualization has attracted much attention in enterprise computing and is in fact now proven to be a fundamental building block in today’s computing. Advancements in hardware capabilities that provide very powerful multicore and high-performance computers, has brought about a potential of utilizing the hardware capabilities to the fullest. Virtualization has made it possible to run several VMs simultaneously on one physical server. Here, each VM runs in parallel to another VM. In addition, each VM has a full software stack, including an operating system (OS) that runs in parallel to other VMs, however each VM acts as a separated physical machine. Virtualization has become a core concept in modern data centers, mainly driven by the benefits of application isolation, resource sharing, fault-tolerance, portability and cost efficiency [11].

2.2. Cloud Computing

A Cloud computing architecture is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., servers, network, applications, and services) that can be readily provisioned and released with minimal management effort or interaction from service providers [12]. Cloud computing model follows a pay-per-use model where users only pay for the services they have used. Furthermore, the Cloud computing model implements virtualization techniques to provide resources to end-users efficiently. Hence, along with the dynamicity and flexibility provided by virtualization, Cloud computing is also characterized by its manageability, scalability, and availability.

According to the National Institute of Standards and Technology (NIST), Cloud computing has four deployment models: Public, private, hybrid and community [12]. Furthermore, typically there are three delivery models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS) (see Figure 1).

2.2.1. Cloud Service Delivery Models

Software as a Service (SaaS): Is a group of remote computing services accessed through the Internet. It allows applications/software to be deployed by third-party vendors.

Platform as a Service (PaaS): Is in the middle of the service models. IaaS delivers services by providing managed platforms, which provides development tools, architecture, framework, programs and Integrated Development Environment (IDE) for the Cloud users.

Infrastructure as a Service (IaaS): Deals with computer hardware (i.e., storage, network, processor, memory, virtual servers/machines, etc.) as a service and is at the bottom of the models. In an IaaS model, Cloud users take responsibility for managing their VMs by installing a preferred OS and other software. In an IaaS Cloud model, the Cloud user is responsible for the security and management of recourses, such as storage, network, processor, memory and VMs.

Anything as a Service (XaaS): This type of service delivery model refers to a collective term that combines numerous things as ‘X’ as a service, where X can be anything or everything as a service. This service then becomes interchangeable in Cloud architecture. Here the Cloud systems have the ability to support substantial resources into specific personal and smaller requirements.

2.2.2. Cloud Service Deployment Models

The deployment model of a Cloud tells the nature and function of a Cloud. The four types of deployment models defined by NIST are [12]:

• Private Cloud: This model has to do with the operations and management of the data center of an organization (i.e., private Cloud). The Cloud infrastructure is operated solely for an organization.
• Public Cloud: This type of Cloud deployment model gives a true representation of Cloud hosting in which they have a strong Service Level Agreement (SLA) between the CSP and the consumer. The CSP provides different services and facilities to the general public. Multiple entities, e.g., businesses, academics or governmental organizations can own and control a public Cloud environment. This creates problems relating to where resources are located or who owns them thereby increasing the difficulty of protecting them from attacks [13].
• Community Cloud: This model is a collaborative effort in which resources are shared between different organizations from a specific community with similar concerns (e.g., security, jurisdiction, compliance) irrespective of where they are managed (be it internally or by a third-party) or hosted (internally or externally).
• Hybrid Cloud: This type of Cloud deployment model is a combination of two or more Cloud models (i.e., public, private, and community). Typically, application and data are bound together by standard and proprietary technology. Hybrid Clouds offer the advantages of other Cloud deployment models. However, it is more organized and more secure than a public Cloud.

2.2.3. Cloud Computing: The Security Viewpoint

The advent of Cloud computing has brought with it many benefits for both Cloud users and providers. Majority of IT users today use one or more public Cloud services, such as e-mail and storage. Nonetheless, many organizations and businesses despite realizing the potential for profits made available by public Clouds are still hesitant to use Cloud services due to its security vulnerability [14]. Cloud computing platforms are more vulnerable to cyber-attacks than other computing platforms due to the diverse nature of its service delivery models. These vulnerabilities could be uncovered through any of the fundamental constituents of Cloud computing i.e., network, VM, application and storage. The next subsection classifies attacks based on the fundamental elements of a Cloud network and their effects.

2.2.4. Classification of Attacks

• Network Based Attacks: One entry point for attackers into a Cloud system can be through the network that leads to weakening the quality of Cloud services and further putting Cloud confidentiality and privacy at risks. The most common attacks on network infrastructure in the Cloud are port scanning, Botnets, man-in-the-middle (MITM) [15], distributed denial of service (DDoS) [16], and spoofing attacks.
• Virtual Machine Based Attack: Several security risks occur as a result of many VM instances being hosted on a single system. The major characteristic feature of VM based attacks is the violation of data and hampering of cloud services as a result of flaws in VMs being manipulated.
• Application Based Attack: Applications running on Cloud platforms are typically delivered through a web browser. However, flaws in these web applications make the Cloud vulnerable to attacks [17]. Examples of application-based attacks are injections of codes into applications that run on Cloud platforms and attacks on protocols that are implemented to provide services in the Cloud.
• Storage Based Attacks: The Cloud storage is a high-value target for attackers because data from various users and business organizations are kept together in a Cloud environment [18]. Hence, breaching into the Cloud storage will potentially give an attacker access to a large pool of sensitive information. Examples of storage-based attacks are data scavenging and data recovery attacks.

2.2.5. Effects of Attacks on Cloud Resources

Attacks on Cloud platforms may have one or more implications that further affect the delivery of Cloud services. This section discusses and analyses these implications.

• Account or Service Hijacking: This type of attack can happen as a result of different aspects for example, social engineering of weak passwords/credentials. When an attacker gains access to these credentials they can carry out a variety of malicious acts, such as gaining access to sensitive data, manipulation of data and even redirecting transactions [19].
• Malicious Manipulation of Customer Data: The communication between the Cloud and the users is usually via the Internet through web browsers. This attack is usually carried out through the manipulation of data that are sent from the application component to the servers. Examples of these attacks are cross-site scripting (XSS), SQL injection (SQLi), direct object references, etc.
• Denial of Service: A malicious user may target a Cloud platform by occupying all possible resources [16]. Thereby making the system unable to satisfy other genuine users due to resources being unavailable.
• Malicious VM Creation: Here an attacker who creates an authentic account can create a VM image containing malicious codes, such as worms, viruses and Trojan horses, and store it in the CSP’s repository [20].
• Insecure VM Migration: During the live migration of VMs logs of a VM’s execution state that is being upheld due to a rollback implementation. These logs can become accessible and this can give room for attackers to access data illegally, transfer a VM to an untrusted host and cause disruption or DoS as a result of creating and migrating several VMs at the same time [21,22].
• Sniffing/Spoofing of Virtual Networks: An attacker’s VM can listen to network or even use ARP spoofing to re-address packets to and from other VMs [23].

2.2.6. Automated Cloud Security Using Intrusion Detection/Prevention

The continuous evolvement of Cloud computing architecture means that traditional firewalls are unable to secure the Cloud effectively. In disparity to traditional firewalls which secures a network by probing network packets passing through network ports, IDS monitors and analyses the headers and payloads of network packets and compares them with normal/benign traffic to detect any vulnerability exploits against a target application or system. IDS primarily try to identify patterns in known attacks and alerts the security administrator. Equally, intrusion prevention systems (IPS) is similar to IDS, though it also has the capability to reject malicious traffic and to terminate a suspicious connection.

As we know that the backbone of Cloud computing is a high-speed network, therefore this calls for the use of an automated or faster IDS/IPS. IDSs have a variety of flavors and approaches used to detect suspicious traffic (see Figure 2). A network-based intrusion detection/prevention system (NIDS/NIPS) attempts to secure all devices on a network by analyzing network traffic for signs of malicious behaviors, while a host-based intrusion detection/prevention system (HIDS/HIPS) attempts to secure one particular host [9]. HIDS/HIPS is particularly used to secure valuable or private information on a specific server. As well as HIDS/HIPS and NIDS/NIPS, hypervisor-based IDS provide another type IDS used to ensure the security of data and information in the Cloud. This type of IDS/IPS runs inside the hypervisor, making it possible to monitor and analyze communication between VMs, hypervisors, and the virtual network.

Typically, IDS have two types of detection approaches: Anomaly detection and signature detection [24]. The anomaly detection approach maintains a pool of information regarding user profile, hosts, application and connection (ports, devices, and protocols) specified by a network administrator. Anomalies are detected by comparing current activity with the rules defined by the administrator. In disparity, the signature detection approach compares signatures of activities on the system against an array of malicious signatures or threat patterns.

3. Related Work

Cloud-based intrusion detection was made possible as a result of researchers combining established techniques of malware detection with the ability to isolate VMs. Nonetheless, the IDS still carry out its duty of identifying changing patterns in the behavior of a system that might have been compromised; for example Bakshi et al., [25], proposed an approach to prevent DDoS attack in a Cloud environment. The authors implemented Snort IDS installed in a VM on VMware ESX, which sniffs all traffic either inbound or outbound over the virtual network through a virtual switch. To detect attacks, logged packets are analyzed by Snort in real time. Although this approach showed that IDS can effectively function in a Cloud computing environment, the implementation is still vulnerable to zero-day attacks as non-virtualized IDS inability to detect new attacks.

The advent of hypervisors and hypervisor-based IDS has paved the way for firewalls to be relocated into the Cloud deployment. An alarming trend in recent malware attacks has proven that knowledgeable attackers have found stealthy techniques to elude and undermine traditional firewalls. To overcome this issue, Srivastava and Giffin [26] developed a tamper-resistant virtual firewall (VMwall) which leverages the benefits of both VM isolation and traditional firewalls. VMwall makes use of Xen hypervisor for isolation of the firewall and VM introspection to correlate UDP or TCP traffic with process information [27]. The Xen hypervisor provides functionality by adding hooks that capture all network operations. A whitelist (that approves processes and connection type) is used to determine if the connection is allowed or blocked. Although the VMwall was effective at identifying and blocking network connection with minimal impact on performance, the whitelist may be vulnerable to hijack by an already established connection.

Another approach in securing the Cloud is by using prevention techniques. Jiang et al. [28] proposed an intrusion prevention system by implementing VMwatcher which methodically reconstructs the data structures (i.e., files, directories, processes and kernel modules) of a VM for analysis at the hypervisor level in an unobtrusive manner. Casting these data structures and function schematics on the hypervisor-level VM so that the VM’s schematic view can be reconstructed outside, makes the reconstruction possible. Monitoring tools, such as Windows Task Manager and memory dump, can be used to display all processes in memory so as to check for differences between guest’s states. Differences between the two states may indicate the presence of malware in the guest VM. Further improvement to the VMwatcher implementation is to use anti-virus software to scan the state of guest VMs from inside the hypervisor. The major shortcoming of this implementation is the assumption that the hypervisor has not been compromised already.

Our review indicates that each of the core components of Cloud computing (network, storage, application, VM) has its potential threats. However, little effort has been made to study security at service delivery (IaaS, PaaS, SaaS) levels of Cloud computing. Although existing studies, such as References [29,30,31], primarily investigate the potential of implementing IDS in a Cloud environment; these studies also discuss the various threats contained in each service delivery model. Evaluation of IDS based on service delivery models is important as it provides detailed information about how each service delivery model can be secured. Furthermore, we believe that one of the main challenges faced by security administrators is to identify attacks that are embedded inside normal VM operations in Cloud environments.

CSP uses VM technologies and hypervisors, such as VMware, ESXi, Xen, Microsoft virtual PC, etc., to deliver a multi-tenant Cloud environment, which may have in them potential vulnerabilities that are prone to cyber-attacks [32]. In addition, conventional techniques for protecting user data through the use of anti-viruses, firewall and endpoint encryption are becoming extinct due to the multi-threaded nature of Cloud computing architectures [33]. Hence, the target for attackers has shifted from the network layer to the application layer due to Cloud services are being delivered through the web browser. Therefore, in the remainder of this article, we explore these gaps by proposing a model that incorporates intrusion detection practices into an IaaS model public Cloud platform.

4. Methodologies

Our hypothesis is that it is possible to deploy an IDS sensor in a Cloud environment in such a way that it can detect attacks that are embedded inside normal VM operation. Furthermore, one open question is how to select a technology that makes it possible to implement and manage IDS in Cloud environments. This technology should be adaptable enough for experimentation and have adequate performance to support current Cloud topologies.

4.1. Experimental Setup

The experimental environment is a highly flexible, centralized virtual lab infrastructure, which consists of an ESXi server hosting three VMs: Security Onion (SO) [34], Kali Linux [35] and Metasploitable [36] (see Figure 3). In this setup, SO runs the IDS instance, Kali hosts the attacker and Metasploitable is the victim/target machine. ESXi 6.0 is used which is a robust, high-performance hypervisor that virtualizes hardware resources and makes them shareable by several VMs inside VMware Workstation 12 on Intel (R) Core (TM) i7, 16GB RAM and 734GB hard disk space.

To implement the IDS, SO is configured for network monitoring, intrusion detection and log management in one of our three VMs. The major factor that influenced the decision to use SO is that it comes with pre-installed security tools, such as Snort, Bro, Suricata, OSSEC, Sguil, etc., which makes network monitoring a less difficult task for security administrators. SO can be used in two ways, either proactive: When it is used to identify vulnerabilities or expiring SSL certificates, or reactive: When used for network forensics or incident response. Although SO provides visibility into a network and context around the anomalous event, it still requires commitment from a security administrator to monitor network activity, review alerts and incline to learn new things. There are other commercial solutions which offer similar tools as SO, but only a selected few contain the vast capabilities of SO in one package.

SO offers the choice of Snort or Suricata for rule-driven intrusion detection. In this work, Snort [37] is considered as it is a de-facto standard IDS with millions of downloads and is the most extensively deployed IDS technique worldwide. Snort IDS scans network traffic for identifiers or fingerprints that matched known malicious or suspicious traffic.

With full-packet capture and Snort logs, there is an overwhelming amount of data to be analyzed. Fortunately, SO integrates analysis tools, such as Sguil, Squert and ELSA. In this experiment, we use the Sguil console for data analysis. Sguil [38] provides visibility into the data that is being collected and the justification to validate the alert.

To test the effectiveness of our IDS, Metasploitable is installed in one VM to serve as a victim machine. Then attacks are simulated from Kali Linux to mimic real world scenario.

4.2. Network Configuration

For this experiment, all three VMs are interconnected via a virtual switch (vSwitch). The vSwitch is configured with two port groups: The VM port group, and the Promiscuous port group. The VM port group has its promiscuous mode set to “Reject” by default while the Promiscuous port group has its promiscuous mode set to “Accept.”

4.3. Security Onion Configuration

We setup our SO as a standalone system with both server and sensor in the same location. We use production mode setup as we would like to have greater control over what we what to install. Also, we use Snort IDS engine and Emerging Threats GPL (no oinkcode required) ruleset. Oinkcode is a unique key connected with the user account given by Snort and it allows one to have more access to the latest rules and updates. Snort is an open source libpcap-based network intrusion detection and prevention system performing packet sniffing and logging and traffic analysis on IP networks. The current version of Snort employs different types of techniques, such as signature, protocol and anomaly-based inspection to detect and prevent cyber-attacks.

Security Onion has pf_ring built into it, which allows one to spin multiple Snort instances to handle a greater amount of traffic. However, this is limited by the number of CPU cores the VM has. In our case, the VM has two CPU cores, so we used the maximum amount of IDS engine processes that are allowed (i.e., 2). This means we can spin up to two instances of Snort.

There are three critical areas in the configuration and use of SO: The management of the configuration, rules file, and logs. Important file locations from which many of the tools contained in SO can be configured from are “/opt/bro” and “/etc/nsm” files. SO is only as effective as the rules that are implemented for it to use. These rules can be found in “/etc/nsm/rules” file. Important files in this location include: “local.rules”, “downloaded.rules”, “whitelist.rules” and “blacklist.rules” files. Also Log files of network activities, such as DHCP, DNS, SNMP, SSL and various other connection types, can be located at “/nsm/bro/current” for analysis through Sguil. For our system, we configured two NICs, NIC 1 (eth0) connected to the “VM network” and NIC 2 (eth1) for the management of the IDS.

5. Results and Discussion

This section discusses the process of penetration testing and analysis of data captured during penetration testing through the Sguil console. This testing involves all applications and services on the target system. First, we use the fping tool to determine the accessibility of the target. Next, we determine open and active services on the system by using open source Nmap [39] and traceroute tools. We further carry out a vulnerability scan on the victim system using Nessus vulnerability scanner [40]. Finally, we exploit the system using a Metasploit console.

Simultaneously, we carry out security monitoring and reporting on the platform using the Sguil console. Security onion has two software options: Sguil and Squert already preinstalled for this purpose. Classification of logged events in Sguil makes it easier for security analysts to easily review triggered alerts. For example, all forms of port scan or ping sweep are classified as Category 6. All category 6 alerts can be removed from the console hence allowing a security analyst to focus on other more dangerous alerts. However, in this experiment, all kinds of alerts are important to us. This gives us a proper view of what is monitored by our IDS.

5.1. Discovery Phase

5.1.1. Intelligence Gathering and Analysis

Foot Printing: Our first assumption is that the malicious user does not know the IP address of the victim system. We employ fping tool to find out the host that are alive on the network.

Scanning: The foot printing stage discussed earlier aids a malicious user to discover the IP address of the victim. Furthermore, the malicious user can use tools, such as traceroute and ping to collect more information about the victim system. The output is given by the ping and traceroute command shows that the victim system is alive and accessible with a maximum of 30 hops. This, therefore, confirms that the victim system is active and can be reached within a range of possible distance.

After confirming that the victim system is alive, the different applications/services running on the victim system can be identified by the attacker using Nmap command. The result from Nmap scan reveals ports that are open, their service version, and the protocols types which are currently running.

During the information gathering stage, our IDS has real-time access to events, session data and packet data captured on the network, and uses the Sguil interface to analyze these events. Figure 4 shows the output of the Sguil console during the information gathering phase.

Data from the Figure 4 above indicates that a variety of scans and probes are being initiated on the target IP 192.168.182.130 from the source IP 192.168.182.129. The event message column gives a security analyst a brief description of the action that triggered the alert. The first line on the console (first logged event) indicates that a ping request is being sent across the network. These tallies with the first process of information gathering we carried out. Further going down the list of logged events, we noticed that each line on the console corresponds with all of the probes and scans made during the information gathering stage. The Sguil console also shows the network interface being monitored, the source and destination ports and ID of the alert for further analysis.

Enumerating: In the enumeration stage, we make use of open port services and active connections to detect services that are not adequately implemented. This stage helps an attacker to create a blueprint of the target network, hence determining potential weaknesses. The domain name, MAC address and host name of the destination NetBIOS of the victim system are then revealed by means of nbtscan command.

Additional enumeration is performed using the Metasploit framework. We found the version of Samba of the victim machine. We also enumerated HTTP port 80 using the Nmap.

During the enumeration phase, our IDS continues monitoring the network and alerts for strange events to the Sguil console for further analysis by a security administrator. Figure 5 below shows the output of the Sguil console during the enumeration phase.

The output of the enumeration phase showed in Figure 5 indicates in the first line of the probe on the system with the destination IP 192.168.182.130 and destination port 445 from source IP 192.168.182.129 and source port 37,469 to detect the version of Samba that is being run by the target system. Also, the output of the console indicates several probes being carried out on the HTTP port 80 of the target system; this alert corresponds to the HTTP enumeration we carried out.

5.1.2. Vulnerability Detection

After gathering useful information about the victim system and the network, the next stage in our penetration testing is to scan the victim system for vulnerabilities that can be exploited. To scan for available vulnerabilities in our victim, we configured Nessus vulnerability scanner against the victim machine. A detailed result of this vulnerability scan is shown in Figure 6 following their level of severity.

The result of the Nessus scan (see Figure 6) is strictly based on services, which are open and active, it also includes an OS and applications discovered in earlier phases. The total number of vulnerabilities found was 112, but we only focused on two vulnerabilities (rouge shell backdoor and VSFTPD smiley face backdoor) which both have a critical level of severity. Compared to other vulnerabilities that are at a critical severity level, the chance of exploiting Samba and VSFTPD is at a reasonable level due to the fact that some preconditions need to be met before the exploit can take place [41].

While running the vulnerability scan, our IDS was also monitoring the network and events were logged into the Sguil console. Figure 7 represents the output of the Sguil console while the Nessus vulnerability scanner was running.

During the Nessus vulnerability scan, many alerts were reported on the Sguil console, and this involves different types of port scans to detect open ports and various kinds of attacks simulated by the vulnerability scanner to detect if the target system is porous. From the console, it can be observed that although the destination IP (192.168.182.130) and source IP (192.168.182.129) remained constant, the origin and destination ports were varying. Also visible from the console is the name of the vulnerability scanner being used, i.e., Nessus User Agent.

5.2. Attack Phase (Penetration Attempt)

After determining the vulnerabilities that exist in the system in the previous phases. Next, we attempt to exploit these vulnerabilities.

5.2.1. VSFTPD Smiley Face Backdoor Attack

OSs, such as Ubuntu, CentOS and Fedora, contain VSFTPD ftp server. Over the years, this service has been quite secure, but a key incident happened in July 2011 when the original version of this service was replaced with a version containing malicious codes and a backdoor. This vulnerability is existent in version 2.3.4 of VSFTPD. The VSFTPD vulnerability allows attackers to gain access to the shell of affected systems by listening on port 6200 and logging in with Username: “:)” and any password of choice. We carried out this attack by using the Netcat command to find the version of VSFTD, and we found it was version 2.3.4 which contains a backdoor. We then proceed to use username “letmein :)” and password “hi”. While the first terminal was still running, we opened a second terminal and then used Netcat command to gain access to shell and root using port 6200 unlike 21 employed in the first.

During this attack, our IDS was in position and was monitoring all the events traversing the network. Figure 8 illustrates a screenshot of the alert received on the Sguil interface during the attack.

The Sguil console in Figure 8 shows that a VSFTPD backdoor attack was launched from IP address 192.168.182.129 to 192.168.182.130. The red banner in the first column indicates that alert needs immediate attention from the security administrator.

5.2.2. Samba MS-RPC Remote Shell Command Execution Attack

Versions 3.0.0 to 3.0.25rc3 of Samba contains a vulnerability that allows intruders to perform shell commands due to the failure of the software to verify and sanitize user inputs. Malicious users can exploit this vulnerability by running arbitrary shell commands through the vulnerable Samba application on the target machine.

In the previous stage of enumeration, we found out the version of samba to be 3.0.20; this means the Samba has a vulnerability. In Metasploit framework, we used “exploit/multi/samba/usermap_script” module to exploit command execution susceptibility in Samba when utilizing non-default “username map script”.

Our IDS running in the background alerted us on some suspicious activities happening on the network. Figure 9 demonstrates the alerts displayed on the Sguil console during this attack. As seen on the Sguil interface in Figure 9, our IDS successfully alerts the security administrator of an attempt from source IP 192.168.182.129 to exploit the Samba application of the target machine 192.168.182.130.

5.2.3. VSFTPD Smiley Face Backdoor Attack

In this section, we make use of Hping3 tool in Kali Linux to mimic a basic DDoS attack on our Metasploitable VM. Although this DDoS attack simulation is very limited regarding attack traffic used and scale, it gives us a taste of how efficient our IDS can detect real-life Internet scale attacks.

Before we started launching the DDoS attacks, we added several rules into our Snort IDS engine to make sure it able to detect malicious traffic and generate appropriate alerts. Figure 10 shows an example of one of the rules added to the local.rules file.

This means that the rule will alert if any TCP flooding is targeted at the destination network 192.168.32.0/24 and destination port “80” from “any” source network and “any” source port.

The Hping3 tool in Kali Linux was used to simulate an SYN flood attack. This attack involves hitting our victim (Metasploitable VM) with a large number of SYN packets and seeing how it affects usage of the VM.

While the simulated attack running, our Sguil interface is active and alerts us of a possible DDoS attack (see Figure 11). Figure 11 shows an alert that was triggered on the Sguil console. We have highlighted the alert produced and the rule that triggered the alert. It shows a possible TCP DoS attack was launched from IP address 192.168.32.130 (IP address of our Kali Linux VM) to the destination IP address 192.168.32.129 and port 80.

6. Discussion

The findings from our experiments suggest that IDS can be implemented in a Cloud-computing environment in such a way that it can detect attacks embedded inside inter-VM activities. As observed from the experiment performed on our IDS, it is realized that our proposed architecture is capable of detecting attacks aimed at a victim system. These attacks include port scanning, DoS, spoofing, malware injection and so on. Our proposed model also gives information about where an attack originates from the source port and IP address and the target of the attack i.e., destination port and IP address.

The findings made during penetration testing reveals that the vulnerabilities present in our victim system were either because of the nonexistence of system hardening, lost patches or guessable login credentials. Therefore, we recommend that OS of VMs in Cloud networks should be keept updated to their latest version which contains reinforcements to remedy the vulnerabilities we discovered. Furthermore, more rigid ones that cannot be predicted easily should replace weak login IDs.

We found that the detection capability of Snort is dependent on the number of rules enabled. This means that the more attacks will be detected if more rules are implemented. However, the downside of having a large number of rules is that there will be an equivalent increase in the number of false positive alerts as a result of rules that are intended to detect more complex attacks being triggered. We also noticed that a lot of unwanted alerts were generated. Nonetheless, these unwanted alerts could be reduced by fine-tuning and careful selection of rules. Snort rulesets are updated regularly, thereby enabling them to detect most of the current attacks.

7. Conclusions

The increase in the number of Cloud users has also brought about an increase in the number of malicious users targeting the resources available in the Cloud. Securing Cloud computing architectures from malicious users can be very complicated because it is delivered via public networks, such as the Internet. In traditional computing architectures, different types of intrusion detection techniques are used to counter malicious attacks. Although these techniques can also be implemented in the Cloud computing environment, they cannot efficiently secure Cloud infrastructures. Security of Cloud resources serves as a major bottleneck in the full adoption of Cloud computing in organizations today.

We proposed a Cloud-based IDS to help secure Cloud resources particularly in IaaS public Cloud models from cyber-attacks that are embedded inside normal VM activities. In this experiment, we have built a proof-of-concept using Security Onion and observed that well-design open-source software, such as Security Onion IDS, can effectively detect different types of cyber-attacks targeted at our victim VM (Metasploitable) in real time.

Our hypothesis is that it is possible to deploy an IDS sensor in a Cloud environment in such a way that it can detect cyber-attacks that are embedded inside normal VM operation. We have designed an architecture that follows this idea, and observed that state-of-the-art has evolved in this direction with commercial solutions from Suricata based CounterSnipe [41] and Snort IDS for Amazon EC2. Snort IDS for Amazon EC2 can be installed with support for Sourcefire’s commercial vulnerability research team (VRT) rule set, which allows EC2 users to secure their Cloud with commercial support from Sourcefire. The findings from our experiments suggest that IDS can be implemented in a Cloud-computing environment in such a way that it can detect attacks embedded inside inter-VM activities.

We believe that implementing IDS inside Cloud computing architectures can have a positive effect on information technology by ensuring integrity and confidentiality of Cloud resources, and in our humble opinion, we believe that our proposed architecture is a step in that direction. We plan to enhance our work by implementing a machine learning-based IDS to decrease human intervention and reduce false alarms.