Proactive DDoS Attack Mitigation in Cloud-Fog Environment using Moving Target Defense

Distributed Denial of Service (DDoS) attacks are serious cyber attacks and mitigating DDoS attacks in cloud is a topic of ongoing research interest which remains a major security challenge. Fog computing is an extension of cloud computing which has been used to secure cloud. Moving Target Defense (MTD) is a newly recognized, proactive security defense that can be used to mitigate DDoS attacks on cloud. MTD intends to make a system dynamic in nature and uncertain by changing attack surface continuously to confuse attackers. In this paper, a novel DDoS mitigation framework is presented to support Cloud-Fog Platform using MTD technique (CFPM). CFPM applies migration MTD technique at fog layer to mitigate DDoS attacks in cloud. It detects attacker among all the legitimate clients proactively at the fog layer and isolate it from innocent clients. CFPM uses an effective request handling procedure for load balancing and attacker isolation procedure which aims to minimize disruption to cloud server as well as serving fog servers. In addition, effectiveness of CFPM is evaluated by analyzing the behavior of the system before and after attack, considering different possible scenarios. This approach is effective as it uses the advantage of both MTD technique and Fog computing paradigm supporting cloud environment.


INTRODUCTION
Amongst the diverse threats to cyber security Distributed denial-of-service (DDoS) attack [1]- [3] is most prevailing nowadays. In DDoS attacks, target is overloaded with enormous traffic by a large number of connected devices that are distributed across the Internet. This results in loss of equipment resources and network bandwidth.
Securing cloud from these attacks has become a big challenge [4]- [6]. Cloud servers have the potential to perform computing and storage tasks, without the direct involvement of user. But as they are faraway, it is required to send all the raw data (could be sensitive) to the cloud servers over the internet which may have some privacy and security issues. Various DDoS attack handling techniques in cloud [7]- [9] are proposed.
Fog computing or fogging [10], is a decentralized computing infrastructure that distributes data, services of computing, storage, networking and communications between the cloud and the data source. Fog computing is basically an extension of cloud computing. In order to provide faster ICT services to the end users, it brings cloud computing capabilities to the edge of the network. The goal of fogging is to enhance efficiency by reducing the total amount of sensitive data that is transported to the cloud for analysis, storage and processing [11].
Though fog computing conserves network bandwidth and improves system response time but at the same time it is also prone to cyber attacks such as DDoS attacks. As the capacity of each fog node is restricted, these attacks can be detrimental to fog computing's availability also [12]. As of now it is critical to secure cloud with additional measures as fog layer alone is not sufficient enough.
One newly recognized cyber defense strategy, which helps in mitigating DDoS attacks is introduced i.e. Moving Target Defense (MTD) [13]- [15]. MTD keeps the network environment less deterministic and unpredictable by continuously changing the attack surface. This uncertainity induces confusion for attackers, simultaneously increasing the attacker's time, efforts, and cost while decreasing the cost of defensive strategies. MTD has its potential applications in various areas. In the literature Fog computing and MTD has been used separately for cloud security. Also MTD techniques have not been applied to fog computing paradigm.
In this paper an approach CFPM is presented, which mitigates DDoS attacks in Cloud-Fog Platform using Moving Target Defense(MTD) as the underlying tech-nique. CFPM monitors the traffic generated from all the connected users to look for abnormalities. It handles the DDoS attack at fog layer using the concept of migration MTD. Migration MTD is a dynamic platform diversification MTD technique. This approach is effective as it takes the advantage of both Fog computing and MTD to secure cloud.

