IX. Préparatifs▲
Ce chapitre est destiné à vous permettre de démarrer et vous aider à prendre conscience du rôle que Netfilter et iptables jouent aujourd'hui dans Linux. Idéalement, ce chapitre devrait vous conduire à configurer et finaliser l'expérimentation et l'installation de votre pare-feu. Avec du temps et de la persévérance, vous parviendrez à accomplir exactement ce que vous désirez.
IX-A. Obtenir Iptables ?▲
Le paquetage iptables de l'espace utilisateur peut être téléchargé à partir de http://www.netfilter.org/. Le paquetage iptables nécessite des ressources de l'espace du noyau, qui doivent être configurées au sein de celui-ci pendant la phase make configure. Sur ce sujet, les étapes indispensables seront approfondies un peu plus loin dans ce document.
IX-B. Configuration du noyau▲
Pour exécuter les fonctions les plus élémentaires d'iptables, vous devez configurer les options suivantes dans le noyau, pendant la phase make config ou une autre commande apparentée:
CONFIG_PACKET - Cette option autorise les applications et les utilitaires à accéder directement aux périphériques réseau. Ces utilitaires sont par exemple tcpdump ou snort.
Rigoureusement parlant, CONFIG_PACKET n'est pas indispensable pour faire fonctionner iptables, mais puisqu'il est énormément utilisé, j'ai choisi de l'inclure ici. Si vous ne le souhaitez pas, ne l'ajoutez pas.
CONFIG_NETFILTER - Cette option est nécessaire si vous comptez utiliser votre ordinateur en tant que pare-feu ou passerelle vers Internet. En définitive, c'est indispensable pour faire fonctionner tout ce qui se trouve dans ce didacticiel. Je présume que vous le souhaitez, puisque vous lisez ceci.
Bien sûr, vous devez ajouter les pilotes spécifiques à votre interface pour obtenir un fonctionnement correct, i.e. pour les interfaces de type adaptateur Ethernet, PPP ou SLIP. Cette option ajoute seulement quelques-uns des organes élémentaires présents dans iptables. Pour être honnête, vous ne pourrez pas être véritablement productif car ceci n'ajoute qu'une architecture au noyau. Si vous voulez utiliser des options plus évoluées d'iptables, il vous faudra configurer les options adéquates dans votre noyau. Voici celles disponibles pour un simple noyau 2.4.9 accompagnées d'une courte explication:
CONFIG_IP_NF_CONNTRACK - Ce module permet de faire du traçage de connexion. Entre autres, le traçage de connexion est utilisé par le NAT et le camouflage. Si vous voulez protéger les machines d'un LAN derrière un pare-feu, vous devriez à coup sûr sélectionner cette option. Par exemple, ce module est obligatoire pour que le script rc.firewall.txt puisse fonctionner.
CONFIG_IP_NF_FTP - Ce module permet de faire du traçage de connexion sur du FTP. Comme il est habituellement difficile d'effectuer du traçage de connexion sur des connexions FTP, le module conntrack requiert le bien-nommé module d'assistance << helper >>. Et cette option compile justement le module helper.
CONFIG_IP_NF_IPTABLES - Cette option est nécessaire pour effectuer n'importe quel type de filtrage, du camouflage ou du NAT. Elle insère dans le noyau toute l'architecture d'identification d'iptables. Sans cela, vous ne pourrez rien faire avec iptables.
CONFIG_IP_NF_MATCH_LIMIT - Ce module est facultatif, mais il est utilisé dans l'exemple rc.firewall.txt. Cette option fournit la correspondance LIMIT. Elle donne la possibilité de contrôler le nombre de paquets par minute avec lesquels autoriser la correspondance, suivant la définition d'une règle. Par exemple, la commande -m limit --limit 3/minute autorise une correspondance avec un maximum de 3 paquets par minute. Ce module permet aussi d'éviter certaines attaques de type déni de service (DoS).
CONFIG_IP_NF_MATCH_MAC - Ceci permet de faire correspondre des paquets à partir des adresses MAC. Chaque adaptateur Ethernet possède sa propre adresse MAC. Il est possible de bloquer des paquets en identifiant l'adresse MAC utilisée et par conséquent, bloquer efficacement un ordinateur particulier, puisque l'adresse MAC est rarement modifiée. Cette option n'est utilisée ni dans l'exemple rc.firewall.txt, ni ailleurs.
CONFIG_IP_NF_MATCH_MARK - Ceci permet d'utiliser la correspondance MARK. A titre d'exemple, on peut utiliser la cible MARK afin de marquer un paquet, et s'appuyer sur ce marquage plus loin dans la table pour éventuellement établir une correspondance. Cette option est la correspondance MARK, et un peu plus loin sera décrite la cible MARK.
CONFIG_IP_NF_MATCH_MULTIPORT - Ce module permet de faire correspondre des paquets sur un intervalle étendu de ports source ou destination. Normalement, c'est impossible, mais pas avec cette correspondance.
CONFIG_IP_NF_MATCH_TOS - Avec cette correspondance, on peut faire correspondre des paquets à partir du champ TOS qu'ils contiennent. TOS signifie Type de Service (<< Type Of Service >>). Il peut être défini par certaines règles dans la table mangle et grâce aux commandes ip/tc.
CONFIG_IP_NF_MATCH_TCPMSS - Cette option introduit la possibilité de faire correspondre les paquets TCP en fonction de leur champ MSS.
CONFIG_IP_NF_MATCH_STATE - Il s'agit d'une des plus importantes nouveautés vis-à-vis d'ipchains. Ce module permet de faire de la correspondance d'état sur les paquets. Par exemple, si vous avez déjà observé un trafic dans les deux directions sur une connexion TCP, les paquets concernés seront repérés par la mention ESTABLISHED. Ce module est employé de manière intensive dans l'exemple rc.firewall.txt.
CONFIG_IP_NF_MATCH_UNCLEAN - Ce module introduit la possibilité d'établir une correspondance avec les paquets IP, TCP, UDP et ICMP, qui s'avèrent non-conformes à leur spécification ou invalides. Ces paquets pourront être détruits, mais il sera impossible alors de vérifier leur légitimité. Sachez que cette correspondance est encore expérimentale, donc qu'elle peut ne pas fonctionner parfaitement dans toutes les situations.
CONFIG_IP_NF_MATCH_OWNER - Cette option offre la possibilité d'établir une correspondance en se référant au propriétaire d'un connecteur réseau. A titre d'exemple, on peut autoriser l'accès Internet uniquement à l'utilisateur root. Ce module a été écrit à l'origine pour illustrer les possibilités du nouvel outil iptables. Notez que cette correspondance est encore expérimentale, donc qu'elle pourrait ne pas fonctionner pour tout le monde.
CONFIG_IP_NF_FILTER - Ce module ajoute la table fondamentale filter qui permet d'effectuer le moindre filtrage IP. Dans la table filter, on trouve les chaînes INPUT, FORWARD et OUTPUT. Ce module est indispensable si vous envisagez de faire n'importe quel type de filtrage sur des paquets reçus ou envoyés.
CONFIG_IP_NF_TARGET_REJECT - Cette cible permet de spécifier qu'un message d'erreur ICMP doit être expédié en réponse à des paquets entrants, plutôt que de simplement les détruire. Gardez à l'esprit que les connexions TCP, à contrario des connexions ICMP et UDP, sont toujours réinitialisées ou refusées avec un paquet de type TCP RST.
CONFIG_IP_NF_TARGET_MIRROR - Ceci permet de renvoyer des paquets à leur expéditeur. Par exemple, si vous configurez une cible MIRROR sur le port destination HTTP dans votre chaîne INPUT, et que quelqu'un tente d'accéder à ce port, vous lui renverrez ses paquets, et il devrait probablement visualiser au final sa propre page web.
La cible MIRROR n'est pas à utiliser à la légère. Elle a été écrite à l'origine comme un module de test, et il serait sans doute très dangereux de l'utiliser (risque de DoS sérieux entre autre).
CONFIG_IP_NF_NAT - Ce module permet d'effectuer de la traduction d'adresse réseau, ou NAT, dans ses différentes formes. Il vous donne accès à la table nat d'iptables. Cette option est nécessaire pour réaliser de la redirection de port, du camouflage d'adresse IP, etc. Notez que cette option n'est pas indispensable pour installer un pare-feu et camoufler un réseau local, mais elle devrait vous être utile sauf si vous pouvez fournir une adresse IP unique pour chacun des hôtes. Par conséquent, cette option est nécessaire d'une part pour que le script d'exemple rc.firewall.txt puisse fonctionner correctement, et d'autre part pour votre réseau si vous n'êtes pas en mesure d'ajouter des adresses IP uniques.
CONFIG_IP_NF_TARGET_MASQUERADE - Ce module ajoute la cible MASQUERADE. Par exemple, si vous ne connaissez pas l'adresse IP de votre connexion Internet, cette méthode permet de la récupérer en évitant le recours à du DNAT ou du SNAT. En d'autres termes, si vous utilisez DHCP, PPP, SLIP ou un autre moyen de connexion qui attribue lui-même l'adresse IP, vous aurez besoin d'utiliser cette cible plutôt que du SNAT. Le camouflage génère sur la machine une charge légèrement supérieure à du NAT, mais fonctionne sans connaître à l'avance l'adresse IP.
CONFIG_IP_NF_TARGET_REDIRECT - Cette cible est utile associée avec des proxies d'application par exemple. Au lieu de laisser passer un paquet directement, on peut le rediriger vers une machine locale. Autrement dit, on a la possibilité de réaliser un proxy transparent de cette manière.
CONFIG_IP_NF_TARGET_LOG - Ceci ajoute à iptables la cible LOG avec ses fonctionnalités. Ce module peut être employé pour journaliser des paquets dans syslogd, et découvrir ainsi ce qu'il advient d'eux. Cette possibilité se révèle inestimable dans le cas d'audits de sécurité, d'expertises ou pour déboguer un script en cours d'écriture.
CONFIG_IP_NF_TARGET_TCPMSS - Cette option permet de contrecarrer les Fournisseurs d'Accès à Internet (FAI) et les serveurs qui bloquent les paquets ICMP de type Fragmentation nécessaire (<< Fragmentation Needed >>). La conséquence de ceci est que des pages web ne passeront pas, des petits messages sont envoyés mais pas les gros, ssh fonctionne mais scp s'arrête après l'établissement de la liaison (<< handshake >>), etc. Dans cette situation, on peut utiliser la cible TCPMSS pour contourner cette difficulté en limitant le MSS (<< Maximum Segment Size >> ou taille maximum de segment) à la valeur du PMTU (<< Path Maximum Transmit Unit >> ou unité de transfert maximum de liaison). De cette façon, il est possible de surmonter ce que les auteurs de Netfilter appellent eux-mêmes les << FAI ou serveurs à tendance criminelle >> dans l'aide de la configuration du noyau.
CONFIG_IP_NF_COMPAT_IPCHAINS - Ajoute un mode de compatibilité avec l'outil ipchains qui est devenu obsolète. Ne considérez pas ceci comme une solution sérieuse à long terme pour dénouer les problèmes de migration des noyaux Linux 2.2 vers 2.4, puisque ce mode pourrait bien disparaître dans le noyau 2.6.
CONFIG_IP_NF_COMPAT_IPFWADM - Ajoute un mode de compatibilité avec l'outil ipfwadm, qui est également obsolète. Encore une fois, ne considérez pas ceci comme une solution sérieuse à long terme.
Comme vous le constatez, il existe un large éventail d'options. J'ai expliqué brièvement leur intérêt et ce qu'on pouvait attendre de chaque module. Cependant, seules sont décrites ici les options disponibles pour un noyau Linux 2.4.9 standard (saveur << vanilla >>). Si vous souhaitez connaître d'autres options, je vous suggère de vous orienter vers les fonctions de patch-o-matic (POM) présentes dans l'espace utilisateur de Netfilter, qui apportent d'innombrables options supplémentaires. Les correctifs de POM sont des ajouts qu'il est envisagé d'intégrer au noyau à l'avenir, mais ils ne l'ont pas encore atteint. Les raisons sont variées - entre le patch qui n'est pas tout à fait stable, l'impossibilité à Linus Torvalds de le maintenir, ou son refus de l'ajouter à la branche principale de développement du noyau puisqu'il semble encore expérimental.
La liste d'options suivante devra être compilée dans votre noyau, ou ajoutée en tant que modules, pour que le script rc.firewall.txt fonctionne. Si vous avez besoin d'aide pour les options requises par les autres scripts, lisez la section sur les exemples de scripts de pare-feux.
- CONFIG_PACKET
- CONFIG_NETFILTER
- CONFIG_IP_NF_CONNTRACK
- CONFIG_IP_NF_FTP
- CONFIG_IP_NF_IRC
- CONFIG_IP_NF_IPTABLES
- CONFIG_IP_NF_FILTER
- CONFIG_IP_NF_NAT
- CONFIG_IP_NF_MATCH_STATE
- CONFIG_IP_NF_TARGET_LOG
- CONFIG_IP_NF_MATCH_LIMIT
- CONFIG_IP_NF_TARGET_MASQUERADE
Une dernière fois, tout ceci est indispensable pour le script rc.firewall.txt. Pour les autres scripts d'exemple, leurs conditions d'utilisation sont précisées dans leurs sections respectives. Pour l'instant, concentrez-vous sur le script principal que vous devriez déjà être en train d'étudier.
IX-C. Configuration du domaine utilisateur▲
Avant tout, apprenons à compiler le paquetage iptables. Il est important de réaliser que la configuration et la compilation d'iptables sont étroitement liées à celles du noyau. Certaines distributions sont fournies avec le paquetage iptables préinstallé, Red Hat en fait partie. Cependant, sous Red Hat, il est désactivé par défaut. Nous montrerons comment l'activer, et nous verrons d'autres distributions au cours de ce chapitre.
IX-C-1. Compilation des applications▲
Tout d'abord, dépaquetez l'archive d'iptables. Dans le cas présent, le paquetage iptables 1.2.6a est utilisé, ainsi que le noyau 2.4 (vanilla). Dépaquetez le de manière classique, avec la commande bzip2 -cd iptables-1.2.6a.tar.bz2 | tar -xvf - (ou avec tar -xjvf iptables-1.2.6a.tar.bz2, qui devrait aboutir au même résultat ; cependant, ça peut ne pas marcher avec d'anciennes versions de la commande tar). Cette archive doit être dépaquetée dans un répertoire appelé iptables-1.2.6a. N'hésitez pas à lire le fichier iptables-1.2.6a/INSTALL qui contient des informations pertinentes sur la compilation et la préparation à l'exécution du programme.
Ensuite, vous avez la possibilité de configurer et installer les modules et options supplémentaires du noyau. L'étape décrite à présent vérifie et installe les patches standards en attente d'être intégrés au noyau. Il y a d'autres patches encore plus expérimentaux, qui devraient être disponibles seulement après certaines étapes.
Certains de ces patches sont particulièrement expérimentaux et les installer pourrait ne pas être une très bonne idée. Pourtant, il y a une quantité de correspondances et de cibles extrèmement intéressantes lors de cette étape d'installation, donc n'ayez pas peur d'y jeter un oeil.
Pour finaliser cette étape, il suffit d'exécuter ceci à partir de la racine de l'archive d'iptables :
make pending-patches KERNEL_DIR=/usr/src/linux/
La variable KERNEL_DIR devrait pointer sur l'emplacement des sources du noyau. Normalement, il s'agit de /usr/src/linux/, mais ça peut changer et vous connaissez sûrement leur localisation.
On vous interroge seulement sur certains patches qui, de toute façon, sont presque entrés dans le noyau. Il peut y avoir davantage de patches et d'ajouts que les développeurs de Netfilter aimeraient voir ajouter au noyau, mais qui en sont encore un peu éloignés actuellement. Voici une façon de les installer :
make most-of-pom KERNEL_DIR=/usr/src/linux/
La commande précédente vous interroge sur les éléments à installer - ce que l'on appelle patch-o-matic dans le monde de Netfilter, mais éviter les patches les plus extrêmes, qui peuvent causer des ravages dans votre noyau. Observez qu'il est écrit << interroge >>, parce que c'est le comportement actuel de ces commandes. Elles vous interrogent avant de modifier quoi que ce soit dans les sources du noyau. Afin de forcer l'installation de tous les éléments de patch-o-matic, vous devez exécuter la commande suivante :
make patch-o-matic KERNEL_DIR=/usr/src/linux/
N'oubliez pas de lire attentivement l'aide de chaque patch avant de faire quoi que ce soit. Certains patches en détruisent d'autres, alors que d'autres encore détruisent votre noyau si vous les associez avec certains patches de patch-o-matic, etc.
Vous pouvez ignorer complètement les étapes précédentes si vous ne souhaitez pas patcher votre noyau, autrement dit, elles ne sont pas obligatoires. Toutefois, quelques éléments de patch-o-matic sont tellement intéressants qu'ils méritent votre attention, et il n'y a aucun danger à exécuter ces commandes pour visualiser leur contenu.
Après cela, vous en avez fini avec l'installation des éléments de patch-o-matic. Vous pouvez maintenant compiler un nouveau noyau pour vous servir des nouveaux patches que vous avez inclus dans les sources. N'oubliez pas de reconfigurer le noyau puisque les nouveaux patches ne font certainement pas partie des options définies. Vous pouvez procéder à la compilation du noyau après celle du programme iptables de l'espace utilisateur, si ça vous chante.
Poursuivez en compilant l'application iptables. Pour lancer cette compilation, vous entrez une simple commande comme ceci :
make KERNEL_DIR=/usr/src/linux/
L'application du domaine utilisateur devrait se compiler sans difficulté. Si ce n'est pas le cas, vous êtes face à vous-même, ou vous pouvez vous inscrire à la liste de diffusion de Netfilter, où vous avez la chance de pouvoir demander de l'aide sur vos problèmes. Il y a peu de choses qui peuvent mal tourner dans l'installation d'iptables, donc ne paniquez pas si ça ne fonctionne pas. Soyez logique et découvrez ce qui cloche, ou bien trouvez quelqu'un susceptible de vous aider.
Si tout s'est passé en douceur, vous êtes prêt désormais à installer les fichiers binaires. Pour ce faire, vous devez appliquer la commande suivante :
make install KERNEL_DIR=/usr/src/linux/
Soyons optimiste, tout doit maintenant fonctionner parfaitement dans le programme. Pour exploiter toute modification de l'application iptables, vous devez à présent recompiler et réinstaller vos noyau et modules, si ce n'est pas déjà fait. Pour approfondir l'installation des applications à partir des sources, lisez le fichier INSTALL qui accompagne les sources et contient d'excellentes informations sur le sujet.
IX-C-2. Installation sur Red Hat 7.1▲
Red Hat 7.1 est fournie avec un noyau 2.4.x précompilé avec Netfilter et iptables. Il contient aussi tous les programmes élémentaires du domaine utilisateur et les fichiers de configuration exigés pour l'exécution. Cependant, l'équipe de Red Hat a désactivé la totalité en optant pour la rétrocompatibilité avec le module ipchains. Ennuyé de répéter la même chose, et comme nombre de gens continuent à demander sur différentes listes de diffusion pourquoi iptables ne marche pas, abordons rapidement comment désactiver le module d'ipchains pour le remplacer par iptables.
L'installation par défaut de Red Hat 7.1 donne malheureusement une vieille version des applications de l'espace utilisateur. De fait, vous désirerez certainement compiler une nouvelle version des applications, associée à un noyau récent et personnalisé avant d'exploiter complètement iptables.
En premier lieu, il faut arrêter le module ipchains de telle sorte qu'il ne démarre plus à l'avenir. Pour cela, quelques noms de fichiers doivent être changés dans l'arborescence /etc/rc.d/. La commande suivante devrait suffire :
chkconfig --level 0123456 ipchains offAvec ceci, tous les liens symboliques qui pointent vers le script /etc/rc.d/init.d/ipchains sont déplacés vers K92ipchains. La première lettre, S par défaut, indique de lancer le script de démarrage (<< initscript >>) correspondant. La conversion du S en K stipule d'interrompre (<< Kill >>) le service, ou de ne pas exécuter le script si le service n'a pas déjà démarré. Dorénavant, le script ne démarrera plus.
D'autre part, pour arrêter dès maintenant le service en cours d'exécution, il est nécessaire de lancer une autre commande. Il s'agit de la commande service qui permet de manipuler des services en cours d'exécution. Ainsi, pour stopper le service ipchains, il suffit de faire :
service ipchains stopMaintenant, il reste à démarrer le service iptables. Tout d'abord, il faut connaître les niveaux d'exécution (<< run-levels >>) où l'on veut positionner ce service. Normalement, ça devrait être les niveaux 2, 3 et 5. Ils servent aux choses suivantes :
- 2. Multi-utilisateur sans NFS ou identique à 3 en l'absence de réseau.
- 3. Mode multi-utilisateur intégral, c.-à-d. le niveau d'exécution normal à lancer
- 5. X11. Utilisé si vous démarrez automatiquement sous Xwindow.
On impose de lancer iptables dans ces niveaux d'exécution avec la commande :
chkconfig --level 235 iptables onLa commande ci-dessus permet de lancer le service iptables dans les niveaux d'exécution 2, 3 et 5. Si vous désirez qu'il en soit autrement, modifiez la commande en conséquence. Toutefois, aucun des autres niveaux d'exécution ne devrait être sélectionné, donc vous n'avez pas besoin d'activer iptables pour ces niveaux-là. Le niveau 1 concerne le mode un seul utilisateur, c-à-d. quand vous devez réparer une machine dysfonctionnante. Le niveau 4 devrait être inutilisé, et le niveau 6 est réservé à l'extinction de l'ordinateur.
Pour activer le service iptables, lancez simplement la commande :
service iptables startnitialement, il n'y a aucune règle dans le script iptables. Pour ajouter des règles sur une Red Hat 7.1, il existe deux méthodes. Premièrement, vous pouvez éditer le script /etc/rc.d/init.d/iptables. Cette approche a un désagréable inconvénient, celui de voir toutes ses règles effacées si vous mettez à jour le paquetage iptables par RPM. La deuxième méthode consiste à charger le livre de règles, puis à le sauvegarder par le biais de la commande iptables-save, et enfin à automatiser son chargement au démarrage avec les scripts de rc.d.
Tout d'abord, sera décrite la configuration d'iptables avec des manipulations de copier/coller dans le script iptables du répertoire init.d. Pour ajouter des règles qui seront appliquées au démarrage du service, vous pouvez les insérer soit derrière la section "start)", soit à l'intérieur de la fonction "start()". Si vous choisissez la section "start)", vous devez penser à empêcher l'exécution de la fonction "start()" dans cette section. A propos, songez également à éditer la section "stop)" pour préciser au script les actions à entreprendre soit lorsqu'on éteint l'ordinateur, soit lorsqu'on active un niveau d'exécution qui ne nécessite pas iptables. Par la même occasion, n'oubliez pas de vérifier les sections "restart" et "condrestart". Sachez que tout votre travail sera sûrement effacé si vous avez opté pour "Red Hat Network" qui met à jour automatiquement vos paquetages. Ce sera aussi le cas avec une mise à jour du paquetage RPM iptables.
La seconde méthode de configuration est décrite ici. En premier lieu, créez un livre de règles qui répond à votre besoin, et écrivez-le dans un fichier de script shell ou utilisez-le directement avec iptables, mais n'oubliez pas de l'expérimenter. Lorsque vous trouvez une configuration qui fonctionne sans problème et sans faille, utilisez la commande iptables-save. Typiquement, vous pouvez faire iptables-save > /etc/sysconfig/iptables, pour sauvegarder le livre de règles dans le fichier /etc/sysconfig/iptables. Ce fichier est lu automatiquement par le script iptables de rc.d pour restituer le livre de règles à la demande. Une autre possibilité est de sauvegarder le script en exécutant service iptables save, qui sauvegarde automatiquement vers le fichier /etc/sysconfig/iptables. Au prochain démarrage de votre ordinateur, le script iptables de rc.d fera appel à la commande iptables-restore pour restituer le livre de règles à partir du fichier sauvegardé /etc/sysconfig/iptables. Ne mélangez pas ces deux méthodes, susceptibles de se nuire mutuellement et rendre votre pare-feu inopérant.
Une fois toutes ces étapes achevées, vous pouvez désinstaller les paquetages ipchains et iptables. En effet, ceci permet d'éviter au système tout risque de confusion entre l'application iptables préinstallée et l'application iptables de l'espace utilisateur. Cette étape n'est utile que si vous installez iptables à partir des fichiers sources. Il n'y a rien d'inhabituel à voir le nouveau et l'ancien paquetage se mélanger, puisque l'installation à partir de rpm positionne les fichiers à des emplacements non standards qui ne seront pas écrasés par l'installation du nouveau paquetage iptables. Pour procéder à la désinstallation, exécutez ceci :
rpm -e iptablesD'ailleurs, pourquoi conserver également ipchains s'il n'a plus d'utilité ? Supprimez-le de la même manière que les vieux fichiers binaires d'iptables avec la commande :
rpm -e ipchainsFinalement, vous avez terminé la mise à jour du paquetage d'iptables à partir des sources, en suivant les instructions d'installation. Maintenant, plus un seul fichier binaire, de bibliothèque ou de directive d'inclusion ne devrait résider sur le système.