NuFW Howto

The nufw daemon only depends on:

A system with a kernel prior to 2.6.14 needs a patched version of the ip_queue module and of its "sibling" library libipq.

On kernel superior to 2.6.14, ipq is now deprecated in favor of libnetfilter_queue which uses the new nfnetlink system. We encourage you to switch to this library as it is the future. On top of that nfnetlink also provides libnetfilter_conntrack which is used by NuFW to implement time-based acls.

To be able to use this features, the following libraries are needed:

You can find working versions of these libraries at http://nufw.org/download/libs/index.html And if you run debian, packages are available at http://www.nufw.org/debian/

If you plan to use NuFW time-based acls, it is best to use a kernel superior to 2.6.18 or to apply patches provided on NuFW site.

This is about copying the default certificates. Don't do that unless on very early tests ; you probably want to generate your own certificates: see next section.

For nufw

cp conf/certs/nufw-*.pem /etc/nufw/

For nuauth:

cp conf/certs/nuauth*.pem /etc/nufw/
cp conf/certs/NuFW*.pem /etc/nufw/

Generating your own Certificate authority:

mkdir private
chmod 700 private
openssl req -new -x509 -keyout private/CAkey.pem -out private/CAcert.pem

You have to set a strong password here and keep it secret.

Generating nufw and nuauth private keys:

openssl genrsa -out private/nufw-key.pem

openssl genrsa -out private/nuauth-key.pem

Generating Certificate Signing Requests for both nufw and nuauth keys:

openssl req -new -key private/nufw-key.pem -out nufw.csr

openssl req -new -key private/nuauth-key.pem -out nuauth.csr

Having our keys signed by the certificate authority we created:

openssl x509 -req -days 365 -in nufw.csr -CA private/CAcert.pem \
      -CAkey private/CAkey.pem -CAcreateserial -out nufw-cert.pem

openssl x509 -req -days 365 -in nuauth.csr -CA private/CAcert.pem \
      -CAkey private/CAkey.pem -CAcreateserial -out nuauth-cert.pem

Then, as in previous section, copy the files where needed: For nufw:

cp private/nufw-key.pem /etc/nufw/

cp nufw-cert.pem /etc/nufw/

For nuauth:

cp private/nuauth-key.pem /etc/nufw/

cp nuauth-cert.pem /etc/nufw/

And don't forget your key files (here, nufw-key.pem and nuauth-key.pem) should always remain private.

NuFW sources provide a sample configuration file for nuauth nuauth.conf which is available in the conf directory.

The two most important configuration variables are: nuauth_client_listen_addr which sets the address where nuauth listens for client requests and nuauth_nufw_listen_addr which sets the address where nuauth listens for nufw requests. The list of nufw servers authorized to connect to server nuauth is the nufw_gw_addr.

The next thing to do after setting this variable is to choose your authentication and acl checking module. Authentication modules for user have to be chosen in:

This is set with the option nuauth_user_check_module which default is libsystem (if not set in config file). Further choice for the acl checking module has to be done if you choose:

by setting the variable nuauth_acl_check_module.

To be able to proceed quickly to test, we will use the system module for user and the plaintext module for acl. A sample file for the plaintext acl check module is available in the conf directory, acls.nufw. Copy it to /etc/nufw and adjust the group of the ssh acl to have it matching the group of a system user you will use later to authenticate on the system.

We will test the setup by connecting from the local host ssh server. For this we need to add filtering rules to ask for authentication:

iptables -A OUTPUT -s 192.168.75.0/24 -p tcp --dport 22 -m state --state NEW --syn -j QUEUE
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

^[2]

We will test the setup by connecting from the local host ssh server. For this we need to add filtering rules to ask for authentication:

iptables -A OUTPUT -s 192.168.75.0/24 -p tcp --dport 22 -m state --state NEW --syn -j NFQUEUE
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

^[3]

First, the daemons need to be started. We start nuauth in a terminal

nuauth -vvvvvvvvv

then we start

nufw -vvvvvvvvv

in another terminal.