RELATED WORK
Several techniques have been developed to mitigate the impact of DDoS attacks in cloud [7], [8]. Ahmed et al. [9] investigated such mitigation techniques and compared them in cloud environment. Fog computing [10] is one of the promising way to deal with such attacks in cloud. Decoy information technology called Fog computing has been used by the authors in [11] to secure the cloud. But fog computing itself is susceptible to such attacks, which is investigated by the authors in [12] as fog devices work at the bottom/edge of networks.
MTD emerged as a promising approach to network security. Li Jason et al. [15] productized MTD research technology, called Self-shielding Dynamic Network Architecture (SDNA) technology, now known as Cryptonite NXT. MTD intends to create asymmetric uncertainty on the attacker's side by constantly changing the attack surface. Zheng et al. [16] presented a comprehensive survey on MTD and its implementation strategies from architectural perspective.
Based on the kind of changes MTD is making to the system it has been classified into four categories i.e., Software based diversification , Runtime based diversification, Communication diversification and Dynamic Platform diversification by the authors in [17]. MTD has its potential applications in various areas. Different MTD techniques have been applied in different domains. Authors in [18], [19] have applied runtime based diversification MTD techniques i.e., instruction-set randomization and address-space randomization to counter attack. Jackson et al. [20] have used software based diversification MTD techniques i.e., software diversity and compiler generated diversity and evaluated their effectiveness. Al-Saher et al. [21] presented a MTD architecture called mutable networks(MUTE) which uses communication diversification MTD technique i.e., IP address randomization. Thompson et al. [22] proposes an approach that applies rotation of multiple operating systems to enhance security i.e. diversity technique has been used which comes under dynamic platform diversification MTD.
Zhuang et al. [23] applied simulation-based experiments to explain enhanced efficiency due to the introduction of diversification and randomization in the system. Comparison of different MTD techniques has been proposed by the authors in [24]. Authors in [25], [26] studied the effectiveness of MTD using security models and investigated applications of MTD to network security. Okhravi et al. [27], [28] has applied dynamic platform diversification MTD technique as defense mechansim on critical infrastructure. MTD has been used for mitigation of DDoS attacks against a proxy based architecture by the authors in [29]- [32]. Authors in [33], [34] have used dynamic platform diversification i.e. shuffle MTD as the underlying MTD technique to mitigate DDoS attack proactively at proxy layer.
Peng et al. [35] ascertained whether MTD is effective in protecting Cloud-based services and if yes, upto what extent, with heterogeneous and dynamic attack surfaces. Wang et al. [36] proposed a cost effective defense against DDoS and Covert channel attacks using MTD. Authors in [37] have used IP address randomization as MTD technique for cloud computing platform. The authors in [38], [39] have combined differnt dynamic platform diversification MTD techniques i.e, Shuffle and Diversity and evaluated it for cloud computing. This combined approach is very efficient as it amplifies randomization. So due to its promising capabilities MTD is a suitable strategy for addressing cloud computing security issues. But MTD has not been applied to fog paradigm in the field of research in past. Bazm et al. [40] evaluated that MTD can be applied to both multi-cloud and decentralized cloud infrastructures such as Fog.
This paper presents an approach CFPM that mitigates DDoS attack in a combined Cloud-Fog Platform using dynamic platform diversification MTD technique i.e., migration MTD technique.

Overview
The proposed approach CFPM, mitigates DDoS attacks in the cloud by using the concept of fog computing with migration moving target defense technique. Fig.  1 shows the proposed architecture, which consists of 3 components: 1) (a) cloud servers 2) (b) fog layer comprising of many fog servers 3) (c) users (both innocent and malicious) Fog servers present in the fog layer are in two modes i.e. sleep mode or active mode. Active fog servers are used for serving the users and the grey colored fog server i.e., sleeping fog server is activated only if any attacker is detected so sleeping fog server is named as Attack Fog server. Number of sleeping fog servers are very less compared to active fog servers.
This architecture permits the user to access the services provided by fog servers only after successful authentication. User before connecting to any fog server mention the maximum requests it can send per second and at the time of requesting it passes its current need.
A fog server can serve many users and a user can request any number of times in a second until or unless it has reached its limit i.e., it has requested the maximum number of requests in total that it has mentioned at the time of connection. If the request can not be handled at the fog layer i.e., all fog servers are fully occupied, then only the request is passed to the cloud server.  Table 1 shows various notations used in the CFPM approach presented in this paper.  Fig. 2 shows the structure of Flag[ ] variable, which defines the state of each fog server using 3 fields as follows:

Preliminaries
1) Mode Bit: • If set to 0, then it signifies the fog server is in sleep mode.
• If set to 1, then it signifies the fog server is in active mode. 2) Free Bit: • If set to 0, then it signifies the fog server is fully occupied. • If set to 1, then it signifies the fog server can serve more requests. 3) Sum: It is the sum of the entries in countfid[ ] array maintained for each fog server i.e., the total number of requests served by a fog server.

PROPOSED SCHEME
In this section details of the proposed scheme are discussed.

