Ceci est le Linux IPCHAINS-HOWTO ; voyez la section O� ? pour le site principal, qui d�tient la derni�re version. Vous devriez �galement lire le Linux NET-3-HOWTO. Les howtos IP-Masquerading, PPP-HOWTO, l'Ethernet-HOWTO et le Firewall HOWTO peuvent aussi �tre int�ressants � lire (une fois de plus, la FAQ de alt.fan.bigfoot peut l'�tre aussi).
Si le filtrage des paquets vous semble d�pass�, lisez la section Pourquoi ?, la section Comment ?, et lisez les titres de la section Cha�nes de protection IP.
Si vous vous adaptez en partant d'ipfwadm, lisez la section
Introduction, la section
Comment ?, et les annexes des sections
Diff�rences entre ipchains et ipfwadm et
Utiliser le script `ipfwadm-wrapper'.
Le Linux ipchains est une r��criture du code de firewalling de l'IPv4
de Linux (qui avait �t� principalement emprunt� � BSD) et une r��criture
d'ipfwadm, lui m�me r��criture d'ipfw de BSD, je crois. Il est
n�cessaire pour administrer le filtrage des paquets IP dans les noyaux Linux
� partir de la version 2.1.102.
L'ancien code de firewalling de Linux ne pouvait g�rer les fragments, utilisait des compteurs 32 bits (au moins sur Intel), ne permettait pas la sp�cification de protocoles autres que TCP, UDP ou ICMP, ne pouvait faire de grands changements atomiquement, ne permettait pas la sp�cification de r�gles inverses, avait quelques bizarreries, et pouvait �tre une catastrophe � g�rer (le rendant propice aux erreurs des utilisateurs).
Actuellement le code se trouve dans le noyau principal � partir du 2.1.102. Pour la s�rie des noyaux 2.0, vous devrez r�cup�rer une correction pour le noyau sur une page web. Si votre noyau 2.0 est plus r�cent que la correction r�cup�r�e, la correction ancienne devrait fonctionner ; cette partie des noyaux 2.0 est relativement stable (la correction pour le noyau 2.0.34 fonctionne bien sur le noyau 2.0.35). Cependant, le correctif 2.0 est incompatible avec les correctifs pour l'ipportfw et l'ipautofw, je recommande donc de ne pas l'appliquer, � moins que vous n'ayez r�ellement besoin de l'une des fonctionnalit�s offertes par ipchains.
La page officielle est la Page des cha�nes de filtrage IP de Linux.
Il y a une liste de diffusion pour les rapports d'erreurs, les discussions, le d�veloppement et l'utilisation. Vous pouvez rejoindre la liste de diffusion en envoyant un message contenant le mot ``subscribe'' � ipchains-request de rustcorp.com. Pour �crire � la liste utilisez `ipchains' � la place de `ipchains-request'.
Tout le trafic circulant dans un r�seau est envoy� sous la forme de paquets. Par exemple, pour charger ce paquetage (disons qu'il fait 50k) vous avez d� recevoir plus ou moins 36 paquets de 1460 octets chacun (pour prendre des valeurs au hasard).
Le d�but de chaque paquet pr�cise o� celui-ci va, d'o� il vient, le type du paquet, et divers autres d�tails administratifs. Le d�but de chaque paquet est appel� l'ent�te. Le reste du paquet, contenant les donn�es � transmettre, est couramment appel� le corps.
Quelques protocoles, comme le TCP, qui est utilis� pour le trafic web, mail et les connexions � distance, utilisent le concept de `connexion' -- avant que le moindre paquet de donn�es ne soit envoy�, divers paquets de configuration (avec des ent�tes sp�ciales) sont �chang�s en disant `je veux me connecter', `OK' et `Merci'. Ensuite les paquets normaux sont �chang�s.
Un filtre de paquet est un logiciel qui regarde l'ent�te des paquets lorsque ceux-ci passent, et d�cide du destin du paquet entier. Il peut d�cider de le refuser (le supprimer comme s'il n'avait jamais �t� re�u), de l'accepter (le laisser circuler) ou de le rejeter (effet identique au refus, mais il est pr�cis� � la source que le paquet n'a pas �t� accept�).
Sous Linux, le filtrage des paquets est inclus dans le noyau, et il y a diverses choses que nous pouvons faire avec les paquets, mais le principe g�n�ral (regarder les ent�tes et d�cider du destin du paquet) est toujours pr�sent.
Contr�le. S�curit�. Vigilance.
Lorsque vous utilisez un ordinateur sous Linux pour connecter votre r�seau interne � un autre r�seau (disons, l'Internet) vous aurez l'opportunit� de permettre certains types de trafics, et d'interdire les autres. Par exemple, l'ent�te d'un paquet contient l'adresse de destination du paquet, et vous pouvez ainsi �viter que des paquets aillent vers un certain endroit du r�seau ext�rieur. Comme autre exemple, j'utilise Netscape pour acc�der aux archives de Dilbert. Il y a des publicit�s provenant de doubleclick.net sur la page, et Netscape perd du temps en les chargeant gentiment. Dire au filtre des paquets de ne pas autoriser la circulation de paquets provenant ou allant vers doubleclick.net r�soud le probl�me (il y a cependant de meilleurs moyens pour y parvenir).
Lorsque votre machine Linux est le seul rempart entre le chaos de l'Internet et votre r�seau propre et bien ordonn�, il est utile de savoir que vous pouvez restreindre ce qui vient sonner � votre porte. Par exemple, vous pouvez autoriser tout ce qui sort de votre r�seau, mais vous pouvez vous inqui�ter du fort connu 'Ping of Death' pouvant provenir d'intrus ext�rieurs. Comme autre exemple, vous pouvez interdire aux personnes ext�rieures de se connecter en telnet sur votre machine Linux, m�me si tous vos comptes ont des mots de passe ; peut-�tre d�sirerez-vous (comme la plupart des gens) �tre un simple observateur sur l'Internet, et non un serveur (de bonne volont� ou non) -- simplement en ne laissant personne se connecter, le filtrage de paquets rejetant tous les paquets entrants utilis�s pour cr�er des connexions.
Parfois, une machine mal configur�e du r�seau local d�cidera d'envoyer des paquets au monde ext�rieur. Il est sympathique de pouvoir sp�cifier au filtre de paquets de vous informer si quelque chose d'anormal se produit ; vous pourrez �ventuellement y faire quelque chose, ou bien laisser libre cours � la simple curiosit�.
Vous aurez besoin d'un noyau disposant du nouveau code de cha�nes de protection IP. Vous pouvez savoir si le noyau que vous utilisez actuellement en dispose en cherchant le fichier `/proc/net/ip_fwchains'. Si ce fichier existe, alors c'est tout bon.
Sinon, vous devez cr�er un noyau contenant le code de cha�nes de protection IP. Tout d'abord, r�cup�rez les sources du noyau que vous d�sirez. Si vous avez un noyau dont le num�ro est sup�rieur ou �gal � 2.1.102, vous n'aurez pas besoin de le corriger (il se trouve d�j� inclus dans le noyau). Autrement, appliquez le correctif que vous trouverez sur la page web list�e plus haut, et utilisez la configuration d�taill�e ci-dessous. Si vous ne savez pas comment le faire, ne paniquez pas -- lisez le Kernel-HOWTO.
Les options de configuration que vous devez utiliser pour les noyaux de s�rie 2.0 sont :
CONFIG_EXPERIMENTAL=y
CONFIG_FIREWALL=y
CONFIG_IP_FIREWALL=y
CONFIG_IP_FIREWALL_CHAINS=y
Pour les s�ries de noyaux 2.1 ou 2.2 :
CONFIG_FIREWALL=y
CONFIG_IP_FIREWALL=y
L'outil ipchains parle au noyau et lui dit quels paquets filtrer.
À moins que vous ne soyez un programmeur, ou un curieux inv�t�r�, c'est
ainsi que vous contr�lerez le filtrage des paquets.
L'outil ipchains ins�re et efface des r�gles dans la section
de filtrage de paquets du noyau. Ce qui signifie que quoi que vous
configuriez, tout sera perdu lors d'un red�marrage ; voyez la section
Rendre les r�gles permanentes pour savoir comment
s'assurer que les r�gles seront restaur�es au prochain lancement de Linux.
ipchains remplace ipfwadm, qui �tait utilis� par l'ancien
code pare-feu. Il y a un ensemble de scripts utiles disponibles sur le site
ftp d'ipchains :
ftp://ftp.rustcorp.com/ipchains/ipchains-scripts-1.1.2.tar.gz
Cette archive contient un script shell appell� ipfwadm-wrapper qui
vous autorisera � utiliser le filtrage de paquets comme avant. Vous ne devriez
probablement pas utiliser ce script � moins que vous ne souhaitiez un moyen
rapide de mettre � jour un syst�me utilisant ipfwadm (ce script est
plus lent, ne v�rifie pas les arguments, etc.). Dans ce cas, vous n'avez pas
non plus besoin de ce howto.
Voyez l'annexe
Diff�rences entre ipchains et ipfwadm et l'annexe
Utiliser le script `ipfwadm-wrapper' pour des d�tails suppl�mentaires concernant
ipfwadm.
Votre configuration actuelle de pare-feu est sauv�e dans le noyau, et sera ainsi perdue lors d'un red�marrage. Je vous recommande d'utiliser les scripts `ipchains-save' et `ipchains-restore' pour rendre vos r�gles permanentes. Pour ce faire, configurez vos r�gles, puis utilisez (en tant que super-utilisateur) :
# ipchains-save > /etc/ipchains.rules
#
Cr�ez un script comme le suivant :
#! /bin/sh
# Script to control packet filtering.
# If no rules, do nothing.
[ -f /etc/ipchains.rules ] || exit 0
case "$1" in
start)
echo -n "Turning on packet filtering:"
/sbin/ipchains-restore < /etc/ipchains.rules || exit 1
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "."
;;
stop)
echo -n "Turning off packet filtering:"
echo 0 > /proc/sys/net/ipv4/ip_forward
/sbin/ipchains -X
/sbin/ipchains -F
/sbin/ipchains -P input ACCEPT
/sbin/ipchains -P output ACCEPT
/sbin/ipchains -P forward ACCEPT
echo "."
;;
*)
echo "Usage: /etc/init.d/packetfilter {start|stop}"
exit 1
;;
esac
exit 0
Assurez vous que ceci est lanc� suffisamment t�t dans la proc�dure de lancement. Dans mon cas (Debian 2.1), j'ai cr�� un lien symbolique appell� `S39packetfilter' dans le r�pertoire `/etc/rcS.d' (il sera ainsi lanc� avant S40network).
Ce HOWTO a pour sujet le filtrage de paquets. Ce filtrage permet la prise de d�cision concernant le destin d'un paquet : s'il est autoris� � passer ou non. Cependant, Linux �tant le joujou pour bidouilleurs qu'il est, vous voudriez probablement en savoir un peu plus.
Un des probl�mes est que le m�me outil ("ipchains") est utilis� pour contr�ler � la fois le camouflage et le cache transparent, alors que ce sont des notions s�par�es du filtrage de paquets (l'impl�mentation actuelle de Linux les brouille tous les trois de fa�on inhabituelle, laissant l'impression qu'ils sont tr�s proches).
Le camouflage et le cachage sont recouverts par des HOWTOs s�par�s, et les possibilit�s de redirection automatique et de redirection de ports sont contr�l�es par des outils s�par�s, mais puisque de nombreuses personnes continuent � me harceler � leur propos, je vais ajouter un ensemble de sc�narios classiques en indiquant les moments o� chacun doit �tre utilis�. Les m�rites de la s�curit� de chacun de ces sc�narios ne seront n�anmoins pas discut�s ici.
Ces lignes pr�sument que votre interface externe est appell�e "ppp0". Utilisez ifconfig pour le v�rifier, et ajustez selon votre go�t.
# ipchains -P forward DENY
# ipchains -A forward -i ppp0 -j MASQ
# echo 1 > /proc/sys/net/ipv4/ip_forward
Vous pouvez acheter des pare-feu tout faits. Un excellent est le FireBox de WatchGuard. C'est excellent parce que je l'appr�cie, parce qu'il est s�curis�, bas� sur Linux, et parce qu'ils financent la maintenance d'ipchains ainsi que du nouveau code pare-feu (pr�vu pour le 2.3). En bref, WatchGuard me paye � manger lorsque je travaille pour vous. Donc, je vous prierai de prendre leur travail en compte.
Vous �tes petiteboite.com. Vous avez un r�seau interne, et une connexion intermittente (PPP) simple � l'Internet (firewall.petiteboite.com a pour IP 1.2.3.4). Vous �tes en Ethernet sur votre r�seau local, et votre machine personnelle s'appelle "mamachine".
Cette section illustrera les diff�rents arrangements classiques. Lisez attentivement, car ils sont tous subtilement diff�rents.
Dans ce sc�nario, les paquets venant d'un r�seau priv� ne traversent jamais l'Internet, et vice versa. Les adresses IP du r�seau priv� doivent �tre assign�es en utilisant les adresses priv�es r�serv�es par la RFC 1597 (c�d 10.*.*.*, 172.16.*.* ou 192.168.*.*).
La seule m�thode pour que les choses soient connect�s � l'Internet est en se connectant au pare-feu, qui est la seule machine sur les deux r�seaux qui sont connect�s plus loin. Vous lancez un programme (sur le pare-feu) appell� un proxy pour ce faire (il y a des proxy (caches) pour le FTP, l'acc�s web, telnet, RealAudio, les News Usenet et autres services). Voyez le Firewall HOWTO.
Tous les services auxquels vous voulez que l'Internet puisse avoir acc�s doivent �tre sur le pare-feu (mais voyez Services internes limit�s plus bas).
Exemple : autoriser l'acc�s web d'un r�seau priv� vers l'Internet.
Netscape sur mamachine lit http://slashdot.org.
C'est-�-dire que du point de vue de slashdot.org, la connexion est r�alis�e par 1.2.3.4 (interface PPP du pare-feu), port 1025, vers 207.218.152.131 (slashdot.org) port 80. Du point de vue de mamachine, la connexion est faite de 192.168.1.100 (mamachine) port 1050, vers 192.168.1.1 (interface Ethernet du pare-feu), port 8080.
Dans ce sc�nario, les paquets venant du r�seau priv� ne traversent jamais l'Internet, et vice versa. Les adresses IP du r�seau priv� doivent �tre assign�es en utilisant les adresses priv�es r�serv�es par la RFC 1597 (c�d 10.*.*.*, 172.16.*.* ou 192.168.*.*).
La seule m�thode pour que les choses soient connect�es � l'Internet est en se connectant au pare-feu, qui est la seule machine sur les deux r�seaux, qui sont connect�s plus loin. Vous lancez un programme (sur le pare-feu) appell� un cache transparent pour ce faire ; le noyau envoie les paquets sortants au cache transparent au lieu de les envoyer plus loin (c�d qu'il rend b�tard le routage).
Le cachage transparent signifie que les clients n'ont pas besoin de savoir qu'il y a un proxy dans l'histoire.
Tous les services que l'Internet peut utiliser doivent �tre sur le pare-feu (mais voyez Services internes limit�s plus bas).
Exemple : autoriser l'acc�s web du r�seau priv� vers l'Internet.
Netscape sur mamachine lit http://slashdot.org.
C'est � dire que du point de vue de slashdot.org, la connexion est r�alis�e par 1.2.3.4 (interface PPP du pare-feu) port 1025 vers 207.218.152.131 (slashdot.org) port 80. Du point de vue de mamachine, la connexion est faite � partir de 192.168.1.100 (mamachine) port 1050, vers 207.218.152.131(slashdot.org) port 80, mais il parle en fait au proxy transparent.
Dans ce sc�nario, les paquets venant du r�seau priv� ne traversent jamais l'Internet sans traitement sp�cial, et vice versa. Les adresses IP du r�seau priv� doivent �tre assign�es en utilisant les adresses priv�es r�serv�es par la RFC 1597 (c�d 10.*.*.*, 172.16.*.* ou 192.168.*.*).
Au lieu d'utiliser un cache, nous utilisons une sp�cificit� sp�ciale du noyau nomm�e "camouflage" (masquerading). Le camouflage r��crit les paquets lorsqu'ils passent par le pare-feu, ce qui fait qu'ils semblent toujours venir du pare-feu lui-m�me. Il r��crit ensuite les r�ponses afin qu'elles semblent venir du destinataire originel.
Le camouflage dispose de modules s�par�s afin de g�rer les protocoles "�tranges", comme FTP, RealAudio, Quake, etc. Pour les protocoles vraiment difficiles � g�rer, la sp�cificit� de "redirection automatique" (auto forwarding) peut en g�rer quelques-uns en configurant automatiquement la redirection de ports pour un ensemble donn� de ports : voyez "ipportfw" (noyaux 2.0) ou "ipmasqadm" (noyaux 2.1 et sup�rieurs).
Tous les services auxquels vous voulez que l'Internet puisse avoir acc�s doivent �tre sur le pare-feu (mais voyez Services internes limit�s plus bas).
Exemple : autoriser l'acc�s web du r�seau priv� sur l'Internet.
Netscape sur mamachine lit http://slashdot.org.
C'est � dire que du point de vue de slashdot.org, la connexion est r�alis�e de 1.2.3.4 (interface PPP du pare-feu), port 65000 vers 207.218.152.131 (slashdot.org) port 80. Du point de vue de mamachine, la connexion est faite entre 192.168.1.100 (mamachine) port 1050, et 207.218.152.131 (slashdot.org) port 80.
Dans ce sc�nario, votre r�seau personnel fait partie de l'Internet : les paquets peuvent passer sans avoir � changer de r�seau. Les adresses IP du r�seau interne doivent �tre assign�es en utilisant un bloc d'adresses IP, de mani�re � ce que le reste du r�seau sache comment vous envoyer des paquets. Ceci implique une connexion permanente.
Dans ce r�le, le filtrage de paquets est utilis� pour restreindre les paquets qui peuvent �tre redirig�s entre votre r�seau et le reste de l'Internet, c�d pour restreindre le reste de l'Internet � acc�der uniquement au serveur web qui se trouve en interne.
Exemple : autoriser l'acc�s web du r�seau priv� vers l'Internet.
Netscape sur mamachine lit http://slashdot.org.
C'est � dire qu'il n'y a qu'une seule connexion : � partir de 1.2.3.100 (mamachine) port 1050, vers 207.218.152.131 (slashdot.org) port 80.
Il y a quelques trucs que vous pouvez utiliser pour autoriser l'Internet � acc�der � vos services internes, plut�t que de faire tourner vos services internes sur le pare-feu. Ils fonctionneront soit avec un proxy, soit avec une approche type camouflage pour les connexions externes.
L'approche la plus simple est de faire tourner un "redirecteur", qui est un cache de pauvre, attendant une connexion sur un port donn�, et ouvrant une connexion sur un h�te et un port interne fix�, et copiant les donn�es entre les deux connexions. Un exemple de ceci est le programme "redir". Du point de vue de l'Internet, la connexion est faite sur votre pare-feu. Du point de vue de votre serveur interne, la connexion est faite par l'interface interne du pare-feu sur le serveur.
Une autre approche (qui n�cessite un noyau 2.0 corrig� pour ipportfw, ou un noyau 2.1 ou sup�rieur) est d'utiliser la redirection des ports du noyau. Il effectue le m�me travail que "redir" d'une mani�re diff�rente : le noyau r��crit les paquets lorsqu'ils passent, en changeant leur adresse de destination et le port pour les faire pointer sur un port et un h�te interne. Du point de vue de l'Internet, la connexion est faite sur votre pare-feu. Du point de vue de votre serveur interne, une connexion directe est r�alis�e entre l'h�te Internet et votre serveur.
David Ranch a �crit un excellent howto tout neuf sur le camouflage, qui en grande partie recouvre ce howto. Vous pouvez le trouver sur http://www.ecst.csuchico.edu/~dranch/LINUX/index-LINUX.html
J'esp�re pouvoir bient�t le trouver h�berg� sous les auspices du LDP (Linux Documentation Project), sur http://www.metalab.unc.edu/LDP.
La page officielle du camouflage se trouve sur http://ipmasq.cjb.net.
Cette section d�crit tout ce que vous avez r�ellement besoin de savoir pour construire un filtre de paquets adapt� � vos besoins.
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 :
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�.
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).
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.
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.
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).
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).
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.
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.
Cette cha�ne est travers�e par tout paquet qui tente de passer par cette machine vers une autre.
Cette cha�ne est travers�e par tous les paquets juste avant qu'ils ne soient envoy�s � l'ext�rieur.
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.
Il y a plusieurs moyens pour manipuler les r�gles � l'int�rieur d'une cha�ne :
Il y a quelques op�rations pour le masquage, qui se trouvent dans
ipchains dans l'attente d'un bon endroit pour les mettre :
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.
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
#
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
#
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.
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".
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.
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".
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
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).
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).
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.
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
#
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 :
Pour la diversit�, je d�taillerai ceux-ci en ordre d'importance.
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.
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 :
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'.
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).
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.
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�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.
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.
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.
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.
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
#
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.
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 !.
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
#
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
#
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.
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'.
#
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'.
#
Cette section contient toutes les informations et les questions fr�quemment pos�es que je ne pouvais faire entrer dans la structure ci-dessus.
Cette question n�cessite un peu de r�flexion. Vous pouvez tenter de les organiser pour optimiser la vitesse (minimiser le nombre de v�rifications de r�gles pour la plupart des paquets) ou pour augmenter la maniabilit�.
Si vous avez une connexion intermittente, disons une connexion PPP, vous
pouvez configurer la premi�re r�gle de la cha�ne d'entr�e pour �tre `-i ppp0
-j DENY' au lancement, puis avoir quelque chose comme ceci dans votre script
ip-up :
# Re-cr�e la cha�ne "ppp-in"
ipchains-restore -f < ppp-in.firewall
# Remplace la r�gle DENY par un saut vers la cha�ne se chargeant du ppp
ipchains -R input 1 -i ppp0 -j ppp-in
Votre script ip-down pourrait ressembler � �a :
ipchains -R input 1 -i ppp0 -j DENY
Il y a un certain nombre de choses auxquelles vous devez faire attention avant de commencer � filtrer quelque chose que vous n'auriez pas voulu filtrer.
Les paquets ICMP sont utilis�s (entre autres choses) pour indiquer des probl�mes aux autres protocoles (comme TCP et UDP). Les paquets "destination-unreachable" (destination non accessible) en particulier. Le bloquage de ces paquets signifie que vous n'obtiendrez jamais les erreurs "Host unreachable" ou "No route to host" ; toute connexion attendra une r�ponse qui ne viendra jamais. C'est irritant, mais rarement fatal.
Un probl�me plus inqui�tant est le r�le des paquets ICMP dans la d�couverte MTU. Toutes les bonnes impl�mentations de TCP (y compris celle de Linux) utilisent la recherche MTU pour tenter de trouver quel est le plus grand paquet qui peut atteindre une destination sans �tre fragment� (la fragmentation diminue les performances, principalement lorsque des fragments occasionnels sont perdus). La recherche MTU fonctionne en envoyant des paquets avec le bit "Don't Fragment" mis, et en envoyant ensuite des paquets plus petits s'il re�oit un paquet ICMP indiquant "Fragmentation needed but DF set" (`fragmentation-needed'). C'est un paquet de type "destination-unreachable", et s'il n'est jamais re�u, l'h�te local ne r�duira pas le MTU, et les performances seront abyssales ou inexistantes.
Notez qu'il est commun de bloquer tous les messages ICMP de redirection (type 5) ; ils peuvent �tre utilis�s pour manipuler le routage (bien que les piles IP bien con�ues disposent de gardes-fou), et sont donc souvent consid�r�s comme quelques peu risqu�s.
Si vous tentez de bloquer toutes les connexions TCP sortantes, rappellez vous que le DNS n'utilise pas toujours UDP ; si la r�ponse du serveur d�passe les 512 octets, le client utilise une connexion TCP (allant toujours sur le port num�ro 53) pour obtenir les donn�es.
Ceci peut �tre un pi�ge car le DNS fonctionnera "en gros" si vous interdisez de tels transferts TCP ; vous pouvez exp�rimenter des d�lais longs et �tranges, et d'autres probl�mes li�s au DNS si vous le faites.
Si les demandes de votre DNS sont toujours dirig�es vers les m�mes sources
externes (soit directement en utilisant la ligne nameserver dans
/etc/resolv.conf ou en utilisant un serveur de noms cache en mode de
redirection), alors vous n'aurez besoin d'autoriser que les connexions du
port domain sur ce serveur de nom � partir du port local domain
(si vous utilisez un serveur de nom cache) ou d'un port �lev� (> 1023) si
vous utilisez /etc/resolv.conf.
L'autre probl�me classique du filtrage de paquets est celui pos� par le FTP. Le FTP a deux modes ; le mode traditionnel est appel� mode actif et le plus r�cent est appel� mode passif. Les navigateurs web utilisent souvent le mode passif par d�faut, mais les programmes de ftp en ligne de commmande utilisent en g�n�ral par d�faut le mode actif.
En mode actif, lorsque l'h�te distant d�sire envoyer un fichier (ou m�me les
r�sultats d'une commande ls ou dir), il essaye d'ouvrir une
connexion TCP sur la machine locale. Cel� signifie que vous ne pouvez filtrez
ces connexions TCP sans supprimer le FTP actif.
Si vous avez comme option l'utilisation du mode passif, alors tout va bien ; le mode passif fait passer les connexions de donn�es du client au serveur, m�me pour les donn�es arrivantes. Autrement, il est recommend� de n'autoriser que les connexions TCP vers les ports sup�rieurs � 1024 et de les interdire entre 6000 et 6010 (6000 est utilis� par X-Windows).
Les machines Linux sont maintenant immunis�es du fameux Ping of Death, qui implique l'envoi de paquets ICMP ill�galement grands qui font d�border les buffers de la pile TCP du r�cepteur et causent de gros d�g�ts.
Si vous voulez prot�ger des machines qui peuvent �tre vuln�rables, vos pouvez simplement bloquer les fragments ICMP. Les paquets ICMP normaux ne sont pas assez gros pour n�cessiter la fragmentation, et vous ne casserez rien � part les gros pings. J'ai entendu parler (non confirm�) de rapports comme quoi quelques syst�mes ont seulement besoin du dernier fragment d'un paquet ICMP d�form� pour les corrompre, donc bloquer seulement le premier fragment n'est pas recommand�.
M�me si tous les programmes exploitant cette erreur que j'ai vu utilisent l'ICMP, il n'y a pas de raisons qu'un fragment TCP ou UDP (ou d'un protocole inconnu) ne puisse �tre utilis� pour cette attaque, donc le bloquage des fragments ICMP est seulement une solution temporaire.
Teardrop et Bonk sont deux attaques (principalement contre les machines sous Microsoft Windows NT) qui reposent sur des fragments superpos�s. Avoir votre routeur Linux d�fragmenter, ou interdisant tous les fragments vers vos machines vuln�rables sont d'autres options.
Quelques piles TCP moins fiables sont connues pour avoir des probl�mes � g�rer de larges ensembles de fragments de paquets lorsqu'elles ne re�oivent pas tous les fragments. Linux n'a pas ce probl�me. Vous pouvez filtrer les fragments (ce qui peut casser les utilisations l�gitimes) ou compiler votre noyau avec l'option "IP: always defragment" mise sur "Y" (seulement si votre machine Linux est la seule route possible pour ces paquets).
Il y a quelques probl�mes de temps qui sont impliqu�s dans la modification des r�gles pare-feu. Si vous n'y faites pas attention, vous pouvez laisser entrer des paquets lorsque vous avez fait la moiti� de vos changements. Une approche simpliste serait de faire la suite :
# ipchains -I input 1 -j DENY
# ipchains -I output 1 -j DENY
# ipchains -I forward 1 -j DENY
... Mise en place des changements ...
# ipchains -D input 1
# ipchains -D output 1
# ipchains -D forward 1
#
Ceci supprime tous les paquets pour la dur�e des changements.
Si vos changements sont restreints � une cha�ne simple, vous pouvez cr�er une nouvelle cha�ne avec les nouvelles r�gles, et ensuite remplacer ("-R") la r�gle qui pointait sur la vieille cha�ne par une qui pointe sur la nouvelle cha�ne ; ensuite, vous pouvez supprimer la vieille cha�ne. Le remplacement se fera � vitesse atomique.
L'IP spoofing est une technique dans laquelle un h�te envoie des paquets qui pr�tendent venir d'un autre h�te. Puisque le filtrage des paquets prend ses d�cisions sur la base de cette adresse source, l'IP spoofing est utilis� pour abuser les filtres de paquets. Elle est �galement utilis�e pour cacher l'identit� d'un attaquant utilisant les techniques SYN, Teardrop, Ping of Death et autres d�riv�s (ne vous inqui�tez si vous ne savez pas ce que c'est).
Le meilleur moyen de se prot�ger de l'IP spoofing est la v�rification de
l'adresse source, et il est r�alis� par le code de routage, et non par le
pare-feu et autres.
Cherchez un fichier nomm� /proc/sys/net/ipv4/conf/all/rp_filter.
S'il existe, alors l'activation de la
v�rification de l'adresse source � chaque lancement est la bonne solution pour
vous. Pour se faire, ins�rez les lignes suivantes quelque part dans vos
scripts d'initialisation, avant l'initialisation des interfaces r�seau :
# This is the best method: turn on Source Address Verification and get
# spoof protection on all current and future interfaces.
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then
echo -n "Setting up IP spoofing protection..."
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 > $f
done
echo "done."
else
echo PROBLEMS SETTING UP IP SPOOFING PROTECTION. BE WORRIED.
echo "CONTROL-D will exit from this shell and continue system startup."
echo
# Start a single user shell on the console
/sbin/sulogin $CONSOLE
fi
Si vous ne pouvez faire ceci, vous pouvez ins�rer manuellement les r�gles pour
prot�ger chaque interface. Ceci n�cessite la connaissance de chaque interface.
La s�rie des noyaux 2.1 et sup�rieurs rejette automatiquement les paquets qui
pr�tendent venir des adresses 127.* (r�serv�es pour l'interface de loopback,
lo).
Par exemple, disons que vous avez trois interfaces, eth0, eth1 et
ppp0. Nous pouvons utiliser ifconfig pour nous donner les adresses
et les masques de r�seau de chaque interface. Disons que eth0 est
rattach�e � un r�seau 192.168.1.0 avec le masque de sous-r�seau 255.255.255.0,
eth1 est raccord�e � un r�seau 10.0.0.0 avec le masque de sous-r�seau
255.0.0.0, et ppp0 connect�e � l'Internet (o� toutes les adresses sauf
les adresses IP priv�es r�serv�es sont autoris�es), nous ins�rerions les
r�gles suivantes :
# ipchains -A input -i eth0 -s ! 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i ! eth0 -s 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i eth1 -s ! 10.0.0.0/255.0.0.0 -j DENY
# ipchains -A input -i ! eth1 -s 10.0.0.0/255.0.0.0 -j DENY
#
Cette approche n'est pas aussi bonne que l'approche par v�rification de l'adresse source, parce que si votre r�seau change, vous devrez changer vos r�gles pare-feu pour �tre � jour.
Si vous utilisez un noyau de s�rie 2.0, vous pouvez �galement vouloir prot�ger l'interface loopback, en utilisant une r�gle telle que :
# ipchains -A input -i ! lo -s 127.0.0.0/255.0.0.0 -j DENY
#
Il y a une biblioth�que dans l'espace utilisateur que j'ai �crit et qui est inclue avec la distribution source, nomm�e "libfw". Elle utilise la capacit� de IP Chains 1.3 et suivants pour copier un paquet vers l'espace utilisateur (via l'option du noyau IP_FIREWALL_NETLINK).
La valeur "mark" peut �tre utilis�e pour sp�cifier les param�tres de Qualit� de Service pour les paquets, ou pour sp�cifier comment les paquets doivent �tre renvoy�s. Je ne l'ai cependant jamais utilis�e, mais si vous voulez �crire sur ce sujet, contactez moi.
Des choses comme le stateful inspection (je pr�f�re le terme "pare-feu dynamique") peuvent �tre impl�ment�es dans l'espace utilisateur en utilisant cette biblioth�que. D'autres id�es g�niales peuvent �tre le contr�le des paquets sur une base "par utilisateur" en faisant une demande sur un d�mon r�sidant dans l'espace utilisateur. Ceci devrait �tre relativement simple.
ftp://ftp.interlinx.bc.ca/pub/spf est le site du projet SPF de Brian Murrell, qui permet le suivi de connexion dans l'espace utilisateur. Ceci ajoute une dose significative de s�curit� pour les sites � faible bande passante.
Il y a peu de documentation pour le moment, mais voici un message que Brian a envoy� � la liste de diffusion en r�pondant � quelques questions :
> Je pr�sume qu'il fait exactement ce que je veux~: installer une r�gle de
> "retour" temporaire pour laisser entrer des paquets en r�ponse � une
> requ�te ext�rieure.
Yup, c'est exactement ce � quoi il sert. Plus il comprendra de protocoles,
plus il obtiendra de r�gles de retour exactes. Pour l'instant il supporte
(de m�moire, excusez les erreurs ou les omissions) le FTP (� la fois actif et
passif, int�rieur et ext�rieur), un peu de RealAudio, de traceroute, d'ICMP et
d'un ICQ basique (transmission des serveurs ICQ, connexions TCP directes, mais
h�las la seconde connexion directe TCP pour des trucs comme le transfert de
fichiers, etc., ne sont pas encore pr�sentes)
> S'agit-il d'un rempla�ant pour ipchains ou d'un ajout~?
C'est un ajout. Pensez � ipchains comme �tant le moteur pour autoriser et
emp�cher les paquets de traverser une machine Linux. SPF est le pilote, g�rant
et surveillant constamment le traffic et disant � ipchains comment changer ses
polices pour refl�ter les changements dans les sch�mas du traffic.
Michael Hasenstein de SuSE a cod� un correctif pour le noyau qui ajoute le suivi des connexions ftp � ipchains. Celui-ci peut �tre trouv� sur http://www.csn.tu-chemnitz.de/~mha/patch.ftp-data-2.gz
Les codes de pare-feu et de NAT sont en cours de remise � jour pour le 2.3. Les plans et les discussions sont disponibles sur l'archive de netdev, et sur la liste ipchains-dev. Ces extensions doivent nettoyer de nombreux probl�mes d'utilisation (r�ellement, la mise en place du pare-feu et le camouflage ne devrait pas �tre aussi dur, et devrait autoriser une croissance pour un pare-feu beaucoup plus flexible).
Vous bloquez probablement les demandes DNS ; il finira probablement par stopper. Essayez d'utiliser l'option "-n" (num�rique) d'ipchains, qui supprimera la recherche des noms.
V�rifiez si la redirection de paquets est activ�e (dans les noyaux r�cent, elle est d�sactiv�e par d�faut ce qui signifie que les paquets ne tentent jamais de traverser la cha�ne "forward"). Vous pouvez changer ce d�faut (en tant que super-utilisateur) en tapant
# echo 1 > /proc/sys/net/ipv4/ip_forward
#
Si ceci marche pour vous, vous pouvez le mettre quelque part dans vos scripts de lancement, de mani�re � ce que la redirection soit activ�e � chaque fois ; vous devrez toutefois configurer votre pare-feu avant le lancement de cette commande, autrement il peut y avoir passage de paquets.
Vous devez autoriser la retransmission des paquets (voir plus haut) pour que celle-ci fonctionne ; sinon le code de routage supprime le paquet. Ainsi, si vous utilisez juste la redirection sans avoir de transmission, vous devez y faire attention.
Notez que REDIR (dans la cha�ne d'entr�e) n'affecte pas les connexions d'un processus local.
Il y avait une erreur dans les versions 2.1.102 et 2.1.103 du noyau (et dans
quelques anciens correctifs que j'avais sorti) qui faisait planter les
commandes ipchains utilisant une interface joker (comme -i ppp+).
Cette erreur a �t� corrig�e dans les noyaux r�cents, et dans le correctif 2.0.34 du site web. Vous pouvez aussi le corriger � la main dans les sources du noyau en changeant la ligne 63 de include/linux/ip_fw.h :
#define IP_FW_F_MASK 0x002F /* All possible flag bits mask */
Ceci doit en fait �tre "0x003F". Corrigez et recompilez le noyau.
C'est de ma faute : la configuration du champ Type of Service ne change pas le Type of Service dans les noyaux 2.1.102 � 2.1.111. Ce probl�me a �t� corrig� dans le 2.1.112.
Pour les 2.0.x, c'est vrai ; je n'ai pas le temps de cr�er et de maintenir un correctif de taille gigantesque pour ipchains et ipautofw/ipportfw.
Pour les 2.1.x, r�cup�rez ipmasqadm de Juan Ciarlante sur
<url url="http://juanjox.linuxhq.com/"
name="http://juanjox.linuxhq.com/">
et utilisez-le exactement de la mani�re dont vous auriez utilis� ipautofw
ou ipportfw, � part qu'� la place de ipportfw vous devez taper
ipmasqadm portfw, et � la place de ipautofw vous devez taper
ipmasqadm autofw.
Mettez � jour � la version 1.6.0 ou sup�rieure, qui ne n�cessite pas de r�gle pare-feu pour les noyaux 2.1.x. Il semblerait �tre � nouveau cass� dans le 1.6.1 ; veuillez voir l'auteur (ce n'est pas de ma faute !).
C'�tait une erreur dans ipchains version 1.3.3. Veuillez mettre � jour.
C'est vrai (pour les noyaux 2.1.x) jusqu'au et incluant le 2.1.112. Ceci est pour le moment vigoureusement traqu�, et au moment o� vous lirez ce document il se pourrait que ce soit r�solu. Ma page web contiendra un correctif lorsqu'il sera disponible.
Ainsi qu'un certain nombre d'autres personnes, il semble. Mon code couvre seulement IP, malheureusement. Du bon c�t�, tout est l� pour pouvoir firewaller IPX ! Vous devrez juste �crire le code ; je vous aiderai joyeusement l� o� ce sera possible.
Cet exemple est extrait du tutorial donn� par Michael Neuling et moi-m�me en mars 1999 lors du LinuxWorld ; ce n'est pas le seul moyen de r�gler le probl�me donn�, mais c'est probablement le plus simple. J'esp�re que vous le jugerez informatif.
R�seau externe (MAUVAIS)
|
|
ppp0|
---------------
| 192.84.219.1| R�seau des serveurs (ZDM)
| |eth0
| |----------------------------------------------
| |192.84.219.250 | | |
| | | | |
|192.168.1.250| | | |
--------------- -------- ------- -------
| eth1 | SMTP | | DNS | | WWW |
| -------- ------- -------
| 192.84.219.128 192.84.219.129 192.84.218.130
|
R�seau Interne (BON)
Sur la machine filtrant les paquets :
Tr�s utile si la machine est hors-service.
Une fois de plus, utile pour les diagnostics.
Pour rendre ping et DNS plus utile.
À l'int�rieur de la Zone D�militaris�e :
Serveur mail
Serveur de nom
Serveur web
En interne :
Ce sont des services standards � autoriser : on autorise parfois les machines internes � tout faire, mais ici nous serons plus restrictifs.
Bien entendu, nous voulons qu'il leur soit possible d'envoyer du courrier vers l'ext�rieur.
C'est ainsi qu'ils lisent leur courrier.
Ils doivent pouvoir rechercher des noms externes pour le web, le ftp, traceroute ou ssh.
C'est ainsi qu'ils synchronisent le serveur web externe avec l'interne.
Bien entendu, nous voulons qu'ils puissent se connecteur au serveur web externe.
Il est courtois de l'autoriser ; ils peuvent ainsi tester si le pare-feu est coup� (ainsi nous ne serons pas tenus responsables si un site ext�rieur est coup�).
Puisque nous n'avons pas de routage asym�trique, nous pouvons simplement mettre en marche l'anti-spoofing pour toutes les interfaces.
# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f; done
#
Nous autorisons tout de m�me le traffic local, mais nous interdisons tout le reste.
# ipchains -A input -i ! lo -j DENY
# ipchains -A output -i ! lo -j DENY
# ipchains -A forward -j DENY
#
Ceci est g�n�ralement r�alis� par les scripts de lancement. Fa�tes bien attention � ce que les r�gles ci-dessus soient ins�r�es avant que les interfaces ne soient configur�es, afin de pr�venir le passage de paquets avant l'insertion des r�gles.
Nous devons ins�rer le module de camouflage du FTP, ainsi le ftp passif et actif fonctionnera `uniquement' du r�seau interne.
# insmod ip_masq_ftp
#
Avec le camouflage, il vaut mieux filtrer la cha�ne de retransmission.
Cassez la cha�ne de retransmission en plusieurs cha�nes utilisateurs d�pendant des interfaces sources/destination ; ceci ram�ne le probl�me � des probl�mes plus g�rables.
ipchains -N bon-zdm
ipchains -N mauvais-zdm
ipchains -N bon-mauvais
ipchains -N zdm-bon
ipchains -N zdm-mauvais
ipchains -N mauvais-bon
ACCEPTer les codes standards d'erreur ICMP est un fait classique, nous lui cr�ons donc une cha�ne.
ipchains -N icmp-acc
Malheureusement, nous connaissons seulement (dans la cha�ne de transmission) quelle est l'interface externe. Ainsi, pour se repr�senter de quelle interface vient le paquet, nous utilisons l'adresse source (l'anti-spoofing �vite les probl�mes li�s aux adresses).
Notez que nous enregistrons tout ce qui ne v�rifie aucune de ces r�gles (cependant, ceci ne devrait jamais arriver).
ipchains -A forward -s 192.168.1.0/24 -i eth0 -j bon-zdm
ipchains -A forward -s 192.168.1.0/24 -i ppp0 -j bon-mauvais
ipchains -A forward -s 192.84.219.0/24 -i ppp0 -j zdm-mauvais
ipchains -A forward -s 192.84.219.0/24 -i eth1 -j zdm-bon
ipchains -A forward -i eth0 -j mauvais-zdm
ipchains -A forward -i eth1 -j mauvais-bon
ipchains -A forward -j DENY -l
Les paquets correspondant � l'une des erreurs ICMP sont accept�s, sinon le contr�le les rendra � la cha�ne appellante.
ipchains -A icmp-acc -p icmp --icmp-type destination-unreachable -j ACCEPT
ipchains -A icmp-acc -p icmp --icmp-type source-quench -j ACCEPT
ipchains -A icmp-acc -p icmp --icmp-type time-exceeded -j ACCEPT
ipchains -A icmp-acc -p icmp --icmp-type parameter-problem -j ACCEPT
Restrictions internes :
On pourrait utiliser le camouflage du r�seau interne vers la ZDM, mais ici nous ne le ferons pas. Puisque personne du r�seau interne ne devrait tenter de choses d�moniaques, nous enregistrons les paquets qui sont interdits.
ipchains -A bon-zdm -p tcp -d 192.84.219.128 smtp -j ACCEPT
ipchains -A bon-zdm -p tcp -d 192.84.219.128 pop-3 -j ACCEPT
ipchains -A bon-zdm -p udp -d 192.84.219.129 domain -j ACCEPT
ipchains -A bon-zdm -p tcp -d 192.84.219.129 domain -j ACCEPT
ipchains -A bon-zdm -p tcp -d 192.84.218.130 www -j ACCEPT
ipchains -A bon-zdm -p tcp -d 192.84.218.130 rsync -j ACCEPT
ipchains -A bon-zdm -p icmp -j icmp-acc
ipchains -A bon-zdm -j DENY -l
ipchains -A mauvais-zdm -p tcp -d 192.84.219.128 smtp -j ACCEPT
ipchains -A mauvais-zdm -p udp -d 192.84.219.129 domain -j ACCEPT
ipchains -A mauvais-zdm -p tcp -d 192.84.219.129 domain -j ACCEPT
ipchains -A mauvais-zdm -p tcp -d 192.84.218.130 www -j ACCEPT
ipchains -A mauvais-zdm -p icmp -j icmp-acc
ipchains -A mauvais-zdm -j DENY
ipchains -A bon-mauvais -p tcp --dport www -j MASQ
ipchains -A bon-mauvais -p tcp --dport ssh -j MASQ
ipchains -A bon-mauvais -p udp --dport 33434:33500 -j MASQ
ipchains -A bon-mauvais -p tcp --dport ftp --j MASQ
ipchains -A bon-mauvais -p icmp --icmp-type ping -j MASQ
ipchains -A bon-mauvais -j REJECT -l
ipchains -A zdm-bon -p tcp ! -y -s 192.84.219.128 smtp -j ACCEPT
ipchains -A zdm-bon -p udp -s 192.84.219.129 domain -j ACCEPT
ipchains -A zdm-bon -p tcp ! -y -s 192.84.219.129 domain -j ACCEPT
ipchains -A zdm-bon -p tcp ! -y -s 192.84.218.130 www -j ACCEPT
ipchains -A zdm-bon -p tcp ! -y -s 192.84.218.130 rsync -j ACCEPT
ipchains -A zdm-bon -p icmp -j icmp-acc
ipchains -A zdm-mauvais -j DENY -l
ipchains -A zdm-mauvais -p tcp -s 192.84.219.128 smtp -j ACCEPT
ipchains -A zdm-mauvais -p udp -s 192.84.219.129 domain -j ACCEPT
ipchains -A zdm-mauvais -p tcp -s 192.84.219.129 domain -j ACCEPT
ipchains -A zdm-mauvais -p tcp ! -y -s 192.84.218.130 www -j ACCEPT
ipchains -A zdm-mauvais -p icmp -j icmp-acc
ipchains -A zdm-mauvais -j DENY -l
ipchains -A mauvais-bon -j REJECT
ipchains -N mauvais-if
ipchains -N zdm-if
ipchains -N bon-if
ipchains -A input -d 192.84.219.1 -j mauvais-if
ipchains -A input -d 192.84.219.250 -j zdm-if
ipchains -A input -d 192.168.1.250 -j bon-if
ipchains -A mauvais-if -i ! ppp0 -j DENY -l
ipchains -A mauvais-if -p TCP --dport 61000:65096 -j ACCEPT
ipchains -A mauvais-if -p UDP --dport 61000:65096 -j ACCEPT
ipchains -A mauvais-if -p ICMP --icmp-type pong -j ACCEPT
ipchains -A mauvais-if -j icmp-acc
ipchains -A mauvais-if -j DENY
ipchains -A zdm-if -i ! eth0 -j DENY
ipchains -A zdm-if -p TCP ! -y -s 192.84.219.129 53 -j ACCEPT
ipchains -A zdm-if -p UDP -s 192.84.219.129 53 -j ACCEPT
ipchains -A zdm-if -p ICMP --icmp-type pong -j ACCEPT
ipchains -A zdm-if -j icmp-acc
ipchains -A zdm-if -j DENY -l
ipchains -A bon-if -i ! eth1 -j DENY
ipchains -A bon-if -p ICMP --icmp-type ping -j ACCEPT
ipchains -A bon-if -p ICMP --icmp-type pong -j ACCEPT
ipchains -A bon-if -j icmp-acc
ipchains -A bon-if -j DENY -l
ipchains -D input 1
ipchains -D forward 1
ipchains -D output 1
Quelques-uns de ces changements sont le r�sultat de changements du noyau, et
quelques autres sont un r�sultat des diff�rences entre ipchains et
ipfwadm.
[ Dans l'ensemble, les arguments des commandes sont en MAJUSCULES, et les options des arguments sont en minuscules ]
Une chose � noter, le camouflage est sp�cifi� par "-j MASQ" ; ceci est
compl�tement diff�rent de "-j ACCEPT", et n'est pas trait� comme un effet de
bord, au contraire d'ipfwadm.
=========================================================================== | ipfwadm | ipchains | Notes --------------------------------------------------------------------------- | -A [both] | -N acct | Cr�e une cha�ne "acct" | |& -I 1 input -j acct | ayant des paquets entrants et | |& -I 1 output -j acct | sortants qui la traversent. | |& acct | --------------------------------------------------------------------------- | -A in | input | Une r�gle sans destination --------------------------------------------------------------------------- | -A out | output | Une r�gle sans destination --------------------------------------------------------------------------- | -F | forward | Utilise �a comme [cha�ne]. --------------------------------------------------------------------------- | -I | input | Utilise �a comme [cha�ne]. --------------------------------------------------------------------------- | -O | output | Utilise �a comme [cha�ne]. --------------------------------------------------------------------------- | -M -l | -M -L | --------------------------------------------------------------------------- | -M -s | -M -S | --------------------------------------------------------------------------- | -a policy | -A [chain] -j POLICY | (voir -r et -m). --------------------------------------------------------------------------- | -d policy | -D [chain] -j POLICY | (voir -r et -m). --------------------------------------------------------------------------- | -i policy | -I 1 [chain] -j POLICY| (voir -r et -m). --------------------------------------------------------------------------- | -l | -L | --------------------------------------------------------------------------- | -z | -Z | --------------------------------------------------------------------------- | -f | -F | --------------------------------------------------------------------------- | -p | -P | --------------------------------------------------------------------------- | -c | -C | --------------------------------------------------------------------------- | -P | -p | --------------------------------------------------------------------------- | -S | -s | Prend seulement un port ou un | | | intervalle, pas de multiples. --------------------------------------------------------------------------- | -D | -d | Prend seulement un port ou un | | | intervalle, pas de multiples. --------------------------------------------------------------------------- | -V | <none> | Utilise -i [nom]. --------------------------------------------------------------------------- | -W | -i | --------------------------------------------------------------------------- | -b | -b | Dor�navant cr�e deux r�gles. --------------------------------------------------------------------------- | -e | -v | --------------------------------------------------------------------------- | -k | ! -y | Ne fonctionne pas � moins que | | | -p tcp ne soit �galement sp�cifi�. --------------------------------------------------------------------------- | -m | -j MASQ | --------------------------------------------------------------------------- | -n | -n | --------------------------------------------------------------------------- | -o | -l | --------------------------------------------------------------------------- | -r [redirpt] | -j REDIRECT [redirpt] | --------------------------------------------------------------------------- | -t | -t | --------------------------------------------------------------------------- | -v | -v | --------------------------------------------------------------------------- | -x | -x | --------------------------------------------------------------------------- | -y | -y | Ne fonctionne pas � moins que | | | -p tcp ne soit �galement sp�cifi�. ---------------------------------------------------------------------------
Ancienne commande : ipfwadm -F -p deny
Nouvelle commande : ipchains -P forward DENY
Ancienne commande : ipfwadm -F -a m -S 192.168.0.0/24 -D 0.0.0.0/0
Nouvelle commande : ipchains -A forward -j MASQ -s 192.168.0.0/24 -d 0.0.0.0/0
Ancienne commande : ipfwadm -I -a accept -V 10.1.2.1 -S 10.0.0.0/8 -D 0.0.0.0/0
Nouvelle commande : ipchains -A input -j ACCEPT -i eth0 -s 10.0.0.0/8 -d 0.0.0.0/0
(Notez qu'il n'y a pas d'�quivalent pour la sp�cification des interfaces par leur adresse : utilisez le nom de l'interface. Sur cette machine, 10.1.2.1 correspond � eth0).
Le script shell ipfwadm-wrapper doit �tre un remplacement d'ipfwadm
pour la compatibilit� descendante avec ipfwadm 2.3a.
La seule option qu'il ne peut vraiment pas supporter est l'option "-V".
Lorsqu'elle est utilis�e, un avertissement est affich�. Si l'option "-W" est
�galement utilis�e, l'option "-V" est ignor�e. Autrement, le script essaye de
trouver le nom de l'interface associ�e � cette adresse, en utilisant
ifconfig. Si �a ne marche pas (comme pour une interface d�sactiv�e),
alors il sortira avec un message d'erreur.
Cet avertissement peut �tre supprim� soit en changeant le "-V" pour un "-W", ou en dirigeant la sortie standard du script vers /dev/null.
Si vous trouvez des erreurs dans ce script, ou une modification entre les
effets du vrai ipfwadm et de ce script, veuillez me rapporter le
probl�me : envoyez un courrier � ipchains@rustcorp.com avec le sujet
"BUG-REPORT". Veuillez lister la version d'ipfwadm (ipfwadm -h),
votre version d'ipchains (ipchains --version), la version du script
d'emballage (ipfwadm-wrapper --version). Envoyez moi �galement la sortie
de ipchains-save. Merci d'avance.
Le m�lange d'ipchains avec le script ipfwadm-wrapper se fait � votre
propre p�ril.
Un grand merci � Michael Neuling, qui a �crit la pr�-version du code d'IP chains en travaillant pour moi. Des excuses publiques pour avoir rejet� son id�e de cache des r�sultats, qu'Alan Cox a propos� plus tard et que j'ai finalement commenc� � impl�menter, ayant vu l'erreur de mon c�t�.
Merci � Alan Cox pour son support technique par email 24h/24, et pour ses encouragements.
Merci � tous les auteurs du code d'ipfw et d'ipfwadm, sp�cialement Jos Vos. Rester aux chevilles des g�ants et tout �a... Ceci s'applique �galement � Linux Torvalds et � tous les bricoleurs du noyau et de l'espace utilisateur.
Merci aux beta testeurs, chasseurs d'erreurs diligents, surtout Jordan Mendelson, Shaw Carruthers, Kevin Moule, Dr. Liviu Daia, Helmut Adams, Franck Sicard, Kevin Littlejohn, Matt Kemner, John D. Hardin, Alexey Kuznetsov, Leos Bitto, Jim Kunzman, Gerard Gerritsen, Serge Sivkov, Andrew Burgess, Steve Schmidtke, Richard Offer, Bernhard Weisshuhn, Larry Auton, Ambrose Li, Pavel Krauz, Steve Chadsey, Francesco Potorti` et Alain Knaff.