Agent Based Detection Mechanism to Outwit Distributed Denial ... - sersc

International Journal of Software Engineering and Its Applications Vol. 10, No. 10 (2016), pp. 149-164 http://dx.doi.org/10.14257/ijseia.2016.10.10.15

Agent Based Detection Mechanism to Outwit Distributed Denial of Service Attacks in Cloud Computing Environment Junath Naseer*, N. Ch. S. N. Iyengar and Mogan Kumar P.C *

Information Technology Department, IBRI College of Technology, Oman School of Computer Science and Engg., VIT University, Vellore -14, T.N, India 1 [email protected], [email protected] Abstract Distributed Denial of Service (DDoS) poses the highest rate of vulnerability to cloud computing in terms of availability with ability to destruct the Data-Center (DC) resources. The fortunate part of the attackers is these kinds of attacks are easier to launch the obscure flood towards victim DC and the unfortunate part of detection mechanism is to uncover the attack events and to protect the victim. In order to adapt and automate the detection mechanism in large scale network, agent based detection helps in improving the efficiency of detection. An increase in the network scale will also require the increase in agents deployed in the network to detect the vulnerability DDoS attack threats. This agent based DDoS Mechanism not only protects against huge DDoS flood, but also distinguishes the traffic characteristics by continuous traffic probing to classify the flash crowd traffic event and DDoS attack threat. Jade tool is used to simulate the experiment for our proposed detection scheme. Keywords: DoS, DDoS, Flash crowd, JADE, Agents

1. Introduction Distributed Denial of Service (DDoS) is one of the serious availability threats to Cloud computing. There are many research solutions available in the market, but in order to provide the solution to suit all scale of requestors; we suggest an architecture with agents which acts as a separation layer between requestors and DC resources. Agents help in minimizing the network load by allowing the parallel processing of incoming requestors by reducing the network load that improves the goodput which in turn improves the availability ratio for the legitimate requestors rather spending most of the time in detection and not in service provisioning. DDoS is one of the hardest attack to detect but easier to launch. These kinds of attacks make the victim to become unresponsive and rarely to be unavailable if the rate of attack strength grows. The intended subscribers’ loss their service as the service provider is under extreme overload. Cloud Flare experienced the largest DDoS attack flooding in February 2014, which is a record-breaking from 300 up to 400 Gbps attack. This attack is launched by anti-spammers Spamhaus, which is one of the largest DDoS attack [1]. Some other notorious DDoS attack experiences are: Mafia boy who succeeded in bringing down the world’s most popular websites, namely Yahoo, CNN, eBay, Dell and Amazon in February, 2000. Similar attacks were made towards the South Korean’s largest newspaper, bank and the United States forces created as a botnet over hundred thousands of computers in July, 2009 [2]. Still, several serious DDoS events lead to long outages to be identified and prevented. This paper is organized into several sections. Section 2 describes the related work; Section 3 illustrates the brief architecture of proposed agent based detection mechanism. Section 4 describes the detailed working mechanism, Section 5 analyses the experimental

ISSN: 1738-9984 IJSEIA Copyright ⓒ 2016 SERSC

International Journal of Software Engineering and Its Applications Vol. 10, No. 10 (2016)

results. Section 6 poses the advantages of the proposed mechanism and Section 7 concludes the work.

