URL: https://linuxfr.org/users/ptifeth/journaux/fantasme-ergonomique-interface-graphique-pour-firewall Title: [Fantasme ergonomique] Interface graphique pour firewall Authors: feth Date: 2008年09月12日T19:56:20+02:00 Tags: Score: 9 _Voici une élucubration assez longue, écrite au kilomètre, par un non spécialiste curieux pour d'autres curieux. J'espère que certains auront le courage de lire en diagonale, et surtout envie de faire partager leur réflexion en commentaires._ **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).