Cela concerne l'ensemble de la suite logicielle NuFirewall distribuée sous licence GPL, à l'exception de la brique propriétaire du client Windows qui n'est donc pas disponible sur le site.
Espérons que le repreneur d'EdenWall, Netasq, va libérer le code de l'agent Windows.
Le code de l'agent Windows est clairement propriétaire. C'était une manière pour INL/EdenWall de garder le monopole sur le logiciel qu'elle éditait (son fer de lance qui la démarquait de la concurrence), le parefeu NuFW.
Il existe 3 agents libres pour Linux, FreeBSD et Mac OS X : agent en mode texte, agent graphique (C++ et Qt, le "QNU", je n'ai pas vérifié s'il est disponible sur ufwi.org) et agent "transparent" (plugin PAM lancé en arrière plan).
Le protocole réseau de NuFW est public, le plus difficile est de trouver des informations sur la table des connexions sous Windows (peu voir non documenté). L'agent Windows utilise notamment un pilote Windows pour récupérer ces informations. Si un ancien client d'EdenWall souhaite faire évoluer l'agent (ou en écrire une nouvelle implémentation), l'agent 64 bits ne supportant pas le VPN par exemple (ce qui commence à poser problème aujourd'hui), il lui suffit d'utiliser la rétro ingénierie.
Bien que ça ne soit pas facile à faire dans une société avec un grand parc existant, la solution évidente à ce problème est de passer les postes sous Linux (ou FreeBSD). La migration pouvant être progressive (règles différentes pour le parc Windows et pour le parc Linux, en utilisant des règles non authentifiés pour Windows par exemple).
Un projet d'agent Windows alternatif utilisant Active Directory pour "identifier" l'origine des connexions avait été évoqué pendant un temps (sécurité plus faible mais meilleure qu'un parefeu non authentifiant), mais le projet ne s'est jamais concrétisé. Je ne connais pas assez Active Directory pour savoir quelles informations il fournit.
Enfin, il existe un autre type d'authentification (faible) : un agent implémenté en Java cette fois-ci, l'applet Java, qui répond simplement "Hello" chaque fois qu'on l'interroge. Cet agent utilise un tunnel chiffré pour son lien avec nuauth (comme les autres agents) et exige une authentification initiale (identifiant et mot de passe de l'utilisateur), mais est incapable de certifier qu'une nouvelle connexion a été ouverte par le poste client sur lequel il tourne.
L'applet Java ne semble pas non être disponible sur ufwi.org. Si une personne en possède une copie, ou mieux, une copie des sources, je pense que la FSF serait intéressée :-)
[^] # Re: NuAgent pas disponible ?
Posté par Victor STINNER (site web personnel) . En réponse au journal Nouvel hébergement du projet NuFW sur ufwi.org. Évalué à 4.
Extrait du communiqué de presse de FSF France :
Espérons que le repreneur d'EdenWall, Netasq, va libérer le code de l'agent Windows.
Le code de l'agent Windows est clairement propriétaire. C'était une manière pour INL/EdenWall de garder le monopole sur le logiciel qu'elle éditait (son fer de lance qui la démarquait de la concurrence), le parefeu NuFW.
Il existe 3 agents libres pour Linux, FreeBSD et Mac OS X : agent en mode texte, agent graphique (C++ et Qt, le "QNU", je n'ai pas vérifié s'il est disponible sur ufwi.org) et agent "transparent" (plugin PAM lancé en arrière plan).
Le protocole réseau de NuFW est public, le plus difficile est de trouver des informations sur la table des connexions sous Windows (peu voir non documenté). L'agent Windows utilise notamment un pilote Windows pour récupérer ces informations. Si un ancien client d'EdenWall souhaite faire évoluer l'agent (ou en écrire une nouvelle implémentation), l'agent 64 bits ne supportant pas le VPN par exemple (ce qui commence à poser problème aujourd'hui), il lui suffit d'utiliser la rétro ingénierie.
Bien que ça ne soit pas facile à faire dans une société avec un grand parc existant, la solution évidente à ce problème est de passer les postes sous Linux (ou FreeBSD). La migration pouvant être progressive (règles différentes pour le parc Windows et pour le parc Linux, en utilisant des règles non authentifiés pour Windows par exemple).
Un projet d'agent Windows alternatif utilisant Active Directory pour "identifier" l'origine des connexions avait été évoqué pendant un temps (sécurité plus faible mais meilleure qu'un parefeu non authentifiant), mais le projet ne s'est jamais concrétisé. Je ne connais pas assez Active Directory pour savoir quelles informations il fournit.
Enfin, il existe un autre type d'authentification (faible) : un agent implémenté en Java cette fois-ci, l'applet Java, qui répond simplement "Hello" chaque fois qu'on l'interroge. Cet agent utilise un tunnel chiffré pour son lien avec nuauth (comme les autres agents) et exige une authentification initiale (identifiant et mot de passe de l'utilisateur), mais est incapable de certifier qu'une nouvelle connexion a été ouverte par le poste client sur lequel il tourne.
L'applet Java ne semble pas non être disponible sur ufwi.org. Si une personne en possède une copie, ou mieux, une copie des sources, je pense que la FSF serait intéressée :-)