BwDDoS attack & defense project Report

8/17/2019 BwDDoS attack & defense project Report

1/44

Bandwidth Distributed Denial of Service: Attacks & Defense

DEPARTMENT Of CSE, MCET 1

1. INTRODUCTION

Internet services are indispensable and yet, vulnerable to Denial of Service (DoS)

attacks, and especially to Distributed Denial of Service (DDoS) attacks. DDoS attacks,

which many attacking agents cooperate to cause excessive load to a victim host, service,

or network. DDoS attacks have increased in importance, number and strength over the

years, becoming a major problem. Furthermore, significant growth in size of attacks

and in their sophistication is reported. BW-DDoS employed relatively crude, inefficient,

‘brute force’ mechanisms; future attacks may be significantly more effective, and hence

much more harmful. To meet the increasing threats, more advanced defenses should be

deployed. This may involve some proposed mechanisms (not yet deployed), as well as

new approaches.

A “denial-of-service” attack is characterized by an explicit attempt by attackers to

prevent legitimate users of a service from using that service. Examples include attempts

to “flood” a network, thereby preventing legitimate network traffic attempts to disrupt

connections between two machines, thereby preventing access to a service attempts to

prevent a particular individual from accessing a service attempts to disrupt service to a

specific system or person Denial-of-service attacks come in a variety of forms and aim

at a variety of services. There are three basic types of attack: consumption of scarce,

limited, or non-renewable resources by sending illegitimate traffic there by denying

service to the legitimate users.

BW-DDoS Attacks

BW-DDoS attacks are usually generated from a large number of compromised

computers (zombies or pup- pets). According to recent surveys, BW-DDoS attacks are

the most frequently used DoS method.1,2 Most BW- DDoS attacks use a few simpleideas, mainly flooding (many agents sending packets at the maximal rate) and reflection

(sending requests to an uncompromised server with a spoofed sender IP address,

causing the server to send longer response packets to the victim). Table 1 summarizes

the different attacks we discuss in this article.

Flooding attacks have created significant damage, because attackers were able to use a

sufficient number of agents to cause massive bandwidth consumption leading to packet

loss. However, it seems that, gradually, attackers are adopting more complex and

effective attacks. For example, the largest attacks reported in recent years consisted of


2/44



100 Gbps in 2010, 60 Gbps in 2011 and 2012, and 300 Gbps in 2013.2,3 The 2010,

2011, and 2013 attacks were DNS reflection and amplification attacks. In 2012, the

largest attack targeted the DNS infrastructure. Researchers have discovered even more

effective BW-DDoS techniques, for instance, with higher amplification factors.

Inducing a significant percentage of packet loss is no easy task. Generally, packet

delivery probability is the ratio between the available bottleneck link bandwidth and the

attack rate. However, as Figure 1 shows, congestion or (small) packet loss probability

causes dramatic performance degradation in TCP connections. This performance

degradation is due to TCP’s congestion control mechanism, which drastically reduces

TCP’s sending rate upon packet loss. Thus, BW-DDoS damage might be worse than the

mere consumed bandwidth.

1.1 NEED FOR THE NEW SYSTEM

To identify Bandwidth Distributed Denial of Service (BW-DDoS) attacks, which

disrupt the operation of the network infrastructure by causing congestion or an

excessive amount of traffic. BW-DDoS attacks can cause loss or severe degradation of

connectivity, between the Internet and victim networks or even whole autonomous

systems, possibly disconnecting whole regions of the Internet.

1.2 DETAILED PROBLEM DEFINITION

The recent occurrences of DDoS attacks make it an important issue to deal with. Of the

various technologies available for its prevention, network filtering is implementable,

effective and reliable method. We thus implement filtering methods to avoid BwDDoS

attacks.

1.3 EXISTING SYSTEM

A number of IP traceback approaches have been suggested to identify attackers and

there are two major methods for IP traceback, the probabilistic packet marking (PPM)

and the deterministic packet marking (DPM). Both of these strategies require routers to

inject marks into individual packets. The DPM strategy requires all the Internet routers

to be updated for packet marking. Moreover, the DPM mechanism poses an

extraordinary challenge on storage for packet logging for routers. Further, both PPM

and DPM are vulnerable to hacking, which is referred to as packet pollution.


3/44



Disadvantages

PPM strategy can only operate in a local range of the Internet (ISP network), where

the defender has the authority to manage. ISP networks are generally quite small,

and cannot traceback to the attack sources located out of the ISP network.

Because of the vulnerability of the original design of the Internet, we may not be

able to find the actual hackers at present.

1.4 PROPOSED SYSTEM

BW-DDoS attack, where the attacker sends as many packets as possible directly to the

victim, or from an attacker controlled machines called ‘zombies’ or ‘bots’.The simplest

scenario is one in which the attacker is sending multiple packets using a connectionless

protocol such as UDP. In UDP flood attacks, the attacker commonly has a user-mode