2. Related Work A statistical way of multivariate data traffic analysis [3] scheme called Feature Feature Source (FFSc) is used to detect the traffic variation. Here the traffic variables are considered via entropy namely Source IP, Packet rate, Variation of source IP. Also, the authors point out considering the single variable would not be sufficient enough to detect the traffic causing threat. By taking several variables into account, the deviation in any one of the variable is sufficient to recognize if the sample is deviated from normal traffic. Entropy of traffic is computed, variety of source IP, packet rate is considered with FFSc measure. Based on the FFSc of the normal network traffic, normal profile is generated with mean FFSc and the optimal range of FFSc which helps in exhibiting the similarity or similarity of traffic samples. An Anti-DoS mechanism [4] is developed from the ISO/IEC 1170-3 Key Exchange Protocol. The existing protocol and its variants are analyzed and the effect variant is slightly altered to transform it as an Anti-DoS mechanism. Protocol based subset sum has security puzzle and also an anti-DoS mechanism. Here the puzzle cannot be pre-computed and cannot be forged as the responder or the receiver end randomly changes the security parameter accordingly. Anti-DoS can execute fresh sessions when the attacker initiates session within the restricted time period. A key exchange protocol based on subset sum is DDoS resistant. Hash computation and memory cost on ciphering is comparatively less in the Protocol based subset sum scheme than stateless connection and fail together mechanism. Because of non-parallel characteristic, the protocol based subset sum client puzzle shows better resistance towards DDoS attacks and is able to deploy to secure the network behavior. A Hop Count Filtration Mechanism [5] is proposed which keeps monitoring the traffic at super flow level i.e., the individual flow can be easily recognized as the all packets destined to certain domain are grouped. The agents deployed in the network observe and detects the abrupt changes in the spatiotemporal distribution of traffic volumes. Based on the traffic surge, the agents intimate the traffic behavior to each other to protect the network being unavailable. The random fluctuations of the network caused by the variation of legitimate traffic, as the drastic fluctuations is considered to be attack threats and agents collaborate appropriately and detect the DDoS attack approaching the network. A Security framework for agent based cloud computing [6] developed the architecture with agents, namely consumer agents, broker agents, service provider agents, resource agents. Here the consumer agents and broker agents are third party agents, whereas service provider agents and resource agents reside at cloud environment. Initially, third party agents are authenticated and the traffic inflow is allowed for service access. The threats are detected at service provider agents based on the traffic behavior and the resources are serviced by resource agents. A stochastic hill climbing approach [7] which is centralized load balancing mechanism and it is an incomplete approach for solving optimization problem. Genetic Algorithm [8] based load balancing proposes the three step operation, namely population generation, cross over to select the best fit resource configuration and mutation for choosing the probable best resource configuration. For insider threat detection, log management [9] has been proposed which uses log analysis with event correlation. Certain rule with a timestamp is continuously monitored using log watcher for better detection. Network flow based entropy approach [10] analyzes requests per flow and improves detection accuracy by three steps. They are flow aggregation analysis based on traffic flow, fast entropy computation, and threshold refresh for maintaining and improving the accuracy rate of detection. Application layer DDoS poses critical threats to web server [11]. For such

150

Copyright ⓒ 2016 SERSC

International Journal of Software Engineering and Its Applications Vol. 10, No. 10 (2016)

detection, the traffic has to be classified in order to avoid considering flashcrowd as DDoS. This has been deployed with real-time frequency vector. Fuzzy logic based DDoS defense mechanism [12] considers the network packet parameters which attempts to detect the DDoS attack scenario, but there is a limitation or pitfall when the rate of traffic is huge as they process each traffic requests’ packet parameters. DDoS Defense for web services in cloud discussion reveals the threat of XML attacks at the application layer [13]. Here the feature extraction and attack request model construction typically detects malicious requests.

3. A Brief Discussion about Agent based Architecture The proposed architecture contains the following sub modular components. Subsidiary Agents (SA) Environment SA

SA Cloud Environment SA Data Center (DC)

SA SA

SA

Agent Manager (AM)

Requestors can be Subscribed Clients (SC) Attack Group (AG) SC SC AG

SC SC SC

SC

SC

AG

SC

SC

AG

Figure 1. Architecture of the Proposed Multi-agent based Detection Mechanism Requestor Group: The requestor group is the incoming clients who are subscribed for the services provided by the cloud environment. The requestors are initially authenticated and allowed access which is again a hierarchical way of serving the resources to the corresponding subscribed client. Always the users will not connect to the DC or the service provider immediately. They are scrutinized by the intermediate layer called subsidiary Agent (SA) Environment. Subsidiary Agent Environment: This Subsidiary Agent Environment will have several agents which serve the requestors based on their requests. These subsidiary agents do not only serve requestors,

Copyright ⓒ 2016 SERSC

151

International Journal of Software Engineering and Its Applications Vol. 10, No. 10 (2016)

but also shares information and communicate among themselves. Also acts as a protective layer and barrier to DC resources. Cloud Environment: Each DC will have an agent manager which collects the information about the current traffic approaching the DC to acquire resources. This agent manager precisely computes the network traffic behavior in an efficient way which helps in forecast the network behavior. As the subsidiary agents of the Agent manager keep track of the requestors, the shared repository is continuously updated by the subsidiary agents. This log helps in recognizing the heuristic behavior. DC in any case processes the requests which are forwarded by agent manager. The agent manager and DC are separated from requestors, so this allows protecting the DC resources and making the least possibility to overload towards the victim, as subsidiary agents will only be compromised, brought down and not the unknown DC and agent manager. The Challenge Handshake Authentication Protocol is used to validate the incoming requestors. The authentication is the most important step to validate the incoming requestors which should be a light weight cipher and should not impose processing load while validating the incoming requestors because the scheme is proposed for overload detection. Spending more time in validating the requestors at the time of DDoS results in queueing of requests which itself a serious hazard and increase the probable chance of being victimized by reducing the availability of DC resources for the intended legitimate clients.

