Activation de Packet Filter sur les systèmes BSD

Date de publication : 22/10/2007

La prise en charge de Packet Filter varie de façon significative d'un système à un autre. Cet article a pour but de détailler la mise en oeuvre de PF sur les différents systèmes BSD.

1. FreeBSD
1.1. Support
1.1.1. Noyau
1.1.2. Modules
1.2. Démarrage
2. NetBSD
2.1. Versions 1.6 et antérieures
2.2. Versions 2.X
2.3. Versions 3.X
2.3.1. Support
2.3.1.1. Noyau
2.3.1.2. Module
2.3.2. Démarrage
2.4. Versions 4.X
2.4.1. Support
2.4.1.1. Noyau
2.4.1.2. Module
2.4.2. Démarrage
3. OpenBSD
4. DragonFlyBSD
4.1. Support
4.1.1. Noyau
4.1.2. Module
4.2. Démarrage
5. Conclusion
5.1. Epilogue
5.2. Remerciements

1. FreeBSD

Packet Filter n'a été intégré à FreeBSD que depuis sa version 5.3. Il existait auparavant un port qui permettait aux versions qui n'en disposaient pas de base de l'utiliser mais il n'est plus d'actualité aujourd'hui.

Les correspondances entre la version de votre système FreeBSD et celle de Packet Filter sont les suivantes :

La branche 5 et à partir de la version 5.3 donc, disposent de PF 3.5
Toutes les versions de la branche 6 sont munies de PF 3.7
La version 7.0 se verra mise à jour vers PF 4.1

1.1. Support

Vous avez ici le choix entre la modification puis la recompilation de votre noyau pour la prise en charge de Packet Filter et le chargement dynamique de modules.

1.1.1. Noyau

Pour une intégration dans le noyau vous devez reconfigurer celui-ci en y ajoutant les options suivantes :

Options à ajouter :

# Packet Filter
device          pf
device          pflog
device          pfsync

options         ALTQ
options         ALTQ_CBQ
options         ALTQ_RED
options         ALTQ_RIO
options         ALTQ_HFSC
options         ALTQ_PRIQ
#options        ALTQ_NOPCC # En SMP uniquement (machines multi-processeurs)

Recompilez le noyau, installez le et rebootez.

1.1.2. Modules

Le support de la gestion de la bande passante (ALTQ) n'est pas disponible si vous avez recours aux modules !

Modifions /boot/loader.conf pour que les modules relatifs au filtrage avec PF soient chargés au démarrage de la machine. Voici les lignes que vous devez y ajouter :

/boot/loader.conf :

# Packet Filter
pf_load="YES"
pflog_load="YES"

1.2. Démarrage

Il ne nous reste qu'à activer le filtrage et la journalisation au démarrage du système, pour ce faire modifions /etc/rc.conf tel que :

/etc/rc.conf :

# Packet Filter                    
pf_enable="YES"
pf_rules="/root/pf.conf" # Fichier de règles à charger
pflog_enable="YES"

2. NetBSD

2.1. Versions 1.6 et antérieures

Ces versions n'offrent aucun support de Packet Filter car trop "vieilles".

2.2. Versions 2.X

Pré-requis :

Les sources du système
Un noyau compilé ou qui sera recompilé avec les options LKM et PFIL_HOOKS

Packet Filter (3.7) n'est disponible que sous la forme d'un module dynamique que vous trouverez dans les paquetages. Avant de nous ruer dessus, il faut savoir que la gestion de la bande passante (ALTQ) et la prise en charge de l'adressage dynamique sont disponibles mais sous forme de patchs. Ces deux fonctionnalités sont optionnelles et indépendantes, mais voyons comment les mettre en oeuvre car vous pourriez en avoir besoin :

ALTQ : la première étape consiste à appliquer le patch. Les instructions sont les suivantes :

# On applique le patch
cd /usr/src/sys
patch -p0 < /usr/pkgsrc/security/pflkm/work/pflkm-20050511/patches/altq.diff

