Eric Leblond regit@inl.fr Vincent Deffontaines gryzor at inl dot fr Jean Baptiste Favre jean.baptiste.favre at gmail.com

Traduction française

2005-2008 INL 0.9.8 2008/04/24 Le problème lié à Xen était en fait un problème lié au mode bridge. 0.9.7 2008/04/17 Plus d'informations sur le fonctionnement des agents NuFW. 0.9.6 2008/04/09 Ajout d'informations spécifiques à l'utilisation de NuFW avec Xen. 0.9.5 2008/02/14 Ajout d'informations spécifiques à certaines versions du noyau (2.6.24). 0.9.4 2008/01/10 Mention est faite de la journalisation Prelude. 0.9.3 2008/01/10 Description détaillée du modèle de journalisation et des mises à jours des tables SQL par nuauth. 0.9.2 2008/01/09 Ajout information sur l'utilisation de TLS dans les différentes briques. Documentation de l'utilisation des logiciels libres utilisées. 0.9.1 2007/12/20 Précision d'une licence. Les versions précédentes de ce document ne précisaient pas la licence, ce qui le rendait propriétaire de fait. 0.9 2007/12/10 Mise à jour de la traduction du howto 2.0 grâce au howto 2.2 en anglais 0.7.3 2007/08/07 Ajout d'une section pour préciser quand une recompilation du noyau doit ou non être faite. 0.7.2 2007/02/09 Mise à jour relative à NuFW 2.0.15. 0.7.1 2007/02/07 Ajout des options relatives à NuFW 2.0.14. 0.6.1 2006/11/14 Compléments d'informations sur PAM/NSS. Mises à jour de certains liens. 0.6 2006/10/12 Ajout d'informations récentes sur le noyau. 0.5 2006/08/01 Modification de ce HowTo pour en faire une documentation sur la version 2.0. 0.4.3 2005/11/23 Ajout d'informations sur le paramétrage de nuauth, notamment avec PAM. Diverses corrections mineures 0.4.2 2005/11/22 Ajout d'informations sur la création des certificats et de leur signature par une AC. 0.4.1 2005/08/01 Ajout d'informations, notamment sur les informations d'authentification et la rotation des logs 0.4 2005/07/25 Ajout de précisions concernant RedHat et le portage pour powerpc 0.3 2005/07/18 Relecture avec la publication de la version 1.0.10 0.2 2005/03/30 Compléments 0.1 2005/03/09 Première version Ce document appartient à INL et est protégé par les lois internationales sur le copyright. La licence de distribution du présent document est la licence Creative Commons by-nc-sa. Le texte complet de cette licence est disponible à l'adresse http://creativecommons.org/licenses/by-nc-sa/3.0/legalcode.

NuFW est un pare-feu d'entreprise qui effectue une authentification de chaque connexion qui le traverse. Ceci s'effectue de façon transparente en requérant les informations d'identification de l'utilisateur avant qu'une quelconque décision de filtrage ne soit prise. En pratique, cela signifie que les politiques de filtrage peuvent intégrer l'annuaire utilisateur, et amène cette notion d'ID utilisateur au niveau de la couche IP. NuFW repose sur Netfilter, l'état de l'art en matière de filtrage IP dans le noyau Linux. NuFW s'intègre parfaitement avec Netfilter et en étend même les fonctionnalités. Les serveurs sont actuellement disponibles pour Linux ; les clients existent pour Windows, Linux, FreeBSD et Mac OSX. NuFW peut : Authentifier toute connection transitant par la passerelle ou simplement de/vers un sous-réseau précis ou encore un protocole précis (iptables est utilisé pour trier les connections à authentifier). Effectuer l'imputation, le routage et la qualité de service en se basant sur les utilisateurs et non plus simplement sur l'adresse IP. Filtrer le trafic en fonction du système d'exploitation et des applications utilisées par les utilisateurs distants. Constituer le coeur d'un système simple mais sécurisé d'authentification unique. NuFW est composé de 2 services qui peuvent être installés sur des machines différentes. Le service principal nuauth intègre le support multithread. nuauth recourt à des modules pour toute interaction avec l'extérieur.

Dans cette section, toutes les librairies utilisées doivent être installées sur le système. Les fichiers d'en-têtes doivent être situés dans des répertoires standards (afin que configure puisse les trouver).

nuauth dépend de : libglib2.0 : nuauth utilise intensément cette librairie qui procure un ensemble d'objets de haut niveau particulièrement utiles. Il faut au minimum la version 2.4. libgnutls : le chiffrement des communications entre les différents composants du système est assuré par TLS libsasl2 : l'authentification est effectuée par sasl libtool : requis pour la compilation des librairies et des modules

