A Project Report On

New Approach DDoS attack Prevention using PFS

Submitted by Amey Vaidya Kashmire Rohit Wagh Shashikant Sampat
(B.E.COMP)

Guided by Prof.R.C.Gaikwad

Department Of Computer Engineering Pune Vidyarthi Grihas College of Engineering, Nashik University Of Pune Year: 2013-2014

PVGs COLLEGE OF ENGINEERING, NASHIK.

THIS IS TO CERTIFY THAT THE SEMINAR REPORT ON

NEW APPROACH TO DDOS ATTACK PREVENTION USING PFS

THIS IS TO CERTIFY THAT

Amey Vaidya Kashmire Rohit Wagh Shashikant Sampat Avhad Ravindra

UNDER THE GUIDANCE OF

Prof.R.C.Gaikwad
AS A PART OF PROJECT REPORT AS PRESCRIBED BY COMPUTER ENGINEERING

Prof.R.C.Gaikwad (Project Guide) Prof.N.S.Walimbe (Principal)

Prof.M.T.Jagtap (H.O.D)

ACKNOWLEDGEMENT

We convey our most sincere thanks to Guide Prof R.C.Gaikwad, for his guidance and effort throughout this Project report. I convey my most sincere heartfelt thanks to Head of the Department of Computer Engineering Prof.M.T.Jagtap for the motivation he had given as during the progress of Project Report. I also convey my heartfelt thanks to my parents and all the individuals who have helped us directly and indirectly to carry out this Project report successfully. Also thankful to all the Staff members.

Abstract
Distributed denial-of-service (DDoS) attacks continue to pose an important challenge to current networks. DDoS attacks can cause victim resource consumption and link congestion. A filter-based DDoS defense is considered as an effective approach, since it can defend against both attacks: victim resource consumption and link congestion. However, existing filter-based approaches do not address necessary properties for viable DDoS solutions: how to practically identify attack paths, how to propagate filters to the best locations (filter routers), and how to manage many filters to maximize the defense effectiveness. We propose a novel mechanism, termed PFS (Probabilistic Filter Scheduling), to efficiently defeat DDoS attacks and to satisfy the necessary properties. In PFS, filter routers identify attack paths using probabilistic packet marking, and maintain filters using a scheduling policy to maximize the defense effectiveness. Our experiments show that PFS achieves 44% higher effectiveness than other filter-based approaches. Furthermore, we vary PFS parameters in terms of the marking probability and deployment ratio, and find that 30% marking probability and 30% deployment rate maximize the attack blocking rate of PFS.

Contents

Chapter 1
1.1 1.2 1.3 1.4 1.5

Introduction

Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .01 Relevant Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .01 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 02 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 02 Design and Implementation Constraints . . . . . . . . . . . . . . . . . . 03
1.5.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 03

Chapter 2
2.1

Requirement Analysis

Requirement Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . .04

2.1.1 Normal Requirement . . . . . . . . . . . . . . . . . . . . . . . . . .04 2.1.2 Expected Requirement . . . . . . . . . . . . . . . . . . . . . . . . 04 2.1.3 Excited Requirement . . . . . . . . . . . . . . . . . . . . . . . . . 05

2.2 2.3 2.4 2.5

Validation of Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 05 Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .05 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 05 External Interface Requirements . . . . . . . . . . . . . . . . . . . . . . . 06

Chapter 3
3.1

System Design

Breakdown Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 07
3.1.1 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 07 3.1.2 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 07

3.2

Project Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1 Estimating Software cost . . . . . . . . . . . . . . . . . . . . . 11 3.2.2 Basic COCOMO Model . . . . . . . . . . . . . . . . . . . . . 11

Chapter 4
4.1

System Analysis

Project Scheduling and tracking . . . . . . . . . . . . . . . . . . . . . . . ..13

4.1.1 Project Breakdown Structure (Analysis) . .

. . . . . . . . . .13
4.1.2 Project (Implementation) . . . . . . 14 4.1.3 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . Breakdown Structure

. . . . . . . . . .15
4.1.4 Project Schedule . . . . . . . . . . . . . . . . . . .