# Celui-ci entraîne un certain nombre de modifications à répercuter sur les sources qui composent le noyau
cp /usr/pkgsrc/security/pflkm/work/pflkm-20050511/include/net/pfvar.h /usr/src/sys/net
mv /usr/include/altq/ /usr/include/altq.old/
mkdir /usr/include/altq/
cd /usr/src/sys/altq
make includes

Seconde étape : il nous faut rajouter une option dans le noyau, le recompiler puis l'installer :

Option à ajouter :

options ALTQ

Troisième et dernière étape : indiquer explicitement, pour la construction du paquetage, que l'on compte utiliser cette option. Pour cela, on ajoute l'option ci-dessous à /etc/mk.conf :

/etc/mk.conf :

PKGOPTIONS.pf+= ifevents

L'utilisation de l'adressage dynamique (DHCP) sur une interface peut être problématique dans la mesure où lors de l'évaluation d'une règle le nom de l'interface est substituée par ses adresses. C'est pourquoi Packet Filter propose une syntaxe alternative pour prendre en compte cette particularité en entourant de parenthèses le nom de l'interface or le noyau de cette branche n'informe pas PF des changements d'adresse qui peuvent subvenir, d'où ce patch.
# On applique le patch cd /usr/src/sys patch -p0 < /usr/pkgsrc/security/pflkm/work/pflkm-20050511/patches/if_events.diff
Une recompilation du noyau sera nécessaire afin d'intégrer ces légères modifications apportées aux sources.

Nos intentions quant à l'utilisation des adresses dynamiques doivent là encore être explicitement déclarées dans le fichier /etc/mk.conf :
/etc/mk.conf :
PKGOPTIONS.pf+= ifevents

Nous pouvons maintenant poursuivre par la compilation et l'installation du paquetage :

cd /usr/pkgsrc/security/pflkm
make install clean

Il nous faut encore charger ce module au démarrage. Pour ce faire, nous éditons /etc/lkm.conf pour y ajouter la ligne suivante :

/etc/lkm.conf :

# path              options         entry           postinstall     output      when
/usr/pkg/lkm/pf.o   -               -               -               -           AFTERMOUNT

Puis pour que le chargement automatique des modules soit effectif au démarrage, l'entrée suivante doit être présente dans le fichier /etc/rc.conf :

/etc/rc.conf :

# Chargement dynamique de modules
lkm=YES

Et on ajoute dans ce même fichier, les variables qui nous permettront de charger nos règles et la journalisation au démarrage du système :

/etc/rc.conf :

pf=YES
pflogd=YES

Les scripts rc permettant le démarrage comme l'arrêt du filtrage doivent être copiés dans le répertoire /etc/rc.d/ puisque c'est à cet emplacement qu'ils seront cherchés :

cp /usr/pkgsrc/share/examples/rc.d/pf* /etc/rc.d/

Les règles seront chargées à partir du fichier /usr/pkg/etc/pf/pf.conf. Ce chemin vous est imposé et seule l'utilisation de liens symboliques vous permettront de passer outre.

2.3. Versions 3.X

Celles-ci incluent Packet Filter correspondant à la version 3.6 d'OpenBSD et certaines fonctions ne sont pas encore totalement implémentées. Parmi celles-ci on compte :

ALTQ, pour la gestion de la bande passante
CARP et pfsync, des outils pour assurer une haute disponibilité
le mot clé group, groupe auquel appartient l'émetteur local du paquet, est inopérant

Comme pour FreeBSD vous pouvez utiliser soit les modules dynamiques soit ajouter son support dans le noyau.

2.3.1. Support

2.3.1.1. Noyau

Pour une intégration dans le noyau, nous devons le recompiler en y définissant les options suivantes :

Options à ajouter :

# Packet Filter
options         PFIL_HOOKS              # pfil(9) packet filter hooks
options         BRIDGE_IPF              # bridge uses IP/IPv6 pfil hooks too

pseudo-device   pf                      # PF packet filter
pseudo-device   pflog                   # PF log if

2.3.1.2. Module

En revanche, dans le cas des modules (déjà présents sur votre système) vous devez rajouter à /etc/rc.conf la ligne ci-dessous afin d'indiquer au système de les charger au démarrage :