executable on the zombie machine which opens a standard UDP sockets and sends

many UDP packets towards the victim.for UDP floods, and many other BW-DDoS

attacks, the attacking agents must have zombies, i.e., hosts running adversary-controlled

malware, allowing the malware to use the standard TCP/IP sockets.The first attempts to

avoid detection, and the second tries to exploit legitimate protocol behavior and cause

legitimate clients/server to excessively misuse their bandwidth against the attacked

victim.

Network-Level Defense Mechanisms

BW-DDoS defense mechanisms focus on several types of schemes, including detecting,

filtering, absorbing, and cooperating. We surveyed defense schemes of both deployed

and academically proposed mechanisms. Here, we discuss different defense

mechanisms, their deployment location in the network, and the infrastructure adaptation

and type of cooperation they require, if any. Note that many defense mechanisms rely

on the ability to differentiate between attacks and legitimate flows; however, in this

article, we don’t discuss differentiation techniques as they have been surveyed before.11

Table 3 summarizes the defense mechanisms.

Response Mechanism

We consider four types of defense mechanisms: filtering, rate limiting, detouring and

absorbing, and breakthrough.

Filtering. Assuming the offending flows are identified, they can be filtered out.

Filtering can take place in various network locations: close to the destination, at the


4/44



core (that is, in routers), or close to the source. Usually, to be effective in BW-DDoS

mitigation, filtering must occur before the congested link, because the victim usually

isn’t in a position to hold back the attack.One example of filtering is preventing source

IP spoofing. RFCs 2827 and 3704 recommend that ISPs employ ingress filtering andfilter packets with IP addresses external to that network. Many ISPs do this; however,

approximately 15 percent of Internet addresses can still send spoofed packets.2,6 LOT

(Lightweight Opportunistic Tunneling) is another solution to mitigate spoofing by

opportunistically establishing tunnels between gateways and adding a random tag to

tunneled packets, making it difficult for attackers to guess the correct tag value.12

Packets not carrying the correct tag are discarded, preventing the spoofing of packets

that originate from incorrect networks.

Additional filtering mechanisms include access control lists (ACLs), Remote-Triggered

Blackhole (RTBH), and firewalls. ACLs are router mechanisms that allow or deny

matching flows. They’re often configured manually; however, some intrusion

prevention systems can configure ACLs automatically. Each ACL entry takes a

significant amount of memory and some time to process, so routers should limit ACL

rules in both number and processing time. Memory and CPU use increase as more ACL

entries are used, which might be an additional target for DDoS — not necessarily bandwidth based.

RTBH (RFC 5635) uses the router’s forwarding tables such that all traffic to the victim

or from attacking sources is forwarded to a “blackhole,” completely denying access to

the target. RTBH uses a small amount of memory and its processing is faster than ACL.

However, RTBH filtering is significantly more aggressive and might help an attacker

disconnect its victim from its sources and/or destinations, thereby potentially achieving

the goal with little resources.

Rate limiting. In contrast to completely blocking the attacking flows, rate-limiting

schemes let the offending flows transmit their typical rate or obey some other limit.

Researchers proposed rate limiting at routers in several forms, including capabilities,

packet tagging, and scheduling based. Capabilities are tokens issued by the destination

(server) to the source (client). Capabilities inform the source, and more importantly the

routers en route, that the destination is willing to accept traffic from this source. The

issued capabilities are attached to packets the source sends, allowing routers en route to


5/44



identify and prioritize approved flows. Note that packets without capabilities aren’t

filtered; instead, they get lower delivery probability, which effectively limits their rate

during attack periods. SIFF (Stateless Internet Flow Filter) proposed stateless

capabilities wherein capabilities are calculated using (keyed) hash.13

Routers check and prioritize flows carrying verified capabilities. TVA (traffic validation architecture)

keeps a (small) state in routers and lets servers request specific restrictions per flow.

Capabilities based solutions assume that victims will authorize only legitimate sources

and won’t cooperate with attackers. Deployment of capabilities-based solutions requires

changes to both end hosts and routers.

Detouring and Absorbing.

Absorption overlays are overprovisioned with bandwidth and can absorb BW-DDoS

attacks. They construct a perimeter around the victim server that only selected nodes

can penetrate; unauthorized traffic is filtered. Cloud (practical) or overlay (academic)

solutions route traffic via the cloud or overlay, which “scrubs” the attack flows.

Absorption clouds and overlays were designed specifically to mitigate BW-DDoS and

were investigated in several works, such as SOS (Secure Overlay Services). 18 Note that

overlay solutions usually introduce new protocols and hence typically require updating

host software. Other solutions, mainly those deployed, make no protocol

Breakthrough. The final category of BW-DDoS mechanisms are those that use

aggressive clients to break through the congestion. Aggressive clients use TCPfriendly

protocols as long as they can sustain enough goodput. When TCP’s goodput drops

