Plus : 3.11 Configuration du domaine En haute : 3. Configuration de la Retour : 3.9 Route supplémentaire (optionnel)
Le Kernel de Linux utilisé par fli4l met à disposition un filtrage de paquets. A l'aide de ce filtrage de paquets, on contrôle les flux qui communiquent avec le routeur et au de là de celui-ci. Par ailleurs, vous pouvez réaliser des dispositifs comme la redirection de port (redirige les paquets réçus par le routeur et les transmettre à un ordinateur du réseau interne) et le masquage (en anglais masquerading. Les paquets provenant d'un ordinateur du réseau interne derrière le routeur sont modifiés, de telle sorte que ces paquets semblent provenir du routeur lui-même).
La structure du filtrage de paquets est indiquée sur le schéma 3.1. Les paquets qui entrent par l'interface réseau, parcourent la chaîne PREROUTING (en anglais "chain"). le routeur qui reçoit les paquets sont manipulés, ils sont ensuites renvoyés vers un autre ordinateur en utilisant l'adresse et le port de destination. Si les paquets sont adressés au routeur, ils parcourent la chaîne INPUT, sinon ils parcourent la chaîne FORWARD. Les deux chaînes examinent si les paquets sont autosisés à passer. S'il sont acceptés, les paquets sont envoyés sur le processus cible locale ou vers la chaîne POSTROUTING (ici le masquage de paquets a lieu) ensuite les paquets passent par l'interface réseau et peuvent atteindre leur destination. Les paquets générés localement sont filtrés dans la chaîne OUTPUT et enfin (en cas de succès) les paquets sont envoyés dans la chaîne POSTROUTING et sont également transmis en passant par l'interface réseau.
La configuration les chaînes de filtrage de paquets, peut être paramétré séparément. En plus il y a une liste pertinente pour chaque chaîne importante, c.-à-d. pour la chaîne INPUT vous avez (PF_INPUT_%), pour la chaîne FORWARD vous avez (PF_FORWARD_%), pour la chaîne PREROUTING vous avez (PF_PREROUTING_%) dans laquelle vous effectuez la redirection de ports et pour la chaîne POSTROUTING vous avez (PF_POSTROUTING_%) dans laquelle vous exécutez le masquage de paquets.
Le paramètrage de la liste se compose principalement d'une action (voir ci-dessous), qui peut être limitée par des conditions supplémentaires. Ces conditions portent sur les propriétés du paquet. Un paquet contient des informations sur son origine (la source quel ordinateur a envoyé le paquet), sa cible (à quel ordinateur et quelle application le paquet doit aller), etc. les conditions du paquet peuvent être basées sur les propriétés suivantes :
Si un paquet entre, les enregistrements ou les règles générées sont récupérées de haut en bas, la première action est exécutée et toutes les conditions. Si aucune des règles ne s'applique, l'action par défaut est exécutée, vous pouvez spécifier des règles pour (presque) toutes les tables.
Un enregistrement a la forme suivant, vous devez faire attention que toutes les restrictions sont optionnelles :
![\includegraphics[width=\columnwidth]{netfilter}](img2.png)
restriction{0,} [[source] [destination]] action [BIDIRECTIONAL|LOG|NOLOG]
Sur les points qui conserne le réseau vous devez spécifier une adresse IP ou un hôte. vous pouvez aussi utiliser les variables IP_NET_%, IP_NET_%_IPADDR ou un @non_d'hôte via les variables HOST_%. Si la variable OPT_DNS est activées, vous pouvez référencer un nom externe au réseau local via @fqdn, mais vous ne devez pas récupérer le nom dans la variable HOST_%. Cela est particulièrement utile, quand il s'agit d'hôtes externes, et qu'ils possèdent en plus des adresses IP dynamique (ou changeante).
Les actions peuvent être les suivants :
On peut modifier le comportement de certaines de ces actions avec les options suivant BIDIRECTIONAL, LOG ou NOLOG. L'option BIDIRECTIONAL génère à nouveau la même règle, mais avec une adresse source et destination inversée (un changement de port source et destination et/ou un changement de l'interface réseau sortant si elle est spécifiée). Les options LOG/NOLOG active ou n'active pas le fichier journal pour cette règle.
les restrictions peuvent être réalisés, elle sont indiquées dans ce chapitre ci-dessous. Si vous ne voulez pas faire de restriction vous pouvez toujours spécifier any, mais vous devez toujours indiquer quelque chose. Les restrictions peuvent être spécifiées dans n'importe quel ordre, si le préfixe est préposé. Cela s'applique à toutes les restrictions, sauf pour spécifier une adresse source ou destination. Ceux-ci doivent toujours être directement devant l'action, les autres restrictions doivent être faites avant. Les restrictions peuvent également être annulés, en préposant tout simplement le symbole !
Chaque paquet contient une source et une cible, respectivement sous la forme multiplet d'adresse IP et de port. 3.2 Cette source ou cette cible peut être utilisé pour une restriction. La spécification de la source ou de la destination peut être faite comme ceci :
| Expression | Importance |
ip |
Une seule adresse IP |
network |
Spécification du réseau sous la forme <ip>/<netmask> |
port[-port] |
Port ou une plage de ports |
IP_NET_x_IPADDR |
Adresse IP de l'interface x du routeur |
IP_NET_x |
Sous-réseau x du routeur |
IP_ROUTE_x |
Spécifier la route x du sous-réseau
(Les routes par défaut ne peuvent pas être utilisés, elles seraient toutes
any, et sont exclus par précaution) |
@name |
Nom ou alias attribué, dans la variable HOST_%_* l'adresse IP est utilisé au nom associée |
<ip ou réseau>:port[-port] |
Hôte ou l'adresse du réseau de l'une des variantes ci-dessus, combiné à un port ou une plage de ports |
Cela pourrait par exemple, ressembler à ceci : '192.168.6.2 any DROP'
Si on regarde ces paramètres, le premier est la source, le second est considéré comme la cible. Dans cet exemple, nous rejetons les paquets qui ont été envoyées par l'ordinateur avec l'adresse IP 192.168.6.2 et peu importe sur quelle destination ils sont adressés.
Si un seul paramètre est indiqué, on peut décider en fonction de la valeur, si c'est la source ou si c'est la destination qui est concernée, la décision est relativement simple :
Si nous voulons écrire plus brièvement l'exemple ci-dessus :
'192.168.6.2 DROP'. Aucun port n'est indiqué, donc l'IP de l'ordinateur
est la source (c'est lui qui envoie les paquets).
Si nous voulons communiquer avec le démon ssh, nous pouvons indiquer
'any any:22 ACCEPT' (les paquets seront acceptés depuis n'importe quel
ordinateur sur le Port 22 du ssh et n'importe quel ordinateur les
acceptera), vous pouvez indiquez aussi '22 ACCEPT' seul un port est indiqué,
nous pouvons dire que c'est la cible, les paquets seront dirigés sur le port 22.
Pour simplifier la quantité de règle à écrire, on peut utiliser l'action BIDIRECTIONAL elle indique que les communications se feront dans les deux sens. Les règles sont paramétrées simplement avec l'IP source, l'IP destination et le port ou avec les interfaces réseau, les échanges entre cet deux réseaux reste le même.
Exemple :
127.0.0.1 ACCEPT |
La communication locale (Souce 127.0.0.1) est accepté | ||
any 192.168.12.1 DROP |
Les paquets vers l'adresse-IP 192.168.12.1 sont rejetés | ||
any 192.168.12.1 DROP LOG |
Les paquets vers l'adresse-IP 192.168.12.1 sont rejetés et sont également enregistrés | ||
any 192.168.12.1 DROP NOLOG |
Les paquets vers l'adresse-IP 192.168.12.1 sont rejetés, ne sont pas enregistrés | ||
22 ACCEPT |
Les paquets vers le port 22 (ssh) sont acceptés | ||
IP_NET_1_NET ACCEPT |
Les paquets du sous-réseau de la première interface sont acceptés | ||
IP_NET_1_NET IP_NET_2_NET |
La communication entre la première et la seconde | ||
ACCEPT BIDIRECTIONAL |
L'interface du sous-réseau est acceptée |
Une règle peut restreindre une interface sur laquelle les paquets arrivent et sortent. Le format de restriction est le suivant : if:in:out
Dans la chaîne INPUT on ne peut pas restreindre l'interface pour les paquets sortant (les paquets ne sortiront plus). Dans la POSTROUTING on ne peut pas restreindre l'interface pour les paquets entrant, car l'information n'est plus disponible à ce moment là. Vous pouvez restreindre une interface uniquement dans la chaîne FORWARD pour les deux conditions (entrant et sortant).
Les valeurs suivantes sont possibles pour in ou out :
IP_NET_x_DEV
Une règle peut restreindre le protocole donc le paquet appartient. Le format est le suivant : prot:protocol ou bien prot:icmp:icmp-type. protocol peut prendre les valeurs suivantes :
Si vous voulez utiliser un numéro de port avec des protocoles différents dans une règle, une telle restriction ne sera pas disponible, vous devez créer la règle en deux fois, une fois pour le tcp et une fois pour le udp.
Vous pouvez utiliser mac:mac-address pour faire une restriction de l'adresse MAC.
pour le filtrage de paquets fli4l utilise les informations de l'état des connexions. Ces informations peuvent ensuite être utilisées pour filtrer les paquets, pour une description plus détaillée sur l'état des connexions : 3.3
| Etat | Importance |
| INVALID | Le paquet n'appartient à aucune connexion connue. |
| ESTABLISHED | Le paquet appartient à une connexion, le paquet a déjà circulé dans l'autre sens (réponse). |
| NEW | Le paquet fait partie d'une nouvelle connexion ou appartient à une connexion, mais le paquet n'a pas encore circulé dans l'autre sens. |
| RELATED | Le paquet fait partie d'une nouvelle connexion, mais il est déjà en relation avec une connexion existante (par ex. établissement d'une connexion avec le ftp pour le transfère de données). |
L'état du paquet est défini comme ceci : state:état(s). Si vous souhaitez spécifier plusieurs conditions, vous devez les sépare par une virgule. Par exemple si vous voulez laisser passer seulement les paquets qui appartiennent directement ou indirectement à une connexion vous paramétrez state:ESTABLISHED,RELATED, il est utile d'écrire (ces états dans la chaîne INPUT ou FORWARD).
Dans certaine circonstance, on aimerait limiter la fréquence des actions, par ex. faire seulement une demande d'écho ICMP par seconde. Cela peut être spécifié avec la commande limitation limit, le format sera le suivant : limit:fréquence:Burst. La fréquence est en n/unité de temps qui sera donnée en (second, minute, hour, day), de plus vous pouvez indiquer une suite d'événements successifs (Burst). Par exemple en spécifiant limit:3/minute:5 un maximum de trois événements par minute sera permis et cinq événements successifs seront acceptés.
Il est possible pour l'utilisateur de simplifier la configuration des données de filtrage de paquets, en l'utilisant un modèle (Template) c'est un condensé de règles prés enregistré qui est fréquemment utilisées. Il est ainsi possible de combiner un certain nombre de règles de filtrage de paquets, dans cette collection de règles un nom symbolique y est associé. Au lieu d'écrire directement dans la variable le protocole et le numéros de port il suffit d'écrire le nom symbolique, si vous voulez utiliser le protocole ssh dans une règle il suffit d'écrire tmpl:ssh. Comment faut-il procéder avec le modèle ssh, vous avez un exemple d'utilisation ci-dessous.
Si vous voulez atteindre votre routeur fli4l par Internet avec le ssh, vous devez écrire dans la variable PF_INPUT_% le nom du service correspondant (ici ssh), précédée par tmpl: et l'action qui consiste à appliquer ce service. Par exemple :
PF_INPUT_2='tmpl:ssh ACCEPT'
Voici comment utiliser tmpl: pour appliquer une règle dans un modèle. Vous donnez le nom du service après les ':', dans notre exemple ssh. Enfin, vous pouvez spécifier quelle action doit être connecté au service. Puisque vous voulez communiquer avec fli4l à partir d'Internet, nous autorisons la connexion avec ACCEPT. La limitation des adresses IP ou des réseaux ne sont pas spécifiées, Avec le service ssh tous les réseaux et toutes les interfaces sont accessibles. Vous pouvez utiliser en cas de besoin la configuration habituelle du filtrage de paquets pour limiter l'accès au service ssh.
Pour quels services des règles sont ils préparées (c.-à-d. le modèle existent),
vous pouvez trouver dans le fichier opt/etc/fwrules.tmpl/templates le
modèle de service prés configuré. Voir ci-dessous la liste (dans le tableau
3.8).
| Modèle | Protocole | Port(s) |
| dhcp | udp | 67-68 |
| dns | tcp/udp | 53 |
| elster | tcp | 159.154.8.2:21 |
| elster | tcp | 159.154.8.35:21 |
| elster | tcp | 193.109.238.26:8000 |
| elster | tcp | 193.109.238.27:8000 |
| elster | tcp | 193.109.238.58:80 |
| elster | tcp | 193.109.238.59:80 |
| elster | tcp | 62.157.211.58:8000 |
| elster | tcp | 62.157.211.59:8000 |
| elster | tcp | 62.157.211.60:8000 |
| elster | tcp | 80.146.179.2:80 |
| elster | tcp | 80.146.179.3:80 |
| ftp | tcp | 21 |
| http | tcp | 80 |
| https | tcp | 443 |
| hylafax | tcp | 4559 |
| imap | tcp | 143 |
| imaps | tcp | 993 |
| imond | tcp | 5000 |
| ipmi | tcp | 22 |
| ipmi | tcp | 2937 |
| ipmi | tcp | 443 |
| ipmi | tcp | 5120 |
| ipmi | tcp | 5123 |
| ipmi | tcp | 5900 |
| ipmi | tcp | 5901 |
| ipmi | tcp | 80 |
| ipmi | tcp | 8889 |
| ipmi | udp | 623 |
| irc | tcp | 6667 |
| ldap | tcp/udp | 389 |
| tcp | 110 | |
| tcp | 143 | |
| tcp | 25 | |
| tcp | 465 | |
| tcp | 587 | |
| tcp | 993 | |
| tcp | 995 | |
| mysql | tcp | 3306 |
| nfs | tcp/udp | 111 |
| nfs | tcp/udp | 2049 |
| nntp | tcp | 119 |
| ntp | udp | 123 |
| oracle | tcp | 1521 |
| pcanywhere | tcp | 5631-5632 |
| ping | icmp:0 | |
| ping | icmp:8 | |
| pop3 | tcp | 110 |
| pop3s | tcp | 995 |
| privoxy | tcp | 8118 |
| proxmox | tcp | 8006 |
| proxmox | tcp | 5900 |
| proxmox | tcp | 3128 |
| rdp | tcp | 3389 |
| rsync | tcp | 873 |
| samba | tcp | 139 |
| samba | tcp | 445 |
| samba | udp | 137-138 |
| sip | tcp/udp | 5060-5061 |
| smtp | tcp | 25 |
| snmp | tcp/udp | 161 |
| socks | tcp | 1080 |
| squid | tcp | 3128 |
| ssh | tcp | 22 |
| ssmtp | tcp | 465 |
| submission | tcp | 587 |
| svn | tcp | 3690 |
| syslog | udp | 514 |
| teamspeak | tcp | 14534 |
| teamspeak | tcp | 51234 |
| teamspeak | udp | 8767 |
| telmond | tcp | 5001 |
| telnet | tcp | 23 |
| teredo | udp | 3544 |
| tftp | udp | 69 |
| time | tcp/udp | 37 |
| traceroute | udp | 33404-33464 |
| vdr | tcp | 6419 |
| vnc | tcp | 5900 |
| whois | tcp | 43 |
| xbl | tcp/udp | 3074 |
| xbl | udp | 88 |
| xmppclient | tcp | 5222 |
| xmppserver | tcp | 5269 |
La syntaxe pour cette forme de règles de filtrage de paquets est toujours
tmpl:<Nom du service> <Restriction> <Action souhaitée>
Les <restrictions> permisent sont décrites dans dans la section
3.10.2. Les valeurs possibles pour les <actions souhaitées>
sont énumérées et décrites dans la section 3.10.1
Voici quelques exemples pour illustrer la démarche. Nous allons d'abord utiliser PF_PREROUTING :
PF_PREROUTING_N='2'
PF_PREROUTING_1='tmpl:xbl dynamic DNAT:@xbox'
PF_PREROUTING_2='tmpl:https dynamic DNAT:192.168.193.250'
La règle PF_PREROUTING_1 fournit à Xbox tout le nécessaire pour Xbox Live. Plus précisément, avec tmpl:xbl vous avez tous les ports et les protocoles nécessaires afin qu'il y ait une transmission entre Xbox Live et les Hôtes xbox. Au lieu de saisir l'adresse IP vous pour enregistrer un nom depuis les paramètres HOST_%_NAME. Si vous indiquez dynamic fli4l sait que les ports seront transmis par l'interface connectée à Internet.
La deuxième règle dirige les paquets correspondants au protocole https sur un serveur Web par l'intermédiaire de la DMZ.
Maintenant, nous allons utiliser PF_INPUT.
PF_INPUT_N='3'
PF_INPUT_1='if:IP_NET_1_DEV:any ACCEPT'
PF_INPUT_2='if:pppoe:any prot:tcp 113 ACCEPT'
PF_INPUT_3='if:br0:any tmpl:dns @xbox IP_NET_1_IPADDR ACCEPT'
La première règle permet à tous les réseaux défini dans IP_NET_1 d'accéder au routeur. La deuxième règle permet à tous les paquets oident d'accéder. sur le port ident est ouvert. la troisième règle et dernière permet à Xbox d'accéder au serveur DNS sur fli4l. Vous avez également comment utiliser un alias d'hôte dans une règle.
Avec PF_FORWARD et PF_POSTROUTING il n'y a rien de plus que le tmpl spécifique.
Il est possible de créer vos propre fichier de modèle ou d'utiliser le fichier
existant pour ajouter vos règles. Pour créer votre propre modèle vous devez
simplement créer un fichier avec un nom de modèle que vous voulez et enregistrer
les règles correspondants selon vos besoins. Si vous avez décidé de créer un
fichier modèle, vous devez copier le fichier dans le sous-répertoire
etc/fwrules.tmpl qui sera dans le répertoire config, comme
indiqué dans la figure 3.2. Si le sous-répertoire
etc/fwrules.tmpl dans le répertoire config n'existe pas,
vous devez créer ce sous-répertoire. les développeurs de paquetages ou les
utilisateurs qui souhaitent créer leurs règles pour plusieurs configurations,
peuvent stocker directement le fichier modèle dans le répertoire
opt/etc/fwrules.tmpl. Dans ce répertoire, sont enregistré que les
nouveaux fichiers modèles. Dans le répertoire config les fichiers
modèles pour les règles sont prioritères au répertoire utilisateur. Enfin, vous
pouvez copier le fichier modèle original fourni par fli4l qui est déjà
«configuré», puis coller le contenu dans votre propre fichier,vous
pouvez ensuite enregistrer dans le répertoire config.
Par exemple, si vous voulez ajouter le modèle vpn_freunde vous devez d'abord créer le fichier vpn_freunde. Ensuite vous devez enregistrer les services suivants, ssh, smtp, dns et samba. Le fichier vpn_freunde doit ressembler à ceci :
prot:tcp 22
prot:tcp 25
53
prot:udp 137-138
prot:tcp 139
prot:tcp 445
Maintenant à chaque fois que vous utilisez le modèle vpn_freunde
des règles que vous avez enregistrez seront génèrées pour tous les protocoles
et les ports spécifiés. Exemple avec une action PF\_FORWARD\_x='tmpl:vpn\_freunde ACCEPT',
les règles du FORWARD seront les suivantes :
prot:tcp 22 ACCEPT
prot:tcp 25 ACCEPT
53 ACCEPT
prot:udp 137-138 ACCEPT
prot:tcp 139 ACCEPT
prot:tcp 445 ACCEPT
Le filtrage de paquets est configurable essentiellement par cinq chaînes voir le tableau :
Dans la variable on régle le niveau de journalisation, valable pour l'ensemble les variables, voici les valeurs que l'on peut paramètrer : debug, info, notice, warning, err, crit, alert, emerg.
Configuration de la chaîne INPUT, c'est ici que les paquets entre dans le routeur, les hôtes peuvent interroger le routeur. S'il n'y a pas de règle définie, pour la chaîne INPUT l'action par défaut sera déterminée, que faut il faire du paquet lorsqu'il est refusé, la variable de protocole détermine si le paquet doit être écrit dans le journal du système.
Il y a deux restrictions, au sujet des paramètres à utilisés :
Si vous avez besoin de définir le comportement du routeur, vous devez indiquer 'no'. Vous devez alors paramétrer toutes les règles vous-mêmes. Un comportement par défaut pour une configuration équivalente devrait ressembler à ceci, (la description des chaînes définies par l'utilisateur est ici) :
PF_INPUT_ACCEPT_DEF='no'
#
# limit ICMP echo requests - use a separate chain
#
PF_USR_CHAIN_N='1'
PF_USR_CHAIN_1_NAME='usr-in-icmp'
PF_USR_CHAIN_1_RULE_N='2'
PF_USR_CHAIN_1_RULE_1='prot:icmp:echo-request length:0-150 limit:1/second:5 ACCEPT'
PF_USR_CHAIN_1_RULE_2='state:RELATED ACCEPT'
PF_INPUT_N='4'
PF_INPUT_1='prot:icmp usr-in-icmp'
PF_INPUT_2='state:ESTABLISHED,RELATED ACCEPT'
PF_INPUT_3='if:lo:any ACCEPT'
PF_INPUT_4='state:NEW 127.0.0.1 DROP BIDIRECTIONAL'
La première règle limite le contrôle des erreurs avec la chaîne "usr-in-icmp".
La deuxième règle accepte seulement les paquets qui appartiennent à une connexion
existante (c. à d. que les paquets sont dans un état ESTABLISHED
ou RELATED), la troisième règle permet la communication locale
avec (if:lo:any ACCEPT). La quatrième règle filtre les paquets qui
prétendent avoir une communication locale, mais qui n'ont pas été acceptées
par la règle précédente.
Si vous travaillez avec OpenVPN, vous devez ajouter des règles, l'utilisation de ces paquets comportent les chaînes suivante :
PF_INPUT_N='5'
...
PF_INPUT_5='ovpn-chain'
Configuration de la chaîne FORWARD, c'est ici que le routeur redirige les paquets. S'il n'y a pas de règle définie, pour la chaîne FORWARD l'action par défaut sera déterminée, que faut il faire du paquet lorsqu'il est refusé, la variable de protocole détermine si le paquet doit être écrit dans le journal du système.
Les paramètres utilisés pour les actions de restriction sont, ACCEPT, DROP et REJECT
'state:ESTABLISHED,RELATED ACCEPT',
poursuite de la règle, rejette des paquets avec l'état inconnu :
'state:INVALID DROP'.
et enfin la règle ignore les paquets avec une adresse IP usurpée :
'state:NEW 127.0.0.1 DROP BIDIRECTIONAL'.
En outre, d'autres sous-systèmes générent les règles par défaut - Voici une configuration sans les règles par défaut, avec la redirection de port et l'OpenVPN la configuration devrait contenir au moins les règles suivantes :
PF_FORWARD_ACCEPT_DEF='no'
PF_FORWARD_N='5'
PF_FORWARD_1='state:ESTABLISHED,RELATED ACCEPT'
PF_FORWARD_2='state:INVALID DROP'
PF_FORWARD_3='state:NEW 127.0.0.1 DROP BIDIRECTIONAL'
PF_FORWARD_4='pfwaccess-chain'
PF_FORWARD_5='ovpn-chain'
Configuration de la La chaîne OUTPUT, c'est ici que le routeur gére ces paquets sortant. S'il n'y a pas de règle définie, pour la chaîne OUTPUT l'action par défaut sera déterminée, que faut il faire du paquet lorsqu'il est refusé, la variable de protocole détermine si le paquet doit être écrit dans le journal du système.
Les paramètres utilisés pour les actions de restriction sont :
Si vous avez besoin de définir le comportement du routeur, vous devez indiquer 'no'. Vous devez alors paramétrer toutes les règles vous-mêmes.Un comportement par défaut pour une configuration équivalente devrait ressembler à ceci :
PF_OUTPUT_ACCEPT_DEF='no'
PF_OUTPUT_N='1'
PF_OUTPUT_1='state:ESTABLISHED,RELATED ACCEPT'
La première règle (et la seule) accepte seulement les paquets qui appartiennent à une connexion existante (c'est à dire les paquets qui ont soit l'état ESTABLISHED ou RELATED)
Parfois pour différentes raisons, on a besoin d'élaborer nos propres chaînes pour régler plus précisément le filtrage de paquets. Ces chaînes peuvent être définies et paramétrées en utilisant la variable PF_USR_CHAIN_%. Les noms de chaîne doivent commencer obligatoirement par usr- suivi de se que vous voulez, ils peuvent être utilisées n'importe ou dans les chaînes INPUT ou FORWARD pour spécifier une action. Par exemple, voici utilisation de la chaîne de filtrage ICMP :
PF_USR_CHAIN_N='1'
#
# create usr-in-icmp
#
PF_USR_CHAIN_1_NAME='usr-in-icmp'
#
# add rule to usr-in-icmp
#
PF_USR_CHAIN_1_RULE_N='2'
PF_USR_CHAIN_1_RULE_1='prot:icmp:echo-request length:0-150 limit:1/second:5 ACCEPT'
PF_USR_CHAIN_1_RULE_2='state:RELATED ACCEPT'
#
# use chain in PF_INPUT
#
PF_INPUT_2='prot:icmp usr-in-icmp'
Les paquets peuvent être manipulés, avant et après les décisions de routage pour le moment. Par exemple, vous pouvez obtenir une nouvelle adresse de destination pour la transmission à un autre ordinateur (port forwarding) ou recevoir une adresse source différente pour masquer le réseau situé derrière le routeur. Le masquage est utilisé par exemple, pour faire un réseau privé avec une adresse IP publique ou de cacher une configuration DMZ du réseau local à partir d'un ordinateur de la DMZ.
La configuration se fait sur deux chaînes, la PREROUTING et la POSTROUTING. Au sujet de la chaînes POSTROUTING on configure, les paquets qui seront masqués par le routeur. Si aucune des règles de chaînes POSTROUTING ne s'applique, les paquets seront acheminés démasqué.
Pour le masquage, il existe deux versions : une pour l'interface réseau qui est assignée lors de la connexion une seule adresse IP (MASQUERADE) et une pour l'interface réseau qui utilise une adresse IP statique(SNAT). Si vous utilisez SNAT l'adresse IP doit être enregistrée dans le paquet source. Les données peuvent être comme ceci.
Vous pouvez indiquer un port ou une plage de ports dans SNAT et aussi dans MASQUERADE pour mapper les ports (ou établir une correspondance entre les ports). Normalement ce n'est pas nécessaire car seul le Kernel peut sélectionner les ports pour établir une correspondance. Cependant il y a des applications qui nécessitent que le port source reste inchangé (et imposent un NAT 1:1 ou elles interdisent le PAT (Port Address Translation) ou NAPT (Network Address and Port Translation)). La plage de ports est simplement ajouté après l'adresse IP, par exemple : SNAT:IP_NET_1_IPADDR:4000-8000.
La chaînes POSTROUTING peut utiliser les actions suivantes ACCEPT, SNAT, NETMAP et MASQUERADE.
Dans la chaîne PREROUTING on configure les paquets qui doivent être transmis à un autre ordinateur. Si aucune règles de la chaîne PREROUTING ne s'applique, les paquets seront ensuite traités sans être changés. L'action DNAT attend une adresse IP qui doit être enregistré dans le paquet en tant que cible. Les données peuvent être comme ceci.
Vous pouvez indiquer un port ou une plage de ports, le port de destination sera mappée. Cela est nécessaire que si le port doit être changé. Le port est simplement ajouté après l'adresse IP, par exemple : DNAT:@server:21.
L'action REDIRECT se comporte comme l'action DNAT, sauf que l'adresse IP de destination est toujours une adresse IP (primaire) - c'est l'adresse de l'interface qui est configurée et sur laquelle le paquet arrive, le paquet sera ensuite livré localement. Cela est nécessaire par exemple pour un proxy transparent, voir OPT_TRANSPROXY.
Si vous voulez faire de la redirection de port sur des interfaces qui utilise une adresse IP dynamique, pendant le démarrage on ne connaît pas l'adresse IP du PC vers lesquel les paquets seront dirigés. on peut utiliser la chaîne PREROUTING avec le paramètre dynamic comme espace réservé pour assignée l'adresse IP plus tard. Par exemple :
'dynamic:80 DNAT:1.2.3.4' # rediriger les paquets http vers
# l'adresse IP 1.2.3.4
'prot:gre any dynamic DNAT:1.2.3.4' # rediriger les paquets gre (fait partie
# du protocole PPTP) vers l'adresse
# 1.2.3.4
La chaînes PREROUTING peut utiliser les actions suivantes ACCEPT, DNAT, NETMAP et REDIRECT.
Pour d'autres exemples sur la façon d faire de la redirection de port, voir la paragraphe suivant.
Voici quelques exemples de configuration du filtrage de paquets.
Ci-dessous la configuration par défaut de la chaîne INPUT, cela nous permet d'atteindre la distribution fli4l :
PF_INPUT_POLICY='REJECT'
PF_INPUT_ACCEPT_DEF='yes'
PF_INPUT_LOG='no'
PF_INPUT_N='1'
PF_INPUT_1='IP_NET_1 ACCEPT'
Ainsi, nous obtenons, une
PF_INPUT_1='IP_NET_1 ACCEPT'),
PF_INPUT_ACCEPT_DEF='yes'),
PF_INPUT_ACCEPT_DEF='yes'),
PF_INPUT_POLICY='REJECT'),
PF_INPUT_LOG='no').
Pour la chaîne FORWARD voici la configuration : seuls les paquets sur le réseau local et les paquets correspondant à une connexions établies par les ordinateurs du réseau local doivent être transmis. En outre, les paquets NetBIOS et CIFS seront rejetés.
PF_FORWARD_POLICY='REJECT'
PF_FORWARD_ACCEPT_DEF='yes'
PF_FORWARD_LOG='no'
PF_FORWARD_N='2'
PF_FORWARD_1='tmpl:samba DROP'
PF_FORWARD_2='IP_NET_1 ACCEPT'
Ce que l'on voit ici, est la dépendance de l'ordre des règles : en premier on rejette les paquets Netbios et ensuite les paquets du réseau local sont acceptés.
Maintenant, le réseau local communique avec le routeur, les paquets sont transmis, il ne manque que le masquage, il est nécessaire pour accéder au réseau privé sur Internet :
PF_POSTROUTING_N='1'
PF_POSTROUTING_1='IP_NET_1 MASQUERADE'
Si vous voulez mettre en place plusieurs sous-réseaux locaux qui puissent communiquer les uns avec les autres librement et sans être masqués, nous devons nous assurer que les paquets ne seront pas rejetés entre ces sous-réseaux et qu'ils ne soient pas masqués. Pour cela il suffit de rajouter une règle ou modifier l'existante.
Supposons que nous ayons un accès DSL via PPPoE, avec deux sous-réseaux IP_NET_1 (192.168.6.0/24) et IP_NET_2 (192.168.7.0/24). La configuration ressemblerait alors à ce qui suit :
PF_FORWARD_POLICY='REJECT'
PF_FORWARD_ACCEPT_DEF='yes'
PF_FORWARD_LOG='no'
PF_FORWARD_N='4'
PF_FORWARD_1='IP_NET_1 IP_NET_2 ACCEPT BIDIRECTIONAL'
PF_FORWARD_2='tmpl:samba DROP'
PF_FORWARD_3='IP_NET_1 ACCEPT'
PF_FORWARD_4='IP_NET_2 ACCEPT'
PF_POSTROUTING_N='3'
PF_POSTROUTING_1='IP_NET_1 IP_NET_2 ACCEPT BIDIRECTIONAL'
PF_POSTROUTING_2='IP_NET_1 MASQUERADE'
PF_POSTROUTING_3='IP_NET_2 MASQUERADE'
Maintenant, les règles occupent les paquets qui sont acheminés entre les deux sous-réseaux sans examen plus approfondi. La troisième et quatrième règles font en sorte que les deux sous-réseaux sont disponible pour aller sur Internet. La première règle de la chaîne POSTROUTING assure que la communication entre les sous-réseaux se fait démasqué.
Alternativement, on peut dire que seuls les paquets qui dépassent par l'interface pppoe doivent être masqués :
PF_POSTROUTING_N='1'
PF_POSTROUTING_1='if:any:pppoe MASQUERADE'
De même, on pourrait limiter le filtrage des ports sur l'interface pppoe et les deux sous-réseaux peuvent être combinés en un seul, voici la configuration :
PF_FORWARD_POLICY='REJECT'
PF_FORWARD_ACCEPT_DEF='yes'
PF_FORWARD_LOG='no'
PF_FORWARD_N='2'
PF_FORWARD_1='if:any:pppoe tmpl:samba DROP'
PF_FORWARD_2='192.168.6.0/23 ACCEPT'
PF_POSTROUTING_N='1'
PF_POSTROUTING_1='if:any:pppoe MASQUERADE'
Les paquets qui passent par l'interface pppoe, qui sont adressée au udp Ports 137-138 ou au tcp Ports 139 et 445 seront rejeté (règle 1), tous les autres paquets qui viennent du sous-réseau 192.168.6.0/23, sont transmis (la règle 2).
Si vous voulez ajouter le réseau 10.0.0.0/24 dans le réseau existant (par ex. pour avoir un accès à distance sur ce réseau), de plus si vous voulez communiquer en étant démasqué et rejeter les paquets des udp Ports 137-138 et aussi destcp Ports 139 et 445, la configuration se présentera comme ceci :
PF_FORWARD_POLICY='REJECT'
PF_FORWARD_ACCEPT_DEF='yes'
PF_FORWARD_LOG='no'
PF_FORWARD_N='4'
PF_FORWARD_1='IP_NET_1 IP_NET_2 ACCEPT BIDIRECTIONAL'
PF_FORWARD_2='tmpl:samba DROP'
PF_FORWARD_3='192.168.6.0/23 ACCEPT'
PF_FORWARD_4='10.0.0.0/24 ACCEPT'
PF_POSTROUTING_N='2'
PF_POSTROUTING_1='10.0.0.0/24 ACCEPT BIDIRECTIONAL'
PF_POSTROUTING_2='192.168.6.0/23 MASQUERADE'
PF_FORWARD_ACCEPT_DEF='yes'
Une alternative à la configuration précédante :
PF_POSTROUTING_N='1'
PF_POSTROUTING_1='if:any:pppoe MASQUERADE'
Dans cette règle seul les paquets qui dépassent par l'interface pppoe doivent être masqués.
Listes noires (ou blacklists) (on refuse aux ordinateurs de cette liste "de faire quelque chose") et liste blanches (ou Whitelists) (on permet aux ordinateurs de cette liste "de faire quelque chose") la mis en place est en principe semblable. Les règles écritent au début de la liste sont très spécifiques et sont plus générique vers la fin de la liste. Dans une liste noir les règles au début de la liste seront interdit de faite quoi que se soit et en fin de liste ils pourront fait quelque chose. Avec une liste blanche, c'est tout le contraire.
Exemple 1 : tous les ordinateurs du sous-réseau 192.168.6.0/24 peuvent accéder à Internet sauf l'ordinateur 12, ils ne pourront pas communiquer avec le protocole CIFS par les ports 137-138 (udp), 139 et 445 (tcp)
PF_FORWARD_POLICY='REJECT'
PF_FORWARD_ACCEPT_DEF='yes'
PF_FORWARD_LOG='no'
PF_FORWARD_N='3'
PF_FORWARD_1='192.168.6.12 DROP'
PF_FORWARD_2='tmpl:samba DROP'
PF_FORWARD_3='192.168.6.0/23 ACCEPT'
PF_POSTROUTING_N='1'
PF_POSTROUTING_2='192.168.6.0/24 MASQUERADE'
Exemple 2 : l'ordinateur 12 peut accéder à Internet (mais on interdit toujours les Ports ...), tous les sous-réseaux locaux peuvent communiquer entre eux.
PF_FORWARD_POLICY='REJECT'
PF_FORWARD_ACCEPT_DEF='yes'
PF_FORWARD_LOG='no'
PF_FORWARD_N='3'
PF_FORWARD_1='192.168.6.0/24 192.168.7.0/24 ACCEPT BIDIRECTIONAL'
PF_FORWARD_2='tmpl:samba DROP'
PF_FORWARD_3='192.168.6.12 ACCEPT'
PF_POSTROUTING_N='1'
PF_POSTROUTING_1='if:any:pppoe MASQUERADE'
#
# Accès au routeur
#
PF_INPUT_POLICY='REJECT'
PF_INPUT_ACCEPT_DEF='yes'
PF_INPUT_LOG='no'
PF_INPUT_N='1'
PF_INPUT_1='IP_NET_1 ACCEPT' # Tous les hôtes du réseau local
# peuvent communiquer avec le routeur
#
# Accés à "Internet"
#
PF_FORWARD_POLICY='REJECT'
PF_FORWARD_ACCEPT_DEF='yes'
PF_FORWARD_LOG='no'
PF_FORWARD_N='2'
PF_FORWARD_1='tmpl:samba DROP' # Les paquets samba qui veulent
# sortir du réseau sont rejetés
PF_FORWARD_2='IP_NET_1 ACCEPT' # Tous les paquets du réseau local
# peuvent sortir
#
# Masquage du réseau local
#
PF_POSTROUTING_N='1'
PF_POSTROUTING_1='IP_NET_1 MASQUERADE' # Masque des paquets qui quittent
# le sous-réseau
#
# Accès au routeur
#
PF_INPUT_POLICY='REJECT'
PF_INPUT_ACCEPT_DEF='yes'
PF_INPUT_LOG='no'
PF_INPUT_N='2'
PF_INPUT_1='IP_NET_1 ACCEPT' # Tous les hôtes du réseau local
# peuvent communiquer avec le routeur
PF_INPUT_2='IP_NET_2 ACCEPT' # Tous les hôtes du réseau local
# peuvent communiquer avec le routeur
#
# Accés à "Internet"
#
PF_FORWARD_POLICY='REJECT'
PF_FORWARD_ACCEPT_DEF='yes'
PF_FORWARD_LOG='no'
#
# Libre communication entre les réseaux
#
PF_FORWARD_N='4'
PF_FORWARD_1='IP_NET_1 IP_NET_2 ACCEPT BIDIRECTIONAL'
PF_FORWARD_2='tmpl:samba DROP' # Les paquets samba qui veulent
# sortir du réseau sont rejetés
PF_FORWARD_3='IP_NET_1 ACCEPT' # Tous les paquets du réseau local
# peuvent sortir
PF_FORWARD_4='IP_NET_2 ACCEPT' # Tous les paquets du réseau local
# peuvent sortir
#
# Masquage des réseaux locaux, la communication entre les réseaux
# ne sont pas masquées
#
PF_POSTROUTING_N='3'
PF_POSTROUTING_1'IP_NET_1 IP_NET_2 ACCEPT BIDIRECTIONAL'
PF_POSTROUTING_2='IP_NET_1 MASQUERADE' # les paquets quittent le sous-réseau
# masqués
PF_POSTROUTING_3='IP_NET_2 MASQUERADE' # les paquets quittent le sous-réseau
# masqués
#
# Accès au routeur
#
PF_INPUT_POLICY='REJECT'
PF_INPUT_ACCEPT_DEF='yes'
PF_INPUT_LOG='no'
PF_INPUT_N='4'
PF_INPUT_1='IP_NET_1 ACCEPT' # Tous les hôtes du réseau local
# peuvent communiquer avec le routeur
PF_INPUT_2='IP_NET_2 ACCEPT' # Tous les hôtes du réseau local
# peuvent communiquer avec le routeur
PF_INPUT_3='tmpl:ssh ACCEPT' # Permettre l'accès au service SSH
# depuis n'importe où
PF_INPUT_4='tmpl:http 1.2.3.4/24 ACCEPT' # Permettre aux ordinateurs
# du sous-réseau d'avoir un accès
# spécifique au service HTTP
#
# Accés à "Internet"
#
PF_FORWARD_POLICY='REJECT'
PF_FORWARD_ACCEPT_DEF='yes'
PF_FORWARD_LOG='no'
#
# Pas de communication entre les réseaux, les deux réseaux peuvent
# avoir accés à Internet, paquets Samba sont rejetés
#
PF_FORWARD_N='2'
PF_FORWARD_1='tmpl:samba if:any:pppoe DROP' # Les paquets samba qui sortent
# du réseau sont rejetés
PF_FORWARD_2='if:any:pppoe ACCEPT' # Tous les autres paquets peuvent
# quitter le réseau local
#
# Masquage des réseaux locaux, la communication entre les réseaux
# ne sont pas masquées
#
PF_POSTROUTING_N='1'
PF_POSTROUTING_1='if:any:pppoe MASQUERADE' # Les paquets sont masqués
#en quitter le sous-réseau
La redirection de port peut être personnalisé avec la chaîne PREROUTING,
vous devez paramétrer la règle de la façon suivante, dans (TARGET vous
indiquez l'adresse IP de destination d'origine (optionnel) et le port de
destination d'origine, dans NEW_TARGET vous indiquez la nouvelle adresse
de destination et le nouveau port de destination (optionnel), dans PROTOCOL
vous indiquez le protocole correspondant) :
TARGET='<port>'
NEW_TARGET='<ip>'
PROTOCOL='<proto>'
PF_PREROUTING_x='prot:<proto> dynamic:<port> DNAT:<ip>'
TARGET='<port1>-<port2>'
NEW_TARGET='<ip>'
PROTOCOL='<proto>'
PF_PREROUTING_x='prot:<proto> dynamic:<port1>-<port2> DNAT:<ip>'
TARGET='<ip>:<port-a>'
NEW_TARGET='<ip>:<port-b>'
PROTOCOL='<proto>'
PF_PREROUTING_x='prot:<proto> any <ip>:<port-a> DNAT:<ip>:<port-b>'
Si vous souhaitez autoriser un accès spécifique à Internet, uniquement via un proxy local sans que le client s'en aperçoive, vous pouvez utiliser les chaînes PREROUTING et POSTROUTING. Fondamentalement, trois étapes sont nécessaires :
PF_FORWARD_x='IP_NET_1 ACCEPT'
Exemple 1 : supposons que nous ayons un seul réseau IP_NET_1,
sur lequel on a installé Squid sur un ordinateur avec le nom proxy et
que vous voulez router le trafic http sur cette ordinateur. Squid
écoute sur le port 3128. Par souci de simplicité, nous allons nous référer au
nom d'hôte @proxy enregistré dans HOST_1_NAME='proxy' (voir
Domaine de configuration).
L'ensemble devrait ressembler à ceci :
...
PF_PREROUTING_x='@proxy ACCEPT'
# Les paquets du Proxy ne doivent pas être détournés
PF_PREROUTING_x='prot:tcp IP_NET_1 80 DNAT:@proxy:3128'
# Les paquets HTTP de IP_NET_1 allant sur n'importe quelle destination
# seront redirigés vers @proxy, Port 3128
PF_POSTROUTING_x='any @proxy:3128 SNAT:IP_NET_1_IPADDR'
# Tous les paquets du Proxy sur le Port du 3128 seront réécrient
# comme s'ils venaient de fli4l (IP_NET_1_IPADDR)
PF_FORWARD_x='prot:tcp @proxy 80 ACCEPT'
# La règle de la chaîne FORWARD laisse passés les paquets HTTP du proxy (si nécessaire)
...
Il peut y avoir plusieurs conflits potentiels avec d'autres réseaux ou de reditection de port (se n'est rien d'autre qu'une règle DNAT), il va falloir formuler encore plus rigoureusement les règles.
Exemple 2 : notre Proxy qui s'appel proxy se trouve dans le réseau IP_NET_1, il écoute sur le port 3128 et sera efficace uniquement pour les clients du réseau IP_NET_1. Le réseau IP_NET_1 est accessible via l'interface IP_NET_1_DEV. Les paquets provenant des autres réseaux ne seront pas pris en considération.
...
PF_PREROUTING_x='if:IP_NET_1_DEV:any !@proxy 80 DNAT:@proxy:3128'
# Les demandes vers le port HTTP, ne viennent pas du proxy, mais via
# l'interface interne (IP_NET_1_DEV) et rediriger vers le port proxy.
# A ce stade, le contrôle if:IP_NET_1_DEV:any est important pour vérifier
# si les paquets viennent bien de l'intérieur, autrement les paquets
# seraient également diriger vers l'extérieur (faille de sécurité~!)
PF_POSTROUTING_x='prot:tcp IP_NET_1 @proxy:3128 SNAT:IP_NET_1_IPADDR'
# Les paquets HTTP provenant de IP_NET_1 sont réécrits pour être envoyés
# sur le port 3128 du proxy, comme s'ils venaient de fli4l (IP_NET_1_IPADDR)
PF_FORWARD_x='prot:tcp @proxy 80 ACCEPT'
# La règle de la chaîne FORWARD laisse passer les paquet http du Proxy (si nécessaire)
...
Exemple 3 : pour vous rendre la vie plus facile et pour rendre les règles un peu plus courtes, vous pouvez également utiliser le modèle (voir Modèle pour le filtrage de paquets). A ce stade tmpl:http est utilisé, il se traduit par prot:tcp any any:80. Par exemple à partir de tmpl:http IP_NET_1 DNAT:@proxy:3128 ou alors prot:tcp IP_NET_1 80 DNAT:@proxy:3128.
Les deux réseaux IP_NET_1 et IP_NET_2 doivent être transparent sur le Proxy. Cela pourrait vous aider à simplifier l'écriture
...
PF_PREROUTING_x='tmpl:http @proxy ACCEPT'
# Les paquets http ne doivent pas être détournés
PF_PREROUTING_x='tmpl:http IP_NET_1 DNAT:@proxy:3128'
# Les paquets HTTP provenant de IP_NET_1 sont détournés
PF_PREROUTING_x='tmpl:http IP_NET_2 DNAT:@proxy:3128'
# Les paquets HTTP provenant de IP_NET_2 sont détournés
PF_POSTROUTING_x='IP_NET_1 @proxy:3128 SNAT:IP_NET_1_IPADDR'
PF_POSTROUTING_x='IP_NET_2 @proxy:3128 SNAT:IP_NET_2_IPADDR'
PF_FORWARD_x='tmpl:http @proxy ACCEPT'
...
Cela peut se poursuivre indéfiniment ...
fli4l permet également la construction d'une simple DMZ. Tout d'abord, vous pouvez voir sur le site wiki https://ssl.nettworks.org/wiki un exemple de configuration.
Bien que l'utilisation du masquage d'IP a l'avantage que plusieurs ordinateurs du réseau local peuvent être acheminés via une adresse IP publique, mais il y a aussi des inconvénients que vous devez prendre en compte.
Le gros problème est, par exemple, qu'aucun ordinateur de l'extérieur ne peut se connecter à un ordinateur du réseau local. C'est souhaitable pour des raisons de sécurité, mais certains protocoles ne fonctionnent pas car ils requièrent une connexion depuis l'extérieur.
Un exemple classique le FTP. En plus du canal de communication, les commandes et les réponses sont échangés sur un autre canal (sous la forme d'un port-IP) pour envoyer les données. fli4l utilise pour cela Conntrack Helper qui permet de transmettre les ports supplémentaires, ils sont utilisés pour déverrouiller le ad hoc et aussi pour les ordinateurs internes quand c'est nécessaire. Conntrack Helper "écoute" le flux de données afin de détecter si un port supplémentaire est nécessaire.
Les applications typiques pour Conntrack Helper sont le protocole pour le Chat et pour les jeux sur Internet.
Vous activez Conntrack Helper avec des règles et un ensemble de variables spécifiques. Dans la liste de règles PF_PREROUTING_CT_% les affectations contiendra les Helpers pour les paquets venant de l'extérieur, dans la liste de règles PF_OUTPUT_CT_% les affectations contiendront les Helpers pour les paquets générés par le routeur. Quelques exemples pratiques viendront illustrer cela.
Exemple 1 : si vous voulez autoriser le mode FTP actif sur le réseau local, le routeur sera visible à partir de cette connexion par les routeurs extérieur, pour cela vous devez créer une règle dans la chaîne PF_PREROUTING_CT_% comme ceci :
PF_PREROUTING_CT_N='1'
PF_PREROUTING_CT_1='tmpl:ftp IP_NET_1 HELPER:ftp'
pour toutes les connexions TCP depuis le réseau local (IP_NET_1) vers toute autre adresse sur le port 21 (c'est le Port du ftp) le module auxiliaire ftp est chargé. Ce module permet alors de se connecter, le serveur FTP peut établir une connexion vers client pour le transfert de données, un "trou" est temporairement ouvert dans le pare-feu.
Exemple 2 : avec le mode FTP passif, il vous permet d'activer un serveur FTP sur le réseau local (ainsi une connexion de données sera établie vers l'extérieur, là aussi un trou dans le pare-feu sera ouvert), ici le routeur sera également visible à partir de cette connexion par les routeurs extérieur. La règle est représentée de la manière suivante :
PF_PREROUTING_CT_N='1'
PF_PREROUTING_CT_1='tmpl:ftp any dynamic HELPER:ftp'
Cette règle se traduit de la manière suivante, toutes les connexions FTP seront envoyés à l'adresse dynamique du routeur, associé à Conntrack Helper du FTP. Ici dynamic a été utilisé car il est supposé que le routeur est responsable de la connexion Internet et a donc une adresse IP externe. Si le routeur effectue une connexion via DSL, la règle peut aussi s'écrire :
PF_PREROUTING_CT_N='1'
PF_PREROUTING_CT_1='tmpl:ftp if:pppoe:any HELPER:ftp'
Cette règle se traduit de la manière suivante, toutes les connexions FTP sur l'interfase DSL (pppoe), seront associées à Conntrack Helper du FTP.
Si le routeur ne se connecte pas, il est par exemple derrière un autre routeur (box FRITZ!, modem câble, etc), la règle suivante peut être utilisée :
PF_PREROUTING_CT_N='1'
PF_PREROUTING_CT_1='tmpl:ftp if:IP_NET_2_DEV:any HELPER:ftp'
On suppose que dans l'exemple la connexion s'effectue via une interface vers l'autre routeur, cette interface est associée au deuxième sous-réseau (IP_NET_2_DEV).
On notera bien sûr, en plus de la configuration il sera nécessaire de paramétrer la chaîne FORWARD, pour réellement faire parvenir les paquets FTP. Voici une règle typique :
PF_PREROUTING_1='tmpl:ftp any dynamic DNAT:@ftpserver'
On suppose que l'hôte sur lequel le programme du serveur FTP fonctionne, a le nom ftpserver.
Exemple 3 : enfin, le must, si vous souhaitez utiliser le mode FTP actif directement à partir de fli4l (avec l'aide du programme ftp qui est dans le paquetage tools). Le pare-feu doit être préparé pour cela, cette fois on utilisera la chaîne OUTPUT et la liste de règles PF_OUTPUT_CT_% ou l'on va configurer les règles :
PF_OUTPUT_CT_N='1'
PF_OUTPUT_CT_1='tmpl:ftp HELPER:ftp'
Cette règle n'est toutefois pas nécessaire si la variable
FTP_PF_ENABLE_ACTIVE='yes' est activée - S'il vous plaît reportez-vous
à la documentation du OPT_protocolFTP dans le paquetage tools
Voici un apperçu de l'actuel Conntrack Helpers :
| Helpers | Explication |
| ftp | File Transfer Protocol |
| h323 | H.323 (Voice over IP) |
| irc | Internet Relay Chat |
| pptp | PPTP Masquerading (Ce module peut être plus qu'un client PPTP il fonctionne simultanément derrière un routeur fli4l.) |
| sip | Session Initiation Protocol |
| sane | SANE Network Procotol |
| snmp | Simple Network Management Protocol |
| tftp | Trivial File Transfer Protocol |
Voici un aperçu des variables à configurer :