/etc/rc.conf :

# Chargement dynamique des modules
lkm=YES

Ensuite il nous faut fournir les informations nécessaires dans le fichier /etc/lkm.conf concernant pf :

/etc/lkm.conf :

# path          options         entry           postinstall     output      when
/usr/lkm/pf.o   -               -               -               -           BEFORENET

2.3.2. Démarrage

Le chargement des règles au démarrage et l'activation de la journalisation se fait à l'aide de nouvelles directives dans /etc/rc.conf :

/etc/rc.conf :

# Packet Filter
pf=YES
pf_rules="/root/pf.conf" # Fichier de règles à charger
pflogd=YES

Si vous venez à rencontrer un message d'erreur vous informant que /dev/pf n'existe pas, il vous faudra créer manuellement ce device. Nous utiliserons alors les commandes suivantes :

cd /dev/
./MAKEDEV pf

2.4. Versions 4.X

A l'heure où sont écrites ces lignes, la version 4.0 n'existe pas encore officiellement puisqu'elle est encore en développement.

La partie pfsync n'est toujours pas d'actualité. De même pour le mot clé group qui reste sans effet.

2.4.1. Support

2.4.1.1. Noyau

Voici la liste des options, qui sont en nombre conséquent et qui doivent être activées pour intégrer les fonctions de filtrage et de gestion de la bande passante directement au noyau :

Options à ajouter :

# Packet Filter
options         PFIL_HOOKS      # pfil(9) packet filter hooks
options         BRIDGE_IPF      # bridge uses IP/IPv6 pfil hooks too
# ALTQ
options         ALTQ            # Manipulate network interfaces' output queues
options         ALTQ_BLUE       # Stochastic Fair Blue
options         ALTQ_CBQ        # Class-Based Queueing
options         ALTQ_CDNR       # Diffserv Traffic Conditioner
options         ALTQ_FIFOQ      # First-In First-Out Queue
options         ALTQ_FLOWVALVE  # RED/flow-valve (red-penalty-box)
options         ALTQ_HFSC       # Hierarchical Fair Service Curve
options         ALTQ_LOCALQ     # Local queueing discipline
options         ALTQ_PRIQ       # Priority Queueing
options         ALTQ_RED        # Random Early Detection
options         ALTQ_RIO        # RED with IN/OUT
options         ALTQ_WFQ        # Weighted Fair Queueing

pseudo-device   pf              # PF packet filter
pseudo-device   pflog           # PF log if
pseudo-device   carp            # Common Address Redundancy Protocol

Recompilez et installez ce nouveau noyau. Pendant ce temps, vous pouvez passer à la suite afin de préparer le chargement automatique des règles.

2.4.1.2. Module

La gestion de la bande passante n'est pas disponible lorsque Packet Filter est activé par les modules. Vous devez impérativement recompiler votre noyau pour bénéficier de cette fonction.

Le module qui nous intéresse est déjà présent sur le système de base, nous avons juste à indiquer au système de le charger à son démarrage. Premièrement, il faut lui dire quels modules doivent être chargés et quand par rapport aux autres étapes que composent l'initialisation du système (montage des partitions, initialisation du réseau, ...). Nous éditons alors /etc/lkm.conf pour y ajouter le module qui nous intéresse :

/etc/lkm.conf :

# path          options         entry           postinstall     output      when
/usr/lkm/pf.o   -               -               -               -           BEFORENET

Puis ce chargement des modules n'étant pas fait par défaut, nous devons modifier ce comportement en ajoutant à /etc/rc.conf la ligne suivante :

# Chargement dynamique des modules
lkm=YES

2.4.2. Démarrage

On retrouve de nouveau notre fichier /etc/rc.conf, où cette fois-ci nous automatisons l'activation de la journalisation et le chargement de nos règles :

/etc/rc.conf :

# Packet Filter
pf=YES
pf_rules="/root/pf.conf" # Fichier de règles à charger
pflogd=YES