below some threshold, aggressive clients commence using protocols without congestion

control, such as UDP, thereby exploiting the real network delivery probability. An

important design goal of aggressive clients is to avoid self-generated BW-DDoS

attacks.

Defense Mechanism Location

The various defense mechanisms can be deployed at different network locations. Some

are deployed close to the destination, that is, near the victim. Note that defense

mechanisms close to the destination might get a good idea about some of the attack’s

properties, but they might not be well-positioned to mitigate BW-DDoS attacks because

many packets are discarded near the victim due to the exhausted resources. Hence,

many defense mechanisms try to mitigate attacks closer to the source. Router or


6/44



backbone-based defense mechanisms are usually located near an overprovisioned link

and try to ensure that traffic reaching the victim originates mostly from legitimate

sources. Similarly, source-based defense mechanisms try to prevent attackers from

sending excessive traffic, especially during BW-DDoS attacks.

Additional deployment locations are “in the cloud” and overlay networks. In such

solutions, traffic is routed via an overprovisioned cloud service that scrubs the attacking

flows and forwards only legitimate traffic to the victim.

Advantages

Bandwidth based identification

Easily identifies attacker High attack detection


7/44



2. ANALYSIS

System analysis is a general term that refers to an orderly, structured process for

identifying and solving problems. We call system analysis process lifecycle

methodology, since it relates to four significant phases in the lifecycle of all business

information system. The life cycle is divided into four phases.

Study Phase

Design Phase

Development Phase

Implementation Phase

Analysis implies the process of breaking something into parts so that the whole may be

understood. The definition of the system analysis includes not only the process of

analysis but also that of synthesis, which implies the process of putting together to form

a new whole.

All activities associated with each life cycle phase must be performed, managed and

documented. Hence we define system analysis as the performance, management,

documentation of the activities related to the life cycle phases of a computer-based

business system. In the study phase a detailed study of the project is made and clear picture of the project is in mind. In the design phase the designing of the input, output

and table designs are made. Development phase is where the physical designing of the

input-output screens and coding of the system is done. System implementation actually

implements the system by making necessary testing.

2.1 FEASIBILITY STUDY

The feasibility of a project can be ascertained in terms of technical factors, economicfactors, or both. A feasibility study is documented with a report showing all the

ramifications of the project. In project finance, the pre-financing work (sometimes

referred to as due diligence) is to make sure there is no "dry rot" in the project and to

identify project risks ensuring they can be mitigated and managed in addition to

ascertaining "debt service" capability.


8/44



Technical Feasibility:There are a number of technical issues, which are generally

raised during the feasibility stage of the investigation. A study of function, performance

and constraints gave me the ability to achieve acceptable system.The software required

for this system is:

JDK 1.5

Financial Feasibility:

The analysis raises financial and economic questions during the preliminary

investigation to estimate the following:

The cost to conduct a full systems investigation.

The cost of hardware and software for the class of application of

the project being considered.

To be judged feasible, a proposal for the specific project must pass all these

tests, otherwise it is not considered as a feasible project. I gathered the details regarding

the financial aspects incorporated in the system to make it cost efficient.

Operational Feasibility.

Suppose for a moment that technical and economic resources are both judged adequate.

The systems analyst must still consider the operational feasibility of the requested

project. Operational feasibility is dependent on human resources available for the

project and involves projecting whether the system will operate and be used once it is

installed. If users are virtually wed to the present system, see no problems with it, and

generally are not involved in requesting a new system, resistance to implementing the

new system will be strong. Chances for it ever becoming operational are low.

2.2 PROJECT MANAGEMENT

Construction of normal Dataset

Local Data Collection

Training normal data using cluster mechanism

Testing Phase


9/44



2.2.1 Construction of normal Dataset

The data obtained from the audit data sources mostly contains local routing information,

data and control information from MAC and routing layers along with other traffic

statistics. The training of data may entail modelling the allotment of a given set of

training points or characteristic network traffic samples.

2.2.2 Local Data Collection

A normal profile is an aggregated rule set of multiple training data segments. New and

updated detection rules across ad-hoc networks are obtained from normal profile. The

normal profile consists of normal behaviour patterns that are computed using trace data

from a training process where all activities are normal. During testing process, normal

and abnormal activities are processed and any deviations from the normal profiles are

recorded.

2.2.3 Training normal data using cluster mechanism

It calculates the number of points near each point in the feature space. In fixed width

clustering technique, set of clusters are formed in which each cluster has fixed radius

also known as cluster width in the feature space.

2.2.4 Testing Phase

The testing phase takes place by comparing each new traffic samples with the cluster set

to determine the anonymity. The distance between a new traffic sample point and each

cluster centroid is calculated. If the distance from the test point s to the centroid of its

nearest cluster is less than cluster width parameter w, then the traffic sample shares the

label as either normal or anomalous of its nearest cluster. If the distance from s to the

