Sans aller vers les extremités telles que "détruit tout le user land en laissant tourner le noyau", dans la téorie des systemes surs il y a la notion de trusted path (http://en.wikipedia.org/wiki/Trusted_path). A l'origine ce mechanisme est destiné a garantir la sécurité (en évitant les fausses mires de login par ex) mais peut aussi servir a lancer un interface de gestion de process comme c'est le cas dans WinNT (sequence ctrl-alt-del). Sous linux il y a la sequence Sys-rq+XX (XX étant une touche par exemple "r" pour passer le clavier en mode raw, switcher vers une autre console et resoudre le pb).
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 ?
La sortie STDOUT de la commande "iptables-save" est une suite de lignes qui, presentée au STDIN de "iptables-restore" a pour effet de reproduire les regles iptables telles quelles au moment de l'execution de "iptables-save" (les chaines sont recrées et celles inexistantes au moment de la sauvegarde, supprimées) , et ce pour toutes les tables et toutes les chaines (et leurs politiques) ce qui en soit et déja tres pratique.
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 ...
Pour ce qui est d'actions en justice , je pense qu'il serait plus efficace de constituer un fond destiné a faire invalider les brevets logiciels illegaux dés que qqn tente de s'en servir dans un proces.
Ce serait une arme de dissuasion dirigée vers tous les brevets a la fois.
D'ailleurs je crois bien que ca existe deja dans le cadre de la FFII.
[^] # Re: Plantage
Posté par het . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 1.
[^] # Re: Plantage
Posté par het . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 2.
[^] # Re: Afficher dans quel but?
Posté par het . En réponse au message Cherche GUI pour iptables. É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)
# 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 ?
[^] # Re: Oublie les GUI
Posté par het . En réponse au message Cherche GUI pour iptables. É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: Et l'Office Européen des Brevets ?
Posté par het . En réponse à la dépêche Les eurodéputés rejettent la directive sur le brevet des logiciels. Évalué à 2.
Ce serait une arme de dissuasion dirigée vers tous les brevets a la fois.
D'ailleurs je crois bien que ca existe deja dans le cadre de la FFII.