Protocole reseau passant difficilement les pare-feu

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 ruses 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).

L'exemple le plus connu est FTP en mode actif qui échange entre le client et le serveur des adresses IP ou des ports TCP/UDP.

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, elle 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/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é maître. Mais certains protocoles contiennent des connexions secondaires initiées du serveur vers le client.

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

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)
• File Transfer Protocol over SSL
• H.323
• Internet Control Message Protocol
• Internet Relay Chat-DCC qui permet l'échange de fichier pair à pair entre 2 clients
• TFTP

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é.

• Portail de la sécurité informatique