Une boîte à outils bas niveau très riche
Nous disposons aujourd'hui de pare-feu capables d'effectuer des filtrages très fins ; en s'organisant bien on peut aujourd'hui décider du destin d'une connexion en fonction de paramètres innombrables :
- source,
- destination,
- type de paquet,
- lien avec une connexion existante,
- application,
- protocole découvert en lisant le paquet,
- utilisateur,
- heure...
Et pas seulement des filtrages ; il est possible de
- logger,
- rediriger sur un autre port, une autre machine,
- faire du PAT/NAT (Network_address_translation)...
Et des choses plus perverses encore.
...mais difficile à utiliser.
De temps en temps nous avons besoin de toucher à cette salade de nouilles que constitue une liste de règles iptables (par exemple). Et soudain, c'est le drame : imaginez l'explosion combinatoire pour une entreprise comportant par exemple 5 serveurs, 10 imprimantes, 30 postes de travail et machines répartis sur 3 sites connectés en VPN et à l'internet, et accessibles depuis icelui via VPN pour des services précis.
Solutions existantes
Heureusement qu'il existe beaucoup de scripts et d'interfaces graphiques pour générer les règles de filtrage, souvent relativement agnostiques par rapport au firewall cible (je pense à fwbuilder).
En gros, ces outils proposent de créer dans chaque table des règles avec les champs
- "source",
- "destination",
- "protocole",
- "décision",
où chacun des champs peut être un élément atomique, un ensemble ou une liste de tels éléments.
Exemple de valeurs pour le champ source :
- une adresse MAC,
- une adresse/un masque de réseau IP,
- "ANY",
- un groupe comprenant n'importe quelle combinaison d'éléments des catégories précédentes
- une liste d'éléments des catégories précédentes
... et proposition d'une abstraction encore plus proche de la tâche complexe à accomplir
Seulement voilà, ça ne me suffit pas encore tout à fait : je pense qu'on pourrait monter un niveau d'abstraction au dessus de ce que proposent nuface, fwbuilder etc, car ces derniers ne font finalement (je caricature, ne frappez-pas) que factoriser la combinaison de règles (et c'est déjà pas mal). Leur apport fondamental, à mon sens, c'est la reprise des notions objet de l'héritage et de l'agrégation.
Alors voilà, j'ai eu deux trois idées, brouillonnes, et sans doute vous en aurez de meilleures.
Choix de la métaphore
Souvent nous voyons des graphes de réseau tout à fait élégants, qui relient des éléments et des ensembles d'éléments représentés au moyen de symboles appropriés par des câbles, et je crois que tout le monde comprend très vite ce langage graphique.
Dans mes rêves, l'outil de gestion de pare-feu serait donc plus ou moins un outil de dessin de réseau.
Représentation de l'agrégation
Si l'on admet que certains éléments du réseau sont des agrégats d'autres éléments, par exemple qu'un réseau est composé de réseaux ou de machines, pas forcément toutes connues, qui possèdent une ou plusieurs adresses IP, MAC, toujours pas forcément connues. À chaque adresse IP on peut associer tous les ports requis.
Je propose qu'on puisse zoomer et dezoomer facilement pour faire apparaître les éléments connus ou utiles d'un ensemble. Exemple : le gros nuage, "Internet", après zoom, contiendrait de nombreux serveurs "pré-saisis".
Par souci de clarté, n'apparaîtraient que les serveurs connus utiles à tout un chacun, comme makezine.com ou utiles à certains métiers comme google.com, laissant à l'utilisateur du logiciel la possibilité d'ajouter des éléments à la liste.
En zoomant sur un (ensemble de) serveur(s), et en choisissant une ou toutes les adresses IP, on pourrait sélectionner d'abord des tâches évidentes : consulter une page web, être un client bittorrent... puis avoir la possibilité d'en créer de nouvelles, bien sûr.
Cas d'utilisation
L'utilisateur pourrait ensuite relier (directionnel) des éléments entre eux. Par exemple "Internet" doit pouvoir consulter des pages web sur notre serveur web, donc on dessine une liaison "consulter des pages web" dans cette direction. Si on a créé un groupe "télétravailleurs", on va le relier vers le groupe "serveurs VPN" avec le type correspondant.
Je pense qu'il est possible de détecter les cas où un pare-feu doit faire du NAT et ceux où il ne le doit pas, et que la configuration d'un NAT par l'utilisateur peut devenir optionnelle.
On peut rendre la vie beaucoup plus facile à l'utilisateur au moyen de l'autodétection, lorsqu'on parvient à des éléments pertinents comme points de liaison (grâce à bonjour, par exemple).
Représentation des personnes
Certaines machines sont des stations de travail, et l'administrateur peut vouloir découpler la configuration utilisateur de la configuration machine, et là, ça devient compliqué... pour le programmeur surtout, parce qu'il n'y a aucune raison d'utiliser une interface différente.
Restrictions et configurations additionnelles
Dans certains cas, certaines tâches ne sont possibles que sous contraintes, et justement, l'intérêt de représenter les liaisons par des câbles, c'est que ceux-ci peuvent, toujours dans la même métaphore, porter des interrupteurs.
Pour la contrainte horaire, l'interrupteur pourrait être relié à une horloge ouvrant le traditionnel dialogue de configuration. Pour d'autres contraintes, il faut plus d'imagination.
J'imagine que les configuration courantes, comme le NAT, devraient également être attachées aux "câbles".
Pas de mockup
J'ai une idée plutôt vague de ce qui serait peut-être une solution rendant la configuration réseau plus accessible, plus facile et plus rapide, sans pour autant perdre trop de possibilités, et un croquis sur papier, mais je préfère ne pas gâcher une impression éventuellement favorable par un mauvais choix de couleurs, ou en fixant un design erroné dans la mémoire visuelle de mes éminents lecteurs, admirables de patience.
Je ferai toutefois une transcription avec inkscape si on me le demande au bon moment (les prochains jours sont chargés).
# Mon sentiment sur ce genre d'outils ...
Posté par totof2000 . Évalué à 9.
Ce genre d'outil en général marche bien pour des choses simples, mais n'est pas capable de traiter correctement les cas complexes. Au final on se retrouve avec un truc qui parait beau et clair mais quand on regarde au dela des apparences dans les couches inférieures on se rend compte que ce qui est généré en dessous est crade, mal optimisé, et souvent très complexe et peu factorisé.
Prenons un exemple tout bête : la génération de pages HTML par des outils style Frontpage/Dreamweaver. Je connais également quelqu'un qui a tenté de générer des règles pour son firewall à l'aide d'un outil "magique" capable de s'interfacer avec plusieurs firewalls ... Je vous racconte pas le plat de nouilles généré .... Plus récemment j'ai vu ce que peuvent donner des outils de génération de scripts. Pas génial ...
tout ceci pour dire que pour bien utiliser un outil il faut le connaitre, et ce dans n'importe quel domaine. Ca signifie connaitre les possibilités de chaque outil, ce qu'il peut faire, ou non, comment réaliser telle ou telle action de la meilleure facon. Faire abstraction de tout cela, c'est se concentrer sur le tronc commun des outils de même type (là on parle de firewall), et se priver des fonctionnalités qui ne sont pas communes. C'est aussi parfois vouloir faire les choses avec l'outil A de la même facon qu'avec l'outil B, alors qu'en s'y prenant autrement avec l'outil B, on obtient un meilleur résultat ...
On pourrait comparer ça à des clés (clé 6 pans, clé allen, etc ...) ou a des tournevis. Il existe des tournevis cruciformes, à tête plate. Il existe des petits, grands tournevis. Bien que parfois il soit possible d'utiliser un tournevis plat pour enlever une vis cruciforme, en général ça ne se passe pas sans dommage pour la vis, et ça ne marche pas tout le temps. Et au final il n'existe pas de tournevis universel capable de visser/dévisser toutes les vis ...
[^] # Re: Mon sentiment sur ce genre d'outils ...
Posté par feth . Évalué à 4.
Tous les firewalls ne peuvent pas tout faire, et pas de la même façon. Entièrement d'accord. Là je vois deux possibilités, même pas contradictoires :
1) ne s'occuper que de linux ou de bsd, et de rien d'autre)
2) créer des objets firewalls de type linux, bsd, cisco... comme le fait fwbuilder. Si un de ces pare-feu ne pouvait faire de filtrage stateful, par exemple, eh bien il suffirait que cette option ne soit pas proposée lorsqu'on tente d'utiliser un tel firewall, non ?
[^] # Re: Mon sentiment sur ce genre d'outils ...
Posté par totof2000 . Évalué à 4.
Il y aura toujours des cas ou on ne pourra pas l'accepter, un peu comme dans le cas de certains traitements que tu ne peux pas traiter en Python car trop lent (par exemple une animation complexe en 3D). C'est pour ça que le cas 1 me parait plus réalisable, ou alors il faut se cantonner aux 'cas simples et génériques' (un peu comme le font certaines interfaces de configuration aujourd'hui) parce que, à un moment tu devras descendre assez bas dans les spécificités du firewall et seul quelqu'un qui connait ledit firewall pourra comprendre ce qu'il fait.
[^] # Re: Mon sentiment sur ce genre d'outils ...
Posté par feth . Évalué à 3.
Un antidote serait de pouvoir re-générer le graphe à partir des règles iptables + les scripts adjoints (qui mettent en place les contraintes telles que "en cas d'apparition de l'interface vpnmarcel", ou "entre midi et 14 heures" ou encore "en cas de port knock port 45678").
[^] # Re: Mon sentiment sur ce genre d'outils ...
Posté par psychoslave__ (site web personnel) . Évalué à 6.
Je ne sais pas ce que génère frontpage/dreamweaver, mais je sais que ce que je pond comme css sous vim, peut largement être factorisé. Ca ne veut pas dire que ça serait plus lisible, mais ça pourrait sans doute faire gagner quelques ko (vous me direz à l'heure où pour afficher 3 lignes de textes il faut télécharger 20Mo d'animation flash, qui ce soucis de la taille des fichiers qu'on envoi).
De plus, je pense que si on commence à utiliser ce genre d'outil de haut niveau, le but c'est de ne plus aller voir ce qui se passe en bas niveau. Alors on peut avoir un plat de nouille bien optimisé mais difficilement compréhensible si on regarde sous le capot.
La personne qui fait du traitement de texte n'a pas besoin de savoir comment fonctionne la génération d'odf, comment fonctionne un système de fichier, le noyau qui fait tourner son OS, ou encore le matériel qui fait tourner tout ça.
Enfin bref, tout ça pour dire que je trouve tes arguments un peu faiblards, même si je pense pas forcément que l'interface décrite dans ce journal soit une bonne manière d'aborder le problème (et n'étant pas admin système, je ne saurais trop me prononcer pour être tout à fait honnête).
[^] # Re: Mon sentiment sur ce genre d'outils ...
Posté par totof2000 . Évalué à 2.
Pas tant que ça en fait ... Ca dépend dans quel sens on le prend ...
De plus, je pense que si on commence à utiliser ce genre d'outil de haut niveau, le but c'est de ne plus aller voir ce qui se passe en bas niveau. Alors on peut avoir un plat de nouille bien optimisé mais difficilement compréhensible si on regarde sous le capot.
Je ne parle pas seulement de lisibilité mais d'efficacité. et la on peut prendre l'exemple du Perl ou C, pour ces langages un code efficace n'est pas forcément un code lisible ...
D'une manière générale ce n'est pas tant l'approche "interface graphique" qui me gène mais l'approche "interface graphique universelle".
La personne qui fait du traitement de texte n'a pas besoin de savoir comment fonctionne la génération d'odf, ...
Peut être, si elle utilise OpenOffice, ou toute autre suite bureautique concue autour de l'ODF, par exemple, elle pourra certainement esperer obtenir un meilleur code généré que si elle utilise un MS Word qui a été à l'origine concu pour un autre format, et le rendu ne sera pas forcément le même.
... comment fonctionne un système de fichier ...
Pour moi c'est un autre problème .... C'est le problème du développeur ça ... Si on veut prendre l'analogie des FS, il faudrait s'intéresser à la façon dont on définit les droits d'accès aux fichiers sur les serveurs Windows et Unix. Et les outils qui cherchent à uniformiser ce genre de trucs en généal réimplémentent un bout de code dans le noyau pour se superposer aux droits du système ...
Pour les deux autres exemples je n'ai pas d'arguments .... mais ça viendra certainement plus tard.
Enfin bref, tout ça pour dire que je trouve tes arguments un peu faiblards, même si je pense pas forcément que l'interface décrite dans ce journal soit une bonne manière d'aborder le problème (et n'étant pas admin système, je ne saurais trop me prononcer pour être tout à fait honnête).
Je pense que c'est surtout ma façon de m'exprimer qui est faiblarde. En fait je ne fais qu'exprimer un ressenti ... Je ne suis pas contre l'approche "interface graphique" mais plutot sceptique à l'interface graphique capable de gérer tous les firewalls existant. Et la c'est surtout un retour d'expérience par rapport aux tentatives que j'ai vues de faire la même chose dans d'autres domaines .....
.
[^] # Re: Mon sentiment sur ce genre d'outils ...
Posté par feth . Évalué à 2.
[^] # Re: Mon sentiment sur ce genre d'outils ...
Posté par totof2000 . Évalué à 2.
[^] # Re: Mon sentiment sur ce genre d'outils ...
Posté par Infernal Quack (site web personnel) . Évalué à 6.
Et quand je vois le code HTML produit à la main dans certaines applications webs que j'ai l'occasion de maintenir, je me demande si je ne préfère pas le code fait par Dreamweaver :)
Bon par contre pour Frontpage, il n'y a pas photo : Il ne peut y avoir pire /o\
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Mon sentiment sur ce genre d'outils ...
Posté par Thomas Douillard . Évalué à 4.
Je pense par exemple qu'une interface qui forcerait à uns structure de document claire, avec des titres, des vrais paragraphes "à la latex diront" nous et pas une mise en page à l'arrache, c'est facile de générer du code propre.
Bref la génération automatique c'est pas forcément le mal absolu, et de nos jours ou on a des outils de hauts niveau pour générer des transformations, je pense à ATLAS_Transformation_Language ATL par exemple ou des trucs de cette communauté, il y a pas de raison que ça empire, bien au contraire.
[^] # Re: Mon sentiment sur ce genre d'outils ...
Posté par totof2000 . Évalué à 2.
Je n'ai jamais dit ça, je dis simplement que la génération automatique montre souvent vite ses limites, et entre les prétendues possibilité d'un outil de génération automatique et ce qu'il fait réellement il y a souvent un gouffre, surtout lorsque ledit outil veut gérer un tas de trucs qui se ressemblent de loin mais qui de près ont t quand même pas mal de différeces, surtout quand on y ajoute une couche graphique ....
Cela dit, le jour ou un tel outil sortira, je serai le premier à m'en réjouir, mais aujourd'hui je n'y crois pas (ou plus ...).
# autre point
Posté par totof2000 . Évalué à 2.
Un ensemble de règles bien écrites et bien commentées ne constitue pas une salade de nouilles ...
Sinon pour en revenir à ton idée, je la trouve plutot bonne, cependant vouloir faire un outil capable de s'interfacer avec tous les firewalls (j'exagère un peu avec "tous" mais l'idée est là) relève comme tu le souligne dans ton titre, du fantasme. Tiens un autre exemple qui me vient à l'idée : les tentatives de créer un outil capable de gérer les divers types de paquets des diverses distributions ....
[^] # Re: autre point
Posté par Thomas Douillard . Évalué à 3.
C'est intéressant ça, ça donnait quoi ?
À priori les concepts des paquets: version - dépendances à d'autres paquets sont identiques, mais les données, à savoir les paquets, sont différents suivant les distributions, c'est ça qui coinçait ?
[^] # Re: autre point
Posté par Marc Poiroud (site web personnel) . Évalué à 5.
http://packagekit.org/
[^] # Re: autre point
Posté par Infernal Quack (site web personnel) . Évalué à 2.
Je pense aux styles gtk ou kde, aux thêmes gdm/kdm/...., aux plugins Firefox,.... Car actuellement ça les installedans le répertoire et pas au niveau de tous les utilisateurs en en plus si on tombe sur un fichier qui appartient à ces composants on ne peut pas vérifier d'oùil vient (rpm -qf ...)/ Et en plus il n'y a pas de gestion de dépendances via des installeurs intégrés à une application.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: autre point
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: autre point
Posté par totof2000 . Évalué à 2.
[^] # Re: autre point
Posté par totof2000 . Évalué à 2.
C'est la même chose pour la mise en place de règles de firewall ....Les concepts sont les mêmes quel que soit le firewall, cependant construire un outil qui est capable de tous les géerer est assez compliqué. Aujourd'hui, on arrive à faire des choses qui "commmencent" à être intéressante. Cela dit ces outils montrent vite leurs limtes. Un exemple :
http://autopackage.org/faq.html?PHPSESSID=3e1bee0a19bb498f5a(...)
# Is autopackage meant to replace RPM?
No. RPM is good at managing the core software of a distro. It's fast, well understood and supports features like prepatching of sources. What RPM is not good at is non-core packages, ie programs available from the net, from commercial vendors, magazine coverdisks and so on. This is the area that autopackage tackles. Although in theory it'd be possible to build a distro based around it, in reality such a solution would be very suboptimal as we sacrifice speed for flexibility and distro neutrality. For instance, it can take several seconds to verify the presence of all required dependencies, something that RPM can do far quicker.
La question que je me pose sur ce genre d'outil c'est que se pass-t-il si un prérequis système n'est pas installé ou n'a pas la bonne versoin ? Voila une limite". Et tot ou tard avec ce genre d'outil on se trouve confronté à ce genre de limite. La seconde : "it can take several seconds to verify the presence of all required dependencies, something that RPM can do far quicker.".
Cet outil serait certainement plus intéressant si les distributions Linux ne liaient pas autant le "core OS" et les packages applicatifs .... Ceci permettrait de faire sauter un premier verroou.
[^] # Re: autre point
Posté par Thomas Douillard . Évalué à 2.
Si un paquet n'est pas dispo pour une distrib particulière, il faut faire un paquet spécifique pour packagkit, idéalement pas (trop) distro dépendant ... Ce qui revient à faire une distro que avec des paquets "haut niveau".
[^] # Re: autre point
Posté par totof2000 . Évalué à 1.
En plus il faut suivre les évolutions des divers gestionnaires de paquets gérés ...
[^] # Re: autre point
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: autre point
Posté par totof2000 . Évalué à 2.
En plus il faut suivre les évolutions des divers gestionnaires de paquets gérés ...
[^] # Re: autre point
Posté par PLuG . Évalué à 5.
J'abonde dans ce sens. IPtables est très complet et pas si compliqué à utiliser, de plus on peut lui adjoindre de la QoS, des tables de routage multiples, et plein d'autre choses sympa. Avec la notion de "jump" on peut même optimiser le nombre de règles parcourues par le kernel pour prendre sa décision ...
Je ne vois pas comment on pourrait mettre tout ça dans une interface graphique qui permette de tout représenter d'un seul coup d'oeil.
Si je pouvais donner un conseil ce serait plutot:
- utilisez la ligne de commande iptable dans des scripts c'est précis
- si vous avez trop de règles, ben justement iptables permet de decouper le probleme en plusieurs chaines (et utiliser le jump -j ). Le découpage intelligent des règles permet de les rendre lisibles.
- et si c'est encore trop compliqué c'est que vous tentez de filtrer beaucoup, beaucoup de zones de sécurités différentes avec un seul parefeu ... pour moi c'est MAL car la moindre erreur de règle va compromettre directement la sécurité du réseau, je conseille donc de séparer le problème en utilisant plusieurs parefeux dans ce cas (le prix d'un PC faisant tourner iptables n'est pas vraiment un problème en entreprise, ni même deux serveurs si on veut un cluster ...)
Tu l'aura compris, pour moi si le problème est compliqué il faut se former ou embaucher quelqu'un qui sait, et ne pas croire qu'une interface graphique va permettre a n'importe qui de gérer correctement des règles de parefeu d'entreprise ... d'autant plus que le script iptables est auditable, gérable dans un gestionnaire de source (svn ?), ...
[^] # Re: autre point
Posté par Thomas Douillard . Évalué à 4.
On peut représenter plein de chose graphiquement. Songe par exemple qu'un mot d'une ligne de commande peut se représenter en plus compact par un symbole ...
Les jeux de plateaux ou de carte font parfois des merveilles pour présenter pleins d'infos de manière claire et synthétique sur une carte à jouer par exemple.
[^] # Re: autre point
Posté par Batchyx . Évalué à 7.
iptables -A INPUT -p tcp -i eth0 --dport ssh -j ACCEPTÇa donne pas franchement envie. Si on utilise les options longues, c'est pas beaucoup mieux :iptables -append INPUT --protocol tcp --in-interface eth0 --dport ssh --jump ACCEPTAvec une syntaxe à-la-ip/ifconfig/route du genreiptables chain INPUT add rule accept when protocol=tcp if=eth0 dport=sshça serait déjà un peu plus lisible sans avoir à lire le man de 60 pages.[^] # Re: autre point
Posté par matt23 . Évalué à 6.
[^] # Re: autre point
Posté par totof2000 . Évalué à 3.
# ssh autorise sur interface externe
pass in quick log on proto TCP from any to any port=22
[^] # Re: autre point
Posté par stricaud . Évalué à 1.
On dirait qu'il y a trop de mots. "pass" sert à quoi par exemple ?
"quick log", c'est pour faire des logs courts ?
le port = 22 s'applique pour la destination ? ca aurait été pour la source ça aurait fait any port = 22 to any ?
[^] # Re: autre point
Posté par Michel Pastor . Évalué à 3.
- "pass" c'est comme ACCEPT pour Netfilter.
- "quick" c'est pour ne pas tester les règles suivante.
- "log" pour loguer le passage du paquet
- "any port = 22" ça veut dire que ça correspond au port 22 source ou destination
Difficile de faire plus simple quand même.
[^] # Re: autre point
Posté par Sarcastic . Évalué à 3.
Juste à indiquer qu'il faut laisser passer le paquet (Et non le bloquer).
Quand au trop de mots, sur pf (notez la disparition du « = »), y a moyen de réduire ça à ($ext_if étant une macro définie plus haut, et remplacée par le nom de l'interface utilisée par la DMZ) :
pass in quick log on $ext_if proto tcp to port 22"quick log", c'est pour faire des logs courts ?
En fait, non. Le quick indique que si le paquet tombe dans cette règle, alors ipf (Ou pf, différence de syntaxe minime dans l'exemple) n'évalue pas les règles suivantes.
le port = 22 s'applique pour la destination ? ca aurait été pour la source ça aurait fait any port = 22 to any ?
Ç'aurait fait :
pass in quick log on $ext_if from any port 22 to anyOu plus simplement :
pass in quick log on $ext_if from port 22[^] # Re: autre point
Posté par ErrTu . Évalué à 1.
pass in quick log on $ext_if from port ssh[^] # Re: autre point
Posté par totof2000 . Évalué à 2.
Ca done plutot <pre> pass in quick log on <interface> proto TCP from any to any port=22 </pre
# Et le site web ?
Posté par gUI (Mastodon) . Évalué à 2.
Un volontaire ? (-;
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# fwbuilder est ton ami
Posté par alphacc . Évalué à -4.
Il supporte iptables,pf, les pix et aussi les acl cisco des IOS.
Il detecte les interface de ta machine par SNMP etc...
Plein d'autre chose a decouvrir.
[^] # Re: fwbuilder est ton ami
Posté par feth . Évalué à 3.
# wolfotrack
Posté par castorpilot . Évalué à 7.
http://software.inl.fr/trac/wiki/Wolfotrack
# ça existe
Posté par Mildred (site web personnel) . Évalué à -1.
http://www.fwbuilder.org/
Je l'ai trouvé très puissant, et très pratique. Avant, je faisais moi même mes script iptables, mais au bout d'un moment j'ai trouvé que c'était assez fastidieux.
# NuFace ?
Posté par bubar🦥 (site web personnel) . Évalué à 2.
http://software.inl.fr/trac/wiki/EdenWall/NuFace#Screenshot
C' est une interface web pour NuFW (qui semble quant même le plus évolué des firewall Libre pour linux) (tiens d' ailleurs netfilter/iptables se font shooter actuellement, ça bouge beaucoup dans le noyau de ce côté là)
NuFace n' est pas "hyper-ergonomique-mme-michue" mais rempli parfaitement son rôle : simplifier et accélérer les déploiement des règles pour NuFW.
Bien sûr un "nuface" en python/qt4 ça serait mieux pour s' occuper du fierwall personnel ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.