. . . . . . . . . 16
4.1.5 Time Line Chart

...............

. . . . . . . . . . . . . .18

4.2 . . . . . . . . . . . . . . . . . . .19
4.2.1

Analysis Model . . . . . . . . . . . . . . . . . .

Use Case diagram . . . . . . . . . . . . . . . . . .

. . . . . . . . . 19
4.2.2 Sequence diagram . . . . . . . . . . . . . . . . . .

. . . . . . . . . 20
4.2.3 Activity diagram . . . . . . . . . . . . . . . . . . .

. . . . . . . . . 24

Chapter 5
5.1

Risk Management
Risk Identification . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . 25 5.2 . . . . . . . . . . . . . . . . . 26 Risk table along with RMMM plan . . . .

Chapter 6
6.1 6.2 6.3

Application and Limitations

Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Future Scope .

Chapter 7

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

CHAPTER I INTRODUCTION ________________________________________________________ 1.1 Problem Definition and Relevant Theory

Distributed denial-of-service (DDoS) attacks have recently again become severe due to the emergence of powerful DDoS attack automation tools and botnets. DDoS attackers have diverse goals, such as racketeering and political motivations.As an example of racketeering or extortion, the Itembay web site for trading game items was paralyzed by DoS attacks in September 2007.As an example of political motivation, in June 2009, media web sites in Belarus were under DDoS attack .The background of this attack was a suspected political issue between Georgia and Russia. Another political motivated incident occurred on July 7th, 2009, the DDoS attack in South Korea and the U.S., the so called 7.7 DDoS attack . The attacks targeted major portal sites in South Korea and several U.S. government agencies. Similarly, another DDoS

attack was launched on March 4th, 2011, which also targeted about 40 major web site in South Korea. These incidents imply that DDoS attacks are still prevalent in the current Internet. Many approaches have been proposed to defeat DDoS attacks. They can be categorized into three groups depending on the location of their deployment. First, a source-end defense scheme has the most effective benefits, because malicious traffic is blocked before spreading. However, a critical issue of this approach is how to deploy the scheme to the majority of end hosts. Second, a victim-end defense scheme, such as IDS/IPS (Intrusion Detection/Prevention System) ,and flow-based detection , protects a victims server side from DDoS attacks. However, it only covers the victims server or a small network area, and cannot counter a link resource attack (e.g., link congestion). Finally, an intermediate network defense scheme utilizes intermediate routers that can be the most effective locations to defend against both victim resource and link resource attacks .It installs filters to intermediate filter routers to block undesired flows.

1.2 Scope
The Area of our concept is in networking. In this system we are using Linux, Windows as an operating system platform , and placing multiple system in different LAN networks connected by routers or switch. One group in LAN will have both legitimate and malicious traffic. Our job is to find out and block the malicious one without banning all the clients from same LAN by using filter rules.

1.3 Objective
A service which enable to Network Administrator to, To actively monitor incoming and outgoing traffic. An User interface that will allow Network Administrator to

actively monitor all traffic in the network.

To Ability to block and prevent system from severe loss and downtime. Blocking DDoS attacks from infected machines without banning all the IP range.

High Availability of Web resource or service. Providing access to service or web resource without any interruption in the service.

Provide Real-time server monitoring.

1.4 Design and Implementation Constraint

1. The project contains modules which are to be implemented in windows so it works on PC which has windows as an operating system. 2. WAN/LAN connectivity. 3. To implement the DDoS prevention mechanism we would be having service which will be work as mediator. The most efficient way to deploy this technique is to create a windows service; this service will run in background and monitor the incoming traffic.

1.5 System Architecture

Chapter II Requirement Analysis

2.1 Requirement Specification

Requirement Analysis is a Software engineering task, which bridges the gap between system level software description and design model. The System description describes overall system functionally of the System including software, hardware, databases, human interfaces and other system elements and the software design mainly focuses on application architectural, user interface and component level designs. As per problem definition and scope of the project

discussed in the previous chapter, the requirement analysis from the point of software has been performed. The requirements have been elaborated in the following sections.