4. Working Mechanism The working mechanism of the proposed agent based detection involves in activating the SA on-demand i.e., when the network behavior is forecasted to grow. As the network overloads, agent manager attempts to process the known and valid legitimate behaviors to reduce the queueing of requests. Once the requests are queued, after certain point of time, it leads to request dropping which may lead to false negative situation. The below protocol outline explains the proposed mechanism’s behavior with respect to Agent Manager and Subsidiary Agents. 4.1. Protocol Outline of the Proposed Mechanism: Traffic Monitoring: At Subsidiary Agents: For Each incoming requestors IRi, Identify request_type If (IRi holds session ID) If(IRi details available at SA) Observe the traffic divergence, compute trust for IRi If(traffic divergence > network threshold) “Abnormal Traffic (DDoS)” Else “Normal Traffic (Legitimate or Flash crowd)” Else Acquire the Client ID and its details from AM. Else Forward to AM. Resource Availability Monitoring: At Agent manager:

152

Copyright ⓒ 2016 SERSC

International Journal of Software Engineering and Its Applications Vol. 10, No. 10 (2016)

If(Request_type == ‘auth_request’) Initiate CHAP authentication If(successful auth_request) Validate service_request. AM Repository is updated with the requestors’ request to provide the service. Else Intimate SA about auth_request failure. Reactive Decision making: At Subsidiary Agents: If (for any IRi inappropriate TBP found) Trigger blackout time period for IRi Agent Manager Interaction: At Subsidiary Agents Environment: if (SA overloaded in processing the incoming requestor) if (number of activated SA == total number of SA) Initiate new SA or fork the existing SA. else Delegate the information among SAs 4.2. Detailed Working Mechanism Agent Manager and Subsidiary agents’ co-ordinate and provide service to the intended requestors. This mechanism follows the master slave delegation strategy. Agent Manager keeps track of the resources allocated and resources available at the DC. The resources information is available in detail with Agent Manager by the VM level resources. The requestors approach the CSP for getting service. The requestors are initially authenticated and the session id is provided to actively identify for further communication for the authenticated requestors. The session Id has a session timeout period which is for about a minute, which will be refreshed until the user communicates actively and expires at the time of service completion. Initially the authentication is carried by CHAP, a protocol implemented to authenticate the incoming requestors. This proposed mechanism is deployed at the attack-prone DC. So, instead of spending much time in authenticating and also ciphering the entire communication, an optimal way of authenticating with CHAP and the session is maintained for each authenticated or valid requestors. The requestors are queued up based on the registration. The registered requestors queue (RRQ) is the one where the requestors who had already have credentials to access the DC service who might or might not acquire session ID and the non-registered requestors queue (NRQ) acquires inappropriate requestors who does not hold any valid client ID. The requestors queue is segregated to quickly identify the requestors with the intention of serving the registered users at priority instead of waiting for along with attack prone requestors at the time of traffic overload. The registered requestors are queued even at the time of overload and served by the agents but the non-registered requestors are queued and given minimal priority comparatively. The registered requestors cannot be made to wait for long at the time of overload. This segregation improves the DC availability to legitimate drastically. DC Status Repository: DC resides at the Cloud Service Provider (CSP). DC is comprised of several resources which are divided as virtual machines (VM) memory blocks. Each DC associated with Agent Manager (AM). The agent manager at the CSP DC end will act as a virtual load balancer by delegating the service activities to its Subsidiary Agents (SA). The connected requestors can be easily identified by the session IDs which is available at SAs.

Copyright ⓒ 2016 SERSC

153

International Journal of Software Engineering and Its Applications Vol. 10, No. 10 (2016)

DC ID

AM ID

Request Type

Time Stamp

