Cette section d�crit tout ce que vous avez r�ellement besoin de savoir pour construire un filtre de paquets adapt� � vos besoins.
Le noyau commence avec trois listes de r�gles : ces listes sont appell�es
cha�nes de protection ou juste cha�nes. Ces trois cha�nes sont
appell�es input (entr�e), output (sortie) et forward
(transmission). Lorsqu'un paquet arrive (disons, par une carte
Ethernet), le noyau utilise la cha�ne input pour d�cider de son destin.
S'il survit � ce passage, alors le noyau d�cide o� envoyer le paquet par la
suite (ceci est appel� routage). S'il est destin� � une autre machine,
il consulte alors la cha�ne de transmission. Enfin, juste avant que le
paquet ne ressorte, le noyau consulte la cha�ne de sortie.
Une cha�ne est une v�rification de r�gles. Chaque r�gle dit `si l'ent�te de ce paquet ressemble � ceci, alors voil� quoi faire de ce paquet'. Si la r�gle ne v�rifie pas le paquet, alors la r�gle suivante dans la cha�ne est consult�e. Enfin, s'il n'y a plus de r�gles � consulter, alors le noyau regarde la cha�ne police pour d�cider ce qu'il doit faire. Dans un syst�me orient� s�curit�, cette police dit g�n�ralement au noyau de rejeter ou de refuser le paquet.
Pour les fans de l'art ASCII, ceci montre le chemin complet d'un paquet arrivant � une machine.
-----------------------------------------------------------------------------
| ACCEPTER/ interface lo |
v REDIRIGER _________ |
--> S --> V --> ______ --> D --> ~~~~~~~~ -->| Cha�ne |----> _______ --> o a |cha�ne| e {D�cision} |transfert| |Cha�ne |ACCEPTER
m l |entr�e| m {Routage } |_________| --->|sortie |
m i |______| a ~~~~~~~~ | | ->|_______|
e d | s | | | | |
| i | q | NON/ | | |
| t v u v REJET | | v
| � NON/ e Processus | | NON/
| | REJET r Local | | REJET
| v | ---------------------- |
v NON \ ------------------------------/
NON
Voici une description point par point de chaque partie :
C'est un test v�rifiant si le paquet n'a pas �t� corrompu d'une mani�re ou d'une autre. S'il l'a �t�, il est refus�.
Il y a en fait un de ces tests sanitaires avant chaque cha�ne de protection, mais les cha�nes d'entr�e sont les plus importantes. Quelques paquets malform�s peuvent rendre confus le code de v�rification des r�gles, et ceux-ci sont refus�s ici (un message est envoy� au syslog si ceci arrive).
C'est la premi�re cha�ne de protection qui
teste le paquet. Si le verdict de la cha�ne n'est ni DENY ni REJECT,
le paquet continue son chemin.
Si le paquet est une r�ponse � un paquet pr�c�demment
masqu�, il est d�masqu�, et envoy� directement � la cha�ne de sortie.
Si vous n'utilisez pas le masquage IP, vous pouvez mentalement supprimer
ceci du diagramme.
Le champ de destination est examin� par le code de routage, pour d�cider si le paquet doit aller vers un processus local (voir processus local plus bas) ou transmis � une machine distante (voyez les cha�nes de renvoi plus bas).
Un processus tournant sur la machine peut recevoir des paquets apr�s l'�tape de d�cision de routage, et peut envoyer des paquets (qui passent par l'�tape de d�cision de routage, puis traversent la cha�ne de sortie).
Si les paquets venant d'un processus local sont destin�s � un autre processus local, alors ils passeront par la cha�ne de sortie en utilisant l'interface lo, puis reviendront par la cha�ne d'entr�e en utilisant la m�me interface. L'interface lo est g�n�ralement nomm�e interface loopback.
Si le paquet n'a pas �t� cr�� par un processus local, alors la cha�ne de transmission est v�rifi�e, sinon le paquet se dirige vers la cha�ne de sortie.
Cette cha�ne est travers�e par tout paquet qui tente de passer par cette machine vers une autre.
Cette cha�ne est travers�e par tous les paquets juste avant qu'ils ne soient envoy�s � l'ext�rieur.
Tout d'abord, v�rifiez que vous avez la version d'ipchains � laquelle se r�f�re ce document :
$ ipchains --version
ipchains 1.3.9, 17-Mar-1999
Notez que je recommande l'utilisation du 1.3.4 (qui ne dispose pas des options longues comme `--sport'), ou du 1.3.8 et suivants ; ils sont en effet tr�s stables.
ipchains dispose d'une page de manuel plut�t bien d�taill�e (man
ipchains), et si vous avez besoin de plus de d�tails en particulier, vous
pouvez consulter l'interface de programmation (man 4 ipfw), ou le
fichier net/ipv4/ip_fw.c dans les sources des noyaux 2.1.x, qui est
(bien �videmment) la r�f�rence.
Il y a �galement une carte de r�f�rence rapide par Scott Bronson dans le paquetage source, aux formats PostScript (TM) a4 et US letter.
Il y a plusieurs choses diff�rentes que vous pouvez faire avec
ipchains. Tout d'abord les op�rations servant � g�rer les cha�nes
enti�res. Vous commencez avec trois cha�nes int�gr�es input,
output et forward que vous ne pouvez effacer.
Il y a plusieurs moyens pour manipuler les r�gles � l'int�rieur d'une cha�ne :
Il y a quelques op�rations pour le masquage, qui se trouvent dans
ipchains dans l'attente d'un bon endroit pour les mettre :
La fonction finale (et peut-�tre la plus utile) vous permet de v�rifier ce qui arriverait � un paquet donn� s'il avait � traverser une cha�ne donn�e.
Ceci est le B.A.-Ba d'ipchains ; manipuler des r�gles. Plus g�n�ralement, vous utiliserez probablement les commandes d'ajout (-A) et de suppression (-D). Les autres (-I pour l'insertion et -R pour le remplacement) sont des simples extensions de ces concepts.
Chaque r�gle sp�ficie un ensemble de conditions que le paquet doit suivre, et ce qu'il faut faire s'il les suit (une "destination"). Par exemple, vous pouvez vouloir refuser tous les paquets ICMP venant de l'adresse IP 127.0.0.1. Donc, dans ce cas nos conditions sont que le protocole doit �tre ICMP et que l'adresse source doit �tre 127.0.0.1. Notre destination est "DENY" (rejet).
127.0.0.1 est l'interface "loopback", que vous avez m�me si vous n'avez de connexion r�seau r�elle. Vous pouvez utiliser le programme "ping" pour g�n�rer de tels paquets (il envoie simplement un paquet ICMP de type 8 (requ�te d'�cho) � qui tous les h�tes coop�ratifs doivent obligeamment r�pondre avec un paquet ICMP de type 0 (r�ponse � un �cho)). Ceci le rend utile pour les tests.
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.2 ms
# ipchains -A input -s 127.0.0.1 -p icmp -j DENY
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
#
Vous pouvez voir ici que le premier ping r�ussit (le "-c 1" dit � ping de n'envoyer qu'un seul paquet).
Puis nous ajoutons (-A) � la cha�ne d'entr�e ("input"), une r�gle sp�cifiant que tous les paquets provenant de 127.0.0.1 ("-s 127.0.0.1") avec le protocole ICMP ("-p ICMP") doivent �tre refus�s ("-j DENY").
Ensuite nous testons notre r�gle, en utilisant le second ping. Il y aura une pause avant que le programme ne se termine, attendant une r�ponse qui ne viendra jamais.
Nous pouvons supprimer la r�gle avec l'un des deux moyens. Tout d'abord, puisque nous savons que c'est la seule r�gle de la cha�ne d'entr�e, nous pouvons utiliser une suppression num�rot�e, comme dans :
# ipchains -D input 1
#
La deuxi�me possibilit� est de copier la commande -A, mais en rempla�ant le -A par -D. C'est utile lorsque vous avez une cha�ne complexe de r�gles et que vous ne voulez pas avoir � les compter afin de savoir que c'est la r�gle 37 que vous voulez supprimer. Dans ce cas, nous pouvons utiliser :
# ipchains -D input -s 127.0.0.1 -p icmp -j DENY
#
Nous avons vu l'utilisation de "-p" pour sp�cifier le protocole, et de "-s" pour sp�cifier l'adresse souce, mais il y a d'autres options que nous pouvons utiliser pour sp�cifier les caract�ristiques des paquets. Ce qui suit en est une description exhaustive.
Les adresses IP source (-s) et destination (-d) peuvent �tre sp�cifi�es de quatre fa�ons diff�rentes. La fa�on la plus classique est d'utiliser le nom complet, comme "localhost" ou "www.linuxhq.com". La deuxi�me m�thode est de sp�cifier l'adresse IP, comme "127.0.0.1".
Les deux autres m�thodes permettent la sp�cification d'un groupe d'adresses IP, comme "199.95.207.0/24" ou "199.95.207.0/255.255.255.0". Toutes deux sp�cifient toutes les adresses IP de 192.95.207.0 � 192.95.207.255, incluse ; les chiffres suivant le "/" indiquent quelles parties de l'adresse IP sont significatives. "/32" ou "/255.255.255.255" sont les d�fauts (v�rifient toutes les adresses IP). Pour ne sp�cifier aucune adresse IP, "/0" peut �tre utilis�, par exemple :
# ipchains -A input -s 0/0 -j DENY
#
Ceci est rarement utilis�, car l'effet produit par cette ligne de commande est le m�me que celui obtenu en ne sp�cifiant pas l'option "-s".
De nombreuses options, incluant les options "-s" et "-d" peuvent avoir leurs propres arguments pr�c�d�s par "!" (prononc� "non") pour ne v�rifier que les adresses n'�tant PAS �quivalentes � celles donn�es. Par exemple, "-s ! localhost" v�rifiera tout paquet ne provenant PAS de localhost.
Le protocole peut �tre sp�cifi� en utilisant l'option "-p". Le protocole peut �tre soit un nombre (si vous connaissez les valeurs num�riques des protocoles pour IP), soit le nom des cas sp�ciaux parmis "TCP", "UDP" ou "ICMP". La casse n'est pas prise en compte, donc "tcp" fonctionne aussi bien que "TCP".
Le nom du protocole peut �tre pr�fix� par un "!", pour l'inverser, comme dans "-p ! TCP".
Pour les cas sp�ciaux o� un protocole TCP ou UDP est sp�cifi�, il peut y avoir un argument suppl�mentaire indiquant le port TCP ou UDP, ou un intervalle (inclusif) de ports (mais voyez Utiliser les fragments plus bas). Un intervalle est repr�sent� en utilisant le caract�re ":", par exemple "6000:6010", qui couvre 11 ports, du 6000 au 6010, de mani�re inclusive. Si la borne inf�rieure est omise, alors elle se met par d�faut � 0. Si la borne sup�rieure est omise, elle est consid�r�e par d�faut comme �tant 65535. Ainsi, pour sp�cifier les connexions TCP venant des ports inf�rieurs � 1024, la syntaxe pourrait �tre "-p TCP -s 0.0.0.0/0 :1023". Les num�ros de ports peuvent �tre sp�cifi�s par leur nom, par exemple "www".
Notez que la sp�cification du port peut �tre pr�c�d�e par un "!", qui l'inverse. Ainsi, pour sp�cifier tous les paquets TCP, SAUF un paquet WWW, vous pourriez sp�cifier
-p TCP -d 0.0.0.0/0 ! www
Il est important de r�aliser que sp�cifier
-p TCP -d ! 192.168.1.1 www
est tr�s diff�rent de
-p TCP -d 192.168.1.1 ! www
La premi�re ligne sp�cifie tout paquet TCP dirig� vers le port WWW de n'importe quelle machine sauf 192.168.1.1. La seconde sp�cifie toute connexion TCP vers tout port de 192.168.1.1 sauf le port WWW.
Enfin, le cas suivant sp�cifie tout, sauf le port WWW et la machine 192.168.1.1 :
-p TCP -d ! 192.168.1.1 ! www
ICMP permet aussi un argument optionnel, mais comme l'ICMP ne dispose pas de ports (ICMP a un type et un code), ils ont une signification diff�rente.
Vous pouvez les sp�cifier par les noms ICMP (utilisez ipchains -h icmp
pour lister les noms disponibles) apr�s l'option "-s", ou en tant que type et
code ICMP num�rique, o� le type suit l'option "-s" et le code suit l'option
"-d".
Les noms ICMP sont relativement longs : vous avez uniquement besoin de suffisamment de lettres pour rendre chaque nom distinct des autres.
Voici un petit r�sum� de quelques-uns des paquets ICMP les plus communs :
Num�ro Nom Utilis� par
0 echo-reply ping
3 destination-unreachable Tout trafic TCP/UDP
5 redirect Routage, si pas de d�mon de routage
8 echo-request ping
11 time-exceeded traceroute
Notez que les noms ICMP ne peuvent �tre pr�c�d�s de "!" pour le moment.
NE PAS, SURTOUT NE PAS bloquer tous les paquets ICMP de type 3 ! (voir Paquets ICMP plus bas).
L'option "-i" sp�cifie le nom d'une interface � v�rifier. Une interface
est le p�riph�rique physique d'o� vient le paquet, ou bien par o� sort ce
paquet. Vous pouvez utiliser la commande ifconfig pour lister les
interfaces qui sont "up" (c�d en fonctionnement).
L'interface pour les paquets entrants (ie. les paquets traversant la cha�ne
d'entr�e) est consid�r�e comme �tant l'interface d'o� les paquets
proviennent. Logiquement, l'interface des paquets sortants (les paquets
traversant la cha�ne de sortie) est l'interface o� ils vont. L'interface
pour les paquets traversant la cha�ne de retransmission est �galement
l'interface par laquelle ils sortiront ; une d�cision plut�t arbitraire � mon
sens.
Il est parfaitement autoris� de sp�cifier une interface qui n'existe pas au
moment de la sp�cification ; la r�gle ne v�rifiera rien jusqu'� ce que
l'interface soit mise en place. Ceci est extr�mement utile pour les connexions
ppp intermittentes (habituellement les interfaces du type ppp0) et autres.
En tant que cas sp�cial, un nom d'interface se finissant par un "+" v�rifiera
toutes les interfaces (qu'elles existent � ce moment ou non) qui commencent
par cette cha�ne. Par exemple, pour sp�cifier une r�gle qui v�rifiera toutes
les interfaces PPP, l'option -i ppp+ pourrait �tre utilis�e.
Le nom d'interface peut �tre pr�c�d� par un "!" pour v�rifier un paquet qui ne v�rifie PAS l'(les) interface(s) sp�cifi�e(s).
Il est parfois utile d'autoriser des connexions TCP dans une direction, mais pas dans l'autre. Par exemple, vous pouvez vouloir autoriser les connexions vers un serveur WWW externe, mais pas les connexions venant de ce serveur.
L'approche na�ve serait de bloquer les paquets TCP venant du serveur. Malheureusement, les connexions TCP utilisent des paquets circulant dans les deux sens pour fonctionner.
La solution est de bloquer uniquement les paquets utilis�s pour la demande d'une connexion. Ces paquets sont nomm�s paquets SYN (ok, techniquement ce sont des paquets avec le drapeau SYN mis, et les drapeaux FIN et ACK supprim�s, mais nous les appellerons des paquets SYN). En interdisant seulement ces paquets, nous pouvons stopper toute demande de connexion dans l'oeuf.
L'option "-y" est utilis�e pour cel� : elle est valide seulement pour les r�gles qui sp�cifient TCP comme leur protocole. Par exemple, pour sp�cifier une demande de connexion TCP venant de 192.168.1.1 :
-p TCP -s 192.168.1.1 -y
Une fois de plus, ce drapeau peut �tre invers� en le faisant pr�c�der par un "!", qui v�rifie tout paquet autre que ceux d'initialisation de connexion.
Parfois, un paquet est trop large pour rentrer dans le c�ble en une seule fois. Lorsque ceci arrive, le paquet est divis� en fragments, et envoy� en plusieurs paquets. Le receveur r�assemble les fragments pour reconstruire le paquet en entier.
Le probl�me avec les fragments se situe dans certaines des sp�cifications list�es ci-dessus (en particulier, le port source, le port de destination, le type et le code ICMP, ou le drapeau TCP SYN), qui demandent au noyau de jeter un regard sur le d�but du paquet, qui est contenu seulement dans le premier fragment.
Si votre machine est la seule connexion vers un r�seau ext�rieur, vous pouvez
demander � votre noyau Linux de r�assembler tous les fragments qui passent par
lui, en compilant le noyau avec l'option IP: always defragment mise �
"Y". Ceci �vite proprement la plupart des probl�mes.
D'autre part, il est important de comprendre comment les fragments sont
trait�s par les r�gles de filtrage. Toute r�gle de filtrage qui demande
des informations dont nous ne disposons pas ne v�rifiera rien. Ceci
signifie que le premier fragment est trait� comme tout autre paquet. Le
deuxi�me fragment et les suivants ne le seront pas. Ainsi, une r�gle -p TCP
-s 192.168.1.1 www (sp�cifiant un port source de "www" ne v�rifiera jamais un
fragment (autre que le premier fragment). La r�gle oppos�e -p TCP -s
192.168.1.1 ! www ne fonctionnera pas non plus.
Cependant, vous pouvez sp�cifier une r�gle sp�ciale pour le deuxi�me fragment et les suivants, en utilisant l'option "-f". �videmment, il est ill�gal de sp�cifier un port TCP ou UDP, un type ou un code ICMP, ou un drapeau TCP SYN dans une r�gle de fragment.
Il est �galement autoris� de sp�cifier une r�gle qui ne s'applique pas au deuxi�me fragment et aux suivants, en pla�ant un "!" avant le "-f".
Habituellement, il est consid�r� comme s�r de laisser passer le deuxi�me fragment et les suivants, puisque le filtrage s'effectuera sur le premier fragment, et pr�viendra donc le r�assemblage sur la machine cible. Cependant, des bogues, connus, permettent de crasher des machines en envoyant de simples fragments. � vous de voir.
� noter pour les gourous r�seau : les paquets malform�s (TCP, UDP et paquets ICMP trop courts pour que le code pare-feu puisse lire les ports ou les types et codes ICMP) sont �galement trait�s comme des fragments. Seuls les fragments TCP d�butant en position 8 sont supprim�s explicitement par le code pare-feu (un message doit appara�tre dans le syslog si cel� arrive).
Par exemple, la r�gle suivante supprimera tout fragment allant sur 192.168.1.1 :
# ipchains -A output -f -d 192.168.1.1 -j DENY
#
OK, maintenant nous connaissons tous les moyens pour v�rifier un paquet en utilisant une r�gle. Si un paquet v�rifie une r�gle, les choses suivantes arrivent :
Pour la diversit�, je d�taillerai ceux-ci en ordre d'importance.
Une destination dit au noyau ce qu'il doit faire d'un paquet qui v�rifie une r�gle. ipchains utilise "-j" (penser � "jump-to") pour la sp�cification de la destination. Le nom de la cible doit comporter moins de 8 caract�res, et la casse intervient : "RETOUR" et "retour" sont totalement diff�rents.
Le cas le plus simple est lorsqu'il n'y a pas de destination sp�cifi�e. Ce type de r�gle (souvent appell�e r�gle de "comptage") est utile pour simplement compter un certain type de paquet. Que cette r�gle soit v�rifi�e ou non, le noyau examine simplement la r�gle suivante dans la cha�ne. Par exemple, pour compter le nombre de paquets venant de 192.168.1.1, nous pouvons faire ceci :
# ipchains -A input -s 192.168.1.1
#
(En utilisant "ipchains -L -v" nous pouvons voir les compteurs de paquets et d'octets associ�s � chaque r�gle).
Il y a six destinations sp�ciales. Les trois premi�res, ACCEPT, REJECT et
DENY sont relativement simples. ACCEPT autorise le passage du
paquet. DENY supprime le paquet comme s'il n'avait jamais �t� re�u.
REJECT supprime le paquet, mais (si ce n'est pas un paquet ICMP) g�n�re
une r�ponse ICMP vers la source pour lui dire que la destination n'est pas
accessible.
La suivante, MASQ dit au noyau de camoufler le paquet. Pour que ceci
fonctionne, votre noyau doit �tre compil� avec le camouflage IP int�gr�. Pour
les d�tails sur ceci, voyez le Masquerading-HOWTO et l'annexe
Diff�rences entre ipchains et ipfwadm. Cette destination
est valide uniquement pour les paquets qui traversent la cha�ne forward.
L'autre destination majeure sp�ciale est REDIRECT qui demande au noyau
d'envoyer un paquet vers un port local au lieu de l� o� il �tait destin�. Ceci
peut �tre sp�cifi� uniquement pour les r�gles sp�cifiant TCP ou UDP en tant
que protocole. Optionnellement, un port (nom ou num�ro) peut �tre sp�cifi�
apr�s "-j REDIRECT" qui redirigera la paquet vers ce port particulier, m�me si
celui-ci �tait dirig� vers un autre port. Cette destination est valide uniquement
pour les paquets traversant la cha�ne input.
La derni�re destination sp�ciale est la RETURN qui est identique � une
terminaison imm�diate de la cha�ne (voir
Choisir une police plus bas).
Toute autre destination indique une cha�ne d�finie par l'utilisateur (d�crite dans Op�rations sur une cha�ne enti�re plus bas). Le paquet traversera tout d'abord les r�gles de cette cha�ne. Si cette cha�ne ne d�cide pas du destin du paquet, lorsque la travers�e de cette cha�ne sera achev�e, la travers�e reprendra sur la r�gle suivante de la cha�ne courante.
Il est temps de faire encore un peu d'art ASCII. Consid�rons deux (�tranges)
cha�nes : input (la cha�ne int�gr�e) et Test (une cha�ne d�finie par
l'utilisateur).
`input' `Test' ----------------------------- ----------------------------- | R�gle1: -p ICMP -j REJECT | | R�gle1: -s 192.168.1.1 | |---------------------------| |---------------------------| | R�gle2: -p TCP -j Test | | R�gle2: -d 192.168.1.1 | |---------------------------| ----------------------------- | R�gle3: -p UDP -j DENY | -----------------------------
Consid�rons un paquet TCP venant de 192.168.1.1, allant vers 1.2.3.4. Il
p�n�tre dans la cha�ne input, et est test� par la R�gle1 - pas de
correspondance. La R�gle2 correspond, et sa destination est Test, donc la r�gle
suivante � examiner est le d�but de Test. La R�gle1 de Test
correspond, mais ne sp�cifie pas de destination, donc la r�gle suivante est examin�e
(R�gle2). Elle ne correspond pas, nous avons donc atteint la fin de la cha�ne.
Nous retournons alors � la cha�ne input, dont nous avons juste examin� la
R�gle2, et nous examinons alors la R�gle3, qui ne correspond pas non plus.
Le chemin suivi par le paquet est donc le suivant :
v __________________________ `entr�e' | / `Test' v ------------------------|--/ -----------------------|---- | R�gle1 | /| | R�gle1 | | |-----------------------|/-| |----------------------|---| | R�gle2 / | | R�gle2 | | |--------------------------| -----------------------v---- | R�gle3 /--+---------------------------/ ------------------------|--- v
Voyez la section Comment organiser vos r�gles pare-feu pour les moyens d'utiliser efficacement les cha�nes d�finies par l'utilisateur.
C'est un effet de bord que la v�rification d'une r�gle peut avoir ; vous pouvez enregistrer les paquets v�rifi�s en utilisant l'option "-l". Vous n'aurez g�n�ralement pas besoin de ceci pour les paquets habituels, mais ce peut �tre une option tr�s utile si vous d�sirez �tre tenu au courant des �v�nements exceptionnels.
Le noyau enregistre cette information de la mani�re suivante :
Packet log: input DENY eth0 PROTO=17 192.168.2.1:53 192.168.1.1:1025
L=34 S=0x00 I=18 F=0x0000 T=254
Ce message d'information est pr�vu pour �tre concis, et contient des informations techniques qui ne sont utiles qu'aux gourous r�seau, mais qui peuvent n�anmoins �tre int�ressantes pour le commun des mortels. Il se d�compose de la fa�on suivante :
Sur les syst�mes Linux standards, la sortie du noyau est captur�e par klogd (d�mon d'information du noyau) qui le repasse � syslogd (d�mon d'information du syst�me). Le fichier `/etc/syslog.conf' contr�le le comportement de syslogd, en sp�cifiant une destination pour chaque "partie" (dans notre cas, la partie est le "noyau") et un "niveau" (pour ipchains, le niveau utilis� est "info").
Par exemple, mon /etc/syslog.conf (Debian) contient deux lignes qui v�rifient `kern.info' :
kern.* -/var/log/kern.log
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none -/var/log/messages
Ceci signifie que les messages sont dupliqu�s dans `/var/log/kern.log' et `/var/log/messages'. Pour plus de d�tails, voyez `man syslog.conf'.
Il y a quatre bits utilis�s par eux-m�mes dans l'ent�te IP, appel�s les bits de Type of Service (TOS). Ceux-ci ont pour effet de modifier la mani�re dont les paquets sont trait�s : les quatres bits sont "Minimum Delay", "Maximum Throughput", "Maximum Reliability" et "Minimum Cost". Un seul de ces bits est autoris� � �tre plac�. Rob van Nieuwkerk, l'auteur du code de gestion du TOS, les d�crit comme suit :
Tout sp�cialement, le "Minimum Delay" est important pour moi. Je le mets pour les paquets "interactifs" dans mon routeur principal (Linux). Je suis derri�re une connexion modem 33,6k. Linux rend les paquets prioritaires en 3 queues. De cette fa�on, j'obtiens des performances interactives acceptables tout en faisant de gros transferts de fichiers en m�me temps. (Cel� pourrait m�me �tre encore mieux s'il n'y avait pas de grosse queue dans le pilote s�rie, mais le temps de latence est maintenu en dessous des 1,5 secondes pour l'instant).
Note : bien entendu, vous n'avez aucun contr�le sur les paquets arrivants ; vous pouvez seulement contr�ler la priorit� des paquets qui quittent votre machine. Pour n�gocier les priorit�s de chaque c�t�, un protocole comme RSVP (dont je ne connais rien) doit �tre utilis�.
L'utilisation la plus commune est de placer les connexions telnet et contr�le du ftp en "Minimum Delay" et les donn�es FTP en "Maximum Throughput". Ceci peut �tre fait de la mani�re suivante :
ipchains -A output -p tcp -d 0.0.0.0/0 telnet -t 0x01 0x10
ipchains -A output -p tcp -d 0.0.0.0/0 ftp -t 0x01 0x10
ipchains -A output -p tcp -s 0.0.0.0/0 ftp-data -t 0x01 0x08
L'option "-t" prend deux param�tres suppl�mentaires, tous les deux en hexad�cimal. Ceci permet un contr�le complexe des bits du TOS : le premier masque est AND� avec le TOS actuel du paquet, et ensuite le deuxi�me masque est XOR� avec lui. Si cel� est trop confus, utilisez simplement le tableau suivant :
Nom du TOS Valeur Utilisations typiques
Minimum Delay 0x01 0x10 ftp, telnet
Maximum Throughput 0x01 0x08 ftp-data
Maximum Reliability 0x01 0x04 snmp
Minimum Cost 0x01 0x02 nntp
Andi Kleen revient sur ce point pour ce qui suit (mod�r�ment �dit� pour la post�rit�) :
Peut-�tre serait-il utile d'ajouter une r�f�rence au param�te txqueuelen de ifconfig dans la discussion sur les bits TOS. La longueur par d�faut de la queue d'un p�riph�rique est r�gl�e pour les cartes ethernet, sur les modems elle est trop longue et rend le fonctionnement de la planification 3 bandes (qui place la queue en fonction du TOS) sous-optimal. C'est donc une bonne id�e de le configurer avec une valeur comprise entre 4 et 10 sur un modem ou un lien RNIS b simple : sur les p�riph�riques rapide une queue plus longue est n�cessaire. C'est un probl�me des 2.0 et 2.1, mais dans le 2.1 c'est une option de ifconfig (dans les nettools r�cents), alors que dans le 2.0 il n�cessite une modification des sources des pilotes du p�riph�rique pour le changer.
Ainsi, pour voir les b�n�fices maximum des changements de TOS pour les liaisons modem PPP, ajoutez un `ifconfig $1 txqueuelen' dans votre script /etc/ppp/ip-up. Le nombre � utiliser d�pend de la vitesse du modem et de la taille du tampon du modem ; voici � nouveau les id�es d'Andi :
La meilleure valeur pour une configuration donn�e n�cessite de l'exp�rimentation. Si les queues sont trop courtes sur le routeur, alors les paquets sauteront. Bien s�r, on peut toujours gagner m�me sans changer le TOS, c'est juste que le changement du TOS aide � gagner les b�n�fices sur les programmes non coop�ratifs (mais tous les programmes Linux standards sont coop�ratifs).
Ceci permet des interactions complexes et puissantes avec la nouvelle impl�mentation de Quality of Service d'Alexey Kuznetsov, ainsi que de la redirection bas�e sur le marquage dans la derni�re s�rie de noyaux 2.1. Des d�tails suppl�mentaires vont arriver puisque nous l'avons dans la main. Cette option est toutefois ignor�e dans la s�rie des noyaux 2.0.
Une des options les plus utiles d'ipchains est la possibilit� de regrouper des
r�gles dans des cha�nes. Vous pouvez appeller les cha�nes de la mani�re qui
vous pla�t, tant que les noms ne sont pas ceux des cha�nes int�gr�es
(input, output et forward) ou des destinations ((MASQ,
REDIRECT, ACCEPT, DENY, REJECT ou RETURN). Je sugg�re
d'�viter compl�tement les noms en majuscules, car je pourrais les utiliser pour
des extensions futures. Le nom de la cha�ne ne doit pas d�passer 8 caract�res.
Cr�ons une nouvelle cha�ne. �tant un type imaginatif, je l'appellerai
test.
# ipchains -N test
#
C'est aussi simple. Maintenant vous pouvez y rajouter des r�gles, comme d�taill� ci-dessus.
La suppression d'une cha�ne est tout aussi simple.
# ipchains -X test
#
Pourquoi "-X" ? Eh bien, toutes les bonnes lettres �taient d�j� prises.
Il y a quelques restrictions � la suppression des cha�nes : elles doivent �tre vides (voir Vider une cha�ne plus bas) et elles ne doivent pas �tre la destination d'une quelconque r�gle. Vous ne pouvez pas supprimer les cha�nes int�gr�es.
Il y a un moyen simple de vider toutes les r�gles d'une cha�ne, en utilisant la commande "-F".
# ipchains -F forward
#
Si vous ne sp�cifiez pas de cha�ne, alors toutes les cha�nes seront vid�es.
Vous pouvez afficher toutes les r�gles d'une cha�ne en utilisant la commande "-L".
# ipchains -L input
Chain input (refcnt = 1): (policy ACCEPT)
target prot opt source destination ports
ACCEPT icmp ----- anywhere anywhere any
# ipchains -L test
Chain test (refcnt = 0):
target prot opt source destination ports
DENY icmp ----- localnet/24 anywhere any
#
La "refcnt" list�e pour test est le nombre de r�gles qui ont test
comme destination. Ceci doit �tre �gal � z�ro (et la cha�ne doit �tre vide) avant
que cette cha�ne ne puisse �tre supprim�e.
Si le nom de la cha�ne est omis, toutes les cha�nes sont list�es, m�me les cha�nes vides.
Il y a trois options qui peuvent accompagner "-L". L'option "-n" (num�rique)
est tr�s utile et emp�che ipchains d'essayer de v�rifier les adresses IP,
ce qui (si vous utilisez DNS comme la plupart des gens) causera de longs
d�lais si votre DNS n'est pas configur� proprement, ou si vous filtrez les
requ�tes DNS. Ceci affichera �galement les ports par leur num�ro plut�t que
par leur nom.
L'option "-v" vous montrera tous les d�tails des r�gles, comme les compteurs de paquets et d'octets, les masques de TOS, l'interface, et les marques de paquets. Autrement, ces valeurs seront omises. Par exemple :
# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
pkts bytes target prot opt tosa tosx ifname mark source destination ports
10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any
Notez que les compteurs de paquets et d'octets sont affich�s en utilisant les suffixes "K", "M" ou "G" pour 1000, 1.000.000 et 1.000.000.000, respectivement. En utilisant �galement l'option "-x" (d�veloppe les nombres), ipchains affichera les nombres en entier, quelque soit leur taille.
Il est parfois utile de pouvoir remettre � z�ro les compteurs. Ceci peut �tre fait par l'option "-Z" (compteurs � Z�ro). Par exemple :
# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
pkts bytes target prot opt tosa tosx ifname mark source destination ports
10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any
# ipchains -Z input
# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
pkts bytes target prot opt tosa tosx ifname mark source destination ports
0 0 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any
#
Le probl�me de cette approche est que parfois vous voudrez conna�tre les valeurs du compteur tout de suite apr�s la remise � z�ro. Dans l'exemple ci-dessus, quelques paquets peuvent passer entre les commandes "-L" et "-Z". Pour cette raison, vous pouvez utiliser le "-L" et le "-Z" ensemble, pour remettre � z�ro les compteurs tout en les lisant. Malheureusement, si vous fa�tes ceci, vous ne pouvez op�rer sur une seule cha�ne : vous devrez lister et remettre � z�ro toutes les cha�nes en une seule fois.
# ipchains -L -v -Z
Chain input (policy ACCEPT):
pkts bytes target prot opt tosa tosx ifname mark source destination ports
10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any
Chain forward (refcnt = 1): (policy ACCEPT)
Chain output (refcnt = 1): (policy ACCEPT)
Chain test (refcnt = 0):
0 0 DENY icmp ----- 0xFF 0x00 ppp0 localnet/24 anywhere any
# ipchains -L -v
Chain input (policy ACCEPT):
pkts bytes target prot opt tosa tosx ifname mark source destination ports
10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any
Chain forward (refcnt = 1): (policy ACCEPT)
Chain output (refcnt = 1): (policy ACCEPT)
Chain test (refcnt = 0):
0 0 DENY icmp ----- 0xFF 0x00 ppp0 localnet/24 anywhere any
#
Nous avons dissert� sur ce qui se passe lorsqu'un paquet atteint la fin de la
cha�ne int�gr�e, lorsque nous avons discut� sur la mani�re dont un paquet
parcourait les cha�nes dans
Sp�cifier une destination
plus haut. Dans ce cas, la police de la cha�ne d�termine le destin du
paquet. Seules les cha�nes int�gr�es (input, output et forward)
ont des polices, car si un paquet atteint la fin d'une cha�ne d�finie par
l'utilisateur, le paquet revient sur la cha�ne pr�c�dente.
La police peut �tre une des quatre premi�res destinations sp�ciales : ACCEPT,
DENY, REJECT ou MASQ. MASQ est la seule destination valide pour la
cha�ne "forward".
Il est �galement important de noter qu'une destination RETURN dans une r�gle de
l'une des cha�nes int�gr�es est utile pour expliciter la destination de la cha�ne
lorsqu'un paquet correspond � la r�gle.
Il y a plusieurs param�tres que vous pouvez modifier pour le camouflage IP.
Ils sont int�gr�s avec ipchains car il n'est pas �vident d'�crire un
outil s�par� pour eux (bien que ceci devrait changer).
La commande du camouflage IP est "-M", et peut �tre combin�e avec "-L" pour lister les connexions actuellement camoufl�es, ou avec "-S" pour configurer les param�tres du camouflage.
La commande "-L" peut �tre accompagn�e par "-n" (montre des nombres � la place des noms de machines et de ports) ou "-v" (affiche les deltas dans les s�quences de nombres pour la connexion camoufl�e, au cas o� vous vous demanderiez).
La commande "-S" doit �tre suivie par trois valeurs de fin d'attente, toutes en secondes : pour les sessions TCP, pour les sessions TCP pr�c�d�es d'un paquet FIN, et pour les paquets UDP. Si vous ne voulez pas changer l'une de ces valeurs, donnez-lui simplement une valeur de "0".
Les valeurs par d�faut sont list�es dans "/usr/src/linux/include/net/ip_masq.h", actuellement 15 minutes, 2 minutes et 5 minutes, respectivement.
La valeur chang�e le plus souvent est la premi�re, pour le FTP (voir Cauchemars du FTP plus bas).
Notez que les probl�mes avec la mise en place de temps de fin d'attente sont list�s dans Je n'arrive pas � configurer mes temps d'attente !.
Parfois, vous voulez savoir ce qui arrive lorsqu'un certain paquet entre dans
votre machine, par exemple pour d�boguer votre cha�ne pare-feu.
ipchains dispose de la commande "-C" pour autoriser cel�, en utilisant
exactement les m�mes routines que celles que le noyau utilise pour v�rifier
les vrais paquets.
Vous sp�cifiez sur quelle cha�ne le paquet doit �tre test� en mettant son nom
apr�s l'argument "-C". M�me si le noyau commence toujours par traverser les
cha�nes input, output ou forward, vous �tes autoris� �
commencer en traversant n'importe quelle cha�ne pour tester.
Les d�tails du "paquet" sont sp�cifi�s en utilisant la m�me syntaxe que celle utilis�e pour sp�cifier les r�gles pare-feu. En particulier, un protocole ("-p"), une adresse source ("-s"), une adresse de destination ("-d") et une interface ("-i") sont n�cessaires. Si le protocole est TCP ou UDP, alors une source unique et une destination unique doivent �tre sp�cifi�es, et un type et un code ICMP doivent �tre sp�cifi�s pour le protocole ICMP (� moins que l'option "-f" soit sp�cifi�e pour indiquer une r�gle de fragment, auquel cas ces options sont ill�gales).
Si le protocole est TCP (et que l'option "-f" n'est pas sp�cifi�e), l'option "-y' doit �tre explicit�e, afin d'indiquer que le paquet test doit �tre configur� avec le bit SYN.
Voici un exemple de test d'un paquet TCP SYN venant de 192.168.1.1, port 60000, et allant sur 192.168.1.2, port www, arrivant de l'interface eth0 et entrant dans la cha�ne "input" (il s'agit d'une initialisation classique d'une connexion WWW) :
# ipchains -C input -p tcp -y -i eth0 -s 192.168.1.1 60000 -d 192.168.1.2 www
packet accepted
#
Parfois, une simple ligne de commande peut affecter de multiples r�gles. Ceci
se fait par deux m�thodes. Premi�rement, si vous sp�cifiez un nom de machine
qui correspond (en utilisant DNS) � de multiples adresses IP, ipchains
agira comme si vous aviez tap� de multiples commandes avec chaque combinaison
d'adresses.
Ainsi, si le nom de machine "www.foo.com" correspond � trois adresses IP, et
si le nom de machine "www.bar.com" correspond � deux adresses IP, alors la
commande "ipchains -A input -j reject -s www.bar.com -d www.foo.com" ajoutera
six r�gles � la cha�ne input.
L'autre m�thode pour avoir ipchains r�alisant de multiples actions est
d'utiliser l'option bidirectionnelle ("-b"). Cette option fait agir
ipchains comme si vous aviez tap� la commande deux fois, la deuxi�me fois
avec les arguments "-s" et "-d" invers�s. Ainsi, pour �viter la transmission
soit de, soit vers 192.168.1.1, vous pourriez utiliser la commande :
# ipchains -b -A forward -j reject -s 192.168.1.1
#
Personnellement, je n'aime pas beaucoup l'option "-b" ; si vous pr�f�rez la convivialit�, voyez Utiliser ipchains-save plus bas.
L'option -b peut �tre utilis�e avec les commandes ins�rer ("-I"), supprimer ("-D") (mais pas avec la variation qui prend un num�ro de r�gle), ajouter ("-A") et v�rifier ("-C").
Une autre option utile est "-v" (bruyant) qui imprime exactement ce que
ipchains fait avec vos commandes. Ceci est utile si vous traitez avec des
commandes qui peuvent affecter de multiples r�gles. Par exemple, nous devons
ici v�rifier le comportement de fragments entre 192.168.1.1 et 192.168.1.2.
# ipchains -v -b -C input -p tcp -f -s 192.168.1.1 -d 192.168.1.2 -i lo
tcp opt ---f- tos 0xFF 0x00 via lo 192.168.1.1 -> 192.168.1.2 * -> *
packet accepted
tcp opt ---f- tos 0xFF 0x00 via lo 192.168.1.2 -> 192.168.1.1 * -> *
packet accepted
#
J'ai une connexion intermittente en PPP (-i ppp0). Je r�cup�re les news
(-p TCP -s news.virtual.net.au nntp) et le courrier (-p TCP -s
mail.virtual.net.au pop-3) � chaque fois que je me connecte. J'utilise la
m�thode ftp de Debian pour mettre ma machine � jour r�guli�rement (-p TCP
-y -s ftp.debian.org.au ftp-data). Je visionne le web au travers du proxy de
mon FAI (Fournisseur d'Acc�s Internet) lorsque je suis en ligne (-p TCP -d
proxy.virtual.net.au 8080), mais je d�teste les publicit�s de doubleclick.net
des Archives de Dilbert (-p TCP -y -d 199.95.207.0/24 et -p TCP -y
-d 199.95.208.0/24).
J'autorise les gens � essayer le ftp sur ma machine lorsque je suis en
ligne (-p TCP -d $LOCALIP ftp), mais je n'autorise personne de
l'ext�rieur � pr�tendre avoir une adresse IP sur mon r�seau interne (-s
192.168.1.0/24). Ceci est commun�ment appel� IP spoofing, et il y a un
meilleur moyen de se prot�ger dans les noyaux 2.1.x et suivants : voir
Comment mettre en place la protection contre l'IP spoof ?.
Cette configuration est relativement simple, car il n'y a pour l'instant aucune autre machine sur mon r�seau interne.
Je ne veux pas que des processus locaux (ie. Netscape, lynx, etc.) se connectent � doubleclick.net :
# ipchains -A output -d 199.95.207.0/24 -j REJECT
# ipchains -A output -d 199.95.208.0/24 -j REJECT
#
Maintenant je d�sire changer les priorit�s des divers paquets sortants (il n'y
a pas vraiment d'int�r�t � le faire pour les paquets entrants). Puisqu'il y a
un certain nombre de ces r�gles, il y a int�r�t � les mettre ensemble dans une
seule cha�ne, nomm�e ppp-out.
# ipchains -N ppp-out
# ipchains -A output -i ppp0 -j ppp-out
#
D�lai minimal pour le trafic web et telnet :
# ipchains -A ppp-out -p TCP -d proxy.virtual.net.au 8080 -t 0x01 0x10
# ipchains -A ppp-out -p TCP -d 0.0.0.0 telnet -t 0x01 0x10
#
Co�t faible pour les donn�es ftp, nntp et pop-3 :
# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 ftp-data -t 0x01 0x02
# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 nntp -t 0x01 0x02
# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 pop-3 -t 0x01 0x02
#
Il y a quelques restrictions sur les paquets venant de l'interface ppp0 ; cr�ons une cha�ne nomm�e "ppp-in" :
# ipchains -N ppp-in
# ipchains -A input -i ppp0 -j ppp-in
#
Maintenant, aucun des paquets venant de ppp0 ne doit pr�tendre avoir une
adresse source de la forme 192.168.1.*, donc nous les enregistrons et les
interdisons :
# ipchains -A ppp-in -s 192.168.1.0/24 -l -j DENY
#
J'autorise l'entr�e des paquets UDP pour le DNS (je fais tourner un serveur de nom cache qui renvoie toutes les demandes sur 203.29.16.1, donc je m'attend � des r�ponses DNS venant uniquement de l�), l'entr�e du ftp, et le retour des donn�es ftp (ftp-data) uniquement (ce qui doit �tre uniquement entre un port strictement sup�rieur � 1023, et pas sur les ports X11 autour de 6000).
# ipchains -A ppp-in -p UDP -s 203.29.16.1 -d $LOCALIP dns -j ACCEPT
# ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 1024:5999 -j ACCEPT
# ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 6010: -j ACCEPT
# ipchains -A ppp-in -p TCP -d $LOCALIP ftp -j ACCEPT
#
Enfin, les paquets local vers local sont OK :
# ipchains -A input -i lo -j ACCEPT
#
Maintenant, ma police par d�faut sur la cha�ne input est DENY, ce
qui fait que tout le reste dispara�t :
# ipchains -P input DENY
#
NOTE : Je ne configurerais pas mes cha�nes dans cet ordre, car des paquets pourraient passer durant la configuration. Le moyen le plus s�r est g�n�ralement de configurer la police � DENY tout d'abord, et ensuite d'ins�rer les r�gles. Bien s�r, si vos r�gles ont besoin d'effectuer des demandes DNS pour r�soudre des noms de machines, vous pourriez avoir des probl�mes.
Configurer des cha�nes pare-feu de la mani�re exacte dont vous le voulez, et se rappeller ensuite des commandes que vous avez utilis� pour le faire la fois suivante est insupportable.
Donc, ipchains-save est un script qui lit votre configuration actuelle
des cha�nes et la sauve dans un fichier. Pour le moment, je conserverais le
suspens en ce qui concerne l'utilit� de ipchains-restore.
ipchains-save peut sauver une cha�ne seule, ou toutes les cha�nes (si
aucun nom de cha�ne n'a �t� sp�cifi�). La seule option actuellement autoris�e
est le "-v" qui affiche les r�gles (vers stderr) lorsqu'elles sont sauv�es. La
police de la cha�ne est aussi sauv�e pour les cha�nes input, output
et forward.
# ipchains-save> my_firewall
Saving `input'.
Saving `output'.
Saving `forward'.
Saving `ppp-in'.
Saving `ppp-out'.
#
ipchains-restore remet les cha�nes que vous avez sauv� avec
ipchains-save. Il peut prendre deux options : "-v" qui d�crit chaque r�gle
lorsqu'elle est ajout�e, et "-f" qui force le nettoyage des cha�nes d�finies
par l'utilisateur si elles existent, comme d�crit plus bas.
Si une cha�ne d�finie par l'utilisateur est trouv�e � l'entr�e,
ipchains-restore v�rifie que cette cha�ne existe d�j�. Si elle existe,
alors vous serez interrog� pour savoir si la cha�ne doit �tre nettoy�e
(suppression de toutes les r�gles) ou si la restauration de la cha�ne doit
�tre saut�e. Si vous sp�cifiez "-f" sur la ligne de commande, vous ne serez
pas interrog� ; la cha�ne sera nettoy�e.
Par exemple :
# ipchains-restore < my_firewall
Restoring `input'.
Restoring `output'.
Restoring `forward'.
Restoring `ppp-in'.
Chain `ppp-in' already exists. Skip or flush? [S/f]? s
Skipping `ppp-in'.
Restoring `ppp-out'.
Chain `ppp-out' already exists. Skip or flush? [S/f]? f
Flushing `ppp-out'.
#
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:35