Next, we can try to connect a user. Under Linux it can be done with:

nutcpc -d -H [NUAUTH IP]

enter name and password of a system user.

At nuauth level, we should see something like:

user bill@nufw uses OS Linux, 3.0.10, #1 Tue Oct 19 23:51:32 CEST 2008

If your PAM setup is based on shadow file, you will not be able to authenticate a user different from the one running nuauth. On this kind of setup, nuauth needs to be run as root to authenticate other users. ^[4]

A ssh connection from the computer to start the authentication process:

OpenLDAP server installation is standard. Use your Linux distribution packages, example with Debian:

apt-get install slapd

Read OpenLDAP Software Administrator's Guide, section "Building and Installing OpenLDAP Software" to get more information.

The file acls.schema has to be put in /etc/ldap/schema and a line

include         /etc/ldap/schema/acls.schema

has to be added at the beginning of the /etc/ldap/slapd.conf. In the level of access setup in this file, one can add:

#INL access for acls
access to  dn="ou=acls,dc=nufw,dc=org"
       by dn="uid=nufw,ou=Users,dc=nufw,dc=org" write
       by dn="uid=nuauth,ou=Users,dc=nufw,dc=org" read
       by dn="cn=admin,dc=nufw,dc=org" write
       by * none

nufw user is able to modify the policy and the nuauth user can only read the acls.

You can start with a LDIF file such as:

dn: dc=nufw,dc=org
objectClass: top
objectClass: dcObject
objectClass: organization
o: nufw.org
dc: nufw
structuralObjectClass: organization

dn: ou=Users,dc=nufw,dc=org
objectClass: organizationalUnit
ou: Users
structuralObjectClass: organizationalUnit

dn: ou=acls,dc=nufw,dc=org
objectClass: organizationalUnit
ou: acls
structuralObjectClass: organizationalUnit

To use LDAP support for acl checking, we need to modify the nuauth.conf file:

nuauth_acl_check_module="libldap"

and we have to setup the connection parameters:

ldap_bind_dn="uid=nuauth,ou=Users,dc=nufw,dc=org"
ldap_bind_password="secretpassword"
ldap_basedn="dc=nufw,dc=org"
ldap_acls_base_dn="ou=Acls,dc=nufw,dc=org"

INL has released a powerful Netfilter rules generator system for NuFW and Netfilter. It is called Nuface and it is available at: http://software.inl.fr/trac/trac.cgi/wiki/EdenWall/NuFace It generates a set of rules for NuFW and Netfilter that can directly be applied from the web interface.

nuaclgen is a script that can help you maintain a simple set of acls in an LDAP tree.

It is advised that you use Nuface rather than Nuaclgen, if possible, since it makes things simpler. In particular, be aware that when you use nuaclgen, you need to also modify by hand your Netfilter rules.

The file nuaclgen.conf contains the informations about LDAP connections. It needs to be modified to suit your configuration, for example:

$ldap_host="localhost";
$username="uid=nufw,ou=Users,dc=nufw,dc=org";
$password="writepasswd";
$basedn="ou=Acls,dc=nufw,dc=org";

^[5]

To allow ssh for users of group 513 if they use /usr/bin/ssh application, we can use:

nuaclgen --Aclname cn=ssh,ou=Acls,dc=nufw,dc=org -p 6 --dport 22 -AppName "/usr/bin/ssh" -j ACCEPT -g 513

Or for access directed to a web server:

nuaclgen --Aclname cn=apt,ou=Acls,dc=nufw,dc=org -p 6 --dport 80 \
  -AppName "/usr/lib/apt/methods/http" -j ACCEPT -g 1042

This ACL gives access to group 1042 which is used by root user of some server of ours. Thus root user can only get file to update the computer, but other users can not access the web.

To achieve NuFW connection tracking it is necessary to have these options in nuauth.conf:

nuauth_log_users_sync=1
nuauth_log_users=9

MySQL server installation is standard. Use your Linux distribution packages, example with Debian:

apt-get install mysql-server

