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-serverRead 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.2Read 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 :
When the connexion opening datagram is authenticated (for TCP, that is the SYN datagram), nuauth creates an entry in database, with a request looking like this (for TCP) :
INSERT INTO conntrack_ulog (state, oob_time_sec, ip_protocol, ip_saddr, ip_daddr, oob_in, oob_out, oob_prefix, user_id, username, client_os, client_app, tcp_sport, tcp_dport) VALUES (... our datagram values ...);If nuauth decision for that datagram is to drop or reject it, log of the "connexion" stops here. The connexion will never be opened, and this database entry will no longer be manipulated by nuauth.
At the time when connection changes state (For TCP, and for any accepted connection, state changes to ESTABLISHED as soon as the server answers the SYN datagram), this request is performed by nuauth, if the nufw daemon is run with "-C" :
UPDATE conntrack_ulog SET state=ESTABLISHED, start_timestamp=FROM_UNIXTIME(timestamp) WHERE (ip_daddr=%s AND ip_saddr=%s "AND tcp_dport='%hu' AND tcp_sport='%hu' AND state=OPEN)The only fields that are altered by this request are "state", which changes to "ESTABLISHED", and start_timestamp, which wasn't set before. It is important to note that no information is lost when this modification is performed. It is indeed obvious that the connection was previously in "OPEN" state, since that's a TCP preambule to the "ESTABLISHED" state, and the database keeps track of the timestamp when the connection was opened in the "oob_time_sec" field. The "start_timestamp" field simply marks the timestamp of switch to the "ESTABLISHED" state.
When the connection expires, this request is executed by nuauth, if the nufw daemon is run with "-C" :
UPDATE conntrack_ulog SET end_timestamp=FROM_UNIXTIME(timestamp), state=CLOSE, packets_in=%d , packets_out=%d , bytes_in=%d , bytes_out=%d WHERE (ip_saddr=%s AND ip_daddr=%sAND tcp_sport='%hu' AND tcp_dport='%hu' AND (state=OPEN OR state=ESTABLISHED))State is updated, it becomes "CLOSE", and we set the end_timestamp field, which was empty before this, as well as packet number and byte number counters for the now dead connexion. Time of opening and time of establishment of the connection remain available in the oob_time_sec and start_timestamp fields.
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.
This is the good case compared to pre 2.6.14.
To enable authenticated connection tracking,
you only have to add the -C to nufw command line.
This flag asks nufw to send any ESTABLISHED and DESTROY message coming from Netfilter connections tracking to nuauth.
As an important number of events can be sent through this mean, nufw offers the capability to only send a subset.
It uses the fact that the initial mark can be put with CONNMARK
on every packets of the connection.
This mode is activated via the -M flag of nufw.
On Netfilter side, the following rules have to be added:
iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark iptables -A POSTROUTING -t mangle -m mark ! --mark 0 -j CONNMARK --save-mark
In short, you should always use -C if you use libnetfilter_conntrack (this is available from linux 2.6.14), and you should use -M if you want all your connections marked per userID (please note that you need to apply transmit_mark patch on your kernel to use this). Library compatibilty is better with a >=2.6.16 kernel.
NuFW stores the following states in the life of a TCP connection:
opening: bit SYN is set
established: SYN ACK is sent
closed: the tcp flags are FIN or FIN,ACK
--syn and the
--tcp-flags options.
Let's use the following configuration as an example: our web servers are protected by a NuFW firewall. They are in the network $DMZ.
The following rules achieve to realize a user connection tracking on the web
server outgoing connections.
iptables -A FORWARD -p tcp -m state --state ESTABLISHED --tcp-flags ACK,FIN NONE -j ACCEPT iptables -A FORWARD -d $DMZ -p tcp -m state --state ESTABLISHED --dport 80 --tcp-flags SYN,RST,ACK RST -j QUEUE iptables -A FORWARD -d $DMZ -p tcp -m state --state ESTABLISHED --dport 80 --tcp-flags FIN FIN -j QUEUE iptables -A FORWARD -s $DMZ -p tcp -m state --state ESTABLISHED --sport 80 --tcp-flags SYN,ACK SYN,ACK -j QUEUE iptables -A FORWARD -p tcp -m state --state ESTABLISHED -j ACCEPT iptables -A FORWARD -d $DMZ -p tcp --syn --dport 80 -m state --state NEW -j QUEUEThe first rule optimizes the filter by matching an important part of the ESTABLISHED traffic. The last rule with --state ESTABLISHED is the standard accepted established packets. It has to be put after NuFW flags matching rules.
No special complicated rule should be set, the kernel will automatically send new events on connections to NuFW. This is the reason why you don't want to use a pre-2.6.14 kernel ;)
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[1] 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
| [1] | as far as the author of this document knows at the time of the writing of this document |