La bibliothèque libmysqlclient est requise pour la compilation du module correspondant.

La bibliothèque libpq est requise pour la compilation du module correspondant.

La librairie libprelude est requise pour la compilation du module correspondant. Prelude permet de centraliser les événements de sécurité d'une organisation, et NuFW peut lui envoyer les événements suivants : Les échecs d'authentification Les réussites d'authentification Les débuts et fin de sessions NuFW Les débuts et fin de connexions authentifiées Les connexions rejetées Toutes informations à propos du projet Prelude sont disponibles à l'adresse http://prelude-ids.org

libldap2 est requis.

Le service nufw dépend de : libgnutls : nufw communique avec nuauth via un tunnel chiffré par TLS libnfnetlink libnetfilter_queue libnetfilter_conntrack Ces dépendances sont valables si votre système utilise un noyau de version supérieure à 2.6.14. Pour les noyaux plus anciens les dépendances sont iptables : libipq.a est la couche d'interaction avec le noyau pour les version de Linux plus anciennes que 2.6.14. libgnutls

Un système avec noyau plus ancien que 2.6.14 nécessitera une version modifiée du module ip_queue et de sa librairie correspondante libipq.

Depuis les noyau 2.6.14, ipq est obsolète et doit être remplacé par libnetfilter_queue qui utilise le système nfnetlink. Nous vous encourageons à utiliser cette dernière librairie dans la mesure où elle représente l'avenir. De plus, nfnetlink procure également libnetfilter_conntrack qui est utilisée par NuFW pour implémenter les ACL horaires. Pour pouvoir bénéficier de ces fonctionnalités, les librairies suivantes sont nécessaires: Vous pouvez trouver des versions fonctionnelles de ces librairies ici : http://nufw.org/download/libs/index.html Si vous utilisez GNU/Debian, les paquets adaptés sont disponibles là : http://packages.inl.fr/stable/ Si vous souhaitez utiliser les ACL horaires, il est recommandé d'utiliser les versions 2.6.18 du noyau ou supérieures ou d'appliquer le correctif disponible sur le site de NuFW.

Sur les distributions listées ici, il n'est PAS nécessaire de recompiler le noyau pour faire tourner NuFWN'hésitez pas à nous envoyer des mises à jour pour cette liste ;): Fedora Core 6 (kernel 2.6.18) Debian Etch (kernel 2.6.18) Par ailleurs, il est à noter que dans tous les cas, une recompilation du noyau n'est au pire nécessaire que sur le pare-feu lui-même (à savoir la machine qui fait tourner le démon nufw). Le démon nuauth n'a aucune dépendance noyau et peut tourner sur n'importe quel système POSIX. Quand aux clients, ils sont par essence multiplateforme et n'ont donc aucune dépendance sur le noyau.

Vous ne devrez modifier votre noyau à l'aide de patch-o-matic que si vous décidez d'utiliser le marquage utilisateur (à partir de la version 2.6.14 du noyau, cette modification est intégrée dans le noyau vanilla). Ceci est nécessaire si vous souhaitez marquer vos flux réseau en fonction de l'ID utilisateur afin, par exemple, d'implémenter une qualité de service basée sur l'utilisateur. Cette fonctionnalité n'est pas nécessaire pour le bon fonctionnement de NuFW. Pour l'activer, installez patch-o-matic et exécutez la commande $./runme ip_queue_vwmark Note importante : il semble que les fonctions netfilter_netlink de 2.6.24 ne fonctionnent que si elles sont compilées en tant que module, pas en dur. Essayez de toujours compiler ces options en tant que modules noyaux : CONFIG_NETFILTER_NETLINK CONFIG_NETFILTER_NETLINK_QUEUE CONFIG_NETFILTER_NETLINK_LOG CONFIG_NF_CT_NETLINK La bonne nouvelle est que sur la plupart des distributions, le noyau fourni par défaut propose ces fonctions comme modules.

Si la version de votre noyau est supérieure à 2.6.14 (et cela devrait être le cas!), vous devriez activer les paramètres suivatns : CONFIG_NETFILTER_XT_TARGET_NFQUEUE=Y or m CONFIG_NETFILTER_NETLINK=Y or m CONFIG_IP_NF_CONNTRACK=m (Avertissement: ne paramétrez pas cette option pour être statiquement intégrée au noyau) CONFIG_IP_NF_CONNTRACK_EVENTS=Y Activer ces options vous permettra d'utiliser la cible NFQUEUE ainsi que des règles Netfilter extrêmement simples pour le suivi de connexions.

