A look at NuFW [LWN.net]

August 3, 2005

This article was contributed by Joe 'Zonker' Brockmeier.

In many environments, it's sufficient to set up a firewall to filter traffic based on IP address. However, in some situations, an administrator may wish to set up a firewall that can actually filter packets based on the user, rather than the IP address that packets are coming from. A typical firewall using Netfilter is capable of filtering traffic and setting QoS rules only by the originating IP address, and doesn't recognize the concept of users at all.

Now User Filtering Works (NuFW) is a package that promises the ability to do a lot more. NuFW is a package that runs on top of Netfilter and allows packet filtering and quality of service (QoS) rules to be assigned by user or application, rather than by the machine or IP address that packets originate from. This makes it possible to apply finer-grained permissions than are possible with Netfilter alone.

There are two daemons that run to provide NuFW's services. The nuauth daemon - the authentication server for NuFW - and the nufw daemon, which runs on the firewall and works in conjunction with Netfilter to actually filter traffic. It is not necessary for the nuauth and nufw daemons to run on the same server, so an administrator can set up nufw on the firewall, and nuauth on any other machine that the firewall can communicate with.

We contacted the NuFW developers, Eric Leblond and Vincent Deffontaines about the project, and asked about the performance impact of NuFW. According to the developers, NuFW uses Netfilter's connection tracking features, and only authenticates the SYN packet of each TCP connection. This means NuFW has no impact on bandwidth, since it is removed from the equation once a connection is open.

Leblond and Deffontaines said that NuFW's impact on performance is minimal:

We also worked on the concern of performance for the SYN packets, as this is very important, too. Both daemons, nufw and nuauth, are multithreaded for max performance. We incorporated from v0.9 on an internal ACL cache into the authentication server, so it doesn't need to perform ACL checks when they were just fetched.

There remains, of course, a measurable impact on the time it takes to open TCP connections. We performed a small, basic bench, to measure this. We built a very basic process that opens a TCP connection to a host, then closes it, in loop for 1000 times. Running that process behind a NuFW firewall took 34 seconds. Running that process behind a "conventional" Netfilter firewall (same hardware) took 20 seconds. So, we're pretty happy with NuFW's behaviour on DoS conditions, and quite confident about the performance matter.

In addition to the nufw and nuauth daemons, each client system must be running the NuFW client -- Nutcpc for Linux, and NuWINc for Windows. Note that the Windows application is governed by a proprietary license, whereas NuFW is available under the GPL. Leblond and Deffontaines said that it should be easy to port the Linux client to Mac OS X and BSD OSes -- and it may run as-is. "What we mostly lack on this is testing. We are, of course, very open to contributions."

When clients send packets through the firewall or gateway, the nufw daemon checks with the nuauth daemon to authenticate the user and verify whether a particular user has the appropriate permissions to send traffic through the firewall.

NuFW distinguishes protocols as well, so users could be allowed (for example) to send HTTP traffic, but not SSH or POP3. Nuauth supports several authentication methods, including LDAP, system authentication with PAM, dbm or a plain text file with user credentials.

NuFW uses an Access Control List (ACL) to determine which services users and groups can access. In the event that two groups have conflicting permissions -- for example, if a user belongs to a group that can access SSH and a group that cannot -- NuFW can be configured to either allow access or deny it.

NuFW also offers detailed logging of activity, so that it's possible to track which users are sending traffic through the server and what traffic has been rejected or accepted. NuFW can log to syslog, or a MySQL or PostgreSQL database.

There is also a Web interface which works with NuFW called Nuface, and a firewall log analysis application called Nulog, which provides a friendly interface for viewing NuFW's logs in detail.

One limitation of NuFW is that it only filters TCP. The developers said that they want to implement UDP, ICMP and other protocols. There are a few other features that they're looking at for the long term as well:

We have to go into IPv6 support, too. We're looking for greater integration into Netfilter with NFQUEUE (yay! it will/should be in 2.6.14!) and all the current work of Netfilter's team on NETLINK, which will allow for even finer filtering. We're in contact with the Netfilter team for this.

We also asked Leblond and Deffontaines if there was any chance of NuFW being ported to any of the BSD OSes. They said that they have looked at this, but that none of the BSD IP filter packages have a feature like Netfilter's QUEUE target, which is used by NuFW. "When/if there is one, we'll be happy to port the nufw daemon to BSD. Right now, the nuauth daemon should run on BSDs, as it is POSIX C."

While NuFW provides a rich set of features, it also adds quite a bit of complexity to the setup. In addition to installing and maintaining an additional set of packages, administrators will need to set up the appropriate groups and define permissions for those groups to determine which users can utilize which services.

Admins will also need to install the NuFW client on all machines that need to authenticate with NuFW, and this means that (for the moment) NuFW is an option only for organizations that restrict their systems to Windows and Linux. It is possible to set up NuFW to ignore one or more subnets on your network, but this does defeat the purpose of using NuFW to some extent.

As Leblond and Deffontaines point out, most of the complexity "comes not from internals, but rather from the fact that NuFW is a glue between systems that don't know about each other: the firewall in the center of the network, and the user directory in the center of organisation." They are working on a "appliance" solution with NuFW that will make it easier to deploy. It's also worth noting that NuFW is now available in Debian sid and the developers say that other distributions are looking at packaging NuFW as well. This could go a long way towards making NuFW much easier to deploy.

(Log in to post comments)

NuFW, what about the mentioned per application filtering?

Posted Aug 4, 2005 21:01 UTC (Thu) by Duncan (guest, #6647) [Link]

From the second paragraph...

> NuFW [...] allows packet filtering and
> quality of service (QoS) rules to be
> assigned by user or application[.]

The article then goes on to explain all about user based rules, but
doesn't mention application again, at all, unless by "application", the
above means "protocol", which /is/ mentioned later, but it /says/
application, /not/ protocol. Where's the description of how it deals with
individual applications?

For some time, since I switched from MSWormOS, I've been wondering when/if
Linux may get application based firewall permissions, similar to what
software firewalls such as Zone Alarm do on MSWormOS. It appears this
idea could go one better, by allowing full user/application based
filtering on a separate firewall, instead of having to be run on the same
machine, to be able to see that information (only the client will have to
be run on the machine with the user/app looking to authenticate).

In fact, I can see this potentially becoming very popular, very fast, with
the consumer level router appliance makers such as Netgear, Linksys/Cisco,
DLink, and the like (altho they'd have to arrange to license the
proprietary MSWormOS client), because this will now allow them to do
application level filtering at the router-appliance, something one had to
run a software firewall to get, before.

That is, of course, /provided/ this actually does application level
filtering as well as user filtering. If it doesn't do so now, I'd expect
the feature to be added, likely within a reasonable time-frame, since it's
GPLed and anyone can have at it, since the same local client that forwards
the user information should be able to pickup and forward the application
information as well.

Seriously looking forward to seeing further developments! This could be
very exciting indeed!

Duncan