Page suivante Page précédente Table des matières

4. Chaînes de protection IP

Cette section décrit tout ce que vous avez réellement besoin de savoir pour construire un filtre de paquets adapté à vos besoins.

4.1 Comment les paquets traversent les filtres

Le noyau commence avec trois listes de règles : ces listes sont appellées chaînes de protection ou juste chaînes. Ces trois chaînes sont appellées input (entrée), output (sortie) et forward (transmission). Lorsqu'un paquet arrive (disons, par une carte Ethernet), le noyau utilise la chaîne input pour décider de son destin. S'il survit à ce passage, alors le noyau décide où envoyer le paquet par la suite (ceci est appelé routage). S'il est destiné à une autre machine, il consulte alors la chaîne de transmission. Enfin, juste avant que le paquet ne ressorte, le noyau consulte la chaîne de sortie.

Une chaîne est une vérification de règles. Chaque règle dit `si l'entête de ce paquet ressemble à ceci, alors voilà quoi faire de ce paquet'. Si la règle ne vérifie pas le paquet, alors la règle suivante dans la chaîne est consultée. Enfin, s'il n'y a plus de règles à consulter, alors le noyau regarde la chaîne police pour décider ce qu'il doit faire. Dans un système orienté sécurité, cette police dit généralement au noyau de rejeter ou de refuser le paquet.

Pour les fans de l'art ASCII, ceci montre le chemin complet d'un paquet arrivant à une machine.

        -----------------------------------------------------------------------------
        |           ACCEPTER/                               interface lo |
        v           REDIRIGER                 _________                  |
--> S --> V --> ______ --> D --> ~~~~~~~~ -->| Chaîne  |----> _______ -->
    o     a    |chaîne|    e    {Décision}   |transfert|     |Chaîne |ACCEPTER
    m     l    |entrée|    m    {Routage }   |_________| --->|sortie |
    m     i    |______|    a     ~~~~~~~~         |      | ->|_______|
    e     d       |        s        |             |      | |     |
    |     i       |        q        |            NON/    | |     |
    |     t       v        u        v           REJET    | |     v
    |     é      NON/      e    Processus                | |    NON/
    |     |     REJET      r      Local                  | |   REJET
    |     v                |        ---------------------- |
    v    NON               \ ------------------------------/
   NON

Voici une description point par point de chaque partie :

Somme (checksum) :

C'est un test vérifiant si le paquet n'a pas été corrompu d'une manière ou d'une autre. S'il l'a été, il est refusé.

Validité (sanity) :

Il y a en fait un de ces tests sanitaires avant chaque chaîne de protection, mais les chaînes d'entrée sont les plus importantes. Quelques paquets malformés peuvent rendre confus le code de vérification des règles, et ceux-ci sont refusés ici (un message est envoyé au syslog si ceci arrive).

Chaîne d'entrée (input chain) :

C'est la première chaîne de protection qui teste le paquet. Si le verdict de la chaîne n'est ni DENY ni REJECT, le paquet continue son chemin.

Demasquerade :

Si le paquet est une réponse à un paquet précédemment masqué, il est démasqué, et envoyé directement à la chaîne de sortie. Si vous n'utilisez pas le masquage IP, vous pouvez mentalement supprimer ceci du diagramme.

Décision routage (Routing decision) :

Le champ de destination est examiné par le code de routage, pour décider si le paquet doit aller vers un processus local (voir processus local plus bas) ou transmis à une machine distante (voyez les chaînes de renvoi plus bas).

Processus local (Local process) :

Un processus tournant sur la machine peut recevoir des paquets après l'étape de décision de routage, et peut envoyer des paquets (qui passent par l'étape de décision de routage, puis traversent la chaîne de sortie).

Interface lo :

Si les paquets venant d'un processus local sont destinés à un autre processus local, alors ils passeront par la chaîne de sortie en utilisant l'interface lo, puis reviendront par la chaîne d'entrée en utilisant la même interface. L'interface lo est généralement nommée interface loopback.

local :

Si le paquet n'a pas été créé par un processus local, alors la chaîne de transmission est vérifiée, sinon le paquet se dirige vers la chaîne de sortie.

forward chain :

Cette chaîne est traversée par tout paquet qui tente de passer par cette machine vers une autre.

output chain :

Cette chaîne est traversée par tous les paquets juste avant qu'ils ne soient envoyés à l'extérieur.

Utiliser ipchains

Tout d'abord, vérifiez que vous avez la version d'ipchains à laquelle se réfère ce document :

$ ipchains --version
ipchains 1.3.9, 17-Mar-1999

Notez que je recommande l'utilisation du 1.3.4 (qui ne dispose pas des options longues comme `--sport'), ou du 1.3.8 et suivants ; ils sont en effet très stables.

ipchains dispose d'une page de manuel plutôt bien détaillée (man ipchains), et si vous avez besoin de plus de détails en particulier, vous pouvez consulter l'interface de programmation (man 4 ipfw), ou le fichier net/ipv4/ip_fw.c dans les sources des noyaux 2.1.x, qui est (bien évidemment) la référence.

Il y a également une carte de référence rapide par Scott Bronson dans le paquetage source, aux formats PostScript (TM) a4 et US letter.

Il y a plusieurs choses différentes que vous pouvez faire avec ipchains. Tout d'abord les opérations servant à gérer les chaînes entières. Vous commencez avec trois chaînes intégrées input, output et forward que vous ne pouvez effacer.

  1. Créer une nouvelle chaîne (-N) ;
  2. Supprimer une chaîne vide (-X) ;
  3. Changer la police d'une chaîne intégrée (-P) ;
  4. Lister les règles d'une chaîne (-L) ;
  5. Supprimer les règles d'une chaîne (-F) ;
  6. Mettre à zéro les compteurs de paquets et d'octets sur toutes les règles d'une chaîne (-Z).

Il y a plusieurs moyens pour manipuler les règles à l'intérieur d'une chaîne :

  1. Ajouter une nouvelle règle à une chaîne (-A) ;
  2. Insérer une nouvelle règle à une position quelconque de la chaîne (-I) ;
  3. Remplacer une règle à une position quelconque de la chaîne (-R) ;
  4. Supprimer une règle à une position quelconque de la chaîne (-D) ;
  5. Supprimer la première règle vérifiée dans la chaîne (-D).

