home user developer researcher download resource about




-

Netnice Packet Filter is an extension of hierarchical virtual network interface, which realizes packet filtering, packet capturing and packet diverting. This page briefly shows how to use the mechanism. Detailed description is available in a developer's note, included in the package (contrib/pcap/note). You will find sample prgrams useful to understand the usage.

Packet Filter

fileVIF-VI.bmp

NPF has a packet filtering feature, a.k.a. firewall mechanism. We can utilize the mechanism to protect connected processes from attack, or to realize access control per application basis.

Applied to the root VIF, which is a physical network interface, the mechanism serves as an ordinary firewall. Thanks to the binary translator (or, JIT assembler) of NPF, the filtering performance is quite competitive.

It is very easy to utilize the mechanism. Simply write a filter code onto the filter file in a VIF directory of interest, under /proc/network. To generate a filter code, use vf program under contrib/pcap, for now.

% vf ./outfile tcp

This command generates a filter code (outfile) which passes just TCP traffic. You can copy the filter code onto any VIF, to activate the filter.

If creation of the intermediate file is too laborious, you can simply redirect the output of the code generator onto the filter file, as follows.

% vf /proc/network/VIF_OF_YOUR_CHOICE/filter "ip src 192.9.200.1" 

Since this is a simple program for system debugging, it is not very useful for management of complex filewall rules. In fact, we are now working on a GUI based firewall rule builder, utilizing Firewall Builder.

Packer Capture/Monitor

fileVIF-V.bmp

To monitor a VIF, read the "port" file in a corresponding directory of the target VIF. This mechanism easily realizes traffic control, based on monitored traffic, monitor of traffic which passed through a firewall, or detect particular type of packets to notify monitoring processes at the userland. This mechanism realizes monitoring of terminating entities, such as socket, process, and process group. And more importantly, the interface is BPF/libpcap compatible, and you can use a variety of useful applications such as tcpdump and ethereal to monitor a VIF.

The existing packet monitoring mechanisms are designed to monitor network interfaces, which mostly tapps the target traffic at device driver level. Hence, there is not any mechanism that can monitor network I/O of terminating entities at desired granularity, although the feature is indispensable to assure security monitoring of process behavior. Since they have tight association with the physical interface, we could not use the mechanisms to inspect the packets which passed through a firewall, which is also associated with an interface. Netnice realizes such feature, by allowing tapping of a VIF.

 

Do you want to know how to use it? It is simple, but, you will need some preparation. This is because, although libpcap expects BPF devices to be under /dev directory, packet capturing interface of a VIF is under /proc/network directory (to be exact, "port" files in VIF directories).

How do we monitor VIF by libpcap? Type as follows.

% cd /dev/
% rm bpf0
% ln -s /proc/network/fxp0/port ./bpf0

By linking the port file to tap from /dev/bpf?, we deceive libpcap.

Since it is too laborious to remove and link the VIF whenever we call libpcap, we may modify the library, or write a libpcap wrapper, which hides the detail.

Packet Diverting

fileVIF-VII.bmp

Packet diverting realizes divert operation of VIF traffic through useland. So, we can insert useful modules, such as proxy, spam mail remover, and web popup limitter.

Unfortunately, we have not yet developed an useful applications for this mechanism, but here is a sample program /contrib/pcap/divert, to see how it works.

Type as follows, to divert all the traffic of the VIF.

% divert /proc/network/fxp0/

To see the divert operation, you may turn on the divert monitor, as follows.

% sysctl -w net.netnice.divert_monitor=1

NPF Binary Translator

NPF has a function which translates a user-provided filter code into optimized binary code native to the underlying processor, inside the kernel. This technique is similar to what they call JIT compiler in Java and other languages. We may call it, in-kernel JIT assembler, since it is an in-kernel mechanism and does not compiles any language.

This feature is advantageous, since typical Berkeley Packet Filter interprets each instruction in the filter code when it executes filter program. On the other hand, Netnice Packet Filter optimizes the code into native binary when a filter code is set onto a VIF, and actual packet filtering is performed by the native binary; this results in a very high performance.

However, a bottleneck of BPF processing is not in filter processing, but this is , in the copying of packet data and data transfer between the kernel and the userland. Although it is not accurate, we think that the CPU cycles consumed in the filtering phase is about 1/10 of the entire processing. Hence, the performance comparison with BPF is not so striking, contrary to the intuition. We think that the major difference between NPF and BPF is its flexibility of monitoring in its location and granularity and combination of passive monitoring and active traffic control integrated on a VIF.

 

Meanwhile, performance advantage of Netnice Packet Filter is striking, in the packet filtering (firewall), where no buffer copy and data transfer happens.

 

Most of existing firewall implementations are based on "rule-chain" model, where the system checks the chained filter rules to decide if a packet should be accepted or dropped. These firewalls have been developed for more and more functionalities, and thus, inefficient.

In contrast, NPF compiles filer rules into filter code in the userland, as we have demonstrated above. Hence, we can optimize the filter in this stage, eliminating redundancy. Further, the filter code in virtual instruction set architecture is translated into native binary, with another optimization. Matching of filter rule is performed at the native code speed, which eliminates most of the processing overhead for filter processing. The performance advantage is obvious, compared with traditional rule-chain based implementations particularly for packet filtering of high-performance servers.

Related Pages


Attach file: fileVIF-VII.bmp 1222 download [Information] fileVIF-V.bmp 4128 download [Information] fileVIF-VI.bmp 1183 download [Information]

Reload   New Edit Unfreeze Diff Upload Copy Rename   Front page List of pages Search Recent changes Backup   Help   RSS of recent changes
Last-modified: 2010-04-25 (Sun) 08:51:47 (2824d)