DC ID is the identifier which uniquely identifies the datacenter whereas AM ID being the agent manager identifier is associated with that DC. This repository also has timestamp which is to indicate the last update of the particular record. AM Repository: Each DC will have its own Agent Manager and any DC’s agent manager can communicate to each other, but the SAs of two different Agent Managers cannot communicate between them. The reason is to have a centralized control of traffic and tracking the resource details and requestor traffic behavior. When the SAs intimate the AM about their requests, AM will service the requests based on the availability and if the resources are not available, AM will redirect the requests appropriately and continue serving the incoming legitimate requestors. VM ID

SA ID

No. of Active Sessions

Allocated Resources (%)

Max available memory block

Time Stamp

AM of each DC will have a repository which has several attributes necessary to track the resource allocation towards that particular DC. The traffic is recorded and controlled by all the subsidiary agents of this AM. The load of DC depends on the resources available, the more resources available, they are less loaded and vice versa. AM Repository will have a list of VM IDs and each VM ID will have an array of SAs which involves in resource allocation in that particular VM ID. And the active sessions associated with that VM along with the percentage of resources allocated. The max available memory block is also listed so as to decide the service ability of the incoming requestor. The timestamp is used to recognize the update status of the VM at AM Repository. SA Repository: SA Repository is used to compute and predict the network traffic condition and requestor behavior and the attributes associated with this repository. The SAs will always have the active clients who obtain the session ID from the AM. All SAs of AM monitors at least 1 client. Otherwise, the SAs are deactivated and activated at the time of more traffic flow. Client ID

Session ID

Trust Behavioral Points (TBP)

Historical TBP

AM ID

Time Stamp

Subsidiary Agents are the subordinates of Agent Manager available at DC and these SA will have the capability to determine the incoming requestor behavior. The requestors can be identified by their Client ID and their active participation towards the DC is identified by Session ID. The requestors’ trust can be recognized based on the TBP and historical TBP. The SAs will also have the imprint of AM ID associated with it. The time stamp is used to recognize the record updated time. Flow of the Defensive Mechanism: The requestors approach DC to get serviced. The Defensive mechanism is developed with the intention to protect the DC, so the requestors are not allowed to interact with DC directly, in fact the requestors are thoroughly authenticated and the valid session is

154

Copyright ⓒ 2016 SERSC

International Journal of Software Engineering and Its Applications Vol. 10, No. 10 (2016)

created and then they are allowed to monitor continuously by the subsidiary agents and a periodical behavior status is updated. While updating the traffic behavior, if the behavior is suspected to be faulty, the client is outwitted temporarily. The traffic deviation is identified based on the standard deviation of the traffic sample from the overall network traffic population. The requestors reach SAs for service requests and the requests can be from Subscribed Clients or from attack prone requestors, sometimes a combination of both. The requestors are hidden about the request flow and at any time minimum one SA will be active per DC to acquire and process the incoming requestors service. In SA, there are two kinds of requests processed, initially while authentication (auth_request) and after successful authentication, the actual service requests (service_request) will be served based on the priority of incoming requestor. The auth_requests are carried out for each incoming requestor before they start getting the service. Initially, the clients initiate the transaction with auth_request and service_request. The service_request will be processed after the successful auth_request. Once the auth_request of any client reaches SA, SA queue them up and forwards it to its AM. AM is the controller of the agents which is responsible for creation and to confine the agents. The requests reaches AM and the SA ID is identified and the load of SA is also computed based on the active clients connected to that particular SA. The requestor’s record will be searched at DC for authenticating them if they are Subscribed Client with Client ID. The SC’s information is forwarded to SA by AM upon validating them with CHAP authentication scheme to scrutinize the authenticity. Otherwise, the incoming requestor is considered as new registration request as the client ID is not obtained by SA and at AM. The valid and unique client ID is created stored at DC and sends to the requestor via SA after obtaining the necessary credential information from the requestor. The session IDs are not created for new requestors as the intention of new requestor might be to overload DC, so they must again join the network with their newly created Client ID to access the DC. Upon consecutive auth_request failure after a certain number of attempts, the requestor will not be assigned a session ID until blackout time period. This way of implementation considerably decreases the chances of request overload toward DC. After the successful authentication, the requestor’s service requests will be processed. The authenticated Client ID and their information will be sent to the respective SAs. The client Information includes the historical behavior (Trust Behavioral Points) and the generated session ID to uniquely identify as a valid session holder at DC. Whenever the clients’ TBP is updated the timestamp is also updated so as to identify their latest update. The SAs, AMs and DCs timestamps also serve the similar purpose of identifying the last update of the corresponding Clients, SAs and VMs. So, the valid session holders or the requestors who all prove authenticity via CHAP authentication scheme, their details will be sent by AM and acquired at SA along with the updated timestamp of SA Repository. Now it is presumed that the services subscribed varies among the incoming requestors. So, the service_request will be validated whether the requestor is eligible for such service_request. Inappropriate service request is also considered as overload threat, but these overload are classified as aggressive legitimates. The service_request can be email, FTP with certain permission levels, HTTP web page access permission levels based on subscriptions. When the service_request is identified as valid, then the transactions are updated at SA along with the TBP. Trust Computation on each transaction of any requestor towards SA: TBPi = 1-(CRRi / MRRi)

