Je vois deux possibiltés:
1) Tu veux analyser les règles pour comprendre le comportement du pare-feu.
2) Tu veux les modifier dans un outil graphique.
Pour le (1) je dirais que rien ne vaut le résultat de "iptables-save", mais tu aura quand même du mal à le lire si "iptables -L" ne te parle pas.
En effet, il te faudra de toute manière comprendre la façon dont travaille netfilter (la partie noyau de iptables) avec les chaînes, les tables, les "target" et modules de "matchig". Savoir lire une config iptables demande une certaine pratique et recherche documentaire.
Pour le (2) ça risque de coincer. Chaque GUI parmis celles que j'ai vu (à part peut-être ipmenu qui se contente de coller à la structure des chaînes et des tables et par la même a bien peu de valeur ajoutée) utilise un formalisme restrictif par rapport à la richesse expressive d'iptables. Un peu comme les langages de haut niveau par rapport à l'assembleur. Cela signifie qu'il n'y a pas forcément d'équivalent, en terme de config de FWbuilder par exemple, a toutes les configs iptables imaginables (et même réalistes), car FWbuilder travaille avec des tuples (source, destination, service, action,...) ordonnées, alors que netfilter utilise un BDD(binary decision diagram) matérialisé par un DAG(directed acyclic graph).
Certes, on peut exprimer à peu près n'importe quel filre avec les tuples de FWbuilder et il est imaginable de créer un programme qui traduira le bdd d'iptables en conf de FWbuilder, mais le résultat risque de ne pas être beau à voir (bon, y a sans doute moyen d'aboutir à un résultat plutôt joli, mais ça relève de la recherche opérationelle assez costaud: il faut reconnaitre les groupes d'objets et de services, les organiser en règles de façon compacte. Vraiment, je doute que ça existe) et de toutes façons une fois modifiée et retraduite en iptables, la conf n'aura plus rien à voir avec celle de départ (à part le résultat de filtrage qui devrait être le même modulo les modif que t'a faites, s'il ya pas de bugs dans les traitements).
J'ai pris l'exemple de FWbuilder car à mon sens son formalisme est le plus riche des frontend que j'ai pu regarder (et j'en ai passé en revue plus de 70 récemment).
Un argument pourrait m'être opposé:
Et si les règles iptables sont à l'origine issues de FWbuilder ? Effectivement, comme pour les desassembleurs qui visent des fichiers objets produits par des compilateurs bien precis, il est beucoup plus facile de revenir en arrière. Du moment que l'on a réussi à déterminer quel formalisme a été utilisé à l'origine et comment il a été translaté en iptables, les choses sont d'autant plus simples que le formalisme en question est restreint par rapport au bdd d'iptables.
Cela dit si j'ai bien compris, le produit qui a servi à créer les règles dans notre cas n'est pas connu (chose étonante par ailleur: d'où viendrait donc cette conf alors?), une bonne séance de reverse engineering s'impose donc? Si tu fournis ta conf on pourrait tenter de faire un "décompilateur" qui produirait une conf FWbuilder ou autre.
Mais là une autre question se pose: comment comptes-tu injecter cette nouvelle conf dans ton système ? Si c'est en écrasant la conf d'origine, pourquoi ne pas repartir de zéro en mettant à plat tes besoins ce qui est une bonne chose à faire de toutes les façons ?
# Afficher dans quel but?
Posté par het . En réponse au message Cherche GUI pour iptables. Évalué à 1.
1) Tu veux analyser les règles pour comprendre le comportement du pare-feu.
2) Tu veux les modifier dans un outil graphique.
Pour le (1) je dirais que rien ne vaut le résultat de "iptables-save", mais tu aura quand même du mal à le lire si "iptables -L" ne te parle pas.
En effet, il te faudra de toute manière comprendre la façon dont travaille netfilter (la partie noyau de iptables) avec les chaînes, les tables, les "target" et modules de "matchig". Savoir lire une config iptables demande une certaine pratique et recherche documentaire.
Pour le (2) ça risque de coincer. Chaque GUI parmis celles que j'ai vu (à part peut-être ipmenu qui se contente de coller à la structure des chaînes et des tables et par la même a bien peu de valeur ajoutée) utilise un formalisme restrictif par rapport à la richesse expressive d'iptables. Un peu comme les langages de haut niveau par rapport à l'assembleur. Cela signifie qu'il n'y a pas forcément d'équivalent, en terme de config de FWbuilder par exemple, a toutes les configs iptables imaginables (et même réalistes), car FWbuilder travaille avec des tuples (source, destination, service, action,...) ordonnées, alors que netfilter utilise un BDD(binary decision diagram) matérialisé par un DAG(directed acyclic graph).
Certes, on peut exprimer à peu près n'importe quel filre avec les tuples de FWbuilder et il est imaginable de créer un programme qui traduira le bdd d'iptables en conf de FWbuilder, mais le résultat risque de ne pas être beau à voir (bon, y a sans doute moyen d'aboutir à un résultat plutôt joli, mais ça relève de la recherche opérationelle assez costaud: il faut reconnaitre les groupes d'objets et de services, les organiser en règles de façon compacte. Vraiment, je doute que ça existe) et de toutes façons une fois modifiée et retraduite en iptables, la conf n'aura plus rien à voir avec celle de départ (à part le résultat de filtrage qui devrait être le même modulo les modif que t'a faites, s'il ya pas de bugs dans les traitements).
J'ai pris l'exemple de FWbuilder car à mon sens son formalisme est le plus riche des frontend que j'ai pu regarder (et j'en ai passé en revue plus de 70 récemment).
Un argument pourrait m'être opposé:
Et si les règles iptables sont à l'origine issues de FWbuilder ? Effectivement, comme pour les desassembleurs qui visent des fichiers objets produits par des compilateurs bien precis, il est beucoup plus facile de revenir en arrière. Du moment que l'on a réussi à déterminer quel formalisme a été utilisé à l'origine et comment il a été translaté en iptables, les choses sont d'autant plus simples que le formalisme en question est restreint par rapport au bdd d'iptables.
Cela dit si j'ai bien compris, le produit qui a servi à créer les règles dans notre cas n'est pas connu (chose étonante par ailleur: d'où viendrait donc cette conf alors?), une bonne séance de reverse engineering s'impose donc? Si tu fournis ta conf on pourrait tenter de faire un "décompilateur" qui produirait une conf FWbuilder ou autre.
Mais là une autre question se pose: comment comptes-tu injecter cette nouvelle conf dans ton système ? Si c'est en écrasant la conf d'origine, pourquoi ne pas repartir de zéro en mettant à plat tes besoins ce qui est une bonne chose à faire de toutes les façons ?