Décompressez l'archive contenant les sources dans le répertoire de votre choix et rendez-vous dans le répertoire ainsi créé. NuFW recourt à autoconf et automake pour la compilation. De plus, un script configure standard est fourni. Les options suivantes (entre autres), sont également disponibles : --with-mysql-log Active le support de la journalisation de l'activité utilisateur dans une base MySQL --with-pgsql-log Active le support de la journalisation de l'activité utilisateur dans une base PostgreSQL --with-system-auth Active le support de l'authentification PAM+NSS --with-ldap Active le support des annuaires LDAP pour le stockage des informations utilisateurs et des ACL Une liste détaillée des options disponibles peut être obtenue grâce à la commande $./configure --help Vous pouvez donc exécuter ./configure avec les options dont vous avez besoin puis commencer la compilation et l'installation: $ ./configure --with-ldap --with-system-auth --with-mysql-log \\ --sysconfdir=/etc/nufw/ $ make $ sudo make install

Il s'agit ici de copier les certificats par défaut. Vous ne devriez vraiment pas procéder de la sorte sauf en cas de tests; dans le cas contraire, vous voudrez sûrement utiliser vos propres certificats : consultez pour cela la section suivante. Pour nufw cp conf/certs/nufw-*.pem /etc/nufw/ Pour nuauth : cp conf/certs/nuauth*.pem /etc/nufw/ cp conf/certs/NuFW*.pem /etc/nufw/

Générez votre propre Authorité de Certification: mkdir private chmod 700 private openssl req -new -x509 -keyout private/CAkey.pem -out private/CAcert.pem Vous devriez utiliser ici un mot de passe particulièrement robuste, et, bien entendu, le garder secret. Générer les clefs privées pour nufw et nuauth: openssl genrsa -out private/nufw-key.pem openssl genrsa -out private/nuauth-key.pem Générer les demandes de certificats pour nufw et nuauth: openssl req -new -key private/nufw-key.pem -out nufw.csr openssl req -new -key private/nuauth-key.pem -out nuauth.csr Signer les demandes de certificats grâce à l'AC: 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 Enfin, comme dans la section précédente, copier les fichiers comme demandé: Pour nufw: cp private/nufw-key.pem /etc/nufw/ cp nufw-cert.pem /etc/nufw/ Pour nuauth: cp private/nuauth-key.pem /etc/nufw/ cp nuauth-cert.pem /etc/nufw/ Avertissement: N'oubliez pas que les fichiers contenant les clefs privées (ici, nufw-key.pem et nuauth-key.pem) doivent rester secrètes.

NuFW fourni un exemple de fichier de configuration pour nuauth, nuauth.conf, qui est disponible dans le répertoire conf. Les deux plus importantes directives de configuration sont : nuauth_client_listen_addr : définit l'adresse à laquelle nuauth va attendre les requètes des clients nuauth_nufw_listen_addr : définit l'adresse à laquelle nuauth va attendre les requètes de nufw. La liste des machines nufw autorisées à se connecter au serveur nuauth constitue la variable nufw_gw_addr. Ensuite, vous devez choisir votre module d'authentification et de vérification des ACL. Les modules suivants sont disponibles : plaintext : les informations utilisateur sont stockées dans un fichier texte system : l'authentification s'adosse à PAM et utilise les groupes existants dans le système. Ceci procure un moyen pratique d'utiliser nss et/ou pam-modules Ceci est paramétrable via l'option nuauth_user_check_module dont la valeur par défaut est libsystem (si non défini dans le fichier de configuration). D'autre paramètres concernant la vérification des ACL doivent être précisés si vous choisissez l'authentification parmi : libldap plaintext en définissant la variable nuauth_acl_check_module. Afin d'être capable de procéder rapidement aux tests, nous utiliserons le module system pour l'authentification et le module plaintext pour les ACL. Un fichier d'exemple, acls.nufw, pour le module ACL plaintext est disponible dans le répertoire conf. Copiez le dans /etc/nufw et modifiez au besoin le groupe pour l'ACL ssh afin d'utiliser le groupe d'appartenance de l'utilisateur que vous allez utiliser pour les connexions de test.

Nous devons ajouter les règles de filtrages de façon à déclencher une demande d'authentification pour toute connection vers ssh: 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 Seuls les paquets SYN sont envoyés vers QUEUE. Ce n'est pas assez pour effectuer une journalisation avancée des activités utilisateur, mais c'est largement suffisant pour une authentification du trafic.