nearest cluster is greater than w, then s lies in less dense region of the feature space, and

is labelled as anomalous.

2.3 REQUIREMENT ANALYSIS

Requirements analysis in systems engineering and software engineering,

encompasses those tasks that go into determining the needs or conditions to meet for a

new or altered product or project, taking account of the possibly

conflicting requirements of the various stakeholders, analysing, documenting, validating

and managing software or system requirements. Requirements analysis is critical to the


10/44



success of a systems or software project. The requirements should be documented,

actionable, measurable, testable, traceable, related to identified business needs or

opportunities, and defined to a level of detail sufficient for system design. Requirements

analysis in systems engineering and software engineering, encompasses those tasks thatgo into determining the needs or conditions to meet for a new or altered product or

project, taking account of the possibly conflicting requirements of the

various stakeholders, analyzing, documenting, validating and managing software or

system requirements. Requirements analysis is critical to the success of a systems or

software project. The requirements should be documented, actionable, measurable,

testable, traceable, related to identified business needs or opportunities, and defined to a

level of detail sufficient for system design.


11/44



3. DESIGN

3.1 INPUT DESIGN

Input design converts user-oriented inputs to computer-based format, which requires

careful attention. The collection of input data is the most expensive part of the system in

terms of the equipment used and the number of people involved. In input design, data is

accepted for computer processing and input to the system is done through mapping via

some map support or links.Inaccurate input data is the most common cause of errors in

data processing. The input screens need to be designed very carefully and logically. A

set of menus is provided which help for better application navigation. While entering

data in the input forms, proper validation checks are done and messages will be

generated by the system if incorrect data has been entered.

3.2 OUTPUT DESIGN

Outputs are the most important and direct source of information to the user and to the

department. Intelligent output design will improve the systems relationship with the

user and help much in decision-making. Outputs are also used to provide a permanent

hard copy of the results for later uses. The forms used in the system are shown in the

appendix. The Output Design is another very important phase. The outputs are mainly

used to communicate with a user, processing the input data given by the user etc. A

quality output is one, which meets the requirements of the end user and presents the

information clearly. In any system results of processing are communicated to the users

and to other through outputs. In the Output design it is determined how the information

is to be displayed for immediate need and also hardcopy out. Efficient, intelligible

output design should improve the system’s relationship with the user and the help in

decision making.

3.3 DATA FLOW DIAGRAM

Data Flow Diagrams represent one of the most ingenious tools used for structured

analysis. It has the purpose of clarifying system requirements and identifying major

transformations that will become programs in system design. It is the major starting

point in the design phase that functionally decomposes the requirements specifications


12/44



down to the lowest level of detail. In the normal convention a DFD has four major

symbols.

Symbols used in DFD are:

Square, this defines source or destination of data.

Arrow, which shows data flow

Circle, which represents a process that transforms

incoming data into outgoing flow

Open rectangle, which shows a data store

Level 0

Level 1


13/44



Level 2

Level 3


14/44



4. SYSTEM MODELLING

4.1 UML DIAGRAM


15/44



5. CODING

Coding is the software activity where the detailed design specification is implemented

as source code. Coding is the lowest level of abstraction for the software development

process. It is the last stage in decomposition of the software requirements where module

specifications are translated into a programming language.

Typical tasks for Coding

Traceability analyses

Source Code to Design Specification(and vice versa)

Test Cases to Source Code and to Design Specification

Source Code and Source Code Document Evaluation

Source Code Interface Analysis

Test Procedure and Test Case Generation

5.1 PROGRAMMING LANGUAGE USED

JAVA

Java is an object-oriented multithread programming languages .It is designed to be

small, simple and portable across different platforms as well as operating systems.

FEATURES OF JAVA

Platform Independence

The Write-Once-Run-Anywhere ideal has not been achieved (tuning for different

platforms usually required), but closer than with other languages.

Object Oriented

Object oriented throughout - no coding outside of class definitions, including main().

An extensive class library available in the core language packages.

Compiler/Interpreter Combo

Code is compiled to byte codes that are interpreted by a Java virtual machines

(JVM).


16/44



This provides portability to any machine for which a virtual machine has been

written.

The two steps of compilation and interpretation allow for extensive code

checking and improved security.

Robust

Exception handling built-in, strong type checking (that is, all data must be

declared an explicit type), local variables must be initialized.

Several features of C & C++ eliminated:

No memory pointers

No preprocessor

Array index limit checking

Automatic Memory Management

Automatic garbage collection - memory management handled by JVM.

Security

No memory pointers

Programs run inside the virtual machine sandbox.

Array index limit checking

Code pathologies reduced by

o

Byte code verifier - checks classes after loading

o Class loader - confines objects to unique namespaces. Prevents loading a

hacked "java.lang.SecurityManager" class, for example.

o Security manager - determines what resources a class can access such as

reading and writing to the local disk.

Dynamic Binding

The linking of data and methods to where they are located is done at run-time.

