Eric Leblond a écrit 245 commentaires

talweg est-il une sorte de proxy authentifiant http https permettant de s'assurer de l'indentité des personnes surfant depuis un réseau Wifi ?
--
Regit qui a du mal à voir quel champ couvre cette application

Sur le site de talweg, la page :
http://sourcesup.cru.fr/talweg/about.php
explique brièvement le fonctionnement, mais s'arrête à l'interception des paquets HTTP,HTTPS.

Je me demande donc quel est la suite du mécanisme, par exemple : comment se passe l'ouverture d'une session ssh (suis perdu sans ça ;-) une fois authentifié ...

NuFW est une surcouche de Netfilter, on choisit les flux à authentifier de manière très fine (utilisation de la cible QUEUE de Netfilter).
Malheureusement, il n'est pas possible de dire, et même dangereux, de dire : "si ce n'est pas un Linux alors on autorise", mais on peut très bien considéré que ce qui est autorisé authentifié pour les postes GNU/Linux peut être tout simplement refusé pour les postes windows.

Cependant, s'il est possible de séparer les machines Windows et les machines GNU/Linux sur le réseau (2 plages d'IP différentes par exemple), on peut établir des règles d'accès très restrictives sur les Windows (on a alors un firewall netfilter standard) et de l'autre côté, utiliser l'authentification sur les postes clients GNU/Linux pour donner un peu plus de liberté aux utilisateurs de systèmes libres.

Non, ma phrase est correcte :
NuFW n'authentitifie que les initialisations de connexions. L'ensemble des paquets datas (après le paquet SYN par exemple pour TCP) sont pris en charge comme n'importe quel paquet directement par Netfilter. NuFW n'a donc aucun impact sur la bande passante.
Son seul impact est à l'initialisation des connexions authentifiées où l'ensemble du processus d'authentification a lieu.

> Pas forcément, il suffit d'utiliser un encapsuleur socks.
et donc de paramétrer toutes les applications des utilisateurs pour utiliser cette encapsuleur ?

Les désavantages de socks sont de plus nombreux, puisque l'on a en fait un proxy applicatif. Il peut donc difficilement traiter efficacement des flux gigabits entre par exemple des serveurs et la zone utilisateurs. NuFW quant à lui n'a aucun impact sur la bande passante d'un firewall car l'ensemble des paquets de datas sont directement pris en charge par netfilter. Je ne parlerais pas non plus de la problématique de masquage des IP sources avec socks (proxy oblige) qui complique sérieusement la gestion des logs et permissions sur les serveurs.

On peut aussi parler des avantages de NuFW en terme de :
- authentification unique
- qualité de service et routage par utilisateur

C'est en partie vrai, mais ce n'est pas l'application qui communique les informations au serveur d'authentificaton de NuFW, mais le client logiciel qui utilise les ressources systèmes pour déterminer quelle est l'application à l'origine d'un flux.

La compromission pourrait venir donc d'un client qui n'utilise pas les informations systèmes et non de l'application. Par conséquent (comme je l'ai déjà écrit) sur un système sécurisé où les binaires sont controlés il est difficile de prendre le système en défaut.

Excellente analyse. On est sûr de de l'identité de l'utilisateur mais on lui fait confiance en ce qui concerne l'application. De plus, si il y a mensonge on peut savoir de quel utilisateur cela provient (par un recoupement entre les logs nufw en SQL et les logs des services par exemple)

Je tiens tout de même à signaler que cette fonctionnalité va dans le sens d'un renforcement de la sécurité :
Le flux est nécessairement ouvert sur n'importe quel type de parefeu. Ici, on est capable de restreindre ce flux suivant un critère, cela renforce donc la sécurité.

De plus, sur des machines sécurisées où l'on fait tourner en tant que service le client d'authentification, les informations concernant l'application peuvent être considéré comme étant fiable. L'utilisateur n'ayant pas le droit de lancer ses propres logiciels. (sous Linux on peut aussi utiliser des fonctionnalités de grsecurity comme la restriction à l'exécution de programmes détenus par root)

On a en plus comme dit la news :
- Le support de l'authentification sur les postes multi-utilisateurs
Par exemple pour un serveur X, un serveur citrix, nufw sait gérer les permissions des utilisateurs séparément. Aucune des solutions citées ne permet de le faire puisqu'elles supposent toutes :
"Utilisateur==IP"
NuFW quant à lui fait une association au niveau des connexions et ce a posteriori. L'authentification réalisée est donc stricte et elle supporte les machines multiutilisateurs.

Il s'agit d'une offensive du conseil de l'union européenne et pas du conseil de l'europe : http://www.coe.int.(...)

Plus de détails sur :
http://europa.eu.int/european_council/index_fr.htm(...)

>Dans les deux cas :
> =========>si c'est pour les serveurs, pourquoi pas openbsd?

securisé n'exclut pas forcément performance. Un serveur multiprocesseur a lui aussi droit à la sécurité.

Désolé, difficille de résister.