Read MySQL Documentation, section "2 Installing and Upgrading MySQL" to get more information.

PostgreSQL server installation is standard. Use your Linux distribution packages, example with Debian (replace 8.2 by the last server version):

apt-get install postgresql-8.2

Read PostgreSQL Documentation, section "III. 14. Installation Instructions" to get more information.

The connection tracking system is really useful with SQL logging modules. We will describe here the setup of the MySQL module.

You have to create the SQL database from the dump file available in the conf/ subdir of the archive. Create a SQL account, which must have UPDATE, INSERT privileges on the "conntrack_ulog" table. You will have to set the credentials for that user in the nuauth.conf file.

You may choose between to schema an IPv4 only one and an IPv4/IPv6 one. Recent tools like Nulog2 are able to use the IPv6 schema. If you have old script or older tools, you better use the IPv4 only schema. To import the IPv4 schema into a newly created database, you can use:

mysqladmin create nufw
cat nulog.ipv4.mysql.dump | mysql nufw

For the IPv6 schema, simply use:

mysqladmin create nufw
cat nulog.ipv6.mysql.dump | mysql nufw

When installing NuFW in production, you have to use the clean_conntrack.pl script, which is available in the scripts/ subdir of the NuFW archive from version 1.0.12 on. For prior versions, you can get the script from Nulog project homepage. You have to create a SQL user to run the script, with the following permissions : SELECT and DELETE on the "conntrack_ulog" table, INSERT on the "ulog" table. The script must be run, every few minutes, from cron, especially on busy firewalls. If you don't run this script, your "conntrack_ulog" table will grow quickly with "dead" connections, and will cause NuFW to act slower and slower. All the script does is transfer "dead" data (ie closed connections, dropped connections) to the ulog table, which is plainly an archive table, not used on production by NuFW, nor by the SSO subsystems.

You may also want to rotate the "ulog" table, so that it doesn't grow to infinite size with time. From 1.0.12 on, scripts are available for this task in the scripts/ subdir of the archive. Before 1.0.12, you can get those two scripts from the Nulog archive at Nulog project homepage Look for the ulog_rotate_*.sh scripts. At the present time, it is assumed those scripts are run as the root SQL user, as cronjobs. Of course the better way to go is to create a separate user for this and grant it the needed privileges. Please provide updates for this document if you implement this before we do.

If nuauth is configured to log network flow information in a SQL database, here is how the logging system works :

The SQL logging feature keeps track of the whole history of each connexion, and updates that nuauth performs on the database do never erase data that was previously logged. This log mode is the most powerful one that a firewall can achieve, because it is very synthetic : one single SQL entry is maintained for each connection ; and it keeps the whole history of all elements of connections.

nutop is a perl script provided with nufw sources. It is a top like tool that displays the active and authenticated connections in real-time.

The best way^[6] to use the logs generated by the connection tracking is to install nulog(a.k.a ulog-php) which provides a convenient web interface. nulog is available under GPL on this page: http://software.inl.fr/trac/trac.cgi/wiki/EdenWall/NuLog

All you need to do is to setup a SQL user with SELECT permissions on the "conntrack_ulog" table. Then setup mod_auth_nufw to use the configured SQL user/database/table. The source code of the apache module is available at NuFW Apache SSO page

All you need to do is to setup a SQL user with SELECT permissions on the "conntrack_ulog" table. Then setup squid_nufw_helper to use the configured SQL user/database/table. The source code of the squid helper is available at NuFW Squid SSO page

Official Linux kernels are not able to mark packets with ip_queue framework before 2.6.14 release. It is thus necessary to patch the kernel (if pre 2.6.14), this has to be done by using the ip_queue_vwmark patch available in the patch-o-matic-ng from netfilter. This will generate a modified version of both ip_queue module and libipq.a file.

Once the new libipq.a is installed, you can now compile nufw:

./configure --with-user-mark ${EXTRA_OPTIONS_YOU_LIKE}
make
make install

nufw can now be run with -m to use userid marking. This option is compatible with -M.