Initial Assignment
For the initial assignment of all the local and global variables used in CFPM approach, Algorithm 1 is executed. end for 11: end function 12: function LOCAL-ASSIGN 13: for every fid do 14: for int i = 1 to do 15: countfid[i] = 0; 16: end for 17: end for 18: end function After each second GLOBAL-ASSIGN() and LOCAL-ASSIGN() functions are called to initialize the variables. For all fog servers mode bit in Flag[ ] variable is initialized at the time of fog server creation.

Request Sending Procedure
Whenever any user sends a request to a fog server or a fog server sends a request to another fog server, then Algorithm 2 is executed. Firstly it is checked whether there is any active free fog server available or not by accessing the mode bit and free bit of Flag[ ] variable for all fog servers. If for all fog servers free bit is 0 i.e., no fog server is free to serve the request, then the request is send to the cloud server.
Otherwise if for any fog server mode bit and free bit is 1, then it is checked whether the request is from user or neighboring fog server. If request is from user, then HANDLE-REQUEST(uid, need) function is called in which the user id of the user to be served is passed along with its current need. Otherwise if the request is from another fog server, then SERVE(uid, rem) function is called and, the user id of the user is passed for which the requested fog server was unable to serve along with the remaining need of the user.

Request Handling Procedure
Whenever any fog server receives a request from a user or any other neighboring fog server it runs Algorithm 3.
If the request is from user, then HANDLE-REQUEST(uid, need) function is called otherwise if the request is from another fog server, then only SERVE(uid, need) function is called.
In HANDLE-REQUEST(uid, need) function the account[uid] value of the user to be served is accessed. If the value is not null i.e, the user is not present in blacklist, then the fog server updates the account [uid] value by adding the current need of the user into it. Then it calculate the score[uid] value using Eq. 1. value, then ACTIVATE-ATTACKFOG(uid) function is called by the fog server to deal with the attacker who is trying to send more requests than its maximum requests. Otherwise if score[uid] value is less than or equal to the limit[uid] value, then fog server accepts the user request and calls SERVE(uid, need) function.
In SERVE(uid, need) function fog server updates the count[uid] value by adding the need value. It then calculates the total number of requests it is currently serving i.e., sum of the entries of its countfid[ ] variable.
All the fog servers have the same data processing speed so maximum requests it can serve per second i.e., would also be same that can be calculated using Eq.

2.
= ℎ ℎ A fog server is performing many functions so to prevent it from getting overloaded, the number of requests that it can serve should be restricted to a certain number. We are assuming that all the fog servers have a certain capacity depicting the number of requests it can serve in total. Using this constraint the CFPM approach balances the load among all the available fog servers. Further, the fog server compares its capacity with the total requests it has served. If its capacity has reached to its limit value i.e., if sum value is equal to , then it updates Flag[fid].sum equal to sum and sets its Flag[fid].free value to 0 and exit.
Otherwise if sum value is greater than , then it means the fog server is unable to serve the user completely. It then calculate the remaining number of requests and updates the count[uid] value equal to the number of requests it has served for the user. It updates Flag[fid].sum equal to and sets its Flag[fid].free value to 0. Further, it calls the SEND-REQUEST(uid, rem) function to request to another available fog server to serve the remaining need of the user.
But if sum is less than , then it signifies the normal execution where the fog server is able to serve the user completely or serves its remaining need completely. So in this it only updates Flag[fid].sum equal to sum.

Attacker Isolation Procedure
The proposed approach CFPM, uses Attack Fog servers to handle attack. Algorithm 4 is executed if ACTIVATE-ATTACKFOG(uid) function is called by any fog server. .mode value to 1. Further, ATTACKER-ISOLATION(uid, fid) function is called in which user id received in the function is declared as attacker and is added to the blacklist. The account value of the attacker is set to NULL to signify that it would no longer be served by any fog server.

Algorithm 4 Attack Fog Activation and Attacker Isola-
After that the attacker is migrated to the attack fog server and the activated fog server again sets its Flag [fid].mode value to 0, which results in isolation of the attacker.

RESULT AND ANALYSIS
In this paper a conceptual approach CFPM is proposed, in which DDoS attack is mitigated at fog layer using migration MTD technique with the aim of minimizing disruption to serving fog servers.
Various cases are possible based on the need of the users and current capability of the fog servers which are handled using the proposed algorithms. MATLAB is used to experimentally evaluate the CFPM approach.