Il y a quelques opérations pour le masquage, qui se trouvent dans ipchains dans l'attente d'un bon endroit pour les mettre :

  1. Lister les connexions masquées actuelles (-M -L) ;
  2. Configurer les valeurs de timeout (-M -S) (mais voyez id="no-timeout" name="Je ne peux pas modifier les temps d'attente du camouflage !">).

La fonction finale (et peut-être la plus utile) vous permet de vérifier ce qui arriverait à un paquet donné s'il avait à traverser une chaîne donnée.

Opérations sur une règle simple

Ceci est le B.A.-Ba d'ipchains ; manipuler des règles. Plus généralement, vous utiliserez probablement les commandes d'ajout (-A) et de suppression (-D). Les autres (-I pour l'insertion et -R pour le remplacement) sont des simples extensions de ces concepts.

Chaque règle spéficie un ensemble de conditions que le paquet doit suivre, et ce qu'il faut faire s'il les suit (une "destination"). Par exemple, vous pouvez vouloir refuser tous les paquets ICMP venant de l'adresse IP 127.0.0.1. Donc, dans ce cas nos conditions sont que le protocole doit être ICMP et que l'adresse source doit être 127.0.0.1. Notre destination est "DENY" (rejet).

127.0.0.1 est l'interface "loopback", que vous avez même si vous n'avez de connexion réseau réelle. Vous pouvez utiliser le programme "ping" pour générer de tels paquets (il envoie simplement un paquet ICMP de type 8 (requête d'écho) à qui tous les hôtes coopératifs doivent obligeamment répondre avec un paquet ICMP de type 0 (réponse à un écho)). Ceci le rend utile pour les tests.

# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.2 ms
# ipchains -A input -s 127.0.0.1 -p icmp -j DENY
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
# 

Vous pouvez voir ici que le premier ping réussit (le "-c 1" dit à ping de n'envoyer qu'un seul paquet).

Puis nous ajoutons (-A) à la chaîne d'entrée ("input"), une règle spécifiant que tous les paquets provenant de 127.0.0.1 ("-s 127.0.0.1") avec le protocole ICMP ("-p ICMP") doivent être refusés ("-j DENY").

Ensuite nous testons notre règle, en utilisant le second ping. Il y aura une pause avant que le programme ne se termine, attendant une réponse qui ne viendra jamais.

Nous pouvons supprimer la règle avec l'un des deux moyens. Tout d'abord, puisque nous savons que c'est la seule règle de la chaîne d'entrée, nous pouvons utiliser une suppression numérotée, comme dans :

        # ipchains -D input 1
        #
Pour supprimer la règle numéro 1 de la chaîne d'entrée.

La deuxième possibilité est de copier la commande -A, mais en remplaçant le -A par -D. C'est utile lorsque vous avez une chaîne complexe de règles et que vous ne voulez pas avoir à les compter afin de savoir que c'est la règle 37 que vous voulez supprimer. Dans ce cas, nous pouvons utiliser :

        # ipchains -D input -s 127.0.0.1 -p icmp -j DENY
        #
La syntaxe de -D doit avoir exactement les mêmes options que la commande -A (ou -I ou -R). S'il y a des règles multiples identiques dans la même chaîne, seule la première sera supprimée.

Spécifications du filtrage

Nous avons vu l'utilisation de "-p" pour spécifier le protocole, et de "-s" pour spécifier l'adresse souce, mais il y a d'autres options que nous pouvons utiliser pour spécifier les caractéristiques des paquets. Ce qui suit en est une description exhaustive.

Spécifier les adresses IP source et destination

Les adresses IP source (-s) et destination (-d) peuvent être spécifiées de quatre façons différentes. La façon la plus classique est d'utiliser le nom complet, comme "localhost" ou "www.linuxhq.com". La deuxième méthode est de spécifier l'adresse IP, comme "127.0.0.1".

Les deux autres méthodes permettent la spécification d'un groupe d'adresses IP, comme "199.95.207.0/24" ou "199.95.207.0/255.255.255.0". Toutes deux spécifient toutes les adresses IP de 192.95.207.0 à 192.95.207.255, incluse ; les chiffres suivant le "/" indiquent quelles parties de l'adresse IP sont significatives. "/32" ou "/255.255.255.255" sont les défauts (vérifient toutes les adresses IP). Pour ne spécifier aucune adresse IP, "/0" peut être utilisé, par exemple :

        # ipchains -A input -s 0/0 -j DENY
        #

Ceci est rarement utilisé, car l'effet produit par cette ligne de commande est le même que celui obtenu en ne spécifiant pas l'option "-s".

Spécifier l'inversion

De nombreuses options, incluant les options "-s" et "-d" peuvent avoir leurs propres arguments précédés par "!" (prononcé "non") pour ne vérifier que les adresses n'étant PAS équivalentes à celles données. Par exemple, "-s ! localhost" vérifiera tout paquet ne provenant PAS de localhost.

Spécifier le protocole

Le protocole peut être spécifié en utilisant l'option "-p". Le protocole peut être soit un nombre (si vous connaissez les valeurs numériques des protocoles pour IP), soit le nom des cas spéciaux parmis "TCP", "UDP" ou "ICMP". La casse n'est pas prise en compte, donc "tcp" fonctionne aussi bien que "TCP".

Le nom du protocole peut être préfixé par un "!", pour l'inverser, comme dans "-p ! TCP".

Spécifier les ports UDP et TCP

Pour les cas spéciaux où un protocole TCP ou UDP est spécifié, il peut y avoir un argument supplémentaire indiquant le port TCP ou UDP, ou un intervalle (inclusif) de ports (mais voyez Utiliser les fragments plus bas). Un intervalle est représenté en utilisant le caractère ":", par exemple "6000:6010", qui couvre 11 ports, du 6000 au 6010, de manière inclusive. Si la borne inférieure est omise, alors elle se met par défaut à 0. Si la borne supérieure est omise, elle est considérée par défaut comme étant 65535. Ainsi, pour spécifier les connexions TCP venant des ports inférieurs à 1024, la syntaxe pourrait être "-p TCP -s 0.0.0.0/0 :1023". Les numéros de ports peuvent être spécifiés par leur nom, par exemple "www".

Notez que la spécification du port peut être précédée par un "!", qui l'inverse. Ainsi, pour spécifier tous les paquets TCP, SAUF un paquet WWW, vous pourriez spécifier

-p TCP -d 0.0.0.0/0 ! www

Il est important de réaliser que spécifier

-p TCP -d ! 192.168.1.1 www

est très différent de

-p TCP -d 192.168.1.1 ! www

La première ligne spécifie tout paquet TCP dirigé vers le port WWW de n'importe quelle machine sauf 192.168.1.1. La seconde spécifie toute connexion TCP vers tout port de 192.168.1.1 sauf le port WWW.

Enfin, le cas suivant spécifie tout, sauf le port WWW et la machine 192.168.1.1 :

-p TCP -d ! 192.168.1.1 ! www

Spécifier les types et codes ICMP

ICMP permet aussi un argument optionnel, mais comme l'ICMP ne dispose pas de ports (ICMP a un type et un code), ils ont une signification différente.

Vous pouvez les spécifier par les noms ICMP (utilisez ipchains -h icmp pour lister les noms disponibles) après l'option "-s", ou en tant que type et code ICMP numérique, où le type suit l'option "-s" et le code suit l'option "-d".

Les noms ICMP sont relativement longs : vous avez uniquement besoin de suffisamment de lettres pour rendre chaque nom distinct des autres.

Voici un petit résumé de quelques-uns des paquets ICMP les plus communs :

Numéro  Nom                     Utilisé par

0       echo-reply              ping
3       destination-unreachable Tout trafic TCP/UDP
5       redirect                Routage, si pas de démon de routage
8       echo-request            ping
11      time-exceeded           traceroute

Notez que les noms ICMP ne peuvent être précédés de "!" pour le moment.

NE PAS, SURTOUT NE PAS bloquer tous les paquets ICMP de type 3 ! (voir Paquets ICMP plus bas).

Spécifier une interface

L'option "-i" spécifie le nom d'une interface à vérifier. Une interface est le périphérique physique d'où vient le paquet, ou bien par où sort ce paquet. Vous pouvez utiliser la commande ifconfig pour lister les interfaces qui sont "up" (càd en fonctionnement).

L'interface pour les paquets entrants (ie. les paquets traversant la chaîne d'entrée) est considérée comme étant l'interface d'où les paquets proviennent. Logiquement, l'interface des paquets sortants (les paquets traversant la chaîne de sortie) est l'interface où ils vont. L'interface pour les paquets traversant la chaîne de retransmission est également l'interface par laquelle ils sortiront ; une décision plutôt arbitraire à mon sens.

Il est parfaitement autorisé de spécifier une interface qui n'existe pas au moment de la spécification ; la règle ne vérifiera rien jusqu'à ce que l'interface soit mise en place. Ceci est extrêmement utile pour les connexions ppp intermittentes (habituellement les interfaces du type ppp0) et autres.

En tant que cas spécial, un nom d'interface se finissant par un "+" vérifiera toutes les interfaces (qu'elles existent à ce moment ou non) qui commencent par cette chaîne. Par exemple, pour spécifier une règle qui vérifiera toutes les interfaces PPP, l'option -i ppp+ pourrait être utilisée.

Le nom d'interface peut être précédé par un "!" pour vérifier un paquet qui ne vérifie PAS l'(les) interface(s) spécifiée(s).

Spécifier uniquement des paquets TCP SYN

Il est parfois utile d'autoriser des connexions TCP dans une direction, mais pas dans l'autre. Par exemple, vous pouvez vouloir autoriser les connexions vers un serveur WWW externe, mais pas les connexions venant de ce serveur.

L'approche naïve serait de bloquer les paquets TCP venant du serveur. Malheureusement, les connexions TCP utilisent des paquets circulant dans les deux sens pour fonctionner.

La solution est de bloquer uniquement les paquets utilisés pour la demande d'une connexion. Ces paquets sont nommés paquets SYN (ok, techniquement ce sont des paquets avec le drapeau SYN mis, et les drapeaux FIN et ACK supprimés, mais nous les appellerons des paquets SYN). En interdisant seulement ces paquets, nous pouvons stopper toute demande de connexion dans l'oeuf.

L'option "-y" est utilisée pour celà : elle est valide seulement pour les règles qui spécifient TCP comme leur protocole. Par exemple, pour spécifier une demande de connexion TCP venant de 192.168.1.1 :

-p TCP -s 192.168.1.1 -y

Une fois de plus, ce drapeau peut être inversé en le faisant précéder par un "!", qui vérifie tout paquet autre que ceux d'initialisation de connexion.

Utiliser les fragments

Parfois, un paquet est trop large pour rentrer dans le câble en une seule fois. Lorsque ceci arrive, le paquet est divisé en fragments, et envoyé en plusieurs paquets. Le receveur réassemble les fragments pour reconstruire le paquet en entier.

Le problème avec les fragments se situe dans certaines des spécifications listées ci-dessus (en particulier, le port source, le port de destination, le type et le code ICMP, ou le drapeau TCP SYN), qui demandent au noyau de jeter un regard sur le début du paquet, qui est contenu seulement dans le premier fragment.

Si votre machine est la seule connexion vers un réseau extérieur, vous pouvez demander à votre noyau Linux de réassembler tous les fragments qui passent par lui, en compilant le noyau avec l'option IP: always defragment mise à "Y". Ceci évite proprement la plupart des problèmes.

D'autre part, il est important de comprendre comment les fragments sont traités par les règles de filtrage. Toute règle de filtrage qui demande des informations dont nous ne disposons pas ne vérifiera rien. Ceci signifie que le premier fragment est traité comme tout autre paquet. Le deuxième fragment et les suivants ne le seront pas. Ainsi, une règle -p TCP -s 192.168.1.1 www (spécifiant un port source de "www" ne vérifiera jamais un fragment (autre que le premier fragment). La règle opposée -p TCP -s 192.168.1.1 ! www ne fonctionnera pas non plus.

Cependant, vous pouvez spécifier une règle spéciale pour le deuxième fragment et les suivants, en utilisant l'option "-f". Évidemment, il est illégal de spécifier un port TCP ou UDP, un type ou un code ICMP, ou un drapeau TCP SYN dans une règle de fragment.

Il est également autorisé de spécifier une règle qui ne s'applique pas au deuxième fragment et aux suivants, en plaçant un "!" avant le "-f".

Habituellement, il est considéré comme sûr de laisser passer le deuxième fragment et les suivants, puisque le filtrage s'effectuera sur le premier fragment, et préviendra donc le réassemblage sur la machine cible. Cependant, des bogues, connus, permettent de crasher des machines en envoyant de simples fragments. À vous de voir.

À noter pour les gourous réseau : les paquets malformés (TCP, UDP et paquets ICMP trop courts pour que le code pare-feu puisse lire les ports ou les types et codes ICMP) sont également traités comme des fragments. Seuls les fragments TCP débutant en position 8 sont supprimés explicitement par le code pare-feu (un message doit apparaître dans le syslog si celà arrive).

Par exemple, la règle suivante supprimera tout fragment allant sur 192.168.1.1 :

 
# ipchains -A output -f -d 192.168.1.1 -j DENY
#

Effets de bord du filtrage

OK, maintenant nous connaissons tous les moyens pour vérifier un paquet en utilisant une règle. Si un paquet vérifie une règle, les choses suivantes arrivent :

  1. Le compteur d'octets de cette règle est augmenté de la taille de ce paquet (entête et autres) ;
  2. Le compteur de paquets de cette règle est incrémenté ;
  3. Si la règle le demande, le paquet est enregistré ;
  4. Si la règle le demande, le champ "Type Of Service" du paquet est modifié ;
  5. Si la règle le demande, le paquet est marqué (sauf dans la série des noyaux 2.0) ;
  6. La destination de la règle est examinée afin de décider ce que nous ferons ensuite du paquet.

Pour la diversité, je détaillerai ceux-ci en ordre d'importance.

Spécifier une destination

Une destination dit au noyau ce qu'il doit faire d'un paquet qui vérifie une règle. ipchains utilise "-j" (penser à "jump-to") pour la spécification de la destination. Le nom de la cible doit comporter moins de 8 caractères, et la casse intervient : "RETOUR" et "retour" sont totalement différents.

Le cas le plus simple est lorsqu'il n'y a pas de destination spécifiée. Ce type de règle (souvent appellée règle de "comptage") est utile pour simplement compter un certain type de paquet. Que cette règle soit vérifiée ou non, le noyau examine simplement la règle suivante dans la chaîne. Par exemple, pour compter le nombre de paquets venant de 192.168.1.1, nous pouvons faire ceci :

# ipchains -A input -s 192.168.1.1
#

(En utilisant "ipchains -L -v" nous pouvons voir les compteurs de paquets et d'octets associés à chaque règle).

Il y a six destinations spéciales. Les trois premières, ACCEPT, REJECT et DENY sont relativement simples. ACCEPT autorise le passage du paquet. DENY supprime le paquet comme s'il n'avait jamais été reçu. REJECT supprime le paquet, mais (si ce n'est pas un paquet ICMP) génère une réponse ICMP vers la source pour lui dire que la destination n'est pas accessible.

La suivante, MASQ dit au noyau de camoufler le paquet. Pour que ceci fonctionne, votre noyau doit être compilé avec le camouflage IP intégré. Pour les détails sur ceci, voyez le Masquerading-HOWTO et l'annexe Différences entre ipchains et ipfwadm. Cette destination est valide uniquement pour les paquets qui traversent la chaîne forward.

L'autre destination majeure spéciale est REDIRECT qui demande au noyau d'envoyer un paquet vers un port local au lieu de là où il était destiné. Ceci peut être spécifié uniquement pour les règles spécifiant TCP ou UDP en tant que protocole. Optionnellement, un port (nom ou numéro) peut être spécifié après "-j REDIRECT" qui redirigera la paquet vers ce port particulier, même si celui-ci était dirigé vers un autre port. Cette destination est valide uniquement pour les paquets traversant la chaîne input.

La dernière destination spéciale est la RETURN qui est identique à une terminaison immédiate de la chaîne (voir Choisir une police plus bas).

Toute autre destination indique une chaîne définie par l'utilisateur (décrite dans Opérations sur une chaîne entière plus bas). Le paquet traversera tout d'abord les règles de cette chaîne. Si cette chaîne ne décide pas du destin du paquet, lorsque la traversée de cette chaîne sera achevée, la traversée reprendra sur la règle suivante de la chaîne courante.

Il est temps de faire encore un peu d'art ASCII. Considérons deux (étranges) chaînes : input (la chaîne intégrée) et Test (une chaîne définie par l'utilisateur).

              `input'                          `Test'
        -----------------------------    -----------------------------
        | Règle1: -p ICMP -j REJECT |    | Règle1: -s 192.168.1.1    |
        |---------------------------|    |---------------------------|
        | Règle2: -p TCP -j Test    |    | Règle2: -d 192.168.1.1    |
        |---------------------------|    -----------------------------
        | Règle3: -p UDP -j DENY    |
        -----------------------------

Considérons un paquet TCP venant de 192.168.1.1, allant vers 1.2.3.4. Il pénètre dans la chaîne input, et est testé par la Règle1 - pas de correspondance. La Règle2 correspond, et sa destination est Test, donc la règle suivante à examiner est le début de Test. La Règle1 de Test correspond, mais ne spécifie pas de destination, donc la règle suivante est examinée (Règle2). Elle ne correspond pas, nous avons donc atteint la fin de la chaîne. Nous retournons alors à la chaîne input, dont nous avons juste examiné la Règle2, et nous examinons alors la Règle3, qui ne correspond pas non plus.

Le chemin suivi par le paquet est donc le suivant :

                                v    __________________________
         `entrée'               |   /    `Test'                v
        ------------------------|--/    -----------------------|----
        | Règle1                | /|    | Règle1               |   |
        |-----------------------|/-|    |----------------------|---|
        | Règle2                /  |    | Règle2               |   |
        |--------------------------|    -----------------------v----
        | Règle3                /--+---------------------------/
        ------------------------|---
                                v

Voyez la section Comment organiser vos règles pare-feu pour les moyens d'utiliser efficacement les chaînes définies par l'utilisateur.

Enregistrement des paquets

C'est un effet de bord que la vérification d'une règle peut avoir ; vous pouvez enregistrer les paquets vérifiés en utilisant l'option "-l". Vous n'aurez généralement pas besoin de ceci pour les paquets habituels, mais ce peut être une option très utile si vous désirez être tenu au courant des événements exceptionnels.

Le noyau enregistre cette information de la manière suivante :

Packet log: input DENY eth0 PROTO=17 192.168.2.1:53 192.168.1.1:1025
  L=34 S=0x00 I=18 F=0x0000 T=254

Ce message d'information est prévu pour être concis, et contient des informations techniques qui ne sont utiles qu'aux gourous réseau, mais qui peuvent néanmoins être intéressantes pour le commun des mortels. Il se décompose de la façon suivante :

  1. `input' est la chaîne qui contenait la règle correspondant au paquet, et qui a causé l'apparition du message.
  2. `DENY' est ce que la règle a dit au paquet de faire. Si ceci est un `-' alors la règle n'a pas du tout affecté le paquet (une règle de comptage).
  3. `eth0' est le nom de l'interface. Puisque ceci était la chaîne d'entrée, celà signifie que le paquet vient de `eth0'.
  4. `PROTO=17' signifie que le paquet était de protocole 17. Une liste des numéros de protocoles est donnée dans `/etc/protocols'. Les plus communs sont 1 (ICMP), 6 (TCP) et 17 (UDP).
  5. `192.168.2.1' signifie que l'adresse IP source du paquet était 192.168.2.1.
  6. `:53' signifie que le port source était le port 53. En regardant dans `/etc/services' on voit que ceci est le port `domain' (càd que c'est probablement une réponse DNS). Pour UDP et TCP, ce numéro est le port source. Pour ICMP, c'est le type ICMP. Pour les autres, ce sera 65535.
  7. `192.168.1.1' est l'adresse IP de destination.
  8. `:1025' signifie que le port de destination était 1025. Pour UDP et TCP, ce numéro est le port de destination. Pour ICMP, il s'agit du code ICMP. Pour les autres, ce sera 65535.
  9. `L=34' signifie que le paquet avait une longueur totale de 34 octets.
  10. `S=0x00' est le champ "Type Of Service" (divisez par 4 pour obtenir le Type of Service utilisé par ipchains).
  11. `I=18' est l'identificateur de l'IP.
  12. `F=0x0000' est l'offset du fragment 16 bits, avec les options. Une valeur débutant par `0x4' ou `0x5' signifie que le bit "Don't Fragment" (ne pas fragmenter) est mis. `0x2' ou `0x3' signifie que le bit "More Fragments" (des fragments suivent) est mis ; attendez vous à recevoir plus de fragments après. Le reste du nombre est le décalage de ce fragment, divisé par 8.
  13. `T=254' est la durée de vie du paquet. On soustrait 1 à cette valeur à chaque saut (hop), et on débute généralement à 15 ou 255.
  14. `(#5)' il peut y avoir un numéro entre parenthèses sur les noyaux les plus récents (peut-être après le 2.2.9). Il s'agit du numéro de la règle qui a causé l'enregistrement du paquet.

Sur les systèmes Linux standards, la sortie du noyau est capturée par klogd (démon d'information du noyau) qui le repasse à syslogd (démon d'information du système). Le fichier `/etc/syslog.conf' contrôle le comportement de syslogd, en spécifiant une destination pour chaque "partie" (dans notre cas, la partie est le "noyau") et un "niveau" (pour ipchains, le niveau utilisé est "info").

Par exemple, mon /etc/syslog.conf (Debian) contient deux lignes qui vérifient `kern.info' :

kern.*                          -/var/log/kern.log
*.=info;*.=notice;*.=warn;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none          -/var/log/messages

Ceci signifie que les messages sont dupliqués dans `/var/log/kern.log' et `/var/log/messages'. Pour plus de détails, voyez `man syslog.conf'.

Manipuler le type de service

Il y a quatre bits utilisés par eux-mêmes dans l'entête IP, appelés les bits de Type of Service (TOS). Ceux-ci ont pour effet de modifier la manière dont les paquets sont traités : les quatres bits sont "Minimum Delay", "Maximum Throughput", "Maximum Reliability" et "Minimum Cost". Un seul de ces bits est autorisé à être placé. Rob van Nieuwkerk, l'auteur du code de gestion du TOS, les décrit comme suit :

Tout spécialement, le "Minimum Delay" est important pour moi. Je le mets pour les paquets "interactifs" dans mon routeur principal (Linux). Je suis derrière une connexion modem 33,6k. Linux rend les paquets prioritaires en 3 queues. De cette façon, j'obtiens des performances interactives acceptables tout en faisant de gros transferts de fichiers en même temps. (Celà pourrait même être encore mieux s'il n'y avait pas de grosse queue dans le pilote série, mais le temps de latence est maintenu en dessous des 1,5 secondes pour l'instant).

Note : bien entendu, vous n'avez aucun contrôle sur les paquets arrivants ; vous pouvez seulement contrôler la priorité des paquets qui quittent votre machine. Pour négocier les priorités de chaque côté, un protocole comme RSVP (dont je ne connais rien) doit être utilisé.

L'utilisation la plus commune est de placer les connexions telnet et contrôle du ftp en "Minimum Delay" et les données FTP en "Maximum Throughput". Ceci peut être fait de la manière suivante :

ipchains -A output -p tcp -d 0.0.0.0/0 telnet -t 0x01 0x10
ipchains -A output -p tcp -d 0.0.0.0/0 ftp -t 0x01 0x10
ipchains -A output -p tcp -s 0.0.0.0/0 ftp-data -t 0x01 0x08

L'option "-t" prend deux paramètres supplémentaires, tous les deux en hexadécimal. Ceci permet un contrôle complexe des bits du TOS : le premier masque est ANDé avec le TOS actuel du paquet, et ensuite le deuxième masque est XORé avec lui. Si celà est trop confus, utilisez simplement le tableau suivant :

Nom du TOS              Valeur          Utilisations typiques

Minimum Delay           0x01 0x10       ftp, telnet
Maximum Throughput      0x01 0x08       ftp-data
Maximum Reliability     0x01 0x04       snmp
Minimum Cost            0x01 0x02       nntp

Andi Kleen revient sur ce point pour ce qui suit (modérément édité pour la postérité) :

Peut-être serait-il utile d'ajouter une référence au paramète txqueuelen de ifconfig dans la discussion sur les bits TOS. La longueur par défaut de la queue d'un périphérique est réglée pour les cartes ethernet, sur les modems elle est trop longue et rend le fonctionnement de la planification 3 bandes (qui place la queue en fonction du TOS) sous-optimal. C'est donc une bonne idée de le configurer avec une valeur comprise entre 4 et 10 sur un modem ou un lien RNIS b simple : sur les périphériques rapide une queue plus longue est nécessaire. C'est un problème des 2.0 et 2.1, mais dans le 2.1 c'est une option de ifconfig (dans les nettools récents), alors que dans le 2.0 il nécessite une modification des sources des pilotes du périphérique pour le changer.

Ainsi, pour voir les bénéfices maximum des changements de TOS pour les liaisons modem PPP, ajoutez un `ifconfig $1 txqueuelen' dans votre script /etc/ppp/ip-up. Le nombre à utiliser dépend de la vitesse du modem et de la taille du tampon du modem ; voici à nouveau les idées d'Andi :

La meilleure valeur pour une configuration donnée nécessite de l'expérimentation. Si les queues sont trop courtes sur le routeur, alors les paquets sauteront. Bien sûr, on peut toujours gagner même sans changer le TOS, c'est juste que le changement du TOS aide à gagner les bénéfices sur les programmes non coopératifs (mais tous les programmes Linux standards sont coopératifs).

Marquage d'un paquet

Ceci permet des interactions complexes et puissantes avec la nouvelle implémentation de Quality of Service d'Alexey Kuznetsov, ainsi que de la redirection basée sur le marquage dans la dernière série de noyaux 2.1. Des détails supplémentaires vont arriver puisque nous l'avons dans la main. Cette option est toutefois ignorée dans la série des noyaux 2.0.

Opérations sur une chaîne entière

Une des options les plus utiles d'ipchains est la possibilité de regrouper des règles dans des chaînes. Vous pouvez appeller les chaînes de la manière qui vous plaît, tant que les noms ne sont pas ceux des chaînes intégrées (input, output et forward) ou des destinations ((MASQ, REDIRECT, ACCEPT, DENY, REJECT ou RETURN). Je suggère d'éviter complètement les noms en majuscules, car je pourrais les utiliser pour des extensions futures. Le nom de la chaîne ne doit pas dépasser 8 caractères.

Créer une nouvelle chaîne

Créons une nouvelle chaîne. Étant un type imaginatif, je l'appellerai test.

# ipchains -N test
#

C'est aussi simple. Maintenant vous pouvez y rajouter des règles, comme détaillé ci-dessus.

Supprimer une chaîne

La suppression d'une chaîne est tout aussi simple.

# ipchains -X test
# 

Pourquoi "-X" ? Eh bien, toutes les bonnes lettres étaient déjà prises.

Il y a quelques restrictions à la suppression des chaînes : elles doivent être vides (voir Vider une chaîne plus bas) et elles ne doivent pas être la destination d'une quelconque règle. Vous ne pouvez pas supprimer les chaînes intégrées.

Vider une chaîne

Il y a un moyen simple de vider toutes les règles d'une chaîne, en utilisant la commande "-F".

# ipchains -F forward
# 

Si vous ne spécifiez pas de chaîne, alors toutes les chaînes seront vidées.

Afficher une chaîne

Vous pouvez afficher toutes les règles d'une chaîne en utilisant la commande "-L".

# ipchains -L input
Chain input (refcnt = 1): (policy ACCEPT)
target     prot opt    source                destination           ports
ACCEPT     icmp -----  anywhere              anywhere              any
# ipchains -L test
Chain test (refcnt = 0):
target     prot opt    source                destination           ports
DENY       icmp -----  localnet/24           anywhere              any
#

La "refcnt" listée pour test est le nombre de règles qui ont test comme destination. Ceci doit être égal à zéro (et la chaîne doit être vide) avant que cette chaîne ne puisse être supprimée.

Si le nom de la chaîne est omis, toutes les chaînes sont listées, même les chaînes vides.

Il y a trois options qui peuvent accompagner "-L". L'option "-n" (numérique) est très utile et empêche ipchains d'essayer de vérifier les adresses IP, ce qui (si vous utilisez DNS comme la plupart des gens) causera de longs délais si votre DNS n'est pas configuré proprement, ou si vous filtrez les requêtes DNS. Ceci affichera également les ports par leur numéro plutôt que par leur nom.

L'option "-v" vous montrera tous les détails des règles, comme les compteurs de paquets et d'octets, les masques de TOS, l'interface, et les marques de paquets. Autrement, ces valeurs seront omises. Par exemple :

# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
 pkts bytes target prot opt   tosa tosx ifname  mark  source    destination  ports
   10   840 ACCEPT icmp ----- 0xFF 0x00 lo            anywhere  anywhere     any

Notez que les compteurs de paquets et d'octets sont affichés en utilisant les suffixes "K", "M" ou "G" pour 1000, 1.000.000 et 1.000.000.000, respectivement. En utilisant également l'option "-x" (développe les nombres), ipchains affichera les nombres en entier, quelque soit leur taille.

Remise à zéro des compteurs

Il est parfois utile de pouvoir remettre à zéro les compteurs. Ceci peut être fait par l'option "-Z" (compteurs à Zéro). Par exemple :

# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
 pkts bytes target prot opt   tosa tosx ifname  mark  source    destination  ports
   10   840 ACCEPT icmp ----- 0xFF 0x00 lo            anywhere  anywhere     any
# ipchains -Z input
# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
 pkts bytes target prot opt   tosa tosx ifname  mark  source      destination   ports
    0     0 ACCEPT icmp ----- 0xFF 0x00 lo            anywhere    anywhere      any
#

Le problème de cette approche est que parfois vous voudrez connaître les valeurs du compteur tout de suite après la remise à zéro. Dans l'exemple ci-dessus, quelques paquets peuvent passer entre les commandes "-L" et "-Z". Pour cette raison, vous pouvez utiliser le "-L" et le "-Z" ensemble, pour remettre à zéro les compteurs tout en les lisant. Malheureusement, si vous faîtes ceci, vous ne pouvez opérer sur une seule chaîne : vous devrez lister et remettre à zéro toutes les chaînes en une seule fois.

# ipchains -L -v -Z
Chain input (policy ACCEPT):
 pkts bytes target prot opt   tosa tosx ifname  mark  source      destination   ports
   10   840 ACCEPT icmp ----- 0xFF 0x00 lo            anywhere    anywhere      any

Chain forward (refcnt = 1): (policy ACCEPT)
Chain output (refcnt = 1): (policy ACCEPT)
Chain test (refcnt = 0):
    0     0 DENY   icmp ----- 0xFF 0x00  ppp0         localnet/24 anywhere      any
# ipchains -L -v
Chain input (policy ACCEPT):
 pkts bytes target prot opt   tosa tosx ifname  mark  source      destination   ports
   10   840 ACCEPT icmp ----- 0xFF 0x00 lo            anywhere    anywhere      any

Chain forward (refcnt = 1): (policy ACCEPT)
Chain output (refcnt = 1): (policy ACCEPT)
Chain test (refcnt = 0):
    0     0 DENY   icmp ----- 0xFF 0x00 ppp0          localnet/24 anywhere     any
#

Choisir une police

Nous avons disserté sur ce qui se passe lorsqu'un paquet atteint la fin de la chaîne intégrée, lorsque nous avons discuté sur la manière dont un paquet parcourait les chaînes dans Spécifier une destination plus haut. Dans ce cas, la police de la chaîne détermine le destin du paquet. Seules les chaînes intégrées (input, output et forward) ont des polices, car si un paquet atteint la fin d'une chaîne définie par l'utilisateur, le paquet revient sur la chaîne précédente.

La police peut être une des quatre premières destinations spéciales : ACCEPT, DENY, REJECT ou MASQ. MASQ est la seule destination valide pour la chaîne "forward".

Il est également important de noter qu'une destination RETURN dans une règle de l'une des chaînes intégrées est utile pour expliciter la destination de la chaîne lorsqu'un paquet correspond à la règle.

Opérations sur le camouflage

Il y a plusieurs paramètres que vous pouvez modifier pour le camouflage IP. Ils sont intégrés avec ipchains car il n'est pas évident d'écrire un outil séparé pour eux (bien que ceci devrait changer).

La commande du camouflage IP est "-M", et peut être combinée avec "-L" pour lister les connexions actuellement camouflées, ou avec "-S" pour configurer les paramètres du camouflage.

La commande "-L" peut être accompagnée par "-n" (montre des nombres à la place des noms de machines et de ports) ou "-v" (affiche les deltas dans les séquences de nombres pour la connexion camouflée, au cas où vous vous demanderiez).

La commande "-S" doit être suivie par trois valeurs de fin d'attente, toutes en secondes : pour les sessions TCP, pour les sessions TCP précédées d'un paquet FIN, et pour les paquets UDP. Si vous ne voulez pas changer l'une de ces valeurs, donnez-lui simplement une valeur de "0".

Les valeurs par défaut sont listées dans "/usr/src/linux/include/net/ip_masq.h", actuellement 15 minutes, 2 minutes et 5 minutes, respectivement.

La valeur changée le plus souvent est la première, pour le FTP (voir Cauchemars du FTP plus bas).

Notez que les problèmes avec la mise en place de temps de fin d'attente sont listés dans Je n'arrive pas à configurer mes temps d'attente !.

Vérifier un paquet

Parfois, vous voulez savoir ce qui arrive lorsqu'un certain paquet entre dans votre machine, par exemple pour déboguer votre chaîne pare-feu. ipchains dispose de la commande "-C" pour autoriser celà, en utilisant exactement les mêmes routines que celles que le noyau utilise pour vérifier les vrais paquets.

Vous spécifiez sur quelle chaîne le paquet doit être testé en mettant son nom après l'argument "-C". Même si le noyau commence toujours par traverser les chaînes input, output ou forward, vous êtes autorisé à commencer en traversant n'importe quelle chaîne pour tester.

Les détails du "paquet" sont spécifiés en utilisant la même syntaxe que celle utilisée pour spécifier les règles pare-feu. En particulier, un protocole ("-p"), une adresse source ("-s"), une adresse de destination ("-d") et une interface ("-i") sont nécessaires. Si le protocole est TCP ou UDP, alors une source unique et une destination unique doivent être spécifiées, et un type et un code ICMP doivent être spécifiés pour le protocole ICMP (à moins que l'option "-f" soit spécifiée pour indiquer une règle de fragment, auquel cas ces options sont illégales).

Si le protocole est TCP (et que l'option "-f" n'est pas spécifiée), l'option "-y' doit être explicitée, afin d'indiquer que le paquet test doit être configuré avec le bit SYN.

Voici un exemple de test d'un paquet TCP SYN venant de 192.168.1.1, port 60000, et allant sur 192.168.1.2, port www, arrivant de l'interface eth0 et entrant dans la chaîne "input" (il s'agit d'une initialisation classique d'une connexion WWW) :

# ipchains -C input -p tcp -y -i eth0 -s 192.168.1.1 60000 -d 192.168.1.2 www
packet accepted
# 

Voir ce qui arrive avec des règles multiples précisées en une seule fois

Parfois, une simple ligne de commande peut affecter de multiples règles. Ceci se fait par deux méthodes. Premièrement, si vous spécifiez un nom de machine qui correspond (en utilisant DNS) à de multiples adresses IP, ipchains agira comme si vous aviez tapé de multiples commandes avec chaque combinaison d'adresses.

Ainsi, si le nom de machine "www.foo.com" correspond à trois adresses IP, et si le nom de machine "www.bar.com" correspond à deux adresses IP, alors la commande "ipchains -A input -j reject -s www.bar.com -d www.foo.com" ajoutera six règles à la chaîne input.

L'autre méthode pour avoir ipchains réalisant de multiples actions est d'utiliser l'option bidirectionnelle ("-b"). Cette option fait agir ipchains comme si vous aviez tapé la commande deux fois, la deuxième fois avec les arguments "-s" et "-d" inversés. Ainsi, pour éviter la transmission soit de, soit vers 192.168.1.1, vous pourriez utiliser la commande :

# ipchains -b -A forward -j reject -s 192.168.1.1
# 

Personnellement, je n'aime pas beaucoup l'option "-b" ; si vous préférez la convivialité, voyez Utiliser ipchains-save plus bas.

L'option -b peut être utilisée avec les commandes insérer ("-I"), supprimer ("-D") (mais pas avec la variation qui prend un numéro de règle), ajouter ("-A") et vérifier ("-C").

Une autre option utile est "-v" (bruyant) qui imprime exactement ce que ipchains fait avec vos commandes. Ceci est utile si vous traitez avec des commandes qui peuvent affecter de multiples règles. Par exemple, nous devons ici vérifier le comportement de fragments entre 192.168.1.1 et 192.168.1.2.

# ipchains -v -b -C input -p tcp -f -s 192.168.1.1 -d 192.168.1.2 -i lo
  tcp opt   ---f- tos 0xFF 0x00  via lo    192.168.1.1  -> 192.168.1.2    * ->   *
packet accepted
  tcp opt   ---f- tos 0xFF 0x00  via lo    192.168.1.2  -> 192.168.1.1    * ->   *
packet accepted
# 

4.2 Exemples utiles

J'ai une connexion intermittente en PPP (-i ppp0). Je récupère les news (-p TCP -s news.virtual.net.au nntp) et le courrier (-p TCP -s mail.virtual.net.au pop-3) à chaque fois que je me connecte. J'utilise la méthode ftp de Debian pour mettre ma machine à jour régulièrement (-p TCP -y -s ftp.debian.org.au ftp-data). Je visionne le web au travers du proxy de mon FAI (Fournisseur d'Accès Internet) lorsque je suis en ligne (-p TCP -d proxy.virtual.net.au 8080), mais je déteste les publicités de doubleclick.net des Archives de Dilbert (-p TCP -y -d 199.95.207.0/24 et -p TCP -y -d 199.95.208.0/24).

J'autorise les gens à essayer le ftp sur ma machine lorsque je suis en ligne (-p TCP -d $LOCALIP ftp), mais je n'autorise personne de l'extérieur à prétendre avoir une adresse IP sur mon réseau interne (-s 192.168.1.0/24). Ceci est communément appelé IP spoofing, et il y a un meilleur moyen de se protéger dans les noyaux 2.1.x et suivants : voir Comment mettre en place la protection contre l'IP spoof ?.

Cette configuration est relativement simple, car il n'y a pour l'instant aucune autre machine sur mon réseau interne.

Je ne veux pas que des processus locaux (ie. Netscape, lynx, etc.) se connectent à doubleclick.net :

# ipchains -A output -d 199.95.207.0/24 -j REJECT
# ipchains -A output -d 199.95.208.0/24 -j REJECT
# 

Maintenant je désire changer les priorités des divers paquets sortants (il n'y a pas vraiment d'intérêt à le faire pour les paquets entrants). Puisqu'il y a un certain nombre de ces règles, il y a intérêt à les mettre ensemble dans une seule chaîne, nommée ppp-out.

# ipchains -N ppp-out
# ipchains -A output -i ppp0 -j ppp-out
# 

Délai minimal pour le trafic web et telnet :

# ipchains -A ppp-out -p TCP -d proxy.virtual.net.au 8080 -t 0x01 0x10
# ipchains -A ppp-out -p TCP -d 0.0.0.0 telnet -t 0x01 0x10
# 

Coût faible pour les données ftp, nntp et pop-3 :

# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 ftp-data -t 0x01 0x02
# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 nntp -t 0x01 0x02
# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 pop-3 -t 0x01 0x02
# 

Il y a quelques restrictions sur les paquets venant de l'interface ppp0 ; créons une chaîne nommée "ppp-in" :

# ipchains -N ppp-in
# ipchains -A input -i ppp0 -j ppp-in
# 

Maintenant, aucun des paquets venant de ppp0 ne doit prétendre avoir une adresse source de la forme 192.168.1.*, donc nous les enregistrons et les interdisons :

# ipchains -A ppp-in -s 192.168.1.0/24 -l -j DENY
#

J'autorise l'entrée des paquets UDP pour le DNS (je fais tourner un serveur de nom cache qui renvoie toutes les demandes sur 203.29.16.1, donc je m'attend à des réponses DNS venant uniquement de là), l'entrée du ftp, et le retour des données ftp (ftp-data) uniquement (ce qui doit être uniquement entre un port strictement supérieur à 1023, et pas sur les ports X11 autour de 6000).

# ipchains -A ppp-in -p UDP -s 203.29.16.1 -d $LOCALIP dns -j ACCEPT
# ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 1024:5999 -j ACCEPT
# ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 6010: -j ACCEPT
# ipchains -A ppp-in -p TCP -d $LOCALIP ftp -j ACCEPT
#

Enfin, les paquets local vers local sont OK :

# ipchains -A input -i lo -j ACCEPT
# 

Maintenant, ma police par défaut sur la chaîne input est DENY, ce qui fait que tout le reste disparaît :

# ipchains -P input DENY
# 

NOTE : Je ne configurerais pas mes chaînes dans cet ordre, car des paquets pourraient passer durant la configuration. Le moyen le plus sûr est généralement de configurer la police à DENY tout d'abord, et ensuite d'insérer les règles. Bien sûr, si vos règles ont besoin d'effectuer des demandes DNS pour résoudre des noms de machines, vous pourriez avoir des problèmes.

Utiliser ipchains-save

Configurer des chaînes pare-feu de la manière exacte dont vous le voulez, et se rappeller ensuite des commandes que vous avez utilisé pour le faire la fois suivante est insupportable.

Donc, ipchains-save est un script qui lit votre configuration actuelle des chaînes et la sauve dans un fichier. Pour le moment, je conserverais le suspens en ce qui concerne l'utilité de ipchains-restore.

ipchains-save peut sauver une chaîne seule, ou toutes les chaînes (si aucun nom de chaîne n'a été spécifié). La seule option actuellement autorisée est le "-v" qui affiche les règles (vers stderr) lorsqu'elles sont sauvées. La police de la chaîne est aussi sauvée pour les chaînes input, output et forward.

# ipchains-save > my_firewall
Saving `input'.
Saving `output'.
Saving `forward'.
Saving `ppp-in'.
Saving `ppp-out'.
#

Utiliser ipchains-restore

ipchains-restore remet les chaînes que vous avez sauvé avec ipchains-save. Il peut prendre deux options : "-v" qui décrit chaque règle lorsqu'elle est ajoutée, et "-f" qui force le nettoyage des chaînes définies par l'utilisateur si elles existent, comme décrit plus bas.

Si une chaîne définie par l'utilisateur est trouvée à l'entrée, ipchains-restore vérifie que cette chaîne existe déjà. Si elle existe, alors vous serez interrogé pour savoir si la chaîne doit être nettoyée (suppression de toutes les règles) ou si la restauration de la chaîne doit être sautée. Si vous spécifiez "-f" sur la ligne de commande, vous ne serez pas interrogé ; la chaîne sera nettoyée.

Par exemple :

# ipchains-restore < my_firewall
Restoring `input'.
Restoring `output'.
Restoring `forward'.
Restoring `ppp-in'.
Chain `ppp-in' already exists. Skip or flush? [S/f]? s
Skipping `ppp-in'.
Restoring `ppp-out'.
Chain `ppp-out' already exists. Skip or flush? [S/f]? f
Flushing `ppp-out'.
# 


Page suivante Page précédente Table des matières