FAPA: A Model to Prevent Flooding Attacks in Clouds
Kazi Zunnurhain and Susan V. Vrbsky
Department of Computer Science The University of Alabama Tuscaloosa, AL 35487-0290
[email protected], [email protected]
Abstract- Several schemes and a variety of intrusion detection systems are available in the market for DoS or flooding attacks. In this paper, we propose a model for the prevention of DoS attacks for clouds called FAPA (Flooding Attack Prevention Architecture). Based on the characteristics of attacks, our FAPA model uses a Learning Phase, Validation checking and Compatibility checking through its hypervisor to prevent flooding attacks. The central idea is to extract an extensive set of traffic behavior, which will describe the usual traffic flow for each session initiated by legitimate customers. Compatibility checking of the traffic from different customer sessions and associative rules will be used to find abnormalities. From those abnormalities, the system will automatically be aware of any phenomenon and precautions can be taken. Lastly, we show how our FAPA model can prevent different types of flooding attacks. Our goal is to design a model that allows a dynamic response that can adapt to prevent any type of flooding attack.
Keywords- Cloud security, DoS, Flooding attack, Hypervisor, Learning module
I. INTRODUCTION
In the field of computation, there have been many approaches for enhancing the parallelism and distribution of resources for the advancement and acceleration of data utilization. Data clusters, distributed database management systems, data grids, and many more mechanisms have been introduced. Now cloud computing is emerging as the mechanism for high level computation, as well as serving as a storage system for resources. Clouds allow users to pay for whatever resources they use, allowing users to increase or decrease the amount of resources requested as needed. Cloud servers can be used to motivate the initiation of a business and ease its financial burden in terms of Capital Expenditure and Operational Expenditure.
There are three general layers that can be used to describe the services provided by a cloud system as shown in Figure 1: IaaS (Infrastructure as a Service), PaaS (Platform as a Service) and SaaS (Software as a Service). The infrastructure layer consists of all the hardware modules of the cloud.
The platform layer contains the running applications on which the customers will obtain their virtual machines for desired computation. The software layer provides the actual computations requested by the customers. Cloud computing has been envisioned as the next generation architecture of IT Enterprise. It offers great potential to improve productivity and reduce costs. In contrast to traditional solutions, where the IT services are under proper physical, logical and personnel controls, cloud computing moves the application software and databases to large data centers. Unfortunately, the management of the data and services may not be fully trustworthy in a cloud, which poses many new security challenges which have not been well understood yet.
Software-as-a-Service (SaaS)
Infrastructure-as-a-Service (IaaS) Platform-as-a-Service (PaaS)
Figure 1: Principle Layers of a Cloud Security is a vital issue for a distributed system where huge data processing and storage issues are a very common phenomenon. These kinds of systems are vulnerable to Denial of Service (DoS) attacks, also called flooding attacks. Because of their highly distributed nature, clouds and grids are very prone to Distributed Denial of Service (DDoS) attacks, occurs when a targeted system is attacked by multiple systems which themselves may have been compromised.
There are many different types of flooding attacks, but in general they all involve a victim receiving, processing and/or sending a large quantity of packets in response to the initial packets sent by an attacker. Dealing with this large number of packets depletes the victim’s resources, causing legitimate requests to starve.
To address the threat of flooding attacks in clouds, our previous work in [6] we presented several possible ideas, one of which included the use of a hypervisor. In this paper, we present a model for preventing flooding attacks of clouds and provide specifics concerning the functionality of the hypervisor.
The remainder of this paper is organized as follows. Section II focuses on work related to DoS prevention and Section III describes different types of flooding attacks. Our FAPA (Flooding Attack Prevention Architecture) model and the role of each module in FAPA in preventing flooding attacks and blocking unauthorized access are presented in Section IV. Section V shows how the FAPA model prevents different types of attacks. Lastly, we draw conclusions in Section VI.
II. RELATED WORK
The four steps considered when responding to DoS attacks can be categorized into four types: Prevention, Detection, Response and Tolerance, and Mitigation [1]. Prevention of DoS attacks can take place by two types of filtering, either Ingress or Egress filtering. If a packet does not contain the IP address of the customer domain as the source address, then it could be filtered out in the outermost router of the customer domain, known as Egress filtering [7]. If packet dropping is possible inside the ISP domain, then it is known as Ingress filtering [12]. Thus, an inside attack could be prevented with Ingress filtering. However, now most research focuses on detecting and responding according to the attack, instead of blindly dropping the compromised packets.
Detection experts have developed many IDS (intrusion detection) systems [8], [9], [10], [11]. For these IDS systems, a system is built based on current scenarios of attack patterns and a developer’s past experience and prediction knowledge [8],[9]. IDS might be rigid enough for any kind of attack along the network layers or transport layers, but if the attacker camouflages the IP packet and tries to intrude in the application layer, then few precautions can be taken. Also, some intrusion detection systems are modifiable and adaptable, but the extent to which these are limited. Sometimes the original code even has to be altered when the intrusion detection cannot perform well enough, which makes it difficult to keep up with network performance. This could be a problem in a cloud system.
In [2] Gil and Poletto proposed a scheme called MULTOPS to detect denial of service type attacks by
measuring the ratio between the uplink and downlink packets. MULTOPS assumes that packet rates between two hosts are proportional during normal operation. If there is a significant disproportion between the packets going back and forth from a host or subnet, then it is a strong indication of a DoS attack. In clouds this IDS is not sufficient, because a cloud can be used as a computational device for a large and complicated program. Different modules of the program pass messages while functions call each other with the help of a SOAP message. This causes the ratio of packets to greatly increase and can even exceed the threshold of normal operations for that specific customer.
Lee and Stolflo [3] used data mining techniques to describe the patterns of system features and user behaviors in order to detect anomalies and intrusions. Rather than running a pattern matching algorithm along the command, they applied various types of algorithms, such as Link analysis, sequence analysis and classification type algorithms. The design is to make their IDS more general so that any kind of data can be fed into their system and statistical results can detect anomalies using association rules. All their data analysis takes place offline and their system does not filter until an anomaly is completely detected and an alarm has been generated. The flaw of this approach is that no effort is made to categorize the types of attacks. In a cloud system it is important to identify the types of malicious attacks to provide a dynamic solution on the fly to customers and to satisfy a proper SLA (service level agreement). In [4], traffic which belongs to a DoS attack was detected by considering the high volume of traffic and then the correct drop probability was calculated to prevent the system from a flooding attack. In a cloud a more dynamic approach is required to accommodate any hardware malfunctions or increases in legitimate resource requests. Dropping legitimate requests can result in a loss of revenue and customer satisfaction.
Hybrid detection approaches [5] are also famous for their low false positives and high detection rate. Hybrid systems combine all the positive features of anomaly based and signature based detection models, such as the generation of association rules, and using data mining to construct features of the system and nature of the traffic. These types of systems are expensive and highly complicated during their implementation and not optimal in terms of cost for clouds.
Mitigation is an important aspect of clouds. An unusual phenomenon that occurs in a cloud and results in an increased cost must be investigated. For example, a usually long processing time for a general application that is not similar to the previous log history may cause increased charges, or the current account usage balance may dramatically increase suddenly for no apparent reason. A customer may charged for an application for which he is not the owner or a cloud user may be charged for using the cloud even though (s)he was not using the cloud at that specific time. An investigation should take place conducted by a neutral third party before charging the customer [13]. This third party investigation will proceed based on the log information and log records containing certain features in the provider’s end [6]. If these features are ensured during the logging, then the actual cause of the interruption can be detected by the third party. However, such an investigation might take too much time. Instead, it is important to inform the third party on the fly, as soon as the alarm has been generated within the system.
III. Types of Flooding Attacks
There are various kinds of flooding attacks, including: ICMP flooding, UDP flooding, TCP SYN and indirect attacks. It is difficult for hackers to understand the infrastructure of a private cloud, so inside attackers are generally the first suspects for any kind of attacks in a private cloud. On the other hand, in a public cloud the flexible infrastructure of public clouds make them easy to penetrate and more vulnerable to outside attackers. We now describe different types of attacks and in Section V we will show how our proposed FAPA model can avert these types of attacks.
ICMP Flooding: One example of ICMP (internet control message protocol) flooding is a Smurf attack in which ping requests with a spoof source address are sent as a broadcast message. Many hosts then respond to the ping with an echo to the spoofed source address, which is the victim of the attack. For this type of attack in a cloud, the attacker is masked as an insider, because the spoof IP address can be a registered user of the cloud.
UDP Flooding/Spoof: A UDP (user datagram protocol) flooding attack can be initiated by sending a large quantity of packets, using UDP or TCP, to random ports on a remote host. In response to a packet received from a port, a distant host will check for an application listening at that port. Since no applications are listening at the random ports, the host will respond to the large quantity of packets by sending many ICMP Destination Unreachable
packets, eventually resulting in it being unreachable by other clients.
In a UDP spoof, an attacker sends a UDP packet to a random port of the victim’s system with a spoof source IP address. The attacker then continues to send additional packets. Eventually, the system tries to verify the spoofed IP address with its ACL (Access Control List) or legitimate user addresses, and finds nothing about the mentioned address. At this point, the attack has already committed its intentional task of occupying the resources of the system. Following this step, multiple packets are sent and the attacker is successful in occupying the total resources of the server.
Both ICMP flooding and UDP flooding can occur in clouds. A camouflaged attack unknowingly propagated from a cloud may compromise a legitimate user. Traditional solutions to prevent this type of attack require the use of additional hardware, a firewall or new devices. Requiring this additional hardware of a customer is not an acceptable solution in a cloud system.
Most of the communications in a cloud or grid take place in the transport layer of the network. In TCP/IP there are fewer layers with less overhead, smaller packets, and fewer redundant bits than the OSI model. With fewer bits, utilizing checksum becomes more complex. As a result, the TCP layers are more vulnerable to attacks and most of the intrusions consider these layers as a medium of transporting their illegal intension to reach the main unit. In a cloud computing environment, the main unit would include the cloud servers. Such an attack on a cloud system could be catastrophic.
TCP SYN flooding: A TCP SYN attack exploits the fact that total communication takes place through a three-way handshake protocol. A requester sends a SYN (synchronization) packet to the server, the server checks the packets and sends a SYN-ACK back to the requester and finally the requester sends an ACK back to the server to complete the communication path for transmitting further traffic. However, the attacker can send a very large number of SYN packets to the system and engage the system with a bulk amount of SYN-ACK packets, which engages the resources for a long time. These types of attacks are sometimes traceable if the attacker uses his own IP address and that IP address can then be blocked. This type of attack is known as a direct attack.
Indirect Attack: We must also consider what happens if the attacker uses some other handlers (zombies) to compel the attack. For example, the attacker machine
(master) can command the handlers to send SYN packets to the victim machine with spoofed IP addresses. In this case, tracing the spoofed addresses of the handlers exhausts the system. Even if the system finds the handlers, it could be difficult for the administrators to find the actual attacker(s). While this scenario can occur in cloud systems, allowing the attack to continue in order to try to trace it back is not a feasible solution. The time taken to trace back the attacker could negatively affect the response time for the customer and the elastic nature of the cloud could allow a tremendous increase in packets.
Proxy servers can be deployed to filter packets with spoofed source IP addresses (indirectly for DoS), but all proxy servers have limitations. Usually the proxy servers are built for medium-sized industries and are capable of handling 15,000 requests/second for a total of 250,000 requests. This kind of system has to be adaptable and scalable to a large extent so that even the growth of requests in the system will not let the attackers penetrate the system. Since one of the characteristics of cloud computing is its scalability, deploying a proxy server may not provide the scalability needed by the cloud.
IV. FAPA MODEL
Though there has been much work on preventing DoS attacks, there is still no complete model for preventing DoS attacks in clouds. We introduce a model in this paper which is named FAPA (Flooding Attack Prevention Architecture), which contains different components that collaborate to prevent unauthorized intrusion or any kind of flooding attack. All these different components have different functions which we will describe in this section. The hypervisor is the composition of all these components. The role of the hypervisor is to learn the nature of the traffic packets, check its validity and schedule the tasks requested by the packets.
In our cloud system, the hypervisor is the core engine responsible for most of the message passing between different servers. While there may be some concern about centralizing multiple tasks around the hypervisor, the alternative is to distribute these tasks in the software layer, which may increase the likelihood of attacks. Instead, we propose to move higher level functionality to a lower level in order to increase security. In the next section we briefly describe the functions of our hypervisor.
A. Hypervisor
A hypervisor or virtual machine manager is an important component of a cloud system. A
hypervisor allows multiple operating systems to run concurrently on a cloud. A hypervisor exists at the lowest level of the hardware. Since the hypervisor will be the kernel of the cloud system, it will be difficult for adversaries to intrude into the hypervisor [6], [14]. As attackers typically try to penetrate the system through the software layers, placing the hypervisor in the infrastructure layer provides additional protection. Currently, the only task a hypervisor performs in a typical cloud is the scheduling of resources, such as CPU, memory, disk I/O, etc., based on the requests from the customers. Our intension is to assign some additional tasks to the hypervisor in order to build a less vulnerable cloud system. We now identify cloud characteristics to determine the responsibilities of the hypervisor and to justify why the hypervisor should be the responsible component.
First, the traffic pattern in a cloud is not unique for all of its users. In other words, clients might have different patterns of usage or different times of day when they access the cloud. Therefore, there should be a module that has the self-learning capability to recognize a valid traffic pattern in order to authenticate all the users. Second, resource allocation should be flexible for each user during a given time span. For example, a user may need more CPU time or RAM during the day, while the same user needs less CPU or RAM at night time. In this regard the system also has to be scalable and dynamic for a cloud; in other words, balancing resources on the fly. Lastly and importantly, scheduling should utilize a separate module which establishes the initial connection between a user and the cloud system through an intermediary system. This is needed because direct communication could be misused due to the lack of knowledge of a new user or a simple mistake. We believe only the hypervisor should undertake all these three responsibilities: 1) learning behavior; 2) task of balancing resources to make the cloud more scalable and dynamic and 3) scheduling the resources based on the customer’s requests by acting as an intermediary system. Satisfying these responsibilities would pose less of a security threat on a cloud system.
The first characteristic the hypervisor possess is a learning capability. There should be information about an application running in the system and the number of requests on a daily basis from a legitimate customer for that specific time period of the day. So for the same customer, if there is any discrepancy in the regular service pattern or if bulk amounts of requests start to arrive for the system to process, a third party can be engaged. The third party will
conduct an investigation for this unusual phenomenon by comparing the log from previous records.
Second, the hypervisor should be scalable and highly dynamic. The hypervisor will not only count the number of SYN packets (requests) coming from the requester but also compare the rate of requests to the established TCP connections. It will facilitate the system’s ability to detect attacks accurately on busy servers without false positives. This will also reduce the overhead of network administrators who spend time tuning the system to the network traffic.
Third, whenever a TCP connection request is placed, the hypervisor will commit the scheduling and also perform the handshaking. Similar to the scheduler in an operating system, which resides in the kernel of the OS, our hypervisor schedules tasks based on the register values collected from a strategy similar to that used by a File Allocation Table. The handshaking process of the hypervisor will proceed as follows. A request comes from the requester and the hypervisor will send a REQ-ACK to the requester and check if the source address is authenticated or not. If the source address is legitimate then it will send a CONN-REQ packet to the actual servers, which is based on a request for memory allocation, processing units or any file management servers from the cloud. If the system sends an ACK to the hypervisor, then upon receiving the ACK the hypervisor will send the requester a CONN-ACK and the direct connection between the requester and the server will be established through the hypervisor. In this way, if any attacker proceeds with a TCP SYN spoof IP address, then the spoof SYN-ACK will be handled by the hypervisor rather than directly engaging the resources of the cloud system. All these messages are accomplished by the hypervisor who is the sole coordinator of message passing between file servers and memory servers or a core processor. Much about this topology was discussed in our previous paper [6] where we depicted the major issues related to cloud security.
B. Learning Ability
Adapting the learning ability in the hypervisor requires extraction of various features from the incoming traffic in the system. The rate of traffic, volume, flow, etc. should be recorded and checked by the hypervisor to detect any kind of anomaly. Comparison with the normal traffic flow or user profile statistics in the cloud will detect any kind of intrusion. Suppose, Tin(t) is the total traffic inflow in the system at time t, Tpr(t) is the previous record
traffic for that specific request usually flowing through the system at t, and Tth is the threshold traffic which will be determined based on the nature of traffic volume fluctuation for that specific t. An intrusion alert will be generated based on the overflow traffic volume, denoted as Tov(t).
Calculate, Tov(t) = Tin(t) - Tpr(t)
if Tov(t) < 0, then no traffic problems detected else if Tov(t) > 0;
then if Tov(t) > Tth , {intruder alert in the system} else “no action”
The intruder alert will propagate through the hypervisor by message passing. Every message is propagated by each module sequentially. Before raising the intrusion flag, the hypervisor will deploy a third party who is provided with the log table in order to investigate the issue within a specific (short) time frame. During a short span of time, no request will be processed from the requester and it will be queued. An unusual event may not be a flooding attack. For example, there could be a malfunction at the customer’s end or a customer might have forgotten to stop his VM by mistake and kept it running for an unusually long period of time. After analyzing all these possibilities, if the third party determines there truly an attack, then based on the confirmation from the third party, a flag will be set indicating the intrusion. The hypervisor will pass the messages to its nearest servers notifying them of the intrusion and the servers themselves will be able to transfer this intrusion alert among their neighboring servers. An important issue is how to make the system more scalable and dynamic during this kind of situation. We cannot assume that the intrusion detection method will completely check any kind of anomalies, because the adversary can inject a Trojan horse or logic bomb. A Trojan horse is a useful, or apparently useful, program or command procedure containing hidden code which will perform some unwanted or harmful functions when invoked. In a logic bomb, embedded code in some legitimate program is set to explode when certain conditions are met. For example, a logic bomb may be inside a regular message which does appears similar to the usual traffic pattern. After some time and based on some event, that logic bomb will be triggered inside one of the servers. Hence, to handle such kind of phenomenon, the system has to be highly scalable and dynamic.
Figure 2: FAPA model
C. Model Specifics
Figure 2 illustrate the components and process flow of the FAPA model. First, as specified by the process flow, the incoming traffic will feed into the system and traffic unpacking will occur. Here by unpacking we mean the separation of the header information from the operation part of the traffic packet. The header information will contain all the infrastructure information, including the creation time, expiration time, type of request and security token for the validation of the message. Next, in the Feature Selection module, the infrastructure information stored in the header is checked to determine if it is an abnormal or a regular traffic pattern. If it is a usual type of traffic pattern, then it is directed towards the comparison checking module. If it is not a usual type, then it is forwarded to the Profile Generation module which has the task of storing records about the traffic. The finishing time of the operation is also used to determine if it is a legitimate packet.
The Comparison Checking module will verify the type, size and all infrastructure details with previously recorded information. Here the different columns of characters are merged into a single string and the string checking is performed. Specifically, assume the recorded information follows the NTFS multiple data streams system. The multiple data streams are independent executable modules and service modules containing access rights, encryption,
and date and time information. All of these need to be checked while passing between the servers and the job queue. Based on the traffic scenario, dynamic rules are generated, classifiers applied and a link analysis performed for comparison checking to identify any abnormality in the traffic pattern. If this infrastructure information passes the comparison checking successfully then it is forwarded to the Validity Checking module, which will be done with the help of the security token. A bucket of security tokens will be organized to maintain continuous validation checking after extracting the body of the message from the header. The bucket of tokens is maintained in the Validation module which contains the unique identifiers of messages of a similar traffic type. If there is a mismatch with the traffic pattern anticipated by the profile generator, the validation module will not forward this message. Otherwise, the header information is extracted from the body and a decryption algorithm is applied in the validation module to retrieve the unique token number of each message. If the validation process fails, then an alarm message will be sent to the Alarm Generation module which executes the task of communicating with the third party by providing the detailed log for investigation.
If validation is successful, then the traffic is fed into the Scheduler. Here the requested operation will be extracted. Based on the type of request, the Scheduler will check the availability for that service in the fleet of servers (file manager, memory Traffic Unpacking Feature Selection Comparison Checking Profile Generation Lear ning P hase Incoming Traffic Validity Checking Alarm Generation Mism atch Not valid Scheduler Operation Extraction File Manager Memory Manager
PU Manager Name Server
Server Available
Job Queue
Message Missing
Message Drop Serve r N ot A vaila ble Third Party Log files
manager, process unit for complex computation, etc). If the specific type of server is not available, then the operation will be queued in the Job Queue storage. If it is available, then the operation will be appointed to the specific server via the Name Server. This Name Server has the task of coordinating all kinds of message passing between the servers and also with the scheduler (Figure 3). Hence, this server can also be considered as the monitoring server for message passing. If any missed message occurs in the system while executing jobs, then it will be detected and a “Drop Message” alarm will be generated by the Name Server. It will send this message to the Scheduler and the Scheduler will share this information with the Alarm Generator. Meanwhile, the Scheduler will also appoint another available server with the remaining task of the affected one via the Name Server, so that the remaining tasks of the attacked server do not starve.
Server 1: File Manager
Name Server
Server 3: Memory Management
Server 2: File Manager Server 1: Core Processor
Server 3: Job Scheduler
Figure 3: Messaging between servers For any kind of alarm message received in the Alarm Generator module, a new tag will be issued by the scheduler itself. This tag will contain all the information about the time of the incident, and the infrastructure information about all the traffic packets at that specific time. These tags will be provided to the neutral third party in a progressive manner; which means based on the investigation of the third party, the logs will be provided without disclosing the provider’s infrastructure information to the third party.
V. PREVENTING ATTACKS
In this section we discuss how our FAPA model prevents different types of flooding attacks.
A. ICMP and UDP Flooding/Spoofing
FAPA prevention: Unauthorized UDP packets will be detected in the Feature Selection module and the Comparison Checking module, and will not be sent to the scheduler.
Justification: The hypervisor is a communication mediator between the requester and the client. Whenever there is an unauthorized UDP packet the Feature Selection module will be able to verify unusual features, such as random ports of the client’s application, unmatched header information or a dissimilar expiration period of that message. In the Comparison Checking module, all these features will point out the invalidity of this packet in the next phase (Validation Checking) before sending the packet for scheduling. Hence, the chance of sending ICMP packets by the Scheduler is eliminated prior to scheduling. Instead, the invalid messages are forwarded to the Alarm Generation module. The system will be saved from UDP flooding and the engagement of its resources. Also, the recorded information in the Profile Generation module will prevent the system from flooding due to these types of packets in the future.
B. TCP SYN flooding attack
FAPA prevention: The 3-way handshake protocol and third party evaluation of the log files can identify the invalid messages and can even identify their requester.
Justification: The TCP SYN attack follows the 3-way handshake protocol and waits for the SYN-ACK from the servers. In our system the hypervisor takes the responsibility of scheduling and coordinating 3-way handshaking. So whenever a requester sends a TCP request, the unpacking is done in the Feature Selection module and infrastructure information inside the TCP packet will determine its illegitimacy. Suppose the attacker somehow manages to create a valid SYN with the usual features and bypasses both the feature and comparison phase. In the validation phase, the system will check the previous records of this requester’s TCP connection types, durations and creation request times etc. In this phase the TCP request will not be able to bypass the validation phase because this module checks all the previous TCP rates and SYN requests before forwarding the SYN to the scheduler. An unmatched TCP will be forwarded to the Alarm Generation module and will be analyzed by the neutral third party. Hence, the scheduler is again prevented from being flooded by SYN packets. Also, the third party will have sufficient log information to trace back to the requester who actually generated these SYN packets to flood the system.
C. Indirect Attack and Logic Bomb
FAPA prevention: The timer inside the Job Queue module will verify the validity of messages and identify an invalid request. Eventually an alarm will be generated so that the Alarm Generator module can broadcast this type of invalid message.
Justification: The hypervisor queues all these requests in the Job Queue module. If after a specific threshold time there is no match found for these types of messages or server requests, all these requests are forwarded to a neutral third party. Also, the Alarm Generation module will generate a broadcast message to notify all the working servers about these new types of invalid messages trying to flood the system. In the case of a Trojan horse or logic bomb, which will be triggered after a specific time, our monitoring device inside the scheduler will coordinate with the working servers and will provide feedback to the Alarm Generator.
FAPA is being design to circumvent any type of ICMP and UDP flooding, spoofing attack and TCP SYN flooding as either a direct one or an attack through handlers.
VI. CONCLUSIONS AND FUTURE WORK A cloud is vulnerable to numerous types and different approaches of attacks. In this paper we propose a theoretical model (FAPA) to prevent DoS attacks. By considering different types of DoS attacks, we aim to make the cloud more dynamic and adaptive. To build a cloud with this capability requires the system to have a learning module that evolves over time, to balance resources to make the cloud more dynamic and to schedule the resources using an intermediary system.
In our future work, we will implement the tasks of the hypervisor to prevent DoS attacks in a cloud. The first step of our implementation phase will be to simulate the FAPA model in a private cloud. By simulating inside a private cloud it will be possible to detect the nature of the inside attackers and their ill intensions. Then we will try our model on a private cloud to verify the vulnerability from different types of DoS attack as an outsider.
For our first step, we have created a private cloud named FLUFFY in our research lab that will be used for the simulation. We also plan to compare the performance of our FAPA model to other strategies to measure the overhead required by FAPA. Based on the results of simulations, we will proceed to bring this model to reality.
REFERENCES
[1] B. B. Gupta, R.C. Joshi, Manoj Misra. “Dyanmic and Auto Responsive Solution for Distributed Denial-of-Service Attacks.” Detection in ISP Network. International Journal of Computer Theory and Engineering, Vol.1, No.1, April 2009.
[2] T.M. Gil, M. Poletto, “Multops: a data structure for bandwidth attack detection,” in the proceedings of the 10th USENIX Security Symposium, Washington, DC, USA, 2001, pp23-38.
[3] W. Lee, S.J. Stolfo, K. W. Mok, “A data mining framework for building intrusion detection models,”
in the Proceedings of the 1999 IEEE Symposium on Security & Privacy, Oakland, CA, 1999, pp.120-132.
[4] S. Floyd, S. Bellovin, J. Ioannidis, K. Kompella, R. Mahajan, V. Paxson, “Pushback Messages for Controlling Aggregates in the Network,” draft-floyd-pushback-messages-00.txt, 2001.
[5] K. Hwang, M. Cai, Y. Chern, M. Qin(2007). Hybrid Intrusion Detection with Weighted Signature Generation over Anomalous Internet Episodes. IEEE Transaction on Dependable and Secure Computing. 4(1) 41-55.
[6] Kazi Zunnurhain, Susan V. Vrbsky. “Security in Cloud Computing”. Proceedings of the 2011 International Conference on Security & Management.
[7]VMware. Virtual Appliance Marketplace. http://www.vmware.com/appliances/.
[8]Amazon Elastic Compute Cloud (Amazon EC2). http://aws.amazon.com/ec2.
[9] Meiko Jenson, Jorg Schwenk, Nils Gruschka, Luigi Lo Iacono. On Technical Security Issues in Cloud Computing. IEEE International Conference on Cloud Computing 2009.
[10] Andreas Haeberlen. A Case for Accountable Cloud. Max Planck Institute of Software System (MPI-SWS).
[11] Nils Gruschka and Luigi Lo Iacono. Vulnerable Cloud: SOAP Message Security Validation Revisited. NEC Laboratories Europe Rathausallee 10 D-53757 Sankt Augustin (Germany), 2009 IEEE. [12] Mladen A. Vouk. Cloud Computing- Issues, Research and Implementations. Proccedings of the ITI 2008 30th Int. Conf. on Information Technology Interfaces, June 23-26,2008, Cavtat, Croatia.
[13] Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz, Andy Konwinski, Gunho Lee, Daviv Patterson, Ariel Rabkin, Ion Stoica and Matei Zaharia. A View of Cloud Computing. Communications of the ACM, April 2010.