(1)

TBPThreshold = (CRR/ CTR)

(2)

Copyright ⓒ 2016 SERSC

155

International Journal of Software Engineering and Its Applications Vol. 10, No. 10 (2016)

CRRi = Current Request Rate for the user group; MRRi = Max Request Rate for the user group; TBPi = Trust Behavior Points for the requestor i. CTR = Current Traffic Rate of the network; Here, request rate is the rate at which the traffic approaches the DC for the particular requestor i. Lessen the number of requests by any requestor, improves the TBP and least number of requests during the nominal traffic reduces the TBP threshold and improves the network traffic condition. Based on the experimental setup, the TBP threshold is set to 0.3 to be authentic and not over loaders, the TBP threshold of 0.49 is set to be aggressive legitimates and 0.5 and above is the overload threats. Upon positive TBP (requestors TBP under 0.5), the legitimates’ service_request is forwarded to AM and the optimal VM resource is allocated. The requestor’s service_request is allocated at particular VM ID, which can be easily referred later as the list of SAs communicating to the VM is also available as a part of AM Repository. Once the valid session ID acquired at AM and positive TBP is identified at SA, the requestor is considered to be legitimate and the traffic flow is continuously monitored for the TBP prediction because this mechanism is proposed with the intention of protecting from overload and the overload can also be initiated by legitimates. So, the traffic is continuously monitored and TBP is updated, whenever the TBP is below TBP threshold, then the legitimate is considered to be the aggressor (who is legitimate but involved in overload activity). The TBP threshold is computed in such a way that consecutive negative behavior is considered as negative TBP. The immediate reduction in TBP of the legitimate is not considered as the illegitimates as the legitimates might face some packet loss in the traffic. So, they might reattempt to get serviced which might appear as overload but actually not. These TBP helps SAs to compute the behavior in the network and once the session is about to be closed by the AM, the SA transmits the session ID and their TBP to AM, so the historical TBP is updated as the last TBP earned by that particular requestor at AM. The SA Repository is updated by removing the expired sessions and the AM Repository is updated with VM ID and resource allocation, SA Lists associated with that VM will also be updated at DC. At the time of Flooding attack: The traffic approaching DC will be a combined legitimate and illegitimate traffic, which must be authenticated initially and then the service requests must be processed. The network traffic sample is collected and the traffic deviation is to be computed. If the traffic deviation is within the CSP controllable limit, then it is confirmed as normal traffic, if the traffic deviation exceeds CSP controllable limit, the network is considered to be suffering from overload which is abnormal traffic condition. The traffic condition is predicted earlier by SAs. The requestors are prioritized by the segregation as registered and non-registered requestors queues. This queue helps in identifying and allowing the legitimates and the valid session holder to participate more actively than non-registered requestors as they are more vulnerable cause of overload. The additional TBP of any requestor computation helps in solely analyzing the behavior in the network. The least overloading legitimates will be given more preference than other legitimates. TBPthreshold determines the trust band within which the requestors are considered as non-overloading requestors. This computation is made for each interval of time with the incoming traffic samples. If the network traffic condition is found abnormal, and if all the requestors are identified as legitimates, then this behavior is called flash crowd. Because, the huge number of requestors approaching DC, all with valid behavior. The overload caused by non-registered requestors and the number of consecutive authentication attempts is more

156

Copyright ⓒ 2016 SERSC

International Journal of Software Engineering and Its Applications Vol. 10, No. 10 (2016)

than the limit set by the CSP, then the requestor is identified as a defaulter and blocked the same requestor’s requests until the blackout time period which is the configurable parameter set by the CSP.