Possible Scenarios
Considering a system with 'n', as the total number of clients where each client is allowed to send maximum 100 requests per second, assuming Reqsize to be 10 Mb. So max[i] entry and limit[i] for all users "i" would be 100 and 1000 respectively.
The network parameters that are used during the simulation are listed in Table 2. F1, F2 and F3 are the fog servers present at fog layer in which F1 and F3 are active fog servers while F2 is a sleeping fog server. All the fog servers are having data processing speed as 5 Gbps. So using (2) we can calculate maximum number of requests that a fog server can handle efficiently i.e., = 500.
For a user "i" the value of account[i] is updated at the time of request generation and further using (1) score[i] is calculated. Then score[i] is compared to limit[i], which results in following two possible cases 1 and 2: (1) Case 1: It is executed when the score[i] value is either equal to or less than limit[i] value. In this case SERVE() function is called which further compares sum value and value resulting in four possible cases -A, B, C and D: (a) Case A: Fig. 4 shows the case when the total number of requests served by a fog server is less than capacity of fog server. Fig. 5 Fig. 6 shows the case when the total number of requests served by a fog server is equal to capacity of fog server.  Table 4 depicting that it has reached its limit and can no longer serve any user.  (c) Case C: Fig. 8 shows the case when the total number of requests served by a fog server is greater than the capacity of fog server so the requests are served by some active fog servers collectively. In this case after serving users U1,U2,U3,U4 and U5, fog server F1 serves 450 requests in total and updates the variables accordingly and their comparison is as shown in Fig. 9. When U6 generates 100 requests then sum value is incremented to 550 which is greater than the capacity of fog server. So F1 server calculates the remaining need of user U6 which it was unable to serve and update its count [U6] value to the number of requests it has served for user U6. It then updates its Flag[F1].sum value to and Flag [F1].free value to 0 as shown in Table 5, which signifies that it has reached to its limit. Further, to serve the remaining need of the user U6 it calls SEND-REQUEST(U6, 50) function and sends request to another available fog server F3. F3 then serve user U6. In this case F1 and F3 fog servers collectively serves the need of user U6 as shown in Fig. 8.  (d) Case D: Fig. 10 shows the case when the total number of requests served by a fog server is greater than the capacity of fog server and all the active fog servers collectively are unable to serve the requests of the user completely. So to handle the case request is forwarded to cloud server. Fig. 11 shows the comparison of all the variables for all users. Final value of Flag[ ] variable for all fog servers is shown in Table 6 . This case is executed when the score[i] value is greater than limit[i] value for any user "i". Fig. 12 shows how the attacker isolation procedure works. Fig. 13     and number of fog servers needed (for case C, two fog servers would be needed and for case D even two fog servers would not suffice. Therefore remaining need is forwarded to cloud server).  Fig. 15 shows the evaluation of the system on implementation of CFPM approach before and after attack. A fog server can handle 500 requests per second so in one second 1000 requests can be served by two fog servers. In case there is no attacker present, after every second same number of requests are handled.

Evaluation
But if there is an attacker present in the system, say the attacker arrives at 4th second, then the fog server detect it by comparing certain values and call ACTIVATE-ATTACKFOG function.
Detection and function calling will take very less time (fraction of seconds), so for only that amount of time there would be a minor decrease in the number of requests served by fog server. After that fog server can process the request in the usual manner. As after detection of attacker, attack fog server is responsible for handling the attacker without any involvement of the detecting fog server. This evaluation proves that the proposed approach CFPM is very effective. Figure 15: Evaluation of the system before and after attack

CONCLUSION
For mitigating DDoS attacks in the cloud, different approaches were proposed in the literature. Fog computing and MTD has been used separately to address the security issues in cloud. MTD has never been applied to fog paradigm. After evaluating the effectiveness of MTD it has been observed that MTD can be applied to decentralized cloud infrastructure such as fog. This paper presents a proactive novel approach CFPM, that mitigates DDoS attacks in cloud using fog layer with applied migration MTD technique. CFPM detects and isolate the attacker based on certain network parameters at fog layer. By using migration MTD technique it migrates the attacker to attack fog server minimizing disruption to serving fog servers and requiring no involvement of cloud server. Attack fog server is an activated fog server which after migration of attacker again goes into the sleep mode resulting in the isolation of the attacker. CFPM approach is analyzed under different cases and performance of the system before and after attack is evaluated. CFPM uses the idea of load balancing to prevent fog servers from getting overloaded.