Project Thesis

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

<>

Analyzing the packets for detecting the attack





Web Server

Monitoring 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 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 Packets

NO YES IF Attack!=0 Attack--

IF Attack==15 YES

Generate RST Packets

NO

Figure 5.2 Activity Diagram

NO

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

<>

getDeviceList() getJpcapSenderInstance () getPacket() openDevice() setFilter() openFile() procesPacket()

openDevice() openRawSacket() close() sendPacket()

<> Packet NetworkInterface

int:caplen byte[]:data DatalinkPacket:datalink packet:EOF byte[]:header int:len long:sec long:usec

NetworkInterface Address: address String:datalink_name String:datalink_ descri ption Byte[]:mac_address

equals() wait() notify(0 notifyAll() getClass()

Packet() toString()

ActiveMonitor Int:NoOfSyns Int:NoOfAcks

main()

Figure 6.1 Class Diagram

Packet DatalinkPacket equals() getClass() wait() notify() notifyAll()

IPPacket InetAddress:src_ip InetAddress:dst_ip short:length short:offset short:protocol short:length boolean:d_flog boolean:don’t_frag int:flow_label int:ident boolen;r_flag boolean_rsv_flag

EithernetPacket byte[]:dst_mac byte[]:src_mac short:frametype

setIPv4Parameter() setIPv6Parameter() 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. is narrow rectangle called an activation that represents an execution

Along the lifeline 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

Client PC1 Asks Packets

Generate packets

Gets Packets Send RST Packets

Receive RST Packets

Figure 6.3 Sequence Diagram

: JpcapCaptor

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 dashedarrow 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 Server

Client 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 :

S.N o 1

JpcapCaptor

Dependencies :

NetworkInterface,JpcapSender,Packet,Packet Receiver

Parameters

dropped_packets ,received_packets

:

Method Under Test getDeviceList

2

getJpcapSenderInstan ce

3

getPacket

4

openDevice

5

openFile

6

updateStat

7.

setFilter

8.

processPacket

Input

Expected Output ---Returns List of Network Interfaces ---Returns JpcapSender object ---Returns The packet captured Network Opens Given Interface, NetworkInterfa int,boolean ce and returns int JpcapObject Valid File Returns the Object Jpcapture object ---Updates the droped_packets ,received_packe ts data memebers String, Sets the Filter boolean int,PacketHan dler.

Captures the specified no of packets.

Actual Action Output Taken Returned List of Network Interfaces Returnsed JpcapSender object Returned A single The packet Is captured Captured Opened Given Network NetworkInterfac Interface e and returns Opened JpcapObject Returned the File is Jpcapture object opened Updated the droped_packets,r eceived_packets data memebers

updatingd roped_pa ckets and received packets Set the Filter Enabling the Filter. Captured the specified no of packets.

2. Testing Class :

S.N o 1

Dependencies :

NetworkInterface,Packet

Parameters

None.

:

Method Under Test openDevice

2

openRawSocket

3

sendPacket

4.

Close

Input

Expected Output NetworkI Returns List of nterface Jpcapseder object ---Returns JpcapSender object packet Sends given packet ------

3. Testing Class :

S.N o 1

JpcapSender

Actual Action Output Taken Returned Network Jpcapsender Interface Object. opened Returnsed JpcapSender object Sent given packet Sending the packet. Closes the Closed the Closing NetworkInterfa NetworkInterface the ce Network Interface

Packet

Dependencies :

Datalink.

Parameters

caplen,data,datalink,EOF,header,len,sec,usec.

:

Method Under Test

Input

toString

--------

Expected Output Returns the String representation of the packet.

Actual Action Output Taken Returns the Creatig a String String. representation of the packet..

4. Testing Class : Dependencies : Parameters

IPPacket InetAddress.

:

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 o 1

2

Method Under Test setIPV4Parameter

toString

5. Testing Class : Dependencies : Parameters

Input

Expected Output All the Creates the IP parameter header s of the class ---Returns the String representation of the IP packet

Actual Output Created the IP header

Action Taken Creating The IP header.

Returned the String representation of the IP packet

Creating the string

TCPPacket None

:

ack,ack_num,dst_port,fin,option,psh,rst,rsv1,rsv2,sequence,src_port syn,urg,urgent_pointer,window. S.N o 1

2

Method Under Test TCPPacket()

toString

Input

Expected Actual Output Output All the Creates the TCP Created the TCP parameter header Header s of the class ---Returns the Returned the String String representation of representation of the TCP packet the TCP packet

Action Taken Creating The TCP header. Creating the string