Automated Analysis and representation of Packet Data from a Network Telescope

1. Automated Analysis and representation of Packet Data from a Network Telescope By: Samuel Oswald Hunter Supervisor: Mr Barry Irwin

2. The project: a dashboard framework for network telescopes Project Explanation Utilising a multitude of information, tools and prior research To create a re-usable framework, for analysis and understanding

3. Project Objectives • To develop a information visualisation framework to be used for network telescope data analysis and representation. • Monitor network telescope activity • Automate the information analysis process • Aggregate information • Discover and identify useful metrics • Find a good use for 27”+ screens  • Overcome mountains of data => to produce information • Display information in a manner that highlights it’s importance • Group useful and related information Project Objectives

4. Background Information A Network Telescope • Captures all traffic destined for a specified range of un-used address space. • Should receive no or VERY little legitimate traffic. • Network telescopes contribute towards our understanding of malicious activity on the internet • Help us to monitor events such as • Worm outbreaks • DDoS attacks • Using some math we can scale our results • although there are arguments against this, some researchers have found distinctively different traffic types on geographically separated address ranges. Background Information

5. Background Information Types of Network Telescopes • Active • Such as the IMS which makes use of a lightweight responder – to complete a TCP 3 way handshake. • Passive • Only captures what it is sent and has no ability to respond, the Rhodes (RUscope) network telescope is an example of such. Types of traffic • Active • Automated worm scanning and exploitation • Passive • Responses from DDoS attacks, worm exploitation attempts • Bad Traffic • If a network telescopes address range is discovered bad people WILL try to poison results Background Information

6. Background Information Rhodes Network Telescope • Monitors a class C address block – 254 addresses and the packet database I’m currently using contains 40,801,854 packets • Size matters – the size of a the address block used determines the probability of a network telescope observing an event Similar Technologies • Honeypots • Also collect malicious traffic – more aggressive as they go out looking for trouble • IDS’s • Monitors traffic over a network and matches malicious traffic with known signatures. Background Information

7. Background Information Dashboards • A dashboard is a graphical interface for information • Displaying important and relevant information in a easy to understand manner and should be able to convey information at a glance. • Information displayed on a dashboard should be grouped in a relevant and complimenting fashion. • Should be clear, concise, NO information overload, useful • Preferably pretty. Background Information

8. Back to my project... What I’ve accomplished thus far • Understanding the role of network telescopes in Information Security • Provide an overview of malicious activity • Provide an early warning sign to new outbreaks • Give as a glimpse of the dark side • Completed my literature review • As always, things need to be added • Written a paper on virtual honeypots which will find a home soon enough • Developed a dashboard framework • Still a bit of work to be done • Identified some metrics and have time to find some more 6. Outlined my final project thesis My Project

9. The Framework

10. Application Core DashGen.php graphScritp.php XMLConstructor.php graphScritp.php graphScritp.php graphScript.php DashConfig.xml

11. Things to note about the Dashboard and its graphs. • Each graph requires a graphScript (named after the unique graph) that contains all the information to construct that graph • Graphs are embedded in the html as .swf files (flash) • If the graphs are required to update their data sets, they do so via ajax requests to that graphScript.php file or in some cases update from data embedded in some javascript. • There is some really nice/naughty DOM manipulation going on behind the scenes Points of intrest

12. Dashboard representation and make-up Dashboard Structure The gauges container is still in development and for the moment will not yet be supported (generated) from the config.xml

13. Graph Container Example

14. Gauge container Example This is the first model I’ve come up with for the gauges container,  its a screenshot from the browser. I still have to integrate it with the rest of the DashBoard framework All of these gauges will update there values at some interval, currently testing 6-8 seconds but will see how things go after user testing

15. Dashboard Layout Current Layout proposal Container 1 Container 2 Container 5 Container 3 Container 4

16. Metrics and Container dynamics The metrics and graphs are still being decided on, I have a couple but am always looking for more and better onces. As things stand I have decided to make each container contain graphs pertaining to a certain type of analysis • Protocol Analysis • Traffic Analysis (Rate of traffic) • Geographic Graphs • Top N metrics • Gauges Container is its own monster The data layout

17. Putting it all together • I have my framework, but there’s clearly still some development to be done as the project has taken on a life of its own. • There’s still time left to get everything done, thus far my project is not behind schedule. • So where to from here... • Finish Implementation (2 Weeks) • Conduct usability testing (2 Weeks) • Make any changes that are needed (1 Week) • Finish final project thesis (1 November – (Now+5weeks)) • Document everything from step 1-3, too make step 4 more do-able • And of course in-between Step 1 and 4 there’s a Poster and Short paper, but alls fair in love and war. In closing

18. Some of the magic disappears without a demonstration, but that would have to wait until I’m 100% happy with the DashBoard. Questions Questions