NVisionIP: An Interactive Network Flow Visualization Tool ... - CiteSeerX

NVisionIP: An Interactive Network Flow Visualization Tool for Security ∗ Kiran Lakkaraju William Yurcik Ratna Bearavolu Adam J. Lee National Center for Supercomputing Applications (NCSA) University of Illinois, Urbana-Champaign {kiran, byurcik, ratna, adamlee}@ncsa.uiuc.edu Abstract – Security engineers are being overwhelmed with data from the network monitoring tools. A tool is needed that will allow security engineers to view information about the entire network. In addition, the tool must allow the security engineers to use their background knowledge and intuition. NVisionIP, a tool developed at the National Center for Supercomputing Applications at the University of Illinois, Urbana-Champaign, provides a visualization of a Class B network. Following the Visual Information Seeking Mantra (”Overview first, zoom and filter, then detailson-demand”), NVisionIP provides a visualization of an entire Class B network, then allows users to drill down and gather more details about the hosts on the network. Combining the visualization and data processing capabilities of computers and the intuition and reasoning capabilities of humans, NVisionIP is a tool that allows security engineers to detect and stop attacks on networks. Keywords: Netflows, Intrusion Detection, Network Security, Network Visualization

1

Introduction

As the recent wave of viruses, worms and attacks illustrate, network security is fast becoming a issue in computer systems everywhere. Attackers can easily download scripts that can be used to attack various systems. These “root kits” allow even hacking novices to attack large systems. With the increase in security incidents in the last few years, Security Engineers are faced with the task of securing networks that are being increasingly being attacked. There are many monitoring and logging tools that provide data on the behavior of networks. Logging facilities, like Syslog on Unix, or packet tracing utilities provide a rich set of data for security engineers to use in detecting and preventing intrusions. With the size and complexity of networks increasing, though, security engineers are often faced with a deluge of data from the network. The large amount of data ∗ 0-7803-8566-7/04/$20.00

c 2004 IEEE.

must be processed by the security engineer in order to understand the state of the network. Unfortunately, the amount of data can often overwhelm a security engineer, and thus networks become vulnerable to attacks as the security engineer cannot keep track of the behavior of the network. To alleviate this problem, there has been much research done on automatically detecting attacks and intrusions from the logs. Automatic Intrusion Detection Systems (IDS) are useful but can easily be overwhelming when applied to a large network. Tools of this type work by matching network activity to “signatures” of attacks. An alarm is generated when the traffic pattern is found and an email is sent to the security engineer. These methods suffer from two major problems, the first being that the signature base must constantly be updated to keep up with new attacks, and the second, the systems often generate a huge amount of alarms, overwhelming the security engineer, once again, with too much information.There is work being done to address these two concerns. The field of Misuse Detection focuses on determining if the behavior of hosts is not normal. Hosts that are behaving abnormally can be investigated further, to determine if they are under attack. The problem, though is determining the “normal” behavior of a host. Alarm Fusion techniques group related alarms together based on their similarity, but determining similarity can be difficult. Although the two techniques mentioned above are promising approaches to automatically detecting intrusions, we find that they are not general and scalable enough to provide practical benefit for our security engineers. Either the technique is too specific, focusing on a simple and small subset of attacks, or the technique is not scalable to the large networks. In addition, many of these techniques have a high false positive rate, that is, indicating an attack when there is not one. At our installation, security is still the domain of human, who with their ability to generalize and utilize background knowledge, are able to far outstrip the automatic IDSes in terms of analysis and determing if an attack is occurring on the system. Unfortunately, with the increase in

attacks, security engineers are being overwhelmed with data, and so new tools are needed, now, to aid the security engineers in grasping all the data. As automatic methods are not fully developed, we believe that a different type of tool is needed that will allow human security engineers to grasp and manipulate the large amount of information that is generated by the network monitors. In addition, we want the tool to allow human security engineers to use their background knowledge and generalization ability to make security decisions. Our tool, NVisionIP provides these two functionalities by creating a visualization of the network data, thus providing a practical solution that allows security engineers to use their generalization ability and background knowledge along with the data crunching and visualization capabilities of machines. Humans have amazing visual capabilities, in fact there is no more powerful method of presenting large amounts of information than through visual data maps [10]. By visualizing the data, human security engineers can grasp and manipulate the large amount of information that is generated by network installations. NVisionIP can be considered a middle ground between human security engineers and automatic intrusion detection systems, allowing a combination of the positive aspects of both. In addition, by monitoring the use of NVisionIP, we hope, in the future, to be able to get ideas on the security analysis process that will allow us to increase the performance of automatic IDSes. The rest of the paper is organized as follows: Section 2 details the related work in IDSes and network visualization. Section 3 discusses NetFlows, the data source for NVisionIP, Section 4 describes NVisionIP, Section 5 lists some examples of attacks and intrusions that NVisionIP can help catch, and Section 6 provides the conclusions and future work.

