pf est un outil très puissant permettant de créer un firewall sur mesure. Il possède toutes les capacités d'un firewall avec proxy, mais peut parfaitement etre configurer à votre guise, en tant que personnal firewall, firewall stateful ou firewall-proxy, selon vos besoins (cf. doc sécurité). Ce système se base sur deux choses :

• Le système de filtrage en lui-meme, géré par le kernel, et se basant sur un fichier de configuration pour les règles de filtrages (filtrage au sens large : ce meme fichier regroupe également les règles de proxy et de redirection).
• Des application sattelites, de bas niveau, qui permettent par exemple le fonctionnement du proxy ou le filtrage des spams, par un renvoi des paquets IP vers le port de ces applications.

L'activation du firewall sous OpenBSD se fait à partir du fichier /etc/rc.conf, qui gère le fonctionnement de la majorité des applications système et réseau. Pour activer le firewall, vous devez editer le fichier /etc/rc.conf, et modifier la ligne pf=NO en pf=YES. En faisant cela, vous activez le support des règles de filtrage au démarrage de votre machine, cependant, vous ne l'avez pas configuré.

Afin de pouvoir manier votre firewall, vous avez un script à votre disposition, qui vous permet de l'activer et le désactiver, de déboguer votre fichier de règles et de vous fournir diverses informations liées à votre firewall. Il s'agit de la commande pfctl. Cette commande vous servira pour à peu près tout, n'hésitez pas à jeter un coup d'oeil à la man page. Voici quelques infos utiles : Pour activer et desactiver le firewall

# pfctl -e

 # pfctl -d
  

Pour parser le fichier de règle (sans le charger) et idem, en le chargeant :

 # pfctl -nf [fichier]
 # pfctl -f [fichier]
  

Ici, on ne charge que les règles de filtrage, puis de nat.

 # pfctl -Rf [fichier]
 # pfctl -Nf [fichier]
  

Dans ces quatre cas, si vous ne donnez pas de fichier, /etc/pf.conf est pris par défaut. Pour avoir des infos sur : les fitrages, le nat, l'etat, les stats et sur tout à la fois.

 # pfctl -s rules   - ou bien - # pfctl -sr
 # pfctl -s nat     - ou bien - # pfctl -sn
 # pfctl -s state   - ou bien - # pfctl -ss
 # pfctl -s info    - ou bien - # pfctl -si
 # pfctl -s all     - ou bien - # pfctl -sa
  

Pour faire un flush sur tout ou partie des règles :

 # pfctl -F all
 # pfctl -F rules
 # pfctl -F nat
  

vide successivement tout, les règles de filtrage, puis de nat. Comme vous l'aurez compris, -s comme show, bien sur. Vous pouvez aussi regrouper certaines options. Ainsi, pour redémarrer le firewall en rechargeant le fichier de règles, cela donne :

 # pfctl -d -e -F all -f /etc/pf.conf
  

Souvent, utilisateurs privés possèdent une IP dynamique. Cela a des répercutions sur le firewall. Les conséquences sont les suivantes : le réseaux ou la machine protégé n'a plus d'accès vers l'exterieur.

• Pourquoi y a t-il un problème ?

Tout d'abord, lors de la reconnection, en général par pppd, vous retrouvez bien un périphérique réseau, avec une adresse IP valide. Cependant, vous n'arrivez pas à recevoir le moindre paquet provenant de celui-ci. pf possède quelques macros (nous verrons lesquelles au chapitre suivant), dont une qui possède le meme nom que votre périphérique réseau (ce nom ne variant pas d'une connection sur l'autre, car il dépend du hardware). Prenons l'exemple du périphérique tun0. (Il s'agit des modems speedtouch, pour les curieux). Au moment où pf se charge, il assigne à la macro (la variable de nom tun0) l'adresse IP de tun0, c'est à dire l'adresse IP de votre modem. Cependant, si il y a deconnection/reconnection, votre adresse IP change, mais celle assignée à la macro non, car pf n'a pas été rechargé. Le problème, c'est que toute vos règles qui autorisent des paquets IP de passer sont basées sur cette macro, avec la mauvaise IP. Et comme vous avez (j'éspère) bloqué toute autre entrée précédement… rien ne passe.