Requestors Trace the Network Traffic

IS NORMAL

Yes

No Overload

No

Overload

Traffic Divergence exceeds threshold

No

FLASH CROWD

Yes

DDOS Figure 2. Overload Prediction based on Traffic Flow Security Feature: Agents are programmed for traffic analysis and to decide the trustworthiness of any incoming requestor. All the agents created by any AM are controlled by its AM. AM is the centralized control system for agent activation, the traffic is completely delegated among the agents to improve the parallelism, each SA agent will have its own repository and have their active session holders to serve for, these SAs consistently report its status to AM and each SA also is involved in computing trust for each incoming requestors. The TBP of any requestor reveals the behavior towards DC. Since the centralized control agents and whole agent creation process are at CSP, there is no need of any third party agents which improves the reliability of agents. The delegated process of computing the session of requestor’s behavior is the only activity of the SA. The pre authentication is done at AM but via SA. So, instead of having several hierarchies of agents, optimizing the level of agent hierarchy and proper delegation of activities to be performed by the delegated agents improves the reliability of agents in this system.

5. Experimental Results JADE is a common agent based simulator built over java as a framework which has been utilized to test the cloud computing environment. The experiments are performed in a distributed network where DC requestors are grouped in five subnets, and each subnet has got 100 workstations, 100 attackers and 200 legitimate clients requesting for application-specific requests at each subnet. This way we created the attacker and

Copyright ⓒ 2016 SERSC

157

International Journal of Software Engineering and Its Applications Vol. 10, No. 10 (2016)

legitimate profile and other devices, which would be needed to test our algorithm as an experiment. The traffic represents internet and the group of spoof attackers is activated at varying time intervals. The attack profile is replicated to increase the attack strength to engage the DC resources like bandwidth, CPU and memory. On the whole, our experiment has 1000 clients and 500 attackers. The configuration would vary based on the network settings. Table 5.1. Configurable parameters at CSP Number of consecutive authentication attempts Timeout period Session expiry/refresh time Number of SA creation SA Load Queue size at AM, SA Blackout time period TBP Threshold

3 45 Seconds 60 Seconds 30 100 120 60 Seconds 0.49

All these configurable parameters are found to be the optimal values to protect the network and these values can vary depending upon the network traffic condition and varied attack prone zones. Setting the above parameters to the experimentation yields the results discussed in this section. 2.1. False Rate Analysis False Rate Analysis is the rate of requests bypassed (sample of illegitimate requests) or dropped (sample of legitimate requests) by the detection scheme. X-Axis represents the time in minutes and Y-Axis represents the number of requestors. Figure 3 shows the false rate analysis where the false positives are comparatively higher than the false negatives. The false positives include the aggressive legitimates which is found based on the TBP at SA. The false negatives are comparatively less because of the statistical nature of detection as the sample of traffic is probed to predict the network condition. Table 5.2. False Rate Analysis Time (mins) False Positives False Negatives

0 5 0 0 0 0

10 82 0

15 18 12

20 25 30 102 190 40 16 105 0

35 12 2

40 0 20

45 0 0

50 18 31

55 0 0

60 2 0

Figure 3. False Rate Analysis

158

Copyright ⓒ 2016 SERSC

International Journal of Software Engineering and Its Applications Vol. 10, No. 10 (2016)

2.2. Session Generation Status Session Generation is the process of allocating the resource at DC for the incoming requestor who is successfully authenticated at AM via SA. X-Axis represents the time in minutes and Y-Axis represents the number of requestors.

Figure 4. Session Generation Status Figure 4 shows the sessions created by the valid requestors and the session dropped due to the illegitimate behavior or authentication failure for consecutive number of times. The oscillations in Figure 4 shows the different requestors are joining the network at different time and also shows the possibility of aggressive legitimates outwit. The session dropped is found to be more after certain point of time as the overload threats behavior had been found from 10th minute of the simulation until then the new sessions are created as the detection mechanism uses separate queues for registered and nonregistered requestors. Table 5.3. Session Generation Status Time (mins) Session Created Session Dropped

0 5 10 100 112 82

15 18

0

212 219 190 120 212 220 212 231 0

0

0

20 22

25 42

30 40

35 40 111 26

45 19

50 18

55 0

60 18 0

2.3. Threat Detection Threat Detection is the number of requestors identified as attack prone based on the behavior. This also includes the requestors who had been blocked due to varied TBPthreshold. X-Axis represents the time in minutes and Y-Axis represents the number of requestors.

