Les améliorations par rapport à la précédente branche stable (1.0) sont donc nombreuses :
- Gestion de vraies règles d'accès horaires
- Plus d'interactivité avec l'utilisateur final (rejet ICMP par exemple)
- Module PAM pour une transparence complète sous GNU/Linux
- Utilisation des toutes dernières fonctionnalités de Netfilter
Les lecteurs de Linux Magazine pourront d'ailleurs trouver dans le numéro de Juin un article consacré à NuFW. Pour rappel, NuFW est un pare-feu authentifiant disponible sous GPL : il réalise l'authentification des connexions passant à travers le filtre IP. Des politiques de sécurité telles que : « Bill peut se connecter au serveur imap si il utilise Mozilla sous Linux 2.6.16 » peuvent être implémentées au moyen d'une règle d'accès NuFW unique.
Cette nouvelle mouture apporte son lot de nouveautés :
- Journalisation des session utilisateurs : on peut maintenant savoir quand et depuis où se sont connectés les utilisateurs
- Règles d'accès par rapport au temps : NuFW gère l'établissement des connexions suivant un période de temps, mais aussi leur destruction à la fin de la plage horaire
- Module de journalisation Prelude : l'ensemble des événements peut maintenant être centralisé dans l'IDS
- Module PAM pour une authentification transparente sous GNU/Linux
- Rechargement dynamique de la configuration : un signal SIGHUP permet de réinitialiser les démons et leurs modules
- Messages de rejet ICMP : l'utilisateur peut maintenant être prévenu du blocage des paquets
- Utilisation des dernières fonctionnalités de Netfilter : NuFW coopère avec libnetfilter_queue et libnetfilter_conntrack, ce qui a permis le développement de certaines des nouvelles fonctionnalités. Attention, un noyau >= 2.6.16.18 est recommandé. Il est souhaitable d'appliquer les patchs disponibles sur le site de NuFW pour un maximum d'efficacité. Ils seront contenus dans la version 2.6.18 du noyau.
Aller plus loin
- NuFW (145 clics)
- Quoi de neuf ? (9 clics)
- Linux Magazine France (20 clics)
- Précédente dépêche LinuxFr (3 clics)
- Téléchargement (56 clics)
# Mais comment ca marche ???
Posté par Erwann Robin (site web personnel) . Évalué à 6.
Bravo pour ce travail, j'espère qu'il sera accepté par les entreprises, les cibles les plus pertinentes de ce type de logiciel.
et il est développé par INL, encore un éditeur de logiciel français !
NB: est-ce qu'on peut envisager de l'utiliser sur une machine personnelle comme firewall applicatif ?
[^] # Re: Mais comment ca marche ???
Posté par _gryzor_ . Évalué à 10.
En tous cas, merci pour tes encouragements! Nous sommes très fiers chez INL de montrer que le libre est un vecteur d'innovation, grâce à ce projet.
Pour info, un client Mac a été développé (et est dispo sous GPL) depuis la rédaction de l'annonce que tu as collée dans ton commentaire ;)
[^] # Re: Mais comment ca marche ???
Posté par Id2ndR . Évalué à 2.
Pourrais-tu nous donner les extensions à utiliser pour faire du filtrage au niveau des applications avec netfilter sur une machine local ?
N'ayant encore jamais utilisé Netfilter (donc aucune extension non plus), j'aimerai bien des liens éventuels vers des tutoriaux de configuration existants.
[^] # Re: Mais comment ca marche ???
Posté par Victor STINNER (site web personnel) . Évalué à 5.
Hum, typiquement, on peut filtrer sur le port destination. Un navigateur utilise les ports 80 et 443 (https), 110 pour POP3, 6667 pour IRC, etc. Liste un peu plus longue par ici :
http://www.haypocalc.com/wiki/Liste_des_ports_TCP_et_UDP
Et la liste de l'IANA (c'est eux qui attribuent les numéros de port) :
http://www.iana.org/assignments/port-numbers
Mais la réalité est un peu plus floue : les applications peuvent utiliser un autre port (les clients P2P utilisent un peu tout et n'importe quoi), il existe des proxys, des tunnels, etc.
Pour reconnaître une application selon son traffic et non pas les ports, on peut utiliser une suite de motifs pour reconnaître une application. Euh ... j'ai pas trop d'exemple ... disons "GET HTTP/1.1" pour une requête HTTP par exemple. Il existe plusieurs projets pour Netfilter pour réaliser ça ... mais j'ai plus les noms en tête. Sous Linux, on peut remonter un paquet en espace utilisateur (avec la rêgle QUEUE) : il existe, par exemple, un programme en Perl (!) pour lancer des regex dessus.
Tout ceci est expliqué dans un article du magazine MISC dispo dans toutes les librairies.
Haypo
[^] # Re: Mais comment ca marche ???
Posté par Jean . Évalué à 3.
Le projet L7-filter permet cela: http://l7-filter.sourceforge.net/
[^] # Re: Mais comment ca marche ???
Posté par Erwann Robin (site web personnel) . Évalué à 3.
(le parefeu intégré de windows ou zone alarm demandent d'autoriser l'accès au net ou pas à chaque fois q'une nouvelle appli essaye de se connecter)
[^] # Re: Mais comment ca marche ???
Posté par Eric Leblond (site web personnel) . Évalué à 4.
connexion->socket->application->comparaison dans base->demande si pas dans base.
Pour voir si une appli est dans la base et n'a pas changé, c'est un md5sum sur le binaire.
Cette méthode ne vaut bien sûr que pour un pare-feu personnel (local)
[^] # Re: Mais comment ca marche ???
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
En local, je ne sais plus comment ça se fait en pratique, mais le noyau peut retrouver quel est l'executable à l'origine d'une connection assez facilement, donc no problem. Par contre, à distance, on a juste les paquets TCP et il faut faire avec, donc, c'est là qu'il faut rajouter une couche, et c'est là qu'il y a forcément un maillon de la chaine de confiance chez le client, qui dit « Ouais, j'ai vérifié, c'est bien un MSIE, laisses-le passer ».
Au passage, si c'était Microsoft qui avait fait ce genre de trucs, et qui l'avait appelé Palladium ou NGSCB, on aurait eu beaucoup moins d'éloge sur ce site ...
[^] # Re: Mais comment ca marche ???
Posté par tontonflingueur . Évalué à 7.
"Dormez, braves administrateurs, nous nous occupons de votre sécurité". Moi je trouve qu'un grand avantage du logiciel libre, c'est une certaine transparence. Rien qu'en regardant la page web du projet tu te fais une idée de ce qui marche, de ce qui ne marche pas (ou pas encore).
En plus maintenant, les vendeurs de logiciels propriétaires ne vendent même plus de softs, ils vendent des "solutions"... On ne comprend même plus ce que font les produits qu'ils vendent. Un exemple parmi d'autres : http://www.macrovision.com/. maximize the value of your content and software wouah ! TIens c'est nos amis justement :ils sont spécialisés dans le DRM. Ils affirment pouvoir sécuriser les DVD même vis-à-vis de deCSS, tout en continuant à fonctionner sur la majorité des lecteurs autorisés existants. Comment ? Mystère ?
[^] # Re: Mais comment ca marche ???
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
[^] # Re: Mais comment ca marche ???
Posté par naotemp . Évalué à 4.
En jettant un coup d oeil à l'algo tu verras que les coeur des fonctionnalités (authentification des connexions) est lui géré par le serveur d'authentification (déporté), lui même connecté via PAM à la base d'utilisateurs existante (en général LDAP ou AD). Un client corrompu ne pourrait s'authentifier si il n'est pas lancé avec des informations de compte valides, vérifiées par ce serveur d'authentification.
[^] # Re: Mais comment ca marche ???
Posté par tontonflingueur . Évalué à 2.
Finalement le problème c'est que sur une machine multi-utilisateurs, tu peux faire tourner un client pirate pour voler les connexions de tes petits camarades (seulement ceux qui sont actuellement connectés sur la même machine, ce qui n'est pas mal).
Je pense que pour éviter que sur une même machine des utilisateurs d'une application de single sign on ne se volent les sessions les uns les autres, il faut d'une certaine manière faire confiance aux clients. Regarde Kerberos par exemple, tu pourrais imaginer que le programme d'acquisition des tickets (kinit) es mal foutu, et qu'il va stocker tous les tickets dans /tmp avec les droits 777 . Dans ce cas les utilisateur peuvent se piquer leurs sessions les uns aux autres. Donc, quelque part le problème pour éviter le vol de sessions entre les utilisateurs d'une même machine cliente est le problème de l'administrateur de la machine cliente. Naturellement root peut voler tous les sessions de tout le monde avec su mais ça on ne peut pas y faire grand chose.
Alors voilà ce que je me disais : au lieu d'avoir autant de clients que d'utilisateurs connectés, ne serait-il pas possible d'avoir un seul client sur la machine, tournant sous le compte root, qui se chargerait de faire le chef d'orchestre, et de certifier que la connexion ouverte sur TCP sur le port 15722 a bien été ouvert par l'utilisateur fblanche (par exemple) ? Je ne sais pas si c'est possible, et en outre j'ai l'impression que ce client ne serait pas portable sur tous les systèmes, mais bon voilà pour mes suggestions à 2 francs 50.
@+
[^] # Re: Mais comment ca marche ???
Posté par Victor STINNER (site web personnel) . Évalué à 6.
Finalement le problème c'est que sur une machine multi-utilisateurs, tu peux faire tourner un client pirate pour voler les connexions de tes petits camarades
Hum ... tu veux dire que le client pirate répond "c'est moi qui ait ouvert la connexion" puis arrive à récupérer les paramètres de la socket (IP + TCP/UDP) ? Sous Linux, je vois mal comment récupérer les paramètres d'une socket TCP/IP, et donc la voler. De plus, ceci suppose que le pirate soit authentifié auprès de nuauth ... donc qu'il ait un compte ou volé un compte.
Je pense que pour éviter que sur une même machine des utilisateurs d'une application de single sign on ne se volent les sessions les uns les autres, il faut d'une certaine manière faire confiance aux clients. (...) Dans ce cas les utilisateur peuvent se piquer leurs sessions les uns aux autres.
Je pense que le seul risque est que le client donne des informations erronées sur le nom de l'application qui a ouvert la connexion. Par contre, une connexion est associée à un utilisateur (et non pas à une IP) de manière sûre. En effet, un tunnel TLS est monté lorsque le client s'authentifie.
Nufw authentifie chaque nouvelle connexion. Le SSO est réalisé du côté serveur et non d'une information venant du côté client. Contrairement à Kerberos, il n'y a aucun ticket sur le poste de travail.
Naturellement root (...)
Root a tous les droits oui. Installer un pare-feu c'est une chose, mais la sécurité ne doit pas se résumer à ça. Il faut former tout le monde pour éviter le social engineering :-)
Alors voilà ce que je me disais : au lieu d'avoir autant de clients que d'utilisateurs connectés, ne serait-il pas possible d'avoir un seul client sur la machine, tournant sous le compte root, qui se chargerait de faire le chef d'orchestre, (...)
Je ne vois pas en quoi ça serait un plus niveau sécurité. Ou alors je n'ai pas saisi la subtilité ?
--
J'ai peut-être répondu à côté de la plaque, mais le problème n'est pas simple et je ne suis pas sûr d'avoir compris ton commentaire :-)
Haypo
[^] # Re: Mais comment ca marche ???
Posté par tontonflingueur . Évalué à 4.
> suppose que le pirate soit authentifié auprès de nuauth ... donc qu'il
> ait un compte ou volé un compte
Oui je suppose que le "pirate" est un utilisateur légitime de nufw qui veut voler la connexion d'un autre utilisateur sur la même machine.
> Hum ... tu veux dire que le client pirate répond "c'est moi qui ait
> ouvert la connexion" puis arrive à récupérer les paramètres de la
> socket (IP + TCP/UDP) ? Sous Linux, je vois mal comment récupérer
> les paramètres d'une socket TCP/IP, et donc la voler.
C'est ça un "yes-client" en quel que sorte. Tu as raison, les paramètre de la socket vont rester attachés à l'utilisateur, donc
tout ce que va avoir gagné notre pirate, c'est que la connexion ouverte par l'utilisateur va récupérer les credentials du pirate, et je doute que ça lui soit très utile.
Honnêtement, c'est vraiment bien pensé ce truc ...
[^] # Re: Mais comment ca marche ???
Posté par _gryzor_ . Évalué à 3.
Idée séduisante sur le papier, mais qui demande une [trop?] grande confiance au poste client.
Nuauth n'a aucun moyen de savoir que ce client tourne en root, puisque tout se passe à distance.
C'est évidemment envisageable mais de mon point de vue c'est trop de confiance dans le client.
L'approche "forcer l'authentification de chaque utilisateur" est plus sécurisante à mon sens. C'est bien sûr discutable :)
[^] # Re: Mais comment ca marche ???
Posté par tontonflingueur . Évalué à 2.
> sécurisante à mon sens. C'est bien sûr discutable :)
Bien sûr. Moi, je parlais juste de la phase ultérieure où sur une machine multi-postes - donc avec plusieurs utilisateurs authentifiés sur Nuauth - il s'agit de repérer à quel utilisateur associer la nouvelle connexion.
> Idée séduisante sur le papier, mais qui demande une [trop?] grande
> confiance au poste client.
Et justement, c'est le client qui disait : c'est moi qui ai ouvert cette connexion. Donc, je trouvais que c'était un point faible mais Victor a levé une partie de mes doutes.
# Le client ...
Posté par salvaire . Évalué à 2.
Autre idée. Pourquoi ne pas attribué une ip par utilisateur?
[^] # Re: Le client ...
Posté par Victor STINNER (site web personnel) . Évalué à 10.
Hum, je vois mal comment faire pour ajouter ces informations sans aller triffouiller dans le noyau (kernel Windows / Linux). De plus, un pirate se fera un plaisir d'utiliser uid=0 par exempe :-)
Autre idée. Pourquoi ne pas attribué une ip par utilisateur?
Parce qu'une IP est "facilement" spoofable ? De plus on peut avoir plusieurs personnes qui ont la même IP, voir une personne mobile (avec un pc portable) qui change d'IP ...
Haypo
# Version 2.0.1
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
NuFW est vraiment un projet super qui doit êre, à mon avis, intégré au plus vite dans nos architectures. C'est vraiment formidable ce que l'on peut faire avec.
Juste une question, dans la 2.0.1, il est annoncé des corrections sur les paquets debian mais où sont-ils les fameux paquets ? Sur le site, on ne trouve que ceux de la version 1.0.25.
Bonne continuation.
[^] # Re: Version 2.0.1
Posté par _gryzor_ . Évalué à 8.
L'infrastructure de construction des paquets debian est cependant tenue à jour directement dans l'archive 2.0.1, et il est donc possible de générer des paquets debian facilement à partir des sources.
Nous acceptons les contributions pour améliorer cette structure et amener les paquets debian dans un état bien stable :)
Merci pour ces encouragements !
# client windows commercial
Posté par Dreammm . Évalué à 1.
Est-ce que l'ouverture des sources est prévue pour cette partie ?
[^] # Re: client windows commercial
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
[^] # Re: client windows commercial
Posté par naotemp . Évalué à 1.
[^] # Re: client windows commercial
Posté par Xavier Poinsard . Évalué à 4.
[^] # Re: client windows commercial
Posté par outs . Évalué à 1.
Je ------->[]
[^] # Re: client windows commercial
Posté par naotemp . Évalué à 10.
En plus, c'est un moyen supplémentaire faire passer les gens au 100% libre car on peut dire "Vous avez exactement les même fonctionnalités sous GNU/Linux que sous MS-Windows". A chacun d'assumer ses choix ... D'ailleurs si tout le monde faisait pareil il y aurait beaucoup plus de remises en questions en faveur du libre au niveau du poste de travail.
[^] # Re: client windows commercial
Posté par bbou . Évalué à -1.
[^] # Re: client windows commercial
Posté par _gryzor_ . Évalué à 3.
Nuauth parle PAM, donc il n'y a rien de caché. INL publie 100% de nufw/nuauth et des clients pour OS libres.
Le système est donc aussi librement interopérable avec Windows que Samba : seule la partie Windows est propriétaire, comme pour Samba ;)
Pour ce qui concerne les fausses informations client<->nuauth, le protocole est ouvert, et nous pensons qu'il est robuste (nous avons mis du temps pour le concevoir, en pensant aux problème possibles). Tu es libre, comme chacun l'est, de réaliser une évaluation indépendante !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.