11-08-2011, 11:44 AM
[attachment=15210]
Introduction
With the increase in use of computer networks for information exchange, regulation and control of the data transferred on these networks is required to secure the intel¬lectual property of an organization. Thus, highly customizable network monitoring tools that capture data transmitted on the network are being designed. Some of these tools also analyze the collected data and provide valuable information to the user.
Network monitoring tools perform their task by sniffing packets from the network and filtering them on the basis of user specified rules. The tools that provide facility of specifying simple rules for filtering packets are called packet filters. Tools that filter packets based on complex rules and perform post-capture analysis of the collected data are termed as network monitoring tools. The following section describes packet sniffers. Later in this chapter, we focus on different packet filtering mechanisms and network monitoring tools. This leads to a motivation for developing and designing a new network monitoring tool - PickPacket,
1.1 Packet Sniffers
The basic goal of network monitoring is to read packets from the network and analyze its contents. At the lowest level, it requires that the network interface be able to read all the packets, irrespective of the destination of the packet. This can be ensured by properly configuring the interface. This activity of monitoring packets on the network is known as Packet Sniffing. Packet sniffers are simple monitoring tools that can only dump the network traffic on the storage media,
1.2 Packet Filters
The amount of information that flows on a network is generally quite high with packets corresponding to different protocols and even a simple analysis of this data takes time. This time can be reduced considerably by allowing the user to specify some rules for capturing packets selectively. For example, the user should be allowed to specify rules that capture all the packets with a given IP address. This would reduce the amount of space required for saving the packets and also lessen the time required for analysis. Packet filters provide this facility of specifying such simple rules. These rules comprise of values corresponding to various fields present the protocol headers of a packet. If the the protocol headers of a packet contain these values then it is saved else it is dropped by the packet filter. We discuss below some existing packet filters.
The CMU/Stanford Packet Filter (CSPF) [9] was the first UNIX based kernel- resident, protocol independent packet demultiplexer developed. It provides indi¬vidual user processes great flexibility in selecting which packets they will receive. It eventually evolved into the Network Interface Tap (NIT) [10] under SunOS 3, and later into Berkeley Packet Filter (BPF) [8], Sun implemented NIT to capture packets and etherfind to print packet headers. These packet filters although being implemented inside the kernel, provide an architecture over which the user-level network monitoring tools can be built.
In 1993, a new packet filtering mechanism, the Berkeley Packet Filter (BPF) [8] was developed by Steve MeCane and Van Jacobson, BPF essentially comprises of two components: a filter code and an interpreter which executes the filter code over the packet read from the network. The filter code uses a hypothetical machine consisting of an accumulator, an index register, a scratch memory store, and a program counter. This filter code is in an assembly like language and includes operations like load, store, branch, return, some register transfer functions, etc, BPF offers substantial performance improvements over other packet filtering mechanisms due to the following two reasons:
1, There are two approaches for filtering packets: a boolean expression tree (used by CSPF) and a directed acyclic control flow graph or CFG (first used by NNstat [17] and then used by BPF), These two models are computationally equivalent. However, in implementation the tree model maps naturally into code for a stack machine while the CFG model naturally maps into code for a register machine. Since most machines are register based, the CFG approach leads to a more efficient implementation,
2, When a packet arrives at the network interface, the network interface driver saves it in its buffer and then copies it to the system protocol stack. But in the case of BPF, the driver after saving the packet in its buffer calls BPF which operates on the stored packet and decides whether it is to be accepted or not. No copy of the packet is made for this filtering process. This leads to a great performance advantage of BPF over other filtering mechanisms (e.g. NIT [10]) that make a copy of the packet before filtering it.
The BSD socket interface is a de-facto standard for writing network based ap¬plications, Thus the Linux operating system came up with the Linux Socket Filter (LSF) [16], LSF is an in-kernel packet filter derived from BPF, It provides the user with a packet filtering facility on BSD sockets. Among other packet filters, tcpdump [6] is probably the most popular packet capturing tool in the UNIX community. It is based on BPF and has the packet capturing and filtering facilities implemented in a separate library, pcap [5], There are a wide range of network monitoring tools that integrate the pcap library
Introduction
With the increase in use of computer networks for information exchange, regulation and control of the data transferred on these networks is required to secure the intel¬lectual property of an organization. Thus, highly customizable network monitoring tools that capture data transmitted on the network are being designed. Some of these tools also analyze the collected data and provide valuable information to the user.
Network monitoring tools perform their task by sniffing packets from the network and filtering them on the basis of user specified rules. The tools that provide facility of specifying simple rules for filtering packets are called packet filters. Tools that filter packets based on complex rules and perform post-capture analysis of the collected data are termed as network monitoring tools. The following section describes packet sniffers. Later in this chapter, we focus on different packet filtering mechanisms and network monitoring tools. This leads to a motivation for developing and designing a new network monitoring tool - PickPacket,
1.1 Packet Sniffers
The basic goal of network monitoring is to read packets from the network and analyze its contents. At the lowest level, it requires that the network interface be able to read all the packets, irrespective of the destination of the packet. This can be ensured by properly configuring the interface. This activity of monitoring packets on the network is known as Packet Sniffing. Packet sniffers are simple monitoring tools that can only dump the network traffic on the storage media,
1.2 Packet Filters
The amount of information that flows on a network is generally quite high with packets corresponding to different protocols and even a simple analysis of this data takes time. This time can be reduced considerably by allowing the user to specify some rules for capturing packets selectively. For example, the user should be allowed to specify rules that capture all the packets with a given IP address. This would reduce the amount of space required for saving the packets and also lessen the time required for analysis. Packet filters provide this facility of specifying such simple rules. These rules comprise of values corresponding to various fields present the protocol headers of a packet. If the the protocol headers of a packet contain these values then it is saved else it is dropped by the packet filter. We discuss below some existing packet filters.
The CMU/Stanford Packet Filter (CSPF) [9] was the first UNIX based kernel- resident, protocol independent packet demultiplexer developed. It provides indi¬vidual user processes great flexibility in selecting which packets they will receive. It eventually evolved into the Network Interface Tap (NIT) [10] under SunOS 3, and later into Berkeley Packet Filter (BPF) [8], Sun implemented NIT to capture packets and etherfind to print packet headers. These packet filters although being implemented inside the kernel, provide an architecture over which the user-level network monitoring tools can be built.
In 1993, a new packet filtering mechanism, the Berkeley Packet Filter (BPF) [8] was developed by Steve MeCane and Van Jacobson, BPF essentially comprises of two components: a filter code and an interpreter which executes the filter code over the packet read from the network. The filter code uses a hypothetical machine consisting of an accumulator, an index register, a scratch memory store, and a program counter. This filter code is in an assembly like language and includes operations like load, store, branch, return, some register transfer functions, etc, BPF offers substantial performance improvements over other packet filtering mechanisms due to the following two reasons:
1, There are two approaches for filtering packets: a boolean expression tree (used by CSPF) and a directed acyclic control flow graph or CFG (first used by NNstat [17] and then used by BPF), These two models are computationally equivalent. However, in implementation the tree model maps naturally into code for a stack machine while the CFG model naturally maps into code for a register machine. Since most machines are register based, the CFG approach leads to a more efficient implementation,
2, When a packet arrives at the network interface, the network interface driver saves it in its buffer and then copies it to the system protocol stack. But in the case of BPF, the driver after saving the packet in its buffer calls BPF which operates on the stored packet and decides whether it is to be accepted or not. No copy of the packet is made for this filtering process. This leads to a great performance advantage of BPF over other filtering mechanisms (e.g. NIT [10]) that make a copy of the packet before filtering it.
The BSD socket interface is a de-facto standard for writing network based ap¬plications, Thus the Linux operating system came up with the Linux Socket Filter (LSF) [16], LSF is an in-kernel packet filter derived from BPF, It provides the user with a packet filtering facility on BSD sockets. Among other packet filters, tcpdump [6] is probably the most popular packet capturing tool in the UNIX community. It is based on BPF and has the packet capturing and filtering facilities implemented in a separate library, pcap [5], There are a wide range of network monitoring tools that integrate the pcap library