Nous devons ajouter les règles de filtrages de façon à déclencher une demande d'authentification pour toute connection vers ssh: 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 Seuls les paquets SYN sont envoyés vers NFQUEUE. C'est suffisant pour effectuer une journalisation avancée des activités utilisateur dans la mesure où les évènements liés aux connections seront automatiquement envoyés à nufw par Netfilter. Ceci suppose, notamment, que l'option CONFIG_IP_NF_CONNTRACK_EVENTS du noyau soit activée.

En premier lieu, il faut démarrer le service nuauth dans un terminal nuauth -vvvvvvvvv Ensuite, nous démarrons nufw -vvvvvvvvv dans un autre terminal. Enfin, nous pouvons essayer de connecter un utilisateur (au sens nufw du terme). Sous Linux, ceci peut être fait par la commande : nutcpc -d -H [NUAUTH IP] Entrez le login et le mot de passe d'un utilisateur. Dans le terminal nuauth, vous devriez voir quelques chose comme: user bill@nufw uses OS Linux, 3.0.10, #1 Tue Oct 19 23:51:32 CEST 2008 Si votre configuration PAM utilise les fichiers shadow, nuauth pourra seulement authentifié l'utilisateur sous lequel il est lancé à moins d'être lancé en root. Avertissement: ne lancez JAMAIS nutcpc avec l'adresse [NUAUTH IP] égale à 'localhost' ou '127.0.0.1', et ce même si nuauth est installé sur la même machine. En effet, dans ce cas, les paquets envoyés à nuauth par le pare-feu proviendront de la machine (avec une adresse égale à, par exemple, 192.168.0.1) alors que nuauth attend pour l'authentification une adresse égale à 127.0.0.1. De ce fait, l'authentification échouera systématiquement.

La connection SSH va déclencher la procédure d'authentification : nufw reçoit un paquet de Netfilter : [PID] Sending request for 1 nufw ouvre une connexion TLS vers nuauth : [PID] Trying TLS connection nuauth reçoit la requète de nufw : ** Message: Packet : ** Message: Connection : src=192.168.75.2 dst=192.168.75.2 proto=6 ** Message: sport=32848 dport=22 nuauth envoie une demande d'authentification au client en fonction de l'IP source : ** Message: need to warn client ** Message: sending request nuauth reçoit la réponse du client : ** Message: User : ** Message: Connection : src=192.168.75.2 dst=192.168.75.2 proto=6 ** Message: sport=32848 dport=22 ** Message: OS : Linux 2.6.9 #1 Tue Oct 19 23:51:32 CEST 2004 ** Message: Application : /usr/bin/ssh nuauth renvoie sa réponse à nufw : Sending auth answer 1 for 1 on 0x42428482 ... nufw renvoie le paquet dans le noyau : [PID] Accepting 1

L'installation du serveur OpenLDAP est standard. Utilisez les paquets de votre distribution Linux, exemple avec Debian : apt-get install slapd Lisez OpenLDAP Software Administrator's Guide, section "Building and Installing OpenLDAP Software" pour plus d'informations.

Le fichier acls.schema doit être placé dans le répertoire /etc/ldap/schema et une ligne include /etc/ldap/schema/acls.schema ajoutée au début du fichier /etc/ldap/slapd.conf. Au niveau du contrôle d'accès, on peut ajouter les lignes : #INL access for acls access to dn="ou=acls,dc=inl,dc=fr" by dn="uid=nufw,ou=Users,dc=inl,dc=fr" write by dn="uid=nuauth,ou=Users,dc=inl,dc=fr" read by dn="cn=admin,dc=inl,dc=fr" write by * none L'utilisateur nufw est autorisé à modifier la politique de sécurité alors que l'utilisateur nuauth n'a qu'un droit de lecture sur les ACL.

Pour activer la vérification des ACL sur un annuaire LDAP, nous devons modifier le fichier nuauth.conf comme suit : nuauth_acl_check_module="libldap" Ensuite, il faut préciser les paramètres de connection à l'annuaire : ldap_bind_dn="uid=nuauth,ou=Users,dc=inl,dc=fr" ldap_bind_password="secretpassword" ldap_basedn="dc=inl,dc=fr" ldap_acls_base_dn="ou=Acls,dc=inl,dc=fr"

INL a développé un puissant générateur de règles pour NuFW et Netfilter. Cet outil s'appelle Nuface. Il est disponible ici : http://software.inl.fr/trac/trac.cgi/wiki/EdenWall/NuFace Il permet de générer des règles pour NuFW et Netfilter, règles qui sont directement applicables depuis l'interface web.

