A Powerful Easy-to-use Packet Control

API for Linux

Maninder Singh

Computer Science & Engineering Department

Thapar University

Patiala, India

Email: maninder.tiet@gmail.com

Dr. Maninder Singh

Computer Science & Engineering Department

Thapar University

Patiala, India

Email: msingh@thapar.edu

Abstract—Network security is a fairly vast field and isof utmost importance to preserve the information. Existingsecurity solutions like firewalls and IDS implement and supportonly limited number of packet control mechanisms at the coreAPI available to them. Thus options for specifying rules arerigid. Also, security companies make the kernel buggy as theycustomize it to make their own firewall for their product. Inthis paper, a new user space API has been proposed which willprovide a consistent, standard and highly flexible packet controlsolution for implementing firewalls. The API is consistent inthe way that most of the security applications can use itwithout modification. It will also provide a standard way forthe security companies to do customization at the kernel level.

Keywords-packet control; IDS; firewall; network security;deep packet inspection; consistent API; linux kernel

I. INTRODUCTION

With the time, the types, nature and severity of the security

issues are continuously increasing [3] [4]. Amongst the

plethora of network security issues, this paper presents a

partial contribution to solve the ones where the content of

the traffic is relatively more important than other facts about

the traffic like IP addresses, ports (layer 3 and 4) and size

etc. Network security has traditionally been managed using

three kinds of technologies:

1) Layer 2 and 3 devices like routers and switches.

2) Layer 3 and 4 devices like Firewalls.

3) IDS/IPS systems

Routers and switches offer some kind of Access Control

Lists (ACL) functionality which lets an administrator control

what goes through the network and what doesn’t, based on

MAC and IP addresses for example. They don’t understand

the concept of a flow which is required for an end-to-end

host communication.

Firewalls understand the concept of flows and control

them by either specifying the IP address or the TCP or

UDP port information. They also understand the concept

of subnets. It’s easy to build rules in firewalls that block a

known set of IP addresses and TCP/UDP ports, allow only

outbound connections and to do a bit of Stateful analysis.

IDS/IPS systems are specifically designed to detect intru-

sions into the network using services that are allowed on

the network but impossible to detect by just IP addresses

and TCP/UDP ports. They look for patterns in layer 5 and

above and try to match them with a known set of malicious

pattern rules–signatures. Any matches trigger actions such as

alerting the administrator or dropping the flow altogether. In

network security, the technology to perform network policy

decisions based on traffic content is referred to as Deep

Packet Inspection (DPI) or layer 7 firewalling [5]. Com-

panies such as Netscreen, SourceFire, and Cisco produce

firewalls that employ some form of deep packet filtering

[1].

II. BACKGROUND

The concept of deep packet inspection was first imple-

mented through the comparison of packet content with a set

of static strings [2]. Later, the companies migrated to the use

of regular expression based content inspection capabilities

due to their increased expressiveness. This payload scan-

ning technique is effective for identifying specific classes

of applications, viruses, protocol definitions etc. Currently

available popular DPI solutions include Snort, snort-Inline

and BRO. Based upon a set of signatures and rules, the

detection system is able to find and log suspicious activity

and generate alerts.

There are a number of packet control mechanisms pos-

sible because of powerful capabilities of Linux Network

subsystem but mostly the firewalls use only drop and accept

policy. A good DPI solution would be the one which is not

just limited to dropping or letting the packets pass but also

to route, bridge as desired, controlling what gets queued

and how, prioritize the packets on the fly based on some

parameters, modifying etc.

III. PROBLEM STATEMENT

DPI firewalls need to be really flexible in terms of letting

users very finely specify what they are looking for and more

detailed packet control has to be provided to the user. The

various packet control options and traffic control primitives

include routing, bridging, dropping, packet modification,

QoS, proxying etc.

2009 International Conference on Advances in Recent Technologies in Communication and Computing

978-0-7695-3845-7/09 $25.00 © 2009 IEEE

DOI 10.1109/ARTCom.2009.50

146

2009 International Conference on Advances in Recent Technologies in Communication and Computing

