Cloud computing performs data packet analysis to defend against DDOS attacks

In a cloud computing environment, Vm instances provide requested cloud services, and sometimes crash when receiving a large number of requests. This is a denial of service (DoS) attack. It is not accessible to normal users. DoS attacks usually use IP spoofing to hide the real attack source and make the attack source address look different.

In this article, we provide a method to defend against DDoS attacks in the cloud computing environment. This new hop count statistics filtering method provides an independent network in the cloud computing environment, it can easily prevent DoS solutions. This method can also reduce the availability of cloud services for normal users, reduce the number of updates, and save computing time. This method simulates the CloudSim Toolkit environment and corresponding results.

I. Introduction

Cloud computing is defined as a new form of computing to provide services on the Internet with dynamically scalable virtual resources. Advanced cloud computing technologies include low consumption, high availability, and scalable features.

DoS attacks do not aim to obtain illegal access by modifying data, but to crash the target service or the entire network, or disrupt normal user access. DoS attacks can be initiated from one or more sources. Multiple Source attacks are called Distributed Denial of Service (DDoS) attacks ).

When the operating system notices that a service has a high workload, it allocates more computing resources to cope with the increased load. Attackers can subscribe to a single point of failure (spof) and the basic system address to make the target service completely unavailable. The typical method of these attackers is flood attacks. They initiate a large number of meaningless packets to a certain service that is open on the cloud. Each request is processed by the Service to verify whether it is a legal request, which makes each total request occupy a certain amount of workload. Under flood attacks, Server DOS is usually caused.

Ii. Skip Calculation

Although the hop count information is not directly stored in the IP header, it can be calculated using the TTL field. TTL is an eight-bit field in the IP header. It is initially used to specify the maximum life cycle of each packet on the Internet. Each intermediate router reduces the TTL value by one before forwarding the IP packet to the next hop.

A. Extract the final TTL value

When a data packet arrives at the destination address to extract the TTL field value, this value is called the final TTL value. The challenge of hop count statistics is that only the final TTL value can be seen at the destination address. It would be easy to use the same TTL initial value for all operating systems, but they did not reach a consensus on the initial TTL value. In addition, since the operating system may change the given IP Address at any time, we cannot assume that each IP address uses a constant TTL initial value.

B. Study the initial value of TTL

According to the above, most modern operating systems only use several initial TTL values, such as 128, 32, 60, 64, 255, and. only a few Internet hosts are divided into more than 30 hops. Therefore, we can preliminarily determine that the initial TTL value of the data packet is the minimum value that the total TTL value of the above set is greater than the final TTL value.

For example, if the final TTL value is 112, then in the possible 128 and 255 options, the minimum value is 128 as the initial value. In this way, the final TTL value can be found. The initial TTL value can be calculated using the following method:

Initial TTL=32 if final TTL <=32Initial TTL =64 if 32<final TTL<=64Initial TTL =128 if 64<final TTL <=128Initial TTL =255 if 128<final TTL <=255

C. IP2HC table

The IP2HC table is a ing table between the source IP address of the data packet and the number of hops of the IP address. This is an index that matches the number of hops based on the source IP address.

Iii. DoS protection Algorithms

This algorithm uses the Skip filtering mechanism and provides a clear idea for implementation in a cloud computing environment.

This algorithm needs to continuously monitor data packets over the network on the cloud. Then, we extract the syn id, TTL value, and source IP information from the monitored TCP/IP packet. The entire operation of this algorithm to identify the tuples of each captured packet is as follows,

If the SYN mark is set and the source IP address exists in the IP2HC table, use the TTL value of the IP package to calculate the hop count. Check whether the number of hops is consistent with the number of hops stored. If they are inconsistent, update the value of the hop segment corresponding to this IP address.

If the SYN mark is set but the source IP address does not exist in the IP2HC table, calculate the number of hops and add the source IP address and the corresponding number of hops to the table as new entries.

If the SYN mark is not set and the IP address exists in the IP2HC table, the number of hops is calculated. If the number of hops does not match the number of hops stored in the IP2HC table, you can determine whether the package is false or the package is invalid.

If the SYN mark is not set and the source IP address does not exist in the IP2HC table, this indicates that the package is false, because each valid IP Address has an available TCP connection information record in the IP2HC table.

This detection algorithm extracts the source IP address and the final TTL value of each IP packet. The algorithm uses the estimation of the initial TTL value minus the final TTL value to obtain the intermediate hop count. The source IP address is used as the index of the table to retrieve the correct number of hops for this IP address. If a packet calculates the number of hops and matches the number of hops in the table, the package is credible, and the package is false.

Algorithm-1

Refer to the following identification:

synflag = Syn bit of TCP packet.mcount =malicious packet counter.Tf= final value of TTL.Ti=initial value of TTL.

The pseudocode is as follows:

1. For each packet
2. Set TTL = ExtractFinalValueOfTTL ();
3. // Get time-to-leave field of IP packet
4. Set srcIp = ExtractSourceIP ();
5. // Get source IP address from IP packet
6. Set synflag = ExtractSynBit ();
7. // Get Syn flag value from TCP packet
8. If (synflag is set)
9. {
10. If (establish_tcp_connection ())
11. // True when connection established
12. {
13. If (srcIp is exist in IP2HC table)
14. {
15. ComputePacket (srcIp, TTL, synflag );
16. // Function call which filter the spoofed
17. Packet
18. }
19. Else // new connection packet
20. {
21. Hc = compute1_count (TTL );
22. // Get hop-count value
23. NewEntryInTable (srcIp, Hc );
24. // Add entry into IP2HC table
25. }
26. }
27. Else
28. {
29. // Ignore packet
30. }
31. }
32. Else // synflag is not set
33. {
34. If (srcIp exist in IP2HC Table)
35. {
36. ComputePacket (srcIp, TTL, synflag );
37. // Function call which filter the spoofed
38. Packet
39. }
40. Else
41. {
42. 'Drop the packet '// Packet is spoofed
43. Mcount ++; // increment in malicious
44. Packet by 1
45. }
46. }
47. ComputePacket (string srcIp, int Tf, boolean
48. Synflag)
49. {
50. Hc = compute0000count (Tf); // get hop-count
51. Value
52. Hs = retreivestored1_count (srcIp );
53. // Get stored hop-count value
54. If (Hc! = Hs)
55. {
56. If (synflag is set)
57. {
58. UpdateTable (srcIp, Hc );
59. // Update hop-count value in IP2HC
60. Table
61. }
62. Else
63. {
64. 'Drop the packet '// Packet is spoofed
65. Mcount ++;
66. // Increment in malicious packet by 1
67. }
68. }
69. Else
70. {
71. 'Allow the packet '// packet is legitimate
72. }
73. }
74. Int compute0000count (int Tf)
75. {
76. Set Ti = InvestigateInitialTTL (Tf );
77. Return Ti-Tf; // return hop-count value
78. }

Iv. Simulation results

We simulated our algorithm on CloudSim Toolkit and reached 1000 pps on the cloud host. The experimental results are shown in table 1, which includes the packet SYN mark (Syn) and source IP address (Src). Syn = 0 indicates that the SYN mark is not set, syn = 1 indicates that the syn id has been set. Similarly, Src identifies whether the current source IP address is in the IP2HC table. Src = 0 indicates that the entry does not exist, and Src = 1 indicates that the entry exists.

The first experiment included 580 (337 + 243, see table 1) malicious packets and 173 new entries, and only 83 entries were updated. Instead, the packages to be updated in the table are 130 (Syn = 1 and Src = 1 ). Therefore, the number of valid packages (actually reduced) is 47 (130-83 ). The total number of updates in the table is reduced to 30.15% (the total number of reports allowed/The number of all packages), which is much better than the conventional method.

Table 2 is used to analyze the results of the calculation time when the input arrival rate of the simulated sample is 'A.

Table 2: sample input

Figure 3 shows the possible computing time saved by the proposed method, and the trend changes in samples of 2, 3, and 4. Sample 2 takes more time. Sample 3 and 4 depend on the fields of the receiving package. Computing time is a factor related to cloud network performance measurement. It improves the processing capability of VM instances and minimizes the loss of available resources.

Figure 3: computing time

V. Conclusion

Cloud computing is becoming more and more popular, but with the widespread use of the cloud, its security problems become more and more obvious. A major threat to operational security is distributed denial of service (DDoS) attacks or simpler Denial of Service (DoS) attacks ). To improve the availability of resources, it is necessary to provide a mechanism to defend against DDoS attacks. One of the defense methods is the hop filtering method (HCF ). This article shows a version of the hop count statistics method, not only to detect malicious packets, but also to update the IP address's hop count table mechanism. By analyzing the SYN mark of the TCP protocol, the number of updates is reduced, which saves the computing time.

Address: http://irnet.sg/irnet_journal/journal/IJCSEE/IJCSEE_Vol1Iss1/06.pdf