En quoi NuFW est-il différent d’un proxy transparent ?
Un proxy transparent n’est capable de traiter que les protocoles qu’il connait. Avec NuFW, n’importe quel protocole peut être authentifié (à condition toutefois que Netfilter ait un module de suivi de connexion qui le traite).
Cependant, avec NuFW (et à l’inverse d’un proxy) les connexions se font directement depuis le client vers les serveurs. Il est cependant possible d’utiliser NuFW avec un proxy pour certains protocoles afin d’augmenter encore la sécurité des échanges dans ces cas précis.
Quelles sont les différences entre NuFW et Checkpoint FW/1 ou Netscreen ?
Avec Chekpoint FW/1 et Netscreen, un utilisateur s’authentifie par HTTPS et les autorisations sont basées sur l’adresse IP de la machine qui a initié la connexion. C’est une authentification a priori, ce qui n’est pas vraiment sûr. De plus ces deux systèmes ne sont pas capables de différencier des utilisateurs connectés sur le même serveur (Terminal Server, Citrix, ...) ou un réseau entier caché derrière de la traduction d’adresse. Par conséquent, les permissions d’un utilisateur sur une machine multi-utilisateurs sont la somme des permissions individuelles de toutes les personnes connectées à ce serveur. NuFW identifie et authentifie l’utilisateur à l’origine de chaque connexion et ce, sans utiliser d’algorithme a priori, ou tout autre supposition.
Avec NuFW, il est possible d’avoir plusieurs utilisateurs utilisant les même systèmes sans interférence, et vous n’êtes pas trompé par le NAT. NuFW offre donc une authentification des utilisateurs bien meilleure.
Oh, nous avions persque oublié : NuFW est un logiciel libre.
Quelles différences entre NuFW et authpf ?
Avec authpf, un utilisateur s’authentifie lorsqu’il se connecte à la passerelle grâce à ssh et les règles sont ajoutées à ce moment précis. Il y a donc 2 points :
Avec NuFW :
Quelles différences entre NuFW et un Réseau Privé Virtuel ?
Un RPV est souvent utilisé pour authentifier les utilisateurs (par exemple dans un réseau local). L’authentification est souvent faite grâce à un certificat SSL et un RPV a l’avantage de chiffrer les données qui transitent sur le réseau. Mais un RPV a, par rapport à NuFW, les désavantages suivants :
L’authentification RPV ne fonctionne pas bien dans le cas des systèmes multi-utilisateurs.
Le chiffrement n’est pas forcément nécessaire dans un environnement sécurisé et il engendre une charge de calculs difficilement gérable dans le cadre d’un LAN de taille conséquente (chiffrement de flux Gigabit entre des serveurs de fichiers et des utilisateurs)
Le RPV ne garantit pas l’identité des utilisateurs puisque l’ordinateur d’un utilisateur peut agir comme routeur.
L’infrastructure nécessaire à la mise en place d’un RPV est beaucoup plus complexe que celle nécessaire à la mise en place de NuFW. Notamment en ce qui concerne les postes clients.
D’un autre coté, le RPV a des avantages sur NuFW :
Il chiffre les fluxs garantissant ainsi une excellente confidentialité des données. De son côté, NuFW n’est pas conçu pour le chiffrement.
Cependant, dans un réseau privé virtuel d’enteprise, NuFW peut être utilisé pour réaliser l’authentification. Il est parfaitement sain et sensé d’utiliser NuFW au coeur d’un RPV, leurs fonctionnalités sont complémentaires.
Quel est le comportement de NuFW vis à vis de la traduction d’adresse ?
NuFW et la traduction d’adresse cible ?
NuFW ne peut gérer cette traduction si elle est faite en amont du parefeu car les données envoyées par le client logiciel ne correspondent pas à celle du paquet reçu par le parefeu.
NuFW et la traduction d’adresse source ?
NuFW supporte la traduction d’adresse source si celle-ci est faite en aval du parefeu ou par lui-même.
NuFW fonctionne-t-il sur les *BSDs ?
Nous avons étudié les couches de filtrages de OpenBSD et de FreeBSD (pf semblant être le choix recommandé)
D’après cette étude, il n’y a actuellement pas de mécanisme dans les sources officielles pour déporter la décision de filtrage dans l’espace utilisateur (équivalent de -j QUEUE sous Linux). Nous ne pensons donc pas qu’il soit possible de porter NuFW sur *BSDs à l’heure actuelle.
Cependant, nous pensons que nuauth, le démon d’authentification, devrait compiler et fonctionner sous *BSDs sans changement de fond. Nous sommes interessés par ce portage d’application. Merci de nous contacter si vous souhaitez travailler avec nous sur ce projet.
Quels sont les protocoles supportés ?
Pour l’instant, le système NuFW permet d’authentifier les protocoles TCP et UDP. Coté client, seul le client Windows supporte UDP pour l’instant. Tous les clients supportent TCP. Nous travaillons sur une architecture sous Linux/UNIX/Mac coté client permettant d’authentifier UDP. Par ailleurs, certains flux, notamment les flux de partages de fichiers (comme NFS ou Samba) sont émis par le noyau de la machine cliente, et ne peuvent donc pas être authentifiés formellement : c’est le noyau qui ouvre les connexions. Dans certains cas, la même connexion est même partagée par plusieurs utilisateurs d’un partage.
Des clients sont-ils disponible pour *BSD ?
La partie cliente (libnuclient et nutcpc) est disponible pour FreeBSD (et Mac OSX) et devrait également être fonctionnelle sous NetBSD. La principale différence se situant au niveau la bibliothèque client, l’ensemble des clients devrait fonctionner sur ces systèmes d’exploitations.
Un client 1.0 est-il compatible avec un serveur nuauth 2.0 (et vice-versa) ?
Non, le protocole a changé entre la version 1.0 et la version 2.0 et il n’y a pas de compatibilité dans les deux sens.
Où puis-je trouver une réponse à mes questions techniques sur NuFW ?
Une FAQ en anglais est disponible.
Où trouver l’ensemble des documentations sur NuFW ?
L’ensemble des documentations sur NuFW est accessible sur software.inl.fr.