Introduction

State of the art : Concepts and limitations of "Classical" IP packet filters

IP filtering is a topic that is well known to most security Administrators, who are now used to the most powerful filtering features, such as Connection Tracking, strict anti-spoof and default dropping policies.

It is also well known that IP filtering is very far from an all-in-one solution : Packet filtering is quite far away from the application level, which is why it must be coordinated with other security tools, such as proxies, anti-virus/anti-Spam software, etc.

In most today’s environments, IP packet filtering systems are mainly devoted to control what people can do from the computer they use, but current implementations control what computers can do at the IP level. So this introduces a conceptual shift : the system administrator has to work on IP level to solve a user management problem. In many cases, this leads to the assumption : “one user = one machine = one IP address”, which is inexact in many ways.

Furthermore, acknowledgment must also be taken of how far today’s IP filters are from the Users base, which is itself very much structuring into LDAP solutions. A high point of focus is also Single Sign On, a very much awaited integrated feature remains to be found. At this time, no IP-filtering solution can be setup in conjunction with SSO, which looks like a paradox, considering the IP filter is at a very central location of the network.

What would an users-aware IP filter bring to network security?

The first point is that this can add a lot of security and granularity into the filters. Imagine each user’s rules “following” him, be he at his desk, at the neighbor’s desk, in a learning room, or in your site in Malaisia.

Also, imagine several users working on the same multi-user system (These systems are spreading these days and are expected to spread much more in the future). With today’s filtering models, the same filtering rules will be applied to all users connected on one multiuser desktop, as rules are IP based. And it will be quite hard for the network Administrator to track users activities, as those can only be logged per IP (with the notable exception of proxified services).

Let’s go further. If network datagrams can be associated with their originating user, we can also filter “automatic” connections, based on their original uid : you want to accept security update files to be downloaded nightly by root user on your web server, but you never want the Apache user to be able to initiate connections to the Internet. More than that, you want to know about such attempts from the Apache user, as they very probably reveal a compromise of your web server.

There’s more than this. If your IP filter allows you to keep track of connections, associated with uid of the connection initiator, in real time, you are getting at hand’s reach of an SSO solution.

Being able to know which user has emitted a given packet, you can also start doing accounting and using kernel’s Quality of Service features on a per-user basis. Now you can assign to each of your user a part of your bandwidth, subdivising his given bandwith by protocols if you want and you are able to to know what is the bandwith consumption of a given user.

How can these ideas be implemented?

When looked at carefully, these ideas are quite near setting up a VPN solution inside your corporate network... with no fundamental need for encrypting data. But this solution would fail on multiuser systems where the same tunnel can be used by different users.

We have been working on a different implementation, called NuFW, working with Netfilter, interfacing with LDAP, and requiring much less a heavy infrastructure than a VPN solution. Our idea is simple : authenticate only IP datagrams that initiate a connection, and trust Netfilter’s connection tracking for "the rest".

We also keep track of users activity in real time, in a database, so that SSO-aware applications can access that data and identify users on the fly, from their connection-related data. As a proof of concept, we have designed an Apache module which allows for a strict user authentication without any prompt to the users.

The counterpart of a user aware solution is, it requires installation of a client software [1] on every host of your network. We are working on implementing a client solution for each OS (for now, both a GNU/Linux and a Windows clients are implemented).

Feel free to visit http://www.nufw.org/ if you are interested in this project, or want to send us remarks about our ideas. We will also be glad to accept contributions and new ideas.