Il existe un autre fichier de configuration appelé pf.boot.conf que vous ne devez pas modifier et qui est systématiquement employé par le système lors du démarrage. Il a pour but de protéger la machine avant l'initialisation des interfaces réseau qui sera ensuite suivi de l'application de vos règles, qui elles sont définies par l'intermédiaire de la directive pf_rules du fichier /etc/rc.conf. De plus, ces règles sont limitées puisqu'elles sont chargées avant que les interfaces réseau ne se voient affecter une adresse.

3. OpenBSD

Packet Filter équipe le système OpenBSD depuis sa version 3.0. Son support intégral étant fortement ancré dans le noyau d'OpenBSD au moyen d'inclusion, vous n'avez aucun besoin de modifier votre noyau ou de vous orienter vers des modules. La gestion de la bande passante (ALTQ), la journalisation et autres options sont également présentes.

Par contre Packet Filter n'est pas actif par défaut. Pour une mise en marche automatique il vous faut modifier /etc/rc.conf.local tel que :

/etc/rc.conf.local :

pf=YES                   # Activation de Packet Filter
pf_rules=/etc/pf.conf    # Configuration à charger

4. DragonFlyBSD

Packet Filter a été injecté au projet DragonFlyBSD à sa version 1.2 et n'a pour ainsi dire pas évolué depuis : DragonFlyBSD 1.2 et 1.4 proposent la version 3.5 de PF et au-delà, la version 3.6.

Les limitations sur ce système sont les suivantes :

Le support de la gestion de la bande passante, ALTQ, est partiel (dépendant du driver de l'interface réseau)
CARP, pour la haute disponibilité, n'est pas intégré

4.1. Support

Vous avez aussi, ici, la possibilité d'utiliser ce pare-feu soit sous forme de module soit par l'intégration, donc recompilation, du noyau.

4.1.1. Noyau

Il sera nécessaire d'ajouter quelques options à votre noyau pour bénéficier de Packet Filter et éventuellement de la gestion de la bande passante :

Options à ajouter :

# PF
device          pf
device          pflog
device          pfsync

# ALTQ
options         ALTQ
options         ALTQ_CBQ
options         ALTQ_RED
options         ALTQ_RIO
options         ALTQ_HFSC
options         ALTQ_PRIQ

Recompilez puis installez ensuite votre noyau avant de redémarrer votre machine sur celui-ci.

4.1.2. Module

Le recours à la gestion de la bande passante (ALTQ) est impossible si vous avez recours au module !

Pour charger Packet Filter en tant que module au démarrage de la machine, complétez (ou créez) votre fichier /boot/loader.conf afin d'y reporter la ligne suivante :

/boot/loader.conf :

# Packet Filter
pf_load="YES"

4.2. Démarrage

Enfin, éditez le fichier /etc/rc.conf afin de d'activer PF et de lire votre configuration :

/etc/rc.conf :

# Packet Filter
pf_enable="YES"
pf_rules="/root/pf.conf" # Votre jeu de règles
pflog_enable="YES"

5. Conclusion

5.1. Epilogue

Force est de constater que NetBSD est en retard sur ses confrères puisque le support de Packet Filter n'est pas encore intégral mais en bonne voie. Par ailleurs, les tests que j'ai pu effectué sur la prise en charge de l'adressage dynamique sur ce même système se sont révélés peu concluants à l'exception des versions 3.

DragonFlyBSD, sur le papier, fournit un support quasi intégral de Packet Filter. A y regarder de plus près on est loin du compte : le support d'ALTQ est partiel et Packet Filter est, pour le moment, figé sur la version 3.6.

Seule l'activation de Packet Filter a été abordée jusqu'ici pour chacun des systèmes BSD, nous n'avons pas vu l'écriture des règles ni leur syntaxe. Ces dernières feront l'objet d'un tutoriel prochainement.

Liens Developpez :

5.2. Remerciements

J'adresse mes remerciements à mon relecteur Biglo pour ses corrections.

Sans négliger mes collègues de la section Linux pour leur soutien et les conseils qu'ils ont su m'apporter (ovh et Biglo).

Copyright © 2007 julp. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD.