Protocole réseau passant difficilement les pare-feu

Infos
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.
Protocole réseau 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 (FTP…) des adresses IP qui ne devraient circuler qu'au niveau réseau (IP) ou des ports qui ne devraient circuler qu'au niveau transport (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 destinatrice. Pour cette raison, ces protocoles passent difficilement voire pas du tout, les règles de NAT.

Problème 2: protocole difficilement prévisible au niveau ports

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 plein de ports, permettant par la même occasion d'autre protocoles. 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 sur Linux Netfilter
- CBAC sur Cisco IOS
- Fixup puis inspect sur Cisco PIX
- ApplicationLayerGateway sur Proventia M,
- Deep Packet Inspection sur
- Predefined Services sur Juniper ScreenOS
- Deep Packet Inspection sur FireWall-1 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
- File Transfer Protocol over SSL
- H.320
- H.323
- Internet Control Message Protocol
- Internet Relay Chat
- Secure File Transfer Protocol
- 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é. Catégorie:Protocole réseau Catégorie:Sécurité du réseau informatique
Sujets connexes
Adresse IP   Berkeley Software Distribution   Berkeley sockets   Cisco Systems   Couche application   Couche de réseau   Couche de transport   Datagramme   Domain Name System   Espace utilisateur   File Transfer Protocol   File Transfer Protocol over SSL   H.320   H.323   IPFilter   Internet Control Message Protocol   Internet Relay Chat   Ipfirewall   Linux   Netfilter   Network address translation   Packet Filter   Pare-feu   Port (logiciel)   Secure File Transfer Protocol   Serveur mandataire   TFTP   Transmission Control Protocol   User Datagram Protocol  
#
Accident de Beaune   Amélie Mauresmo   Anisocytose   C3H6O   CA Paris   Carole Richert   Catherinettes   Chaleur massique   Championnat de Tunisie de football D2   Classement mondial des entreprises leader par secteur   Col du Bonhomme (Vosges)   De viris illustribus (Lhomond)   Dolcett   EGP  
^