nuaclgen est un script qui vous permet de gérer des ACL dans un annuaire LDAP. Il est préférable d'utiliser Nuface plutôt que Nuaclgen dans la mesure où le premier simplifie grandement les opérations. Notamment, lorsque vous utilisez nuaclgen, vous devez modifier manuellement les règles Netfilter alors que Nuface s'en charge pour vous. Le fichier nuaclgen.conf renferme les informations de connexion à l'annuaire LDAP. Elle doivent être adaptées à votre configuration : $ldap_host="localhost"; $username="uid=nufw,ou=Users,dc=inl,dc=fr"; $password="writepasswd"; $basedn="ou=Acls,dc=inl,dc=fr"; Comme nuaclgen.conf contient des informations sensibles, ses permissions doivent être les plus restrictives possible. Pour autoriser les connexions SSH aux membres du groupe 513 à l'aide de l'application /usr/bin/ssh, la règle sera : nuaclgen -A cn=ssh,ou=Acls,dc=inl,dc=fr -p 6 --dport 22 -AppName "/usr/bin/ssh" -j ACCEPT -g 513 Ou pour une connexion vers un serveur web : nuaclgen -A cn=apt,ou=Acls,dc=inl,dc=fr -p 6 --dport 80 \ -AppName "/usr/lib/apt/methods/http" -j ACCEPT -g 1042 Cette ACL autorise les connexions aux membres du groupe 1042 qui est utilisé par les administrateurs de certains de nos serveurs. Ainsi, les administrateurs ne sont autorisés qu'à récupérer les mise à jour depuis Internet, mais tous les autres utilisateurs se verront refuser l'accès à Internet.

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

L'installation du seveur MySQL est standard. Utilisez les paquets de votre distribution Linux, exemple avec Debian : apt-get install mysql-server Lisez MySQL Documentation, section "2 Installing and Upgrading MySQL" pour plus d'informations.

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 Lisez PostgreSQL Documentation, section "III. 14. Installation Instructions" pour plus d'informations.

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.

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.

Cette opération est nettement simplifiée par rapport aux noyaux antérieurs. Pour activer le suivi des connexions authentifiées, vous n'avez qu'à ajouter l'option -C à la commande de démarrage de nufw. Cette option indiquera à nufw de communiquer à nuauth tous les évènements Netfilter ESTABLISHED et DESTROY en provenance du système de suivi de connexions de Netfilter. L'option ci-dessus risque de générer un nombre conséquent d'évènements que devra gérer nuauth. Afin d'éviter un déni de service dû à la saturation de nuauth, nufw offre la possibilité de sélectionner les évènements à envoyer. Cette fonctionnalité utilise les capacités de Netfilter en matière de marquage des connections, matérialisées par la cible CONNMARK. Cette cible permet de marquer automatiquement tous les paquets ESTABLISHED. Ce mode de fonctionnement est activé par l'option -M de nufw. Du côté de Netfilter, les règles suivantes devront être ajoutées: iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark iptables -A POSTROUTING -t mangle -m mark ! --mark 0 -j CONNMARK --save-mark En résumé, vous devriez toujours utiliser l'option -C si vous utilisez libnetfilter_conntrack (qui est disponible dans le noyau linux depuis la version 2.6.14), et l'option -M si vous envisagez d'utiliser le marquage des connections par l'identifiant utilisateur (vueillz noter que vous devrez alors appliquer le patch suivant transmit_mark patch à votre noyau. Cette dernière option fonctionnera beaucoup mieux avec un noyau 2.6.16 et supérieur.

NuFW mémorise les états des connexions TCP suivants : opening : drapeau SYN envoyé established : drapeaux SYN et ACK envoyés closed : drapeaux FIN ou FIN,ACK envoyés Pour détecter ces paquets, nous devons utiliser les options --syn et --tcp-flags de Netfilter. Voyons un exemple : notre serveur HTTP est protégé par un pare-feu NuFW. Ils sont positionnés dans le sous-réseau $DMZ. Les règles ci-après permettent de réaliser un suivi des connexions utilisateurs pour les connexions sortantes. 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 La première règle accélère le fonctionnement de Netfilter en détectant la plus grande partie du trafic ESTABLISHED en l'acceptant. La dernière règle comportant l'option --state ESTABLISHED constitue la règle standard pour les connexions établies. Il est indispensable de l'ajouter après les règles de filtrage propres à NuFW.

