Protocole réseau passant difficilement les pare-feu
Un article de Wikipédia, l'encyclopédie libre.
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-feux.
Sommaire |
[modifier] 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 échangent 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.
[modifier] Problème 2: protocole difficilement prévisible au niveau 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.
[modifier] Problème 3: protocole ouvrant des connexions du serveur vers le 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 appellé maître. Mais certains protocoles contiennent des connexions secondaires initiées du serveur vers le client.
[modifier] 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 Qosmos
- Predefined Services sur Juniper ScreenOS
- Deep Packet Inspection sur Check Point 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.
[modifier] Quelques exemples
- quelques vieux protocoles de transfert de fichier: FTP en mode passif, TFTP
- H323
- les protocoles faisant du peer2peer: IRC-DCC
- les protocoles de gestion de réseau: DNS, certains messages icmp, traceroute
Pour une liste plus exhaustive , voir la catégorie:Protocole réseau passant difficilement les pare-feux.
[modifier] 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 – Accédez aux articles de Wikipédia concernant la sécurité informatique. |
