http://paidtoexist.

com/how-to-stay-hungry-and-see-your-goal-through-to-the-end/

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.M.T.Jagtap
(H.O.D)
Prof.N.S.Walimbe
(Principal)

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

Introduction

1.1

Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .01

1.2

Relevant Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .01

1.3

Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 02

1.4

Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 02

1.5

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

Validation of Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 05

2.3

Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .05

2.4

Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 05

2.5

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

System Analysis

4.1

Project

Scheduling

and

tracking

. . . . . . . . . . . . . . . . . . . . . . . ..13
4.1.1

Project Breakdown Structure (Analysis) . . . . . . . . . . . .13

4.1.2

Project Breakdown Structure (Implementation) . . . . . . 14

4.2

4.1.3

Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

4.1.4

Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1.5

Time Line Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

Analysis Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

4.2.1

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

4.2.2

Sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2.3 Activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Chapter 5

Risk Management

5.1

Risk Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2

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

Chapter 6

Application and Limitations

6.1

Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.2

Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.3

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 VMware vSphere,Workstation,Infrastructure 3
o 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

T2: Project
Planning

(D1,D2,D3)

(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

T22: Project
Estimation

T31:
Analysis

(D2,D4)
T32:
Design

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

T5.1:
Incomin
g traffic

T6: Traffic
Analysis

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

Days

Dependencies

Developers Assigned

T1

25

T1

D1,D2,D3

T2.

15

T1

D1,D3,D4

T3

T4

D1,D2,D3,D4

T4

10

T3,T5

D2

T5

30

T5

D1,D2

T6

15

D1,D4

T7

D2,D3

T8

60

D3,D4

T9

D2,D1

T10

10

D1,D3

T11

D2,D4

Table:4.2 Project scheduling table

Task

Plan Start

Actual

Plan Complete Actual

Plan Person Assign

Complete

Plan Start
T1

27/07/13

24/07/13

19/08/13

23/08/13

D1,D2

T2

22/08/13

25/08/13

20/09/13

20/09/13

D1,D2,D3,D4

T3

19/09/13

22/09/13

25/09/13

29/09/13

D1,D3

T4

28/09/13

30/09/13

15/10/13

D2,D3,D4

T5

17/10/13

26/10/13

D2,D3,D4

T6

30/11/13

19/12/13

D1,D2

T7

17/12/13

29/12/13

D3,D4

T8

30/12/13

10/01/14

D1,D2,D3

T9

13/01/14

20/03/14

D1,D2,D3,D4

T10

09/03/14

03/04/14

D1,D2

T11

08/04/14

22/04/14

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: Requirement Gathering and validation Completed.

M2: 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.

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

Category

Probability

Impact

System incompatibility

project

Less

Marginal

Project does not

Project

Medium

Marginal

Project

More

Marginal

Lack of training on tools

Project

More

Crucial

Insufficient response for

Technical

More

Crucial

complete in time
Lack of trained
developer

the system

Risk table along with RMMM

Risk Mitigation

Monitoring

R1

By setting up the Checking the alternative for

System incompatibility

Management

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

Check database

with proper knowledge

R4

Upgrade the system

Technical assistance

Searching
technologies

for

new

Chapter 6
Application and Limitations
6.1

Application
6.1.1

Industrial Application

6.1.2

Company Application

6.2 FUTURE SCOPE

Better attack detection and prevention. Defend against unknown attacks.

6.3

Limitation
6.2.1

Technical Problems

6.2.2

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_n

ameservers
[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
%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber
%3D6114645