As nufw only works with initialisation packets it can not pull the userid mark of each packet of a connection. Thus, this is necessary to use CONNMARK^[7] which is a target able to propagate marks accross connections. A basic setup is the following:

iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark
iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark

First line restores the existing mark when a packet arrives and second line saves mark on the connection so it can be restored later.

The nuauth variable nuauth_finalize_packet_module lists module which attach a hook called just before nuauth answer to nufw about a packet. It is usually used to modify the mark of the packet following a given strategy. By splitting the mark in different part, this is possible to define complexe marking policy which can later be used by Linux routing and QoS systems.

Extensive documentation can be found in the file README.mark

Netfilter mark can be use by the Quality of Service system and the routing system of Linux.

So it is possible to do differenciated routing between different users by using command like:

ip rule add fwmark XXX lookup TABLE

This is almost the same for QoS, by using tc filter one needs to put user's flows in a specific class:

tc filter add dev IFACE  prio 5 protocol ip handle 102 fw flowid FLOWID

For more information about routing and quality of service you can read lartc.

The syntax is the following: Each option that set up the use of a hook is a list of modules separated by space.

For each module type, the syntax is the following: name[:type[:config file]] If syntax is:

Let's analyse the following line: nuauth_user_logs_module="syslog dblocal:mysql maindb:mysql:/etc/nufw/mainmysql.conf" Packet will be logged multiple times:

It is warmly recommanded to put the nuauth in a protected place to ensure the security of communications between nufw and nuauth^[8]. As the firewall policy relay on the answer of nuauth, is it good to check that the nuauth server is trustworthy. To do so we can ask nufw to check the certificate provided by nuauth during the TLS negotiation. This is done by using the -a at start of nufw followed by the name of the certificate authority file. With this option set nufw will check the presence of a signed certificat on nuauth side.

You can even run nufw in strict TLS mode using -S parameter. We highly recommend to use this option. It means nufw will not start if your certificate is:

Warning: This mode will be activated by default in next major stable release.

You can restrict both the number of connections a given user can start, either on any IP address or per IP address.

On client side, system needs to be trustworthy if you want to perform valuable application and OS filtering. You must never forget that it is the application on client side which tells the application name as well as the operating system name and version: these informations CAN and WILL be spoofed if a malicious user installs a modified NuFW agent.

This warning needs to be taken into account but one can not forget this feature exists to secure flows that an administrator would have to keep open on a standard system^[9].

Thus, the value of application and os filtering depends on the confidence you have on the system which issues the authentication. On a secured system where users can not install software, this sort of filtering is "quite secure".

If your ldap server has support for TLS, you can setup nuauth to have the ldap acls checking module using ldap over SSL.

To do so, edit nuauth.conf and modify ldap port to 636 (ldaps):

ldap_server_port=636

Next step is to edit /etc/ldap/ldap.conf to indicate which policy you want to use for SSL connection. If you only want to encrypt data, you can simply add to ldap.conf:

TLS_REQCERT never

The recommanded setup is to fill in ldap.conf with the path to certificate authority. Your ldap.conf should look like:

TLS_CACERT /etc/ldap/cacert-ldap.pem
TLS_REQCERT demand

Please note that you need to have a certificate that match precisely the hostname put in the ldap_server_addr of nuauth.conf.

PAM is a very convenient way for extending authentication to "exotic" directories. In particular, PAM lets one interface nuauth on NT domains, Active Directory, Radius, etc.

To have nuauth authenticate users based on PAM/Ldap, one must set in nuauth.conf:

nuauth_user_check_module="system"

In addition, PAM needs to be properly setup, which is external to NuFW, and basically out of the scope of this document. Here are a couple of files to set on Debian to get PAM/LDAP working with nuauth: /etc/pam.d/nuauth:

#This is to set PAM-LDAP, modify to suit your needs!
  auth    required      /lib/security/pam_env.so
  auth    sufficient    /lib/security/pam_ldap.so
  auth    required      /lib/security/pam_deny.so

  account required      /lib/security/pam_ldap.so

  session required      /lib/security/pam_limits.so
  session optional      /lib/security/pam_ldap.so