• Régler le problème :

Pour cela, il faut redémarrer le firewall à chaque déconnection/reconnecion. Heureusement, il existe des scripts que vous connaissez peut-etre : ppp.linkup et ppp.linkdown, qui sont respectivement executés à la connection et à la deconnection. Afin de ne plus avoir ce problème, ajoutez ceci à ppp.linkdown :

 ! /sbin/pfctl -d
  

Et ceci à ppp.linkup :

 ! /sbin/pfctl -e -F all -f /etc/pf.conf
  

pf fournit quelques macros qui permettent à l'utilisateur de pouvoir écrire plus facilement ses règles. Les premières d'entre elles sont les macros des périphériques réseau. En effet, à chaque fois (presque) que vous créerez une règle de filtrage, ce sera pour un périphérique réseau spécifique, et vous utiliserez le nom de ce périphérique dans votre règle qui sera remplacé par la valeur de son adresse IP. Ainsi, une machine ayant rl0 et tun0 comme périphérique réseau, aura également les macros rl0 et tun0. Avec celles-ci, on peut construire des règles de ce genre :

 pass in on tun0 proto tcp from any to any port 21 keep state

Cette règle, qui laisse entrer les paquet ayant pour destination un port 21 et étant de protocole TCP, deviendra ceci, si votre périphérique tun0 a pour IP 193.250.51.41 :

 pass in on 193.250.51.41 proto tcp from any to any port 21 keep state
  

On constate donc que tun0 est une macro prédéfinie. Il en est de meme pour tous vos périphériques réseau actifs au moment du lancement de pf. (faites un ifconfig -a pour savoir quels sont ceux que vous possedez).

Il n'y a pas d'autre macro prédéfinie. Cependant, vous pouvez en créez, au début de votre fichier /etc/pf.conf. Créer une macro est très simple est très utile. Cela vous permet de réduire considérablement la longueur des règles de filtrage. Pour créer une macro, vous devez juste taper :

 nom_de_macro=valeur
  

Cependant, vous ne devez pas utiliser ni les noms des macros prédéfinies, ni les mots clés de la syntaxe de pf (cf. plus loin).

On créée en général des listes afin de simplifier l'ecriture des règles. Imaginez que vous avez un réseau de 3 machines derrière votre firewall, et que vous voulez autoriser les connections vers l'exterieur de ces machines vers les ports 21, 22, 25, 80, 110, 443. Je vient de lister les ports. Il serait utile de ne pas avoir à écrire autant de règles que de ports. Alors on fait ceci :

 tcp_ports={ 21, 22, 25, 80, 110, 443 }
 # regle :
 pass in on proto tcp from any port $tcp_ports to any keep state    

Encore mieux, on ne veux pas que les paquet IP transmis vers le réseau aient pour cible une machine qui n'est pas présente. Alors on liste les machines du réseau.

 reseau={ 10.0.0.2/24, 10.0.0.3/24, 10.0.0.4/24 }
 # regle :
 pass in on proto tcp from any port $tcp_ports to $reseau keep state
  

Dans le cas de 15 machines, par exemple, on ne s'amuse pas à toutes les lister. En général, les réseau de taille moyenne et grosse possède un masque de sous-réseau qui ne peux pas permettre beaucoup plus de machines que le nombre préexistant (cf. doc réseau). Dans ce cas là, on créer une macro avec uniquement la partie réseau de l'adresse IP. Exemple d'un réseau de 223 machine, d'adresse 192.168.1.*/24. Alors on créér :

 reseau=192.168.1/24
  

Dans ce cas, pf autorise toutes les machines dont la partie réseau est 192.168.1.