We divide the whole quality requirements in three parts: Normal Requirements. Expected Requirements. Excited Requirements.

2.1.1 Normal Requirements

These are the requirements that must be basically present in our system. N1: Record every incoming connection request N2: Real-time monitoring of network traffic N3: Minimum resource consumption while under attack

2.1.2 Expected Requirements

These requirements are implicit type of requirements. These requirements are not clearly stated but are needed to be present in system.

E1: User interface for Network administrator. E2: Rules enforcement on connection E3: Tracing source and destination IP , port , protocol ,packet

2.1.3 Excited Requirements

These requirements are used to make the end user more satisfied, the developer may include some unexpected requirements.

X1: Support for unknown attacks.

2.2

Validation of Requirements

In software project management, software testing, and software engineering, verification and validation (V&V) is the process of checking that a software system meets specifications and that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. Requirements are properties or attributes, which demonstrated in a way that how problems of real world can be. They are details of how the system should operate; constraints on the systems operations, and application domain information, requirements validation is concerned to check the requirements document for consistency, completeness, and accuracy. Usually, most of the bugs / errors exist in the software are due to incomplete, inaccurate, and inconsistent functional requirements. Figure, illustrates requirements validation process; where requirements documents, organizational knowledge and organizational standards are inputs. List of proposed problems and agreed actions for resolving these problems are outputs of the requirements validation process.

2.3

Software Requirements
o o VMware vSphere,Workstation,Infrastructure 3 Windows Server 2003 or higher

2.4

Hardware Requirements
a. For an x86-based computer:
i. One or more processors with a recommended minimum speed of 3.4 Ghz ii. 4GB of RAM

b. For an x64-based computer:

i. Two or more processors with a minimum speed of 3.4 gigahertz (GHz)

ii. 4 GB of RAM

Chapter III System Design

3.1 Breakdown Structure

3.1.1 System Design:

The web server is connected in LAN/WAN alike network. The scenario is number of pc's with different IP address in LAN will act as malicious users and others will acts as legitimate users. The malicious users will act will perform DDoS attacks on system and normal users will

try to connect to some web resource on server. Our job is to find out who are real users and blocks the attacks from malicious users.

3.1.2 Modules
Module I: Traffic Monitoring In this module we will be analyzing our incoming traffic and request made by number clients from different sets of IP ranges. We will actively monitoring the port , protocol,Source,Destination IPs,Packet.

Module II: Traffic Analyzing Incoming traffic is analyzed. Extract the packet header , Check the protocol associated , Compare with the rules, Check the source and destination add. If protocol is same.Check out the port if protocol is TCP.

3.1.3 Project Estimation

Estimation of KLOC:- 2.5 Efforts:- 8.371 PM Development Time:- 5.2591 month No. of person:- 3

3.2

Project Estimation

3.2.1 Estimating Software cost

This part describes about any software system required to purchase before actually starting the project implementation. Vmware Workstation 9 or later VirtualBox Visual Studio Professional 2008 or later

Administration
A web based application will be developed for the administration purpose. The module would consist of different login and screens and functionality for different login. The admin would be able to create, modify and delete accounts of the service incharge. The admin would also be able to check the status of the service incharge for every vehicle and also the work performed. He would also be able to check the final bill amount for each customer.

The admin would be provided with an interface for managing the company info.

Basic COCOMO Model :

The basic COCOMO model compute software development effort (and cost) as the function of program size expressed in estimated line of code

Effort (size) and (set of factors) Effort = [a + (b * ((Size)**c))] * [PROD(fs)]

where : Size is the estimated size of the project in loc or function points a, b, c, are coefficients derived from past data and curve fitting a = base cost to do business regardless of size b = fixed marginal cost per unit of change of size c = nature of influence of size on cost

fs are a set of additional factors, besides Size, that are deemd important PROD (fs) is the arithmetic-product of the fs

For the basic forms:

Effort = A * B *(size)C Time = D * (Effort)E Organic : A = 3.2 ; C = 1.05 ; D= 2.5; E = .38

Semidetached : A = 3.0 ; C= 1.12 ; D= 2.5; E = .35 Embedded : A = 2.8 ; C = 1.20 ; D= 2.5; E = .32