2 2.1

Related Work Signature Based IDSes

There are several Intrusion Detection Systems that rely on signature based detection. In general, there are two classes, Host-Based IDSes, such as [3], which monitor the host, and Network-based IDSes, like Snort [7] which monitor the packets on a network. Both types of IDSes suffer from the same drawback, namely that the signature database must be updated every time a new attack appears. In addition, the IDSes generally generate a large amount of alarms; at our installation, our security engineer received in excess of 4000 alarms when our computer systems came under attack.

2.2

Network Visualizations

There has been much work on visualizing networks, [2] describes many of the early visualizations of the Internet. Some of the visualization are geographical in

nature, showing the traffic flow between machines as a link between the physical locations of the machines. Other visualizations focus on connectivity patterns and traffic volumes. In terms of visualization for security, [9] provides an example using BGP routing data. Although the data has been visualized to look for security incidents on the Internet, this work does not provide a sense of situational awareness as it analyzes traffic between autonomous systems. A new tool to enhance situational awareness is the Spinning Cube of Potential Doom [4]. This tool represents network traffic as points in 3D space. The addresses of the network being monitored lie on one axis, all possible source IP addresses lie on a second axis, and the third axis represents port numbers. The color of the points represent different characteristics of the traffic flows on the network. This presentation is similar to that of NVisionIP, though it tends to be more “busy.” Although similar to NVisionIP, the Spinning Cube of Potential Doom does not allow the user to drill down or filter for events of interest.

3

NetFlows

NVisionIP uses NetFlows as a data source. A NetFlow is an abstract representation of a sequence of packets transmitted between a source and destination host. NetFlows can keep track of the start and end time, source and destination port, number of bytes, number of packets, and the protocol. Figure 1 shows a sample netflow record. Appended to the source/destination IP address is the source/destination port. The counts are, respectively, source to destination packets, destination to source packets, source to destination bytes, and destination to source bytes. NetFlows can be thought of as connections between computers. For instance, a NetFlow would be generated between Host A and Host B if a user on Host A used ssh to connect to Host B. The source and destination ip addresses would be that of Host A and Host B respectively. The number of bytes, number of packets, and protocol used would depend on the application. A NetFlow is an abstract representation, the only items being transmitted via the network are packets. At NCSA, we are concerned primarily about traffic between the internal network and the Internet, thus we have set up our NetFlow connection architecture to capture the flows between our internal network and our border router. [11] describes, in detail, the NetFlow collection architecture at NCSA as well as details about the various types of NetFlows and their differences. NCSA uses two types of NetFlows, the proprietary CISCO NetFlows ([8]) and ARGUS flows ([1]). Both are similar but have their own idiosyncrasies, consult [11] for more details.

Start Time 20 Aug 03 00:00:06

End Time 20 Aug 03 00:00:06

Protocol tcp

Source IP,Port 202.202.11.172.6881

?i

Destination IP, Port 130.126.143.184.2047

Counts 1 0 909 0 E

Figure 1. Sample NetFlow record

4

NVisionIP

NVisionIP is comprised of three views of the data, and many features that allow manipulation of these views. The three views, Galaxy View , Small Multiple View , and Machine View , successively provide greater detail about a smaller set of machines. The Galaxy View shows high level data about the entire network; Small Multiple View is in the middle giving a reasonable amount of information on a user selected subset of machines; the Machine View shows all the information for a single machine. NVisionIP , by being organized in this way, fits the Visual Information Seeking Mantra: Overview first, zoom and filter, then detailson-demand [5] The Galaxy view provides a high level overview of the entire network. Although each machine is only represented by a 4 pixel square, the use of colors and binning allow enough information to be shown that the Galaxy View can be useful as a quick summary of the traffic patterns on the network. In addition, in the Galaxy View there are zooming and filter capabilities, which will be explained later. Details can be obtained by choosing a subset of the machines in the galaxy view - note that only the machines that the user wants to see details on will be shown here. The Small Multiple View and Machine View show greater detail of a smaller subset of machines, with the Machine View showing all the possible information we have about a single machine.

4.1

Galaxy View

