Domaines

À propos

Contactez-nous

Crédits & mentions légales

Devenez auteur

Les Éditions Diamond recrutent

Liste des sondages de nos magazines

Logo / Bannières

Recherche par auteur

Historique et enjeux du filtrage IP par utilisateur

Les techniques de filtrage IP ont grandement évolué au cours de la dernière décennie. D'un filtrage individuel des paquets, on est passé aujourd'hui à un filtrage avec notion d'états (stateful inspection [1]), qui améliore les performances et surtout la sécurité des filtres : par exemple, pour TCP, les filtres plus anciens, ne disposant pas de tables d'états, laissaient systématiquement passer les connexions à destination de ports hauts... Actuellement, les évolutions se font dans deux directions majeures : d'une part, l'inspection du contenu des paquets, d'autre part, l'identification et l'authentification des utilisateurs à l'origine des paquets avec prise en compte de ces informations au niveau du filtre IP. Si les solutions théoriques pour l'inspection des paquets sont globalement connues, il n'en est pas de même de l'identification des paquets où des voies nouvelles sont en cours d'exploration. Le logiciel NuFW est l'implémentation d'une méthode innovante d'authentification qui passe outre l'association IP==utilisateur, ce qui présente des avantages autant d'un point de vue fonctionnel qu'en termes de sécurité.

Faiblesses de l'approche utilisateur == machine :

La plupart des systèmes de filtrage authentifiant proposent une authentification des flux par l'association d'une adresse IP à un utilisateur, considérant implicitement réalisée l'association utilisateur == machine. Cette méthode était une réponse appropriée dans les années qui ont vu les premiers développements des pare-feu puisque la quasi-totalité des parcs de micro-ordinateurs était constituée de machines utilisant un système d'exploitation mono utilisateur (quoique...). Le développement et le retour des systèmes multiutilisateurs (Terminal Server, Citrix, Systèmes UNIX-like " envahissant " le poste de travail) ont rendu cette association caduque au niveau fonctionnel en rompant l'association utilisateur == machine. De plus, au niveau de la sécurité, ce genre d'approche recèle une faille importante de par son principe même. En effet, ces solutions d'authentification reposent sur l'association à un moment donné entre adresse IP et utilisateur (cette association est réalisée par diverses méthodes : de nombreuses " boîtes noires " utilisent HTTPS [2] ; OpenBSD l'implémente sur OpenSSH avec Authpf [3]...). Les paquets ensuite reçus de la machine sont supposés provenir de l'utilisateur, un mécanisme s'assurant dans le meilleur des cas de la persistance de la validité de l'association. L'authentification des paquets réalisée par ce type de système – dite a priori – est donc sujette à diverses attaques (comme par exemple l'attaque du type arp-spoofing) utilisant la rémanence de l'association IP==utilisateur pour usurper l'identité de l'utilisateur.

Apports de l'identification des paquets

