Threshold Based Kernel Level HTTP Filter (TBHF) for DDoS Mitigation

Published Online November 2012 in MECS (http://www. DOI: 10.5815/ijcnis.2012.12.03

Distributed Denial of Service (DDoS) attack uses a large number of computers to cause a coordinated DoS attack against a targeted web server. Flooding attack is usually caused by continuously sending multiple requests to bring down the targeted server. This eventually fills the server’s buffer space. Once the buffer memory is full no further connections can be made to the server, thus making the service unavailable. This scenario is attained by misusing the URL shortening service which eventually leads to the formation of HTTP botnet [1]. URL shortening service is a technique, used in the World Wide Web (WWW) to substantially shorten a lengthy URL into a shorter one while redirecting the user to the requested webpage. This is achieved by referring HTTP redirect information from the available database of the URL shortener tool. This redirect information is required for redirecting the shortened URL to the requested original URL. Thus attacks could be launched using shortened URL. On making use of shortened URL service the user requested web page gets loaded in the web browser along with malicious scripts downloaded from the attacker. This is done by misusing the html iframe tag [2]. Thus HTTP GET flooding attack is initiated in the background by using the client side scripts downloaded from the attacker without interrupting the user’s browser activity [3]. The attack will continue as long as the web page is active and it will not leave any trace of code unless the cache of the browser is not cleared on the client side.

The rest of the paper is organized as follows: Related work is discussed in Section II. Section III discusses the Threshold Based Kernel Level HTTP Filter (TBHF) algorithm in detail. HTTP GET attack generation and analysis are explained in Section IV. Performance analysis of TBHF is discussed in Section V and finally, Section VI concludes the paper.

• II.    Related Work

Client side prevention of browser initiated flooding attacks is mainly done by Client side Caching optimization and implementation of the Human Interaction Proof (HIP) protocol [4]. In client side, a cache is maintained at browser level. All HTTP GET requests which are sent for the first time are cached in the local persistent storage [5]. Subsequent requests to the same

URL are served from the local cache. However, this method fails when the attacker requests different URLs, thereby making the technique ineffective.

Another method is Completely Automatic Public Turing tests to tell Computers and Humans Apart (CAPTCHA) [6] where the user is puzzled with an image, which contains randomly skewed alpha numeric characters. This is used to distinguish between human and bot behaviour. In the normal scenario when a host is making a large number of requests to a specific URL, the

User Space

Network Interface

Figure.1 Block schematic of Threshold Based Kernel Level HTTP Filter system detects an anomaly and redirects the user to a CAPTCHA page. If the user is able to complete the challenge, then the actual URL is served again. In the case of a bot requesting the URL, the CAPTCHA cannot be cracked, leading to inaccessibility of the URL. But in the current HTTP-GET attack scenario, the host requests different pages under the same server. Hence, no anomaly is raised and the CAPTCHA page is not served thereby surpassing the technique which leads to the flooding attack. Techniques such as blackholing are used by ISPs to mitigate DDoS attacks, where in traffic to a specific IP is blocked [7]. The blocked traffic may also contain genuine packets thus making the service unavailable to the legitimate user. Access Control Lists (ACLs) [8] are altered in order to stop users from participating in DDoS attack. But this technique becomes inefficient when attackers spoof genuine IP address.

• III.    Proposed Work

• A.    Threshold Based Kernel Level HTTP Filter (TBHF)

The block diagram in Fig. 1, shows the different modules of the proposed TBHF, viz., Traffic capture, Parameter extractor, and the Analyzer module. First the packets are captured at kernel level by the traffic capture module. The output of the traffic capture module, the outbound TCP packets alone, are filtered and sent to the parameter extractor module which extracts the features such as remote IP address and the arrival time of packets. Then the packets are subjected to the Analyzer which decides whether to drop or allow the packets into the network based on the threshold set.

The analyzer module contains an IP frequency list to store the number of occurrences of individual IP address over a period of time. It checks the frequency of each IP address in IP frequency list and further decides whether to block or allow the packets.

The flow chart for the basic functioning of TBHF is given in Fig. 2. Threshold value as mentioned in section IV is set to restrict the number of HTTP requests to a particular IP address for a given period of time. Based on the parameters extracted from the packets ∆T values are calculated, which gives the time interval between current and previous instance of a packet for a particular IP

Figure.2 Functioning of TBHF address. Based on the threshold set if the value of the IP frequency list exceeds the threshold value, then the packets are dropped else they are allowed into the network.

• B.    Proposed TBHF Algorithm

The proposed TBHF algorithm goes through the following steps: The network traffic (which includes all varieties of packets) is given as input to the TBHF. In Step 1 the outbound HTTP GET request packets are filtered and it is sent through the other modules for further processing. In Step 2, the parameters such as remote IP address and arrival time of packets are extracted from the filtered packets. The presence of the extracted IP address is checked in the IP address list and accordingly the IP frequency list is updated. If the IP address is not found in the IP address list, then the new IP address and its corresponding arrival time are stored in the IP address list. Then in Step 3, the difference in time (interval) between two packets of same IP address (∆T) is calculated. If the time interval is less than 1 second, then the IP frequency list value for the corresponding IP address is incremented by 1. Otherwise the IP address is added to the IP frequency list. The time interval to refresh list is set to 1 second and also the IP frequency list values are reset to null after the elapse of every second. The threshold value (N) is set to 20 based on the experiments conducted in our lab, viz., only 20 HTTP GET requests are allowed to a particular IP in one second. The HTTP GET packets are allowed to an IP address till the corresponding IP frequency list value reaches N. If the IP frequency list value for an IP address exceeds N, then the packets are dropped. The value of N was set based on our research experiments conducted in various environments and their results are listed in Table 1.

Step 1:

Input: Network Traffic

IF (Outbound packets)

THEN

IF (Packet == HTTP GET)

THEN

Step 2 :

// ExtractParameters

// IP 1 , IP 2 , …, IP i - remote IP address

// t 1 , t 2 , …, t i - Arrival time of packets

//IPAddrList – IP Address List

IPAddrList[IP i ][0] = IP i ;

IPAddrList[IP i ][1]=t i ;

Step 3:

// ∆T - Difference in time between two instance of same IP address

// N - Threshold value

//IPFreqList – IP Frequency List

∆T = t2(IPAddrList[IP i ][1]) – t1 (IPAddrList[IP i ][1]);

IF (∆T < 1 second)

THEN

IPFreqList[i]++;

IF (IPFreqList [i] < N)

THEN

Allow packet to Network;

ELSE

Drop packet;

END IF

END IF

ELSE

Allow packet to Network;

END IF

END IF

• IV.    Work Done

• A. HTTP GET attack generation

The Fig. 4 shows the log from Web Console tool in Mozilla Firefox on the Victim machine. Mark A shows the Link which is shortened using genuine URL shortener service provided by Google namely Mark B shows the Genuine URL, to which the user is redirected, to get the user requested web page.

Fig. 5 shows the log from Web Console using Mozilla Firefox during attack scenario. The Mark A in Fig. 5 shows the shortened URL that was provided by the attacker URL Shortening Service. In a genuine case when user clicks the link provided by shortened URL service, the user is redirected to the user requested web page but in case of an attack scenario, when a user clicks a malicious link provided by the attacker the user requested web page is displayed by exploiting the HTML iframe tag. Simultaneously GET requests are generated to victim server [9]. The Mark B shows the victim server IP address to which the HTTP GET Flooding attack has been initiated. The Mark C shows the dynamic resource name hich is intended to overcome the browser level caching mechanism. Dynamic resource names are randomly generated unique IDs to access the resources from the web server.

WAMP server was set up in attacker side to host the malicious web page. On clicking the malicious link, the script to generate HTTP GET attack was downloaded from attacker web server to the victim browser. The script did not install any malicious software in the victim machine rather used the browser script engine to generate the malicious requests.

Figure.3 Graph analysis of HTTP GET attack using Wireshark

TABLE 1 – HTTP GET ATTACK RESULTS *

Web browsers used	Total No. of Packets (for 30 second)	HTTP GET requests (for 30 second)	Average HTTP GET request (per second)
Safari	32184	15891	529
Google Chrome	59507	29708	990
Mozilla Firefox	87442	43654	1455

* Results shown for 30 second time interval during attack period

Firefox ’

IwSlidin window protocol - Wikipedia, th..,

ite

P Clear x

Position- Filter

■ Net -

A

В

■ CSS - ■ JS - ■ Web Developer *

Create account Д Log in

^ XXI ^

Article Talk

Read Edit View history

Search

WikipediA

Tie Free Encyclopedia

Sliding window protocol

From Wikipedia, the free encyclopedia

Main page Contents Featured content Current events Random article Donate to Wikipedia

Interaction

Help

About Wikipedia Community portal Recent changes Contact Wikipedia

►

Toolbox

►

PrinVexport

Languages

This article includes a list of references, but its sources remain unclear because it has insufficient inline citations. Please help to improve this article by introducing more precise citations. (August 201 o)

A sliding window protocol is a feature of packet-based data transmission protocols. Sliding window protocols are used where reliable in-order delivery of packets is required, such as in the Data Link Layer (OSI model) as well as in the Transmission Control Protocol (TCP).

Conceptually, each portion of the transmission (packets in most data link layers, but bytes in TCP) is assigned a unique consecutive sequence number, and the receiver uses the numbers to place received packets in the correct order, discarding duplicate packets and identifying missing ones. The problem with this is that there is no limit of the size of the sequence numbers that can be required.

By placing limits on the number of packets that can be transmitted or received at any given time, a sliding window protocol allows an unlimited number of packets to be communicated using fixed-size sequence numbers. The term '"window" on transmitter side represents the logical boundary of the total number of packets yet to be

Figure.4 Web Console log using Mozilla Firefox during normal scenario

Firefox

► \J http://10.150.42/abcd

<• w 101.5042/abcd

[™ -

Google

P Clear

Position* Filter

■ CSS * ■ JS * О Web Developer •

16 16 16 16 16 16 16 16 16 16 16 16 :16 16 16 16 16 16 16 16 16	14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14 14	15.465 15.475 15.486 15.496 15.586 15.517 15.554 15.554 15.565 15.589 15.684 15.628 15.656 15.665 15.682 15.788 15.717 15.755 15.751 15.767 13.784	GEl[http	//10.1.50.42/abcd|	[HTTP/1.1 288 OK 16irs] ----(a)
			GET http	//en.wikipedia.org/wiki/Sliding Window Protocof [HTTP/1.0 200 OK 265ms]
			GET http	//10.4.5.205/?hKFD=843475158 [HTTP/1.1 200 OK 93ms]
			GET http	//10.4.5.205/?hKFD=4130143671 [HTTP/1.1 200 OK 94ms]
			GET http	//bits .wikimedia. org/en .wikipedia ....skins.vector&only= st yles&skin=vectors*
			GET http	//bits. wikimedia. org/en .wikipedia. ...modules=site&only=styles&skin=vector&*
			GET http	//bits , wikimedia . org/en . wikipedia ....les=startup&only=scripts&skin = vector&*
			GET http	//bits .wikimedia. org/en .wikipedia ....kins. vector&only=scripts&skin=vector&*
			GET http	//bits .wikimedia. org/en .wikipedia. ...odules=site&only=scripts&skin=vectors*
			GElfhttp	//10.4.5.205j ?hKFD-964O991794 [HTTP/1.1 200 OK 62ms] -----(В )
			GET http	//10.4.5.205/?hKFD=2106335786 [HTTP/1.1 200 OK 63ms]
			GET http	//10.4.5.205/?hKFD=3897772424 [HTTP/1.1 200 OK 63ms]       —
			GET http	//10.4.5.205E?hKFD=7185667378|		[IITTP/1.1 289 OK 02ts] ------( C )
			GET http	//10.4.5.205/?hKFD=1813026438 [HTTP/1.1 200 OK 62ms]
			GET http	//10.4.5.205/?hKFD=3075510368 [HTTP/1.1 200 OK 63ms]
			GET http	//10.4.5.205/?hKFD=7350609323 [HTTP/1.1 200 OK 63ms]
			GET http	//10.4.5.205/?hKFD=1626354068 [HTTP/1.1 200 OK 62ms]
			GET http	//10.4.5.205/?hKFD=1619674885 [HTTP/1.1 200 OK 62ms]
			GET http	//10.4.5.205/?hKFD=2748207345 [HTTP/1.1 200 OK 94ms]
			GET http	//10.4.5.205/?hKFD=4279164591 [HTTP/1.1 200 OK 94ms]
			GET http	//10.4.5.205/?hKFD=6103134000 [HTTP/1.1 200 OK 94ms]

WikipediA

Hie Free Encyclopedia

Create account * Log in

Article

Talk

Read

Edit

View history

Search                     Q

Sliding window protocol

From Wikipedia, the free encyclopedia

Main page

Contents

Featured content

Current events

Random article

Donate to Wikipedia

••■ Interaction

Help

About Wikipedia

This article includes a list of references, but its sources p remain unclear because it has insufficient inline •      citations. Please help to improve this article by introducing more precise citations. (August 2010)

A sliding window protocol is a feature of packet-based data transmission protocols. Sliding window protocols are used where reliable in-order delivery of packets is required, such as in the Data Link Layer (OSI model) as well as in the Transmission Control Protocol (TCP).

Conceptually, each portion of the transmission (packets in most data link layers, but

Figure.5 Web Console log using Mozilla Firefox during attack scenario

Figure.6 Statistics of HTTP GET attack before installing TBHF

TABLE 2 – PERFORMANCE ANALYSIS**

PACKET CAPTURE STATISTICS IN VICTIM MACHINE (30 SECONDS)
Total No. of Packets		OUTBOUND TRAFFIC
		Total No.	To target server	HTTP GET PACKETS
				Total No.	To target server
Before	87442	43692	43685	43656	43654
After	371	132	112	83	79

** Results shown for 30 second time interval before and after loading TBHF filter

Figure.7 Statistics of HTTP GET attack after installing TBHF

Figure.8 Suppression of HTTP GET attack traffic after TBHF installation

3436-5E’VBNM,alysis

When observed using Wireshark, an enormous amount of HTTP GET requests were generated to the target IP address in a very short span of time which usually does not happen in a genuine case. Based on this observation, a threshold was set to ascertain the number of HTTP GET requests generated to a particular IP address in a certain time period.

• V.    Performance Analysis

• A.    Experimental setup

The effective working of the proposed system was tested by generating HTTP GET attack in Local Area Network (LAN) and using the TBHF driver for its mitigation. HTTP GET attack was generated using client side scripting in victim web browser. Traffic analysis was done with respect to HTTP packets using Wireshark. Based on the obtained results, the parameters to be set for filtering out malicious HTTP GET packets using TBHF were decided. The same was implemented and the performance of the TBHF was studied.

• B.    Detection module at victim machine for kernel level packet filtering

Sun virtual box with Windows 7 installed in it was made the victim. The developed TBHF driver was installed on the victim machine. A GUI called Open System Resources (OSR), was used to load or unload the packet filter in the victim machine. The loading or unloading of the filter can also be done manually which involves making registry changes and then starting the filter through command prompt.

• C.    Results

A real time HTTP GET attack was generated in the victim machine. Table 1 shows the web traffic that was generated using three different browsers, viz., Safari, Google Chrome, and Mozilla Firefox.

Table 1 comprises of the total number of packets, number of HTTP GET packets sent to the targeted web server, and the average number of HTTP GET requests sent per second. The variation in the request generation depends on the capability of the browser script engine and system configuration. A Core 2 Quad processor with 4 GB of RAM running Windows 7 Operating System (OS) was made the victim machine.

Once the attack was initiated, traffic was captured using Wireshark and is shown in Fig. 3. The graph in Fig. 3 showing the attack packets, reveals the presence of continuous bombarding of HTTP GET packets from victim machine to the target server.

Fig. 6 shows the statistics of HTTP attack before installing the TBHF filter driver. In Fig. 6, the highlighted portion shows the packet count of HTTP GET packets sent from the victim machine to the target server before loading the TBHF filter driver for the interval of 30 seconds.

Fig. 7, shows drastic drop in the http packet count between the victim and target server over the same period of time after installing the TBHF filter driver. Thus from Fig. 7, it is evident that the developed filter was able to mitigate the DDoS attack.

The performance analysis of the proposed TBHF was done by measuring the number of outbound packets in the victim machine before and after loading the filter. Table 2 shows the number of HTTP GET requests sent to the target server before and after the filter installation. It is evident from the 2nd row that the flooding packets generated to target server were dropped by TBHF. The accuracy in terms of mitigating the DDoS attacks by TBHF works out to be 99.82% which is calculated as the ratio of the number of HTTP GET attack packets blocked to the total number of HTTP GET attack packets generated (43575 / 43654 * 100).

Fig. 8, shows the decline in the attack traffic after driver installation. X-axis shows the time in seconds and Y-axis shows the number of HTTP GET packets. It is observed that after the driver installation there is a drastic drop in flow of attack traffic which signifies that the HTTP GET attack is mitigated.

• VI.    Conclusion

Application layer attack has become a major threat to the internet in today’s world. The focus of this paper was to come out with an effective solution for the detection and prevention of clients from inadvertently taking part in such attacks. Accordingly, a Threshold Based Kernel Level HTTP Filter (TBHF) was proposed and implemented in Windows 7 OS. Experiments were conducted by generating HTTP GET attacks and using TBHF for its mitigation. It was evident that the TBHF suppressed the flooding packets and thus prevented the client system from taking part in such an attack. The ongoing work is to implement TBHF in other OS and mobile platforms.

Acknowledgement

The authors thank the National Technical Research Organization (NTRO), New Delhi, Government of India for sponsoring this research work under the Collaborative Directed Basic Research in Smart and Secure Environment project.