978-0-7695-3845-7/09 $26.00 © 2009 IEEE

DOI 10.1109/ARTCom.2009.50

146

2009 International Conference on Advances in Recent Technologies in Communication and Computing

978-0-7695-3845-7/09 $26.00 © 2009 IEEE

DOI 10.1109/ARTCom.2009.50

146

Apart from this, almost all the security domain companies

come up with some custom code inside the Linux kernel

to support packet control. They implement firewalls inside

Linux kernel, for example. Sometimes, they push the policy

from the user–space directly into the kernel, thereby making

the system vulnerable to any bugs in the kernel firewall code.

At other times, they use a custom API to talk from user–

space to kernel. This goes against the guidelines for software

design. Anything that has been used over and over again

should go through some amount of standardization. But there

is no such standard thing available yet.

IV. THE PROPOSED SOLUTION

The solution to the above stated problems is a consistent

and standard user–space API that can help enforce packet

control policies from the user–space in most flexible way.

The API allows exhaustive control, ease of use and a variety

of applications are able to use it without the substantial

changes thus providing consistency. With this, the security

companies will make use of this new standard API which

will have a plethora of possibilities of different criteria to

form the rules and would allow the customization (using

numerous rule formation options) from the user space only,

thus avoiding the possible vulnerability.

V. CONCEPTUAL ARCHITECTURE OF THE PROPOSED

SOLUTION

The proposed API is to be implemented inside the kernel

in the network subsystem [8]. The kernel side part of the

desired product would then consist of three major parts: one

which will accept rules from a user space program. Second

part will read the rules and match them against the packets

passing through the network subsystem and third part will

store the rules. Let us call these parts as “Rule Acceptor

Module”, “Rule Matcher Module” and “Rule Repository”.

Now this is the point where capability of the Linux network

subsystem can be harnessed and its true value can be

realized. The diagram in Figure 1 explains the architecture.

A. Rule Acceptor Module

The user space program when requires issuing a new

filter rule, it is made to call the kernel API and results in

Rule Acceptor Module being invoked, accepting the rule,

and getting it stored in a rule repository. This will involve

communication between the user space and kernel space

which can be accomplished by use of either IOCTL [12]

or shared memory [13]. Both of these approaches have their

own advantages and disadvantages. Based on their suitability

to the scenario and keeping in consideration the consistency

requirements, one of them can be chosen. The user space

program needs to send the address of a data structure

containing the rule, to kernel. The rule is processed under

following conditions: If there is no rule in list (repository)

yet, add the new rule only if it is of DROP type. An ACCEPT

Figure 1. Architecture of the proposed solution

type of rule simply implies to remove corresponding DROP

rule but since list is empty at this point, so ACCEPT type of

rule is meaningless here. If already list contains some rule,

then the rule is either added to list as new rule; or it may

be a duplicate rule to be discarded, or user might want to

remove an already existing rule (by giving same values of

rule options but with ACCEPT operation type).

B. Rule Repository

This sub–part of the solution will store the rules as they

are accepted by the Rule Acceptor Module. This module

will not be responsible for maintaining the persistence of the

rules between the system–down–events. That job is assumed

to be handled by the application program itself in the user–

space. The rules can be stored in any easy to access data

structure like linked list. Using a linked list, it would be easy

to add and remove a rule from the repository.

C. Rule Matcher Module

This module sits in-between the packet’s path track

through the network subsystem of kernel. The dark blue

directed lines in Figure 1 indicate the path of packets through

the kernel. For each forwarded packet, as it passes through

this module, it matches its parameters with those stored

inside each of the rules. If a rule matches, the specified

target action (given in the rule) is taken with the packet

otherwise the packet continues its normal journey through

the kernel. This module is implemented as a Netfilter hook

at NF IP POST ROUTING.

The fields included in match are srcaddr, destaddr, srcport,

destport. Any of them if zero (in some rule in the list), means

that field would not be included in the match. Thus, if all

the fields are zero in the rule, none of the packets would be

accepted.

147147147

VI. DIFFERENT PACKET CONTROL OPTIONS

Packet control refers to what can be done with packets