Avant toute choses il faut connaitre l'ordre dans lequel le fichier pf.conf doit être écrit. On doit faire succéder différents types de structures qui ne doivent jamais être inverser, sous peine de rendre son fichier faux. Cet ordre est le suivant :

- Macros

• variables
• queues (définitions)
• tables (définitions)

- NAT

- RDR

- Règles

• gestion des paquets
• règles d'entrée-sortie

Nous verrons NAT (Network Adress Translation) et RDR (Redirection) plus tard, occupons nous des règles : Tout d'abord, il existe une règle spécifique, appellée scrub, qui permet de définir la gestion des paquets IP transitant par le firewall. En effet, il est possible de préciser si les paquets doivent être recomposés ou s'ils doivent être conservés séparés à chaque passage. Scrub permet de les recomposer, et fournit une protection contre certaines attaques (de vers nottament). De plus, ils bloques les paquets ayant des combinaisons de flags TCP incorrectes. Nous verrons plus tard ces combinaisons. La forme la plus employée de cette règle est :

 scrub in all   

Cela permet de recomposer les paquet sur toutes les interfaces. Cependant, cela pose quelques problèmes avec les connections NFS. Il est alors plus adequat de filtrer toutes les interfaces sauf celles faisant transiter des paquets pour des connections NFS, qui en général sont réservées à des réseaux surs.

Cependant, voyons d'un peu plus près cette règle. Elle possède diverses options, dont certaines peuvent être très utiles pour empécher les prises d'empreintes par les scans de ports comme nmap. En effet, les scans de ports détectent quel système d'exploitation se trouve sur la machine cible en annalysant les paquet retournés par celle-ci. Il regarde leur ttl, leur mss, et diverses options propres à chaque OS. Afin de bloquer cette prise d'empreinte, on modifie ces caractéristiques grace à cette option. Voila quelques options du scrub :

  
 * **no-df** : Vide le bit signalant de ne pas fragmenter du paquet IP.
 * **min-ttl <valeur>** : Précise le TTL (Time To Live) minimum des paquets sortant, remplacant la valeur par défaut liée à l'OS.
 * **max-mss <valeur>** : Modifie la valeur du MSS des paquets sortant, de la même manière.
 * **random-id** : Remplace la valeur du champ d'identification IP par une valeur aléatoire pour les paquets sortant non fragmentés.

Voici un exemple de ligne de scrub avec les options no-df et random-id :

 scrub in all no-df random-id    

Pour filtrer les port, la syntaxe est assez proche de iptables sous GNU/Linux. Voyons tout d'abord la structure de base :

pass|block in|out [log] [quick] on int [inet|inet6] [proto protocole] \
   from adr_source [port port_source] to adr_dest [port port_dest] \
   [tcp_flags] [etat]

Regardons de plus près chacun des termes :

• pass|block : Selon que vous choisissiez l'un ou l'autre, vous créer une règle de passage ou d'interdiction.
• in|out : Direction des paquets que vous filtrez dans l'interface qu'ils traverse. in représente une arrivée vers votre machine, out une sortie.
• log : (optionnel) précise que chaque fois que cette règle est employée, une trace est conservé dans un fichier de log lisible à l'aide de l'utilitaire tcp-dump.
• quick : (optionnel) Marque la règle comme indépendante. Toute autre règle antagoniste sur des paquets dépendants de celle-ci n'a pas d'effets sur eux.
• int : l'interface. Représente le nom ou la macro de l'interface réseau à filtrer. Utilisée dans presque toutes les règles sauf celles de bloquage inconditionnel au début (cf. plus loin).
• inet|inet6 : (optionnel) Précise le type de paquets IP qui seront filtrés : il peut s'agir de paquet ipv4 (inet), ipv6 (inet6) ou les 2 si vous ne mettez rien.
• proto|protocole : (optionnel) Précise le protocole qui sera filtré. Il peut s'agir de tcp, udp ou icmp. vous pouvez réunir tcp et udp en une famille { tcp, udp } pour que cela affecte les deux protocoles. Dans le cas où vous utilisez icmp, vous ne pouvez pas spécifier de ports (cf. plus loin).
• adr_source|adr_dest : (optionnel) adresse source est destination du paquet. Permet de limiter par exemple les sources des paquets pour les serveurs DNS.
• port_source|port_dest : (optionnel) Précise port source et port de destination des paquets.
• tcp_flags : (optionnel) Définit les structures de flags qui doivent etre filtrés. Par exemple un pass […] S/SA keep-state laisse passer les paquet TCP avec un flag SYN activé parmis SYN et ACK.