New classes can be loaded while a program is running. Linking is done on the

fly.


17/44



Even if libraries are recompiled, there is no need to recompile code that uses

classes in those libraries.

This differs from C++, which uses static binding. This can result in fragile

classes for cases where linked code is changed and memory pointers then point

to the wrong addresses.

Good Performance

Interpretation of byte codes slowed performance in early versions, but advanced

virtual machines with adaptive and just-in-time compilation and other

techniques now typically provide performance up to 50% to 100% the speed of

C++ programs.

Threading

Lightweight processes, called threads, can easily be spun off to perform

multiprocessing.

Can take advantage of multiprocessors where available

Great for multimedia displays.

Built-in Networking

Java was designed with networking in mind and comes with many classes to

develop sophisticated Internet communications.

5.2 CODES

Client

package ui;

import java.awt.Dimension;

import java.awt.event.ActionEvent;

import java.awt.event.ActionListener;

import java.awt.event.WindowEvent;

import java.awt.event.WindowListener;

import java.io.IOException;

import java.io.ObjectOutputStream;


18/44



import java.net.InetAddress;

import java.net.UnknownHostException;

import java.util.Iterator;

import java.util.Map.Entry;

import java.util.Set;

import java.util.TreeMap;

import java.util.Vector;

import javax.swing.JButton;

import javax.swing.JFrame;

import javax.swing.JLabel;

import javax.swing.JOptionPane;

import javax.swing.JScrollPane;

import javax.swing.JTable;

import javax.swing.JTextArea;

import javax.swing.JTextField;

import javax.swing.UIManager;

import javax.swing.UIManager.LookAndFeelInfo;

import javax.swing.UnsupportedLookAndFeelException;

import javax.swing.table.DefaultTableModel;

import logic.Multicst;

import logic.Receiver;

import logic.SocketListener;

import support.Constants;

import support.SocketConnection;

import support.Utils;

import voc.SearchVO;

public class ClientForm implements ActionListener,WindowListener