Calculation of E(effort):
E=a1 *(KLOC)^a2 E=3.0 *(2.5)^1.120 E=8.371 person-months

Calculation of T(duration):
Tdev = b1*(E)^b2 Tdev = 2.5*(8.371)^0.35 Tdev = 5.259 Months

Now we have N, Number of people = EFFORT/DURATION =E/D For our project N = 4 D=E/N D = 8.371/4 D = 2.092 Months Thus we require 2.092 months to complete the software part.

Chapter IV System Analysis

4.1 PROJECT SCHEDULING AND TRACKING

DDoS prevention system

T1: Communication (D1,D2,D3)

T2: Project Planning (D1,D3,D4)

T3: Modeling (D1, D2,D3,D4)

T4:Risk Anlysis&Maaagement (D2) ()

T5: Testing (D1,D2)

T11: Project Initiation

T12: Requireme nt Gathering

T31: Analysis

(D2,D4) T32: Design

T22: Project Estimation

T23: Project Scheduling

T1: Communication: Software development process starts with the communication between customer and developer. Requirements are gathered according to need of the project.

T2: Planning: It includes complete estimation and scheduling and tracking.

T3: Modeling: It includes detailed requirement analysis and project design.

T4: Risk Management It involves identifying the risk during project development & according to that, managing the risk which affects the project development.

T5: Testing After completing all the phases different testing technique is applied at the time of designing of the system.

4.1.2 DETAIL PROJECT WORK BREAKDOWN STRUCTURE (DETAIL WITH TASKS)

DDoS prevention System

T5: Traffic Monitoring

T6: Traffic Analysis

T5.1: Incomin g traffic

T5.2: Outgoing Traffic

T6.1: Packet Extraction

T6.2:
Packet Rules Checking

Figure 4.2: Project Breakdown Structure (Implementation)

4.1.3 Tasks:
As per the various modules described above, by applying the concept of modularity we can divide the project work in following tasks and subtasks. Each of the following tasks is so basic that it can be easily understood and implemented. T1. Communication T1.1.Requirement Gathering T2. Project Planning T2.1. Project Estimation T3. Modeling T3.1. Analysis T3.2. Design T4. Risk Analysis and Management Analysis T5. Traffic Monitoring T5.1. Incoming traffic monitoring T5.2. Outgoing Traffic monitoring T6. Traffic Analysis T6.1. Packet Extraction T6.2. Packet rules checking

4.1.4 Project Schedule

The table describes the schedule for the project development. It also highlights all the tasks to be carried out along with their duration, dependencies, and developers assigned to accomplish those tasks.

Table:4.1 Project Schedule

Task T1 T2. T3 T4 T5 T6 T7 T8 T9 T10 T11

Days 25 15 8 10 30 15 8 60 8 10 2

Dependencies T1 T1 T4 T3,T5 T5 -

Developers Assigned D1,D2,D3 D1,D3,D4 D1,D2,D3,D4 D2 D1,D2 D1,D4 D2,D3 D3,D4 D2,D1 D1,D3 D2,D4

Table:4.2 Project scheduling table

Task

Plan Start

Actual Plan Start

Plan Complete Actual Complete

Plan Person Assign

T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11

27/07/13 22/08/13 19/09/13 28/09/13 17/10/13 30/11/13 17/12/13 30/12/13 13/01/14 09/03/14 08/04/14

24/07/13 25/08/13 22/09/13 30/09/13

19/08/13 20/09/13 25/09/13 15/10/13 26/10/13 19/12/13 29/12/13 10/01/14 20/03/14 03/04/14 22/04/14

23/08/13 20/09/13 29/09/13

D1,D2 D1,D2,D3,D4 D1,D3 D2,D3,D4 D2,D3,D4 D1,D2 D3,D4 D1,D2,D3 D1,D2,D3,D4 D1,D2 D1,D2,D3,D4

Each task is assigned to different team member, where D1: Amey Vaidya

D2,D4: Rohit Kashmire D3: Shashikant Sampat Wagh .

