Configuration du domaine utilisateur

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.

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 off

Avec 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 stop

Maintenant, 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 on

La 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 start

Initialement, 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 iptables

D'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 ipchains

Finalement, 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.