{

SocketListener socketListener;

private String nodeName = "";

private JFrame jFrame;

private JTextField jTextField;

private JButton jButtonSend;

public JTextArea jTextAreaRes;


19/44



private JScrollPane jScrollPane;

private String port;

private String ipAddress;

private String msg = "";

private Multicst multicst;

Receiver receiver;

private JButton jButtonSearch;

private JTable jTableRouting;

private DefaultTableModel modelRouting;

JScrollPane jScrollPane2;

JLabel jLabel3;

Vector routInfo = new Vector();

SocketConnection socketConnection = new

SocketConnection();

public ClientForm() {

try {

for (LookAndFeelInfo info :

UIManager.getInstalledLookAndFeels()) {

if ("Nimbus".equals(info.getName())) {

UIManager.setLookAndFeel(info.getClassName());

break;

}

}

} catch (UnsupportedLookAndFeelException e) {

// handle exception

} catch (ClassNotFoundException e) {

// handle exception

} catch (InstantiationException e) {

// handle exception

} catch (IllegalAccessException e) {

// handle exception

}

nodeName = Utils.NodeName(Constants.TYPE_CLIENT);

port = Utils.generatePortNo();


20/44



socketListener = new SocketListener(port, this);

try {

ipAddress =

InetAddress.getLocalHost().getHostAddress();

} catch (UnknownHostException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

receiver = new Receiver(this, this.nodeName);

multicst = new Multicst(Constants.MULTICAST_NEI +

this.nodeName + ":"

+ port + ":" + ipAddress,

Constants.INET_ADDRESS_NEIGHBOR,

Constants.MULTICAST_NEI);

}

public void designForm() {

jFrame = new JFrame(nodeName);

jFrame.setLayout(null);

jFrame.setVisible(true);

// jFrame.setSize(700, 700);

/* Search Query */

JLabel jLabel = new JLabel("Search :");

jLabel.setBounds(10, 30, 150, 40);

jFrame.add(jLabel);

jTextField = new JTextField();

jTextField.setBounds(10, 80, 150, 40);

jFrame.add(jTextField);

jButtonSend = new JButton("Send");

jButtonSend.setBounds(10, 130, 100, 40);

jButtonSend.addActionListener(this);

jButtonSearch = new JButton("Search Router");

jButtonSearch.setBounds(140, 130, 140, 40);

jButtonSearch.addActionListener(this);

jFrame.add(jButtonSearch);

jFrame.add(jButtonSend);


21/44



/* Response */

JLabel jLabel2 = new JLabel("Response :");

jLabel2.setBounds(20, 180, 100, 40);

jFrame.add(jLabel2);

jTextAreaRes = new JTextArea();

jScrollPane = new JScrollPane(jTextAreaRes);

jScrollPane.setBounds(20, 230, 660, 400);

jFrame.add(jScrollPane);

/* Routing Table */

jLabel3 = new JLabel("Routing Info :");

jLabel3.setBounds(320, 30, 150, 40);

jLabel3.setVisible(false);

modelRouting = new

DefaultTableModel(Constants.routerInfo, 0);

jTableRouting = new JTable(modelRouting);

jScrollPane2 = new JScrollPane(jTableRouting);

jScrollPane2.setVisible(false);

jScrollPane2.setBounds(320, 70, 300, 100);

jFrame.add(jLabel3);

jFrame.add(jScrollPane2);

screenCenter();

}

public void screenCenter() {

Dimension dim = jFrame.getToolkit().getScreenSize();

int screenWidth = dim.width;

int screenHeight = dim.height;

int frameWidth = screenWidth / 3;

int frameHeight = screenHeight / 3;

jFrame.setSize(700, 700);

jFrame.setLocation((screenWidth - frameWidth) / 2,

(screenHeight - frameHeight) / 2);

}

public static void main(String[] args) {


22/44



ClientForm clientForm = new ClientForm();

clientForm.designForm();

}

@Override

public void actionPerformed(ActionEvent e) {

// TODO Auto-generated method stub

if (e.getSource() == jButtonSearch) {

modelRouting.setRowCount(0);

jTextAreaRes.setText("");

// modelRouting.r

jTableRouting = new JTable(modelRouting);

jScrollPane2.setVisible(false);

jLabel3.setVisible(false);

new JProgressBarForm().designForm(jFrame, this);

TreeMap nodeConfig =

receiver.nodeConfig;

Set set =

nodeConfig.entrySet();

Iterator iter =

set.iterator();

while (iter.hasNext()) {

Entry mapEntry =

iter.next();

String nameTmp = mapEntry.getKey();

String nameConfig = mapEntry.getValue();

if

(nameTmp.contains(Constants.TYPE_ROUTER)) {

routInfo.add(nameTmp);

String[] nameInfo =

nameConfig.split(":");

routInfo.add(nameInfo[0]);

routInfo.add(nameInfo[1]);

modelRouting.addRow(routInfo);

// modelRouting.


23/44



}

}

// jScrollPane2.setVisible(true);

// jLabel3.setVisible(true);

} else if (e.getSource() == jButtonSend) {

if (routInfo.size() != 0) {

SearchVO searchVO = new SearchVO();

searchVO.setQuery(jTextField.getText());

searchVO.setClientName(this.nodeName);

searchVO.setClientPort(port);

searchVO.setClientIp(ipAddress);

searchVO.setTo(Constants.TYPE_ROUTER);

String searchKey = jTextField.getText();

ObjectOutputStream oo =

socketConnection.SocketSend(

routInfo.get(1),

routInfo.get(2));

try {

oo.writeObject(searchVO);

oo.close();

} catch (IOException e1) {

// TODO Auto-generated catch block

e1.printStackTrace();

}

} else {

JOptionPane.showMessageDialog(null,

"Retrieve Router Info !!");

}

}

}

public void windowClosing(WindowEvent e)

{

System.exit(0);


24/44



}

public void windowClosed(WindowEvent e)

{}

public void windowOpened(WindowEvent e)

{}

public void windowActivated(WindowEvent e)

{}

public void windowDeactivated(WindowEvent e)

{}

public void windowIconified(WindowEvent e)

{}

public void windowDeiconified(WindowEvent e)

{}

}

Router

package ui;

import java.awt.BorderLayout;





import java.net.UnknownHostException;



import javax.swing.JTabbedPane;








25/44





public class RouterTabForm implements WindowListener{

public String nodeName = "";

public String portNo;

public String ipAddress;

public Receiver receiver;

private final Multicst multicst;

SocketListener socketListener;

public RouterForm router;

JFrame jFrame;

public RouterTableForm routerTableForm;

public String[] config;

public RouterTabForm() throws UnknownHostException {

try {





break;

}

}

} catch (UnsupportedLookAndFeelException e) {

// handle exception

} catch (ClassNotFoundException e) {

// handle exception

} catch (InstantiationException e) {

// handle exception

} catch (IllegalAccessException e) {

// handle exception

}

config = Utils.getProperties();

nodeName = Utils.NodeName(Constants.TYPE_ROUTER);


26/44



portNo = Utils.generatePortNo();

ipAddress =


multicst = new Multicst(Constants.MULTICAST_NEI +

nodeName + ":"+ portNo + ":" + ipAddress,

Constants.INET_ADDRESS_NEIGHBOR,Constants.MULTICAST_NEI);

receiver = new Receiver(this, nodeName);

socketListener = new SocketListener(portNo, this);

router = new RouterForm(multicst, receiver, this);

routerTableForm = new RouterTableForm();

}

public void Design() {

try {

jFrame = new JFrame(nodeName);

JTabbedPane tab = new JTabbedPane();

jFrame.add(tab, BorderLayout.CENTER);

JButton button = new JButton("1");

tab.add(nodeName, router);

button = new JButton("2");

tab.add("Routing Table", routerTableForm);

jFrame.add(tab);

jFrame.setVisible(true);

screenCenter();

} catch (Exception e) {


}

}


