Enhanced Random Time Queue Blocking using Efficient Active Queue Management for Detection and Mitigation of Low Rate Denial of Service Attacks against Iterative Application Servers

Abstract

The main aim of Denial-of-Service (DoS) attacks is either partially or completely, disturbing the newlineavailability of a system or network. Currently, Low-Rate DoS (LRDoS) attacks have merged as novel strategies newlineto deny the network services. It is a mixed approach between flooding and vulnerability attacks. These attacks newlinetake advantage of certain vulnerability in the victim to reduce the traffic rate directed to the victim. Low-Rate newlineDenial of Service attacks against iterative application servers (LoRDAS) attack is one such kind of attacks. The newlinemain aim is to reduce the availability of a server to process legitimate user s request. newlineBased on the Radware s global application and network security report, 45.96% of attacks are Denial of newlineService attacks. The first low rate denial of service attack was detected by Asta network in the year 2001. A newlinereliable report of low-rate DoS attacks in China appears in 2004 when www.qq.com is attacked by low-rate newlineDoS attack. There are four defense mechanisms available in the literature [36]. Out of which, Random Service newlineTime (RST), Random Answer Instant (RAI), Random Time Queue Blocking (RTQB) and Improved Random newlineTime Queue Blocking (IRTQB) are developed to handle LRDoS attacks against iterative application servers. newlineIn Random Service Time (RST), when a service request is completed, the service module does not newlineimmediately send the answer to the client. It waits for some random time called extra delay. After expiration of newlinethis delay, the answer is sent to the corresponding client and the next request is fetched from the queue. The newlinelimitation of this method is extra delay and the impact of the server is changed. newlineIn Random Answer Instant (RST), when a service request is completed, the service module does not newlineimmediately send the answer to the client. It waits for some random time called extra delay. After expiration of newlinethis delay, the answer is sent to the corresponding client. During this delay time, the service module fetches the newlinenext request from the queue and continues its process.