Copyright ⓒ 2016 SERSC

159

International Journal of Software Engineering and Its Applications Vol. 10, No. 10 (2016)

Figure 5. Threat Detection at CSP Figure 5 shows threat detection at CSP which include the aggressive legitimates detection who does not have legitimate TBP. The oscillations in time in the network can be found in Figure 5 and the threats are outwitted, again they try to participate in the network, so the number of threats detected again increases, this keeps continuing and appears as an oscillation. Table 5.4. Threat Detection Time (mins) Threats Detected

0 0

5 5

10 15 102 64

20 51

25 92

30 40

35 40 111 26

45 73

50 18

55 15

60 18

2.4. Request Traffic Number of requestors who attempts to acquire resource at victim DC. This includes both legitimate and illegitimate requestors, a combined traffic source. X-Axis represents the time in minutes and Y-Axis represents the number of requestors.

Figure 6. Request Traffic at CSP

160

Copyright ⓒ 2016 SERSC

International Journal of Software Engineering and Its Applications Vol. 10, No. 10 (2016)

Table 5.5. Request Traffic Time (mins) 0 0 Traffic Requests

5 50

10 15 20 25 30 35 40 45 50 55 60 102 190 218 228 205 210 221 241 235 228 222

Figure 6 shows the request traffic attempts to reach DC for acquiring the resources, these requestors traffic includes both registered and nonregistered requestors. It can be found easily that the Figure 6 shows the steep increase initially which is due to the legitimates and again after some time, another steep increase shows the DDoS overload attack is started, from that point the traffic shows the little ups and downs which is due to the maximum number of attackers who had participated in targeting the victim. 2.5. DC Response Time The time spent in processing the service request and allocating the resource and updating their behavior at DC for any requestor’s request at point of time. X-Axis represents the time in minutes and Y-Axis represents the response time in milliseconds. Table 5.6. DC Response Time Time (mins) 0 DC Response 0 Time (ms)

5 5

10 15 102 64

20 51

25 92

30 40

35 40 111 26

45 73

50 18

55 15

60 18

DC Response time in Figure 7 is less which seems quicker and as time goes the response time gradually increases and at times, the steep increase in response time which is due to the large number of requests approaching DC. Whenever the AM spends more time in interacting with SAs, the response time gradually increases, which would create a slight delay in processing and retrieving the necessary information for any requestor instead of being unavailable. Though response time does not seem much higher which is because the AM is deployed to carry all the traffic control and DC spends its time only in responding to the legitimates approved by AM.

Figure 7. DC Response Time

3. Advantages 1) Scalable Mechanism: As the proposed mechanism depends on agents, the SAs scalability will automate the whole detection scheme scalability as they are the requestor behavior monitoring point. They cannot be bypassed to reach DC or AM as the valid session ID is a mandated requirement to get serviced from DC. AM acts as a intra load

Copyright ⓒ 2016 SERSC

161

International Journal of Software Engineering and Its Applications Vol. 10, No. 10 (2016)

balancer among the available VMs by tracking the VM resource allocation for the requestors. 2) Implicit Trusted Agents: The proposed mechanism resembles very much similar to requesting the resources directly to DC, as the AM and SAs resides at CSP. Since they are at CSP end there is no explicit calculation is needed to validate the agents trust. The requestors will reach the intermediate SA to acquire service which is then processed at confined DC. 3) Security Add-ons: Instead of having a hierarchy of agents. Lesser the agents’ hierarchy, lesser the chances of communication error and fasten the service. Since there is no need of any third party agents, the CSP agents is completely secured on its own. It does not depend on any other third-party agents. The add-on feature is the aggressive client detection i.e., the detection scheme does not only identify the overload but also identifies the cause of such threat and outwits them even if the overload is caused by legitimates and categorizing them as aggressive clients.

4. Conclusion The proposed mechanism makes use of multi-agents to detect DDoS. This scheme also helps in distinguishing the attack causing threats and valid requestors at the time of overload. These multi-agents are extremely optimal as they are activated on demand. And as a part of the contingency, more agents are made proactive only when they are to be required in the near future, instead of forking them initially which considerably reduces the processing consumption. The separation layer of subsidiary agents allows the DC to only serve the requestor as the detection of threats in monitored by Agent manager based on the subsidiary agents. This considerably improves the efficiency of the detection. The basic architecture and the agent manager along with its subsidiary agents’ behavior tracking allows the proposed mechanism to deploy in all scale.