4.3 Time line chart :

M1: M2: :

Requirement Gathering and validation Completed. Project Planning and System Design Completed. Indicates M1 & M2 are Milestones

4.2

Analysis Model

4.2.1 Use case Diagram

A use case involves a sequence of interactions between the initiator and the system, possibly involving other actors.

Figure 4.4: Use Case Diagram for DDoS Prevention syste

4.2.2 Sequence Diagram

A sequence diagram is a graphical view of a scenario that shows object interaction in a time-based sequence what happens first, what happens next. Sequence diagrams establish the roles of objects and help provide essential information to determine class responsibilities and interfaces. This type of diagram is best used during early analysis phases in design because they are simple and easy to comprehend. Sequence diagrams are normally associated with use cases.

sd sequnce diagram DDos Prevention System Client Web server

Connection()

Monitors incoming traffic()

[If Legitimate packet]() Legitimate packet

Drop packets()

Acknowledgement()

Figure 4.5: Sequence diagram DDoS Prevention system

4.2.3 Activity Diagram

An activity diagram illustrates the dynamic nature of a system by modeling the flow of control from activity to activity.

Figure 1: Activity Diagram of CEFC

Chapter V Risk Management

5.1 Risk Identification
Risk Identification is systematic attempt to specify threats to the project plan.i.e. Estimates, schedule, resource loading etc. There are two types of risks for each of the categories that have been 1. Generic risks. 2. Product specific risks. Generic risks are potential threat to every software project. Product specific risks can be identified only by those with a clear understanding of the technology, the people and environment that is specific to the software that is to be built. One method for identifying risks is to create a risk checklist in the following generic sub categories: 1. Product size: risk associated with the overall size of the software to be built or modified. 2. Business impact: risks associated with constraints imposed by management or the marketplace. 3. Process definition: risks associated with the degree to which the software process has been defined and is followed by the development organization. 4. Technology to be built: risks associated with the complexity of the system to be built and the newness of the technology that is packaged by the system. 5. Staff size and experience: risks associated with the overall technical and project experience of the software engineers who will do the work. Customer related risk:

If server is under heavy ddos attack then customer may or may not be able to use web resource on server. Technical risk: If IP spoofing attack performed then some of the IPs may get blocked.

5.2 Risk Projection

Preparing risk table Risks System incompatibility Project does not complete in time Lack of trained developer Lack of training on tools Insufficient response for the system Project Technical More More Crucial Crucial Project More Marginal Category project Project Probability Less Medium Impact Marginal Marginal

Risk table along with RMMM Risk Mitigation R1 System incompatibility Monitoring Management

By setting up the Checking the alternative for software tools during software tools implementation

R2

Ensure the planning of the project

Conduct reviews

Ensures that the modules are developed in timely manner.

R3

Ensure that the developers are Consider experience with proper knowledge

Check database

R4

Upgrade the system

Technical assistance

Searching technologies

for

new

Chapter 6 Application and Limitations

6.1 Application
6.1.1 6.1.2 Industrial Application Company Application

6.2 FUTURE SCOPE

Better attack detection and prevention. Defend against unknown attacks.

6.3

Limitation
6.2.1 6.2.2 Technical Problems System should always be online

CHAPTER VII CONCLUSION

____________________________________________________________

The system will work on minimization DDoS attack impact on web server. This will allows legitimate users to have access to web resource. It will stop the Link congestion and resource depletion of victim, by early detection and prevention mechanism. Packet based Filtering helps to eliminate these problems but its effectiveness improves when multiple filtering are scheduled and system installed on destination for more effective approach.

Even today many commercial web services are continued to face challenges of such attack every day or so. Placing right system will increase their effective against it.

References
____________________________________________________________
[1] http://en.wikipedia.org/wiki/Denial-of-service_attack [2]http://en.wikipedia.org/wiki/Distributed_denial_of_service_attacks_on_root_na meservers [3] http://en.wikipedia.org/wiki/Firewall_%28computing%29 [4] http://manuals.kerio.com/kpf/en/ch08s01.html [5]http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6114645&url=http%3 A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D611464 5