Aucune régle compliquée n'est nécessaire, le noyau enverra automatiquement les nouveaux événements à NuFW. C'est pour cette raison que nous recommandons un noyau supérieur à 2.6.14.

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 simpleau moment d'écrire cette documentation en tout cas 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

Tout ce dont vous avez besoin est de créer un utilisateur SQL disposant des droits SELECT sur la table "conntrack_ulog". Puis, paramétrez le module Apache mod_auth_nufw afin qu'il utilise les informations utilisateurs/base de données et table. Le code source du module pour Apache peut être récupéré là : NuFW Apache SSO page

De la même façon, il faut ajouter un utilisateur SQL disposant du droit SELECT sur la table "conntrack_ulog". Puis, paramétrez squid_nufw_helper pour qu'il utilise ces informations. Le code source correspondant est disponible ici : NuFW Squid SSO page

Il est possible d'employer des certificats clients : si un utilisateur en fourni un lors de l'établissement de la connexion TLS, nuauth va vérifier si le DN correspond à un utilisateur connu du système. Si c'est le cas, l'utilisateur est réputé authentifié et aucun mot de passe n'est demandé. Pour activer cette fonctionnalité, vous devez definir l'option nuauth_tls_auth_by_cert à 1. Dans ce cas de figure, nuauth_tls_request_cert doit être positionné à 1 ou 2.

Les noyaux officiels sont incapables d'utiliser le marquage de paquets conjointement avec ip_queue. Il est donc nécessaire de modifier le noyau (version antérieures à 2.6.14), ce qui est possible grâce au correctif ip_queue_vwmark intégré dans patch-o-matic-ng de Netfilter. Cette opération va à la fois fournir une version modifiée du module ip_queue et du fichier libipq.a. Une fois libipq.a installé, vous pouvez alors compiler nufw : ./configure --with-user-mark ${EXTRA_OPTIONS_YOU_LIKE} make make install

nufw peut alors être exécuter avec l'option -m pour activer le support du marquage utilisateur. Cette option est compatible avec l'option -M vue au-dessus.

Dans la mesure où NuFW n'utilise que les premiers paquets de chaque connexion, il ne peut effectuer le marquage des autres. Il est donc nécessaire d'utiliser la cible CONNMARKCONNMARK est disponible dans patch-o-matic version antérieure à 2.6.11, et est inclu dans le noyau depuis la version 2.6.12. Cette cible mémorise et rétabli automatiquement le marquage sur tous les paquets concernés d'une connexion. Exemple de paramétrage simple : iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark La première règle récupère le marquage existant à l'arrivée d'un paquet et la seconde sauvegarde le marquage appliqué afin de pouvoir le restaurer plus tard.

La variable de nuauth.conf nuauth_finalize_packet_module liste les modules qui s'attache à un hook appelé juste avant l'envoi de la réponse relative à un paquet de nufw. Cela est généralement utilisé pour marquer le paquet suivant la stratégie désirée. En découpant la marque (de 32 bits) en plusieurs champs de bits, il est possible de définir une politique de marquage complexe qui peut ensuite être utilisée Une documentation complète est disponible dans le fichier suivant README.mark

Le marquage Netfilter peut être utilisé pour la qualité de service et le routage. Il devient donc possible de préciser des routes spécifiques à tel ou tel utilisateur grâce, par exemple, à la commande : ip rule add fwmark XXX lookup TABLE Il en va de même pour les opération de QoS: en utilisant la commande tc filter on peut alors répartir le trafic dans des classes spécifiques en fonction de l'identifiant utilisateur : tc filter add dev IFACE prio 5 protocol ip handle 102 fw flowid FLOWID Pour plus d'information sur le routage avancé et la qualité de service, on se référera utilement au guide lartc.

Chaque option définissant l'utilisation d'un module doit être de la forme d'une liste de modules, séparés d'un espace Pour chaque module, la syntaxe doit être de la forme : name[:type[:config file]] Exemples : name: charge le module "name" dont les directives de configuration se trouvent dans le fichier nuauth.conf name:type: charge le module "type" dont les directives de configuration se trouvent dans le fichier CONFIG_DIR/modules/name.conf name:type:conf: charge le module "type" dont les directives de configuration se trouvent dans le fichier "conf"

Analysons les exemples suivants : nuauth_user_logs_module="syslog dblocal:mysql maindb:mysql:/etc/nufw/mainmysql.conf" Les paquets seront journalisés plusieurs fois : Par syslog Dans une base MySQL en utilisant le fichier de configuration /etc/nufw/modules/dblocal.conf Dans une autre base MySQL en utilisant le fichier de configuration /etc/nufw/mainmysql.conf

