SYSTEM

REQUIREMENTS

SYSTEM REQUIREMENTS
5.1Functional Requirements:

1.Finiding the interfaces Available in the machine

2.Opening the required Interface in the promiscuous mode
3.Caputring the packets relevant to the server
4. Calculating the No.of SYN packets and ACK packets received
5.If the Difference Between No.of SYN packets and No.of ACK packets is Positive then
storing the SYN Packet details in the file.
6.Sending the RST packets through opened interface.

5.2 .Non Functional Requirements:

1.Capturing all the packets

2.Generating the Attack details in time

3.Sendint all RST packets without Fail.

5.3 UML diagrams for Analysis

Use Case Diagrams:

A use case corresponds to a sequence of transactions, in which

each transaction is invoked from outside the system (actors) and engages internal objects
to interact with one another and with the system’s surroundings. In essence, the use-case
model defines the outside (actors) and inside (use case) of the system’s behavior. Use
cases represent specific flows of events in the system. The use cases are initiated by actors
and describe the flow of events that these actors are set off.
 Reading the Time to
monitor, Packets
 Client
PC

Admin
<<includes>>

Analyzing the packets for

detecting the attack



Monitoring
Web Server

PC

Generating Attack details

And Generating RST packets

Figure 5.1 Use Case Diagram

Activity Diagram:

Activity diagram is a variation or special case of a state machine, in which the

states are activities representing the performance of operations and the transitions are
triggered by the completion of operations. Unlike state diagrams that focus on the events
occurring to a single object as it responds to messages, an activity diagram can be used to
model an entire business process. The purpose of an activity diagram is to provide a view
of flows and what is going on inside a use case or among several classes.
 Read Time t

YES
Is current time NO
is less than t

Capturing the TCP

control Packets for 5
seconds.

Calculating the Value of

X=SYN-ACK.

YES NO
If X>0

Attack++,
Store Syn NO
Packets YES
IF Attack!=0

Attack--

IF Attack==15 Generate RST

Packets
YES
NO

Figure 5.2 Activity Diagram

SYSTEM DESIGN
 SYSTEM DESIGN
6.1Class Diagrams

The UML class diagram also referred to as object modeling, is the main static
analysis diagram. Object modeling is the process by which the logical objects in the real
world (problem space) are represented (mapped) by the actual objects in the program.
(Logical or a mini world). These diagrams show a set of classes, interfaces, and
collaborations and their relationships. These diagrams address the static design view of a
system. This view primarily supports the functional requirements of a system – the
services the system should provide to its end users. A class diagram is a collection of static
modeling elements, such as classes and their relationships, connected as a graph to each
other and to their contents; Class diagrams do not show temporal information which is
required in dynamic modeling.

Contents
Class diagrams commonly contain the following things:
 Classes
 Interfaces
 Collaborations
 Dependency, Generalization and association relationships
 JpcapCaptor JpcapSender

int: dropped_packets
int: received_packets <<create>>
getDeviceList() openDevice()
getJpcapSenderInstance openRawSacket()
() close()
getPacket() sendPacket()
openDevice()
setFilter()
openFile()
procesPacket()

<<create>>
Packet

