Upload
duonghanh
View
230
Download
1
Embed Size (px)
Citation preview
Visualisation of tcpdump Output
Alexander Page
Bachelor of Science in Computer Science with HonoursThe University of Bath
May 2010
This dissertation may be made available for consultation within the Uni-versity of Bath Library and may be photocopied or lent to other librariesfor the purposes of consultation.
Signed:
Visualisation of tcpdump output
Submitted by: Alexander Page
COPYRIGHT
Attention is drawn to the fact that copyright of this dissertation rests with its author. TheIntellectual Property Rights of the products produced as part of the project belong to theUniversity of Bath (see http://www.bath.ac.uk/ordinances/#intelprop).This copy of the dissertation has been supplied on condition that anyone who consults itis understood to recognise that its copyright rests with its author and that no quotationfrom the dissertation and no information derived from it may be published without theprior written consent of the author.
Declaration
This dissertation is submitted to the University of Bath in accordance with the requirementsof the degree of Bachelor of Science in the Department of Computer Science. No portion ofthe work in this dissertation has been submitted in support of an application for any otherdegree or qualification of this or any other university or institution of learning. Exceptwhere specifically acknowledged, it is the work of the author.
Signed:
Abstract
Tcpdump is a unix command which prints out information from captured packet headers.The output from the command is verbose and difficult to read. This gave motivation to aproject to ease the interpretation of tcpdump data by displaying it diagrammatically withannotations to identify key networking (TCP) characteristics. This results in a clearerrepresentation and a reduction in the time taken to read the raw tcpdump data.
This document discusses the implementation details of the program which parses a givenlog file and produce both a PDF document and an on-screen representation of the data.The program is also capable of annotating the visualisation with colours and labels whichare generated as a result of executing user-defined rules which specify patterns to matchagainst the tcpdump.
The resultant program successfully achieves the outlined tasks and forms a basis for furtherdevelopments which are discussed as part of the evaluation.
Contents
1 Introduction 1
1.1 Example output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Project requirements specification . . . . . . . . . . . . . . . . . . . . . . . 2
1.4.1 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4.2 Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.3 Annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.4 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.5 Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.6 Further Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Literature Survey 4
2.1 About tcpdump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Uses for tcpdump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Methods of viewing tcpdump data . . . . . . . . . . . . . . . . . . . . . . . 5
2.5 Visualisation of tcpdump data . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6 Conversion from data to image . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6.1 PGF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6.3 Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
ii
CONTENTS iii
3 Requirements 11
3.1 Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2 Project Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Non-functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 Requirements Critique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Design 14
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Module design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4.1 Log Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4.2 Rules Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4.3 Graph Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.6 Design conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5 Implementation and Testing 20
5.1 Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2 Detailed explanation of implementation . . . . . . . . . . . . . . . . . . . . 21
5.2.1 Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.2 Log parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.3 Rules engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.4 Graph rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Implementation conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.2 Testing environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
CONTENTS iv
5.4.3 Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4.4 Requirements Verification . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4.5 Non-functional requirements verification . . . . . . . . . . . . . . . . 30
5.4.6 Testing Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6 Conclusions 32
6.1 Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.2 Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.3 Future works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3.1 Rules Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3.2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3.3 Visualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3.4 Real-time analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.4 Critical Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A Design Diagrams 38
B Test Files 42
C Test cases 43
D Screenshots 55
E Code 60
E.1 File: dumphandler.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
E.2 File: main.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
E.3 File: packet.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
E.4 File: pattern.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
E.5 File: renderarea.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
E.6 File: rule.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
E.7 File: rulesengine.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
E.8 File: tcpgraph.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
E.9 File: types.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
CONTENTS v
E.10 File: dumphandler.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
E.11 File: packet.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
E.12 File: pattern.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
E.13 File: renderarea.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
E.14 File: rule.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
E.15 File: rulesengine.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
E.16 File: tcpgraph.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
E.17 File: types.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
List of Figures
1.1 A single line of output from tcpdump . . . . . . . . . . . . . . . . . . . . . 1
2.1 Stevens’ tcp graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 tcp state machine generated by TikZ and PGF . . . . . . . . . . . . . . . . 8
2.3 UML diagram generated by TikZ and PGF . . . . . . . . . . . . . . . . . . 9
4.1 Program modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1 Rule and pattern matching algorithm for a pattern of type average . . . . . 25
A.1 Graph visualisation display window design . . . . . . . . . . . . . . . . . . . 38
A.2 Design of tcpdump graph without additional annotations . . . . . . . . . . 39
A.3 Design of tcpdump graph with coloured rule match . . . . . . . . . . . . . . 40
A.4 Design of tcpdump graph with additional labels . . . . . . . . . . . . . . . . 41
D.1 Screenshot of the GUI. This is the initial view that is shown once processingis complete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
D.2 Screenshot of the GUI. This is the view of the interface once the user hasscrolled down. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
D.3 Screenshot of the GUI. This is an example of both colouring and labellingannotations with rules 19.xml. . . . . . . . . . . . . . . . . . . . . . . . . . 58
D.4 This is a screenshot of the generated PDF open in Preview. . . . . . . . . . 59
vi
List of Tables
5.1 Attribute types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2 Results from execution of test cases . . . . . . . . . . . . . . . . . . . . . . . 29
5.3 Functional requirements verification . . . . . . . . . . . . . . . . . . . . . . 30
vii
Acknowledgements
I would like to thank my project supervisor Dr. Russell Bradford, for providing the projectmotivation. I would also like to thank my colleagues for providing support throughout theprocess.
viii
Chapter 1
Introduction
The use of tcpdump is prominent in the world of networking. It is a command line packetanalysing utility that prints out the header of packets sent over the network in which thecomputer is connected to. One of the most common uses for tcpdump is network debugging.This is mainly due to the configurability of the tool which allows users to specify variousoptions which allow for the selection of relevant data. The output can then be parsed intoother programs which analyse and report on problems or inconsistencies, resulting in anautonomous way to diagnose and troubleshoot network faults. Due to the nature of packetheaders, the instructions they contain are not intended to be human readable. It is difficultfor an administrator to quickly observe the current state of a network, instead they need tomentally decode each packet and build up a picture of the network communications thatare taking place. This has lead to an interest in trying to visualise this data in order tospeed up the process of deciphering tcpdump output.
1.1 Example output
09:57:58.262567 IP 138.38.174.243.58721 > 138.38.159.143.80: Flags [S],seq 3090222848, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS val 54544112 ecr 0,sackOK,eol], length 0
Figure 1.1: A single line of output from tcpdump
Figure 1.1 shows the amount of information packed into just one line of a tcpdump output.The most commonly useful elements are the source and destination IP, flags, sequencenumber (seq), window size (win) and length. Given even just a few more of these lines andit is immediately clear that analysing these logs is a lengthy and tiresome process.
1
CHAPTER 1. INTRODUCTION 2
1.2 Aim
The purpose of this project is to develop a system which takes the output from the tcpdumpcommand and visualises it in such a way that improves the representation of the data tospeed up analysis. This representation should not only reproduce what is seen in the log filebut also include annotations which help to explain that data. The main use of this kind ofrepresentation is twofold. The first use is for network administrators who use the tcpdumpcommand as part of their job. This will help them to view the information in another wayand hopefully speed up fault diagnosis or help identify ways in which the efficiency of theirnetwork can be improved. Another use for this project is for educational purposes. Theteaching of networking (TCP/IP) concepts can be dry and difficult to illustrate. One wayof teaching phenomena such as TCP connection establishment would be to display real-lifepacket capture in a diagram with the relevant packets clearly displayed. This would helpstudent to understand what is occurring.
1.3 Objectives
• Execute the tcpdump command and study the output. Learn to understand thepacket structure and information.
• Investigate ways of visualising information graphically. Find graphics packages thatwill take a text input and create a diagram according to certain rules.
• Create a transformation between the raw tcpdump output and the required input tothe graphics application.
• Extend this transformation by applying some logic to the parsed tcpdump in orderto annotate the produced diagram.
1.4 Project requirements specification
1.4.1 Deliverables
There should be two main software milestones. The first implementation should produce adiagram given some static raw tcpdump data. The second version should extend the firstwith an annotated diagram to display more useful diagnostics which will be decided uponand specified at a later date. The minimum achieved should be a diagram which shows theclient and server communications.
CHAPTER 1. INTRODUCTION 3
1.4.2 Diagram
The diagrams should consists of the client and server addresses on opposite sides witharrows between the two and annotations along these arrows and alongside the client andserver address. As an example see Stevens’ Book (Stevens, 1996)
1.4.3 Annotations
The annotations should provide more information than the raw tcpdump itself. It shouldbe possible to derive useful information from the original dump that can then be displayedon the diagram. An example of this may be noting where a connection begins and ends andthen displaying this, perhaps with a colour coding. More details on this will be availablefurther into the project after researching the usage of tcpdumps.
1.4.4 Version
The version of tcpdump should be that developed by Van Jacobson, Craig Leres andSteven McCanne, all of the Lawrence Berkeley National Laboratory, University of Califor-nia, Berkeley, CA. This version is available at http://www.tcpdump.org/ (Jacobson, Leresand McCanne, n.d.b)
1.4.5 Exclusions
The scope of this project extends as far as a 2 dimensional diagram representing tcp com-munications. It is important to note that the focus is in providing as much useful detailas possible rather than producing more visually enticing graphics such as extending to 3dimensional representations.
1.4.6 Further Scope
If the requirements outlined above are met within the allowed timeframe, further workshould look at doing the same thing in real-time and also providing even more annotationsbased on the data.
Chapter 2
Literature Survey
2.1 About tcpdump
The tcpdump tool was developed at the Lawrence Berkeley Laboratory at the Universityof California, Berkeley, by Van Jacobson, Craig Leres, and Steven McCanne. It was origi-nally developed to improve the performance of TCP/IP by discovering problems that areexposed by analysing packet headers. The tool is freely available on most systems archi-tectures including most versions of Unix and Windows (O’Reilly, n.d.). This fact suggeststhat the tool developed for this project which will visualise the tcpdump data should becross-platform compatible, allowing any users of the tcpdump dump program to pipe theiroutput into the visualisation tool and view the results. The most obvious language that isappropriate for this would be Java. A program written in Java can be run on any machinewhich has the Java virtual machine.
It is also widely known that the output is difficult to read, particular in hexadecimal format(Kretchmar, 2004), this makes it necessary to have some other tool to aid deciphering theoutput.
2.2 Uses for tcpdump
As already mentioned the main use for tcpdump is for network debugging. The programcan also be used for troubleshooting network problems, intrusion detection, logging networktraffic, discovering a faulty network card and even for forensics and evidence (Fuentesand Kar, 2005). Tcpdump can also be used in educational environment to help studentsunderstand the communications between computers at a low level. This wide variety ofuses reinforces the importance of a tool which aids readability of the tcpdump output.
4
CHAPTER 2. LITERATURE SURVEY 5
2.3 TCP/IP
Development began on the TCP/IP protocol suite in the 1960s by government funded re-search (Stevens, 1996). This is now used as the standard system for networking computers.The protocol is divided into four different layers; Link, Network, Transport and Applica-tion. Each layer is responsible for a different task. It is the Transport layer which we areinterested in for this project.
Link: Responsible for the physical connection between computers.
Network: Controls the movements of packets around the network.
Transport: Responsible for the flow of data between hosts.
Application Handles the network data sent and received by applications.
The TCP protocol falls into the transport layer, this is the layer in which tcpdump allowsus to examine. Each TCP segment has the following information in its header, whichtcpdump records.
• Source address & port
• Destination address & port
• Sequence number
• Acknowledgment number
• Window Size
• Flags/Options
This is the information that needs to be visualised.
2.4 Methods of viewing tcpdump data
The tcpdump command allows the user to choose how the output is formatted. This rangesfrom how the timestamp is printed, to how much network information is included and theverbosity of the output. For example, the ’-a’ switch tells the tool to try and resolvenetwork addresses to names (Jacobson, Leres and McCanne, n.d.a). This demonstratesthat there is not one standard form of output which a tcpdump visualisation programwould need to parse. A tcpdump visualisation program would have to be able to adjust itsparsing technique to allow for the style of the given input. This could be done in a numberof different ways. An ideal way to do this would be that the parser i.e. the part of the
CHAPTER 2. LITERATURE SURVEY 6
visualisation program that reads the input, recognises which type of input is present andso does not try to visualise data that it knows is not available in the input. This could beimplemented by using regular expressions to test for a set of rules which define what typeof input is given. A less automated way would be for the user to specify which switcheswere passed to the tcpdump command which generated the given output. This way theprogram would know what data is available. This is not ideal, but a feasible method.
From the above finding, one could conclude that the tcpdump visualisation program shouldbe flexible in parsing different forms of tcpdump data.
2.5 Visualisation of tcpdump data
The standard tcpdump output is just text. This is verbose and not very easy to read. It isnecessary to explore different ways of displaying this data.
There are already programs available which visualise tcpdump data. One of these attemptsto do this in 3D. An example is 3d-tcpdump (UKAI, n.d.) although it is not clear if thisproject was completed and does not appear to be available for download. There is howevera video demonstration of the program running. From this it is clear that the program runsin real-time and machines are only visible whilst they are interacting with the computerrunning tcpdump. As soon as communication ends, the representation of them disappearsfrom the 3d image. This is obviously done to avoid cluttering the image over time whenmany transactions have taken place. However, it means that one cannot analyse the dataafter this moment has passed. It is not clear if the program allows to playback partsof the capture to analyse what type of messages have been sent but from viewing thedemonstration it seems important for this feature to be available.
The most popular packet inspection tool is Wireshark. This program allows users to capturepackets and analyse the results. This does not visualise the data into an image in the waythat 3d-tcpdump does, but instead organises in such a way that allows the user to easily seethe different types of packet by colouring them according to ”colouring rules”(Combs, n.d.). It displays the list of packets in the top half of the window and then a detailed descriptionof the selected packet at in the bottom half of the window. This is different to 3d-tcpdumpin that it does not focus on the link between packet source and destination (although itdoes include these details) but rather the actual contents of the packets themselves. Itallows the user to filter the packets so only those of interest are shown. For example,one could filter for HTTP packets or DNS. This tool could be considered not so much as atcpdump visualisation but more of an interface to filter and organise tcpdump data makingit more searchable and easier to navigate. This could speed up the process of debugginga particular problem. For example, if the user knows that a problem lies with DNS, theycould filter for those packets in particular. This program seems good for helping a usernavigate captured packets, but doesn’t do much in the way of displaying actual activitygraphically between computers. The focus of this project is to visualise tcpdump datatherefore where 3d-tcpdump removes a large amount of information, Wireshark includes
CHAPTER 2. LITERATURE SURVEY 7
all the data. The program developed for this project needs to be somewhere between theseprograms in terms of the way it displays the data.
Computer programs are not the only time in which visualisation of network communicationoccurs. This also happens in text books to explain the theory behind networking. Stevensuses a particular method of graphing TCP which may well be beneficial for this project(Stevens, 1996).
Figure 2.1: Stevens’ tcp graph
Figure 2.1 demonstrates this technique of displaying the client on the left and the server onthe right. It shows the direction in which the packet was sent and also displays tcp actioninformation such as ’ack’. This information is more relevant to the scope of the projectbecause it allows a user to see an overview of what is happening in TCP communicationrather the more granular view given by Wireshark, which shows individual packet contents.
If the program is to produce output as in figure 2.1, there is a requirement for some methodof translating between tcpdump data and an image like the one shown.
CHAPTER 2. LITERATURE SURVEY 8
2.6 Conversion from data to image
2.6.1 PGF
There seem to be a limited number of programs available that allow you to create graphicsprogrammatically but one that does exist is TikZ and PGF. PGF is a macro package forLatex which is for generating graphics. TikZ is a user-friendly syntax layer. This wouldmean that a program could parse the tcpdump data and convert it into a format readableby the PGF macro (Tantau, n.d.). This would then convert the text into a graphic. Hereare some examples of what is achievable by using this macro.
CLOSED
LISTEN
SYN SENTSYN RCVD
ESTABLISHED
FIN WAIT 1
FIN WAIT 2
CLOSE WAIT
CLOSINGLAST ACK
TIME WAIT
Passive open Close
SYN/SYN + ACK Send/SYN
Timeout/RSTClose
Active open/SYN
SYN/SYN + ACK
Close/FIN
ACK SYN + ACK/ACK
Close/FIN FIN/ACK
ACK
ACK
FIN +ACK/ACK
FIN/ACK
ACK
Close/FIN
ACK
Timeout after two maximumsegment lifetimes (2*MSL)
Figure 2.2: tcp state machine generated by TikZ and PGF
Figure 2.2 is a much more complicated example than those used in Stevens’ text, butactually illustrates tcp data and is therefore relevant.
CHAPTER 2. LITERATURE SURVEY 9
:SimulationServer :SimControlNode :PhysicsServer :SenseServer:SimulationServer :SimControlNode :PhysicsServer :SenseServer
Initialize()
StartCycle()
ActAgent()
Update()
PrePhysicsUpdate()
state
PhysicsUpdate()
PostPhysicsUpdate()
EndCycle()
SenseAgent()
Run LoopRun Loop
Figure 1: UML sequence diagram demo.
Figure 2.3: UML diagram generated by TikZ and PGF
The style of figure 2.3 is much similar to the image in (Stevens, 1996) text, but is of coursemore complicated. The first part of the image (Initialize()) would be the style of graphicgenerated by tcpdump visualisation. I.e. direct communication between client and serverwith no intermediary.
Both images are very specific in the way the data is displayed. After some amount ofexperimentation it is clear that we will not be able to adapt the macro to display the graphin the way Stevens’ represents TCP data. As a result, it is necessary to explore alternativesto visualising information.
CHAPTER 2. LITERATURE SURVEY 10
Many high-level programming languages provide libraries that can be used to draw images.Two of these languages are explored.
2.6.2 Java
The java.awt.geom package (Microsystems, n.d.) is designed for drawing of 2D geometricshapes.
The abstract class Line2D is the superclass of Line2D.Double and Line2D.Float. Either ofthese classes could be used to draw the lines which represents packets, going from right-to-left and left-to-right and also any other other lines required in the image. These classesrepresent straight lines, where as arrows are required. To achieve this a similar class couldbe used that will produce a polygon (triangle) given three coordinates. This would bepositioned at the tip of the arrow.
2.6.3 Qt
The QPainter class (Corporation, n.d.) provides support for drawing many different shapesonto paint devices. This would include a graphical user interface and also a file that wouldbe used store the tcpdump visualisation. Unlike Java, it has functions rather than classesthat are used to draw the various shapes necessary to produce a visualisation.
2.7 Conclusion
From the survey of available literature it can be concluded that the tcpdump data shouldbe represented in a graphical way with arrows pointing between communicating computers.This graph should be annotated with relevant tcp information.
The research into TCP has highlighted the relevant fields which we we wish to display onthe graph.
The research into visualisation has revealed that PGF is far too restrictive in how it gen-erates images. This means it will not give enough control to produce the image which issimilar to Stevens’ graph. We have learnt that the QPainter class that is part of Qt allowspainting using a coordinate system which will allow us to produce images exactly as wewant them.
The tcpdump data will be parsed and converted into a representation that is easier tovisualise. This means that the program should easily be able to discover the direction ofthe arrow and the information that should be displayed alongside it.
Chapter 3
Requirements
3.1 Sources
In order to produce reasonable requirements the sources selected for requirement deductionare important. Due to the developmental nature of the project rather than one that isresearch oriented, most requirements have to be formed from own decisions and have notstemmed from surveying potential users and asking questions like ‘what would make packet-analysis easier?’.
3.1.1 Literature Review
The literature survey allowed for identification of what had already been achieved in thisfield and what would be possible to develop upon. It was discovered that there were applica-tions in existence which made the process of running a tcpdump simpler and displayed thedata in different text forms but there is little in the way of packet analysis and visualisation.
3.1.2 Project Supervisor
The project supervisor has advanced experience within this field of study and was able tomake suggestions as to where to focus the project. For example, it was suggested that theanalysis feature was more important than real-time visualisation.
3.2 Functional Requirements
The following functional requirements have been decided upon.
1. The program should be capable of parsing the output from the tcpdump command
11
CHAPTER 3. REQUIREMENTS 12
executed on a Unix computer.
1.1 The system will only be able to handle tcpdump data between two computers,source and destination.
1.2 The first packet in the tcpdump output will be declared the source and the nextpacket that does not match the source address will be declared the destination.
2. The program will produce a graph which represents communication between sourceand destination computers.
2.1 The graph will consists of straight lines with arrow tips indicating a packettravelling from source to destination or vice versa.
2.2 Packets originating from the source address will begin on the left hand side ofthe graph.
2.3 Packets originating from the destination address will being on the right handside of the graph.
3. The program will accept an optional rules file which will define one or more patternsto look for in the input log file.
3.1 The rules file should be written in XML.3.2 The rules file will contain one or more rules.3.3 Each rule will contain patterns to match the rule upon.3.4 A pattern contains information explaining the following information;
3.4.1 Which field in tcpdump log file to examine.3.4.2 Which value to compare it to.3.4.3 Which order this packet should occur in relation to other patterns within
the rule. For example, 1st, 2nd, 3rd etc.3.5 If the program is passed an invalid rules file it should display an error and exit.
4. When rules from the input rules file are matched, various annotations will be addedto the graph.
4.1 It should be possible to specify within the rules file the annotations to be added.4.2 Colouring of the relevant packets should be one of the annotations.4.3 Labelling of the relevant packets should be one of the annotations.
5. The graph should be displayed both on screen and written to a file for later viewing.
5.1 The file format for the saved graph should be PDF.
6. The program will be executed from the command line and will take a series of argu-ments defining the following things.
6.1 The location of the tcpdump file.6.2 Optionally: The location of the rules file.6.3 Optionally: The filename and location of the output file.
CHAPTER 3. REQUIREMENTS 13
3.3 Non-functional Requirements
1. The program should run on as many operating systems as possible.
2. The program should be useable by those who are colourblind.
3. The program should not crash when given an invalid log file.
3.4 Conflicts
The decision had to be made as to whether the program should focus on ease of use orfunctionality. Ultimately, it would be preferable that both options were fulfilled completelybut little development time meant the focus had to be given to one or the other. Choosingfunctionality over user interface would give more control over the tool for developers asthey would be able to better automate graph generation. This could be done by havingscripts which call the program with different arguments and rule files. Although having auser interface would make the tool more accessible to those with less technical experience.Arguably, it is those with experience of the command line interface that would find tcpdumpvisualisation most beneficial. It was this reason that led to the decision to have the programrun solely from the command line. Adding a user interface at a later stage would be arelatively trivial process due to the model, view, control paradigm.
3.5 Requirements Critique
The requirements gathering and specification process for a software project is useful as aguideline to begin design. However it is difficult to stick to these requirement entirely aslater on in the software cycle discoveries are made that mean requirements must change.Due to the short time-span of this project it was decided that the waterfall model as de-scribed by (Sommerville, 2006) would be used with little iteration. Perhaps more usefulrequirements could have been obtained by sending out questionnaires to network admin-istrators in order to obtain specific data identifying their needs and wants. Instead, theprogram was developed in a way that made it as customisable as possible (with the intro-duction of the rules system).
Chapter 4
Design
4.1 Introduction
The previous section outlined the requirements for the program. This section will refer tothose requirements and discuss how those requirements will be implemented.
4.2 Architecture
The program consists of four major modules (figure 4.1). These are log parsing, rules engineand graph rendering. They are driven from a control class. The design of each componentis given in detail. It was important to separate each of these modules because this allowsfor easy maintenance and simplifies future development of the system.
Graph Rendering
Control Module Rules EngineLog Parsing
Figure 4.1: Program modules
14
CHAPTER 4. DESIGN 15
4.3 Data Types
The following custom data types are required.
Packet - Each instance of this class represents one line of the input tcpdump file. Itcontains variables which hold the values of each field and also additional information setby the rules engine defining how the packet should be visualised.
Rule - Each instance represents a rule in the input rules file. The object holds the infor-mation stating what to do when the rule is matched and also one or more Patterns.
Pattern - This represents a pattern in the input file. This contains information specifyingwhich fields to look for and what values to compare them with in order to decide whethera rule is matched or not.
4.4 Module design
4.4.1 Log Parsing
In order to process the tcpdump output. It must be transformed to a representation whichis more suitable for use within the program. This is done by the log parsing module. ThePacket type described above is the end-goal representation for each line of the tcpdump.A list of these Packets will give an exact representation of the log.
Different versions of the tcpdump command along with the various switches that can beused to filter and transform the data mean that the output from the command varies.With this in mind, it was necessary to decide how to account for the different formats. Thedevelopment environment for the project is Mac OS X and the program is hard coded toread tcpdump files produced on this machine. This means that it will not read files createdon other operating systems. A solution to this problem has been found which involvescreating a template file which defines the format of the tcpdump output i.e. the order offields and the regular expressions which identifies those fields. This file would then be readby the log parser in order to learn where to find each field in the given tcpdump.
It is the responsibility of the log parsing module to handle file open, read and close for therules file.
4.4.2 Rules Engine
The rules engine is responsible for handling the part of the program which allows users tospecify patterns which are then matched against the tcpdump file.
It was decided that the program should be as dynamic as possible with regards to recog-nising TCP/IP characteristics. Users are likely to have their own requirements and maywish to look for things which are not a standard TCP/IP activity. There were two options;
CHAPTER 4. DESIGN 16
hardcode as many patterns to look for as possible or create a system which allows usersto specify their patterns. The latter option was the obvious choice. This meant that theexact requirements of the user could be implemented by the user themselves allowing for amore flexible tool which does not stick to the rigid rules of our own development.
It is as a result of this design decision that the rules engine was devised. The system wasis given the following tasks:
• Process the user-defined rules file.
• Analyse packets to decide whether they match any rules.
• Add details to packets which match rules so that render area can display correctdetails.
The module must read the file into a list of the Rule/Pattern objects (described earlier).This allows access to the rules for the next stage, processing.
Once the log parsing module has completed its task, the Packet objects should be examinedfor those which match rules.
Rules File
The rules engine accepts an XML file (defined in listing 4.1) which contains the rules definedby the user. The program would be distributed with a template file which contains rulesfor discovering some simple TCP characteristics. An example file is shown in listing 4.2which will identify packets that contain the ACK flag.
Explanation of rules file:
<rule name="ACK">
Introduce a new rule and give it a name.
<pattern type="average" match="win" order="1" count="5" origin="source">5200-5500</pattern>
Add a pattern to the rule. Each pattern has the following attributes:
• type:constant - match the given string for each packet.average - (for integer fields) calculate the average and compare to given number orrange.
• match: Which field in the packet header to examine.
CHAPTER 4. DESIGN 17
• order: The order the pattern should appear (for use with rules that have multiplepatterns). Default = 1
• count: (for patterns of type average) How many consecutive packets to include in theaverage calculation.
• origin: Specify whether to look only at packets originating from the source (thecomputer that initated the connection) or destination machine. If left blank, willmatch both.
The above pattern would match on five consecutive packets originating from the sourcemachine with an average window size between 5200 and 5500 inclusive.
<result type="colour" value="blue"/>
Define what will be done when this rule is matched.
• type:colour - Change the colour of the corresponding packets.label - Add a label to the corresponding packets.
• value: The colour or label to add.
The above result would colour blue any packets that match the rule.
<?xml ve r s i on=” 1 .0 ”?><xs : schema>
<xs : element name=” ru l e s ”><xs : complexType>
<xs : sequence><xs : element name=” ru l e ” maxOccurs=”unbounded”><xs : complexType>
<xs : a t t r i b u t e name=”name” type=”xs : s t r i n g ”/><xs : a l l >
<xs : element name=” pattern ” maxOccurs=”unbounded”><xs : complexType>
<xs : a t t r i b u t e name=” type” type=”xs : s t r i n g ”/><xs : a t t r i b u t e name=”match” type=”xs : s t r i n g ”/><xs : a t t r i b u t e name=” order ” type=”xs : i n t e g e r ”/><xs : a t t r i b u t e name=”count” type=”xs : i n t e g e r ”/><xs : a t t r i b u t e name=” o r i g i n ” type=”xs : s t r i n g ”/>
</xs : complexType></xs : element><xs : element name=” r e s u l t ”>
<xs : complexType><xs : a t t r i b u t e name=” type” type=”xs : s t r i n g ”/>
<xs : a t t r i b u t e name=”value ” type=”xs : s t r i n g ”/></xs : complexType>
</xs : element></xs : a l l >
</xs : complexType>
CHAPTER 4. DESIGN 18
</xs : element></xs : sequence>
</xs : complexType></xs : element>
</xs : schema>
Listing 4.1: XML Schema Definition for rules file
<?xml ve r s i on=” 1 .0 ” encoding=”ISO−8859−1”?><ru l e s >
<r u l e name=”ACK”><pattern type=” constant ” match=” f l a g ” order=”1” count=”1”>.</pattern><r e s u l t type=” co lour ” value=”blue ”/>
</ru le></ru l e s >
Listing 4.2: Example rules file for identifying packets containing ACK
4.4.3 Graph Rendering
This module is responsible for drawing the graph, displaying it on screen and generatingthe PDF file. The input will be a list of Packets created by the log parser and modified bythe rules engine.
The main problem for the graph rendering component is how to display the data. Therequirements specify that packets must be displayed as arrows from source to destinationand back. A decision must also be made as to how to display the additional labels i.e. thepacket headers and any information from the rules engine.
The program is executed from the command line with arguments and xml files controllingthe functionality. Therefore the interface to display the graph does not need to be inter-active. It only serves one purpose, as stated in the requirements; “to display the graphon screen”. Figure A.1 illustrates the desired look for this interface. Noticeably, the onlyinteraction that the user will have with the program is with the scroll bar which will allowthe user to see the entirety of the image.
Figure A.2 shows the design for the basic graph without any added data from the rulesengine. The source IP address will be displayed on the left and the destination on theright. To the left hand side of each arrow is the time the packet was sent which must beconverted to a relative time in seconds and milliseconds rather than the actual time givenin the packets timestamp.
The two ways which are going to be implemented for the rules engine to display resultsare colouring of the packets and adding a label next to the corresponding packets. This isshown in the design figures A.3 and A.4.
CHAPTER 4. DESIGN 19
4.5 Usage
The program must be executed from the command line, as stated by the requirementsdocument. It should be possible to run it in the following way:
./tcpdumpvis <tcpdump_filename> [-r rules_filename] [-o pdf_filename]
This means that the only mandatory argument is the tcpdump filename. Optionally, therules file can be specified with the -r switch and giving the filename and the pdf specifiedwith -o and its filename.
4.6 Design conclusion
The design stage highlighted the main modules of the program and discussed their tasks ata high level. This abstraction allowed for identification of the interfaces between moduleswithout worrying about implementation details.
The design stage could have been reinforced at this point by referring back to the require-ments and verifying that each requirement has been considered in the design.
Chapter 5
Implementation and Testing
This chapter is a review of the implementation algorithms, issues, testing and a critique ofthese processes.
5.1 Language
Consideration of which language to use was taken in order to achieve a successful develop-ment. The main technical features which the language must provide for were examined.
• Reading from text files.
• Parsing XML files.
• Drawing graphs.
• Creating PDF documents.
It is of course possible to perform these tasks in the majority of high-level languages,perhaps by using additional libraries, therefore the task was selection of a language mostappropriate based on simplicity, minimal dependencies and ease of use.
Java was the initial language of choice, with a vast collection of libraries to choose from,however this language was rejected in favour of Qt. Qt is a cross-platform frameworkusing C++. The reason it was chosen instead of Java is because it provides better supportfor drawing with the use of the QPainter class. The language is heavily designed aroundcross-platform support and is not dependant on a virtual machine. This would allow forextension amongst all variants of unix/linux operating systems which is crucial for thesuccess of the tool.
20
CHAPTER 5. IMPLEMENTATION AND TESTING 21
5.2 Detailed explanation of implementation
5.2.1 Control
This is the module (class TCPGraph) which is responsible for interfacing between the otherfunctional modules (see figure 4.1).
The process begins with the sorting of command line arguments. There must be a minimumof two arguments for the program to function, this is the location of the tcpdump log fileand the command used to run the program (which by default is always the first elementin the argument list). The maximum number of expected arguments is six, anything moreand the program prints usage information and exits. The third argument is examined, if itis “-r” then the following argument is the location of the rules file and if it is “-o” then thefollowing argument is the desired name of the PDF output. The same process is appliedto the 5th and 6th arguments.
The control module now initialises the graph rendering class (RenderArea) which is alsoresponsible for the Packet list. A pointer to this list is retrieved from RenderArea and passedto the rules engine which is initialised and parses the rules file. This allows both modulesto access the same Packet list, the list of Packet objects which contain the informationabout each line of the input file.
The log parsing module (DumpHandler) is now initialised and receives an argument whichcontains the location of the log. The DumpHandler parsing function is called repeatedlyand each time it returns a hash table of the fields contained in the next line of tcpdumpoutput. The control module takes the values in this hash and creates a new Packet object.This Packet is passed to the RenderArea which adds it to the Packet list).
Once this process is complete, all Packets have been created and are processed by the rulesengine.
Finally, the visualisation must be generated. The size of the window must be set - thewidth is always constant but the length varies depending on the number of packets. It isknown how much space each packet takes up on-screen so this is multiplied by the numberof packets to get the total length of the window which is enclosed in a scroll area. AQPrinter is created and passed to a function within the rendering module which createsthe PDF. The RenderArea is then displayed on the screen.
5.2.2 Log parsing
The only function this module has is to read the tcpdump log file line by line and return ahash table (QHash) of the fields (packet headers) which are contained within that line. Thedecision which had to be made was how to separate those fields. Each field is separated bywhitespace. Therefore the line is split into an array by whitespace character.
10:55:39.474882 IP 192.168.2.148.53249 > 192.168.2.57.hbci: Flags [S],
CHAPTER 5. IMPLEMENTATION AND TESTING 22
seq 3176377061, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TSval 33437871 ecr 0,sackOK,eol], length 0
When the line above is split, it produces the following array (only first part shown):
[0] 10:55:39.474882
[1] IP
[2] 192.168.2.148.53249
[3] >
[4] 192.168.2.57.hbci:
[5] Flags
[6] [S],
[7] seq
[8] 3176377061,
We can use the known positions for each of the standard fields to assign their values into theQHash. For example, timestamp will always be at position 0 and source address at position2. Notice, in the example line given and all other lines that the timestamp is followed bythe word “IP” and the source and destination are separated by the character “>”. It isknown that these characters are stored in the array at position 1 and 3 respectively so wejust ignore these. Note that for the destination address at position 4 we have to removethe last character, the ‘:’ before adding the value to the QHash.
From position 5 onwards, the order in which fields appear is not certain. To tackle thesefields we look at each position and compare the string to different possibilities. If thestring is identifiable then we know that the i+1 position holds the value for that field. Forexample, we discover that position 5 matches the word “Flags” which means position 6holds the flags value to add into the QHash. We apply the same logic to positions 7 and 8to get the sequence number and continue with this for the remaining elements.
Once all fields are added, the hash table is returned to the control module which builds thePacket.
5.2.3 Rules engine
The rules engine is responsible for both parsing the rules file and processing the packets tospot sequences which match the user-defined rules.
CHAPTER 5. IMPLEMENTATION AND TESTING 23
Processing rules
This begins by opening the rules file and reading it into memory (QDomDocument). Eachrule element is extracted into a list. We now wish to process each rule in order to createa representation of it within the program. For each rule we create a new Rule object.Every child of rule is either a pattern or a result. The Rule and Pattern classes containaccessors and mutators for each of their properties where as pattern and result elementsrepresents each of their properties as an XML attribute. In order to find their associatedaccessor and mutator, a programming feature called reflection is used. This works bybuilding a string based on the attribute name, which will then match the mutator functionname. For example, the attribute count would mean construction of the function namesetcount(). This enables the rules engine to call the correct mutator based on the attributename and improves maintainability. If we need to add a new attribute to the Pattern or Ruleclass, it is just a matter of adding the variable and its associated accessors and mutatorsand the rules engine will be able to process those attributes without any of its code beingchanged.
It does get slightly more complicated because attributes have different types and thereforedifferent mutators will have different parameter types. Table 5.1 shows the different typesan attribute could hold. This is important because when calling the mutator function usingreflection we cannot just specify empty parenthesis as shown in the example above, we haveto give the correct parameter type also in order to be able to call that function. We mustalso find out whether to convert the attribute value to an enumerated type or leave the valueas it is. This is done by building three different strings, one for each type. For the examplegiven above we would build; setcount(QString), setcount(int), setcount(long). Qthas a function which allows us to find the index of a given function name, it returns -1 ifno such function exists. Therefore we call this lookup on all three of the built strings. Twowill return -1 and one will return a valid index. We now know the type of the attribute weare dealing with and can convert it to an enumerated type if necessary (when the type isint) and call the correct mutator to set the value.
Table 5.1: Attribute typesType Used For ExampleQString Custom strings for colours; “blue”, “green”long Any integer For defining expected window size: 1335int Enumerated types {ACK, SYN, WIN}
The program uses enumerated types to represent the different packet headers or patterntypes (constant or average). This allows for faster integer comparisons rather than stringcomparisons when iterating over data. Naturally, in the rules XML, the different headersare referred to by their names. We need to convert these names to their enumerated type.In Qt it is not possible to convert from a string to the enumerated type that has alreadybeen associated with it. In order to do this a helper function has been implemented to
CHAPTER 5. IMPLEMENTATION AND TESTING 24
store a mapping between the string itself and its integer representation.
Finally, to call a function using reflection you must pass in the object that holds thefunctions you wish to access. In order to pass in the correct object depending on whetherthe child is a pattern or a result, we perform a string comparison on it’s node name andassign either the pattern or the rule object to a parent variable QObject which is thenpassed into the reflection call. This means we do not have to have two sets of reflectivecalls for both patterns and results.
This is repeated for all other rules and completes the rule parsing stage.
Rule matching
Once all rules and packets have been parsed. The program applies the rules to the packets.The rule matching works by iterating over rules, patterns and packets. It begins by takingeach rule in turn and setting a ‘base’ index into the list as 0, the first packet in the list.The rule is applied to the packets beginning from the base index, any matches are handledand then the base increments.
When a rule is applied, each pattern within the rule is taken in turn. If a pattern is oftype constant, i.e. a comparison between the value of a field with one given in the patterndefinition, then the order attribute specifies which packet to examine in relation to thebase. This is calculated the following way:
Packet index = base + (pattern order attribute - 1)
For example, if the base is 0, the following pattern would examine the packet at index 2which is the third packet in the list.
<pattern type="constant" match="win" order="3" origin="source">5200</pattern>
If the pattern is of type average then in addition to the order attribute being used tocalculate the first packet to examine, the count attribute is also used to decide how manyconsecutive packets to include in the average calculation.
Figure 5.1 shows this process taking place for a rule with one pattern which is of typeaverage, with order = 1 and count = 3. The first iteration shows that the average iscalculated with packets 1, 2 and 3 (because the base is 0), then this group of three shiftsdown the list by one and the average is calculated again. This continues until the end ofthe list is reached. The second iteration starts at packet 2, 3 and 4 and works in the sameway. The iterations continue until there is not enough packets below the base to satisfythe value of count. This means the given example ends after the third iteration because ifattempting a fourth iteration, only packet 4 and packet 5 remain in the list which does notallow us to take an average over three packets.
CHAPTER 5. IMPLEMENTATION AND TESTING 25
Packet 1
Packet 2
Packet 3
Packet 4
Packet 5
Packet 1
Packet 2
Packet 3
Packet 4
Packet 5
Packet 1
Packet 2
Packet 3
Packet 4
Packet 5
Packet 1
Packet 2
Packet 3
Packet 4
Packet 5
Packet 1
Packet 2
Packet 3
Packet 4
Packet 5
Packets being compared with current pattern.
Legend
Packets not being compared with current pattern.
Packets already compared with this rule.
Packet 1
Packet 2
Packet 3
Packet 4
Packet 5
First iteration, base = 0
Second iteration, base = 1
Third iteration, base = 2
Figure 5.1: Rule and pattern matching algorithm for a pattern of type average
At this stage, the necessity of the order attribute may be unclear. Remember that rulescan have multiple patterns. For example, a rule which identifies a connection-open wouldneed to specify the order of which its patterns should occur; SYN (order = 1), SYN-ACK(order = 2) ACK (order = 3).
In order to decide whether a rule has entirely matched, when each packet is examined anddeclared a match, it is added to a new list of packets, called matched. As soon as a packetis found to not match the rule, the base is incremented, the matched list is cleared andprocessing begins again. Once all patterns have been matched for the current rule, weapply the result to all packets in the matched list. The packets in the list will have theresult specified within the rule applied to them, for example, a colour. Each element in thematched list just holds a pointer to the original packet - any changes made to the packets inthis list will be reflected by the packets held in the original list held by the graph rendering
CHAPTER 5. IMPLEMENTATION AND TESTING 26
module. This allows the graph rendering module to recognise the changes that the rulesengine has applied to the packets.
5.2.4 Graph rendering
The RenderArea class is responsible for displaying the packets on the graph. The moduleis used to add packets when they are created. The first packet that is added is declaredthe source address, as outlined in the requirements.
When the drawGraph() function is called, it calculates the coordinates for the first line.Lines are drawn by using four coordinates. x1, y1 represents the starting point of the line,x2, y2 represents the end point.
Each packet is drawn onto the graph by using the following algorithm:
1. Calculate time difference between this packet and last.
2. Construct the line label.
This is done by checking whether each of the header variables within the packet objecthave a value assigned to them. If they have, the header name and value is appendedto the label. The flags are a special case and must be handled differently. Generally,each flag is added to the label and they are surrounded by square brackets. The ’.’flag which indicates the packet is an ACK is not added to the label because the ACKvalue is displayed separately anyway. Therefore, if this is the only flag held by thatpacket we must know not to draw the surrounding square brackets. This is done byfirst checking that there are flags, then checking the number of flags is is not equalto one (will only be greater than 1 if the ack flag is present) OR the the first flag isnot ’.’ (the ack flag will always be the second flag). If both of these conditions aretrue, draw the first square bracket, append each flag as long as it is not the ack flagand then draw the closing square bracket.
3. Compare the direction of this line with the last and calculate coordinates.
The program compares the source field of the packet and the address we rememberedfrom the first packet to decide whether this is a packet originating from the source ordestination. If the packet originates from the source, it begins on the left hand sideof the screen. The set of the coordinates for the line must be calculated based on thelast packet drawn. An integer is used to represent the direction of the last packet. 0means left to right, 1 means right to left. If the last packet drawn originated from thesource and so does the packet we are currently drawing then the y-axis only needs tobe increased. Where as if the last packet drawn originated from the right, the x-axismust be set back to the correct value for drawing from left-to-right as well as they-axis increase. The same principle applies to lines changing direction the oppositeway.
CHAPTER 5. IMPLEMENTATION AND TESTING 27
4. Draw the line.
If the packet has the colour field set, the brush must be changed to that colour andthen reverted back to the original afterwards.
5. Draw the arrow head.
This is done by drawing a polygon based on the calculated coordinates.
6. Add the time.
Once again, this is based on the calculated coordinates
7. Add the line label.
If the rules engine has added an additional label display this to the right of the packet.
8. Set the previous line direction value, 0 or 1.
Drawing the PDF document
The algorithm above takes a QPaintDevice parameter which is used to initialise the QPainterobject which does the drawing. In order to draw the PDF document, the same function iscalled but a QPrinter is passed which has been setup to write to a pdf document.
The difficulty with using QPrinter is that we have to manually control pagination. Thismeans that the painting system is not aware that it has reached the end of the page andtherefore does not know to create a new one. When calculating the coordinates for paintingon-screen we can just keep incrementing for each new packet that is drawn. It is not assimple as this for printing. Each page is represented as a new set of coordinates with 0,0being the top left corner of the page.
In order to differentiate our algorithm to work with the QPrinter we can check if we arecurrently painting an image onto the graphical user interface or the PDF document. Thisis done by attempting to cast the QPaintDevice to a QPrinter. Succeeding to do so meanswe have a QPrinter and therefore we need to control the pages and coordinate system.Each packet has a standard size on-screen. It was calculated that 18 packets fit onto a pageof A4. Each time we cross 18 packets, a new page is created and the coordinate systemis set back to the original coordinates. We must also print the side lines and the hostand destination label at the top of the page. This is done for every page, unlike for theon-screen representation where it is only done once.
CHAPTER 5. IMPLEMENTATION AND TESTING 28
5.3 Implementation conclusion
Issues
The main issue that the solution does not address is the variation in tcpdump log filesbetween different operating systems. Currently the implementation is only programmed tohandle the mac version of tcpdump. This works by having knowledge of additional char-acters that should be ignored when parsing the input. A proposed solution to the problemhas been developed. This is discussed in the improvements section of the conclusion.
Due to unfamiliarity with the language their may be parts of the program which are notwritten as succinctly as they could be. Therefore the source code would benefit fromrefactoring.
Summary
This chapter has provided a detail description of the workings of the program. This wouldallow someone who wishes to extend the project to understand every aspect of the currentimplementation.
5.4 Testing
This section demonstrates correct operation of the program and verifies the requirements.
5.4.1 Methodology
The testing method used focuses around the requirements and aims of the project. Testcases were written. Each test case specifies the input to the program; the command toexecute, associated rules file and the expected output. The test cases are are designedto verify that each of the requirements have been correctly implemented. Test cases werewritten to provide for both positive and negative testing. This is to ensure that the programdoes what is supposed to do and does not do anything it shouldn’t. Following developmentand execution of test cases, requirements were individually examined in order to determinesuccess or failure. This style of testing results in discovery of any bugs that are presentand also reveals parts of the implementation that are missing.
5.4.2 Testing environment
The test cases were executed on a computer running OS X. The Qt framework is cross-platform compatible so code should also compile on any computer with Qt installed.
CHAPTER 5. IMPLEMENTATION AND TESTING 29
5.4.3 Test Cases
These are the results from the test cases that are listed in the appendix.
Table 5.2: Results from execution of test casesTest # Pass/Fail Test # Pass/Fail1 PASS 2 PASS3 PASS 4 PASS5 PASS 6 PASS7 PASS 8 PASS9 PASS 10 PASS11 PASS 12 PASS13 PASS 14 PASS15 PASS 16 PASS17 PASS 18 PASS19 PASS 20 PASS21 PASS 22 PASS23 PASS 24 PASS25 PASS 26 PASS27 PASS 28 PASS29 PASS
5.4.4 Requirements Verification
Table 5.3 examines each requirement and marks each as pass or fail according to evidencegiven from test cases.
CHAPTER 5. IMPLEMENTATION AND TESTING 30
Table 5.3: Functional requirements verification
Requirement # Pass/Fail Evidence1 PASS Testing environment was OS-X, a unix based operating sys-
tem1.1 PASS Graphs clearly show interaction between two computers1.2 PASS This logic can be seen by comparing example files with output
graphs2 PASS The graph shows the tcpdump data on each line2.1 PASS Screenshots demonstrate the arrows2.2 PASS Screenshots2.3 PASS Screenshots3 PASS Test cases show using rules files3.1 PASS The example rules files (see appendix) are XML3.2 PASS Test case using rules 16.xml passes3.3 PASS The example rules files (see appendix) contain patterns3.4 PASS Example rules files3.4.1 PASS This is the match attribute within pattern, rules XSD (List-
ing 4.1)3.4.2 PASS This is text of pattern element, rules XSD (Listing 4.1)3.4.3 PASS This is the order attribute of pattern element, rules XSD
(Listing 4.1)3.5 PASS Test case using rules 17.xml passes4 PASS Screenshots show annotations added to graph4.1 PASS Example rules files and test cases4.2 PASS Example rules files and test cases4.3 PASS Labelling demonstrated in test cases5 PASS Test cases5.1 PASS Test cases6 PASS Test cases6.1 PASS Test cases6.2 PASS Test cases6.3 PASS Test cases
5.4.5 Non-functional requirements verification
The first requirement specifies that the program should run on as many operating systemsas possible. In order to achieve this, the program was developed in Qt. Whilst thisrequirement has been achieved from an execution perspective, there are still limitationswith parsing the tcpdump created by different architectures. This is something which mustbe rectified in order to both execute the program and parse a tcpdump created on the same
CHAPTER 5. IMPLEMENTATION AND TESTING 31
machine.
The program should be useable by those who are colourblind. In order to tackle thisrequirement, the user is able to change the colours of packets within the rules system.They also have the ability to label packets rather than use colours at all.
The program should not crash when given an invalid log file. This is requirement has beenmet because test case 3 uses a tcpdump with a malformed line.
5.4.6 Testing Conclusion
The test results clearly demonstrate that the requirements set out before implementationhave been met. This demonstrates a successful design and implementation.
Although all test cases passed, there were some issues that were identified. The mainproblem was when multiple rules matched the same packet. The rule which was appliedlast overwrote any changes made by previous rules. For example, if a rule matched a packetand coloured it blue and is followed by a rule matching the same packet and colouring itred; the packet would be displayed in red and colour related to the first rule would be lost.A solution to this problem is suggested later, in the evaluation section. There is also apeculiar problem with rendering that when scrolling down and then returning to the topof the image, the host and destination label along with the first arrow is distorted.
In critique of the testing process, it is noted that the program has only undergone white-box testing. The requirements have been verified and the program is shown to be working,but this does not do anything to ensure usability. There was no qualitative testing ofthe program by potential users. Further testing in this area would have been helpful indeciding what could be improved from a user interface stand point. There is no test oraclefor these test cases because an image is produced therefore a mechanism could not bewritten which compares actual text output with expected output. This made the testinga time consuming process because each rule match had to be compared by hand with thetcpdump input file in order to validate it.
Chapter 6
Conclusions
In this chapter we review the success of the project in relation to the aims and objectivesoutlined in the introduction. This is followed by identification of improvements and furtherworks. Finally, we critically analyse the project process and critique our own learning.
6.1 Achievements
The project implementation was successful in achieving the objective given in the projecttitle, the visualisation of tcpdump data. This allows users to capture tcpdump data to a fileand the implemented program will transform this file into a graph. The graph is successfullydisplayed both on-screen and in a PDF file, allowing for distribution of the visualisation. Amajor objective was to provide the ability to display additional information in the form ofcolours, labels and other methods on the visualisation. This goal was also achieved, withthe screenshots showing evidence of the colours and labels.
The literature survey analysed the ability of graphics systems such as PGF which allowsfor generation of images from text instructions. It was suggested that this system wasused to generate the image. In actual fact, the project achieves the result by using part ofthe Qt framework to draw the image manually i.e. by specifying coordinates for paintingand building the image up this way. From this we achieved graphs that were tailored toour exact requirements and they were not limited to assumptions on the way somethingshould look which would be made by other graphics systems. This will allow for muchmore flexible development of the program if further improvements and works were to beimplemented. This task was quite difficult because the coordinates had to be calculated todraw everything in the correct place and according to the size of the window.
Initially, it was planned that the program will have built in procedures for identifyinguseful or interesting characteristics within the tcpdump data. This objective was developedfurther and instead a system was developed which allows the user to manually definepatterns which are of interest to them. This even allows them to specify the way in which
32
CHAPTER 6. CONCLUSIONS 33
they wish the additional data to be visualised. This is a massive achievement compared towhat was originally expected. This makes the system much more flexible for an individualsneeds because it allows them unlimited selection of patterns to suit their own requirements.
The implementation of the rules system is an achievement because the concentration wason producing code that is as dynamic as possible. As a result, the parsing of the rulesfile is impressive in that the name of each attribute is used to generate code to store theattributes value into the corresponding variable.
6.2 Improvements
Naturally, there are improvements that could be made in order to enhance the system.The program works well for the functionality that has been implemented. As the test caseresults show, there are not any known bugs.
The correct way of handling rules which match the same packets is currently not defined.This means that rules can clash with each other and overwrite the changes to the packetdetails that have been made by one another. A simple solution to this would be to set asalience attribute for each rule. This would allow prioritising rules so that if multiple rulesmatch the same packet(s) then the rule with the highest salience can be applied.
When designing the system, the names given to attributes within the rules file were notgiven enough thought. This means that they are potentially confusing for the user. Thisis something that user acceptance testing would have discovered. For example, the originattribute allows the user to specify either ‘source’ or ‘destination’. Arguably the source isthe computer which the packet originated from but in this context it actually means whetherthe packet originates from the computer initiating the connection and running tcpdump(source) or the computer that is being connected to (destination). This could be clearer byusing the terms ’local’ and ’remote’. Another example is the match attribute which allowsthe user to specify which field they wish to compare to, this is perhaps better representedas ‘field’. A third example is the pattern type ‘constant’ which is used to compare theexact value of a field with the value given in a pattern. This doesn’t particularly relate tothem term constant so perhaps ’equality’ would be better. These are just three examplesof confusing names, but more exist.
The way the system parses tcpdump data is hardcoded. This could be improved by usingregular expressions to match each of the fields in the tcpdump file and even allowing theuser to specify their own regular expressions to support different output formats of tcpdumpversions.
Finally, there are areas of the code that are not satisfactory in terms of maintainability. Thebest example of this is the graph rendering module. The RenderArea class has completelyduplicated code (other than coordinates) for drawing a line from left-to-right and right-to-left. This should be re-factored to use the same code and calculate different coordinatesaccording to direction of line.
CHAPTER 6. CONCLUSIONS 34
6.3 Future works
The project provides a good foundation for further development. There were ideas thatwere had before, during and after implementation that give scope for further work on thisproject.
6.3.1 Rules Engine
The rules engine provides the fundamental workings of a system for defining and executingrules. This should be extended further to allow for definition of different pattern typesother than ‘constant’ and ‘average’. A suggestion for a different type is one which allowsthe user to specify a percentage range for increase or decrease of a particular value over anumber of packets. If the increase or decrease of a value is within the specified range, it isconsidered a match. This would allow users to look for a gradual increase in window size,perhaps an indication of tcp slow start. Adding more different types will result in a farmore flexible system.
Currently the only way users can create rules is if they know how the XML should bewritten. An extension to the project would be to create a rules generator which would be agraphical user interface that allows easy specification of different patterns. This would thengenerate the XML automatically. This would make the program easier to use for those notas experienced with creating XML files.
6.3.2 Interface
There is another development that could be done to make the system easier to use for thosethat dislike the command line. It would be useful to have a part of the user interface whichallows users to locate and load a tcpdump file. This would work alongside the suggesteduser interface for defining rules.
6.3.3 Visualisation
There are a few things which could be done to extend the visualisation. Firstly, it would beuseful for the program to generate a legend which shows the colour of packets and the ruleassociated with that colour. This would make it much easier for users to identify whichpackets matched which rule by cross-referencing the colours with the legend rather thanthe rules file.
Currently, there are only two ways of adding annotations to rules - colours and labels. Aworthwhile further work would be to add many ways of annotating the graph. One exampleof such would be having information shown in tooltips when the mouse is hovered over eachpacket. The system is limited on how much information can be added to the graph withoutmaking it more complicated and difficult to read than the raw tcpdump data itself.
CHAPTER 6. CONCLUSIONS 35
The graph only shows data between two computers. It would be useful to extend theprogram to work with more than two computers i.e. to show the connections betweenone computer and any other computer it communicates with. This has the potential ofproducing cluttered graphs if arrows start overlapping each other.
6.3.4 Real-time analysis
An exciting extension would be to incorporate the capture of tcpdump data into the pro-gram. This would allow for creation of the graph in real-time whilst maintaining a con-nection to the tcpdump data. This would be relatively simple to implement. Instead ofthe current action of reading from a file, the system would need to be modified to readfrom a process’ standard output. Controls would be implemented to start and stop capturefrom the user interface. For the rules engine to successfully operate in this environmentthe system would need to constantly evaluate rules against packets. This would be fairlyresource heavy so there should be an option to display packets in realtime and then oncecapture stops, apply the rules. Once this is implemented, we have the basis of a real-timemonitoring system that could be extended to generate alerts if particular rules are matchedagainst captured packets.
6.4 Critical Analysis
Requirements were difficult to complete fully without any experience of this kind of system.Ideally there would have been another iteration of requirements and design after someimplementation had been completed. This would have allowed for incorporation of ideasthat were discovered at the implementation phase.
The design stage was extremely useful to implementation. It meant that the programwas planned at a high-level meaning that implementation was easy to begin because eachmodule had to be programmed and then connected to each other. Ideally, the design stagewould have gone into even more detail to inform implementation. This would have lead tobetter code which perhaps wouldn’t need refactoring as the current version does.
A lot of the implementation time was spent learning the correct syntax of the programminglanguage. This cannot be helped but it does mean that similar projects would be imple-mented faster. If the program was to be written again from scratch, each module wouldbe more streamlined with much less code duplication and there would be shorter functionsdefinitions with high cohesion by introducing more helper functions.
The rules system was an extension to the project after conception, originally these ruleswere going to be hardcoded into the system. Upon reflection, this was without doubt agood decision. Much of the code that would have to be written to hardcode rules was alsoused as part of the rules engine anyway. This did increase the amount of development timethat had to be spent on rules though. As a result, there was less time available to spendon visualisation. This meant that the graphs produced are not quite perfect. For example,
CHAPTER 6. CONCLUSIONS 36
any tcpdump spanning a large period of time will mean that the time displayed on the lefthand side will over run into the graph area. Also, any labels that are added to the righthand side of the graph have the potential of spilling of the edge of the page i.e. there is notext wrapping. The label running along the line of each packet was intended to follow theangle of the line (see A.2) but instead remains horizontal.
It is not obvious what the correct syntax of the rules file is. In order for users to effectivelyoperate the program, it should be supplied with pre-written rules, these could not only beused for visualisation but also to provide an explanation for users to learn how to developtheir own rules.
In summary, the project outcome is the successful visualisation of tcpdump data. Theresulting program is a cross-platform compatible tool that could be used by network ad-ministrators or education institutions to help with their understanding of tcpdump.
Bibliography
Combs, G. (n.d.), ‘Wireshark coloring rules’, http://wiki.wireshark.org/ColoringRules.
Corporation, N. (n.d.), ‘Qpainter class reference’, http://doc.trolltech.com/4.6/qpainter.html.
Fuentes, F. and Kar, D. C. (2005), ‘Ethereal vs. tcpdump: a comparative study on packetsniffing tools for educational purpose’, J. Comput. Small Coll. 20(4), 169–176.
Jacobson, V., Leres, C. and McCanne, S. (n.d.a), ‘tcpdump manpage’, http://www.tcpdump.org/tcpdump_man.html.
Jacobson, V., Leres, C. and McCanne, S. (n.d.b), ‘tcpdump website’, http://www.tcpdump.org.
Kretchmar, J. (2004), ‘Tcpdump: An open source tool for analyzing packets’, inform IT .
Microsystems, S. (n.d.), ‘java.awt.geom library’, http://java.sun.com/javase/7/docs/api/java/awt/geom/package-summary.html.
O’Reilly (n.d.), ‘Network troubleshooting tools’, http://docstore.mik.ua/orelly/networking_2ndEd/tshoot/ch05_04.htm.
Sommerville, I. (2006), Software Engineering: (Update) (8th Edition), Addison Wesley.
Stevens, W. R. (1996), TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP,NNTP, and the UNIX Domain Protocols, Addison-Wesley Professional.
Tantau, T. (n.d.), ‘Pgf sourceforge’, http://sourceforge.net/projects/pgf/.
UKAI, F. (n.d.), ‘3d-tcpdump website’, http://www.3d-tcpdump.org.
37
Appendix A
Design Diagrams
TCPDump Visualisation
< GRAPH >
Figure A.1: Graph visualisation display window design
38
APPENDIX A. DESIGN DIAGRAMS 39
0ms
4ms8ms
10ms
packet information
packet information
packet information
packet information
Source Destination
Figure A.2: Design of tcpdump graph without additional annotations
APPENDIX A. DESIGN DIAGRAMS 40
0ms
4ms8ms
10ms
packet information
packet information
packet information
packet information
Source Destination
Figure A.3: Design of tcpdump graph with coloured rule match
APPENDIX A. DESIGN DIAGRAMS 41
0ms
4ms8ms
10ms
packet information
packet information
packet information
packet information
Source Destination
Figure A.4: Design of tcpdump graph with additional labels
Appendix B
Test Files
dump 1.txt and dump 2.txt are included on the accompanying compact disk.
42
Appendix C
Test cases
Test 1
Execution steps
Start program without any arguments
./tcpdumpvis
Expected result
Usage information printed and program exit
Test 2
Execution steps
Start program with 1 argument - an invalid tcpdump location.
./tcpdumpvis dump_1.txt
Expected result
Error message and usage information printed, exit
43
APPENDIX C. TEST CASES 44
Test 3
Execution steps
Start program with 1 argument - tcpdump location. tcpdump file has invalid line (times-tamp malformed).
./tcpdumpvis dump_2.txt
Expected result
Print specific error and exit
Test 4
Execution steps
Start program with 1 argument - tcpdump location.
./tcpdumpvis dump_1.txt
Expected result
Graph should be displayed with no rules annotations. pdf output with default filename
Test 5
Execution steps
Start program with 2 arguments - tcpdump location and rules file location (missing -rswitch)
./tcpdumpvis dump_1.txt rules_1.txt
Expected result
Print usage and exit
APPENDIX C. TEST CASES 45
Test 6
Execution steps
Start program with 2 arguments - tcpdump location and output pdf location (missing -oswitch)
./tcpdumpvis dump_1.txt out.pdf
Expected result
Print usage and exit
Test 7
Execution steps
Start program with 3 arguments - tcpdump location, output switch and output filename
./tcpdumpvis dump_1.txt -o test.pdf
Expected result
Show graph, PDF produced - filename as given in args
Test 8
Execution steps
Start program with 3 arguments - tcpdump location, rules switch and rules location.rules 1.xml is a simple rules file with one rule containing one pattern matching on thelength field.
./tcpdumpvis dump_1.txt -r rules_1.xml
APPENDIX C. TEST CASES 46
Expected result
Show graph with any packets which have length = 0, highlighted in red, pdf output withdefault filename
Test 9
Execution steps
Start program with 3 arguments - tcpdump location, rules switch and rules location.rules 2.xml is as rules 1.xml but with the colour set to blue.
./tcpdumpvis dump_1.txt -r rules_2.xml
Expected result
Show graph with any packets which have length = 0, highlighted in blue, pdf output withdefault filename
Test 10
Execution steps
Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisrule tests labelling for matching rules (no colouring).
./tcpdumpvis dump_1.txt -r rules_18.xml
Expected result
Show graph with any packets which have length = 0, labelled from rule, pdf output withdefault filename
APPENDIX C. TEST CASES 47
Test 11
Execution steps
Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisrule tests labelling AND colouring for matching rules.
./tcpdumpvis dump_1.txt -r rules_19.xml
Expected result
Show graph with any packets which have length = 0, labelled and coloured red from rule,pdf output with default filename
Test 12
Execution steps
Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis to test the pattern type ’constant’ on the ack field. Will match any packets with ack =1.
./tcpdumpvis dump_1.txt -r rules_3.xml
Expected result
Show graph with any packets which have ack = 1, highlighted in blue, pdf output withdefault filename
Test 13
Execution steps
Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis to test the pattern type ’constant’ on the win field. Will match any packets with win =65535.
./tcpdumpvis dump_1.txt -r rules_4.xml
APPENDIX C. TEST CASES 48
Expected result
Show graph with any packets which have win = 1, highlighted in blue, pdf output withdefault filename
Test 14
Execution steps
Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis to test the pattern type ’constant’ on the flags field. Will match any packets with S flagset.
./tcpdumpvis dump_1.txt -r rules_5.xml
Expected result
Show graph with any packets which have S flag highlighted in blue, pdf output with defaultfilename
Test 15
Execution steps
Start program with 3 arguments - tcpdump location, rules switch and rules location. This isto test the pattern type ’constant’ but only include packets originating from source address.
./tcpdumpvis dump_1.txt -r rules_6.xml
Expected result
Show graph with any packets which have length = 0 AND originate from source addresshighlighted in blue, pdf output with default filename
APPENDIX C. TEST CASES 49
Test 16
Execution steps
Start program with 3 arguments - tcpdump location, rules switch and rules location. This isto test the pattern type ’constant’ but only include packets originating from source address.
./tcpdumpvis dump_1.txt -r rules_7.xml
Expected result
Show graph with any packets which have length = 0 AND originate from destination ad-dress highlighted in blue, pdf output with default filename
Test 17
Execution steps
Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis to test the pattern type ’average’. Taking the length field and average over 3 packets,looking for an average of 965
./tcpdumpvis dump_1.txt -r rules_8.xml
Expected result
Show graph with all occurrences (there is at least one) highlighted in blue pdf output withdefault filename
Test 18
Execution steps
Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis to test the pattern type ’average’ with an average range specified. Taking the lengthfield and average over 3 packets, looking for an average between 500-1000
./tcpdumpvis dump_1.txt -r rules_10.xml
APPENDIX C. TEST CASES 50
Expected result
Show graph with all occurrences (there is at least one) highlighted in blue pdf output withdefault filename
Test 19
Execution steps
Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis to test the pattern type ’average’ with origin=destination. Taking the length field andaverage over 3 packets that originate from the destination, looking for an average of 506.
./tcpdumpvis dump_1.txt -r rules_9.xml
Expected result
Show graph with all occurrences (there is at least one) highlighted in blue pdf output withdefault filename
Test 20
Execution steps
Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis to test the pattern type ’average’ with origin=source. Taking the length field and averageover 3 packets that originate from the source, looking for an average of 130.
./tcpdumpvis dump_1.txt -r rules_11.xml
Expected result
Show graph with all occurrences (there is at least one) highlighted in blue. Pdf outputwith default filename
APPENDIX C. TEST CASES 51
Test 21
Execution steps
Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis to test the pattern type ’average’ and using count = 1. This means taking the averageof 1 packet which is equivalent to using the constant pattern type. This rule will colour allpatterns with 0 length.
./tcpdumpvis dump_1.txt -r rules_12.xml
Expected result
Show graph with all occurrences coloured in blue pdf output with default filename
Test 22
Execution steps
Start program with 3 arguments - tcpdump location, rules switch and rules location. Thispattern tries to match the average type on a field which is non-integer: flags
./tcpdumpvis dump_1.txt -r rules_13.xml
Expected result
Error message and no rule matches.
Test 23
Execution steps
Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis a more complex rule with two patterns. Both of which are constants. The rule matchesfor two packets in a row with length = 0.
./tcpdumpvis dump_1.txt -r rules_14.xml
APPENDIX C. TEST CASES 52
Expected result
Show graph with all occurrences highlighted in blue. Pdf output with default filename
Test 24
Execution steps
Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis another complex rule with a constant followed by an average.
./tcpdumpvis dump_1.txt -r rules_15.xml
Expected result
Show graph with all occurrences highlighted in blue. Pdf output with default filename
Test 25
Execution steps
This a test of having multiple rules in a file. The rules have different colours assigned tothem.
./tcpdumpvis dump_1.txt -r rules_16.xml
Expected result
The graph should have all three colours displayed on it correctly identifying each of thematched rules. Pdf output with default filename
Test 26
Execution steps
Start program with 5 arguments - tcpdump location, rules switch, rules location, outputswitch, output filename. rules 1.xml is a simple rules file with one rule containing one
APPENDIX C. TEST CASES 53
pattern matching on the length field.
./tcpdumpvis dump_1.txt -r rules_1.xml -o output.pdf
Expected result
Show graph with any packets which have length = 0, highlighted in red, pdf output withfilename: output.pdf
Test 27
Execution steps
Start program with 5 arguments - tcpdump location, output switch, output filename, rulesswitch, rules location. I.e. testing having the switches in reverse order to previous rule.rules 1.xml is a simple rules file with one rule containing one pattern matching on thelength field.
./tcpdumpvis dump_1.txt -o output.pdf -r rules_1.xml
Expected result
Show graph with any packets which have length = 0, highlighted in red, pdf output withfilename: output.pdf
Test 28
Execution steps
Start program with 3 arguments - tcpdump location, rules switch, rules location. This is arule designed to recognise tcp connection establishment.
./tcpdumpvis dump_1.txt -r rules_connection_open.xml
Expected result
Show graph with tcp open coloured in blue, pdf output with filename: output.pdf
APPENDIX C. TEST CASES 54
Test 29
Execution steps
Start program with 5 arguments - tcpdump location, rules switch, rules location. This is arule file with malformed XML, negative test.
./tcpdumpvis dump_17.txt -r rules_connection_open.xml
Expected result
Print error malformed XML and exit
55
APPENDIX D. SCREENSHOTS 56
Appendix D
Screenshots
Figure D.1: Screenshot of the GUI. This is the initial view that is shown once processingis complete.
APPENDIX D. SCREENSHOTS 57
Figure D.2: Screenshot of the GUI. This is the view of the interface once the user hasscrolled down.
APPENDIX D. SCREENSHOTS 58
Figure D.3: Screenshot of the GUI. This is an example of both colouring and labellingannotations with rules 19.xml.
APPENDIX D. SCREENSHOTS 59
Figure D.4: This is a screenshot of the generated PDF open in Preview.
Appendix E
Code
60
AP
PE
ND
IXE
.C
OD
E61
E.1 File: dumphandler.cpp
#include ”dumphandler . h”
DumpHandler : : DumpHandler ( QString f i leName ) :dump( f i leName ) ,t s (&dump) ,out ( stdout )
{dump . open ( QIODevice : : ReadOnly ) ;
}
DumpHandler : : ˜ DumpHandler ( ) {dump . c l o s e ( ) ;
}
QHash<QString , QString> DumpHandler : : readLine ( ){
QString l i n e ;QString d e s t i n a t i on ;QStr ingLi s t p a i r s L i s t ;QHash<QString , QString> pairTable ;QTextStream out ( stdout ) ;i f ( t s . atEnd ( ) ) {
return pairTable ;}l i n e = t s . readLine ( ) ;/∗ S p l i t s t r i n g by whi tespace ∗/p a i r s L i s t = l i n e . s p l i t ( ” ” , QString : : SkipEmptyParts )
;i f ( p a i r s L i s t . s i z e ( ) == 0)
return pairTable ;/∗ Put the en t r i e s with a f i x e d l o c a t i on in to t a b l e
∗/pairTable [ ” timestamp” ] = ( QString ) p a i r s L i s t . at (0 ) .
trimmed ( ) ;pa i rTable [ ” source ” ] = p a i r s L i s t . at (2 ) . trimmed ( ) ;d e s t i n a t i on = ( QString ) p a i r s L i s t . at (4 ) . trimmed ( ) ;d e s t i n a t i on . chop (1 ) ;pa i rTable [ ” d e s t i n a t i on ” ] = de s t i n a t i on ;
/∗ Look at each other entry and put in to t a b l e ∗/for ( int i = 5 ; i < p a i r s L i s t . s i z e ( ) ; i++) {
QString cPair = ( QString ) p a i r s L i s t . at ( i ) . trimmed( ) ;
QString trimmed ;i f ( cPair == ”Flags ” ) {
trimmed = pa i r s L i s t . at ( i +1) ;trimmed . chop (1 ) ;pa i rTable [ ” f l a g s ” ] = trimmed ;
}else i f ( cPair == ” seq ” ) {
trimmed = pa i r s L i s t . at ( i +1) ;trimmed . chop (1 ) ;pa i rTable [ ” seq ” ] = trimmed ;
}else i f ( cPair == ”win” ) {
trimmed = pa i r s L i s t . at ( i +1) ;trimmed . chop (1 ) ;pa i rTable [ ”win” ] = trimmed ;
}else i f ( cPair == ”ack” ) {
trimmed = pa i r s L i s t . at ( i +1) ;trimmed . chop (1 ) ;pa i rTable [ ”ack” ] = trimmed ;
}else i f ( cPair == ” length ” ) {
trimmed = pa i r s L i s t . at ( i +1) ;pa i rTable [ ” l ength ” ] = trimmed ;
}}
i f ( ! QRegExp( ” [0 −9 , : .A−Za−z ]+” ) . exactMatch (pa i rTable [ ” timestamp” ] ) )
{p r i n t f ( ”Malformed tcpdump f i l e here :\n” ) ;p r i n t f ( pa i rTable [ ” timestamp” ] . toLat in1 ( ) . data ( )
) ;e x i t (1 ) ;
}return pairTable ;
}
AP
PE
ND
IXE
.C
OD
E62
E.2 File: main.cpp
#include <QApplication>#include ” tcpgraph . h”
int main ( int argc , char ∗argv [ ] ){
QApplication app ( argc , argv ) ;QScrol lArea s c r o l l ;TCPGraph ∗graph = new TCPGraph( ) ;s c r o l l . setWidget ( graph ) ;s c r o l l . setGeometry ( ( int ) ( QApplication : : desktop ( )−>
width ( ) −
( QApplication : : desktop ( )−>width ( ) −( QApplication : : desktop ( )−>width ( ) / 2) ) ∗ 1 . 5 ) / 2 ,( int ) ( QApplication : : desktop ( )−>he ight ( ) −
( QApplication : : desktop ( )−>he ight ( ) −( QApplication : : desktop ( )−>he ight ( ) / 2) ) ∗ 1 . 5 ) /
2 ,( int ) ( ( QApplication : : desktop ( )−>width ( ) −
( QApplication : : desktop ( )−>width ( ) / 2) ) ∗ 1 . 5 ) ,( int ) ( ( QApplication : : desktop ( )−>he ight ( ) −
( QApplication : : desktop ( )−>he ight ( ) / 2) ) ∗ 1 . 5 ) ) ;s c r o l l . show ( ) ;s c r o l l . setMinimumSize (855 , 200) ;s c r o l l . setMaximumSize (855 , 1000) ;return app . exec ( ) ;
}
AP
PE
ND
IXE
.C
OD
E63
E.3 File: packet.cpp
#include ”packet . h”
Packet : : Packet ( QString source , QString d e s t i n a t i on ){
QStr ingLi s t s o u r c e Sp l i t = source . s p l i t ( ’ . ’ ) ;QStr ingLi s t d e s t S p l i t = de s t i n a t i on . s p l i t ( ’ . ’ ) ;QString quad ;int count = 0 ;f o r each ( quad , s o u r c e Sp l i t ) {
i f ( count > 3)break ;
this−>source . append ( quad ) ;this−>source . append ( ” . ” ) ;count++;
}count = 0 ;f o r each ( quad , d e s t Sp l i t ) {
i f ( count > 3)break ;
this−>de s t i n a t i on . append ( quad ) ;this−>de s t i n a t i on . append ( ” . ” ) ;count++;
}this−>source . chop (1 ) ;this−>de s t i n a t i on . chop (1 ) ;
}
void Packet : : addFie ld ( int type , QString value ) {switch ( type ) {case SEQ:
seq = value ;break ;
case ACK:ack = value . toDouble ( ) ;break ;
case WIN:win = value . t o In t ( ) ;break ;
case COLOUR:co l ou r = value ;break ;
case FLAGS:
/∗Put each f l a g in to QChar array ∗/for ( int p = 0 ; p < value . l ength ( ) ; p++) {
i f ( va lue . at (p) == ’ [ ’ )continue ;
else i f ( va lue . at (p) == ’ ] ’ )break ;
elsef l a g s . append ( value . at (p) ) ;
}break ;
case TIMESTAMP:/∗ crea t e new timestamp QTime remove l a s t 3
decimal p l a c e s from mi l l i s e c ond s f i r s t ∗/value . chop (3) ;timestamp = QTime : : f romStr ing ( value , ”hh :mm: s s .
zzz ” ) ;break ;
case LENGTH:length = value . t o In t ( ) ;break ;
case LABEL:l a b e l = value ;break ;
}}
QString Packet : : g e tF i e l d ( int f i e l d ) {switch ( f i e l d ) {case SEQ:
return seq ;break ;
case ACK:return QString : : number ( ack ) ;break ;
case WIN:return QString : : number (win ) ;break ;
case COLOUR:return co l ou r ;break ;
case SOURCE:return source ;break ;
case DESTINATION:
AP
PE
ND
IXE
.C
OD
E64
return de s t i n a t i on ;break ;
case LENGTH:return QString : : number ( l ength ) ;break ;
}return ”” ;
}
AP
PE
ND
IXE
.C
OD
E65
E.4 File: pattern.cpp
#include ” pattern . h”
Pattern : : Pattern ( QObject ∗parent ) :QObject ( parent )
{}
void Pattern : : s e t type ( int type ) {this−>type = type ;
}
void Pattern : : setmatch ( int match ) {this−>match = match ;
}
void Pattern : : s e t o rd e r ( long order ) {this−>order = order ;
}
void Pattern : : s e t o r i g i n ( int o r i g i n ) {this−>o r i g i n = o r i g i n ;
}
void Pattern : : s e tcount ( long count ) {this−>count = count ;
}
void Pattern : : s e t va lu e ( QString value ) {this−>value = value ;
}
int Pattern : : gettype ( ) {return this−>type ;
}
int Pattern : : getmatch ( ) {return this−>match ;
}
long Pattern : : g e to rde r ( ) {return this−>order ;
}
int Pattern : : g e t o r i g i n ( ) {return this−>o r i g i n ;
}
long Pattern : : getcount ( ) {return this−>count ;
}
QString Pattern : : g e tva lue ( ) {return this−>value ;
}
AP
PE
ND
IXE
.C
OD
E66
E.5 File: renderarea.cpp
#include <QtGui>#include ” renderarea . h”#include <QPrinter>
RenderArea : : RenderArea (QWidget ∗parent ): QWidget ( parent )
{setBackgroundRole ( QPalette : : Base ) ;setAutoFi l lBackground ( true ) ;
}
QSize RenderArea : : minimumSizeHint ( ) const{
return QSize (800 , 500) ;}
QSize RenderArea : : s i z eH in t ( ) const{
i f ( y2 == 0)return QSize (800 , 1000) ;
elsereturn QSize (800 , ( packets . l ength ( ) ∗40 + 40) ) ;
}
int RenderArea : : getGraphHeight ( ) {return packets . s i z e ( ) ∗80 ;}
/∗ Add an arrow to the graphd i r e c t i on = 1 , hos t −> de s t i na t i ond i r e c t i on = 0 , hos t <− de s t i na t i on ∗/
void RenderArea : : addPacket ( Packet ∗packet ) {packets . append ( packet ) ;/∗ I f t h i s i s the f i r s t packet , s e t the hos t and
de s t i na t i on ∗/i f ( this−>host . compare ( ”” ) == 0) {
this−>host = packet−>source ;this−>de s t i n a t i on = packet−>de s t i n a t i on ;this−>f i r s tT ime = packet−>timestamp ;
}
}
QList<Packet∗>∗ RenderArea : : ge tPacketL i s t ( ) {return &packets ;
}
void RenderArea : : paintEvent ( QPaintEvent ∗ /∗ event ∗/ ){
drawGraph ( this ) ;}
void RenderArea : : drawGraph ( QPaintDevice ∗ paint ) {QPainter pa in t e r ( pa int ) ;pa in t e r . setPen (Qt : : b lack ) ;pa in t e r . setBrush (QBrush (Qt : : b lack ) ) ;pa in t e r . setRenderHint ( QPainter : : Ant i a l i a s i ng , true ) ;QFont painterFont = QFont ( ) ;
QString l a b e l ;pa interFont . s e tPo in tS i z e (8 ) ;pa in t e r . setFont ( painterFont ) ;
QString ms ;
int prev ious = −1;for ( int i = 0 ; i < packets . l ength ( ) ; i++) {
QPrinter ∗ p r i n t e r ;i f ( ( p r i n t e r = dynamic cast<QPrinter∗> ( pa int ) ) !=
0) {i f ( i%18==0 && i !=0) {
/∗Draw s i de l i n e s ∗/pa in t e r . drawLine (150 , 15 , 150 , y2+5) ;pa in t e r . drawLine ( width ( ) −150, 15 , width ( )
−150, y2+5) ;
/∗Draw host , d e s t i na t i on t e x t ∗/pa in t e r . drawText (150−(( host . l ength ( ) ∗4)
/2) , 10 , host ) ;pa in t e r . drawText ( width ( )−150−((
d e s t i n a t i on . l ength ( ) ∗4) /2) , 10 ,d e s t i n a t i on ) ;
p r in t e r−>newPage ( ) ;/∗ Set l i n e s t a r t p o s i t i on ∗/
AP
PE
ND
IXE
.C
OD
E67
x1 = 150 ; y1 = 20 ;x2 = width ( ) −150; y2 = 40 ;
}}
/∗Ca lcu la t e timestamp d i f f e r e n c e in ms then s ∗/int difms = f i r s tT ime . msecsTo ( packets . at ( i )−>
timestamp ) ;i f ( di fms >= 1000) {
double s e c s = f l o o r ( di fms /1000) ;double remainingMs = difms − s e c s ∗1000 ;ms = QString : : number ( s e c s ) ;ms += ” sec ” ;ms += QString : : number ( remainingMs ) ;ms += ”ms” ;
}else {
ms = QString : : number ( di fms ) ;ms += ”ms” ;
}
/∗Construct l i n e l a b e l based on g iven packet data∗/
l a b e l = ”” ;i f ( ! packets . at ( i )−> f l a g s . empty ( ) ) {
i f ( packets . at ( i )−> f l a g s . s i z e ( ) != 1 | |packets . at ( i )−> f l a g s . at (0 ) != ’ . ’ ) {l a b e l . append ( ” [ ” ) ;for ( int f = 0 ; f < packets . at ( i )−> f l a g s .
l ength ( ) ; f++) {i f ( packets . at ( i )−> f l a g s . at ( f ) == ’ . ’ )
continue ;i f ( f != 0)
l a b e l . append ( ” ” ) ;l a b e l . append ( packets . at ( i )−> f l a g s . at (
f ) ) ;}l a b e l . append ( ” ] ” ) ;
}}i f ( packets . at ( i )−>seq != 0) {
l a b e l . append ( ”SEQ ” ) ;l a b e l . append ( packets . at ( i )−>seq ) ;
}i f ( packets . at ( i )−>ack != 0) {
l a b e l . append ( ” ACK ” ) ;l a b e l . append ( QString : : number ( packets . at ( i )−>
ack , ’ f ’ , 0 ) ) ;}i f ( packets . at ( i )−>win != 0) {
l a b e l . append ( ” WIN ” ) ;l a b e l . append ( QString : : number ( packets . at ( i )−>
win ) ) ;}l a b e l . append ( ” l ength ” ) ;l a b e l . append ( QString : : number ( packets . at ( i )−>
l ength ) ) ;
i f ( packets . at ( i )−>source . compare ( this−>host ) ==0) {/∗Drawing l i n e from L−>R∗/switch ( prev ious ) {case −1:
/∗ Set l i n e s t a r t p o s i t i on ∗/x1 = 150 ; y1 = 20 ;x2 = width ( ) −150; y2 = 40 ;break ;
case 0 :x1 = 150 ; y1 = y2 + 20 ;x2 = width ( ) −150; y2 = y2 + 40 ;break ;
case 1 :x1 = 150 ; y1 = y1 + 40 ;x2 = width ( ) −150; y2 = y2 + 40 ;break ;
}i f ( pr intCoords )
p r i n t f ( ”Line %d : x1 = %d y1 = %d x2 =%d y2 = %d\n” , i , x1 , y1 , x2 , y2
) ;i f ( packets . at ( i )−>co l ou r != ”” ) {
pa in t e r . setPen (QColor ( packets . at ( i )−>co l ou r ) ) ;
pa in t e r . setBrush (QBrush ( QColor (packets . at ( i )−>co l ou r ) ) ) ;
}pa in t e r . drawLine ( x1 , y1 , x2 , y2 ) ;stat ic const QPoint po in t s [ 3 ] = {
QPoint (0 , 0) ,
AP
PE
ND
IXE
.C
OD
E68
QPoint (−5 , −5) ,QPoint (−5 , 5)
} ;
/∗Adding the arrow Head∗/pa in t e r . save ( ) ;pa in t e r . t r a n s l a t e ( x2 , y2 ) ;pa in t e r . drawPolygon ( points , 3) ;pa in t e r . r e s t o r e ( ) ;pa in t e r . setPen (Qt : : b lack ) ;pa in t e r . setBrush (QBrush (Qt : : b lack ) ) ;
/∗Adding the timestamp∗/pa in t e r . drawText ( x1−50, y1 , ms) ;
/∗Add a l a b e l ∗/pa in t e r . save ( ) ;pa in t e r . drawText ( x1 , y1−15, x2−x1 , 24 , Qt
: : AlignHCenter , l abe l , NULL) ;pa in t e r . r e s t o r e ( ) ;
/∗Add annotat ion from ru l e i f t he re i sone∗/
i f ( packets . at ( i )−> l a b e l != ”” )pa in t e r . drawText ( x2+20, y2 , packets .
at ( i )−> l a b e l ) ;
/∗Set t h i s l i n e as prev ious ∗/prev ious = 1 ;
}else {
/∗Drawing l i n e from R−>L∗/switch ( prev ious ) {case −1:
/∗ Set l i n e s t a r t p o s i t i on ∗/x1 = width ( ) −150; y1 = 20 ;x2 = 150 ; y2 = 40 ;break ;
case 0 :y1 = y1 + 40 ;x2 = 150 ; y2 = y2 + 40 ;break ;
case 1 :x1 = x2 ; y1 = y2 + 20 ;x2 = 150 ; y2 = y2 + 40 ;
break ;
}i f ( pr intCoords )
p r i n t f ( ”Line %d : x1 = %d y1 = %d x2 = %dy2 = %d\n” , i , x1 , y1 , x2 , y2 ) ;
i f ( packets . at ( i )−>co l ou r != ”” ) {pa in t e r . setPen (QColor ( packets . at ( i )−>
co l ou r ) ) ;pa in t e r . setBrush (QBrush ( QColor ( packets . at
( i )−>co l ou r ) ) ) ;}pa in t e r . drawLine ( x1 , y1 , x2 , y2 ) ;
/∗Adding the arrow Head∗/pa in t e r . save ( ) ;pa in t e r . t r a n s l a t e ( x2 , y2 ) ;stat ic const QPoint po int s2 [ 3 ] = {
QPoint (0 , 0) ,QPoint (5 , −5) ,QPoint (5 , 5)
} ;pa in t e r . drawPolygon ( points2 , 3) ;pa in t e r . r e s t o r e ( ) ;pa in t e r . setPen (Qt : : b lack ) ;pa in t e r . setBrush (QBrush (Qt : : b lack ) ) ;
/∗Adding the timestamp∗/pa in t e r . drawText ( x2−50, y2 , ms) ;
/∗Add a l a b e l ∗/pa in t e r . save ( ) ;pa in t e r . drawText ( x2 , y1−15, x1−x2 , 24 , Qt : :
AlignHCenter , l abe l , NULL) ;pa in t e r . r e s t o r e ( ) ;
/∗Add l a b e l from annotat ions ∗/i f ( packets . at ( i )−> l a b e l != ”” )
pa in t e r . drawText ( x1+20, y1 , packets . at ( i )−> l a b e l ) ;
/∗Set t h i s l i n e as prev ious ∗/prev ious = 0 ;
}
AP
PE
ND
IXE
.C
OD
E69
}
/∗Draw s i de l i n e s ∗/pa in t e r . drawLine (150 , 15 , 150 , y2+5) ;pa in t e r . drawLine ( width ( ) −150, 15 , width ( ) −150, y2
+5) ;
/∗Draw host , d e s t i na t i on t e x t ∗/
pa in t e r . drawText (150−(( host . l ength ( ) ∗4) /2) , 10 ,host ) ;
pa in t e r . drawText ( width ( )−150−(( d e s t i n a t i on . l ength( ) ∗4) /2) , 10 , d e s t i n a t i on ) ;
pa in t e r . end ( ) ;
updateGeometry ( ) ;}
AP
PE
ND
IXE
.C
OD
E70
E.6 File: rule.cpp
#include ” ru l e . h”
Rule : : Rule ( QObject ∗parent ) :QObject ( parent )
{index = counter ;counter++;
}
void Rule : : addPattern ( Pattern ∗pat ) {pat t e rns . append ( pat ) ;
}
void Rule : : s e t type ( int type ) {this−>type = type ;
}
void Rule : : s e t va l u e ( QString value ) {this−>value = value ;
}
QString Rule : : g e tva lue ( ) {
return value ;}
int Rule : : gettype ( ) {return type ;
}
QString Rule : : t oS t r i ng ( ) {QString s t r i n g ( ”Rule ” + QString : : number ( index ) + ”
type : ” + QString : : number ( type ) + ” value : ” +value ) ;
s t r i n g . append ( ”\n” ) ;for ( int i = 0 ; i < pat t e rns . s i z e ( ) ; i++) {
s t r i n g . append ( ”\ t ” ) ;s t r i n g . append ( ”Pattern : type : ” + QString : : number
( pat t e rn s . at ( i )−>gettype ( ) ) + ” match : ” +QString : : number ( pat t e rns . at ( i )−>getmatch ( ) ) +” order : ” + QString : : number ( pat t e rn s . at ( i )−>ge to rde r ( ) ) + ” o r i g i n : ” + QString : : number( pat t e rn s . at ( i )−>g e t o r i g i n ( ) ) + ” value : ” +pat t e rns . at ( i )−>getva lue ( ) ) ;
s t r i n g . append ( ”\n” ) ;}return s t r i n g ;
}
AP
PE
ND
IXE
.C
OD
E71
E.7 File: rulesengine.cpp
#include ” ru l e s eng i n e . h”
RulesEngine : : RulesEngine ( QList<Packet∗> ∗ packetL i s t ,QString r u l e s F i l e )
{this−>packets = packe tL i s t ;this−>r u l e s F i l e = r u l e s F i l e ;
}
int RulesEngine : : parseRules ( ) {QTextStream out ( stdout ) ;
QDomDocument doc ( ” r u l e s ” ) ;QFile f i l e ( r u l e s F i l e ) ;i f ( ! f i l e . open ( QIODevice : : ReadOnly ) )
return −1;i f ( ! doc . setContent ( &f i l e ) ){
f i l e . c l o s e ( ) ;p r i n t f ( ”Malformed r u l e s f i l e !\n” ) ;e x i t (1 ) ;
}/∗Get each Rule∗/QDomNodeList r u l e s = doc . elementsByTagName ( ” ru l e ” ) ;for ( int i = 0 ; i < r u l e s . s i z e ( ) ; i++) {
QDomNode ru l e = ru l e s . at ( i ) ;/∗Create new ru l e ∗/Rule ∗newRule = new Rule ( ) ;QDomNodeList ch i l d r en = ru l e . chi ldNodes ( ) ;for ( int j = 0 ; j < ch i l d r en . s i z e ( ) ; j++) {
QDomNode ch i l d = ch i l d r en . at ( j ) ;/∗Create a new pat t e rn ∗/Pattern ∗newPattern = new Pattern ( ) ;int i sPa t t e rn = 0 ;QDomNamedNodeMap a t t r i b u t e s = ch i l d .
a t t r i b u t e s ( ) ;for ( int k = 0 ; k < a t t r i b u t e s . s i z e ( ) ; k
++) {i f ( ! a t t r i b u t e s . item (k ) . i sNu l l ( ) ) {
/∗Bui ld method name with i n tparameter ∗/
QString intMethod = ” s e t ” +a t t r i b u t e s . item (k ) . nodeName ( )+ ” ( i n t ) ” ;
/∗Bui ld method name with longparameter ∗/
QString longMethod = ” s e t ” +a t t r i b u t e s . item (k ) . nodeName ( )+ ” ( long ) ” ;
/∗Bui ld method name with QStringparameter ∗/
QString str ingMethod = ” s e t ” +a t t r i b u t e s . item (k ) . nodeName ( )+ ” ( QString ) ” ;
/∗Bui ld method name wi thout theparameters f o r use withinvokeMethod ∗/
QString methodName = ” s e t ” +a t t r i b u t e s . item (k ) . nodeName ( );
out << methodName ;out << ” ” ;QObject ∗ ob j e c t ;const QMetaObject∗ meta ;i f ( c h i l d . nodeName ( ) == ” pattern ” )
{ob j e c t = newPattern ;meta = newPattern−>metaObject
( ) ;i sPa t t e rn++;out << ” pattern \n” ;
}else {
ob j e c t = newRule ;meta = newRule−>metaObject ( ) ;
}i f (meta−>indexOfS lot (QMetaObject
: : normal i zedS ignature (intMethod . toLat in1 ( ) . data ( ) ) )!= −1) {
QMetaObject : : invokeMethod (object , methodName .toLat in1 ( ) . data ( ) , Qt : :AutoConnection , Q ARG( int, Types : : lookupEnum(a t t r i b u t e s . item (k ) .
AP
PE
ND
IXE
.C
OD
E72
nodeValue ( ) ) ) ) ;}else i f (meta−>indexOfS lot (
QMetaObject : :normal i zedS ignature (longMethod . toLat in1 ( ) . data ( ) )) != −1) {QMetaObject : : invokeMethod (
object , methodName .toLat in1 ( ) . data ( ) , Qt : :AutoConnection , Q ARG(long , a t t r i b u t e s . item (k ) .nodeValue ( ) . toLong ( ) ) ) ;
}else i f (meta−>indexOfS lot (
QMetaObject : :normal i zedS ignature (str ingMethod . toLat in1 ( ) . data( ) ) ) != −1) {QMetaObject : : invokeMethod (
object , methodName .toLat in1 ( ) . data ( ) , Qt : :AutoConnection , Q ARG(QString , a t t r i b u t e s . item (k ) . nodeValue ( ) ) ) ;
}}
}/∗Set the va lue f o r t h i s pa t t e rn ∗/i f ( i sPa t t e rn ) {
newPattern−>s e t va lu e ( c h i l d . toElement( ) . t ex t ( ) ) ;
newRule−>addPattern ( newPattern ) ;}
}/∗Add Rule to r u l e s L i s t ∗/r u l e s L i s t . append ( newRule ) ;
}f i l e . c l o s e ( ) ;/∗Print out a l l r u l e s ∗/for ( int a = 0 ; a < r u l e s L i s t . s i z e ( ) ; a++) {
out << r u l e s L i s t . at ( a )−>t oS t r i ng ( ) ;out << ”\n” ;
}
return 0 ;}
void RulesEngine : : p roces sPacket s ( ) {QTextStream out ( stdout ) ;/∗ Take each ru l e ∗/for ( int r = 0 ; r < r u l e s L i s t . s i z e ( ) ; r++) {
Rule ∗ r u l e = r u l e s L i s t . at ( r ) ;/∗Move the base ( f i r s t packet to look at ) a long
the l i s t o f packe t s ∗/for ( int b = 0 ; b < packets−>s i z e ( ) ; b++) {
int ruleBroken = 0 ;QList<Packet∗> matched ;/∗ Look at each pa t t e rn . Process i t according
to the type ∗/for ( int p = 0 ; p < ru le−>pat t e rns . s i z e ( ) ; p
++) {Pattern ∗pat = ru le−>pat t e rns . at (p) ;/∗Work out which packet to look at
according to the order a t t r i b u t e inthe pa t t e rn and the current base ∗/
int pos = ( pat−>ge to rde r ( ) − 1) + b ;i f ( pos < packets−>s i z e ( ) ) {
Packet ∗pack = packets−>at ( pos ) ;i f ( pat−>gettype ( ) == CONSTANT) {
/∗Before doing any checks , makesure source / d e s t i na t i on match.
I f source / d e s t i na t i on nots p e c i f i e d in pa t t e rn thenassume we can match frome i t h e r ∗/
i f ( pat−>g e t o r i g i n ( ) == SOURCE) {/∗ I s the packet we have from
source ?∗/i f ( packets−>at (0 )−>ge tF i e l d (
SOURCE) != pack−>source ){out << ”No f l a g match
when b = ” + QString: : number (b) + ”\n” ;
ruleBroken++;break ;
}}
AP
PE
ND
IXE
.C
OD
E73
else i f ( pat−>g e t o r i g i n ( ) ==DESTINATION) {/∗ I s the packet we have from
de s t i na t i on ?∗/i f ( packets−>at (0 )−>ge tF i e l d (
DESTINATION) != pack−>source ) {out << ”No source /
d e s t i n a t i on matchwhen b = ” + QString: : number (b) + ”\n” ;
ruleBroken++;break ;
}}
i f ( pat−>getmatch ( ) == FLAGS) {/∗Compare each char ∗/QString ru l eF l ag s = pat−>
getva lue ( ) ;/∗Check number o f f l a g s in
packet i s the same as inpa t t e rn ∗/
i f ( ru l eF l ag s . l ength ( ) != pack−>f l a g s . l ength ( ) ) {/∗ Al l f l a g s not found ∗/out << ”No f l a g match
when b = ” + QString: : number (b) + ”\n” ;
ruleBroken++;break ;
}int foundCurrentFlag ;for ( int i = 0 ; i < ru l eF l ag s .
l ength ( ) ; i++) {foundCurrentFlag = 0 ;for ( int j = 0 ; j < pack−>
f l a g s . l ength ( ) ; j++){i f ( ru l eF l ag s . at ( i ) ==
pack−>f l a g s . at ( j) ) {/∗Found t h i s f l a g
∗/
foundCurrentFlag++;
out << ”Foundf l a g : ” ;
out << ru l eF l ag s .at ( i ) ;
out << ”\n” ;}
}i f ( ! foundCurrentFlag ) {
/∗ Al l f l a g s notfound ∗/
out << ”No f l a g matchwhen b = ” +
QString : : number (b) + ”\n” ;
ruleBroken++;break ;
}}/∗ I f a l l f l a g s found , add
packet to matched l i s t ∗/i f ( ruleBroken == 0)
matched . append ( pack ) ;}else {
i f ( pack−>ge tF i e l d ( pat−>getmatch ( ) ) == pat−>getva lue ( ) ) {/∗ This packet has
matched the pa t t e rn∗/
matched . append ( pack ) ;out << ”Made a match when
b = ” ;out << b ;out << ”\n” ;
}else {
/∗ Packet did not matchva lue in pa t t e rn ∗/
out << ”No match when b =” + QString : : number (
b) + ”\n” ;ruleBroken++;
AP
PE
ND
IXE
.C
OD
E74
break ;}
}}else i f ( pat−>gettype ( ) == AVERAGE) {
QString requ i r edSource = ”none” ;/∗Work out the requ i red source
address i f the packet i s to matchthe s p e c i f i e d o r i g i n ∗/
i f ( pat−>g e t o r i g i n ( ) == SOURCE) {r equ i r edSource = packets−>at (0 )−>
ge tF i e l d (SOURCE) ;}else i f ( pat−>g e t o r i g i n ( ) ==
DESTINATION) {r equ i r edSource = packets−>at (0 )−>
ge tF i e l d (DESTINATION) ;}/∗How many packe t s have been examined
and t h e i r sum − used fo raverages ∗/
int count = 0 ;int sum = 0 ;while ( count < pat−>getcount ( ) ) {
/∗ i f packet i s from cor r ec tsource or de s i r ed source i snot s p e c i f i e d then add toaverage ∗/
i f ( r equ i r edSource != pack−>ge tF i e l d (SOURCE) &&requ i r edSource != ”none” ) {i f (++pos >= packets−>s i z e ( ) )
break ;pack = packets−>at ( pos ) ;continue ;
}matched . append ( pack ) ;int va l = pack−>ge tF i e l d ( pat−>
getmatch ( ) ) . t o In t ( ) ;sum = sum + val ;out << ” value added to sum : ” +
QString : : number ( va l ) + ”\n” ;i f (++pos >= packets−>s i z e ( ) )
break ;count++;
pack = packets−>at ( pos ) ;}i f ( count >= pat−>getcount ( ) ) {
/∗Check average va lue . I f a rangecheck wi th in range ∗/
i f ( pat−>getva lue ( ) . conta in s ( ’− ’ ) ){
QString lower = pat−>getva lue( ) . s p l i t ( ’− ’ ) . at (0 ) ;
QString upper = pat−>getva lue( ) . s p l i t ( ’− ’ ) . at (1 ) ;
i f ( ! ( lower . t o In t ( ) <= sum/count && sum/count <=upper . t o In t ( ) ) ) {/∗ Packet did not match
average range inpa t t e rn ∗/
out << ”No average matchwhen b = ” + QString: : number (b) + ”\n” ;
ruleBroken++;matched . c l e a r ( ) ;break ;
}}else i f (sum/count != pat−>
getva lue ( ) . t o In t ( ) ) {/∗ Packet did not match
average va lue in pa t t e rn∗/
out << ”No average match whenb = ” + QString : : number (
b) + ” average : ” +QString : : number (sum/count) + ” sum : ” + QString : :number (sum) + ” count : ” +QString : : number ( count ) +”\n” ;
ruleBroken++;matched . c l e a r ( ) ;break ;
}}else {
AP
PE
ND
IXE
.C
OD
E75
/∗ Packet did not match va lue inpa t t e rn ∗/
out << ”No average match when b =” + QString : : number (b) + ”\n
” ;ruleBroken++;matched . c l e a r ( ) ;break ;
}}
}else {
/∗ Pos i t ion to check exceeds the numbero f packe t s ∗/
out << ” Pos i t i on to check exceeds numbero f packets \n” ;
ruleBroken++;break ;
}
}/∗ I f ruleMatched i s then mark r e l e v an t packe t s
with the r e s u l t ∗/i f ( ruleBroken == 0) {
out << ”Rule Matched ! ! ! ! when b = ” + QString: : number (b) + ”\n” ;
/∗Take each pa t t e rn in the ru l e and mark thecorresponding packet ∗/
for ( int i = 0 ; i < matched . s i z e ( ) ; i++) {matched . at ( i )−>addFie ld ( ru le−>gettype
( ) , ru l e−>getva lue ( ) ) ;}/∗ I f t h i s break i s removed , i t w i l l on ly
match once and then s top ∗/// break ;
}}
}}
AP
PE
ND
IXE
.C
OD
E76
E.8 File: tcpgraph.cpp
#include ” tcpgraph . h”#include <QPrinter>
TCPGraph : : TCPGraph( ){
QTextStream out ( stdout ) ;/∗Get program arguments∗/QStr ingLi s t args = QCoreApplication : : arguments ( ) ;i f ( args . l ength ( ) < 2 | | args . l ength ( ) > 6) {
pr intUsage ( ) ;}else {
dumpFile = args . at (1 ) ;for ( int arg = 2 ; arg < args . l ength ( ) −1; arg+= 2)
{i f ( args . at ( arg ) == ”−r ” ) {
r u l e s F i l e = args . at ( arg + 1) ;i f ( ! QFile : : e x i s t s ( r u l e s F i l e ) ) {
out << ” Inva l i d r u l e s f i l e s s p e c i f i e d” ;
pr intUsage ( ) ;}
}else i f ( args . at ( arg ) == ”−o” ) {
outputF i l e = args . at ( arg + 1) ;}else {
pr intUsage ( ) ;}
}}
renderArea = new RenderArea ;QGridLayout ∗mainLayout = new QGridLayout ;mainLayout−>setColumnStretch (0 , 1) ;mainLayout−>setColumnStretch (3 , 1) ;mainLayout−>addWidget ( renderArea ) ;mainLayout−>setRowMinimumHeight (1 , 6) ;setLayout ( mainLayout ) ;setWindowTitle ( t r ( ”TCPDump V i s u a l i s e r ” ) ) ;setBackgroundRole ( QPalette : : Dark ) ;
i f ( ! QFile : : e x i s t s ( dumpFile ) ) {p r i n t f ( ” Inva l i d tcpdump f i l e s p e c i f i e d .\n” ) ;pr intUsage ( ) ;
}DumpHandler ∗dumph = new DumpHandler ( dumpFile ) ;
QHash<QString , QString> returnedHash ;Packet ∗packet ;while ( ! ( returnedHash = dumph−>readLine ( ) ) . isEmpty
( ) ) {packet = new Packet ( returnedHash [ ” source ” ] ,
returnedHash [ ” d e s t i n a t i on ” ] ) ;packet−>addFie ld (FLAGS, returnedHash [ ” f l a g s ”
] ) ;packet−>addFie ld (SEQ, returnedHash [ ” seq ” ] ) ;packet−>addFie ld (ACK, returnedHash [ ”ack” ] ) ;packet−>addFie ld (WIN, returnedHash [ ”win” ] ) ;packet−>addFie ld (TIMESTAMP, returnedHash [ ”
timestamp” ] ) ;packet−>addFie ld (LENGTH, returnedHash [ ” l ength
” ] ) ;renderArea−>addPacket ( packet ) ;
}// I f a r u l e s f i l e has been s p e c i f i e di f ( r u l e s F i l e != ”” ) {
RulesEngine ∗ r u l e s = new RulesEngine (renderArea−>getPacketL i s t ( ) , r u l e s F i l e ) ;
ru l e s−>parseRules ( ) ;ru l e s−>proces sPacket s ( ) ;
}
QPrinter p r i n t e r ( QPrinter : : Sc reenReso lut ion ) ;i f ( outputF i l e == ”” )
p r i n t e r . setOutputFileName ( ”TCPDump V i s u a l i s a t i o n .pdf ” ) ;
else {QFi l e In fo f i ( outputF i l e ) ;p r i n t e r . setOutputFileName ( f i . f i leName ( ) ) ;
}p r i n t e r . s e tPageS i ze ( QPrinter : : A4) ;renderArea−>drawGraph(&p r i n t e r ) ;
}
void TCPGraph : : pr intUsage ( ) {
AP
PE
ND
IXE
.C
OD
E77
QTextStream out ( stdout ) ;p r i n t f ( ” usage : tcpdumpvis <dumpfi le> [− r r u l e f i l e ] [−o
pd f f i l ename ] ” ) ;
e x i t (1 ) ;}
AP
PE
ND
IXE
.C
OD
E78
E.9 File: types.cpp
#include ” types . h”
Types : : Type ( ){
addEnum(”ACK” , ACK) ;addEnum(”SEQ” , SEQ) ;addEnum(”WIN” , WIN) ;addEnum(”FLAG” , FLAG) ;addEnum(”SOURCE” , SOURCE) ;addEnum(”DESTINATION” , DESTINATION) ;addEnum(”CONSTANT” , CONSTANT) ;addEnum(”COLOUR” , COLOUR) ;
}
void Types : : addEnum( QString s t r , int enumInt ) {enumMap [ s t r ] = enumInt ;
}
int Types : : lookupEnum( QString s t r ) {i f (enumMap . conta in s ( s t r ) ) {
return enumMap [ s t r ] ;}else {
return −1;}
}
AP
PE
ND
IXE
.C
OD
E79
E.10 File: dumphandler.h
#ifndef DUMPHANDLERH#define DUMPHANDLERH
#include <QFile>#include <qtextstream . h>#include <iostream>#include <QStr ingList>#include <QLis t I t e ra to r >#include <QHash>
class DumpHandler
{public :
DumpHandler ( QString ) ;QHash<QString , QString> readLine ( ) ;˜DumpHandler ( ) ;
private :QFile dump ;QTextStream t s ;QTextStream out ;
} ;
#endif // DUMPHANDLERH
AP
PE
ND
IXE
.C
OD
E80
E.11 File: packet.h
#ifndef PACKET H#define PACKET H
#include <QString>#include <QTime>#include <QStr ingList>#include ” types . h”
class Packet{public :
Packet ( QString , QString ) ;void addFie ld ( int , QString ) ;
QString ge tF i e l d ( int f i e l d ) ;QTime timestamp ;QString source ;QString d e s t i n a t i on ;QString seq ;QString co l our ;QString l a b e l ;QList<QChar> f l a g s ;double ack ;int win ;int empty ;int l ength ;
} ;
#endif // PACKET H
AP
PE
ND
IXE
.C
OD
E81
E.12 File: pattern.h
#ifndef PATTERN H#define PATTERN H
#include <QObject>
class Pattern : public QObject{Q OBJECTpublic :
expl ic it Pattern ( QObject ∗parent = 0) ;
s i g n a l s :
public s l o t s :void s e t type ( int ) ;int gettype ( ) ;void setmatch ( int ) ;int getmatch ( ) ;void s e t o rd e r ( long ) ;long ge to rde r ( ) ;void s e t o r i g i n ( int ) ;int g e t o r i g i n ( ) ;
void se tcount ( long ) ;long getcount ( ) ;void s e t va lu e ( QString ) ;QString ge tva lue ( ) ;
private :/∗Type o f match e . g . equa l to s t r i n g va lue or average
va lue or % increase ∗/int type ;/∗ Which f i e l d to look at ∗/int match ;/∗ The packet number 1 , 2 , . . . , n I f matching on any
packet , use −1 ∗/long order ;/∗ Source or d e s t i na t i on ∗/int o r i g i n ;/∗ The number o f consecu t i v e packe t s we shou ld
inc lude f o r averages ∗/long count ;/∗ St r ing to match on i f e q u a l i t y check ∗/QString value ;
} ;
#endif // PATTERN H
AP
PE
ND
IXE
.C
OD
E82
E.13 File: renderarea.h
#ifndef RENDERAREA H#define RENDERAREA H
#include <QBrush>#include <QPen>#include <QPixmap>#include <QWidget>#include <QFont>#include <QList>#include <QString>#include <QTime>#include ”packet . h”#include <cmath>
// ! [ 0 ]class RenderArea : public QWidget{
Q OBJECT
public :RenderArea (QWidget ∗parent = 0) ;QSize minimumSizeHint ( ) const ;QSize s i z eH in t ( ) const ;
void addPacket ( Packet ∗) ;QList<Packet∗>∗ getPacketL i s t ( ) ;int getGraphHeight ( ) ;void drawGraph ( QPaintDevice ∗ paint ) ;
public s l o t s :
protected :void paintEvent ( QPaintEvent ∗ event ) ;
private :/∗ Line po s i t i on i n g ∗/int x1 ; int y1 ;int x2 ; int y2 ;/∗ Host and Des t ina t ion ∗/QString host ;QString d e s t i n a t i on ;QList<Packet∗> packets ;/∗Enable d i s a b l e p r i n t i n g coords ∗/stat ic const int pr intCoords = 0 ;/∗The f i r s t timestamp used to work out d i f f e r e n c e ∗/QTime f i r s tT ime ;
} ;// ! [ 0 ]
#endif
AP
PE
ND
IXE
.C
OD
E83
E.14 File: rule.h
#ifndef RULE H#define RULE H
#include <QObject>#include <QList>#include ” pattern . h”
stat ic int counter ;
class Rule : public QObject{Q OBJECTpublic :
expl ic it Rule ( QObject ∗parent = 0) ;QList<Pattern∗> pat t e rns ;
public s l o t s :void addPattern ( Pattern ∗) ;void s e t type ( int ) ;void s e t va lu e ( QString ) ;QString ge tva lue ( ) ;int gettype ( ) ;QString toS t r i ng ( ) ;
private :/∗ I d e n t i f i e s t h i s ru l e f o r matches ∗/int index ;/∗Set how to f l a g a match e . g . co lour ∗/int type ;/∗ Spec i f y what co lour ∗/QString value ;
} ;
#endif // RULE H
AP
PE
ND
IXE
.C
OD
E84
E.15 File: rulesengine.h
#ifndef RULESENGINE H#define RULESENGINE H
#include <QtXml>#include <QFile>#include <qtextstream . h>#include ” ru l e . h”#include ” types . h”#include <QHash>#include ”packet . h”
class RulesEngine
{public :
RulesEngine ( QList<Packet∗>∗ , QString ) ;int parseRules ( ) ;void proces sPacket s ( ) ;
private :QList<Rule∗> r u l e s L i s t ;QList<Packet∗> ∗ packets ;QString r u l e s F i l e ;
} ;
#endif // RULESENGINE H
AP
PE
ND
IXE
.C
OD
E85
E.16 File: tcpgraph.h
#ifndef TCPGRAPH H#define TCPGRAPH H
#include <QtGui>#include ” renderarea . h”#include <QWidget>#include ”packet . h”#include ” a s s e r t . h”#include ” types . h”#include <QGraphicsView>#include <QGraphicsScene>#include <QImage>#include ”dumphandler . h”#include <QHash>#include <QTextStream>#include <QScrollArea>#include <QStr ingList>#include ” ru l e s eng i n e . h”
QT BEGIN NAMESPACEclass QCheckBox ;
class QComboBox ;class QLabel ;class QSpinBox ;QT END NAMESPACEclass RenderArea ;
// ! [ 0 ]class TCPGraph : public QWidget{
Q OBJECT
public :TCPGraph( ) ;void pr intUsage ( ) ;
private s l o t s :
private :RenderArea ∗ renderArea ;QString dumpFile ;QString r u l e s F i l e ;QString outputF i l e ;
} ;// ! [ 0 ]
#endif
AP
PE
ND
IXE
.C
OD
E86
E.17 File: types.h
#ifndef TYPES H#define TYPES H
#include <QString>#include <QHash>
enum{/∗Tcpdump data f i e l d s ∗/ACK, SEQ, WIN, FLAGS, SOURCE, DESTINATION, TIMESTAMP,
LENGTH,/∗Types used fo r pa t t e rns ∗/CONSTANT, AVERAGE,/∗Rule r e s u l t t ypes ∗/COLOUR, LABEL
} ;
stat ic QHash<QString , int> enumMap ;
class Types {
public :stat ic int lookupEnum( QString s t r ) {
i f (enumMap . s i z e ( ) == 0)Types : : addEnums ( ) ;
return enumMap [ s t r ] ;}stat ic void addEnums ( ) {
enumMap [ ”ack” ] = ACK;enumMap [ ” seq ” ] = SEQ;enumMap [ ”win” ] = WIN;enumMap [ ” f l a g s ” ] = FLAGS;enumMap [ ” source ” ] = SOURCE;enumMap [ ” d e s t i n a t i on ” ] = DESTINATION;enumMap [ ” constant ” ] = CONSTANT;enumMap [ ” average ” ] = AVERAGE;enumMap [ ” co l ou r ” ] = COLOUR;enumMap [ ” l a b e l ” ] = LABEL;enumMap [ ”timestamp” ] = TIMESTAMP;enumMap [ ” l ength ” ] = LENGTH;
}} ;
#endif // TYPES H