Il est particulièrement recommandé de placer nuauth dans un endroit protégé afin de garantir la sécurité des communications entre nufw et nuauthMême si tous les paquets sont chiffrés par TLS. Dans la mesure où la décision du pare-feu dépend de la réponse de nuauth, il est important de pouvoir valider l'identité du serveur nuauth. Pour cela, nous pouvons demander à nufw de vérifier le certificat présenté par nuauth lors de l'établissement du tunnel TLS. Ceci peut être mis en place grâce à l'option -a suivie du nom du fichier contenant le certificat d'autorité racine. Cette option est ajoutée à la ligne de commande démarrant nufw. Ce faisant, nufw vérifiera la validité du certificat présenté par nauth.

Il est possible de restreindre le nombre de connexions qu'un utilisateur peut initier et de limiter le nombre de connexions depuis une adresse IP donnée. nuauth_single_user_client_limit: fixe le nombre maximum de connexions simultanées qu'un utilisateur peut démarrer. nuauth_single_ip_client_limit: fixe le nombre maximum de connexions simultanées ayant pour source une même adresse IP.

Du côté du client, le système doit être intègre pour que les informations conernant les applications et le système d'exploitation soient pertinentes. Vous devez toujours garder à l'esprit que seul l'agent installé côté client est capable d'obtenir ces renseignements. En cas d'attaque, il est évident que ces informations PEUVENT et SERONT faussées par l'installation d'un agent NuFW modifié. Vous devez impérativement tenir compte de cet avertissement et ne surtout pas oublier que cette fonctionnalité permet de sécuriser des flux qui auraient dû être ouvert sans vérification sur un système basiqueMerci d'éviter le syndrome ABS : Nous avons plus de sécurité, nous pouvons prendre plus de risques et freiner plus tard. La pertinence du filtrage d'application et/ou de système d'exploitation dépend de la confiance que vous placez dans le système qui réalisera l'authentification. Elle est "relativement bonne" sur un système sécurisé sur lequel les utilisateurs ne peuvent installer de logiciels.

Si voter serveur LDAP supporte les connexions SSL, il est possible de paramétrer nuauth pour qu'il se connecte en ldap over SSL. Pour se faire, il faut éditer nuauth.conf et modifier le port LDAP à 636 (ldaps) : ldap_server_port=636 L'étape suivante est l'édition du fichier /etc/ldap/ldap.conf pour indiquer la politique des connexions SSL. Pour une simple encryption des données, il suffit d'ajouter à ldap.conf: TLS_REQCERT never La configuration recommandée suppose d'utiliser une autorité de certification. Il faut pour cela éditer le fichier ldap.conf pour lui fournir le chemin vers le fichier de l'autorité de certification. Le fichier ldap.conf devrait ressembler à : TLS_CACERT /etc/ldap/cacert-ldap.pem TLS_REQCERT demand Attention, dans ce mode de fonctionnent, il est nécessaire que le nom indiqué dans le certificat du serveur LDAP et le nom d'hôte spécifié dans la variable ldap_server_addr de nuauth.conf soient identiques.

PAM permet simplement d'étendre les méthodes d'authentification à des annuaires "exotiques". Par exemple, PAM vous permet d'interfacer nuauth avec un domaine NT, Active Directory, Radius, etc. Pour réaliser l'authentification utilisasteur en s'appuyant sur PAM, vous devez paramétrer nuauth.conf (pour la 1.0): nuauth_user_check_module="system" En complément, il faut configurer correctement PAM. Ce point ne fait pas directement partie des objectifs de ce document. Voici quelques exemples de fichiers de configuration PAM basé sur la distribution GNU/Debian afin de permettre à nuauth d'utiliser l'authentification PAM : /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 Le fichier /etc/nsswitch.conf doit également être adapté : #This is to set PAM-LDAP, modify to suit your needs! passwd: compat ldap group: compat ldap (ne modifiez pas les autres lignes). Vous souhaiterez également adapter la configuration du fichier /etc/pam_ldap.conf. Ce fichier fonctionne correctement chez nous, à condition qu'il n'y ait pas de ligne commençant par "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 Vous devrez également installer et configurer libnss-ldap. La configuration suivante fonctionne pour nous (toujours sous Debian) : 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 Bien entendu, vous devez adapter ce qui précède à vos besoins propres. Souvenez-vous que ces directives ne sont peut-être pas adaptées à d'autres distribution que GNU/Debian!

