DENIAL OF SERVICE ATTACKS AND SOLUTION

 

 

Sujatha Gnaneswaran

E-mail:sgnanesw@cs.kent.edu

Prepared for Prof. Javed I. Khan
Department of Computer Science, Kent State University

 

 

 


ABSTRACT:

 

Denial of Service attacks is a fast growing trend of attacks on the computer industry. They can disable computers and to a certain extent the network in which the computer is connected or in some cases, the entire organization. Denial of service attacks come in a variety of forms and aim at a variety of services. Defense against these attacks has been a much tedious task. My paper studies the existing DoS and DDoS attacks and some solutions in the present scenario.

 

Keywords: DoS, IP spoofing, Reflector attacks, Smurf attacks, DDoS.

 

 

TABLE OF CONTENTS

 

Introduction

 

What is DoS

What is DDoS

Modes of Attack

 

 

Defensive measures

Summary

Scope of Survey

References

 

 

 

 


INTRODUCTION

 

What is DoS

 

DoS is the acronym for Denial of Service. Denial of Service is a virulent relatively new type of Internet attacks where a group of users of a specified service deny service to another group of users such that the former group makes the specified service unavailable to the latter group for a period of time which exceeds the intended and advertised service time. This loss of service may range from the inability of some particular network service such as an e-mail to that of an entire browser having to go out of operation.

 

 

 

                     

                                                                            

 

 

 

What is DDoS

 

A Distributed Denial of Service (DDoS) attack uses many computers to launch a coordinated DoS attack against one or more targets.

 

 

 

 

 

                                                     

                             

                                                                           

 

 

 

Modes of Attack

 

 

The most obvious attack is the attack on the server, which may result in denial of services to the client. Another form of attack is the attack on the network. This causes it not to transmit the messages necessary to give the required service either to all clients or to a class of clients. A less obvious attack is to cause it to send messages which it should not - as for example the simulation of a disabled client. A third possibility is to flood the network with enough messages to impede its proper use. Some of the common attacks are flooding attacks, reflector attacks, and amplified reflector attacks.

 

 

Flooding Attacks

 

 

Flooding is the overwhelming of a network or an individual computer with messages consuming its resources. Flooding is further classified as:

 

TCP SYNC attacks

SMURF attacks

 

 

 

TCP SYNC attacks

 

Any system providing TCP based services to the Internet community are potentially vulnerable to this Denial of Service attack. Here, the attacking system initiates a connection by sending a SYN message (a message that begins the client-server "handshake") with a return address other than its own (This is achieved by IP spoofing) to the server. The server allocates a buffer for the request and acknowledges the SYN message by sending SYN-ACKNOWLEDGE, or SYN-ACK, message to the machine specified in SYN message that is of course not the IP address of the attacking machine. Thus, the server never receives the final ACK and the connection is never fully connected. These uncompleted connections are called "pending connections," and are written to a buffer of limited size Eventually, as the attacking machine creates an ever increasing number of pending connections, the buffer described above will eventually fill up and overflow. The number of pending connections that a system can handle simultaneously varies, depending on the operating system. Eventually the target machine will stop accepting connections. In effect, the machine is now closed to all new incoming connections.

 

 

 

                 

                       

Smurf Attacks

 
The "smurf" attack, named after its exploit program, is one of the most recent in the denial of service attacks.  The attacker sends a large amount of ICMP echo request packets to IP broadcast addresses, all of it having a spoofed source address of a victim.  All the hosts which are alive each pick up a copy of the ICMP Echo request datagram and send an ICMP Echo Reply datagram back to what they think is the source. On a multi-access broadcast network, there could potentially be hundreds of machines to reply to each packet. Not only can the attacker cause problems for the target host, the influx of traffic can in fact be so great as to have a seriously negative effect on the upstream network(s) from the target.
 
 
 
 
 
 
                                   
 
 
 
 
 
Reflector Attacks
 

 

In a distributed denial-of-service (DDOS) attack, the attacker compromises a number of slaves and installs flooding servers on them, later contacting the set of servers to combine their transmission power in an orchestrated flooding attack. The use of a large number of slaves both augments the power of the attack and complicates defending against it. Attackers can render distributed denial-of-service attacks more difficult to defend against by bouncing their flooding traffic off of reflectors; that is, by spoofing requests from the victim to a large set of Internet servers that will in turn send their combined replies to the victim.

 

 

                                                    

 

DEFENSIVE MEASURES

Ingress/Egress Filtering

Hop Count Filtering

Secure Overlay

DoS Resistant Architecture

 

Ingress/Egress Filtering

Ingress filtering is from the point of view of the Internet. Here an Internet Service Provider (ISP) filters out packets with illegitimate source address, based on the ingress link by which the packet

enters the network. In contrast, egress filtering is from the point of view of the customer network and the filtering occurs at the exit point of a customer domain. Here a router checks whether the source addresses of packets actually belong to the customer’s domain. Packets with invalid source addresses are dropped.

 

Hop Count Filtering

