4.2. Activer le suivi des connexions authentifiées avec NuFW

4.2.1. Paramétrage de nuauth

Pour activer le suivi de connexion avec NuFW, il est nécessaire de paramétrer les options suivantes dans le fichier nuauth.conf :

nuauth_log_users_sync=1
nuauth_log_users=9

4.2.2. Installation du serveur MySQL

L'installation du seveur MySQL est standard. Utilisez les paquets de votre distribution Linux, exemple avec Debian :

apt-get install mysql-server

4.2.3. Installation du serveur PostgreSQL

L'installation du serveur PostgreSQL est standard. Utilisez les paquets de votre distribution Linux, exemple avec Debian (remplacez 8.2 par la dernière version stable) :

apt-get install postgresql-8.2

4.2.4. Configuration de SQL

Le suivi de connexion révèle toute sa puissance lorsqu'il est associé à la journalisation SQL. Nous allons décrire ici le paramétrage du module MySQL.

Vous devrez créer la base SQL à partir du fichier dump disponible dans le sous-répertoire conf/ de l'archive. Créez un utilisateur dans MySql. Celui-ci doit disposer des droits UPDATE et INSERT sur la table "conntrack_ulog". Enfin, ajoutez les informations de connexions au serveur SQL dans le fichier nuauth.conf.

Lors du déploiement de NuFW en environnement de production, vous devez utiliser le script clean_conntrack.pl qui est disponible dans le sous-répertoire scripts/ de l'archive NuFW à partir de la version 1.0.12. Pour les versions antérieures, vous pouvez récupérer le script ici : Nulog project homepage. Vous devrez créer un utilisateur SQL disposant des privilèges suivants: : SELECT et DELETE sur la table "conntrack_ulog", INSERT sur la table "ulog". Ce script doit être exécuté très régulièrement, à intervalles de quelques minutes seulement, par l'intermédiaire de cron, notamment en cas de trafic important. Si vous ne faites pas cela, la table "conntrack_ulog" sera vite saturée de connexions "mortes" ce qui provoquera un ralentissement de NuFW. La seule opération réalisée par le script est de transférer les connexions "mortes" (ie les connexions fermées ou refusées) vers la tables ulog, qui est en fait une table d'archivage. Celle-ci n'est pas utilisée en production, ni par NuFW, ni par les modules SSO.

Vous pouvez également envisager d'archiver régulièrement la table "ulog", afin d'éviter qu'elle ne grossisse indéfiniment. A partir de la version 1.0.12, les scripts nécessaires sont disponibles dans le sous-répertoire scripts/ de l'archive. Pour les versions antérieures, pour pouvez récupérer les 2 scripts concernés là : Nulog project homepage Recherchez les scripts ulog_rotate_*.sh. Actuellement, vous devez exécuter ces scripts en tant que root via cron. Bien évidemment, une meilleure solution serait de créer un utilisateur particulier pour exécuter ces scripts, en lui donnant les droits appropriés. Merci de fournir une mise à jour à cette documentation si vous l'implémentez avant nous.

4.2.5. Vie d'une connexion dans la table SQL

Si nuauth est parametré pour journaliser les flux dans une base SQL, voici le fonctionnement du système :

• Au moment de l'authentification du paquet d'ouverture de connexion (pour TCP, le paquet SYN), nuauth crée une entrée dans la base de données, avec pour un flux TCP, une requête du style :

  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 (...les valeurs...);

  Si la décision prise pour ce datagramme est un rejet, la journalisation de cette "connexion" s'arrête ici, cette entrée dans la base de données ne sera plus manipulée par Nuauth.

• Au moment où la connexion change d'état (Pour TCP, dans la vie normale d'une connexion acceptée, celle ci passe en état ESTABLISHED au moment où le serveur répond), la requête suivante sera effectuée par nuauth, si le démon nufw est lancé avec l'option "-C" :

  UPDATE conntrack_ulog SET state=ESTABLISHED, start_timestamp=FROM_UNIXTIME(marqueur_de_temps)
  WHERE (ip_daddr=%s AND ip_saddr=%s "AND tcp_dport='%hu' AND tcp_sport='%hu' AND state=OPEN)
  

  Les seuls champs alterés par cette requête sont "state", qui passe en état établi, et start_timestamp, qui n'était pas positionné préalablement. Il est important de noter qu'aucune information n'est perdue lors de cette modification de la table. Il est évident que la connexion a été préalablement en état "OPEN", puisque c'est un préalable à l'état "ESTABLISHED", et nous disposons de l'heure de l'ouverture de la connexion dans le champ "oob_time_sec". Le champ "start_timestamp" marque simplement l'heure de passage en état ESTABLISHED.

• Quand la connexion vient à expirer, la requête suivante est effectuée par nuauth, si le démon nufw est lancé avec l'option "-C":

  UPDATE conntrack_ulog SET end_timestamp=FROM_UNIXTIME(marqueur_de_temps), 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))
  

  L'état est mis à jour, il devient "CLOSE", nous positionnons le champ end_timestamp, qui était préalablement vide, et nous positionnons les compteurs (auparavant vides également) sur le nombre de paquets et le nombre d'octets qui ont transité sur cette connexion. L'heure d'ouverture de la connexion reste présent et inalteré dans le champ oob_time_sec, et l'heure de passage de la connexion en état établi est également conservé dans le champ start_timestamp.

Le mode de journalisation en SQL conserve donc tout l'historique de chaque connexion, et les différentes mises à jour de la base de données n'effacent en aucun cas les données journalisées précédemment. Ce mode de journalisation est le plus puissant que puisse offir un pare-feu, car il est très synthétique : une seule entrée est maintenue pour chaque connexion ; et il conserve tout l'historique de tous les événements de connexion.

4.2.6. Configuration de Netfilter

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

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 QUEUE

4.2.7. Utiliser le suivi de connexions

nutop est un script perl fourni avec les sources de nufw. Il permet d'afficher en temps réel les connexions authentifiées actives de façon similaire à la commande top.

Le plus simple[1] afin d'exploiter la journalisation effectuée par le système de suivi de connexion est d'installer nulog (autrefois nommé ulog-php) qui fourni une interface web conviviale. nulog est disponible sous licence GPL ici : http://software.inl.fr/trac/trac.cgi/wiki/EdenWall/NuLog