NetworkInterface
int:caplen
NetworkInterface
byte[]:data
Address: address
DatalinkPacket:datalink
String:datalink_name
packet:EOF
String:datalink_
byte[]:header
descri ption
int:len
Byte[]:mac_address
long:sec
long:usec
equals()
Packet()
wait()
toString()
notify(0
notifyAll()
getClass()

ActiveMonitor

Int:NoOfSyns
Int:NoOfAcks

main()

Figure 6.1 Class Diagram

 Packet

DatalinkPacket

equals()
IPPacket getClass()
InetAddress:src_ip wait()
InetAddress:dst_ip notify()
short:length notifyAll()
short:offset
short:protocol
short:length
boolean:d_flog
boolean:don’t_frag
int:flow_label
int:ident EithernetPacket
boolen;r_flag
boolean_rsv_flag
byte[]:dst_mac
setIPv4Parameter() byte[]:src_mac
setIPv6Parameter() short:frametype
toString()
getDestinationsAddr
ess()
getSourceAddress()

TCPPacket
boolean:ack
long:ack_num
int:dst_port
boolean:fin
byte[]:option
boolean:syn
boolean:rst
boolean:urg
boolean:fin
boolean:psh
int:window
long:sequence

toString()

Figure 6.2 Class Diagram

6.2 Sequence Diagrams
Sequence Diagrams describe the interactions between design components and
environment. Instances of these design components appear on the horizontal axis of the
diagram, with interactions such as events, operations, and time placed on the vertical axis.
A sequence diagram describes how objects interact with each other and how messages are
sent and received between the objects.

A sequence diagram shows an interaction arranged in time sequence. The

instances participating in the interaction. Sequential sub states occur one after the other. A
line separates concurrent sub states. The arrow lines gives the interaction among the
objects takes place in a specified sequence and the sequence takes time to go from
beginning to end. The sequence diagram shows how objects communicate with one
another. The objects represented in usual way as named rectangles. Messages represented
as solid line arrow and time represented by vertical lines. The objects are at top of the
diagram from left to right. Extending a line from object is called objects life line.

Objects:
The objects are laid out near the top of the diagram from left to right. Extending
downward from each object is a dashed line called the object’s lifeline. Along the lifeline
is narrow rectangle called an activation that represents an execution of an operation the
object carries out.

Messages:
A message can be simple, synchronous, or asynchronous. A simple message is a
transfer of control from one object to another. If an object sends a synchronous message, it
waits for an answer to that message before it proceeds with its business. If an object sends
an asynchronous message, it doesn’t wait for an answer before it proceeds. In the sequence
diagram, a simple message has a two-line arrowhead, a synchronous message has a full
arrowhead, and an asynchronous message has a half-arrowhead.
Time:
Time starts at the top and progresses toward the bottom. A message that’s closer to
the top occurs earlier in time than a message that’s closer to the bottom.

: Active
Monitor : JpcapCaptor : JpcapCaptor

Client
PC1
Asks
Generate Packets
packets

Gets
Packets

Send RST Packets

Receive RST Packets

Figure 6.3 Sequence Diagram

Deployment Diagrams:

A Deployment Diagram is a graph of nodes connected by communication

association. Nodes may contain component instances, which mean that the component
lives or runs at that node. Components may contain objects; this indicates that the object
is part of the component. Components are connected to other components by dashed-
arrow dependencies usually through interfaces, which indicate one component uses the
services of another. Each node or processing element in the system is represented by a
three-dimensional box. Connections between the nodes (or platforms) themselves are
shown by solid lines.

Packets
Active
Monitor
Client
PC1 OS

Packets

Packets

Web Client
Server PC2 OS
 TESTING

8.1 Testing
 Software testing is a critical element of software quality assurance and represents the
ultimate service of specification design and coding. The increasing visibility of software as
a system element and the attended costs associated with the software failure and motivating
forces for well planned, through testing. It is not unusual for a software development to
spend between 30 and 40 percent of total project effort in testing.

System Testing Strategies for this system integrate test case design techniques into a well
planned series of steps that result in the successful construction of this software. It also
provides a road map for the developer, the quality assurance organization and the customer,
a roadmap that describes the steps to be conducted as path of testing, when these steps are
planned and then undertaken and how much effort, time and resources will be required.
The test provisions are follows.

Testing Objectives:

The following are the testing objectives....

• Testing is a process of executing a program with the intent of finding an error.
• A good test case is one that has a high probability of finding an as yet undiscovered error.
• A successful test is one that uncovers as a yet undiscovered error.

The above objectives imply a dramatic change in view point. They move counter
to the commonly held view that a successful test is one in which no errors are found. Our
objective is to design tests that systematically different clauses of errors and do so with
minimum amount of time and effort.
If testing is conducted successfully, it will uncover errors in the software. As a
secondary benefit, testing demonstrates that software functions appear to be working
according to specification and that performance requirements appear to have been met. In
addition, data collected as testing is conducted provides a good indication of software.
Testing can't show the absence of defects, it can only show that software errors are present. It
is important to keep this stated in mind as testing is being conducted.
Testing principles:
 Before applying methods to design effective test cases, a software engineer must understand
the basic principles that guide software testing.

• All tests should be traceable to customer requirements.

• Tests should be planned ling before testing begins.
• Testing should begin "in the small" and progress towards testing "in the large".
• Exhaustive testing is not possible.
8.2 Class Testing

Software Testing begins “in the small “and slowly progresses toward testing “in the large”.
Testing in the small focuses on a single class and the methods that are encapsulated by the
class.
In object oriented programs control flow switches from one object to another by inter-object
communication and state of the object displays an important role in invocation of methods.
Hence testing technique is to test all the methods of a class, one by one, against the set of
states that the object can take also termed as state-based testing. State-based testing is
technique to test whether or not the methods of a class interact correctly among themselves
by monitoring the data members of the class.

Steps to be followed for test case design

1. Each test case should be uniquely identified and explicitly associated with the class to
be tested.
2. The purpose of the test should be stated.
3. A list of steps should be developed for each test and should contain
• A list of specified states for the object that is to be tested.
• A list of messages and operations that will be exercised as a consequence of the
test.
• A list of exceptions that may occur as the object is tested.
• A list of external conditions.
• Supplementary information that will aid in understanding or implementing test
 I. Testing Class : JpcapCaptor
Dependencies : NetworkInterface,JpcapSender,Packet,Packet Receiver
Parameters : dropped_packets ,received_packets

S.N Method Under Test Input Expected Actual Action

o Output Output Taken
1 getDeviceList ---- Returns List of Returned List of
Network Network
Interfaces Interfaces
2 getJpcapSenderInstan ---- Returns Returnsed
ce JpcapSender JpcapSender
object object
3 getPacket ---- Returns Returned A single
The packet The packet Is
captured captured Captured
4 openDevice Network Opens Given Opened Given Network
Interface, NetworkInterfa NetworkInterfac Interface
int,boolean ce and returns e and returns Opened
int JpcapObject JpcapObject
5 openFile Valid File Returns the Returned the File is
Object Jpcapture Jpcapture object opened
object
6 updateStat ---- Updates the Updated the updatingd
droped_packets droped_packets,r roped_pa
,received_packe eceived_packets ckets and
ts data data memebers received
memebers packets
7. setFilter String, Sets the Filter Set the Filter Enabling
boolean the
Filter.
8. processPacket int,PacketHan Captures the Captured the
dler. specified no of specified no
packets. of packets.
 2. Testing Class : JpcapSender
Dependencies : NetworkInterface,Packet
Parameters : None.

S.N Method Under Test Input Expected Actual Action

o Output Output Taken
1 openDevice NetworkI Returns List of Returned Network
nterface Jpcapseder Jpcapsender Interface
object Object. opened
2 openRawSocket ---- Returns Returnsed
JpcapSender JpcapSender
object object
3 sendPacket packet Sends given Sent given packet Sending
packet the
packet.
4. Close ------ Closes the Closed the Closing
NetworkInterfa NetworkInterface the
ce Network
Interface

3. Testing Class : Packet

Dependencies : Datalink.
Parameters : caplen,data,datalink,EOF,header,len,sec,usec.
S.N Method Under Test Input Expected Actual Action
o Output Output Taken
1 toString -------- Returns the Returns the Creatig a
String String String.
representation of representation of
the packet. the packet..
 4. Testing Class : IPPacket
Dependencies : InetAddress.
Parameters :
d_flag,don’t_frag,dst_ip,flow_label,hop_limit,ident,IPPROTO_TCP,
length,more_frag,offset,options,priority,protocol,rsv_frag,rsv_tos,
src_ip,version

S.N Method Under Test Input Expected Actual Action

o Output Output Taken
1 setIPV4Parameter All the Creates the IP Created the IP Creating
parameter header header The IP
s of the header.
class
2 toString ---- Returns the Returned the Creating
String String the
representation of representation of string
the IP packet the IP packet

5. Testing Class : TCPPacket

Dependencies : None
Parameters :
ack,ack_num,dst_port,fin,option,psh,rst,rsv1,rsv2,sequence,src_port
syn,urg,urgent_pointer,window.
S.N Method Under Test Input Expected Actual Action
o Output Output Taken
1 TCPPacket() All the Creates the TCP Created the TCP Creating
parameter header Header The TCP
s of the header.
class
2 toString ---- Returns the Returned the Creating
String String the
representation of representation of string
the TCP packet the TCP packet