Hop count is calculated from the Time to Live (TTL) field. The initial TTL value minus the final TTL value at a node gives the hop count at that node. So a node if it wants to inspect for spoofed packets may extract the source IP address and the final TTL value from each IP packet. Final TTL value minus the initial TTL value gives the hop count. The source IP address serves as the index for into the table to retrieve the correct hop count for this IP address. If there is a computational disparity between the two calculated hop counts then the packet is likely to be spoofed. Hop Count filtering is successful against most spoofed DoS attacks.

 

Secure Overlay

The portion of the network immediately surrounding the target to be protected allows only packets with approved source addresses. These set of addresses are picked from among a secure overlay network. Any transmission wishing to traverse the overlay must first be validated at secure overlay access points. Traffic is tunneled securely on the overlay to approved locations which then forwards the validated traffic, through the filtering routers to the destination.

 

DoS Resistant Architecture

Separate Client and Server addresses

The aim is to allow clients to initiate connections to servers, but not to allow clients to initiate connections to clients, nor servers to initiate connections to servers. The benefits of this depend on where the restriction is enforced. Even if it were only enforced by the recipient, this would immediately reduce the threat from worms. A worm would have to spread from client→server→client, exploiting two separate vulnerabilities. This greatly slows the worm  because the server→client phase depends on clients choosing to contact an infected server. Very fast spreading worms would no longer be possible. Worms that attempt to spread via contagion are still possible, but are significantly more likely to be spotted in the client→server phase In addition, many reflection DoS attacks on servers are prevented. A reflection attack on a server would  require server→client→server communication, and most clients are not going to respond to a new connection request from a server.

 

Non Global Client Addresses

 

This prevents distributed DoS attacks on the client or its access network unless each attacking host can figure out a workable address to route traffic towards the client. One way to allocate client addresses in a non-global manner would be for the source address to be constructed domain-by-domain as the packets travel from client to server. On entry to a domain, a local routing ID (indicating the next domain toward the client) would be pre-pended to the source address.

Packets being forwarded back towards the client would then be forwarded by the usual longest-prefix-match forwarding mechanisms within each domain (in this case the prefix is the local ID for

the next domain). As the packet leaves each domain heading back towards the client, the local ID is removed. The goal is that even if one malicious server in the Internet knows a client’s address, no-one elsewhere in the Internet who is given that address can easily deduce a workable client address to reach the client from their location. The simple prepending scheme above provides this protection to some degree, but it is possible that more security is required. This can be achieved at the expense of additional forwarding cost by encrypting the client address before prepending the local ID in the client-to-server path, and decrypting it in the return path after removing the local ID.

 

State Setup Bit

 

Packets that cause a connection setup must set up a state setup bit. So packets requesting for a connection without this bit set would simply be discarded.  We also ensure that server addresses cannot setup this bit. So malicious servers who take place in a reflector attack with this bit setup will simply be discarded. Some sites may also rate limit at their outgoing firewalls the number of packets with state setup bits

 

 

 

 

 

 

Summary

 

 

 

Proposed Solutions

Attack Type

Reactive/Proactive

Router based/Victim based Defense

Research

Work Done

 

Ingress/Egress Filtering

TCP Sync, Smurf, Reflector

Reactive

Router Based

Implemented in the present day Internet

 

HCF

Smurf, Reflection

Proactive

Victim Based

Experimental evaluation By implementation in Linux Kernel

 

SOS

TCP Sync, Smurf, Reflector

Proactive

Both

Evaluated using Mathematical model

 

DoS Resistant Architecture

TCP Sync, Smurf, Reflector

Proactive

Both

Implemented using C macros on GCC

 

DoS Resistant Software

TCP Sync, Smurf, Reflector

Proactive

Victim Based

 

Experimentally tested using Flash Web Server

 

 

 

 

 

 

 







 

 

Scope of the Survey

I have based my survey on the current available information on DoS and DDoS. The resources I made use of were mostly research papers from the ACM Digital Library. The paper aims at a detailed study of the existing approaches. Though the present trend has not conquered all DoS/DDoS attacks, it is worthwhile to note that some approaches like the DoS resistant architecture and software are capable if implemented in the present Internet.

 

 

 

 

References

SOS: Secure Overlay Services

Angelos D. Keromytis, Vishal Misra, Dan Rubenstein

ACM SIGCOMM Computer Communication Review, Proceedings of the 2002 conference on Applications, technologies, architectures, and protocols for computer communications

 

Steps towards DoS Resistant Internet Architecture

Mark Handley, Adam Greenhalgh

Proceedings of the ACM SIGCOMM workshop on Future directions in network architecture

 

Hop Count Filtering an Effective Defense against Spoofed DDoS Traffic

Cheng Jin, Haining Wang, Kang G. Shin

Proceedings of the 10th ACM conference on Computer and communications security

 

Defensive Programming: Using an annotation toolkit to build DoS Resistant Software

Xiaohu Qie, Ruoming Pang, Larry Peterson

ACM SIGOPS Operating Systems Review

 

Other Relevant Links

http://www.physnet.uni-hamburg.de/physnet/security/vulnerability/synk4.html
 
http://www.pentics.net/denial-of-service/white-papers/smurf.cgi
 
http://www.ceenet.org/workshops/lectures2000/Gorazd_Bozic/SI-CERT_CEENet_2000-1/sld027.htm
 
http://www.sensecurity.org/downloads/ICMP_Whitepaper.doc