Salut,
Je cherche un GUI pour iptables qui puisse me faire un affichage graphique des regles.
Quand je fais un iptables -L ça ne me parle pas beaucoup.
Si possible un outil qui puisse tourner sur une autre machine que la machine qui fait tourner le firewall vu que le firewall est sur un système embarqué.
Est-ce que ça peut le faire avec firestarter ou knetfilter ?
Forum Linux.général Cherche GUI pour iptables
11
août
2006
# Oublie les GUI
Posté par slack . Évalué à 2.
Tout simplement : trouve le fichier qui configure le pare-feu et édite le avec n'importe quel éditeur de texte (vi ou emacs).
Si ton système embarqué permet le partage (NFS) ou la copie de fichiers (rcp ou mieux scp), tu pourras éditer ce fichier sur une autre machine plus puissante.
Vu les très nombreuses possibilités offertes par netfilter/iptables, jamais une interface graphique ne pourra offrir la puissance de la ligne de commande pour configurer ce pare-feu !
[^] # Re: Oublie les GUI
Posté par arnepsilon . Évalué à 1.
Perso comme le dit Slack, iptables est un outils très puissant et même si je me suis arraché les cheveux à comprendre et à l'utiliser correctement, je suis frileux à utiliser une gui alors qu'il marche du tonnerre chez moi.
Par contre sur un poste client (situé dans un réseau suffisement protégé), rien ne t'empeche de teser les frontend afin de vérifier comment ils procède et si c'est suffisament fiable.
[^] # Re: Oublie les GUI
Posté par mururoa69 . Évalué à 0.
Il n'y a aucun moyen de faire du reverse ? De passer d'un résultat de iptables -L ou iptables avec d'autres options à une liste de règles ayant servi à configurer iptables ?
[^] # Re: Oublie les GUI
Posté par slack . Évalué à 1.
Pas à ma connaissance,
"iptables -L" affiche les règles simples mais pas complètement celles qui sont élaborées.
Peux-tu détailler le "en parsant un fichier de config" ?
Qui crée le fichier de config? Comment est parsé ce fichier? Quelles règles iptables sont générées?
Pourquoi ne pas configurer netfilter dans un script contenant toutes les règles ?
[^] # Re: Oublie les GUI
Posté par mururoa69 . Évalué à 0.
C'est le mecanisme standard de la distribution ( openwrt ) mais oui, je pourrais tout mettre dans un unique fichier de conf. iptables en changeant un peu le mecanisme.
[^] # Re: Oublie les GUI
Posté par het . Évalué à 1.
Mais de plus (ce qui repond a la question du parent), les lignes ainsi generées correspondent aux arguments que l'on passerait a iptables pour peupler les chaines en question: "-A ....".
Pour la creation des tables ("-N ...") et (pour les chaines "builtin") leur politique par defaut ("-P ..."), il faut regarder les lignes commençant par ":", par example
":PLOUF - [6596:1531004]" implique "iptables -N PLOUF"
et
":INPUT DROP [6596:1531004]" implique "iptables -P INPUT DROP"
Les nombres entre crochets sont les stats pour les paquets et les octets respectivement pour la chaine en question.
A noter tout de meme qu'il manque dans ces lignes la reference a la table visée (option "-t") qu'il est possible de retrouver en cherchant les lignes commençant par "*" par example "*mangle" ce qui sui jusq'au COMMIT se refere a la table en question.
Pour resumer:
#iptables-save
# Generated by iptables-save v1.3.3 on Sun Aug 27 21:10:31 2006
*filter
:INPUT DROP [6596:1531004]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [2094864:353911224]
:PLOUF - [0:0]
-A INPUT -i lo+ -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A FORWARD -i lo+ -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Sun Aug 27 21:10:31 2006
# Generated by iptables-save v1.3.3 on Sun Aug 27 21:10:31 2006
*nat
:PREROUTING ACCEPT [39829:3853197]
:POSTROUTING ACCEPT [25:1508]
:OUTPUT ACCEPT [64239:4506008]
-A POSTROUTING -o ppp9+ -j MASQUERADE
COMMIT
# Completed on Sun Aug 27 21:10:31 2006
# Generated by iptables-save v1.3.3 on Sun Aug 27 21:10:31 2006
*mangle
:PREROUTING ACCEPT [8972072:43983625347]
:INPUT ACCEPT [8904220:43942249986]
:FORWARD ACCEPT [64055:40676940]
:OUTPUT ACCEPT [8096951:42527763934]
:POSTROUTING ACCEPT [8161012:42568441108]
-A OUTPUT -m owner --uid-owner lamer -j TOS --set-tos 0x02
COMMIT
# Completed on Sun Aug 27 21:10:31 2006
permet de deduire la config suivante:
# table "filter" pour commencer, l'option "-t" n'est pas necessaire
iptables -N PLOUF
iptables -A INPUT -i lo+ -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i lo+ -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
# table "nat"
iptables -t nat -A POSTROUTING -o ppp9+ -j MASQUERADE
#table mangle
iptables -t mangle -A OUTPUT -m owner --uid-owner lamer -j TOS --set-tos 0x02
Pour les curieux:
- lo+ englobe les interfaces "lo" et "lo_lan", interface ethernet interne que j'ai renommé (cf "nameif") pour l'occasion.
- la ligne avec "--set-tos" traine depius l'epoque ou je fesais du P2P sur cette machine et de la QoS sur une autre, il faillait transmettre l'info sur l'emeteur du paquet, elle ne sert plus.
- la chaine "PLOUF" ne sert a rien, je l'ai cree pour l'example.
En fait, perso, j'utilise meme pas "iptables -L" mais toujours iptables-save, meme pour regarder.
Pareil, "route -n" ou "netstat -rn" se remplacent avantageusement par "ip ro ls", 'ifconfig" par contre garde me faveurs alors que la logique voudrait que j'utilise "ip addr ls". Va savoir ...
Vala, "my 2c" comme disent nos amis saxons.
[^] # Re: Oublie les GUI
Posté par mururoa69 . Évalué à 0.
# fwbuilder
Posté par Calim' Héros (site web personnel) . Évalué à 2.
Je ne suis pas sur que tu puisses recuperer tes regles mais tu pourra creer celle de ton choix et exporter le script a lancer sous la machine cible pour les mettre en place.
De plus il marche avec de nombreux firewall, pas seulement iptables
[^] # Re: fwbuilder
Posté par mururoa69 . Évalué à 0.
# Afficher dans quel but?
Posté par het . É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 ?
[^] # Re: Afficher dans quel but?
Posté par mururoa69 . Évalué à 0.
En fait c'etait plus 1) et iptable-save n'est pas dispo sur la distrib openWRT. Sauf erreur c'est un binaire redhat.
[^] # Re: Afficher dans quel but?
Posté par het . Évalué à 1.
Et bien erreur justement, iptables-save fait partie du source iptables http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/iptables/(...)
Double erreur meme puisque iptables-utils_1.3.3-2_mipsel
http://downloads.openwrt.org/whiterussian/rc5/packages/iptab(...)
contient justement iptables-save et iptables-restore :o)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.