Protocole réseau passant difficilement les pare-feu

En informatique, certains protocoles, de par leur conception, ne passent pas ou difficilement les pare-feu. Ils peuvent poser des problèmes au niveau du filtrage ou au niveau de la traduction d'adresse réseau (NAT).

Pour contourner ce problème, la plupart des pare-feu doivent implémenter des mécanismes très complexes.

Ce problème est important au point qu'il existe plusieurs RFC dont la RFC 3235 qui décrivent comment concevoir un protocole compatible avec les pare-feu.

Problème 1 : échange de donnée IP dans le protocole

Certains protocoles échangent au niveau applicatif (couche 7 du modèle OSI : FTP…) des adresses IP qui ne devraient circuler qu'au niveau réseau (couche 3 : IP) ou des ports qui ne devraient circuler qu'au niveau transport (couche 4 : TCP/UDP). Ces échanges transgressent le principe de la séparation des couches réseaux (transgressant par la même occasion la RFC 3235).

Les exemples les plus connus sont le FTP en mode actif (le client exécute la commande PORT : il fournit son IP locale et le port auxquels le serveur devra se connecter pour échanger les données) et le FTP en mode passif (le client exécute la commande PASV : le serveur y répond en fournissant son IP locale et le port auxquels le client devra se connecter pour échanger les données).

Les données échangées au niveau applicatif ne sont pas traduites. Ces données échangées n'étant pas valides après avoir traversé le routeur NAT, elles ne peuvent être utilisées par la machine destinataire.

Pour cette raison, ces protocoles passent difficilement voire pas du tout, les règles de NAT.

Problème 2 : utilisation de ports TCP et UDP variables

TFTP est imprévisible au niveau des ports

Certains protocoles utilisent de larges plages de ports. En effet ils décident des ports dynamiquement, échangent les nouveaux ports au niveau applicatif (cf. précédente section) puis ouvrent de nouvelles connexions vers ces ports.

Ainsi, lorsqu'un administrateur définit la politique de filtrage de son pare-feu, il a beaucoup de difficultés à spécifier les ports en cause. Dans le pire des cas il est obligé d'ouvrir un nombre important de ports, permettant, par la même occasion, d'autres protocoles que ceux voulus.

Par exemple le protocole TFTP échange des numéros de ports ouverts sur la machine cliente. Le serveur TFTP s'en sert pour ouvrir des datagrammes vers le client. Ces datagrammes ont un port source et un port destination indéterminé. Donc, pour laisser passer TFTP, il faut laisser passer presque tout UDP entre les deux machines.

Problème 3 : protocole ouvrant des connexions du serveur vers le client

FTP en mode actif ouvre des connexions serveur → client

Dans la définition d'un protocole, celui qui initie la communication est le client, celui qui est en attente est le serveur. La plupart des protocoles sont constitués de une ou plusieurs connexions (socket ou datagramme) du client au serveur, la première étant appelée maître. Mais certains protocoles contiennent des connexions secondaires initiées du serveur vers le client (exemple de FTP en mode actif).

Solution

La seule solution pour filtrer et « natter » correctement un protocole « à contenu sale » est de faire de l'inspection applicative. La plupart des types de pare-feu sait inspecter un nombre limité d'applications. Chaque application est gérée par un module différent que l'on peut activer ou désactiver pour gagner en performance ou en cas de bug publié. La terminologie pour le concept de module d'inspection est différente pour chaque type de pare-feu :

• Conntrack (comme connection tracking) sur Linux Netfilter
• CBAC (Control Based Access Control) sur Cisco IOS
• Fixup puis inspect sur Cisco PIX
• ApplicationLayerGateway sur Proventia M,
• Deep packet inspection sur Qosmos
• Predefined services sur Juniper ScreenOS
• Deep packet inspection sur Check Point FireWall-1
• ASQ sur netasq
• FAST sur Arkoon

Pour des raisons de sécurité, les pare-feu logiciels BSD (Ipfirewall, IPFilter et Packet Filter) ne font pas d'inspection de service dans le noyau. En effet l'inspection de service étant complexe, tout bug pourrait permettre la prise de contrôle de la machine. Pour faire de l'inspection de service, il faut dans ce cas installer un proxy qui, lui, tourne en espace utilisateur.

Les modules d'inspection applicative ont deux actions qui corrigent les deux problèmes :

• Ils traduisent les adresses IP et les ports échangés au niveau applicatif. Cela permet de natter les protocoles en cause.
• Ils autorisent dynamiquement les sockets ou datagrammes secondaires du protocole.

Il suffit par exemple d'autoriser TCP vers le port 21 pour autoriser FTP, la socket vers le port 20 étant automatiquement autorisée. Cela permet de filtrer les protocoles en cause sans autoriser de gros intervalles de ports.

Quelques exemples

Voici quelques protocoles réseau qui sont difficilement filtrables par un pare-feu :

• Domain Name System
• File Transfer Protocol en mode actif (le mode passif passe mieux les pare-feux)(connexions du serveur vers le client)
• File Transfer Protocol over SSL
• H.323
• Internet Control Message Protocol
• Internet Relay Chat-DCC qui permet l'échange de fichier pair à pair entre deux clients
• TFTP (grand intervalle de ports)

La vraie solution

La vraie solution est de concevoir le protocole en respectant toute une liste de règles. La RFC 3235 « Network Address Translator (NAT)-Friendly Application Design Guidelines » décrit comment élaborer un protocole passant la NAT sans difficulté.