The /etc/nsswitch.conf file also needs to be tuned:

#This is to set PAM-LDAP, modify to suit your needs!
  passwd:         compat ldap
  group:          compat ldap
  

(leave the other lines unchanged). And you probably also need to tune the /etc/pam_ldap.conf file. This file works for us, provided there is no line beginning with "uri":

  host 127.0.0.1
  ldap_version 3
  scope one
  pam_password crypt
  nss_base_passwd         ou=Users,dc=nufw,dc=org?one
  nss_base_group          ou=Group,dc=nufw,dc=org?one
  

You also need to install and configure libnss-ldap. Configuration that works for us (still on debian) in /etc/libnss-ldap.conf:

  host 127.0.0.1
  base replace_with_your_base
  ldap_version 3
  rootbinddn cn=admin,dc=replace_with_your_base
  #Optional, set if you need these:
  nss_base_passwd ou=users,dc=replace_with_your_base?one
  nss_base_group ou=groups,dc=replace_with_your_base?one
  

Of course, tune this to suit your needs, and be aware that these system instructions may not be accurate for other distributions!

On Debian/Ubuntu, you will need the following packages:

    krb5-user
    krb4-config
    samba
    winbind
   

The /etc/krb5.conf file should contain something like:

[libdefaults]
        default_realm = DOMAIN.NAME
# The following krb5.conf variables are only for MIT Kerberos.
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true

[realms]
        DOMAIN.NAME = {
                kdc = 10.0.122.5
                admin_server = 10.0.122.5
                default_domain = DOMAIN.NAME
        }

[domain_realm]
        .domain.name = DOMAIN.NAME
        domain.name = DOMAIN.NAME
        shortname = DOMAIN.NAME
        .shortname = DOMAIN.NAME
   

The /etc/nsswitch file should look like:

passwd:         compat winbind
group:          compat winbind
shadow:         compat

hosts:          files dns mdns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis
   

It is very important that your system is time-synchronized with the AD/NT server. You should setup ntp to achieve this!

The /etc/samba/smb.conf file should also be customized:

[global]
# Change this to the workgroup/NT-domain name your Samba server will part of
   realm = DOMAIN.NAME
   password server = AD-SERVER
   netbios name = NUAUTH-SERVER
   workgroup = SHORTNAME

# server string is the equivalent of the NT Description field
   server string = %h server sexa-prn1 (Samba, Ubuntu)

####### Authentication #######

   security = ads
   encrypt passwords = true
   guest account = nobody

############ Misc ############

   socket options = TCP_NODELAY
   domain master = no

# Some defaults for winbind (make sure you're not using the ranges
# for something else.)
   idmap uid = 10000-20000
   idmap gid = 10000-20000
   template shell = /bin/bash

   template homedir = /home/%D/%U
   client use spnego = yes
   client ntlmv2 auth = yes
   restrict anonymous = 2
   

To join the Windows Domain, one will use:

kinit administrator@DOMAIN.NAME

net ads join -U administrator

The last command should display the short domain name, and should specify that the machine was successfully added to the domain.

Winbind (or winbindd) should be running on your system. You can check things are going allright by reading samba logs (probably in /var/log/samba/*).

As RHEL4 is shipped with a 2.6.9 kernel that is subject to the ip_queue problem mentionned later in this document. With this kernel the bug occurs systematically (at least on SMP machines).

There's an ip_queue bug on kernels prior to 2.6.12. It can hang the system when an ACCEPT decision is done on the INPUT chain. Thus DO NOT use a QUEUE target on INPUT with these kernels or it could freeze your computer. And anyway, you should use a recent kernel and NFQUEUE, as explained hereup in this howto.

NuFW should run seamlessly in virtualized environments. However it seems a Xen 3.1 does not allow the use of nfnetlink without problems. The following facts were reported (with NuFW 2.2.14, but NuFW versioning is not the matter) :