A partir de la vous devrez pouvoir définir quelques règles sans difficulté. Nous allons voir quelques exemples afin de mieux appréhender le fonctionnement.

Tout d'abord, les règles simples, blocage de tous les ports, puis ouverture pour un serveur web :

 block log in all
 pass in on lo0 all
 pass in on $ext_if proto tcp from any to $ext_if port 80 keep state
  

Commentons un peu. Tout d'abord, on bloque tout avec la première règle. Dans ce cas. rien ne sort ni ne rentre, quelle que soit l'interface. Vous pouvez constater le log qui signifie que tous les paquets qui ne passent pas grace aux règles suivantes seront logués sur l'interface pflog0 (cf. plus loin). La deuxième règle permet d'ouvrir la lo (loopback interface) utilisée par certaines applications locales, et qui peut etre utile pour des tests. La troisième règle permet d'ouvrir le port 80 en entrée. On n'a en effet bloqué uniquement les entrées. Cette règles autorise uniquement les paquets ayant comme IP de destination l'adresse IP de votre interface $ext_if (ext_if étant une macro contenant le nom de votre interface - tun0, rl0…). Ces paquets doivent passer par le port 80 et peuvent avoir n'importe quelle source.

On peut lister les ports et les protocoles. Voila quelques exemples :

 pass in on $ext_if proto { tcp, udp } from any port 53 to $ext_if keep state
 pass in on $int_if proto tcp from $reseau to $int_if port > 41500 keep state
 pass in on $ext_if proto udp from $reseau to $int_if port 1500 >< 1600 keep state
  

La première règle montre une union de 2 protocoles. Les paquets de type tcp et udp sont acceptés. La deuxième règle ouvre les ports supérieurs à 41500 aux paquets tcp entrant du réseau. Remarque : Ici les seuls les paquets ayant pour destination l'IP de l'interface interne sont autorisés. Ainsi, si vous communiquez avec le serveur avec son IP locale, les paquets passeront, si vous utilisez l'IP de l'interface exterieure, il seront bloqués. Lister les ports se fait facilement, avec les signes >, >=, <, ⇐, >< et !=, le dernier signifie que la règle s'applique à tous les ports sauf celui succédant.

Un dernier mot sur le mot-clé quick. De base, lorsqu'un paquet est transmit au firewall, les règles sont lues de bas en haut. Un paquets peut etre dépendant de plusieurs règles, cependant, c'est celle lue en dernier qui agira sur lui. Il est possible de contrecarrer cette loi. Le mot clé quick appliqué à une règle de filtrage signifie qu'elle 'gagne' sur toutes les autres règles pour les paquets qu'elle gère. Ainsi :

 pass in quick on lo0 all
 block in all

Dans ce cas là, les paquets IP de la lo seront autorisés, malgré le fait qu'il dépendent aussi de la règle suivante qui les bloque. Le mot-clé quick est placé juste après le sens du paquet (in|out).

Il est possible, à l'aide de pf, de réduire l'accès à certains services qu'à certains utilisateurs. Nous verrons que cela est utile pour certain services tels que les proxys, seuls habilités à se connecter à certains ports.