Dimension dim = jFrame.getToolkit().getScreenSize();





jFrame.setSize(700, 700);


27/44



jFrame.setLocation((screenWidth - frameWidth) / 2,


}


try {

RouterTabForm routerTabForm = new

RouterTabForm();

routerTabForm.Design();



}

}

@Override

public void windowOpened(WindowEvent e) {

// throw new UnsupportedOperationException("Not supported

yet."); //To change body of generated methods, choose Tools |

Templates.

}

@Override

public void windowClosing(WindowEvent e) {

System.exit(0);//throw new

UnsupportedOperationException("Not supported yet."); //To change

body of generated methods, choose Tools | Templates.

}

@Override

public void windowClosed(WindowEvent e) {

//throw new UnsupportedOperationException("Not supported


Templates.

}

@Override


28/44



public void windowIconified(WindowEvent e) {



Templates.

}

@Override

public void windowDeiconified(WindowEvent e) {



Templates.

}

@Override

public void windowActivated(WindowEvent e) {



Templates.

}

@Override

public void windowDeactivated(WindowEvent e) {



Templates.

}

}

IDS System

package ui;

import java.awt.BorderLayout;







29/44




import javax.swing.JTabbedPane;









public class IdsDesignTabForm implements WindowListener{

JFrame jframe;

public IdsMonitoringForm idsMonitoringForm;

String[] nodeConfig;

public SocketListener socketListener;

public IdsGraphForm idsGraphForm;

public Receiver receiver;

String inetAddress;

public IdsDesignTabForm() {

try {

inetAddress =


receiver = new Receiver(this, "");

idsMonitoringForm = new IdsMonitoringForm(this);

idsGraphForm = new IdsGraphForm(this);





break;

}

}


30/44




// handle exception

}

}

public void designForm() {

try {

nodeConfig = Utils.getProperties();

socketListener = new

SocketListener(nodeConfig[3], this);

// design();

jframe = new JFrame("IDS System");

JTabbedPane tab = new JTabbedPane();

jframe.add(tab, BorderLayout.CENTER);

JButton button = new JButton("1");

tab.add("Ids Monitoring", idsMonitoringForm);

button = new JButton("2");

tab.add("Network Monitoring", idsGraphForm);

jframe.add(tab);

jframe.setVisible(true);

screenCenter();



}

}


Dimension dim = jframe.getToolkit().getScreenSize();





jframe.setSize(700, 700);

jframe.setLocation((screenWidth - frameWidth) / 2,


}


31/44




IdsDesignTabForm idsDesignForm = new

IdsDesignTabForm();

idsDesignForm.designForm();

}

/*public void callMulticst() {

try {

String msg = Constants.MULTICAST_MONITOR;

multicst = new Multicst(msg, inetAddress, msg);



// TODO: handle exception

}

}*/

@Override

public void windowOpened(WindowEvent e) {



Templates.

}

@Override

public void windowClosing(WindowEvent e) {

System.exit(0); //throw new

UnsupportedOperationException("Not supported yet."); //To change

body of generated methods, choose Tools | Templates.

}

@Override

public void windowClosed(WindowEvent e) {



Templates.

}


32/44



@Override

public void windowIconified(WindowEvent e) {



Templates.

}

@Override

public void windowDeiconified(WindowEvent e) {



Templates.

}

@Override

public void windowActivated(WindowEvent e) {



Templates.

}

@Override

public void windowDeactivated(WindowEvent e) {



Templates.

}

}

5.3

SOFTWARE REQUIREMENTS

The Software Requirements is a technical specification of requirements for the software

product. The goal of software requirements definition is to completely and consistently

specify the technical requirements for the software product in a concise and

unambiguous manner


33/44



Operating System : Windows Family.

Programming Language : JDK 1.5 or higher

5.4

HARDWARE REQUIREMENTS

The selection of hardware is very important in the existence and proper working of any

software. When selecting hardware the size and capacity requirements are also

important.

Processor : Any Processor above 500 MHz.

Ram : 128Mb.

Hard Disk : 10 GB.

Input device : Standard Keyboard and Mouse.

Output device : VGA and High Resolution Monitor.


34/44



6. SYSTEM TESTING

6.1 TESTING PROCEDURES

Unit Testing

Integration Testing

Validation Testing

Output Testing

User Acceptance Testing

System Testing

6.1.1 Unit Testing

Here we test each module individually and integrate the overall system. Unit

testing focuses verification efforts even in the smallest unit of software design in each

module. This is known as “Module Testing”. The modules of the system are tested

separately. This testing is carried out in the programming style itself. In this testing each

module is focused to work satisfactorily as regard to expected output from the module.

There are some validation checks for the fields.

6.1.2 Integration Testing

Data can be lost across an interface, one module can have an adverse effect on

the other sub-functions, when combined may not produce the desired functions.

Integrated testing is the systematic testing to uncover the errors within the interface.

This testing is done with simple data and the developed system has run successfully

with this simple data. The need for integrated system is to find the overall system

performance.

6.1.3 Validation Testing

At the culmination of black box testing, software is completely assembled as a

package. Interfacing errors have been uncovered and correct and final series of test, i.e.,

validation test begins. Validation test van is defined with a simple definition that

succeeds when the software functions in a manner that can be reasonably accepted by

the customer.


35/44



6.1.4 Output Testing

After performing validation testing, the next step is output testing of the

proposed system. Since the system cannot be useful if it does not produce the required

output. Asking the user about the format in which the system is required tests the output

displayed or generated by the system under consideration. Here the output format is

considered in two ways. One is on screen format and other one is printed format. The

output format on the screen is found to be corrected as the format was designed in the

system phase according to the user needs. As for hard copy the output comes according

to the specification requested by the user. Here the output testing does not result in any

correction in the system.

Taking various kinds of data plays a vital role in system testing. After preparing

the test data, system under study is tested using the tested data. While testing, errors are

again uncovered and corrected by using the above steps and corrections are also noted

for future use. The system has been verified and validated by running test data and live

data.

First the system is tested with some sample test data are generated with the

knowledge of possible range of values that are required to hold by the fields. The

system runs successfully for the given test data and for live data.

6.1.5 User Acceptance Testing

User acceptance testing of the system is the key factor for the success of any

system. The system under consideration is tested for the user acceptance by constantly

keeping in touch with perspective system at the time of development and making

change whenever required. This is done with regard to the input screen design and

output screen design.

6.2 TESTING METHODOLOGIES

Different testing methodologies are applied before the system is tested for user

acceptance.

Black Box Testing

Knowing the specific function that a product has been designed to perform, test

can be conducted that each function is fully operational. Black Box Testing is carried to


36/44



test that input to a function is probably accepted and output is correctly produced. A

black box testing examines some aspects of a system with little regards for the internal

logical structure of the software. Errors in the following categories were found through

black box testing

Incorrect or missing function

Interface errors

Errors in data structures or external database access

Performance errors

Initialization and termination errors

White Box Testing

White Box Testing of software is predicated on a close examination of

procedural details. The status of a program may be tested at various points. Things to

determine whether asserted status is corresponding to the actual status. Using the

following test case can be derived.

Exercise all logical conditions on their true and false side

Exercise all loops within their boundaries and their operational bounds

Exercise internal data structure to ensure their value


37/44



7. CONCLUSION

BW-DDoS attacks employed relatively crude, inefficient, brute force mechanisms.

However, several known attacks, which aren’t commonly used, let attackers launch

sophisticated attacks, which are difficult to detect and might considerably amplify

attackers’ strength. Deployed and proposed defenses might struggle to meet these

increasing threats; therefore, we need to deploy more advanced defenses. This might

involve proposed mechanisms as well as new approaches. Some proposed defenses

raise operational and political issues; these are beyond the scope of our article but

should be considered carefully. Finally, for a defense mechanism to be practical, it must

be easy to deploy and require minor changes, if any, especially to the Internet’s core

routers.


38/44



8. REFERENCE

[1] “Prolexic Attack Report,Q32011Q42012,”P.T.Inc.,2012;

www.prolexic.com/attackreports.

[2] “Worldwide Infrastructure Security Reports

Series(20052012),”ArborNetworks,2013; www.arbornetworks.com/report.

[3] M. Prince, “The DDoS that Almost Broke the Internet,”CloudFlare, 27 Mar.

2013; http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet.

[4] S. Wei, J. Mirkovic, and M. Swany, “Distributed WormSimulation with a

Realistic Internet Model,” Workshop Principles of Advanced and Distributed

Simulation(PADS 05), IEEE CS, 2005, pp. 71 – 79.

[5]

S. Antonatos et al., “Pu ppetnets: Misusing Web Browsers as a Distributed

Attack Infrastructure,” ACM Trans. Information and System Security, vol. 12,

no. 2, 2008, pp. 12:1 – 12:15.

[6] “ANA Spoofer Project,” Advanced Network Architecture Group, 2012;

http://spoofer.csail.mit.edu/summary.php.

http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internethttp://blog.cloudflare.com/the-ddos-that-almost-broke-the-internethttp://blog.cloudflare.com/the-ddos-that-almost-broke-the-internethttp://spoofer.csail.mit.edu/summary.phphttp://spoofer.csail.mit.edu/summary.phphttp://spoofer.csail.mit.edu/summary.phphttp://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet


39/44



9. SCREENSHOT


40/44




41/44




42/44




43/44




44/44


BwDDoS attack & defense project Report

Documents

Transcript of BwDDoS attack & defense project Report