entering and leaving the system. The following explain the

various well-known packet control options:

A. Routing

Linux offers a very advanced routing infrastructure. In

some cases even better than some of the popular specialized

network devices. But since routing operation modifies the

packets, it is generally less efficient than other packet control

methods that don’t “touch” the packet.

B. Bridging

Bridging packets is in some ways the same as routing

except that in bridging, packets are not modified. Another

requirement for bridging is that networks joined using bridg-

ing are on the same subnet.

C. Firewalling

Firewalling refers to the basic operations of letting either

through the device or dropping them based on some known

rules. Linux implements firewall using Iptables [6] [7].

Firewalling is a very common and important operation in

what we are trying to accomplish.

D. Quality of Service

You may want to control what gets queued and how,

prioritize some traffic over others. Metrics like bandwidth,

throughput and latency etc. are important in context of a

network. You may also want to control how much of these

is allocated/permissible to a particular set of traffic.

E. Packet Modification

By modifying the packets as they are passing through

the device, one could solve interesting problems. Iptables

provides some of the packet mangling support. NAT is also

covered under this.

F. Proxying

We may want the original packets coming to the device

locally received and held instead of passing them on to the

intended destination. These packets are processed and a new

different flow is created to the destination.

So, there are a number of possibilities how a packet can be

controlled. But there is hardly any firewall which implements

all of these.

VII. CONCLUSION

Deep Packet Inspection is an emerging field due to the

increasing number and types of security threats. Just by

looking at the headers of the packets is not sufficient these

days like most of the firewalls do presently. We need to look

inside the payload also. Based on this concept, DPI firewalls,

IPS, IDS have been built but they provide only limited

control on packets. Moreover, they use pattern matching

techniques to classify traffic into one or more of known

classes or buckets. These patterns are also known as signa-

tures, since they are unique to the traffic in question. Linux is

rich in its networking capabilities and overall infrastructure

that can be leveraged to provide a more comprehensive DPI

solution with support of a number of packet control options.

Iptables and Netfilter architecture [9] provide a flexible way

to handle the packets as they pass through the system. The

proposed solution provides a standard way for the security

companies to implement firewall in the kernel. Moreover,

it is a consistent API which can be used by any security

application. It provides exhaustive control as it implements

new packet control mechanisms as well and provides the

user flexibility to specify the nonrigid set of rules for filtering

and controlling the network traffic. With this solution, the

packets which are forwarded in the system are matched to

the specified set of rules given by a user–space program.

To maintain persistence of rules is responsibility of the user

space program itself.

REFERENCES

[1] I. Dubrawsky, Firewall Evolution–Deep Packet Inspection.Infocus, July 2003.

[2] Y. H. Cho, S. Navab, and W. H. Mangione-Smith. DeepNetwork Packet Filter Design for Reconfigurable Devices. In12th Conference on Field Programmable Logic and Applica-tions, pages 452-461. Montpellier, France, September 2002.Springer- Verlag.

[3] Rose Mathew. Careers in information security course. Onlineat http://www.bharatbhasha.com/careers.php/49365

[4] eSoft. Modern network security: The migration to deep packetinspection. White Paper.

[5] Introduction to deep packet inspection. Online at http://www.dpacket.org/?q=node/7.

[6] Iptables primer. Online at http://www.higherpass.com/linux/Tutorials/Iptables-Primer/.

[7] Iptables tutorial 1.2.2. Online at http://iptables-tutorial.frozentux.net/iptables-tutorial.html.

[8] Christian Benvenuti. Understanding Linux Network internals.ORIELLY.

[9] Roll your own firewall with netfilter. Online at http://www.linuxjournal.com/article/7184.

[10] Robert Love. Linux System Programming. OREILLY.

[11] Tim Carstens. Programming with pcap. Online at http://www.tcpdump.org/pcap.htm.

[12] Introduction to implementing ioctls. Online at http://www.codeproject.com/KB/system/driverdev2.aspx.

[13] Shared memory introduction. Online at http://www.kohala.com/start/unpv22e/unpv22e.chap12.pdf.

148148148