Si j'ai bien compris, la CPS permet une authentication des professionnels du monde de la santé. Cette authentication doit donc être utilisable pour s'interfacer avec NuFW (et ainsi controler les flux réseaux au sein d'un hopital par exemple), mais tout le travail reste à faire :
- récupération des certificats de la carte sur le poste client
- vérification du certificat sur le serveur NuFW

Le travail est conséquent mais il ne me semble pas insurmontable.

La différence avec authpf (partie de PF "ressemblant" à NuFW) est décrite dans la FAQ.

Pour faire bref et en français :
authpf fait IP=USER. Donc il n'est résistant ni au NAT ni aux machines multiutilisateurs. Et donc ,dans ces deux cas, les permissions de chaque utilisateur sont égale à la somme des permissions des utilisateurs telles que vu par le système de filtrage.

NuFW ne fait pas cette association et authentifie individuellement les connexions. Il n'y a aucune approximation.

Ce n'est pas le cas de authpf qui repose sur la connexion SSH. Donc, si on déconnecte brutalement le client SSH, le serveur ne peut détecter immédiatement la déconnexion. Il y a donc un laps de temps pendant lequel les permissions associées à l'IP restent présentes et il est donc possible de se subsituer à la machine ayant acquises les permissions tout en conservant ces mêmes permissions. Ce n'est pas le cas avec NuFW qui authentifie chaque connexion de manière fiable.

Il y a surtout eu une fausse captive blanche qui a reçu tous les honneurs et une vraie captive noire qui a été virée par l'armée.

Non voir : http://www.nufw.org/principles.html(...)
Grosso modo :
- le firewall met en queue les requetes
- nufw envoie les requetes à nuauth
- nuauth check dans le ldap et dit au firewall si le paquet peut passer ou non

Merci mais la diversité n'a jamais nuit au logiciel libre.
de plus le longtemps date d'un peu plus d'un an si ma mémoire est bonne.
> Le système de fitrage PF d'OpenBSD adapte alors les règles de filtrage dynamiquement
- Est-il capable de gérer la modification des règles alors que l'utilisateur est déjà loggué ? Non, d'après la FAQ.
- Comment traite-t-il le cas de plusieurs personnes venant de la même IP (NAT, serveur de terminal) ? Avec NuFW, chaque utilisateur authentifie CES paquets et on peut donc avoir plusieurs utilisateurs avec des permissions différentes sur la même machine, ce n'est pas le cas de AuthPF !

Sachant qu'il a accès au mot de passe tapé (ou qu'aurait du taper l'utilisateur) il génère la chaine de charactère résultant de la concaténation des champs cités puis crypte avec la fonction crypt la chaine obtenue en utilisant le "salt" du crypt MD5 fournit par l'utilisateur.
La chaine sortant alors de crypt doit être la même que le crypt MD5 fournit par l'utilisateur.

Lorsqu'un utilisateur ouvre une connection ssh sur le firewall, un ensemble de règle est jouée, ce qui permet de faire à peu près comme NuFW.
Quelques différences :
- il faut créer un compte sur le FW ce qui est contraignant et mobilise des ressources sur le firewall.
- l'ensemble de règles (pour ce que j'en sais) ne peut être géré dynamiquement.

Oui, en mieux ;-) puisque les règles peuvent être gérées par un serveur LDAP, on est donc dans qqc de plus dynamique.

Qui dit proxy, dit qu'au final c'est un serveur qui fait les requêtes sur la cible final. Si le proxy fait les requêtes, c'est qu'il connait le protocole et que le protocole s'y prete.

Ici, on n'est capable d'autoriser n'importe quel protocole (ayant un suivi de connection par netfilter) en filtrant par utilisateur.

les différences sont donc :
- pas de relayage mais une transmission directe.
- pas de connaissance nécessaire du protocole et donc adaptation possible à tous les protocoles.

> dans ce cas, comment fais tu pour savoir quel est l'utilisateur qui a initié la connexion ?
/proc/net/tcp indique qui a ouvert la socket
>de plus le deamon tourne en root ou sous une session de l'utilisateur concerné ?
Le démon est lancé par l'utilisateur et tourne sous son ID.

plusieurs choix : libpcap
utilisée pour tcpdump : on peux dumper les paquets SYN tcp, les paquets UDP, ....

ou ce qui est fait maintenant (provisoire pour tcp):
regarder /proc/net/tcp et si une nouvelle connexion est en SYN_SENT c'est qu'elle est "en attente" (de modération ;-) et on envoie un paquet

>le client s'authentifie à chaque fois pour chaque paquet
Pas tout à fait en utilisant le suivi de connexion de Netfilter, on authentifie uniquement les paquets initialisant les connexions. Ceci réduit considérablement la charge de traitement?.
> faire ça avec un système de tunnels
Avce beaucoup moins de flexibilité puisque l'on peut ici :
- filtrer UDP (voir meme icmp) par utilisateur
- gérer dynamiquement les règles (retour d'un IDS qui modifie le LDAP par exemple)
- pas de modification de la conf du client qui se contente betement d'authentifier tous les paquets d'initialisation de session.

Benssoussan est là pour défendre les brevets logiciels ? ou j'ai raté un épisode (ce qui ne m'étonnerait pas)

La licence BSD est plus du genre : "Prend mon projet et fais moi mal"
C'est pas pour rien que la mascote est un démon ;-)

Hotmail ?