Nous allons maintenant voir la modulation des paquets aux travers des règles. Comme vous l'avez constaté, chacune des règles ci-dessus se finie par keep state. Cela signifie que les paquets sont conservés tels quels pendant le filtrage. Cependant, il est possible de moduler les flags des paquets, pour limiter les connections qu'à des paquets ayant une certaine combinaison de flags, conventionnelle. Voyons un exemple :

 pass in on $ext_if proto tcp from any to $ext_if port 80 modulate state flags S/SA
  

Les trois mots modulate state flags signifie que le paquet sera modifié si besoin, au niveau de sa combinaison de drapeaux. Le dernier terme signifie le type de combinaison que le paquet doit avoir. Avant le / se trouve les flags qui doivent etre activés, après le / ceux qui sont controlés. Ainsi, S/SA signifie que sur les flags SYN et ACK, SYN doit etre activé et ACK non lors de la connection. Il s'agit d'un comportement standard lors d'une demande de connection TCP en 3 temps, c'est pourquoi on emploie facilement la combinaison S/SA. Voyons les différentes lettre représentant les différents flags :

• S : SYN (synchronisation)
• A : ACK (acknowledgment)
• F : FIN (Finish)
• R : RST (Reset)
• P : PSH (Push)
• U : URG (Urgent)
• E : ECE (Explicit Congestion Notification Echo)
• W : CWR (Congestion Window Reduced)

