Présentation de NuFW
Signature : , | Mis en ligne le : 07/06/2008
Catégorie(s) :
  • GNU/Linux Magazine
  • | Domaine :
    Commentez

    Retrouvez cet article dans : Linux Magazine 84

    Cet article vise à présenter le fonctionnement du pare-feu authentifiant NuFW [NuFW], d’une part en montrant les principes qui sous-tendent sa conception et, d’autre part, en construisant une architecture de test. La première partie constitue donc une présentation de NuFW et la suite de cet article est un exercice d’utilisation pratique de filtrage authentifié. Cet article est le premier d’une série de trois centrés sur NuFW. Dans les articles à venir, plutôt orientés développeurs, nous verrons comment NuFW interagit de manière fine avec Netfilter et comment la Glib nous permet de faciliter la gestion des threads et de la mémoire.

    /img-articles/lm/84/art-4/fig-1.jpg

    Quelques rappels sur le filtrage IP et Netfilter

    Quand Internet a cessé d’être un réseau de privilégiés et a découvert ses problèmes de sécurité, les premiers filtres IP ont permis de limiter les accès en imposant des règles basées sur la nature individuelle des paquets, port et IP source ou destination. Chaque paquet routé était soumis à l’ensemble du jeu de règles pour savoir s’il devait être autorisé à passer. C’est, par exemple, le modèle de fonctionnement d’ipchains, la couche de pare-feu du noyau Linux 2.2. Un échange entre un client et un serveur comprend le plus souvent des paquets aller et des paquets retour. Il faut donc, avec ce type de filtre, autoriser les paquets dans les deux sens en écrivant une règle pour l’aller et une règle pour le retour. Cela induit une complexité importante au niveau de la génération des règles, puisqu’il faut 2 N règles pour N flux. De plus, en termes de sécurité, ce système est peu acceptable, puisque l’on n’est pas assuré du sens de l’initialisation de la session (du client vers le serveur). En effet, avec ce type de système, elle est possible du serveur vers le client alors que l’on cherche à n’avoir que l’inverse. L’introduction de la notion de connexion a résolu cette problématique. Depuis la fin des années 90, la notion de connexion a été implémentée dans les filtres IP. Dans un échange entre un client et un serveur, une connexion contient la direction de l’initialisation de l’échange et l’ensemble des paquets émis dans les deux sens. Le pare-feu se " souvient " des paquets d’ouverture de connexion qu’il a autorisés, et laisse passer le flot de la connexion sans que des règles spécifiques soient nécessaires à cet usage. Ce principe, beaucoup plus sécurisé, apporte une plus grande complexité interne du côté du pare-feu : celui-ci doit maintenir en mémoire une table de suivi des connexions. C’est ce que Netfilter [Netfilter], le pare-feu des systèmes Linux 2.4 et 2.6, appelle le Conntrack (connection tracking). Nous verrons dans l’article du prochain numéro les évolutions récentes du Conntrack et la manière dont on peut le manipuler très finement, depuis les toutes dernières versions de la branche 2.6 du noyau.

    NuFW : théorie et algorithmes

    Principes

    La conception et le développement de NuFW sont partis d’un constat simple : les filtres IP n’appliquent qu’une approximation grossière des politiques de sécurité. En effet, la politique de sécurité définit les droits d’accès d’utilisateurs à des ressources. Par opposition et dans la pratique, un pare-feu classique manipule des objets purement réseau, qu’il est difficile de lier à la notion d’utilisateur. En particulier, l’approximation " adresse IP = utilisateur ", admise (jusqu’ici) par tous les pare-feu " authentifiants ", laisse à désirer sur plusieurs plans :
    • Plusieurs utilisateurs peuvent travailler simultanément sur une machine du réseau et chacun d’eux générer du trafic (une adresse IP = N utilisateurs).
    • À l’inverse, il est concevable qu’un seul utilisateur utilise plusieurs machines à un instant donné (N adresses IP = un utilisateur).
    • L’adresse IP est un paramètre purement technique, pas un paramètre d’authentification ou d’identification. Conceptuellement, il paraît donc absurde de l’utiliser au niveau du filtre pour gérer des droits d’accès.
    • Un utilisateur peut très facilement masquer volontairement tout un réseau de machines derrière un ordinateur faisant office de routeur et utilisant la traduction d’adresse (NAT). Le filtre voit alors tous les flux comme étant émis par la même adresse IP et ne peut donc distinguer les différentes machines. Il y a dans ce cas intention de nuire, mais ce type de problème se présente aussi lorsqu’un utilisateur s’authentifie depuis un réseau NATé. Involontairement cette fois-ci, l’ensemble du réseau acquiert l’identité de l’utilisateur.
    • Il est extrêmement aisé de " voler " l’adresse IP d’une autre machine, par diverses méthodes.
    Des tentatives pour corriger ces problèmes (comme 802.1x) permettent de résoudre l’un ou l’autre de ces points, mais jamais tous. Par exemple, 802.1X n’apporte aucune réponse au fait que tous les systèmes d’exploitation un peu récents (voire anciens...) soient multi-utilisateurs. Par ailleurs, tous les pare-feu " vendus " aujourd’hui comme authentifiants réalisent l’approximation IP=utilisateur à un moment ou à un autre. NuFW est vraiment le premier pare-feu à apporter une authentification stricte des flux, pour chaque connexion qui le traverse. Méfiez-vous des approximations !

    NuFW : Now User Filtering Works !

    Le but du projet NuFW est de compléter le fonctionnement du filtre IP, et de proposer une authentification (et bien sûr une décision fondée sur cette authentification) individuelle pour chacune des connexions qui le traversent. NuFW est en fait le point de rencontre entre deux cœurs du système d’information : d’une part, le pare-feu, cœur historique du réseau et, d’autre part, le service d’annuaire, centre de la gestion des utilisateurs. Fondamentalement, le but de NuFW est de faire collaborer ces deux entités : si le pare-feu " voit " les utilisateurs d’une manière stricte, il peut filtrer leur trafic selon leur identité et leurs droits, le journaliser... Point n’est besoin de réinventer la poudre ; aussi le projet NuFW utilise-t-il Netfilter, la couche de filtrage du noyau Linux, et s’interface sur tous les services d’annuaires existants. Bien entendu, NuFW est un projet publié sous licence GPL, ce qui apporte une preuve (s’il en fallait une de plus) que le modèle de développement du Logiciel libre est parfaitement adapté à l’innovation pointue : NuFW est le premier pare-feu à présenter un mécanisme d’authentification strict. NuFW est d’ailleurs l’heureux vainqueur des Trophées du Libre [TrophéesDuLibre] 2005 dans la catégorie " Sécurité ". NuFW apporte cependant une contrainte : la présence d’une partie cliente qui tourne sur le poste de l’utilisateur. Nous allons toutefois voir que cette contrainte est contre-balancée par un " effet de bord " très positif : l’émergence d’un système d’Authentification Unique (SSO : Single Sign On) multi-protocole, élégant, simple et surtout sécurisé. Pour commencer, présentons l’algorithme de fonctionnement de NuFW pour éclaircir comment tout ceci interagit.

    Algorithme de NuFW

    Le principe de fonctionnement est simple : Lorsqu’une connexion doit être authentifiée, le pare-feu Netfilter délègue la décision à NuFW et celui-ci demande aux utilisateurs d’indiquer le trafic qu’ils ont généré. NuFW établit alors les concordances entre les différentes sources d’informations et transmet la décision requise à Netfilter.

    /img-articles/lm/84/art-4/fig-2.jpg

    Détaillons maintenant l’algorithme tel que décrit dans la figure suivante.
    • 1. Au démarrage de sa session de travail, l’utilisateur lance un client sur son poste de travail. Le client ouvre un tunnel crypté par TLS vers le serveur nuauth qui réalise l’authentification de l’utilisateur pour ce tunnel au regard d’un annuaire référent. Ce tunnel est ensuite conservé pendant toute la durée des opérations et l’ensemble des échanges entre nuauth et le client se fait ensuite par son intermédiaire.
    • 2. Supposons maintenant que l’utilisateur ouvre une connexion vers un serveur, par exemple une connexion web à destination du serveur d’application. Il utilise alors son navigateur favori qui envoie un paquet à destination du serveur. Le paquet envoyé est un paquet TCP standard avec notamment comme caractéristiques port destination 80 (web) et bit SYN positionné (ouverture de connexion).
    • 3. Le pare-feu (Netfilter) envoie ce paquet au démon nufw (au moyen de la décision QUEUE ou NFQUEUE) : contrairement à un pare-feu " classique ", Netfilter ne prend pas de décision à propos de cette connexion.
    • 4. Le démon nufw se contente de relayer le paquet reçu vers le serveur d’authentification, qui a autorité sur les décisions.
    • 5. Le démon nuauth analyse le paquet reçu (et en particulier l’adresse IP source) et envoie une demande de mise à jour à tous les clients connectés (par l’étape 1) depuis cette adresse pour qu’ils authentifient les connexions en attente. Cette demande est envoyée au travers du (ou des) canal (canaux) crypté(s) ouvert(s) à l’étape 1.
    • 6. Le client qui a ouvert notre connexion " témoin " stipule à nuauth qu’il l’a fait, en précisant tous les paramètres IP (IP et port destination, port source, etc.). À ce stade, le serveur nuauth connaît, de manière sûre, l’identité de l’utilisateur à la source de notre connexion.
    • 7. nuauth réalise une requête sur la base des ACL, pour vérifier si l’utilisateur dispose des droits pour établir cette connexion. nuauth obtient ainsi une décision.
    • 8. (En option) nuauth journalise toutes les informations relatives à cette connexion dans une base SQL, avec bien sûr l’identité de l’utilisateur.
    • 9. nuauth envoie la décision obtenue en 7 à nufw, qui la relaie à son tour à Netfilter. La décision associée à notre utilisateur est alors appliquée par Netfilter.
    • 10. S’il est autorisé, le paquet poursuit sa route.
    • 11. (En option) Si le serveur (Apache, par exemple) désire connaître l’identité de l’utilisateur, au lieu de la lui demander directement, il peut réaliser une simple requête SQL SELECT pour récupérer l’identifiant de l’utilisateur en partant de marqueurs uniques de la connexion (la socket source, pour les connaisseurs). L’utilisateur est ainsi authentifié de manière transparente, et sans pouvoir tricher, sur le serveur : il s’agit d’une solution de Single Sign On (authentification unique) très simple, très sûre, et indépendante du protocole.
    • 12. Le reste du flux est géré par le suivi de connexion (Stateful inspection) de Netfilter : les paquets ne repassent pas par les démons nufw/nuauth. Pour plus d’informations au sujet de l’algorithme, vous pouvez vous référer aux articles issus du projet EFICAAS [EFICAAS].

      Quelques mots sur les performances

      Le principe de fonctionnement de NuFW peut paraître " lourd " par rapport à celui d’un pare-feu " classique ". Plusieurs aspects sont à noter :
    • NuFW s’appuie sur les capacités " Stateful Inspection " du suivi de connexion de Netfilter (le fameux conntrack) : seul le paquet d’ouverture de connexion fait l’objet de la procédure décrite par l’algorithme. Tout le reste du flux d’une connexion est géré par Netfilter, exactement comme le fait un pare-feu " pur " Netfilter. Les flux réseau standard (en vert sur le graphe) ne sont donc pris en charge par NuFW qu’à l’initialisation de la connexion.
    • L’une des phases les plus longues est la requête (Étape 7 sur notre schéma) dans la base d’ACL – typiquement une base LDAP. Depuis la branche 0.9, le serveur d’authentification, nuauth, dispose d’un système de cache interne pour alléger ces flux.
    • Seuls les flux dessinés en noir sur notre schéma sont exécutés au passage d’une nouvelle connexion. Les flux dessinés en bleu sont réalisés soit une seule fois (étape 1), soit périodiquement (étape 7) grâce au système de cache. De plus, les étapes 8 et 11 sont optionnelles.
    Nous avons procédé à des benchs sur différents systèmes. Des tests ont notamment été faits sur un système en production avec la totalité des fonctions activées (journalisation MySQL complète notamment). Ce système est constitué d’un pare-feu et d’un serveur d’authentification. Pour 1000 connexions successives, la moyenne de temps de connexion a été de 15,2 ms. C’est beaucoup plus élevé que le temps de connexion moyen sur un système standard qui est de l’ordre de 1 ms, mais il est important de noter qu’en valeur absolue cette différence de performance est imperceptible pour l’être humain. Ces tests ont été faits sur un LAN ; des ouvertures de connexion sur Internet (même sans NuFW) prennent typiquement des durées d’échelle supérieure à ce facteur. Il n’y a donc pas d’impact en termes de qualité de service du point du vue de l’utilisateur. L’important est que ce délai n’augmente pas quand le pare-feu est chargé et c’est bien ce que nos benchs ont montré. En pratique, le système tourne en production sur des réseaux de plusieurs centaines d’utilisateurs, sans que ceux-ci ne perçoivent de ralentissement.

    Compilation et installation

    Choix de la version NuFW

    NuFW : Not a Usermode FireWall ! Le projet NuFW comporte deux démons, nufw et nuauth. Si nufw est minimaliste, nuauth est plus complexe et son comportement est paramétrable en utilisant des modules externes qui permettent de gérer toutes les interactions avec l’extérieur :
    • authentification ;
    • journalisation ;
    Pour commencer, il convient de choisir la version de NuFW. À l’heure de l’écriture de cet article, deux branches de NuFW coexistent :
    • Branche 1.0 : branche stable et éprouvée, supporte l’authentification de tous les flux TCP ; s’interface avec tous types d’annuaires grâce à PAM.
    • Branche 2.0 : nouvelle branche stable, récemment en développement, avec comme nouveautés :
    • Support de tous les protocoles IP existants (et notamment UDP, ICMP).
    • Support du signal de reload HUP (ça n’a l’air de rien, mais c’est une vraie plaie à gérer !).
    • Support du chargement simultané de plusieurs modules pour une même tâche : par exemple si l’authentification d’un utilisateur échoue sur un annuaire, on peut se rabattre sur un autre ou utiliser une base locale... Le but est de gérer des pare-feu complexes au cœur de plusieurs annuaires administrativement distincts.
    • Support des règles de filtrage selon l’heure ; le pare-feu autorise des connexions en journée, mais pas la nuit ; mieux, il va couper les connexions existantes à l’heure dite.
    Interfaçage beaucoup plus fin avec le noyau, grâce aux développements très récents (où à venir bientôt) de la branche 2.6 de Linux.
    • Attention : à partir de 2.0, le protocole d’échange entre client (nutcpc) et serveur (nuauth) a été modifié. Les clients NuFW 1.0 ne sont pas compatibles avec la version 2.0. Il faut donc prêter attention à la version du client installé.
    En pratique, la branche 2.0 fonctionne plutôt bien, même si elle n’est pas encore officiellement stabilisée (elle le sera en fait sans doute à l’heure de mise sous presse de cet article). Commençons donc par récupérer l’archive 2.0. Si vous le désirez, vous pouvez bien sûr utiliser la branche 1.0 : la plupart des instructions de cet article sont " portables ". À noter que la suite NuFW est, à cette heure, packagée dans les distributions Debian (sid, etch), Mandriva (Cooker) et Ubuntu (Breezy/universe). Nous laissons les fans de ces distributions adapter nos directives s’ils préfèrent utiliser les paquetages.

    Compilation

    Ici, nous souhaitons que nuauth supporte la journalisation en base MySQL et nous compilons NuFW avec les messages de debug pour nous aider en cas de problème de configuration en root : Nous laissons au lecteur le soin d’examiner les autres options de ./configure pour une installation plus fine. Et notamment pour s’interfacer avec les dernières fonctionnalités Netfilter apparues avec le noyau 2.6.14 (cf. prochain article). Ceci réalise l’installation des démons nufw et nuauth, ainsi que du client nutcpc pour Linux. Tout est installé par défaut dans /usr/local.

    Configuration et démarrage des démons

    Le répertoire conf/ contient un exemple de fichier de configuration de nuauth, nuauth.conf que l’on copiera dans le répertoire /etc/nufw/. Les serveurs nufw et nuauth utilisant gnutls pour leurs échanges, il est nécessaire de leur fournir des certificats. Le répertoire conf/certs contient des exemples de certificats que l’on peut copier dans le répertoire /etc/nufw/ : Allons maintenant vérifier quelques options importantes de notre configuration nuauth, dans /etc/nufw/nuauth.conf : nuauth considère que la base des utilisateurs est locale, dans un fichier plat. Ceci est idéal pour réaliser des tests ;) Bien sûr, sur un réseau d’entreprise, on interface plutôt nuauth à l’annuaire (LDAP, Active Directory, Radius, etc.) nuauth va chercher les droits de chaque utilisateur dans un fichier texte également et ses paramètres frères : mysql*, à positionner bien sûr selon la configuration du serveur MySQL utilisé. Si vous ne souhaitez pas de journalisation MySQL, vous pouvez conserver " syslog ". Notes Les heureux testeurs de la 2.0 peuvent utiliser mysql et syslog simultanément en spécifiant " syslog mysql " Pour journaliser en MySQL, il faut avoir une base contenant la bonne structure. On peut obtenir une base utilisable en utilisant le fichier nulog.mysql.dump du répertoire conf et les commandes suivantes : Il ne reste ensuite plus qu’à paramétrer les permissions d’accès à la base. Insérons nos règles Netfilter de test. À titre d’exemple, nous allons authentifier les flux sortants de la machine et à destination du site web test.nufw.org. Attention, le module noyau (netfilter) ip_queue doit être compilé et chargé. Faites : s’il n’est pas compilé en dur dans votre noyau (la plupart des distributions le fournissent en module, donc ceci devrait fonctionner sur les installations par défaut). Démarrons le démon nufw : (pour voir la portée des options, voir nufw –help ou bien man nufw) Comme nous avons installé nufw et nuauth dans /usr/local, il faut créer le répertoire /usr/local/var/run/nuauth avant de lancer nuauth : Démarrons maintenant nuauth : doit à présent montrer les deux processus qui tournent (sur un noyau 2.4, vous en verrez un plus grand nombre : ces processus sont multithreads). Positionnons nos règles de filtrage d’exemple au niveau de Netfilter, pour envoyer au démon nufw les paquets destinés au port 80 du serveur test.nufw.org. La première règle met en queue les paquets TCP vers le port 80 de test.nufw.org si le bit SYN est positionné (--syn). C’est donc une initialisation de connexion TCP. À ce test s’ajoute l’utilisation du module state (-m state) grâce auquel on vérifie que le paquet ne correspond pas à une connexion établie (--state NEW). La deuxième règle autorise, quant à elle, en sortie toutes les connexions établies ou relatives à une connexion établie. À présent, créons notre fichier texte de définition des utilisateurs /etc/nufw/users.nufw avec le contenu suivant. Le fichier par défaut définit donc trois utilisateurs : user, admin et suadmin. Le deuxième champ (après le " : ") est le mot de passe. Le troisième champ est un identifiant propre à chaque utilisateur. Enfin, le dernier champ définit la liste des groupes (numériques) auxquels l’utilisateur appartient. Ici, donc, l’utilisateur user a comme mot de passe user, comme identifiant 1 et appartient au groupe 102. Personnalisez ce fichier si vous le souhaitez, mais souvenez-vous de faire correspondre les identifiants de groupe à ceux du fichier d’ACL. Bien évidemment, ces utilisateurs sont totalement indépendants des utilisateurs systèmes existants sur le pare-feu (voir /etc/passwd). Notre base d’utilisateur est ici parfaitement spécifique à NuFW. Voyons à présent ces fameuses ACL. Nous allons créer le fichier /etc/nufw/acls.nufw avec le contenu suivant : Nous autorisons donc les membres du groupe 102 à surfer sur notre site test.nufw.org. Dans notre exemple, il s’agit des utilisateurs user et admin. Rechargeons la configuration du serveur nuauth (2.0) – Pour 1.0, il faut le redémarrer complètement : à présent, lançons le client : Très important : l’adresse IP passée au moyen du switch -H est celle du serveur nuauth. A priori, vous ne devriez jamais utiliser 127.0.0.1, mais plutôt l’adresse IP externe de votre machine (en tous cas, celle que les paquets à destination de l’extérieur de votre machine se voient attribuer). Dans le cas contraire, nuauth ne fera pas le lien entre les paquets à authentifier, ayant comme adresse source votre IP d’interface réseau et l’interface locale 127.0.0.1. Si tout se passe bien, un mot de passe vous est demandé (si ce n’est pas le cas, c’est que nuauth ne tourne pas ou a un problème de configuration). Il est par ailleurs possible que vous ayez à installer le paquet libsasl2-modules (sous Debian) ou équivalent, pour que nutcpc fonctionne : nutcpc s’appuie sur le module SASL plain. Nutcpc, une fois le tunnel initialisé, passe en tâche de fond et est prêt à authentifier les paquets si nuauth lui demande. Notes Le client nutcpc authentifie les paquets pour l’utilisateur qui l’a lancé. Si vous changez de compte sur la machine, il vous faut relancer nutcpc sur l’autre compte. Seuls les paquets émis par le propriétaire du processus nutcpc sont authentifiés auprès de nuauth. Test de surf sur test.nufw.org : La connexion s’ouvre, notre authentification fonctionne. Pour en voir un peu plus, on peut arrêter les démons nufw et nuauth et les relancer attachés à leur console, avec une grande verbosité : Ou mieux, changer la verbosité des démons au moyen des signaux SIGUSR1 et SIGUSR2 (voir les pages man de nufw et nuauth). Et regardez ce que les démons ont à dire en cas de connexion d’un client nutcpc (réussie ou non), ainsi qu’au passage de chaque paquet authentifié.

    Extensions et suites

    Normalement, à ce stade, le filtrage IP authentifié fonctionne sur votre machine. Bien évidemment, le système NuFW est conçu pour fonctionner sur un réseau et, dans une configuration typique, les clients tournent sur d’autres machines que les démons nufw et nuauth. Si vous avez besoin de plus d’informations, pour se connecter à un annuaire particulier ou détailler les points vus ici, nous vous invitons à vous reporter au howto en ligne, actualisé en permanence. Vous pouvez également vous connecter au canal IRC #nufw-fr (sur les serveurs irc.Freenode.net), où nous tâchons de répondre aux questions relatives au fonctionnement de NuFW. Il ne vous reste plus qu’à découvrir les options de journalisation dans une base MySQL et d’aller y naviguer avec l’outil web NuLog [Nulog]. Ou encore les possibilités de SSO. Vous allez découvrir assez vite qu’à moins d’être puriste de la ligne de commande, la génération de règles Netfilter à la main est fastidieuse, surtout lorsqu’il s’agit de mixer des connexions authentifiées et non authentifiées. Il est également nécessaire de synchroniser la base d’ACL avec le jeu de règles authentifiantes... Pour cela, nous avons conçu l’outil NuFace [Nuface], interface plus intuitive, et de haut niveau, pour la gestion des règles de filtrage de A à Z. NuFace peut d’ailleurs être utilisé pour un pare-feu Netfilter " simple ", c’est-à-dire sans authentification. Notes INL propose sur son site [EdenWall] plusieurs autres outils, sous licence GPL, pour faciliter l’administration d’un pare-feu NuFW. Rendez-vous dans le prochain numéro pour une présentation des fonctionnalités avancées de Netfilter et des interactions avec le noyau que cela permet à NuFW. Références

    Retrouvez cet article dans : Linux Magazine 84

    Vous souhaitez commenter cet article ?
    Brèves Flux RSS
    Édito : GNU/Linux Magazine Hors-Série N°72
    Édito : Linux Pratique N°84
    Édito : MISC N°74
    Édito : GNU/Linux Magazine N°173
    Édito : MISC Hors-Série N°9
    Communication RSS Com. RSS Presse
    HACKITO ERGO SUM
    GNU/Linux Magazine, partenaire du SymfonyLive Paris
    Opensilicium, partenaire de RTS EMBEDDED
    Linux Pratique et Linux Essentiel, Partenaire de l’Open World Forum
    Gnu/Linux Magazine, Partenaire des JDEV 2013
    Rechercher un article dans notre base documentaire :
    Désolé, aucun article ne correspond à vos critères.