The Galaxy View provides an overall look of the entire network. The ip-addresses of the machines are organized in a Cartesian plane, with the X-axis representing subnets and the Y -axis representing the host, so each point in the plane is one ip address. For instance, the point at coordinates (23, 47) would represent ip address 141.142.23.47. Similarly, the point (100, 20) would represent the ip address 141.142.100.20. (We also allow the user the option of changing the IP header to something other than 141.142). The color of each machine represents the number of unique ports used by that machine to send and receive data. For instance, if the host with ip-address 141.142.33.55 transmitted and received data via ports, 5, 12, 3456, and 90, it would have a count of 4. The binning legend on the bottom left of the Galaxy View shows the mapping of numbers to colors. In this case, 4 would fall in the second bin, 2-10, and thus 141.142.33.55 would be colored grey. The motivation behind this view is to provide a visual summary of the

entire network so that a Security Engineer can quickly scan to pick up problems. For instance, it is easy to observe some strong patterns of activity in Figure 2. It can be seen that many of the hosts with subnet values greater then 100 are not active. If, one day, some activity does occur in this range, a security engineer, upon a quick visual scan, can realize this fact, and act appropriately. By providing a visualization, in one screen, of the entire network, the security engineer can quickly scan and make judgments about the state of the network. NVisionIP provides two zooming facilities. One is a drill-down zoom, where a security engineer can choose a subset of machines and view them in the Small Multiple View . This will be described in more detail later on. In addition, NVisionIP provides a standard zooming option that increases the size of the galaxy view underneath the zooming tool. 4.1.1

Filtering

NVisionIP has a filtering capability in the Galaxy View . Using this capability, the user can choose to display only those hosts that satisfy some criteria. Currently, the user can decide what ports/protocols the host must have used in order to be shown. For instance, suppose a Security Engineer has been informed of a worm that propagates itself via port 4456 on the host machine. The Security Engineer can then filter the Galaxy View so that only machines that have used port 4456 will be shown in the Galaxy View .

4.2

Small Multiple View

Figure 3 shows the Small Multiple View which provides a more detailed look at a subset of machines in the network. The main panel is organized as in the Galaxy View , with subnets on the X-axis, and hosts on the Y -axis. Each machine in this view, though, is represented by two bar graphs. Both of these bar graphs show traffic (in terms of number of flows) over ports. The top bar graph shows the traffic for a certain set of special ports. Table 1 shows the initial special ports in NVisionIP. Each special port is assigned a unique color. The special ports can be seen on the left hand side of the view, in the legend. New special ports can be added by using the Add button. The top bar chart shows the counts for only the special ports, the color of the bar indicates which port it is. The second (bottom) bar chart shows flow counts for the top 10 ports outside of the special ports. The ports between 0-1024 are colored blue, and the rest of the ports

PORT 7 21 22 23 25 37 42 53 80 88 143

DESCRIPTION ECHO FTP SSH TELNET SMTP TIME NS DNS HTTP KRB IMAP

Table 1. Initial Special Ports in NVisionIP

are colored black. Of course, the special ports are colored their respective colors. The colors can be changed using the change color button. Once again, in this view a security engineer can quickly scan the machines and pick out machines that are not behaving normally.

4.3

Machine View

flows in which the port was present) or Byte Count (the number of bytes which the port transmitted/received). Each set of two charts follows the same style as in the Small Multiple View , the top bar chart shows counts for a set of ”special” ports, and the bottom shows the counts for the rest of the ports. Among the bar charts that can be viewed are charts that show how many bytes were transferred by a port that has used the protocol TCP or UDP, the byte count for every port, and several other types of ports Each of these bar charts can be accessed via the tabs at the top of the Machine View . As can be seen in Figure 4, there are three sets of bar charts in the Machine View . The top, and largest set, of bar charts shows the total traffic coming into and out of this machine. The bottom left hand bar chart shows the amount of traffic that the ports transmitted. The bottom right hand bar charts shows the amount of traffic that the ports received. The sum of the values from the left and right equal the values of the center chart.

5

User Evaluation.

NVisionIP is currently being tested by the internal Security engineers at NCSA. NVisionIP was developed with security in mind, so it is useful for detecting security incidents. NVisionIP can help in several things: Worm Infection Many types of worms spread by probing for other hosts to infect. For instance, the Slammer worm sent 376-byte packets to UDP port 1434 of random hosts in an attempt to propagate [6]. A security engineer could filter the galaxy view to only show hosts that have flows with destination port 1434 transmitted using UDP. Once identified, the security engineer can alert the system admins of the hosts and inform them of the worm. Compromised Systems Figure 4. The NVisionIP Machine View

