Linux IPCHAINS-HOWTO
Paul Russell, ipchains@rustcorp.com
Version fran�aise par Arnaud Launay, asl@launay.org
v1.0.7, 12 mars 1999
_________________________________________________________________
_Ce document d�crit l'obtention, l'installation et la configuration du
logiciel am�lior� de cha�nes pare-feu IP pour Linux, et donne quelques
id�es sur l'utilisation que vous pouvez en faire._
_________________________________________________________________
1. Introduction
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'.
1.1 Qu'est ce que c'est ?
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.
1.2 Pourquoi ?
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).
1.3 Comment ?
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.
1.4 O� ?
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'.
2. Bases du filtrage de paquets
2.1 Qu'est ce que c'est ?
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.
2.2 Pourquoi ?
Contr�le. S�curit�. Vigilance.
_Contr�le :_
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).
_S�curit� :_
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.
_Vigilance :_
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�.
2.3 Comment ?
Un noyau avec le filtrage de paquets
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.
ipchains
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.
Rendre les r�gles permanentes
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).
3. Je suis troubl� ! Routage, camouflage, redirection de ports, ipautofw...
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.
3.1 Le guide du camouflage en 3 lignes par Rusty
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
3.2 Publicit� gratuite : le z�le de WatchGuard
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.
http://www.watchguard.com
3.3 Configurations classiques de type pare-feu
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.
R�seaux priv�s : caches traditionnels
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.
1. On a assign� les adresses 192.168.1.* au r�seau priv�, avec
mamachine �tant 192.168.1.100, et l'interface Ethernet du pare-feu
�tant assign�e � 192.168.1.1.
2. Un cache web (comme "squid") est install� et configur� sur le
pare-feu, disons tournant sur le port 8080.
3. Netscape sur le r�seau priv� est configur� pour utiliser le
pare-feu port 8080 comme cache.
4. Le DNS n'a pas besoin d'�tre configur� sur le r�seau priv�.
5. Le DNS doit �tre configur� sur le pare-feu.
6. Le r�seau priv� n'a pas besoin de disposer de route par d�faut
(passerelle).
Netscape sur mamachine lit http://slashdot.org.
1. Netscape se connecte sur le port 8080 du pare-feu, en utilisant le
port 1050 de mamachine. Il demande la page web de
"http://slashdot.org".
2. Le cache recherche le nom "slashdot.org", et obtient
207.218.152.131. Il ouvre alors une connexion sur cette adresse IP
(en utilisant le port 1025 de l'interface externe du pare-feu), et
demande la page au serveur web (port 80).
3. En recevant la page web par sa connexion au serveur web, le
pare-feu copie les donn�es vers la connexion de Netscape.
4. Netscape affiche la page.
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.
R�seaux priv�s : caches transparents
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.
1. On a assign� les adresses 192.168.1.* au r�seau priv�, avec
mamachine �tant 192.168.1.100, et l'interface Ethernet du pare-feu
�tant assign�e � 192.168.1.1.
2. Un proxy web transparent (je pr�sume qu'il existe des correctifs
pour squid lui permettant d'op�rer de cette fa�on, sinon, essayez
"transproxy") est install� et configur� sur le pare-feu, disons
tournant sur le port 8080.
3. On dit au noyau de rediriger les connexions sur le port 80 du
proxy, en utilisant ipchains.
4. Netscape, sur le r�seau priv�, est configur� pour se connecter
directement.
5. Le DNS doit �tre configur� sur le r�seau priv� (c�d que vous devez
faire tourner un serveur DNS de la m�me mani�re que le proxy sur
le pare-feu).
6. La route par d�faut (passerelle) doit �tre configur� sur le r�seau
priv�, pour envoyer les paquets au pare-feu.
Netscape sur mamachine lit http://slashdot.org.
1. Netscape recherche le nom "slashdot.org", et obtient
207.218.152.131. Il ouvre alors une connexion vers cette adresse
IP, en utilisant le port local 1050, et demande la page au serveur
web (port 80).
2. Comme les paquets venant de mamachine (port 1050) et allant sur
slashdot.org (port 80) passent par le pare-feu, ils sont redirig�s
sur le proxy transparent en attente sur le port 8080. Le cache
transparent ouvre alors une connexion (en utilisant le port local
1025) vers 207.218.152.131 port 80 (vers lequel les paquets de
d�part allaient).
3. Alors que le cache re�oit la page web par sa connexion avec le
serveur web, il copie les donn�es vers la connexion avec Netscape.
4. Netscape affiche la page.
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.
R�seaux priv�s : camouflage
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.
1. On a assign� les adresses 192.168.1.* au r�seau priv�, avec
mamachine �tant 192.168.1.100, et l'interface Ethernet du pare-feu
�tant assign�e � 192.168.1.1.
2. Le pare-feu est configur� pour camoufler tous les paquets venant
du r�seau priv� et allant sur le port 80 d'un h�te sur Internet.
3. Netscape est configur� pour se connecter directement.
4. Le DNS doit �tre configur� correctement sur le r�seau priv�.
5. Le pare-feu doit �tre la route par d�faut (passerelle) du r�seau
priv�.
Netscape sur mamachine lit http://slashdot.org.
1. Netscape recherche le nom "slashdot.org", et obtient
207.218.152.131. Il ouvre alors une connexion vers cette adresse
IP, en utilisant le port local 1050, et demande la page au serveur
web (port 80).
2. Comme les paquets venant de mamachine (port 1050) et allant sur
slashdot.org (port 80) passent par le pare-feu, ils sont r��crits
pour venir de l'interface PPP du pare-feu, port 65000. Le pare-feu
a une adresse Internet valide (1.2.3.4), donc les paquets venant
de slashdot.org sont rout�s correctement.
3. Lorsque les paquets venant de slashdot.org (port 80) sur
firewall.petiteboite.com (port 65000) arrivent, ils sont r��crits
pour aller sur mamachine, port 1050. La v�ritable magie du
camouflage se trouve ici : il se souvient des paquets sortants
r��crits afin de pouvoir r��crire les paquets entrants qui en sont
la r�ponse.
4. Netscape affiche la page.
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.
R�seaux publics
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.
1. Votre r�seau interne dispose du bloc d'adresses IP que vous avez
enregistr�, disons 1.2.3.*.
2. Le pare-feu est configur� pour autoriser tout le trafic.
3. Netscape est configur� pour se connecter directement.
4. Le DNS doit �tre configur� correctement sur votre r�seau.
5. Le pare-feu doit �tre la route par d�faut (passerelle) pour le
r�seau priv�.
Netscape sur mamachine lit http://slashdot.org.
1. Netscape recherche le nom "slashdot.org", et obtient
207.218.152.131. Il ouvre alors une connexion vers cette adresse
IP, en utilisant le port local 1050, et demande la page au serveur
web, port 80.
2. Les paquets passent par votre pare-feu, comme ils passent par
d'autres routeurs entre vous et slashdot.org.
3. Netscape affiche la page.
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.
Services internes limit�s
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.
3.4 Pour plus d'informations sur le camouflage
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.
4. Cha�nes de protection IP
Cette section d�crit tout ce que vous avez r�ellement besoin de savoir
pour construire un filtre de paquets adapt� � vos besoins.
4.1 Comment les paquets traversent les filtres
Le noyau commence avec trois listes de r�gles : ces listes sont
appell�es _cha�nes de protection_ ou juste _cha�nes_. Ces trois
cha�nes sont appell�es _input_ (entr�e), _output_ (sortie) et _forward_
(transmission). Lorsqu'un paquet arrive (disons, par une carte
Ethernet), le noyau utilise la cha�ne input pour d�cider de son
destin. S'il survit � ce passage, alors le noyau d�cide o� envoyer le
paquet par la suite (ceci est appel� _routage_). S'il est destin� �
une autre machine, il consulte alors la cha�ne de transmission. Enfin,
juste avant que le paquet ne ressorte, le noyau consulte la cha�ne de
sortie.
Une cha�ne est une v�rification de _r�gles_. Chaque r�gle dit `si
l'ent�te de ce paquet ressemble � ceci, alors voil� quoi faire de ce
paquet'. Si la r�gle ne v�rifie pas le paquet, alors la r�gle suivante
dans la cha�ne est consult�e. Enfin, s'il n'y a plus de r�gles �
consulter, alors le noyau regarde la cha�ne _police_ pour d�cider ce
qu'il doit faire. Dans un syst�me orient� s�curit�, cette police dit
g�n�ralement au noyau de rejeter ou de refuser le paquet.
Pour les fans de l'art ASCII, ceci montre le chemin complet d'un
paquet arrivant � une machine.
-----------------------------------------------------------------------
------
| ACCEPTER/ interface lo |
v REDIRIGER _________ |
--> S --> V --> ______ --> D --> ~~~~~~~~ -->| Cha�ne |----> _______ -->
o a |cha�ne| e {D�cision} |transfert| |Cha�ne |ACCEPTER
m l |entr�e| m {Routage } |_________| --->|sortie |
m i |______| a ~~~~~~~~ | | ->|_______|
e d | s | | | | |
| i | q | NON/ | | |
| t v u v REJET | | v
| � NON/ e Processus | | NON/
| | REJET r Local | | REJET
| v | ---------------------- |
v NON \ ------------------------------/
NON
Voici une description point par point de chaque partie :
_Somme (checksum) :_
C'est un test v�rifiant si le paquet n'a pas �t� corrompu d'une
mani�re ou d'une autre. S'il l'a �t�, il est refus�.
_Validit� (sanity) :_
Il y a en fait un de ces tests sanitaires avant chaque cha�ne
de protection, mais les cha�nes d'entr�e sont les plus
importantes. Quelques paquets malform�s peuvent rendre confus
le code de v�rification des r�gles, et ceux-ci sont refus�s ici
(un message est envoy� au syslog si ceci arrive).
_Cha�ne d'entr�e (input chain) :_
C'est la premi�re cha�ne de protection qui teste le paquet. Si
le verdict de la cha�ne n'est ni DENY ni REJECT, le paquet
continue son chemin.
_Demasquerade :_
Si le paquet est une r�ponse � un paquet pr�c�demment masqu�,
il est d�masqu�, et envoy� directement � la cha�ne de sortie.
Si vous n'utilisez pas le masquage IP, vous pouvez mentalement
supprimer ceci du diagramme.
_D�cision routage (Routing decision) :_
Le champ de destination est examin� par le code de routage,
pour d�cider si le paquet doit aller vers un processus local
(voir processus local plus bas) ou transmis � une machine
distante (voyez les cha�nes de renvoi plus bas).
_Processus local (Local process) :_
Un processus tournant sur la machine peut recevoir des paquets
apr�s l'�tape de d�cision de routage, et peut envoyer des
paquets (qui passent par l'�tape de d�cision de routage, puis
traversent la cha�ne de sortie).
_Interface lo :_
Si les paquets venant d'un processus local sont destin�s � un
autre processus local, alors ils passeront par la cha�ne de
sortie en utilisant l'interface lo, puis reviendront par la
cha�ne d'entr�e en utilisant la m�me interface. L'interface lo
est g�n�ralement nomm�e interface loopback.
_local :_
Si le paquet n'a pas �t� cr�� par un processus local, alors la
cha�ne de transmission est v�rifi�e, sinon le paquet se dirige
vers la cha�ne de sortie.
_forward chain :_
Cette cha�ne est travers�e par tout paquet qui tente de passer
par cette machine vers une autre.
_output chain :_
Cette cha�ne est travers�e par tous les paquets juste avant
qu'ils ne soient envoy�s � l'ext�rieur.
Utiliser ipchains
Tout d'abord, v�rifiez que vous avez la version d'ipchains � laquelle
se r�f�re ce document :
$ ipchains --version
ipchains 1.3.9, 17-Mar-1999
Notez que je recommande l'utilisation du 1.3.4 (qui ne dispose pas des
options longues comme `--sport'), ou du 1.3.8 et suivants ; ils sont
en effet tr�s stables.
ipchains dispose d'une page de manuel plut�t bien d�taill�e (man
ipchains), et si vous avez besoin de plus de d�tails en particulier,
vous pouvez consulter l'interface de programmation (man 4 ipfw), ou le
fichier net/ipv4/ip_fw.c dans les sources des noyaux 2.1.x, qui est
(bien �videmment) la r�f�rence.
Il y a �galement une carte de r�f�rence rapide par Scott Bronson dans
le paquetage source, aux formats PostScript (TM) a4 et US letter.
Il y a plusieurs choses diff�rentes que vous pouvez faire avec
ipchains. Tout d'abord les op�rations servant � g�rer les cha�nes
enti�res. Vous commencez avec trois cha�nes int�gr�es input, output et
forward que vous ne pouvez effacer.
1. Cr�er une nouvelle cha�ne (-N) ;
2. Supprimer une cha�ne vide (-X) ;
3. Changer la police d'une cha�ne int�gr�e (-P) ;
4. Lister les r�gles d'une cha�ne (-L) ;
5. Supprimer les r�gles d'une cha�ne (-F) ;
6. Mettre � z�ro les compteurs de paquets et d'octets sur toutes les
r�gles d'une cha�ne (-Z).
Il y a plusieurs moyens pour manipuler les r�gles � l'int�rieur d'une
cha�ne :
1. Ajouter une nouvelle r�gle � une cha�ne (-A) ;
2. Ins�rer une nouvelle r�gle � une position quelconque de la cha�ne
(-I) ;
3. Remplacer une r�gle � une position quelconque de la cha�ne (-R) ;
4. Supprimer une r�gle � une position quelconque de la cha�ne (-D) ;
5. Supprimer la premi�re r�gle v�rifi�e dans la cha�ne (-D).
Il y a quelques op�rations pour le masquage, qui se trouvent dans
ipchains dans l'attente d'un bon endroit pour les mettre :
1. Lister les connexions masqu�es actuelles (-M -L) ;
2. Configurer les valeurs de timeout (-M -S) (mais voyez
id="no-timeout" name="Je ne peux pas modifier les temps d'attente
du camouflage !">).
La fonction finale (et peut-�tre la plus utile) vous permet de
v�rifier ce qui arriverait � un paquet donn� s'il avait � traverser
une cha�ne donn�e.
Op�rations sur une r�gle simple
Ceci est le B.A.-Ba d'ipchains ; manipuler des r�gles. Plus
g�n�ralement, vous utiliserez probablement les commandes d'ajout (-A)
et de suppression (-D). Les autres (-I pour l'insertion et -R pour le
remplacement) sont des simples extensions de ces concepts.
Chaque r�gle sp�ficie un ensemble de conditions que le paquet doit
suivre, et ce qu'il faut faire s'il les suit (une "destination"). Par
exemple, vous pouvez vouloir refuser tous les paquets ICMP venant de
l'adresse IP 127.0.0.1. Donc, dans ce cas nos conditions sont que le
protocole doit �tre ICMP et que l'adresse source doit �tre 127.0.0.1.
Notre destination est "DENY" (rejet).
127.0.0.1 est l'interface "loopback", que vous avez m�me si vous
n'avez de connexion r�seau r�elle. Vous pouvez utiliser le programme
"ping" pour g�n�rer de tels paquets (il envoie simplement un paquet
ICMP de type 8 (requ�te d'�cho) � qui tous les h�tes coop�ratifs
doivent obligeamment r�pondre avec un paquet ICMP de type 0 (r�ponse �
un �cho)). Ceci le rend utile pour les tests.
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.2 ms
# ipchains -A input -s 127.0.0.1 -p icmp -j DENY
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
#
Vous pouvez voir ici que le premier ping r�ussit (le "-c 1" dit � ping
de n'envoyer qu'un seul paquet).
Puis nous ajoutons (-A) � la cha�ne d'entr�e ("input"), une r�gle
sp�cifiant que tous les paquets provenant de 127.0.0.1 ("-s
127.0.0.1") avec le protocole ICMP ("-p ICMP") doivent �tre refus�s
("-j DENY").
Ensuite nous testons notre r�gle, en utilisant le second ping. Il y
aura une pause avant que le programme ne se termine, attendant une
r�ponse qui ne viendra jamais.
Nous pouvons supprimer la r�gle avec l'un des deux moyens. Tout
d'abord, puisque nous savons que c'est la seule r�gle de la cha�ne
d'entr�e, nous pouvons utiliser une suppression num�rot�e, comme
dans :
# ipchains -D input 1
#
Pour supprimer la r�gle num�ro 1 de la cha�ne d'entr�e.
La deuxi�me possibilit� est de copier la commande -A, mais en
rempla�ant le -A par -D. C'est utile lorsque vous avez une cha�ne
complexe de r�gles et que vous ne voulez pas avoir � les compter afin
de savoir que c'est la r�gle 37 que vous voulez supprimer. Dans ce
cas, nous pouvons utiliser :
# ipchains -D input -s 127.0.0.1 -p icmp -j DENY
#
La syntaxe de -D doit avoir exactement les m�mes options que la
commande -A (ou -I ou -R). S'il y a des r�gles multiples identiques
dans la m�me cha�ne, seule la premi�re sera supprim�e.
Sp�cifications du filtrage
Nous avons vu l'utilisation de "-p" pour sp�cifier le protocole, et de
"-s" pour sp�cifier l'adresse souce, mais il y a d'autres options que
nous pouvons utiliser pour sp�cifier les caract�ristiques des paquets.
Ce qui suit en est une description exhaustive.
Sp�cifier les adresses IP source et destination
Les adresses IP source (-s) et destination (-d) peuvent �tre
sp�cifi�es de quatre fa�ons diff�rentes. La fa�on la plus classique
est d'utiliser le nom complet, comme "localhost" ou "www.linuxhq.com".
La deuxi�me m�thode est de sp�cifier l'adresse IP, comme "127.0.0.1".
Les deux autres m�thodes permettent la sp�cification d'un groupe
d'adresses IP, comme "199.95.207.0/24" ou
"199.95.207.0/255.255.255.0". Toutes deux sp�cifient toutes les
adresses IP de 192.95.207.0 � 192.95.207.255, incluse ; les chiffres
suivant le "/" indiquent quelles parties de l'adresse IP sont
significatives. "/32" ou "/255.255.255.255" sont les d�fauts
(v�rifient toutes les adresses IP). Pour ne sp�cifier aucune adresse
IP, "/0" peut �tre utilis�, par exemple :
# ipchains -A input -s 0/0 -j DENY
#
Ceci est rarement utilis�, car l'effet produit par cette ligne de
commande est le m�me que celui obtenu en ne sp�cifiant pas l'option
"-s".
Sp�cifier l'inversion
De nombreuses options, incluant les options "-s" et "-d" peuvent avoir
leurs propres arguments pr�c�d�s par "!" (prononc� "non") pour ne
v�rifier que les adresses n'�tant PAS �quivalentes � celles donn�es.
Par exemple, "-s ! localhost" v�rifiera tout paquet ne provenant PAS
de localhost.
Sp�cifier le protocole
Le protocole peut �tre sp�cifi� en utilisant l'option "-p". Le
protocole peut �tre soit un nombre (si vous connaissez les valeurs
num�riques des protocoles pour IP), soit le nom des cas sp�ciaux
parmis "TCP", "UDP" ou "ICMP". La casse n'est pas prise en compte,
donc "tcp" fonctionne aussi bien que "TCP".
Le nom du protocole peut �tre pr�fix� par un "!", pour l'inverser,
comme dans "-p ! TCP".
Sp�cifier les ports UDP et TCP
Pour les cas sp�ciaux o� un protocole TCP ou UDP est sp�cifi�, il peut
y avoir un argument suppl�mentaire indiquant le port TCP ou UDP, ou un
intervalle (inclusif) de ports (mais voyez Utiliser les fragments plus
bas). Un intervalle est repr�sent� en utilisant le caract�re ":", par
exemple "6000:6010", qui couvre 11 ports, du 6000 au 6010, de mani�re
inclusive. Si la borne inf�rieure est omise, alors elle se met par
d�faut � 0. Si la borne sup�rieure est omise, elle est consid�r�e par
d�faut comme �tant 65535. Ainsi, pour sp�cifier les connexions TCP
venant des ports inf�rieurs � 1024, la syntaxe pourrait �tre "-p TCP
-s 0.0.0.0/0 :1023". Les num�ros de ports peuvent �tre sp�cifi�s par
leur nom, par exemple "www".
Notez que la sp�cification du port peut �tre pr�c�d�e par un "!", qui
l'inverse. Ainsi, pour sp�cifier tous les paquets TCP, SAUF un paquet
WWW, vous pourriez sp�cifier
-p TCP -d 0.0.0.0/0 ! www
Il est important de r�aliser que sp�cifier
-p TCP -d ! 192.168.1.1 www
est tr�s diff�rent de
-p TCP -d 192.168.1.1 ! www
La premi�re ligne sp�cifie tout paquet TCP dirig� vers le port WWW de
n'importe quelle machine sauf 192.168.1.1. La seconde sp�cifie toute
connexion TCP vers tout port de 192.168.1.1 sauf le port WWW.
Enfin, le cas suivant sp�cifie tout, sauf le port WWW et la machine
192.168.1.1 :
-p TCP -d ! 192.168.1.1 ! www
Sp�cifier les types et codes ICMP
ICMP permet aussi un argument optionnel, mais comme l'ICMP ne dispose
pas de ports (ICMP a un _type_ et un _code_), ils ont une
signification diff�rente.
Vous pouvez les sp�cifier par les noms ICMP (utilisez ipchains -h icmp
pour lister les noms disponibles) apr�s l'option "-s", ou en tant que
type et code ICMP num�rique, o� le type suit l'option "-s" et le code
suit l'option "-d".
Les noms ICMP sont relativement longs : vous avez uniquement besoin de
suffisamment de lettres pour rendre chaque nom distinct des autres.
Voici un petit r�sum� de quelques-uns des paquets ICMP les plus
communs :
Num�ro Nom Utilis� par
0 echo-reply ping
3 destination-unreachable Tout trafic TCP/UDP
5 redirect Routage, si pas de d�mon de routage
8 echo-request ping
11 time-exceeded traceroute
Notez que les noms ICMP ne peuvent �tre pr�c�d�s de "!" pour le
moment.
NE PAS, SURTOUT NE PAS bloquer tous les paquets ICMP de type 3 ! (voir
Paquets ICMP plus bas).
Sp�cifier une interface
L'option "-i" sp�cifie le nom d'une _interface_ � v�rifier. Une
interface est le p�riph�rique physique d'o� vient le paquet, ou bien
par o� sort ce paquet. Vous pouvez utiliser la commande ifconfig pour
lister les interfaces qui sont "up" (c�d en fonctionnement).
L'interface pour les paquets entrants (ie. les paquets traversant la
cha�ne d'entr�e) est consid�r�e comme �tant l'interface d'o� les
paquets proviennent. Logiquement, l'interface des paquets sortants
(les paquets traversant la cha�ne de sortie) est l'interface o� ils
vont. L'interface pour les paquets traversant la cha�ne de
retransmission est �galement l'interface par laquelle ils sortiront ;
une d�cision plut�t arbitraire � mon sens.
Il est parfaitement autoris� de sp�cifier une interface qui n'existe
pas au moment de la sp�cification ; la r�gle ne v�rifiera rien jusqu'�
ce que l'interface soit mise en place. Ceci est extr�mement utile pour
les connexions ppp intermittentes (habituellement les interfaces du
type ppp0) et autres.
En tant que cas sp�cial, un nom d'interface se finissant par un "+"
v�rifiera toutes les interfaces (qu'elles existent � ce moment ou non)
qui commencent par cette cha�ne. Par exemple, pour sp�cifier une r�gle
qui v�rifiera toutes les interfaces PPP, l'option -i ppp+ pourrait
�tre utilis�e.
Le nom d'interface peut �tre pr�c�d� par un "!" pour v�rifier un
paquet qui ne v�rifie PAS l'(les) interface(s) sp�cifi�e(s).
Sp�cifier uniquement des paquets TCP SYN
Il est parfois utile d'autoriser des connexions TCP dans une
direction, mais pas dans l'autre. Par exemple, vous pouvez vouloir
autoriser les connexions vers un serveur WWW externe, mais pas les
connexions venant de ce serveur.
L'approche na�ve serait de bloquer les paquets TCP venant du serveur.
Malheureusement, les connexions TCP utilisent des paquets circulant
dans les deux sens pour fonctionner.
La solution est de bloquer uniquement les paquets utilis�s pour la
demande d'une connexion. Ces paquets sont nomm�s paquets _SYN_ (ok,
techniquement ce sont des paquets avec le drapeau SYN mis, et les
drapeaux FIN et ACK supprim�s, mais nous les appellerons des paquets
SYN). En interdisant seulement ces paquets, nous pouvons stopper toute
demande de connexion dans l'oeuf.
L'option "-y" est utilis�e pour cel� : elle est valide seulement pour
les r�gles qui sp�cifient TCP comme leur protocole. Par exemple, pour
sp�cifier une demande de connexion TCP venant de 192.168.1.1 :
-p TCP -s 192.168.1.1 -y
Une fois de plus, ce drapeau peut �tre invers� en le faisant pr�c�der
par un "!", qui v�rifie tout paquet autre que ceux d'initialisation de
connexion.
Utiliser les fragments
Parfois, un paquet est trop large pour rentrer dans le c�ble en une
seule fois. Lorsque ceci arrive, le paquet est divis� en _fragments_,
et envoy� en plusieurs paquets. Le receveur r�assemble les fragments
pour reconstruire le paquet en entier.
Le probl�me avec les fragments se situe dans certaines des
sp�cifications list�es ci-dessus (en particulier, le port source, le
port de destination, le type et le code ICMP, ou le drapeau TCP SYN),
qui demandent au noyau de jeter un regard sur le d�but du paquet, qui
est contenu seulement dans le premier fragment.
Si votre machine est la seule connexion vers un r�seau ext�rieur, vous
pouvez demander � votre noyau Linux de r�assembler tous les fragments
qui passent par lui, en compilant le noyau avec l'option IP: always
defragment mise � "Y". Ceci �vite proprement la plupart des probl�mes.
D'autre part, il est important de comprendre comment les fragments
sont trait�s par les r�gles de filtrage. Toute r�gle de filtrage qui
demande des informations dont nous ne disposons pas ne v�rifiera
_rien_. Ceci signifie que le premier fragment est trait� comme tout
autre paquet. Le deuxi�me fragment et les suivants ne le seront pas.
Ainsi, une r�gle -p TCP -s 192.168.1.1 www (sp�cifiant un port source
de "www" ne v�rifiera jamais un fragment (autre que le premier
fragment). La r�gle oppos�e -p TCP -s 192.168.1.1 ! www ne
fonctionnera pas non plus.
Cependant, vous pouvez sp�cifier une r�gle sp�ciale pour le deuxi�me
fragment et les suivants, en utilisant l'option "-f". �videmment, il
est ill�gal de sp�cifier un port TCP ou UDP, un type ou un code ICMP,
ou un drapeau TCP SYN dans une r�gle de fragment.
Il est �galement autoris� de sp�cifier une r�gle qui ne s'applique
_pas_ au deuxi�me fragment et aux suivants, en pla�ant un "!" avant le
"-f".
Habituellement, il est consid�r� comme s�r de laisser passer le
deuxi�me fragment et les suivants, puisque le filtrage s'effectuera
sur le premier fragment, et pr�viendra donc le r�assemblage sur la
machine cible. Cependant, des bogues, connus, permettent de crasher
des machines en envoyant de simples fragments. � vous de voir.
� noter pour les gourous r�seau : les paquets malform�s (TCP, UDP et
paquets ICMP trop courts pour que le code pare-feu puisse lire les
ports ou les types et codes ICMP) sont �galement trait�s comme des
fragments. Seuls les fragments TCP d�butant en position 8 sont
supprim�s explicitement par le code pare-feu (un message doit
appara�tre dans le syslog si cel� arrive).
Par exemple, la r�gle suivante supprimera tout fragment allant sur
192.168.1.1 :
# ipchains -A output -f -d 192.168.1.1 -j DENY
#
Effets de bord du filtrage
OK, maintenant nous connaissons tous les moyens pour v�rifier un
paquet en utilisant une r�gle. Si un paquet v�rifie une r�gle, les
choses suivantes arrivent :
1. Le compteur d'octets de cette r�gle est augment� de la taille de
ce paquet (ent�te et autres) ;
2. Le compteur de paquets de cette r�gle est incr�ment� ;
3. Si la r�gle le demande, le paquet est enregistr� ;
4. Si la r�gle le demande, le champ "Type Of Service" du paquet est
modifi� ;
5. Si la r�gle le demande, le paquet est marqu� (sauf dans la s�rie
des noyaux 2.0) ;
6. La destination de la r�gle est examin�e afin de d�cider ce que
nous ferons ensuite du paquet.
Pour la diversit�, je d�taillerai ceux-ci en ordre d'importance.
Sp�cifier une destination
Une _destination_ dit au noyau ce qu'il doit faire d'un paquet qui
v�rifie une r�gle. ipchains utilise "-j" (penser � "jump-to") pour la
sp�cification de la destination. Le nom de la cible doit comporter
moins de 8 caract�res, et la casse intervient : "RETOUR" et "retour"
sont totalement diff�rents.
Le cas le plus simple est lorsqu'il n'y a pas de destination
sp�cifi�e. Ce type de r�gle (souvent appell�e r�gle de "comptage") est
utile pour simplement compter un certain type de paquet. Que cette
r�gle soit v�rifi�e ou non, le noyau examine simplement la r�gle
suivante dans la cha�ne. Par exemple, pour compter le nombre de
paquets venant de 192.168.1.1, nous pouvons faire ceci :
# ipchains -A input -s 192.168.1.1
#
(En utilisant "ipchains -L -v" nous pouvons voir les compteurs de
paquets et d'octets associ�s � chaque r�gle).
Il y a six destinations sp�ciales. Les trois premi�res, ACCEPT, REJECT
et DENY sont relativement simples. ACCEPT autorise le passage du
paquet. DENY supprime le paquet comme s'il n'avait jamais �t� re�u.
REJECT supprime le paquet, mais (si ce n'est pas un paquet ICMP)
g�n�re une r�ponse ICMP vers la source pour lui dire que la
destination n'est pas accessible.
La suivante, MASQ dit au noyau de camoufler le paquet. Pour que ceci
fonctionne, votre noyau doit �tre compil� avec le camouflage IP
int�gr�. Pour les d�tails sur ceci, voyez le Masquerading-HOWTO et
l'annexe Diff�rences entre ipchains et ipfwadm. Cette destination est
valide uniquement pour les paquets qui traversent la cha�ne forward.
L'autre destination majeure sp�ciale est REDIRECT qui demande au noyau
d'envoyer un paquet vers un port local au lieu de l� o� il �tait
destin�. Ceci peut �tre sp�cifi� uniquement pour les r�gles sp�cifiant
TCP ou UDP en tant que protocole. Optionnellement, un port (nom ou
num�ro) peut �tre sp�cifi� apr�s "-j REDIRECT" qui redirigera la
paquet vers ce port particulier, m�me si celui-ci �tait dirig� vers un
autre port. Cette destination est valide uniquement pour les paquets
traversant la cha�ne input.
La derni�re destination sp�ciale est la RETURN qui est identique � une
terminaison imm�diate de la cha�ne (voir Choisir une police plus bas).
Toute autre destination indique une cha�ne d�finie par l'utilisateur
(d�crite dans Op�rations sur une cha�ne enti�re plus bas). Le paquet
traversera tout d'abord les r�gles de cette cha�ne. Si cette cha�ne ne
d�cide pas du destin du paquet, lorsque la travers�e de cette cha�ne
sera achev�e, la travers�e reprendra sur la r�gle suivante de la
cha�ne courante.
Il est temps de faire encore un peu d'art ASCII. Consid�rons deux
(�tranges) cha�nes : input (la cha�ne int�gr�e) et Test (une cha�ne
d�finie par l'utilisateur).
`input' `Test'
----------------------------- -----------------------------
| R�gle1: -p ICMP -j REJECT | | R�gle1: -s 192.168.1.1 |
|---------------------------| |---------------------------|
| R�gle2: -p TCP -j Test | | R�gle2: -d 192.168.1.1 |
|---------------------------| -----------------------------
| R�gle3: -p UDP -j DENY |
-----------------------------
Consid�rons un paquet TCP venant de 192.168.1.1, allant vers 1.2.3.4.
Il p�n�tre dans la cha�ne input, et est test� par la R�gle1 - pas de
correspondance. La R�gle2 correspond, et sa destination est Test, donc
la r�gle suivante � examiner est le d�but de Test. La R�gle1 de Test
correspond, mais ne sp�cifie pas de destination, donc la r�gle
suivante est examin�e (R�gle2). Elle ne correspond pas, nous avons
donc atteint la fin de la cha�ne. Nous retournons alors � la cha�ne
input, dont nous avons juste examin� la R�gle2, et nous examinons
alors la R�gle3, qui ne correspond pas non plus.
Le chemin suivi par le paquet est donc le suivant :
v __________________________
`entr�e' | / `Test' v
------------------------|--/ -----------------------|----
| R�gle1 | /| | R�gle1 | |
|-----------------------|/-| |----------------------|---|
| R�gle2 / | | R�gle2 | |
|--------------------------| -----------------------v----
| R�gle3 /--+---------------------------/
------------------------|---
v
Voyez la section Comment organiser vos r�gles pare-feu pour les moyens
d'utiliser efficacement les cha�nes d�finies par l'utilisateur.
Enregistrement des paquets
C'est un effet de bord que la v�rification d'une r�gle peut avoir ;
vous pouvez enregistrer les paquets v�rifi�s en utilisant l'option
"-l". Vous n'aurez g�n�ralement pas besoin de ceci pour les paquets
habituels, mais ce peut �tre une option tr�s utile si vous d�sirez
�tre tenu au courant des �v�nements exceptionnels.
Le noyau enregistre cette information de la mani�re suivante :
Packet log: input DENY eth0 PROTO=17 192.168.2.1:53 192.168.1.1:1025
L=34 S=0x00 I=18 F=0x0000 T=254
Ce message d'information est pr�vu pour �tre concis, et contient des
informations techniques qui ne sont utiles qu'aux gourous r�seau, mais
qui peuvent n�anmoins �tre int�ressantes pour le commun des mortels.
Il se d�compose de la fa�on suivante :
1. `input' est la cha�ne qui contenait la r�gle correspondant au
paquet, et qui a caus� l'apparition du message.
2. `DENY' est ce que la r�gle a dit au paquet de faire. Si ceci est
un `-' alors la r�gle n'a pas du tout affect� le paquet (une r�gle
de comptage).
3. `eth0' est le nom de l'interface. Puisque ceci �tait la cha�ne
d'entr�e, cel� signifie que le paquet vient de `eth0'.
4. `PROTO=17' signifie que le paquet �tait de protocole 17. Une liste
des num�ros de protocoles est donn�e dans `/etc/protocols'. Les
plus communs sont 1 (ICMP), 6 (TCP) et 17 (UDP).
5. `192.168.2.1' signifie que l'adresse IP source du paquet �tait
192.168.2.1.
6. `:53' signifie que le port source �tait le port 53. En regardant
dans `/etc/services' on voit que ceci est le port `domain' (c�d
que c'est probablement une r�ponse DNS). Pour UDP et TCP, ce
num�ro est le port source. Pour ICMP, c'est le type ICMP. Pour les
autres, ce sera 65535.
7. `192.168.1.1' est l'adresse IP de destination.
8. `:1025' signifie que le port de destination �tait 1025. Pour UDP
et TCP, ce num�ro est le port de destination. Pour ICMP, il s'agit
du code ICMP. Pour les autres, ce sera 65535.
9. `L=34' signifie que le paquet avait une longueur totale de 34
octets.
10. `S=0x00' est le champ "Type Of Service" (divisez par 4 pour
obtenir le Type of Service utilis� par ipchains).
11. `I=18' est l'identificateur de l'IP.
12. `F=0x0000' est l'offset du fragment 16 bits, avec les options. Une
valeur d�butant par `0x4' ou `0x5' signifie que le bit "Don't
Fragment" (ne pas fragmenter) est mis. `0x2' ou `0x3' signifie que
le bit "More Fragments" (des fragments suivent) est mis ; attendez
vous � recevoir plus de fragments apr�s. Le reste du nombre est le
d�calage de ce fragment, divis� par 8.
13. `T=254' est la dur�e de vie du paquet. On soustrait 1 � cette
valeur � chaque saut (hop), et on d�bute g�n�ralement � 15 ou 255.
14. `(#5)' il peut y avoir un num�ro entre parenth�ses sur les noyaux
les plus r�cents (peut-�tre apr�s le 2.2.9). Il s'agit du num�ro
de la r�gle qui a caus� l'enregistrement du paquet.
Sur les syst�mes Linux standards, la sortie du noyau est captur�e par
klogd (d�mon d'information du noyau) qui le repasse � syslogd (d�mon
d'information du syst�me). Le fichier `/etc/syslog.conf' contr�le le
comportement de syslogd, en sp�cifiant une destination pour chaque
"partie" (dans notre cas, la partie est le "noyau") et un "niveau"
(pour ipchains, le niveau utilis� est "info").
Par exemple, mon /etc/syslog.conf (Debian) contient deux lignes qui
v�rifient `kern.info' :
kern.* -/var/log/kern.log
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none -/var/log/messages
Ceci signifie que les messages sont dupliqu�s dans `/var/log/kern.log'
et `/var/log/messages'. Pour plus de d�tails, voyez `man syslog.conf'.
Manipuler le type de service
Il y a quatre bits utilis�s par eux-m�mes dans l'ent�te IP, appel�s
les bits de _Type of Service_ (TOS). Ceux-ci ont pour effet de
modifier la mani�re dont les paquets sont trait�s : les quatres bits
sont "Minimum Delay", "Maximum Throughput", "Maximum Reliability" et
"Minimum Cost". Un seul de ces bits est autoris� � �tre plac�. Rob van
Nieuwkerk, l'auteur du code de gestion du TOS, les d�crit comme suit :
Tout sp�cialement, le "Minimum Delay" est important pour moi. Je le
mets pour les paquets "interactifs" dans mon routeur principal
(Linux). Je suis derri�re une connexion modem 33,6k. Linux rend les
paquets prioritaires en 3 queues. De cette fa�on, j'obtiens des
performances interactives acceptables tout en faisant de gros
transferts de fichiers en m�me temps. (Cel� pourrait m�me �tre
encore mieux s'il n'y avait pas de grosse queue dans le pilote
s�rie, mais le temps de latence est maintenu en dessous des 1,5
secondes pour l'instant).
Note : bien entendu, vous n'avez aucun contr�le sur les paquets
arrivants ; vous pouvez seulement contr�ler la priorit� des paquets
qui quittent votre machine. Pour n�gocier les priorit�s de chaque
c�t�, un protocole comme RSVP (dont je ne connais rien) doit �tre
utilis�.
L'utilisation la plus commune est de placer les connexions telnet et
contr�le du ftp en "Minimum Delay" et les donn�es FTP en "Maximum
Throughput". Ceci peut �tre fait de la mani�re suivante :
ipchains -A output -p tcp -d 0.0.0.0/0 telnet -t 0x01 0x10
ipchains -A output -p tcp -d 0.0.0.0/0 ftp -t 0x01 0x10
ipchains -A output -p tcp -s 0.0.0.0/0 ftp-data -t 0x01 0x08
L'option "-t" prend deux param�tres suppl�mentaires, tous les deux en
hexad�cimal. Ceci permet un contr�le complexe des bits du TOS : le
premier masque est AND� avec le TOS actuel du paquet, et ensuite le
deuxi�me masque est XOR� avec lui. Si cel� est trop confus, utilisez
simplement le tableau suivant :
Nom du TOS Valeur Utilisations typiques
Minimum Delay 0x01 0x10 ftp, telnet
Maximum Throughput 0x01 0x08 ftp-data
Maximum Reliability 0x01 0x04 snmp
Minimum Cost 0x01 0x02 nntp
Andi Kleen revient sur ce point pour ce qui suit (mod�r�ment �dit�
pour la post�rit�) :
Peut-�tre serait-il utile d'ajouter une r�f�rence au param�te
txqueuelen de ifconfig dans la discussion sur les bits TOS. La
longueur par d�faut de la queue d'un p�riph�rique est r�gl�e pour
les cartes ethernet, sur les modems elle est trop longue et rend le
fonctionnement de la planification 3 bandes (qui place la queue en
fonction du TOS) sous-optimal. C'est donc une bonne id�e de le
configurer avec une valeur comprise entre 4 et 10 sur un modem ou
un lien RNIS b simple : sur les p�riph�riques rapide une queue plus
longue est n�cessaire. C'est un probl�me des 2.0 et 2.1, mais dans
le 2.1 c'est une option de ifconfig (dans les nettools r�cents),
alors que dans le 2.0 il n�cessite une modification des sources des
pilotes du p�riph�rique pour le changer.
Ainsi, pour voir les b�n�fices maximum des changements de TOS pour les
liaisons modem PPP, ajoutez un `ifconfig $1 txqueuelen' dans votre
script /etc/ppp/ip-up. Le nombre � utiliser d�pend de la vitesse du
modem et de la taille du tampon du modem ; voici � nouveau les id�es
d'Andi :
La meilleure valeur pour une configuration donn�e n�cessite de
l'exp�rimentation. Si les queues sont trop courtes sur le routeur,
alors les paquets sauteront. Bien s�r, on peut toujours gagner m�me
sans changer le TOS, c'est juste que le changement du TOS aide �
gagner les b�n�fices sur les programmes non coop�ratifs (mais tous
les programmes Linux standards sont coop�ratifs).
Marquage d'un paquet
Ceci permet des interactions complexes et puissantes avec la nouvelle
impl�mentation de Quality of Service d'Alexey Kuznetsov, ainsi que de
la redirection bas�e sur le marquage dans la derni�re s�rie de noyaux
2.1. Des d�tails suppl�mentaires vont arriver puisque nous l'avons
dans la main. Cette option est toutefois ignor�e dans la s�rie des
noyaux 2.0.
Op�rations sur une cha�ne enti�re
Une des options les plus utiles d'ipchains est la possibilit� de
regrouper des r�gles dans des cha�nes. Vous pouvez appeller les
cha�nes de la mani�re qui vous pla�t, tant que les noms ne sont pas
ceux des cha�nes int�gr�es (input, output et forward) ou des
destinations ((MASQ, REDIRECT, ACCEPT, DENY, REJECT ou RETURN). Je
sugg�re d'�viter compl�tement les noms en majuscules, car je pourrais
les utiliser pour des extensions futures. Le nom de la cha�ne ne doit
pas d�passer 8 caract�res.
Cr�er une nouvelle cha�ne
Cr�ons une nouvelle cha�ne. �tant un type imaginatif, je l'appellerai
test.
# ipchains -N test
#
C'est aussi simple. Maintenant vous pouvez y rajouter des r�gles,
comme d�taill� ci-dessus.
Supprimer une cha�ne
La suppression d'une cha�ne est tout aussi simple.
# ipchains -X test
#
Pourquoi "-X" ? Eh bien, toutes les bonnes lettres �taient d�j�
prises.
Il y a quelques restrictions � la suppression des cha�nes : elles
doivent �tre vides (voir Vider une cha�ne plus bas) et elles ne
doivent pas �tre la destination d'une quelconque r�gle. Vous ne pouvez
pas supprimer les cha�nes int�gr�es.
Vider une cha�ne
Il y a un moyen simple de vider toutes les r�gles d'une cha�ne, en
utilisant la commande "-F".
# ipchains -F forward
#
Si vous ne sp�cifiez pas de cha�ne, alors _toutes_ les cha�nes seront
vid�es.
Afficher une cha�ne
Vous pouvez afficher toutes les r�gles d'une cha�ne en utilisant la
commande "-L".
# ipchains -L input
Chain input (refcnt = 1): (policy ACCEPT)
target prot opt source destination ports
ACCEPT icmp ----- anywhere anywhere any
# ipchains -L test
Chain test (refcnt = 0):
target prot opt source destination ports
DENY icmp ----- localnet/24 anywhere any
#
La "refcnt" list�e pour test est le nombre de r�gles qui ont test
comme destination. Ceci doit �tre �gal � z�ro (et la cha�ne doit �tre
vide) avant que cette cha�ne ne puisse �tre supprim�e.
Si le nom de la cha�ne est omis, toutes les cha�nes sont list�es, m�me
les cha�nes vides.
Il y a trois options qui peuvent accompagner "-L". L'option "-n"
(num�rique) est tr�s utile et emp�che ipchains d'essayer de v�rifier
les adresses IP, ce qui (si vous utilisez DNS comme la plupart des
gens) causera de longs d�lais si votre DNS n'est pas configur�
proprement, ou si vous filtrez les requ�tes DNS. Ceci affichera
�galement les ports par leur num�ro plut�t que par leur nom.
L'option "-v" vous montrera tous les d�tails des r�gles, comme les
compteurs de paquets et d'octets, les masques de TOS, l'interface, et
les marques de paquets. Autrement, ces valeurs seront omises. Par
exemple :
# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
pkts bytes target prot opt tosa tosx ifname mark source destination po
rts
10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere an
y
Notez que les compteurs de paquets et d'octets sont affich�s en
utilisant les suffixes "K", "M" ou "G" pour 1000, 1.000.000 et
1.000.000.000, respectivement. En utilisant �galement l'option "-x"
(d�veloppe les nombres), ipchains affichera les nombres en entier,
quelque soit leur taille.
Remise � z�ro des compteurs
Il est parfois utile de pouvoir remettre � z�ro les compteurs. Ceci
peut �tre fait par l'option "-Z" (compteurs � Z�ro). Par exemple :
# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
pkts bytes target prot opt tosa tosx ifname mark source destination po
rts
10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere an
y
# ipchains -Z input
# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
pkts bytes target prot opt tosa tosx ifname mark source destination
ports
0 0 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere
any
#
Le probl�me de cette approche est que parfois vous voudrez conna�tre
les valeurs du compteur tout de suite apr�s la remise � z�ro. Dans
l'exemple ci-dessus, quelques paquets peuvent passer entre les
commandes "-L" et "-Z". Pour cette raison, vous pouvez utiliser le
"-L" et le "-Z" _ensemble_, pour remettre � z�ro les compteurs tout en
les lisant. Malheureusement, si vous fa�tes ceci, vous ne pouvez
op�rer sur une seule cha�ne : vous devrez lister et remettre � z�ro
toutes les cha�nes en une seule fois.
# ipchains -L -v -Z
Chain input (policy ACCEPT):
pkts bytes target prot opt tosa tosx ifname mark source destination
ports
10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere
any
Chain forward (refcnt = 1): (policy ACCEPT)
Chain output (refcnt = 1): (policy ACCEPT)
Chain test (refcnt = 0):
0 0 DENY icmp ----- 0xFF 0x00 ppp0 localnet/24 anywhere
any
# ipchains -L -v
Chain input (policy ACCEPT):
pkts bytes target prot opt tosa tosx ifname mark source destination
ports
10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere
any
Chain forward (refcnt = 1): (policy ACCEPT)
Chain output (refcnt = 1): (policy ACCEPT)
Chain test (refcnt = 0):
0 0 DENY icmp ----- 0xFF 0x00 ppp0 localnet/24 anywhere
any
#
Choisir une police
Nous avons dissert� sur ce qui se passe lorsqu'un paquet atteint la
fin de la cha�ne int�gr�e, lorsque nous avons discut� sur la mani�re
dont un paquet parcourait les cha�nes dans Sp�cifier une destination
plus haut. Dans ce cas, la _police_ de la cha�ne d�termine le destin
du paquet. Seules les cha�nes int�gr�es (input, output et forward) ont
des polices, car si un paquet atteint la fin d'une cha�ne d�finie par
l'utilisateur, le paquet revient sur la cha�ne pr�c�dente.
La police peut �tre une des quatre premi�res destinations sp�ciales :
ACCEPT, DENY, REJECT ou MASQ. MASQ est la seule destination valide
pour la cha�ne "forward".
Il est �galement important de noter qu'une destination RETURN dans une
r�gle de l'une des cha�nes int�gr�es est utile pour expliciter la
destination de la cha�ne lorsqu'un paquet correspond � la r�gle.
Op�rations sur le camouflage
Il y a plusieurs param�tres que vous pouvez modifier pour le
camouflage IP. Ils sont int�gr�s avec ipchains car il n'est pas
�vident d'�crire un outil s�par� pour eux (bien que ceci devrait
changer).
La commande du camouflage IP est "-M", et peut �tre combin�e avec "-L"
pour lister les connexions actuellement camoufl�es, ou avec "-S" pour
configurer les param�tres du camouflage.
La commande "-L" peut �tre accompagn�e par "-n" (montre des nombres �
la place des noms de machines et de ports) ou "-v" (affiche les deltas
dans les s�quences de nombres pour la connexion camoufl�e, au cas o�
vous vous demanderiez).
La commande "-S" doit �tre suivie par trois valeurs de fin d'attente,
toutes en secondes : pour les sessions TCP, pour les sessions TCP
pr�c�d�es d'un paquet FIN, et pour les paquets UDP. Si vous ne voulez
pas changer l'une de ces valeurs, donnez-lui simplement une valeur de
"0".
Les valeurs par d�faut sont list�es dans
"/usr/src/linux/include/net/ip_masq.h", actuellement 15 minutes, 2
minutes et 5 minutes, respectivement.
La valeur chang�e le plus souvent est la premi�re, pour le FTP (voir
Cauchemars du FTP plus bas).
Notez que les probl�mes avec la mise en place de temps de fin
d'attente sont list�s dans Je n'arrive pas � configurer mes temps
d'attente !.
V�rifier un paquet
Parfois, vous voulez savoir ce qui arrive lorsqu'un certain paquet
entre dans votre machine, par exemple pour d�boguer votre cha�ne
pare-feu. ipchains dispose de la commande "-C" pour autoriser cel�, en
utilisant exactement les m�mes routines que celles que le noyau
utilise pour v�rifier les vrais paquets.
Vous sp�cifiez sur quelle cha�ne le paquet doit �tre test� en mettant
son nom apr�s l'argument "-C". M�me si le noyau commence toujours par
traverser les cha�nes input, output ou forward, vous �tes autoris� �
commencer en traversant n'importe quelle cha�ne pour tester.
Les d�tails du "paquet" sont sp�cifi�s en utilisant la m�me syntaxe
que celle utilis�e pour sp�cifier les r�gles pare-feu. En particulier,
un protocole ("-p"), une adresse source ("-s"), une adresse de
destination ("-d") et une interface ("-i") sont n�cessaires. Si le
protocole est TCP ou UDP, alors une source unique et une destination
unique doivent �tre sp�cifi�es, et un type et un code ICMP doivent
�tre sp�cifi�s pour le protocole ICMP (� moins que l'option "-f" soit
sp�cifi�e pour indiquer une r�gle de fragment, auquel cas ces options
sont ill�gales).
Si le protocole est TCP (et que l'option "-f" n'est pas sp�cifi�e),
l'option "-y' doit �tre explicit�e, afin d'indiquer que le paquet test
doit �tre configur� avec le bit SYN.
Voici un exemple de test d'un paquet TCP SYN venant de 192.168.1.1,
port 60000, et allant sur 192.168.1.2, port www, arrivant de
l'interface eth0 et entrant dans la cha�ne "input" (il s'agit d'une
initialisation classique d'une connexion WWW) :
# ipchains -C input -p tcp -y -i eth0 -s 192.168.1.1 60000 -d 192.168.1.2 www
packet accepted
#
Voir ce qui arrive avec des r�gles multiples pr�cis�es en une seule fois
Parfois, une simple ligne de commande peut affecter de multiples
r�gles. Ceci se fait par deux m�thodes. Premi�rement, si vous
sp�cifiez un nom de machine qui correspond (en utilisant DNS) � de
multiples adresses IP, ipchains agira comme si vous aviez tap� de
multiples commandes avec chaque combinaison d'adresses.
Ainsi, si le nom de machine "www.foo.com" correspond � trois adresses
IP, et si le nom de machine "www.bar.com" correspond � deux adresses
IP, alors la commande "ipchains -A input -j reject -s www.bar.com -d
www.foo.com" ajoutera six r�gles � la cha�ne input.
L'autre m�thode pour avoir ipchains r�alisant de multiples actions est
d'utiliser l'option bidirectionnelle ("-b"). Cette option fait agir
ipchains comme si vous aviez tap� la commande deux fois, la deuxi�me
fois avec les arguments "-s" et "-d" invers�s. Ainsi, pour �viter la
transmission soit de, soit vers 192.168.1.1, vous pourriez utiliser la
commande :
# ipchains -b -A forward -j reject -s 192.168.1.1
#
Personnellement, je n'aime pas beaucoup l'option "-b" ; si vous
pr�f�rez la convivialit�, voyez Utiliser ipchains-save plus bas.
L'option -b peut �tre utilis�e avec les commandes ins�rer ("-I"),
supprimer ("-D") (mais pas avec la variation qui prend un num�ro de
r�gle), ajouter ("-A") et v�rifier ("-C").
Une autre option utile est "-v" (bruyant) qui imprime exactement ce
que ipchains fait avec vos commandes. Ceci est utile si vous traitez
avec des commandes qui peuvent affecter de multiples r�gles. Par
exemple, nous devons ici v�rifier le comportement de fragments entre
192.168.1.1 et 192.168.1.2.
# ipchains -v -b -C input -p tcp -f -s 192.168.1.1 -d 192.168.1.2 -i lo
tcp opt ---f- tos 0xFF 0x00 via lo 192.168.1.1 -> 192.168.1.2 * ->
*
packet accepted
tcp opt ---f- tos 0xFF 0x00 via lo 192.168.1.2 -> 192.168.1.1 * ->
*
packet accepted
#
4.2 Exemples utiles
J'ai une connexion intermittente en PPP (-i ppp0). Je r�cup�re les
news (-p TCP -s news.virtual.net.au nntp) et le courrier (-p TCP -s
mail.virtual.net.au pop-3) � chaque fois que je me connecte. J'utilise
la m�thode ftp de Debian pour mettre ma machine � jour r�guli�rement
(-p TCP -y -s ftp.debian.org.au ftp-data). Je visionne le web au
travers du proxy de mon FAI (Fournisseur d'Acc�s Internet) lorsque je
suis en ligne (-p TCP -d proxy.virtual.net.au 8080), mais je d�teste
les publicit�s de doubleclick.net des Archives de Dilbert (-p TCP -y
-d 199.95.207.0/24 et -p TCP -y -d 199.95.208.0/24).
J'autorise les gens � essayer le ftp sur ma machine lorsque je suis en
ligne (-p TCP -d $LOCALIP ftp), mais je n'autorise personne de
l'ext�rieur � pr�tendre avoir une adresse IP sur mon r�seau interne
(-s 192.168.1.0/24). Ceci est commun�ment appel� IP spoofing, et il y
a un meilleur moyen de se prot�ger dans les noyaux 2.1.x et suivants :
voir Comment mettre en place la protection contre l'IP spoof ?.
Cette configuration est relativement simple, car il n'y a pour
l'instant aucune autre machine sur mon r�seau interne.
Je ne veux pas que des processus locaux (ie. Netscape, lynx, etc.) se
connectent � doubleclick.net :
# ipchains -A output -d 199.95.207.0/24 -j REJECT
# ipchains -A output -d 199.95.208.0/24 -j REJECT
#
Maintenant je d�sire changer les priorit�s des divers paquets sortants
(il n'y a pas vraiment d'int�r�t � le faire pour les paquets
entrants). Puisqu'il y a un certain nombre de ces r�gles, il y a
int�r�t � les mettre ensemble dans une seule cha�ne, nomm�e ppp-out.
# ipchains -N ppp-out
# ipchains -A output -i ppp0 -j ppp-out
#
D�lai minimal pour le trafic web et telnet :
# ipchains -A ppp-out -p TCP -d proxy.virtual.net.au 8080 -t 0x01 0x10
# ipchains -A ppp-out -p TCP -d 0.0.0.0 telnet -t 0x01 0x10
#
Co�t faible pour les donn�es ftp, nntp et pop-3 :
# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 ftp-data -t 0x01 0x02
# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 nntp -t 0x01 0x02
# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 pop-3 -t 0x01 0x02
#
Il y a quelques restrictions sur les paquets venant de l'interface
ppp0 ; cr�ons une cha�ne nomm�e "ppp-in" :
# ipchains -N ppp-in
# ipchains -A input -i ppp0 -j ppp-in
#
Maintenant, aucun des paquets venant de ppp0 ne doit pr�tendre avoir
une adresse source de la forme 192.168.1.*, donc nous les enregistrons
et les interdisons :
# ipchains -A ppp-in -s 192.168.1.0/24 -l -j DENY
#
J'autorise l'entr�e des paquets UDP pour le DNS (je fais tourner un
serveur de nom cache qui renvoie toutes les demandes sur 203.29.16.1,
donc je m'attend � des r�ponses DNS venant uniquement de l�), l'entr�e
du ftp, et le retour des donn�es ftp (ftp-data) uniquement (ce qui
doit �tre uniquement entre un port strictement sup�rieur � 1023, et
pas sur les ports X11 autour de 6000).
# ipchains -A ppp-in -p UDP -s 203.29.16.1 -d $LOCALIP dns -j ACCEPT
# ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 1024:5999 -j ACCE
PT
# ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 6010: -j ACCEPT
# ipchains -A ppp-in -p TCP -d $LOCALIP ftp -j ACCEPT
#
Enfin, les paquets local vers local sont OK :
# ipchains -A input -i lo -j ACCEPT
#
Maintenant, ma police par d�faut sur la cha�ne input est DENY, ce qui
fait que tout le reste dispara�t :
# ipchains -P input DENY
#
NOTE : Je ne configurerais pas mes cha�nes dans cet ordre, car des
paquets pourraient passer durant la configuration. Le moyen le plus
s�r est g�n�ralement de configurer la police � DENY tout d'abord, et
ensuite d'ins�rer les r�gles. Bien s�r, si vos r�gles ont besoin
d'effectuer des demandes DNS pour r�soudre des noms de machines, vous
pourriez avoir des probl�mes.
Utiliser ipchains-save
Configurer des cha�nes pare-feu de la mani�re exacte dont vous le
voulez, et se rappeller ensuite des commandes que vous avez utilis�
pour le faire la fois suivante est insupportable.
Donc, ipchains-save est un script qui lit votre configuration actuelle
des cha�nes et la sauve dans un fichier. Pour le moment, je
conserverais le suspens en ce qui concerne l'utilit� de
ipchains-restore.
ipchains-save peut sauver une cha�ne seule, ou toutes les cha�nes (si
aucun nom de cha�ne n'a �t� sp�cifi�). La seule option actuellement
autoris�e est le "-v" qui affiche les r�gles (vers stderr)
lorsqu'elles sont sauv�es. La police de la cha�ne est aussi sauv�e
pour les cha�nes input, output et forward.
# ipchains-save > my_firewall
Saving `input'.
Saving `output'.
Saving `forward'.
Saving `ppp-in'.
Saving `ppp-out'.
#
Utiliser ipchains-restore
ipchains-restore remet les cha�nes que vous avez sauv� avec
ipchains-save. Il peut prendre deux options : "-v" qui d�crit chaque
r�gle lorsqu'elle est ajout�e, et "-f" qui force le nettoyage des
cha�nes d�finies par l'utilisateur si elles existent, comme d�crit
plus bas.
Si une cha�ne d�finie par l'utilisateur est trouv�e � l'entr�e,
ipchains-restore v�rifie que cette cha�ne existe d�j�. Si elle existe,
alors vous serez interrog� pour savoir si la cha�ne doit �tre nettoy�e
(suppression de toutes les r�gles) ou si la restauration de la cha�ne
doit �tre saut�e. Si vous sp�cifiez "-f" sur la ligne de commande,
vous ne serez pas interrog� ; la cha�ne sera nettoy�e.
Par exemple :
# ipchains-restore < my_firewall
Restoring `input'.
Restoring `output'.
Restoring `forward'.
Restoring `ppp-in'.
Chain `ppp-in' already exists. Skip or flush? [S/f]? s
Skipping `ppp-in'.
Restoring `ppp-out'.
Chain `ppp-out' already exists. Skip or flush? [S/f]? f
Flushing `ppp-out'.
#
5. Divers
Cette section contient toutes les informations et les questions
fr�quemment pos�es que je ne pouvais faire entrer dans la structure
ci-dessus.
5.1 Comment organiser vos r�gles pare-feu
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
5.2 Ce qu'il ne faut pas filtrer
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
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.
Connexions TCP au DNS (serveur de nom)
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.
Cauchemars du FTP
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).
5.3 Filtrer le ping de la mort (Ping of Death)
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.
5.4 Filtrer teardrop et bonk
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.
5.5 Filtrer les bombes � fragments
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).
5.6 Changer les r�gles pare-feu
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.
5.7 Comment mettre en place la protection contre l'IP spoof ?
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
#
5.8 Projets avanc�s
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.
SPF : Stateful Packet Filtering
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.
Modification des donn�es ftp par Michael Hasenstein
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
5.9 Extensions futures
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).
6. Probl�mes classiques
6.1 ipchains -L est gel� !
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.
6.2 Le camouflage/redirection ne fonctionne pas !
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.
6.3 -j REDIR ne marche pas !
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.
6.4 Les interfaces joker ne fonctionnent pas !
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.
6.5 TOS ne fonctionne pas !
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.
6.6 ipautofw et ipportfw ne fonctionnent pas !
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.
6.7 XosView ne marche pas !
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 !).
6.8 Erreur de segmentation avec -j REDIRECT !
C'�tait une erreur dans ipchains version 1.3.3. Veuillez mettre �
jour.
6.9 Je ne peux pas modifier les temps d'attente du camouflage !
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.
6.10 Je veux firewaller IPX !
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.
7. Un exemple s�rieux
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.
7.1 L'arrangement
* Un r�seau interne camoufl� (sous divers syst�mes d'exploitation),
que nous appellerons "BON" ;
* des serveurs expos�s dans un r�seau s�par� (nomm� "ZDM" pour Zone
D�militaris�e) ;
* une connexion PPP � l'Internet (nomm� "MAUVAIS").
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)
7.2 Buts
Sur la machine filtrant les paquets :
_PING tout r�seau_
Tr�s utile si la machine est hors-service.
_TRACEROUTE tout r�seau_
Une fois de plus, utile pour les diagnostics.
_Acc�s au DNS_
Pour rendre ping et DNS plus utile.
� l'int�rieur de la Zone D�militaris�e :
Serveur mail
* SMTP vers l'ext�rieur
* Accepte le SMTP de l'int�rieur et de l'ext�rieur
* Accepte le POP3 de l'int�rieur
Serveur de nom
* Envoi de requ�tes DNS vers l'ext�rieur
* Accepte les requ�tes DNS de l'int�rieur, l'ext�rieur, et du filtre
de paquets
Serveur web
* Accepte les requ�tes HTTP de l'int�rieur et de l'ext�rieur
* Acc�s rsync de l'int�rieur
En interne :
_Autorise WWW, ftp, traceroute et ssh vers l'ext�rieur_
Ce sont des services standards � autoriser : on autorise
parfois les machines internes � tout faire, mais ici nous
serons plus restrictifs.
_Autorise le SMTP vers le serveur mail_
Bien entendu, nous voulons qu'il leur soit possible d'envoyer
du courrier vers l'ext�rieur.
_Autorise le POP3 vers le serveur mail_
C'est ainsi qu'ils lisent leur courrier.
_Autorise les requ�tes DNS vers le serveur de nom_
Ils doivent pouvoir rechercher des noms externes pour le web,
le ftp, traceroute ou ssh.
_Autorise rsync vers le serveur web_
C'est ainsi qu'ils synchronisent le serveur web externe avec
l'interne.
_Autorise les requ�tes WWW vers le serveur web_
Bien entendu, nous voulons qu'ils puissent se connecteur au
serveur web externe.
_Autorise le ping vers le filtre de paquets_
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�).
7.3 Avant le filtrage des paquets
* Protection anti-spoofing
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
#
* Mettre en place des r�gles de filtrage en interdiction (DENY)
totale :
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
#
* Configurer les interfaces
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.
* Insertion des modules de camouflage par protocole
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
#
7.4 Filtrage de paquets pour les paquets traversants
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
Configurer les sauts de la cha�ne de transmission
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
D�finir la cha�ne icmp-acc
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
Bon (interne) vers ZDM (serveurs)
Restrictions internes :
* Autorise WWW, ftp, traceroute, ssh vers l'ext�rieur
* _Autorise le SMTP vers le serveur mail_
* _Autorise le POP3 vers le serveur mail_
* _Autorise les requ�tes DNS vers le serveur de nom_
* _Autorise le rsync vers le serveur web_
* _Autorise le WWW vers le serveur web_
* Autorise le ping vers le filtre de paquets
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
Mauvais (ext�rieur) vers ZDM (serveurs)
* Restrictions de la ZDM :
+ Serveur mail :
o _SMTP vers l'ext�rieur_
o _Accepte le SMTP venant_ de l'int�rieur et _ext�rieur_
o Accepte le POP3 de l'int�rieur
+ Serveur de noms :
o _Envoi de requ�tes DNS vers l'ext�rieur_
o _Accepte le DNS venant_ de l'int�rieur, _ext�rieur_ et
du filtre de paquets
+ Serveur web :
o _Accepte les requ�tes HTTP venant de_ l'int�rieur et de
_l'ext�rieur_
o Acc�s rsync de l'int�rieur
* Les trucs � autoriser du r�seau ext�rieur vers la ZDM
+ N'enregistre pas les violations, elles peuvent arriver.
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
Bon (int�rieur) vers Mauvais (ext�rieur).
* Restrictions internes :
+ _Autorise le WWW, ftp, traceroute, ssh vers l'ext�rieur_
+ Autorise SMTP vers le serveur mail
+ Autorise POP-3 vers le serveur mail
+ Autorise DNS vers le serveur de nom
+ Autorise rsync vers le serveur web
+ Autorise WWW vers le serveur web
+ Autorise ping vers le filtre de paquets
* Un grand nombre de gens autorisent tout venant de l'int�rieur vers
les r�seaux ext�rieurs, puis ajoutent des restrictions. Nous
sommes fascistes.
+ Enregistre les violations.
+ Le ftp passif est g�r� par le module de camouflage.
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
ZDM vers Bon (int�rieur)
* Restrictions internes :
+ Autorise WWW, ftp, traceroute, ssh vers l'ext�rieur
+ _Autorise SMTP vers le serveur mail_
+ _Autorise POP3 vers le serveur mail_
+ _Autorise DNS vers le serveur de noms_
+ _Autorise rsync vers le serveur web_
+ _Autorise WWW vers le serveur web_
+ Autorise ping vers le filtre de paquets
* Si nous camouflions le r�seau int�rieur de la ZDM, nous
refuserions simplement les paquets venant d'un autre moyen. Tel
quel, il autorise uniquement les paquets qui peuvent provenir
d'une connexion pr�-�tablie.
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
ZDM vers Mauvais (ext�rieur)
* Restrictions de la ZDM :
+ Serveur mail
o _SMTP vers l'ext�rieur_
o _Accepte SMTP venant de_ l'int�rieur et de _l'ext�rieur_
o Accepte POP3 venant de l'int�rieur
+ Serveur de noms
o _Envoi de requ�tes DNS vers l'ext�rieur_
o _Accepte le DNS de_ l'int�rieur, _l'ext�rieur_ et du
filtre de paquets
+ Serveur web
o _Accepte HTTP venant de_ l'int�rieur et de _l'ext�rieur_
o Acc�s rsync de l'int�rieur
*
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
Mauvais (ext�rieur) vers Bon (int�rieur)
* Nous n'autorisons rien (de non camoufl�) � passer du r�seau
ext�rieur vers le r�seau int�rieur.
ipchains -A mauvais-bon -j REJECT
Filtrage de paquets pour la machine Linux elle-m�me
* Si nous d�sirons utiliser le filtrage de paquets sur les paquets
arrivant sur la machine elle-m�me, nous devons filtrer la cha�ne
d'entr�e. Nous cr�ons une cha�ne pour chaque interface de
destination :
ipchains -N mauvais-if
ipchains -N zdm-if
ipchains -N bon-if
* Cr�ons les sauts vers elles :
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
Interface Mauvais (ext�rieur)
* Machine de filtrage des paquets :
+ _PING tous les r�seaux_
+ _TRACEROUTE tous les r�seaux_
+ Acc�s DNS
* L'interface ext�rieure re�oit aussi des r�ponses aux paquets
camoufl�s, les erreurs ICMP leur correspondant et les r�ponses
PING.
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
Interface ZDM
* Restrictions du filtre de paquets :
+ _PING tous les r�seaux_
+ _TRACEROUTE tous les r�seaux_
+ _Acc�s DNS_
* L'interface ZDM re�oit les r�ponses DNS, ping et les erreurs ICMP
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
Interface Bon (int�rieur)
* Restrictions du filtre de paquets
+ _PING tous les r�seaux_
+ _TRACEROUTE tous les r�seaux_
+ _Acc�s DNS_
* Restrictions int�rieures :
+ Autorise WWW, ftp, traceroute, ssh vers l'ext�rieur
+ Autorise SMTP vers le serveur mail
+ Autorise POP3 vers le serveur mail
+ Autorise DNS vers le serveur de noms
+ Autorise rsync vers le serveur web
+ Autorise WWW vers le serveur web
+ _Autorise ping vers le filtre de paquets_
* L'interface int�rieure re�oit les pings, les r�ponses ping et les
erreurs ICMP.
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
7.5 Finalement
* Supprime les r�gles de bloquage :
ipchains -D input 1
ipchains -D forward 1
ipchains -D output 1
8. Annexe : diff�rences entre ipchains et ipfwadm
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.
1. De nombreux arguments ont �t� modifi�s : les majuscules indiquent
dor�navant une commande, et les minuscules indiquent une option.
2. Les cha�nes arbitraires sont support�es, ainsi m�me les cha�nes
int�gr�es ont des noms complets plut�t que des options (c�d,
"input" � la place de "-I").
3. L'option "-k" a saut� : utilisez "! -y".
4. L'option "-b" ins�re/ajoute/supprime actuellement deux r�gles,
plut�t qu'une r�gle "bidirectionnelle" simple.
5. L'option "-b" peut �tre pass�e � "-C" pour effectuer deux
v�rifications (une dans chaque direction).
6. L'option "-x" de "-l" a �t� remplac�e par "-v".
7. Les ports sources et destinations multiples ne sont plus
support�s. Heureusement, la possibilit� d'employer un intervalle
de port aura le m�me effet.
8. Les interfaces peuvent seulement �tre sp�cifi�es par leur nom (pas
par leurs adresses). L'ancienne s�mantique a �t� silencieusement
chang�e dans la s�rie des noyaux 2.1, de toute mani�re.
9. Les fragments sont examin�s, mais pas automatiquement autoris�s.
10. On s'est d�barrass� des cha�nes de comptage explicites.
11. On peut �crire des r�gles qui porteront uniquement sur certains
protocoles IP.
12. L'ancien comportement de v�rification de SYN et ACK (qui �tait
auparavant ignor� pour les paquets non TCP) a chang� ; l'option
SYN n'est plus valide pour les r�gles non sp�cifiques au TCP.
13. Les compteurs sont maintenant de 64 bits sur les machines 32 bits,
et non plus 32 bits.
14. L'inversion des options est dor�navant support�e.
15. Les codes ICMP sont maintenant support�s.
16. Les interfaces joker sont maintenant support�es.
17. Les manipulations de TOS sont maintenant v�rifi�es : l'ancien code
du noyau les stoppait silencieusement pour vous en manipulant
(ill�galement) le bit TOS "Must Be Zero" ; ipchains retourne
maintenant une erreur si vous essayez, de m�me que pour d'autres
cas ill�gaux.
8.1 Guide de r�f�rence rapide
[ 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�.
---------------------------------------------------------------------------
8.2 Exemples de commandes ipfwadm traduites
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).
9. Annexe : utiliser le script ipfwadm-wrapper
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.
10. Annexe : remerciements
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.