Sur Debian/Ubuntu, vous aurez besoin des paquets suivants : krb5-user krb4-config samba winbind le fichier /etc/krb5.conf doit contenir quelque chose du genre : [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 Le fichier /etc/nsswitch doit ressembler à : 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 Il est très important de synchroniser l'heure du système avec les serveurs Active Directory. On peut utiliser ntp pour se faire. Le fichier /etc/samba/smb.conf doit aussi être modifié: [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 Pour joindre le Domaine Windows, on peut utiliser: kinit administrator@DOMAIN.NAME net ads join -U administrator La dernière commande devrait afficher le nom court du domaine et indiquer que l'inscription s'est bien passée. Winbind (ou winbindd) devrait tourner sur votre système. On peut vérifier le bon fonctionnement dans les journaux samba (probablement dans /var/log/samba/*).

C'est relativement limpide à réaliser : le gros du travail doit être effectué dans le fichier nuauth.conf (les différentes options sont documentées dans le fichier lui-même). Souvenez-vous qu'utiliser une authentification directe sur un LDAP vous obligera à utiliser un schéma LDAP spécifique à NuFW ce qui pourrait se révéler bloquant pour vous. Dans ce cas, envisagez sérieusement l'utilisation de PAM comme décrit ci-dessus.

Un agent, appelé NuWinC (NuFW Windows Client) est disponible pour les systèmes Microsoft Windows 95/98/NT/2000/XP/2003/Vista, auprès de la société INL. Cet agent permet, dans le cadre d'une authentification sur un domaine, un fonctionnement 100% transparent pour les utilisateurs. Pour toutes informations à propos de ce logiciel, consulter http://www.inl.fr/NuWINc.html.

MacOS X est supporté par le client graphique Nuapplet2.

Il existe plusieurs clients pour Linux : nutcpc : le client le plus léger, en ligne de commande Nuapplet2 : le client en mode graphique Authentification par PAM, au moyen du module pam_nufw. Ceci permet d'obtenir une authentification 100% transparente pour les systèmes GNU/Linux.

nutcpc fonctionne sur les systèmes FreeBSD. Pour les autres systèmes, vos retours seront accueillis chaleureusement! Par ailleurs, le portage des agents NuFW aux systèmes *NIX devrait être assez simple.

Ce type d'architecture est supporté depuis la version 1.0.11. Les versions antérieures ne fonctionnent pas.

Glibc 2.3.2 est boguée et il faut positionner system_glibc_cant_guess_maxgroups au nombre maximum de groupes pour un utilisateur.

NuFW est inclu dans la distribution Debian. Les paquets sont aussi stables que possible mais n'hésitez pas à sauvegarder votre configuration avant une mise à jour. Dans le même ordre d'idée, tout retour d'expérience est le bienvenu. Depuis la version 1.0.16, les paquets Debian sont considérés comme particulièrement stables.

NuFW est inclu dans Mandriva Corporate Server 4.

La version 9 de Suse semble utiliser une très ancienne version de Glib, qui n'est pas compatible avec NuFW. Il semble que cela soit le cas pour toutes les version de Suse jusqu'à la 9.

RHEL4 étant fournie avec la version 2.6.9 du noyau, ce système est sujet au problème lié à ip_queue comme mentionné ci-après. Le problème s'est systématiquement posé avec ce noyau (en tout cas sur les machines multi-processeurs).

Il existe un bug ip_queue dans les noyaux antérieurs au 2.6.12. Il provoque un crash du système lorsque qu'une décision ACCEPT est prise dans la chaîne INPUT. N'utilisez donc pas la cible QUEUE dans la chaîne INPUT avec ces noyaux ou vous risquez de geler votre machine. Dans tous les cas de figure vous devriez vraiment utiliser un noyau plus récent et la cible NFQUEUE, comme expliqué plus haut dans ce document.

NuFW devrait tourner sans soucis dans des environnements utilisant des interface bridge. Il est cependant à noter que le bridge semble poser des problèmes à l'utilisation de NFQUEUE. Les tests suivants ont été réalisés (avec NuFW 2.2.14, mais la version NuFW semble sans importance) : noyau 2.6.22 BUG : Tout traffic réseau est bloqué dès que le démon nufw est lancé. noyau 2.6.24 Tout fonctionne.

nufw nufw nufw est le service qui tourne sur le pare-feu. Il reçoit les paquets du noyau, les envoie au service d'authentification et récupère la réponse. nuauth nuauth nuauth est le service d'authentification qui reçoit les paquets en provenance de nufw et du client, prend une décision concernant la connexion et la renvoie à nufw.