Le module br_netfilter du noyau Linux permet d'étendre les capacités de filtrage du pare-feu Netfilter, notamment avec iptables, aux flux de trafic transitant par un pont réseau (bridge). Cette fonctionnaltié est essentielle pour implémenter ce qu'on appelle un pare-feu transparent ou un pare-feu en mode pont. Un tel pare-feu s'intègre discrètement dans le chemin du trafic sans nécessiter de modification de l'adressage IP sur les hôtes connectés, offrant ainsi une grande flexibilité de déploiement, une excellente discrétion et une sécurité accrue.

Intégration de Ntefilter avec les Ponts Réseau

L'activation de br_netfilter permet aux outils de gestion du pare-feu tels que iptables, ip6tables et arptables d'inspecter et de filtrer les paquets IPv4, IPv6 et ARP qui sont acheminés via une interface de pont. Cette inspection s'applique même lorsque ces paquets sont encapsulés, par exemple, dans des en-têtes 802.1Q VLAN ou PPPoE. Cette capacité transforme un système Linux en un pare-feu transparent et étatique extrêmement puissant.

Grâce à cette intégration, toutes les fonctionnalités de Netfilter – filtrage basé sur des règles, journalisation des événements et traduction d'adresses réseau (NAT) – peuvent être appliquées aux trames réseau qui traversent le pont. Cela permet, par exemple, la mise en œuvre d'une machine de masquage réseau transparente, où les hôtes locaux perçoivent qu'ils sont directement connectés au réseau externe, alors que le pare-feu gère toutes les translations.

Configuration et Contrôle via Procfs

Le comportement de br_netfilter est configurable à travers le système de fichiers /proc/sys/net/bridge/. Plusieurs entrées permettent d'activer ou de désactiver la visibilité du trafic ponté pour les différents outils de filtrage :

• /proc/sys/net/bridge/bridge-nf-call-arptables : Contrôle si arptables peut voir les paquets ARP pontés.
• /proc/sys/net/bridge/bridge-nf-call-iptables : Contrôle si iptables peut voir les paquets IPv4 pontés.
• /proc/sys/net/bridge/bridge-nf-call-ip6tables : Contrôle si ip6tables peut voir les paquets IPv6 pontés.

De plus, la prise en charge des paquets encapsulés VLAN et PPPoE peut être activée ou désactivée via d'autres paramètres :

• /proc/sys/net/bridge/bridge-nf-filter-vlan-tagged : Active le filtrage des paquets tagués 802.1Q VLAN.
• /proc/sys/net/bridge/bridge-nf-filter-pppoe-tagged : Active le filtrage des paquets encapsulés PPPoE.

Ces fichiers sont manipulés simpelment en écrivant '1' pour activer la fonction ou '0' pour la désactiver (par exemple, echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables).

Lorsque ces options sont activées, le code br_netfilter intercepte les paquets à des points clés du chemin de traitement du pont et les soumet aux chaînes Netfilter appropriées du sous-système IP. Conceptuellement, le flux de paquets à travers un pare-feu transparent impliquant br_netfilter implique que les trames Ethernet sont d'abord gérées par le pont, puis, si elles contiennent des paquets IP/IPv6/ARP, elles sont "exposées" aux hooks Netfilter de la couche réseau avant d'être transmises par le pont.

Flux d'Exécution au Niveau du Noyau

L'initialisation de br_netfilter dans le noyau Linux implique l'enregistrement de plusieurs points d'accroche (hooks) Netfilter spécifiques au pont. Ces hooks sont définis dans une structure nf_hook_ops et permettent à br_netfilter d'intervenir à diverses étapes du traitement des paquets sur le pont. L'enregistrement se fait via la fonction nf_register_hooks :

ret = nf_register_hooks(br_nf_ops, ARRAY_SIZE(br_nf_ops));

Le tableau br_nf_ops contient une série de hooks. Parmi les plus importants, on trouve :

• br_nf_pre_routing : Pour le traitement des paquets avant toute décision de routage ou de pontage initial.
• br_nf_local_in : Pour les paquets destinés localement au système qui agit comme pont.
• br_nf_forward_ip : Spécifiquement conçu pour les paquets IP/IPv6 qui doivent être transférés via le pont.
• br_nf_forward_arp : Gère le transfert des paquets ARP.
• br_nf_post_routing : Pour le traitement final des paquets juste avant leur envoi.

La fonction br_nf_forward_ip est particulièrement illustratrice du mécanisme. Son rôle est de préparer un paquet IP ou IPv6 qui est en cours de pontage afin qu'il puisse être traité par les chaînes Netfilter de la couche IP. Elle extrait l'en-tête de la couche réseau (IP ou IPv6), ajuste certains drapeaux dans la structure sk_buff (comme pkt_type), et marque le paquet comme étant en cours de pontage (BRNF_BRIDGED) et associe les interfaces physiques d'entrée et de sortie. Finalement, elle redirige le paquet vers les hooks Netfilter IP via un appel NF_HOOK :

/* ... à l'intérieur de br_nf_forward_ip ... */
NF_HOOK(pf, NF_INET_FORWARD, skb, bridge_parent(in), parent,
        br_nf_forward_finish);
/* ... */

Cet appel NF_HOOK est crucial. Il indique que le paquet, qui était initialement traité au niveau du pont, est maintenant soumis à la chaîne NF_INET_FORWARD (ou NF_INET6_FORWARD pour IPv6) du sous-système Netfilter IP, permettant ainsi l'application des règles iptables ou ip6tables configurées pour le trafic de transit. Une fois le traitement par la couche IP terminé, le paquet est retourné à br_nf_forward_finish pour finaliser son transfert via le pont.