Acknowledgments I Junath Naseer highly thankful to Mr. MOGAN KUMAR PC for helping in experimental setup during the summer and also in giving me his valuable inputs, otherwise it would not have been possible for me to complete this work. I am also thankful to the reviewers for their valuable comments for improving the work and to SERSC management for considering at the earliest.

References [1] [2] [3] [4]

[5] [6]

[7] [8] [9]

162

https://www.cloudflare.com/under-attack (accessed on June 2016). http://www.thedailybeast.com/articles/2010/12/11/hackers-10-most-famous-attacks-wormsandddostakedowns.html (accessed on June 2016). N. Hoque, D. K. Bhattacharyya and J. K. Kalita, “A Novel Measure for Low-rate and High-rate DDoS Attack Detection using Multivariate Data Analysis”, COMSNETS, (2016), pp. 1-2. L. Jiang, C. Xu, X. Wang and Y. Zhou, “Analysis and Comparison of the Network Security Protocol with DoS/DDoS Attack Resistance Performance”, IEEE 17th International Conference on High Performance Computing and Communications (HPCC), (2015), pp. 1785-1790. M. Duraipandian and C. Palanisamy, “An Intelligent Agent Based Defense Architecture for DDoS Attacks”. Venkateshwaran K., A. Malviya, U. Dikshit and S. Venkatesan, “Security Framework for Agent-Based Cloud Computing”, International Journal of Artificial Intelligence and Interactive Multimedia, vol. 3, no. 3, (2015), pp. 35-42. B. Mondal, K. Dasgupta and P. Dutta, “Load Balancing in Cloud Computing using Stochastic Hill Climbing-A Soft Computing Approach”, Procedia Technology, vol. 4, (2012), pp. 783-789. K. Dasgupta, B. Mandal, P. Dutta, J. K. Mandal and S. Dam, “A Genetic Algorithm (GA) based Load Balancing Strategy for Cloud Computing”, Procedia Technology, vol. 10, (2013), pp. 340-347. A. Ambrea and N. Shekokar, “Insider Threat Detection Using Log Analysis and Event Correlation”, Procedia Computer Science, vol. 45, (2015), pp. 436-445.

Copyright ⓒ 2016 SERSC

International Journal of Software Engineering and Its Applications Vol. 10, No. 10 (2016)

[10] J. David and C. Thomas, “DDoS Attack Detection Using Fast Entropy Approach on Flow-Based Network Traffic”, Procedia Computer Science, vol. 50, (2015), pp. 30-36. [11] W. Zhou, W. Jia, S. Wen, Y. Xiang and W. Zhou, “Detection and defense of application-layer DDoS attacks in backbone web traffic”, Future Generation Computer Systems, vol. 38, (2014), pp. 36-46. [12] N. Ch. S. N. Iyengar, A. Banerjee and G. Ganapathy, “A Fuzzy Logic based Defense Mechanism against Distributed Denial of Service Attack in Cloud Computing Environment”, International Journal of Communication Networks and Information Security (IJCNIS), vol. 6, no. 3, (2014), pp. 233-245. [13] T. Vissers, T. S. Somasundaram, L. Pieters, K. Govindarajan and P. Hellinckx, “DDoS defense system for web services in a cloud environment”, Future Generation Computer Systems, vol. 37, (2014), pp. 3745.

Authors Junath Naseer Ahmed, he is currently working as lecturer at Information Technology Department, IBRI College of Technology, Oman. His area of interest is Cloud computing, Agent technology and Information Technology.

N. Ch. S. N. Iyengar, he is a Senior Professor, SCOPE at VIT University, Vellore, TN, India. His research interests include cloud Computing, Information Security, Big data, Intelligent Computing, eCommerce, Health Informatics and Fluid Dynamics (Porous Media). He had 30+ years of teaching and research experience with 200+ publications with good credentials.

Mogan Kumar PC, he is a researcher, SCOPE at VIT University, Vellore, TN, India. His research interests include Cloud Computing, Network Security, Big Data Processing and analytics.

Copyright ⓒ 2016 SERSC

163

International Journal of Software Engineering and Its Applications Vol. 10, No. 10 (2016)

164

Copyright ⓒ 2016 SERSC