The Machine View provides a detailed look at one machine in the network. To get the Machine View for a machine, the user must simply choose the machine from the Small Multiple View . The purpose of the Machine View is to provide all the information possible about the machine. To this end, the netflows used to generate all the visualization are presented in the Machine View . The security engineers, at this point, require a look at the raw netflows used by NVisionIP . In addition to the raw netflows, we provide several different bar charts that emphasize different aspects of the data. Each of the bar charts shows a subset of ports on the x axis, and either flow count (the number of

Many times, when a host is compromised, the attacker will install software that allows remote access to the machine. In this way, compromised hosts can act as file servers, allowing illegal software to be copied from the host. NVisionIP can aid in the detection of such hosts because the hosts will suddenly have a large amount of traffic originating from them. These machines will be displayed in red in the Galaxy View , and thus be easily spotted by the security engineer. In addition, once the security engineer drills down on these machines, they can see which ports have been used, and whether the port usage is anomalous for that machine. Port Scans Port scans are easily detectable using NVisionIP. If one host is targeted, and all its ports scanned, then that host should turn red in the galaxy view. If the attacker

scans a series of machines on a particular subnet, this can show up as a line in the galaxy view. Figure 5 illustrates this type of scan in NVisionIP.

References [1] Argus – metrics. Web Page, Mar. 2001. hhttp: //www.qosient.com/argus/metrics.htmi. [2] Martin Dodge and Rob Kitchin. Atlas of Cyberspace. Addison Wesley, Harlow, England, 2001. [3] Gene H. Kim and Eugene H. Spafford. The design and implementation of tripwire: a file system integrity checker. In Proceedings of the 2nd ACM Conference on Computer and communications security, pages 18–29. ACM Press, 1994. [4] Stephen Lau. The spinning cube of potential doom. Communications of the ACM, 47(6):25–26, Jun. 2004.

Figure 5. Port Scan activity in NVisionIP

6

Conclusions and Future Work

In the future, we plan to incorporate into the Galaxy View the ability to compare the state of the network at two different moments in time. The Security Engineer can save the Galaxy View of a period of time in which they deem the network traffic to be normal, and then compare subsequent states against this ”normal” version. Current research in Anomaly and Misuse detection can be incorporated within NVisionIP as well. Instead of just showing the information about the host based on netflows, we could incorporate information taken from Intrusion Detection Systems and Anomaly detection algorithms running on various hosts/servers. NVisionIP can also provide insights into the security process. By monitoring NVisionIP while security engineers are using it, it could be possible to generate automatic rules derived from how the security engineers use NVisionIP. Securing and preventing attacks on computer networks is a difficult endeavor, made harder by the large amount of information a security engineer must wade through. Although there is work in Automatically looking for attacks, the work is not general, scalable, or efficient enough. NVisionIP provides a visualization of network information, allowing a human security engineer to utilize their background knowledge and generalization abilities while letting the machine handle the brute force task of visualization and data gathering. By bringing together the best parts of man and machine, NVisionIP allows a security engineer to focus on what is important - finding and detecting security incidents on the network.

[5] Ben Shneiderman. The eyes have it: A task by data type taxonomy for information visualizations. In Proceedings of the 1996 IEEE Symposium on Visual Languages, page 336, 1996. [6] CERT Advisory CA-2003-04 MS-SQL Server Worm. Web Page, Jan. 2003. hhttp://www.cert. org/advisories/CA-2003-04.htmli. [7] Snort: The open source network intrusion detection system. Web Page, Jun. 2004. hhttp://www. snort.orgi. [8] Cisco Systems. Cisco IOS Netflow Technology. Web Page, Jul. 2002. hhttp://www.cisco.com/warp/ public/cc/pd/iosw/prodlit/iosnf_ds.h%tm i. [9] Soon Tee Teoh, Kwan-Liu Ma, S. Felix Wu, and Xiaoliang Zhao. Case study: Interactive visualization for internet security. In IEEE Visualization, 2002. [10] Edward R. Tufte. The Visual Display of Quantitative Information. Graphics Press, P.O. Box 430, Cheshire, CT 06410, Second edition, Jan. 2001. [11] William Yurcik, Yifan Li, James Barlow, Kiran Lakkaraju, Xiaoxin Yin, and Cristina Abad. Scalable data-centric processing of netflows for security monitoring. In In Review, Proceedings of the ACM SIGCOMM Internet Measurement Conference, 2004.

Figure 2. The NVisionIP user interface (with magnifier activated in galaxy view)

Figure 3. The NVisionIP Small Multiple View