Il faut donc faire attention en modulant les flags, pour ne pas risquer de bloquer les connections légitimes. Voyons une dernière chose sur les flags : les règles de blocage général. En effet, certaines combinaisons de drapeaux (je rapelle qu'il y en a 8!) ne sont pas standard et sont utilisées pour des scans de ports ou autres. Afin de vous en prémunir, vous pouvez interdire certaines combinaisons indépendament des services ou des protocoles. Voila quelques règles utilisées pour bloquer les scans :

 block in quick proto tcp all flags SF/SFRA
 block in quick proto tcp all flags SFUP/SFRAUP
 block in quick proto tcp all flags FPU/SFRAUP
 block in quick proto tcp all flags /SFRA
 block in quick proto tcp all flags F/SFRA
 block in quick proto tcp all flags U/SFRAU
 block in quick proto tcp all flags P/SFRAUPE
  

pf écrit ses logs dans des fichiers lisibles uniquement par tcpdump, du nom de pflog, se situant dans le dossier /var/log/.tcpdump (ou tout autre outil qui l'emploie, comme ethereal) vous permet donc de lire ce fichier. Il vous est également possible d'afficher les logs en temps réel, toujours via tcpdump, en affichant les données transmises via l'interface réseau employées pour les logs de pf : pflog0. Afin que la gestion des logs puisse être effectuée, il faut que le démon pflogd soit activé. Si pf est démarré via le fichier d'initialisation /etc/rc.conf, pflogd sera automatiquement exécuté. Sinon, il vous faudra l'exécuter vous-même, via un prompt :

 # pflogd
  

• structure : Lorsqu'une règle emploie le mot-clé log, seul le premier paquet de chaque connexion est logué. Cela permet de réduire considérablement la lourdeur du fichier. Cependant, il est possible de retransmettre l'integralité de la communication, en utilisant le mot clé log-all. Voyons deux exemples de règles, utilisant chacune un mot clé différent :

 pass in log on tun0 proto tcp from any to tun0 port sunrpc modulate state S/SA
 block in log-all on  rl0 from any port 1234 to any port >1024
  

Il faut cependant utiliser le mot clé log-all avec parcimonie, afin de ne pas alourdir la charge du firewall.

• lecture des logs : Voyons les cas de lecture du fichier de logs avec tcpdump et ethereal, comme expliqué plus haut :

 # tcpdump -n -e -ttt -r /var/log/pflog
 # ethereal -r /var/log/pflog0
  

Dans le cas d'une lecture en temps réel des logs, on réutilise toujours ces outils, mais sur l'interface pflog0 :

 # tcpdump -ttt -i pflog0
 # ethereal -i pflog0
  

Le NAT permet, lorsque vous possédez une seule adresse IP externe (utilisable sur internet), de pouvoir partager votre connexion entre plusieurs machines (le nombre de machines peut être très grand). Le principe est le suivant :

• Une machine est utilisée comme routeur, c'est elle qui se connecte au réseau extérieur ou à Internet.
• Les autres machines sont reliées par une connexion Ethernet, wifi, tocken ring…)
• La configuration du réseau local utilise une des classes d'adresses destinées à cette utilisation : 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
• La passerelle du réseau (qui devient un routeur car faisant une transformation des adresses IP locales (cf. les deux type de NAT, plus loin), est configurée pour gérer le NAT.

Il existe de types de NAT. Cela permet de gérer plusieurs situations. Les différents types sont les suivants :

• NAT unidirectionnel : Il s'agit de l'utilisation la plus simple du NAT. Pour chaque paquet provenant du réseau interne, le routeur modifie l'adresse IP source et la remplace celle de son interface réseau externe. Les paquets reçus ensuite par le routeur sont ensuite renvoyés vers la machine source, et ce sans modifier l'adresse source. En conséquence, les machines du réseau local envoient et reçoivent des données directement des machines externes, et donc ont utilise directement les adresses de celles-ci.

Voyons maintenant la configuration nécessaire à la mise en place d'un NAT unidirectionnel. Pour cela, il faut ajouter une règle commençant par le mot clé nat dans le fichier pf.conf. Voici d'abord la structure :

 nat on interface_ext from reseau_int to any -> interface_ext
  

Un exemple :

 nat on tun0 from 192.168.0.0 to any -> tun0

Il faut bien remarquer que le NAT se fait sur l'interface externe du routeur, car en le plaçant sur l'interface interne de celui-ci, les requêtes ayant pour destination le routeur lui-même passerait par le NAT, ce qui est parfaitement inutile, puisque son interface interne fait partie du réseau local. Voici la signification de l'exemple ci-dessus : “Mise en place du NAT sur l'interface tun0, pour les paquets provenant du réseau 192.168.0.0 vers n'importe quelle destination, pour remplacer l'IP source par l'IP de l'interface tun0”. Il est également possible de bloquer le NAT pour certaines source (ports, machines, destinations), en utilisant le mot clé no nat. Un exemple concret est de bloquer est de bloquer me NAT pour une machine du réseau :

 no nat on tun0 from 192.168.0.5/24 to any

Enfin, il faut penser à bien placer les règles règles du NAT (cf. § premières règles).

• NAT bidirectionnel : Le NAT bidirectionnel est plus complexe : il modifie l'adresse des machines du réseau, comme le précédant, ainsi que celles du réseau extérieur. Ainsi, les machines du réseau interne ne communique qu'avec le routeur pour toute connexion extérieure. Ainsi l'adresse source des paquets transitant par le routeur vers l'intérieur du réseau auront toujours comme adresse source l'IP de l'interface interne du routeur.

Le mot-clé employé est binat. La structure de la règle est cependant très semblable :

 binat on interface_ext from reseau_int to any -> interface_ext

Voici un exemple :

 binat on tun0 from 192.168.0.0 to any -> tun0

Il se peut que plusieurs adresses IP soient utilisables pour le réseau exterieur (dans le cas, par exemple, ou le FAI (Fournisseur d'Accès Internet) fournit plusieurs adresses IP). Il est alors possible d'utiliser le NAT bidirectionnel pour remplacer en façade l'adresse locale d'une machine par une adresse IP accessible directement par le réseau extérieur. Voici la structure générale :

 binat on interface_ext from IP_locale to any -> adresse_IP_2

Voici un exemple ou la machine 192.168.0.2, interne au réseau, aura pour adresse IP 193.214.56.32 pour les machines extérieures au réseau :

 binat on tun0 from 192.168.0.2 to any -> 193.214.56.32

Cela permet donc d'employer plusieurs IP accessibles par le réseau extérieur dans le réseau local.
En complément du NAT, il existe les redirections, qui sont expliquées au chapitre suivant.

Les redirections sont utiles pour un grand nombre de configurations. Elles permettent facilement de renvoyer des connexions sur d'autres ports ou d'autres machines, et permettent ainsi une configuration plus complexe mais plus aboutie des réseaux. De plus, tout comme le NAT, elles fonctionnent de manière transparente. Les redirections sont également intégrées au firewall. La structure de base est celle-ci :

rdr on interface proto protocole from source(s) to  destination port \
numéro(s) -> destination(s) port numéro(s)

Les règles de redirections se placent juste sous les NAT dans le fichier pf.conf (cf. § premières règles). Voyons un exemple de redirection des données entrant sur le port 25 (dans le cas par exemple d'un serveur SMTP se trouvant sur une machine du réseau interne). les connexions sur le port 25 sont alors renvoyé vers l'IP de cette machine, sur sont port 25 également :

 rdr on tun0 proto tcp from any to tun0 port 25 -> 192.168.0.4

On peut constater dans cet exemple qu'il n'y a pas le mot clé port à la fin de la règle. En effet, lors d'une redirection entre deux ports identique, il n'est pas obligatoire de signifier le port de destination, qui est implicitement le même que le port source s'il n'est pas précisé. Il est également possible de faire une redirection d'une intervalle entière de ports, en remplaçant le port source par une intervalle, tout comme il est possible de renvoyer vers une intervalle de ports. Cela peut être le cas pour un serveur ftp se trouvant sur une machine du réseau. Les connections en mode passif utilise en effet une fenêtre de ports, et il faut donc renvoyer la fenêtre complète vers le serveur ftp, qui peut tout à fait avoir une fenêtre de ports décalée. La redirection donnerait ceci :

 rdr on tun0 proto tcp from any to tun0 port 45000:50000 -> 192.168.0.4 \
 ports 35000:40000

Il s'agit là d'une redirection plus complexe, mais très efficace. Il est également possible de faire une redirection en local, d'un port vers un autre. Cela peut être utile lors de l'utilisation d'un proxy ou de services tels que spamd (cf. § Autres redirections intéressantes). Voici un exemple du port 80 vers le port 8080 :

 rdr on tun0 proto tcp from any to tun0 port 80 -> 127.0.0.1 port 8080

Toutes les utilisations habituelles des redirections ont été vues. Les chapitres qui suivent décrivent des cas particuliers.

Le protocole ftp est tel qu'il est difficile d'utiliser un client ftp derrière un routeur, car le protocole ftp, qui utilise le port 21 pour la connexion, renvoie les données sur plusieurs ports, et a pour conséquence de compromettre une bonne réception des données pour le client. Afin de régler le problème, pf utilise un proxy ftp, qui s'occupe de gérer les connexions entre les machines du réseau interne et les serveurs ftp externes. Afin d'activer le proxy, il faut renvoyer les connexions des clients vers le port 21 des machines externes vers le port 8021 local, où est activé le proxy. Celui-ci servira ensuite d'intermédiaire entre le serveur ftp et le client. Dans la pratique, il s'agit d'une redirection des paquets sortant du réseau et ayant pour destination un port 21 vers le port 8021 local, soit une redirection locale entre deux ports. Avant tout, il faut que le proxy soit activé, cela via le démon inetd. Il faut donc ajouter une ligne à son fichier de configuration (/etc/inetd.conf), puis le redémarrer pour qu'il prenne en compte la nouvelle configuration. Il est conseillé de démarrer le proxy ftp avec l'option -t 300 qui permet de fermer une session si elle reste inactive plus de cinq minutes (300 secondes). Par défaut, une session peut en effet rester ouverte indéfiniment. La ligne à ajouter au fichier inetd.conf est celle-ci :

 127.0.0.1:8021 stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy

Une fois ceci fait, il faut ajouter la redirection, afin d'activer la configuration dans le firewall :

 rdr on tun0 proto tcp from 192.168.0.0/24 to any port 21 -> 127.0.0.1 \
 port 8021

Dans cet exemple, on voit bien que les communications du réseau vers l'interface externe du routeur et partant vers un port 21 sont renvoyées vers le port 8021 de celui-ci. Avec ces modifications, les connexions ftp sont fonctionnelles et sécurisées, car l'utilisation du proxy permet également de filtrer les paquets, éliminant ceux qui ne correspondent pas à une connexion ftp.

L'outil pf permet également l'utilisation d'un système anti-spam, nommé spamd, intégré directement au firewall. Le principe est le suivant : spamd se base sur des serveurs fournissant une base de données des adresses IP des relais mail ouverts. Il récupère régulièrement la dernière version de ces bases, et rentre toutes les IP dans une table du firewall. Le firewall lit ensuite la table à chaque connexion sur le port smtp. Si l'adresse source se trouve dans la table, il revoie la connexion vers le port du service réseau spamd, qui va ralentir au maximum la transaction, avant de renvoyer le mail avec une erreur. Cela a pour avantage à la fois de filtrer les mails au niveau du firewall, et de ralentir au maximum les spammeurs. La mise en place se fait de cette manière : Avant toute chose, il faut configurer spamd, pour lui signaler où se mettre à jour, et ajouter une table d'adresse IP dites de confiance, qui ne seront pas vérifiées. La configuration se fait via un fichier, par défaut /etc/spamd.conf. Il se décompose en blocs gérant chacun une base de données d'adresses, et d'un premier bloc précisant les bases à utiliser. Voici un exemple de bloc :

spews2:\
	:black:\ :msg="SPAM. Your address %A is in the spews level 2\n\
	database. See http://www.spews.org/ask.cgi?x=%A for more details":\
	method=http:\
	:file=www.spews.org/spews_list_level2.txt:\

La première ligne précise le titre du bloc, qui devra être noté dans le bloc listant les bases. La deuxième précise le type de liste (white, black ou grey depuis OpenBSD 3.5). La troisième ligne indique le message d'erreur qui sera renvoyé à l'adresse source. La dernière ligne précise le fichier contenant la base de données d'adresses IP. Il faut bien faire attention à la structure. Chaque précision (type de liste, message, fichier) commence et finit par le caractère :, et les lignes se finissent toutes par le caractère /. Le fichier de configuration est normalement préconfiguré à l'installation avec trois bases de données. Il est cependant possible d'y ajouter d'autres base, comme une liste blanche d'adresses. Dans ce cas, il faut mettre white à la place de {black}, et préciser un fichier local contenant les adresses IP de confiance. Ce fichier ne doit contenir que des adresses IP. Il est cependant possible d'y inclure des commentaires, en plaçant le caractère # avant. Une fois la configuration effectuée, il faut placer dans le cron la mise à jour régulière des tables :

 0       *       *       *       *       /usr/libexec/spamd-setup 1>/dev/null 2>>/var/log/spamdmaj

Cette ligne du crontab met à jour spamd toutes les heures, et renvoie d'éventuelles erreurs dans un fichier de log : /var/log/spamdmaj. Il faut ensuite placer la redirection dans le fichier de configuration du firewall. La ligne à ajouter est celle-ci :

 rdr inet proto tcp from  to any port smtp -> 127.0.0.1 port 8025

Il faut également ajouter la définition de la table spamd, au tout début du fichier, après d'éventuelles définitions de macros :

 table  persist

Une fois ceci fait, il ne reste plus qu'à activer spamd. Pour cela, il faut modifier le fichier rc.conf la ligne suivante :

 spamd_flags=NO

Pour mettre à la place :

 spamd_flags=""

Cette aide a été écrite à partir de la faq. pf du site OpenBSD.org. L'aide de base est en anglais.

Auteur : Philippe Thierry
Mis Sur Le Wiki Par :Azwaw OUSADOU|