This is an archive of past FreeBSD releases; it's part of the FreeBSD Documentation Archive.
Contribution de Gary Palmer <gpalmer@FreeBSD.org> et Alexander Langer <alex@FreeBSD.org>.
Les coupe-feux suscitent un intérêt croissant de la part de gens qui se connectent à l'Internet, et sont même installés sur des réseaux privés pour accroître leur sécurité. Cette section vise à vous expliquer ce que sont les coupe-feux, comment les utiliser et comment mettre en oeuvre les possibilités offertes par le noyau de FreeBSD pour les implémenter.
Note: Les gens pensent souvent qu'avoir un coupe-feu entre le réseau interne de leur entreprise et le ``Grand Méchant Internet'' résoud tous leurs problèmes de sécurité.
Cela peut y concourir, mais une système de coupe-feu mal configuré présente pour la sécurité un risque plus grand que de ne pas en avoir du tout. Un coupe-feu ajoute une couche protectrice supplémentaire à votre système, mais ne sera pas capable d'empêcher un pirate réellement déterminé de pénétrer votre réseau interne. Si vous êtes laxiste quant à votre sécurité interne parce que vous croyez votre coupe-feu impénétrable, vous avez tout bonnement simplifié la tâche des pirates.
Il y a aujourd'hui deux types de coupe-feux différents d'utilisation courante sur l'Internet. Le premier est appelé plus justement routeur filtrant, quand le noyau d'une machine interconnectée à plusieurs réseaux sélectionne, en appliquant un ensemble de règles, les paquets qu'il transmet ou rejette. Le second, désigné par le terme de serveurs mandataires, s'appuie sur des ``démons'' pour assurer l'authentification et transmettre les paquets, éventuellement sur une machine interconnectée dont la transmission de paquets au niveau du noyau est désactivée.
Les sites combinent parfois ces deux approches, de telle sorte qu'une machine seulement (appelée bastion) soit autorisée à envoyer des paquets, via un routeur filtrant, sur le réseau interne. Les services mandatés, qui sont généralement plus sûrs que les mécanismes habituels d'authentification, sont fournis par le bastion.
Le noyau de FreeBSD inclut une fonctionnalité de filtrage de paquets (appelée IPFW), dont traite essentiellement la suite de cette section. Des serveurs mandataires sous FreeBSD peuvent être mis en oeuvre avec des logiciels extérieurs, mais il y a une telle variété de serveurs mandataires qu'il est impossible de les décrire dans ce document.
Un routeur est une machine qui transmet des paquets entre plusieurs réseaux. Le noyau d'un routeur filtrant comporte en plus du code qui applique à chaque paquet un jeu de règles pour décider de le transmettre ou non. La plupart des logiciels récents de routage IP comportent du code de filtrage de paquets. Pour l'utiliser, vous devez fournir au filtre un ensemble de règles sur la base desquelles il peut décider d'autoriser ou non la transmission des paquets.
Pour décider si le paquet peut passer ou non, le code parcourt les règles jusqu'à ce qu'il en trouve une qui corresponde aux en-têtes du paquet. Il effectue alors l'opération associée à la règle. Ce peut être rejeter le paquet, le transmettre, ou même répondre par un message ICMP à l'émetteur. La première règle trouvée, en séquence, est seule prise en considération. On peut donc parler d'une ``chaîne de règles''.
Les critères de sélection des paquets varient selon les logiciels, mais vous pouvez typiquement définir des règles basées sur les adresses IP de l'émetteur et du destinataire, les ports source et destination (pour les protocoles qui supportent les ports), voir le type de paquet (UDP, TCP, ICMP, etc...).
Les serveurs mandataires sont des machines sur lesquelles les ``démons'' du système standard (telnetd, ftpd, etc) sont remplacés par des serveurs spéciaux. Ce sont ces serveurs que l'on appelle serveurs mandataires, car ils n'autorisent normalement que les connexions entrantes. Cela permet (par exemple), avec un serveur mandataire telnet sur votre bastion, aux gens de se connecter de l'extérieur et d'accéder à votre réseau interne, après avoir satisfait à un mécanisme d'authentification (inversement, des serveurs mandataires peuvent être utilisés pour les connexions du réseau interne vers l'extérieur).
Les serveurs mandataires sont généralement plus sûrs que les serveurs ordinaires et disposent d'une plus grande variété de mécanismes d'authentification, dont les mots de passe ``à usage unique'', de façon à ce que, même si quelqu'un arrive à surprendre votre mot de passe, il ne puisse l'utiliser pour accéder à vos systèmes, puisqu'il expire aussitôt. Comme ils ne donnent pas aux utilisateurs l'accès à la machine qui les héberge, il en est d'autant plus difficile d'installer une entrée dérobée dans votre système de sécurité.
Les serveurs mandataires ont aussi souvent la possibilité de restreindre encore l'accès, de telle façon que seules certaines machines y soient autorisées, et peuvent aussi la plupart du temps être configurés pour définir quels utilisateurs peuvent accéder aux machines cibles. Là encore, les fonctionnalités disponibles dépendent des logiciels que vous choisissez.
IPFW, le logiciel fourni avec FreeBSD, est un système de filtrage de paquets et de comptabilité qui est intégré au noyau, et comporte un outil de configuration accessible à l'utilisateur, ipfw(8). Ensemble, ils vous permettent de définir et de consulter les règles appliquées par le noyau pour prendre ses décisions de routage.
IPFW comporte deux parties. Le coupe-feu s'occupe du filtrage de paquets. Il y a aussi une partie comptabilité IP, qui vous permet de tracer l'utilisation de votre routeur, sur la base de règles similaires à celle utilisée par le coupe-feu. Vous pouvez (par exemple) savoir quel trafic votre routeur reçoit d'une machine donnée, ou quel volume de requêtes WWW (``World Wide Web'') il transmet.
De par la conception d'IPFW, vous pouvez l'utiliser sur une machine qui ne fait pas de routage, pour filtrer les connexions entrantes et sortantes. C'est un cas plus particulier d'application d'IPFW que l'usage général, qui se gère avec les mêmes commandes et les mêmes techniques.
Comme la majeure partie du système IPFW est intégrée au noyau, vous devrez ajouter une ou plusieurs options à votre fichier de configuration du noyau, selon les possibilités que vous voulez utiliser, et recompiler votre noyau. Reportez-vous au chapitre Configurer le noyau de FreeBSD pour plus de détails sur la recompilation du noyau.
Il y a trois options de configuration du noyau qui concernent IPFW:
Intègre au noyau le code de filtrage de paquets.
Donne au code la possibilité de tracer les paquets via syslogd(8). Sans cette option et même si vous précisez dans vos règles que les paquets doivent être tracés, rien ne se passera.
Limite le nombre de paquets similaires tracés. Cette option peut être utile dans un environnement hostile, si vous voulez surveiller l'activité de votre coupe-feu, tout en évitant les attaques par refus de service qui submergeraient syslog.
Quand une règle atteint le nombre limite de paquets identiques, la trace est désactivée pour cette règle. Pour la remettre en service, vous devrez réinitialiser le compteur associé avec l'utilitaire ipfw(8):
# ipfw zero 4500
où 4500 est le numéro de la règle que vous voulez de nouveau tracer.
Il y avait, dans les versions antérieures de FreeBSD, une option IPFIREWALL_ACCT. Elle est maintenant obsolète. Le code du coupe-feu intègre désormais automatiquement les fonctions comptables.
La configuration du logiciel IPFW se fait avec l'utilitaire ipfw(8). La syntaxe de cette commande paraît assez compliquée, mais elle est relativement simple, une fois que vous en avez compris la structure.
L'utilitaire comporte quatre catégories de commandes: ajout/suppression, liste, vidage, réinitialisation. On ajoute et l'on supprime des règles de filtrage. On liste les règles. On vide la séquence de règles, pour supprimer toutes les règles. On réinitialise les informations comptables.
La syntaxe pour ce type de commande est:
ipfw [-N] commande [index] action [log] protocole adresses [options]
Il n'y a qu'un seul indicateur avec ce type de commande:
Résoudre les adresses et les noms de services dans les sorties.
La commande peut être raccourcie à son abbréviation univoque la plus courte. Les commandes valides sont:
Ajoute une entrée à la liste des règles de filtrage/comptabilité.
Supprime une entrée de la liste des règles de filtrage/comptabilité.
Des versions antérieures d'IPFW séparaient les règles de filtrage et celles de comptabilité. La version actuelle autorise la comptabilisation de chaque règle de filtrage.
L'index, s'il est renseigné, permet d'insérer la règle à un point précis de la séquence. Sinon, la règle est ajoutée en fin de séquence avec un index de 100 supérieur à la dernière règle existante (à l'exception de la règle par défaut, 65535, ``deny'').
L'option log active la trace de la règle à la console système, si le noyau a été compilé avec l'option IPFIREWALL_VERBOSE.
Les actions valides sont:
Refuse le paquet, et envoie un message ICMP hôte ou port non joignable (selon le cas) à l'émetteur.
Transmet normalement le paquet (alias: pass et accept).
Rejette le paquet. N'envoie pas de message ICMP à l'émetteur (tout ce passe comme si le paquet n'était jamais arrivé à destination).
Met à jour les informations comptables, mais le paquet n'est pas accepté/rejeté sur la base de cette règle. Le filtrage se poursuit avec la règle suivante de la séquence.
Chaque action est identifiable par son abbréviation univoque la plus courte.
Les protocoles qui peuvent être précisés sont:
N'importe quel paquet IP.
Les paquets ICMP.
Les paquets TCP.
Les paquets UDP.
Les adresses sont représentées comme suit:
from adresse/masque [port] to adresse/masque [port] [via interface]
Vous ne pouvez spécifier le port qu'avec les protocoles qui les supportent (UDP et TCP).
Le paramètre via est optionnel et définit soit l'adresse IP, soit le nom de domaine d'une interface IP locale, soit le nom d'une interface (e.g. ed0) pour que la règle ne s'applique qu'aux paquets passant par cette interface. Le numéro d'unité de l'interface peut être remplacé par un caractère de substitution. Par exemple, ppp* désigne toutes les interfaces associées au module PPP intégré au noyau.
La syntaxe utilisée pour adresse/masque est:
adresse
ou:
adresse/longueur_du_masque
ou:
adresse:masque_logique
Un nom de machine valide peut remplacer l'adresse IP. longueur_du_masque est une valeur décimale indiquant combien de digits de l'adresse doivent correspondre. e.g. 192.216.222.1/24 génère un masque tel que toutes les adresses d'un sous-réseau de classe C (dans ce cas, 192.216.222) soient sélectionnées. masque_logique est une adresse IP telle que le masque soit obtenu par intersection logique (``ET'') avec l'adresse associée. Le mot-clé any peut être utilisé pour indiquer ``n'importe quelle adresse IP''.
Les numéros des ports à bloquer sont indiqués par:
port [,port [,port [...]]]
pour donner un seul port ou une liste de ports, ou:port-port
pour donner une plage de valeurs. On peut aussi combiner une seule plage et une liste, mais la plage doit toujours être indiquée en premier.Les options disponibles sont:
Le paquet correspond si ce n'est pas le premier fragment d'un datagramme.
Le paquet correspond si c'est un paquet entrant.
Le paquet correspond si c'est un paquet sortant.
Le paquet correspond si son en-tête IP contient les options - séparées par des virgules - de la liste d'options. Les options IP reconnues sont: ssrr (``strict source route'' - routage strict par la source) lsrr (``loose source route'' - routage souple par la source), rr (``record packet route'' - enregistrer la route du paquet), et ts (``timestamp'' - date). L'absence d'une option est indiquée en la faisant précéder d'un !.
Le paquet correspond s'il fait partie d'une connexion TCP déjà établie, (i.e. si le bit RST ou ACK est positionné). Vous pouver optimiser les performances du coupe-feu en introduisant une règle established assez tôt dans la séquence.
Le paquet correspond si c'est un paquet qui initialise une connexion TCP (Le bit SYN est positionné mais pas le bit ACK).
Le paquet correspond si son en-tête contient les indicateurs - séparés par des virgules - de la liste d'indicateurs. Les indicateurs reconnus sont fin, syn, rst, psh, ack, et urg. L'absence d'un indicateur donné est indiquée en le faisant précéder d'un !.
Le paquet correspond si son type ICMP appartient à la liste types. La liste est donnée sous forme d'une combinaison de plages et/ou de types séparés par des virgules. Les types ICMP habituellement utilisés sont: 0 ``echo reply'' (réponse à un ping), 5 ``redirect'' (modification de la route), 8 ``echo request'' (émis par ping), et 11 ``time exceeded'' (utilisé pour indiquer que le TTL - ``Time To Live'' - durée de vie - ,a été atteint, avec traceroute(8), par exemple).
La syntaxe de cette forme de la commande est:
ipfw [-a] [-t] [-N] l
Il y a trois indicateurs valides avec ce type de commande:
Affiche avec la liste, les valeurs des compteurs. Cette option est le seul moyen de consulter les informations comptables.
Affiche la date de dernière concordance pour chaque règle de la séquence. Le format d'affichage n'est pas compatible avec la syntaxe d'entrée de l'utilitaire ipfw(8).
Essaye de résoudre les adresses et le noms des services.
La commande pour vider les règles est:
ipfw flush
Toutes les règles de la séquence sont supprimées, sauf la règle par défaut définie par le noyau (index 65535). Faites attention quand vous utilisez cette commande, la règle par défaut ``deny'' isolera votre coupe-feu du réseau jusqu'à ce qu'une nouvelle règle ``allow'' soit ajoutée à la séquence.
La syntaxe pour réinitialiser un ou plusieurs compteurs de paquets est:
ipfw zero [index]
Employée sans l'argument index, tous les compteurs sont réinitialisés. Si un index est précisé, l'opération ne s'applique qu'à la règle correspondante.
Cette commande empêchera le routeur de transmettre tous les paquets venant de la machine sales.pirates.org vers le port ``telnet'' de la machine chics.types.org:
# ipfw add deny tcp from sales.pirates.org to chics.types.org 23
L'exemple suivant rejette tout trafic TCP venant du réseau pirates.org (un réseau de classe C) vers la machine chics.types.org machine (quel que soit le port).
# ipfw add deny log tcp from sales.pirates.org/24 to chics.types.org
Si vous ne voulez pas que l'on puisse ouvrir de sessions X sur votre réseau interne (un sous-réseau d'un réseau de classe C), la commande suivante applique le filtrage adéquat:
# ipfw add deny tcp from any to mon.reseau.org/28 6000 setup
Pour lister les informations comptables:
# ipfw -a list
# ipfw -a l
# ipfw -at l
Note: Les suggestions ci-dessous ne sont rien que des suggestions. Les contraintes varient d'un coupe-feu à l'autre et je ne peux pas vous dire comment mettre en place le coupe-feu qui réponde à votre besoin particulier.
Lorsque vous commencez à configurer votre coupe-feu, à moins que vous n'ayez un banc d'essai pour faire vos tests dans un environnement que vous contrôlez, je vous conseille vivement d'utiliser les options de trace des commandes après avoir compilé un noyau supportant les traces du coupe-feu. Vous pourrez ainsi identifier rapidement les problèmes et y remédier sans provoquer trop de gêne. Même par la suite, je vous conseille de conserver l'option pour les commandes deny, ce qui vous permettra de tracer les attaques éventuelles et aussi de modifier vos règles si vos besoins évoluent.
Note: Tracer les commandes accept aboutit à de gros volumes de fichiers de trace, puisqu'il y a une ligne pour chaque paquet qui transite par le coupe-feu. Les transferts ftp/http importants ralentissent alors sérieusement le système. Cela augmente aussi le temps de latence pour ces paquets, parce que cela demande au noyau plus de traitement avant de les passer. syslogd utilisera aussi plus de temps CPU pour écrire toutes ces informations sur disque et peut même assez rapidement saturer la partition sur laquelle réside le répertoire /var/log.
Tel qu'il est livré, FreeBSD ne sait pas charger les règles du coupe-feu au démarrage du système. Je vous suggère d'appeler une procédure ad-hoc depuis la procédure /etc/netstart. Mettez cette procédure assez tôt dans le fichier netstart, de sorte que le coupe-feu soit configuré avant les interfaces IP. Il n'y a ainsi pas de possibilité d'accès tant que votre réseau est encore ouvert.
Employez la méthode que vous voulez pour charger les règles. La commande ipfw ne peut pas charger toutes les règles en une seule fois. Je procède de la façon suivante:
# ipfw list
pour écrire dans un fichier les règles que j'ai définies. Puis j'édite ce fichier pour ajouter ipfw au début de chaque ligne. La procédure peut alors être exécutée pour recharger les règles. C'est n'est peut-être pas la façon la plus efficace de procéder, mais cela marche.
La question suivante est de savoir ce que votre coupe-feu doit réellement faire! Cela dépend dans une large mesure des accès que vous voulez autoriser de l'extérieur à votre réseau et vice-versa. Voici quelques règles générales:
Bloquez tous les accès entrants sur des ports TCP en dessous de 1024. C'est là que les services les plus problématiques pour la sécurité se trouvent, comme finger, SMTP (courrier électronique) et telnet.
Bloquez tout traffic UDP entrant. Il y a très peu de services utiles qui fonctionnent sur UDP, et les services qui sont utiles menacent généralement la sécurité (e.g. Les protocoles RPC et NFS de Sun). Cela présente l'inconvénient que, comme le protocole UDP est sans état, les réponses aux requêtes UDP sortantes sont aussi bloquées. Cela peut poser problème à des utilisateurs internes qui veulent interroger des serveurs archie (prospero) externes. Si vous voulez autoriser l'accès à archie, vous devez accepter les paquets UDP venant des ports 191 et 1525 sur n'importe quel port UDP interne. ntp est un autre service que vous pouver envisager d'autoriser; il utilise le port 123.
Bloquez le trafic entrant vers le port 6000. Le port 6000 est utilisé pour accèder aux serveurs X11, et peut présenter des risques pour la sécurité (en particulier si les gens ont l'habitude d'utiliser xhost + sur leur station de travail). X11 peut en fait utiliser une plage de ports commençant au port 6000, la limite supérieure dépendant du nombre de sessions d'affichage qu'accepte la machine. La limite définie par la RFC 1700 est 6063.
Répertoriez les ports utilisés par les serveurs internes (e.g. serveurs SQL, ...). C'est probablement une bonne idée de les bloquer aussi, car ils sont normalement hors de la plage 1-1024 décrite plus haut.
Le CERT propose d'autres recommendations pour la configuration d'un coupe-feu à l'adresse ftp://ftp.cert.org/pub/tech_tips/packet_filtering.
Comme je l'ai dit plus haut, ce ne sont que des propositions. Vous devrez définir vous-même les règles à appliquer à votre coupe-feu. Je ne peux endosser AUCUNE responsabilité si quelqu'un s'infiltre sur votre réseau, même si vous suivez les conseils donnés ci-dessus.
| Précédent | Sommaire | Suivant |
| Kerberos | Niveau supérieur | Imprimer |
For questions about FreeBSD, e-mail
<questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.