L'identification des paquets est vue généralement comme une solution résolvant un problème d'administration système et réseau. L'établissement d'une politique de sécurité avancée dans une organisation vise à différencier les entités (individus, processus, etc.), la finalité étant d'autoriser les accès de chaque entité aux seules ressources auxquelles elle a droit. Au niveau du filtrage, il est par conséquent nécessaire d'identifier l'auteur de chaque flux pour mettre en œuvre une telle politique. Ce genre de problématique est classiquement résolu en associant à chaque utilisateur l'adresse IP de sa machine lors de l'écriture de règles de filtrage et en générant des règles d'accès pour cette machine. Cette technique, encore très couramment utilisée, est inapplicable si les utilisateurs sont mobiles (que ce soit physiquement ou, par exemple, au niveau IP dans le cadre d'un réseau en DHCP). Par ailleurs, comme vu ci-dessus, ce genre de système est peu fiable. Un système d'authentification est nécessaire pour appliquer des politiques individualisées dans le cadre de ces réseaux. Ceci permet de plus de gérer des règles traitant directement des utilisateurs, simplifiant au passage le travail de l'administrateur. Bien entendu, cette solution s'appuie sur une notion d'identifiant unique pour chaque utilisateur, à l'échelle d'un réseau. Un autre intérêt découle d'un tel système : le pare-feu connaissant l'association entre flux et utilisateur, il sait être une source d'identification pour l'ensemble des services d'un système d'information. L'authentification des paquets a plusieurs conséquences. D'une part, la réalisation de politiques de filtrage individualisées, d'autre part, de fournir une infrastructure permettant de construire une solution d'authentification unique – Single Sign On – indépendante du protocole.

NuFW : une solution d'authentification des flux IP a posteriori

NuFW (Now User Filtering Works [4] [5]) est un système résultant du rapprochement du filtre IP et de l'annuaire des utilisateurs d'un réseau (LDAP ou autre). Cet article vise à présenter les idées à la source du projet, ainsi que les avantages induits par ce rapprochement. L'aspect des performances du filtre IP est également étudié. Dans la deuxième partie de cet article, les aspects pratiques de l'installation et du paramétrage de NuFW seront abordés.

Principes

Le logiciel NuFW propose une solution d'authentification a posteriori des flux, fondée sur Netfilter, la couche de filtrage IP du noyau Linux. Avec NuFW, chaque utilisateur doit démontrer son identité à chaque initialisation de connexion (le terme " connexion " est à prendre au sens du Conntrack de Netfilter, pas au sens classique associé à TCP ; le Conntrack étend cette notion aux protocoles non connectés, tels UDP ou ICMP [6]). Une fois l'identité de l'utilisateur établie, le paquet est ensuite filtré, selon les droits associés à l'utilisateur. Si ce premier paquet est accepté, alors les autres paquets appartenant à la même connexion sont gérés par le système de suivi d'état de Netfilter : seul le paquet d'initialisation d'une connexion est authentifié. Ce principe de fonctionnement requiert la présence d'un client logiciel sur le poste de l'utilisateur. Des clients NuFW existent pour Microsoft Windows et GNU/Linux. Un mode sans client est également disponible dans NuFW. Il délègue l'authentification à un module externe, adjoint au serveur, nuauth. Il est ainsi possible de se passer d'un client logiciel sur le poste utilisateur en utilisant par exemple une authentification par identd. Un tel mode d'authentification par Netbios est également envisagé. Dans tous les cas, le mode sans client est un mode " dégradé " puisque l'autorité de confiance est le client lui-même.

Systèmes multiutilisateurs

Avec NuFW, chaque connexion est associée à un utilisateur, avant même que soit prise une décision concernant son acceptation. Ce système réalise donc un filtrage par utilisateur, même si plusieurs utilisateurs travaillant sur une même machine génèrent simultanément des flux à partir d'une même adresse IP source. Avant de statuer sur chacune des connexions, le pare-feu NuFW demandera la validation de l'identité de chacun des utilisateurs et appliquera à chaque connexion les droits associés à son utilisateur.

Performances

Puisque la tâche d'authentification est réalisée uniquement lors de l'arrivée du premier paquet de chaque connexion et puisque le reste du flux relatif à la connexion est pris en charge par le système de suivi de connexions de Netfilter, la charge du système d'authentification est largement limitée. Outre de grands avantages en termes de charge réseau, cette méthode garantit que l'impact de NuFW en terme de débit sur le pare-feu est inexistant : seuls les paquets d'initialisation de connexion sont concernés par le procédé d'authentification. De plus, il est à noter que la qualité de service des applications interactives (h323...) n'est pas affectée par NuFW : un délai est mesurable à l'initialisation des connexions, puis le trafic s'écoule interactivement comme avec un filtre " classique ".

/img-articles/misc/18/art-7/t1.jpg

Un bench de performances a été réalisé, dont voici un bref résumé. Le port discard a été utilisé, sur Internet, vers une machine rejetant les paquets (renvoi d'un paquet ICMP " connexion refused "). Le protocole de test est très simple et porte dans notre cas uniquement sur le temps d'ouverture d'une connexion. Pour charger les démons NuFW, nous lançons l'ouverture consécutive de 1000 connexions vers un serveur sur Internet. Dans le premier cas, les paquets transitent par NuFW et sont donc l'objet d'une authentification. Dans le deuxième cas, les paquets sont autorisés directement par le filtre IP (règle Netfilter " ~~-j ACCEPT~~ "). Voici les résultats de ce test:

/img-articles/misc/18/art-7/t2.jpg

Nous constatons donc que dans un schéma proche de l'attaque de type denial of service, NuFW se comporte très bien. Il a acheminé tous les paquets, en réalisant ses tâches d'authentification en un temps plus long (comme prévu) que sur un filtre IP classique, mais dans la même échelle de temps (moins de 2 fois le temps sur un filtre classique). Rappelons que dans un environnement de production les connexions TCP sont conçues pour durer plus longtemps et donc lisser largement cet écart de temps. La suite de filtrage NuFW dans son ensemble s'est par ailleurs montrée très stable au cours des derniers mois dans le cadre d'une installation en production.

Autres fonctionnalités de NuFW

Au-delà d'une extension sécurisée des règles de filtrage à la notion d'utilisateur, NuFW apporte un certain nombre de fonctionnalités intéressantes.

Surveillance des systèmes

NuFW contribue de manière très pointue à la surveillance de l'activité réseau des serveurs : toutes les implémentations modernes de serveurs attribuent des utilisateurs système distincts aux services qu'ils font tourner. NuFW permet naturellement de définir, pour les serveurs, une politique réseau différente pour chaque utilisateur système. Ces différents cas de figure sont traités pratiquement dans la deuxième partie du présent article. Par exemple, sur un serveur Web, le superutilisateur se connecte généralement à Internet pour vérifier et éventuellement télécharger les mises à jour de sécurité. D'un autre côté, si l'utilisateur qui fait tourner le serveur Web sur la même machine tente d'ouvrir une connexion, il est probable qu'il ait été compromis : NuFW bloque le trafic et alerte les administrateurs.

Filtrage par système d'exploitation ou par application

Profitant de la présence du client logiciel sur le poste utilisateur, NuFW filtre également le trafic selon l'OS ou l'application à sa source. Il est par exemple possible de créer une règle qui autorise uniquement Mozilla ou Thunderbird, tournant sous Windows XP, à se connecter à un serveur IMAP donné et de refuser les connexions ayant pour origine un autre système d'exploitation ou une autre application. À noter que NuFW fait confiance sur ce point aux informations transmises par l'agent installé sur le poste client. La pertinence de ces informations est à relativiser. En effet, on ne peut pas exclure l'hypothèse d'un utilisateur malveillant se servant d'un agent modifié ou encore l'hypothèse d'un virus ou autre programme mal intentionné envoyant de fausses informations au serveur NuFW. Il reste possible de positionner des règles de filtrage strictes à la condition d'accorder une confiance importante dans l'intégrité du poste de travail. Par exemple, un tel filtrage est envisageable sur une machine d'un LAN sur lesquels les utilisateurs n'ont pas les droits d'installation.

Qualité de service différenciée et routage par utilisateur

NuFW est capable de marquer chaque paquet d'une connexion avec l'identifiant de son utilisateur et donc d'appliquer une politique de qualité de service spécifique à chaque utilisateur. Il est ainsi possible d'attribuer à un utilisateur une certaine bande passante globale. L'implémentation d'une politique de routage différenciée est une des conséquences de cette fonctionnalité. En résumé, NuFW sait attribuer très finement la bande passante et la priorité du trafic réseau, par utilisateur et par protocole et ceci même sur les machines multiutilisateurs.

Suivi de l'activité des utilisateurs

NuFW dispose de modules de surveillance qui journalisent les événements principaux de l'activité du réseau en indiquant quels sont les utilisateurs à l'origine des flux : ouverture de connexion, établissement de connexion, fermeture de connexion, paquets bloqués par le système. Les modules de logs existant utilisent au choix Syslog, PostgreSQL ou encore MySQL. NuFW garde la trace de chaque connexion ouverte (ou tentée). Par exemple, grâce aux modules SQL, il est très facile de visionner les connexions initialisées par M. Dupont au cours du mois dernier, même si ce dernier a changé d'adresse IP ou d'endroit et ce y compris si M. Dupont partage son poste de travail avec d'autres utilisateurs.

Authentification unique (Single Sign On)

NuFW permet d'identifier les utilisateurs des applications réseau, de manière simple, par Single Sign On. Les modules de journalisation SQL maintiennent en temps réel une table des connexions associant connexion et utilisateur. Par exemple, pour TCP ou UDP, une connexion d'un utilisateur est identifiée de manière sûre, en partant des 5 paramètres suivants : adresse IP source, adresse IP destination, port source, port destination, marqueur de temps (le lecteur averti a déjà noté la possible omission de l'adresse et du port destination). Ainsi, faire une requête sur la base SQL de NuFW portant sur ces paramètres conduit à une identification fiable de l'utilisateur à la source de la connexion. Par conséquent, toute application réseau qui doit identifier un utilisateur est capable de déterminer l'identité de ce dernier en interrogeant le système de suivi de connexions de NuFW. Ce fonctionnement est facilement extensible à toute application réseau client/serveur et garantit une identification stricte, transparente et sécurisée des utilisateurs. À l'heure de l'écriture de cet article, des modules SSO NuFW [7] sont fonctionnels pour Apache, et pour Squid, et illustrent la validité de ce principe. En termes de performances, nos tests – réalisés avec AB (Apache Bench) – montrent que le fonctionnement de NuFW en mode Single Sign On a un impact non perceptible par l'utilisateur.

Installation et configuration de NuFW

Architecture de NuFW

Principe de fonctionnement

Une installation typique de la suite logicielle NuFW comporte 2 démons : ~~nufw~~ et ~~nuauth~~ et autant de clients que nécessaire. Commençons par une description rapide du travail de chaque démon. Le démon nufw est très léger et tourne sur la même machine que le filtre de paquets (Netfilter). Il dialogue avec Netfilter au moyen de la librairie ~~libipq~~ (et de la cible ~~-j QUEUE~~), reçoit des données au sujet des paquets à authentifier, dialogue avec le démon ~~nuauth~~ et renvoie la décision à Netfilter. nuauth est un démon multithreadé, qui réalise le cœur des opérations d'authentification : il dialogue avec les clients pour associer à chaque flux un utilisateur, authentifie les utilisateurs auprès d'un annuaire et vérifie également leurs droits au moyen d'ACL (typiquement gardées dans une structure d'annuaire, également). Un seul démon ~~nuauth~~ peut travailler en concordance avec plusieurs pare-feu installés avec des démons NuFW. Dans la branche 0.9, ~~nuauth~~ s'est vu ajouter un système de cache interne qui a permis de largement optimiser ses performances. Nous allons voir que le démon ~~nuauth~~ dispose également d'autres fonctionnalités, notamment en ce qui concerne la gestion des journaux. Coté client, le travail réalisé par le logiciel est très simple : il consiste, pour chaque paquet IP à authentifier, à envoyer au démon ~~nuauth~~ des données propres à ce paquet, l'identifiant de l'utilisateur et son mot de passe (ou sa clé), le tout crypté afin de garantir qu'un attaquant ne puisse rejouer le scénario ou authentifier ses propres paquets IP en usurpant l'identité d'un utilisateur légitime. Les clients ne supportent pour l'instant que l'authentification des connexions TCP, l'ajout d'UDP faisant parti des fonctionnalités planifiées. A noter que dans le cas d'une connexion TCP, seul le paquet d'ouverture (SYN) est authentifié ; la suite de la connexion est gérée par le suivi d'état de Netfilter.

Composants logiciels et dépendances

L'ensemble des briques présentées ci-avant est codé en C. Le démon ~~nufw~~ est conçu pour s'intégrer aux architectures ayant de faibles ressources (comme les appliances). Il est donc le plus léger possible tant au niveau des ressources système qu'au niveau des dépendances logicielles. Il s'appuie uniquement sur la libc et la bibliothèque ~~libipq~~ pour le dialogue avec Netfilter, avec toutefois aussi ~~gnutls~~ pour la partie chiffrement. À ce jour, le démon ~~nufw~~ tourne sur le noyau Linux uniquement. Le démon ~~nuauth~~ utilise quant à lui la librairie ~~glib~~ et profite de ses nombreuses abstractions, notamment au niveau de la gestion des threads. Les communications sur le réseau sont chiffrées par TLS (utilisation là aussi de la bibliothèque ~~gnutls~~) et l'authentification, qui utilise SASL, repose sur la bibliothèque ~~cyrus-sasl~~.

Modules d'authentification et de journalisation

La modularité de ~~nuauth~~ s'exprime au niveau des interactions avec le système qui sont réalisées par des modules. Ainsi l'authentification et la gestion des groupes utilisateur, le stockage et la vérification des ACL et la journalisation des évènements sont faits par l'intermédiaire de modules utilisant soit du code propre à NuFW, soit des briques ou des services leaders du Logiciel libre. Base de stockage des utilisateurs et groupes La gestion des données utilisateur est réalisée par l'un des modules :

~~system~~ : ce module reposant sur PAM et NSS apporte à NUFW la puissance des modules déjà développés pour ces deux systèmes et garantit une intégration optimale au système d'information.
~~ldap~~ : une classe d'objet LDAP spécifique permet d'obtenir les informations d'appartenance aux groupes en une requête contrairement à la solution de stockage couramment utilisée (PAM, NSS notamment). Ceci fait de ce module une solution efficace.
~~dbm~~ : les données relatives aux utilisateurs sont stockées dans un fichier dbm que l'on maintient grâce à un utilitaire fourni dans les sources.
~~plaintext~~ : ce module particulièrement facile à déployer, mais réservé aux installations avec un faible nombre d'utilisateurs, stocke les informations dans un fichier plat.

Base de stockage des ACL Une Access List (ACL) met en jeu un sujet et un objet et associe à ce couple une décision : ~~ACCEPT~~ ou ~~DROP~~. Pour NuFW, un sujet est composé d'informations à propos d'une adresse IP source, l'identifiant d'un groupe ou encore d'une application ou d'un système d'application et de leurs versions. Le seul élément obligatoire dans la définition d'un sujet est un ensemble non vide de groupes utilisateur. Un objet est composé des informations : adresse IP destination, protocole, ports source et destination... De cette manière, on peut par exemple autoriser les membres du groupe administrateurs à se connecter vers Internet sur le port TCP 22, avec comme application uniquement ~~/usr/bin/ssh~~. Toute tentative de sortie en ssh par un autre utilisateur ou en utilisant une autre application sera refusée et fera l'objet d'une entrée dans les journaux, contenant l'identifiant de l'utilisateur à la source du trafic illégitime, le nom de l'application utilisée, son nom et version de système d'exploitation, ainsi que tous les paramètres IP habituels. Comme pour le stockage des utilisateurs et groupes, l'architecture de nuauth est modulaire et donc extensible. A ce jour, existent un schéma LDAP dédié pour stocker les ACL dans un annuaire et un module ~~plaintext~~. Journalisation Le mode le plus simple pour la journalisation est l'utilisation de Syslog. Un choix est possible en ce qui concerne les informations à journaliser : accès refusés, ouvertures de connexions, etc. Les modes plus évolués en ce qui concerne la journalisation utilisent des bases de données SQL et sont nécessaires à l'utilisation des capacités d'Authentification Unique (Single Sign On) de la suite NuFW. A ce niveau, ces modules sont en réalité une sorte de conntrack étendu : ils garantissent une mise à jour en temps réel d'une table SQL avec toutes les données habituelles stockées dans le conntrack de Netfilter, avec en plus les notions d'utilisateur, d'application et de système d'exploitation source, associées à chaque connexion. La puissance du principe de requêtage lié à SQL s'exprime grâce à une interface comme ~~nulog [8][9]~~. A ce jour, les bases de données supportées sont MySQL et PostGreSQL.

Installation de NuFW

Cette partie décrit une installation typique de la suite NuFW, dans la branche 1.0.X, utilisant :

authentification utilisateur par PAM et NSS (module ~~system~~) ;
stockage des ACL grâce à LDAP (module ~~ldap~~) ;
journalisation par MySQL (module ~~log_mysql~~).

Compilation

Pré-requis Les bibliothèques suivantes ainsi que leurs en-têtes respectifs sont impliqués dans la compilation :

~~libglib2.~~0
~~iptables~~ : le fichier ~~libipq.a~~ est nécessaire à la compilation du serveur NuFW
~~libsasl2~~
~~libgnutls11~~
~~libldap2~~
~~libmysqlclient~~

~~libtool~~ est lui utilisé pour la génération des modules. Paramétrage du noyau En ce qui concerne la compilation du noyau l'option ~~CONFIG_IP_NF_QUEUE~~ doit être incluse, que ce soit en dur ou en tant que module (~~ip_queue~~). La plupart des noyaux officiels des distributions sont compilés avec cette option. Un chargement du module ~~ip_queue~~ est donc sans doute la seule étape à réaliser. Optionnellement, il est possible de patcher le noyau avec le ~~patch-o-matic-ng [10]~~ pour ajouter le marquage de paquets par utilisateur, ce qui offre la possibilité de mettre en place, par exemple, de la Qualité de Service (QoS) par utilisateur ou par application. Le nom du patch à appliquer est ~~ip_queue_vwmark~~. Dans ce cas, ~~iptables~~ doit être également recompilé pour injecter le ~~libipq.a~~ modifié par le patch ~~ip_queue_vwmark~~ et ce, avant la compilation de NuFW. Configuration et compilation L'archive de NuFW doit tout d'abord être téléchargée [11]. Nous configurons notre installation pour journaliser les événements dans une base de données Mysql, authentifier les utilisateurs et lire les ACL dans un arbre LDAP. L'option ~~--with-user-mark~~ sert à marquer les paquets dans une optique de QoS, en utilisant comme critère par exemple l'identifiant de l'utilisateur.

$ ./configure --with-mysql-log --with-ldap --sysconfdir=/etc/nufw/ 
[--with-user-mark]

Installation et tests de fonctionnement

Par défaut, tous les fichiers installés depuis l'archive le sont bien sûr dans ~~/usr/local/~~. Installation des certificats Dans le cadre de cet article, les certificats de test fournis dans l'archive de NuFW sont utilisés. Bien entendu, vous pouvez générer vos propres certificats SSL x509 à ce stade.

Pour ~~nufw~~ :

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

Pour ~~nuauth~~ :

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

Pour les clients (~~nutcpc~~ - sous Linux), pour chaque utilisateur, l'outil ~~tinyca[12]~~ (packagé dans la Debian) fait parfaitement le travail.

mkdir ~/.nufw
tinyca

Les fichiers certificat et clé doivent respectivement être sauvegardés sous les noms : ~~~/.nufw/cert.pem~~ et ~~~/.nufw/key.pem~~. Il est bien sûr possible d'utiliser pour tester les certificats et les clés fournis avec les sources. Installation du SQL Il faut créer la base MySQL et l'initialiser au moyen du fichier ~~nulog.mysql.dump~~ fourni dans l'archive.

mysqladmin create ulog
cat conf/nulog.mysql.dump | mysql ulog

Il faut ensuite créer un utilisateur capable de faire les modifications appropriées dans la table ~~ulog~~ :

#mysql mysql
> GRANT INSERT,UPDATE ON ulog.ulog TO 'nuauth'@'localhost' IDENTIFIED BY 'goodsecret';

Configuration

Configuration de l'annuaire LDAP pour le stockage des ACL

Il faut tout d'abord ajouter le schéma de stockage des ACL au LDAP. Pour cela, il faut copier le fichier acls.schema dans ~~/etc/ldap/schema~~ et éditer ~~/etc/ldap/slapd.conf~~ en rajoutant sous les lignes include du début de fichier :

include         /etc/ldap/schema/acls.schema
On ajoute ensuite les règles d'accès LDAP :
#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 sera utilisé par les scripts pour effectuer les modifications dans l'arbre et l'utilisateur ~~nuauth~~ réalisera les requêtes en lecture pour ~~nuauth~~. Configuration de nuaclgen Le script ~~nuaclgen~~ est un outil de gestion basique des ACL dans la base LDAP. Les données de connexion à l'annuaire sont à paramétrer dans le fichier ~~conf/nuaclgen.conf~~ qu'on copiera dans ~~/etc/nufw/~~ :

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

Ce fichier contenant des données sensibles doit posséder des droits limités. Pour tester :

nuaclgen -A cn=ssh,ou=Acls,dc=inl,dc=fr -p 6 --dport 22 -AppName "/usr/bin/ssh" -j ACCEPT -g 513

On donne ainsi accès au port du protocole ssh aux utilisateurs du groupe 513, s’ils utilisent le binaire ssh. Le regroupement des utilisateurs en groupes est utilisé de manière traditionnelle afin de définir des politiques d'accès pour des utilisateurs au profil proche les uns des autres. Ou encore pour les accès provenant d'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 donne aux membres du groupe 1042 (qui contient des utilisateurs propres aux comptes root de nos serveurs Web) l'autorisation de réaliser les mises à jour de notre distribution favorite. Ainsi, à supposer que l'utilisateur Apache tente une requête vers un autre serveur Web, il sera bloqué, et sa tentative sera journalisée. En revanche, à supposer que notre serveur Web soit un proxy inversé, l'utilisateur Apache doit effectivement accéder aux ressources Web sur d'autres serveurs :

nuaclgen -A cn=apache-proxy,ou=Acls,dc=inl,dc=fr -p 6 --dport 80 -AppName "/usr/sbin/http" -da "192.168.50.0/24" -j ACCEPT -g 1043

où le groupe 1043 est dédié aux utilisateurs Apache des serveurs Web. Le support d'un switch ~~AppSig~~ pour signer en SHA1 les binaires autorisés à envoyer des flux réseau est en cours de développement. Pour effacer une règle, il faut utiliser le switch ~~--Delete~~ suivi du DN de l'ACL à enlever.

Configuration de nuauth

La configuration choisie utilise le module d'authentification des utilisateurs ~~libsystem~~ et le module de gestion des ACL ~~libldap~~. Il faut donc modifier le fichier ~~/etc/nufw/nuauth.conf~~ en conséquence :

nuauth_user_check_module="libsystem"
nuauth_acl_check_module="libldap"

Pour utiliser le module de gestion des ACL LDAP, il faut paramétrer le DN de connexion à l'arbre :

# dn and password to bind ldap connexion to
ldap_bind_dn="uid=nuauth,ou=Users,dc=inl,dc=fr"
ldap_bind_password="secretpassword"

et les bases de recherche pour les ACL :

ldap_basedn="dc=inl,dc=fr"
ldap_acls_base_dn="ou=Acls,dc=inl,dc=fr"

La variable de configuration ~~nufw_gw_addr~~ spécifie la liste des serveurs NuFW autorisés à se connecter.

Paramétrage du pare-feu

Nous avons vu que, pour TCP, seuls les paquets d'initialisation de connexion sont à passer à NuFW. On positionne donc pour ssh une règle telle que :

iptables -A intranet-dmz -s 10.0.0.0/8 -p tcp --dport 22 -m state --state NEW \\
--syn -j QUEUE
iptables -A intranet-dmz -m state --state ESTABLISHED,RELATED -j ACCEPT

Nous envoyons en ~~QUEUE~~ uniquement les paquets SYN. C'est un schéma possible de fonctionnement pour NuFW, mais pas encore le meilleur : ne seront journalisées dans ce cas que les ouvertures de connexions, pas les passages en mode établi ni les fermetures.

Tests du système d'authentification

Démarrage des services Pour tester le processus d'authentification, il faut lancer les services nécessaires :

nuauth -vvvvvvvvv
nufw -vvvvvvvvv

Il faut ensuite lancer un client, par exemple sous GNU/Linux :

nutcpc -d -H [IP DE NUAUTH]

et entrer le nom et le mot de passe d'un utilisateur système. L'authentification de l'utilisateur a alors réussi si ~~nutcpc~~ ne rend pas la main. Au niveau de ~~nuauth~~, on doit voir un message identifiant l'utilisateur du type :

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

Attention ! En lançant ~~nutcpc~~, ne jamais lui spécifier ~~'localhost'~~ ou ~~'127.0.0.1'~~, même si ~~nuauth~~ écoute sur la même machine. En effet, les paquets interceptés en sortie seront vus sur l'interface externe et l'authentification ne sera jamais demandée sur l'interface locale. Pour les systèmes Microsoft, un client est également disponible [13] (sous licence propriétaire) ; une version d'évaluation est téléchargeable. Test initial et processus de debug Un appel de ssh vers une machine dans la DMZ déclenche alors le processus d'authentification :

~~nufw~~ reçoit un paquet intercepté par Netfilter :

[PID] Sending request for 3352783904

~~nufw~~ se connecte en TLS à ~~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=32803 dport=22

~~nuauth~~ envoie une requête de demande d'authentification au client situé sur l'IP source :

       ** Message: need to warn client
       ** Message: sending request

~~nuauth~~ reçoit le paquet d'authentification venant du client :

       ** Message: User :
       ** Message: Connection : src=192.168.75.2 dst=192.168.75.2 proto=6
       ** Message: sport=32803 dport=22
       ** Message: OS : Linux 2.6.9 #1 Tue Oct 19 23:51:32 CEST 2004
       ** Message: Application : /usr/bin/ssh

~~nuauth~~ envoie la réponse à ~~nufw~~ :

       Sending auth answer 1 for 3352783904 on 0x42428482 ...

~~nufw~~ réinjecte le paquet :

[PID] Accepting 3352783904

Lorsque la connexion au serveur ssh réussit ou que tout du moins l'ensemble des étapes précédentes a été observé si vous avez choisi de rejeter les paquets, il est bon d'arrêter la phase de déboguage en relançant les services avec des options moins bavardes et avec l'option -D qui transformera nufw et nuauth en vrais démons.

Construire un système d'authentification unique

Afin de tester les fonctionnalités d'authentification unique de NuFW, nous allons mettre en place une authentification transparente sur un serveur Apache en utilisant le module ~~mod_auth_nufw.~~ On commence donc par rajouter une règle de filtrage du ~~port 80~~ :

nuaclgen -A cn=webdmz,ou=Acls,dc=inl,dc=fr -p 6 --dport 80 -j ACCEPT -g 513

Il faut également positionner la règle Netfilter qui nous enverra les paquets Web :

iptables -A intranet-dmz -s 10.0.0.0/8 -p tcp --dport 80 -m state --state NEW --syn -j QUEUE

Paramétrage du suivi de connexions authentifiées

Configuration de nuauth et du backend MySQL Il faut paramétrer les variables décrivant la connexion dans ~~nuauth.conf~~ :

~~mysql_server_addr~~ : adresse IP ou nom du serveur MySQL (localhost)
~~mysql_server_port~~ : port sur lequel le serveur MySQL écoute (3306)
~~mysql_user~~ : utilisateur MySQL capable d'effectuer des ~~INSERT~~ et des ~~UDPATE~~ sur la table (~~nuauth~~)
~~mysql_passwd~~ : mot de passe associé (goodsecret)
~~mysql_db_name~~ : nom de la base de donnée (~~ulog~~)
~~mysql_table_name~~ : table dans laquelle il faut modifier les informations (~~ulog~~)

Note : si pour une raison quelconque, la base SQL est déconnectée ou arrêtée pendant le fonctionnement de nuauth, celui continue d'effectuer ses tâches d'authentification. Dès que la base sera redémarrée, il reprendra la journalisation sans qu'une action particulière de l'administrateur soit nécessaire. Il faut enfin indiquer à ~~nuauth~~ que l'on souhaite réaliser un suivi de connexions complet. Pour cela, il faut positionner ~~nuauth_log_users~~ à 8 dans ~~nuauth.conf~~. Mise en place des règles du pare-feu Afin de réaliser une table d'états des connexions SQL, on enregistre les événements majeurs de la vie de chaque connexion TCP (~~OPEN~~, ~~ESTABLISHED~~, ~~CLOSE~~). Cette information doit remonter du pare-feu vers nuauth et il est donc nécessaire de mettre en place un jeu de règle de filtrage plus complexe et spécifique :

#Ligne déja positionnée ci-avant
iptables -A intranet-dmz -s 10.0.0.0/8 -p tcp --dport 80 -m state --state NEW \\
 --syn -j QUEUE
#Le paquet SYN+ACK de retour de connexion est intercepté pour repérer le
#passage en état établi
iptables -A dmz-intranet -s 10.0.0.0/8 -p tcp --sport 80 -m state --state ESTABLISHED --tcp-flags SYN,ACK,RST,FIN SYN,ACK -j QUEUE
#Paquets de fermeture de connexion
iptables -A intranet-dmz -s 10.0.0.0/8 -p tcp --dport 80 -m state --state ESTABLISHED --tcp-flags RST RST -j QUEUE
iptables -A intranet-dmz -s 10.0.0.0/8 -p tcp --dport 80 -m state --state ESTABLISHED --tcp-flags FIN FIN -j QUEUE
iptables -A intranet-dmz -m state --state ESTABLISHED -j ACCEPT

Voici enfin un jeu de règles Netfilter plus complet, qui journalise tous les états des connexions dans la base SQL. La première règle envoie au démon ~~nufw~~ le premier paquet de chaque connexion TCP ssh. La deuxième transmet le paquet ~~SYN+ACK~~, qui correspond au moment de l'établissement de la connexion (troisième étape du TCP handshake). Les troisième et quatrième règles servent à intercepter les paquets de fermeture de connexion, pour positionner l'état sur ~~CLOSE~~. Pour ces trois règles où le paquet est envoyé en ~~QUEUE~~, NuFW garantit que la décision sera bien sûr ~~ACCEPT~~. A noter que ces règles modifient sensiblement la conceptualisation des règles d'un pare-feu : en particulier, la règle d'acceptation de tous les paquets de connexions établies n'est plus suffisante puisqu’elle empêcherait la traversée de certaines des règles décrites ici. L'organisation des règles est donc à penser soigneusement et l'impact en terme de performances sur un pare-feu très chargé doit être évalué pour un système en production.

Module d'authentification Apache

Préparation de la base SQL Le serveur Apache doit réaliser des requêtes sur la base SQL pour savoir quel est l'utilisateur à l'origine des connexions. On crée donc un utilisateur capable de faire des select sur la base :

# mysql mysql
> GRANT SELECT ON ulog.ulog TO 'apache'@'webserver' IDENTIFIED BY 'anothergoodsecret';

Compilation du module Il faut tout d'abord télécharger l'archive du module apache 1.3 [14], puis l'extraire et enfin le compiler (apxs doit être installé sur le système) :

$ ./configure --with-mysql

Pour compiler le module, ~~apxs~~ est nécessaire. Configuration d'Apache Le premier pré-requis est le chargement du module dans la configuration d'Apache.

LoadModule mod_auth_nufw modules/mod_auth_nufw.so

Il faut ensuite positionner les directives de configuration dans la configuration d'Apache. Dans ce cas d'exemple, le répertoire ~~/foo/bar~~ sera accessible uniquement aux utilisateurs identifiés par NuFW, en SSO.

<Directory /foo/bar>
  #Enable NuFW SSO auth
  AuthNufwEnabled On
  #Dont fallback on any other auth scheme if this one fails.
  AuthNufwAuthoritative On
  #Paramètres pour accéder à notre serveur SQL
  AuthNufwSQLHost sqlserver.inl.fr
  AuthNufwSQLPort 3306
  AuthNufwSQLDatabase ulog
  AuthNufwSQLTable ulog
  AuthNufwSQLUser apache
  AuthNufwSQLPassword anothergoodsecret

  AuthType Basic
  Require valid-user
</Directory>

Dans ce fonctionnement, un utilisateur sera autorisé si et seulement si la connexion a été autorisée par NuFW. Dans ce cas, le nom de l'utilisateur apparaîtra dans le journal d'accès d'Apache, exactement comme pour une authentification " classique ". Il est également possible d'authentifier les utilisateurs par un autre moyen (comme une authentification classique) si l'authentification n'est pas réussie en utilisant NuFW (par exemple pour des utilisateurs venant d'un réseau non-couvert par NuFW). C'est l'usage de la directive AuthNufwAuthoritative. Voir également la documentation fournie avec le module pour des fonctionnalités plus avancées. Bien entendu, le serveur Apache peut disposer d'ACL plus évoluées, par l'utilisation d'un module d'autorisation (par exemple, un module de règles d'accès aux ressources du serveur, stockées dans LDAP), mais cela sort du champ direct de NuFW. Un module pour Squid est également disponible [15]. Il fournit sensiblement les mêmes fonctionnalités SSO pour l'authentification des utilisateurs sur Squid, y compris pour authentifier les accès sur des serveurs proxy transparents.

Conclusion

La suite logicielle NuFW propose une identification et une authentification strictes des utilisateurs d'un réseau, pour tous les flux. Au-delà des possibilités très fines que ce système apporte à la conception de règles de filtrage et du suivi de l'activité des utilisateurs, NuFW est le fondement d'une solution de Single Sign On (Authentification Unique) très élégante et facilement extensible. Le modèle du Logiciel libre, parfois critiqué comme " à la traîne " et copiant les inventions du monde propriétaire, montre par ce projet qu'il est tout à fait capable d'apporter des innovations [16], y compris dans le domaine de la sécurité des réseaux. Références