firewalls applicatifs aux - wapiti.telecom-lille.fr · en 1997, l'ietf conçoit un système de...
TRANSCRIPT
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
Claire VIGODA
Romain LAHOCHE
Coordonnée par Ahmed MEDDAHI
25 septembre 2004
FI2005
FIREWALLS applicatifs aux
protocoles multimédias
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 1/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
SOMMAIRE
LES PROTOCOLES MULTIMEDIA ................................................................................................................................................................ 3 1. POURQUOI DES PROTOCOLES MULTIMEDIA ............................................................................................................................................. 3
1.1. Les exigences du transfert de la voix .............................................................................................................................................. 3 1.2. Les limites du réseau IP ................................................................................................................................................................. 3 1.3. Le besoin en QoS ............................................................................................................................................................................. 3
2. LES STRUCTURES DE NORMALISATION .................................................................................................................................................... 4 2.1. Historique des normes..................................................................................................................................................................... 5 2.2. La norme H323................................................................................................................................................................................ 5 2.3. La norme SIP ................................................................................................................................................................................... 5 2.4. Les normes MGCP et MEGACO................................................................................................................................................... 6
LES FIREWALLS APPLICATIFS..................................................................................................................................................................... 6 1. LIMITES DES FIREWALL ET NAT.............................................................................................................................................................. 6
1.1. Firewall............................................................................................................................................................................................ 6 1.2. Nat.................................................................................................................................................................................................... 7 1.3. Protocoles et ports utilisés par H323, SIP et MGCP ................................................................................................................... 10
2. 1ERE SOLUTION : LES RELAIS ................................................................................................................................................................... 11 2.1. Serveur d’application .................................................................................................................................................................... 12 2.2. 2.2.2. Serveur d’application avec agent : ..................................................................................................................................... 13 2.3. 2.2.3. Passerelle de la couche d’application (ALG) :................................................................................................................... 14 2.4. 2.2.4 Traversal Using Relay NAT (TURN) ................................................................................................................................... 15
3. 2EME SOLUTION : LA COMMUNICATION DIRECTE .................................................................................................................................... 16 3.1. Tunnel de données ......................................................................................................................................................................... 16 3.2. Universal Plug and Play (UPnP).................................................................................................................................................. 16 3.3. Midcom .......................................................................................................................................................................................... 17 3.4. Simple Traversal of UDP Through Network Address Translation devices (STUN) ........................................................ 17 3.5. Interactive Connectivity Establishment(ICE).......................................................................................................................... 18
4. CONCLUSION PROTOCOLAIRE ................................................................................................................................................................ 18 4.1. Avantages des solutions de communication directes .................................................................................................................... 18 4.2. Avantages de la solution Midcom ................................................................................................................................................. 19
L’ETAT DE L’ART ............................................................................................................................................................................................ 19
REFERENCES..................................................................................................................................................................................................... 19
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 2/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
Ce document est une base pour la compréhension des problèmes que rencontrent les protocoles multimédias face aux
réseaux IP d'aujourd’hui.
Ce document présente les difficultés que doivent affronter les flux multimédias : H.323, Media Gateway Control Protocol
(MGCP), Session Initiation Protocol (SIP), Real-Time Transport Protocol (RTP) and RTP Control Protocol (RTCP) pour
traverser les firewalls et les autres processus de sécurité des réseaux tels que les Network Adress Translation (NAT's).
Les Protocoles multimédia
1. Pourquoi des protocoles multimédia 1.1. Les exigences du transfert de la voix
Une conversation entre deux personnes respecte deux principes : intelligibilité et interactivité. L’interactivité, assurée par le fait
que deux interlocuteurs peuvent parler en même temps, est assuré par une conversation full duplex.
Au niveau téléphonique, cette interactivité implique des notions de délais. Les mesures effectuées montrent qu’un temps de
transit de la voix inférieur à 150 ms garantit un dialogue actif. Tant qu’on ne dépasse pas 400 ms le dialogue reste tout de
même assez réactif. Au-delà de cette limite l’interlocuteur aura l’impression de parler dans le vide.
Une communication téléphonique, en plus d’assurer le transport de la voix, doit prendre en compte l’établissement et la rupture
de la communication. Ces fonctions sont assurées en téléphonie traditionnelle par des « signaux de service » : « signalling
flows » que s’échangent les postes téléphoniques et les différents centraux traversés par la communication.
1.2. Les limites du réseau IP
Le réseau IP est un ensemble de réseaux interconnectés qui achemine les données par commutation de paquets en mode non
connecté. En d’autres termes aucun chemin n’est alloué pour transférer les paquets de données jusqu’à leur destinataire.
Bien qu’il s’agit d’un protocole simple, ce protocole ne met pas en œuvre de contrôle d’erreur. Le transfert de données sur
Internet suit la politique du « best effort ». En d’autres termes lorsque deux machines sont en relation, le contrôle des données
se fait uniquement par le récepteur. Si on admet que la donnée reçue est mauvaise alors il faut retransmettre cette information.
Enfin, le protocole IP est d’autant plus simple qu’il ne met pas en oeuvre de Qualité de Services (QoS). Bien que chaque paquet
possède un champ « type de services », ce champ est encore peu utilisé par les routeurs durant la transmission.
Le réseau IP est donc un réseau asynchrone, c’est-à-dire qui transmet un paquet émis vers son récepteur sans aucune
contrainte. Les termes : délai, variation de délai, priorité, temps réel lui sont inconnus.
1.3. Le besoin en QoS
Afin de bien percevoir les difficultés associées au transport de la voix sur IP, le schéma ci-dessous présente un comparatif entre
la commutation de circuits des télécoms qui utilise X25 et la commutation de paquets d’IP : Transmission sur réseau IP et sur
réseau X25
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 3/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
Figure 1 : Différence réseau IP et réseau X25
Les approches IP et télécoms sont pratiquement opposées. Où IP est simple et débrouillard, les télécoms sont complexes
et figés. Les deux principales causes des limites associées à la VoIP (Voice Over IP) restent :
• Le Délai : par l’absence de QoS, quantifier le délai sur le réseau de manière fiable est quasi impossible, car il y a trop
d'inconnues : table de routage, congestion, files d'attente… Cependant le temps de transmission d'un paquet doit
rester inférieur à 400 ms pour respecter les contraintes d'une conversation interactive.
• Les Pertes : par l’absence de contrôle d’erreur, la disparition de paquets au cours de la communication fait partie de
la transmission IP. Suivant le nombre de paquets perdus, la qualité sonore en bout de ligne peut s'en ressentir.
Toutes ces défauts liés à IP sont les fondements des difficultés rencontrées par le concept VoIP :
Figure 2 : Difficulté d’une transmission sous IP
Pour pallier au problème d’absence de QoS sur IP il faut à la fois bien dimensionner les caractéristiques de bande passante
mais aussi améliorer le transfert. Ceci est réalisable grâce à des protocoles qui permettent d'obtenir une QoS plus favorable. Les différents protocoles utilisés sont détaillés ci-dessous :
2. Les structures de normalisation Les services multimédias temps réel sur IP sont gérés par des protocoles de signalisation. On entend par signalisation
l'ensemble des informations échangées par les terminaux, les passerelles et tous les éléments assurant l'établissement, le
contrôle et la rupture d'une connexion temps réel. Ces informations sont élaborées sur la couche Application et doivent être
définies par des procédures communes entre les différents fournisseurs de produits.
Les organismes participant aux travaux de signalisation sont : l'ITU (Union Internationale des Télécommunications), l'IETF, les
consortiums industriels et les opérateurs de télécommunication.
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 4/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
2.1. Historique des normes En 1996, une trentaine de logiciels de téléphonie ou visioconférence sur IP existaient. Chacun ayant une signalisation
propriétaire, les applications n'étaient évidemment pas compatibles entre elles.
Milieu 1996, Microsoft lance le logiciel de visioconférence : Netmeeting. Cependant, Netscape le concurrent du moment impose
le logiciel CoolTalk comme fédérateur des logiciels de téléphonie sur IP : les deux technologies étant bien entendu
incompatibles. Pour riposter, Microsoft décide de s’orienter vers une standardisation des protocoles de signalisation et s'investit
donc dans les groupes travail de standardisation ITU et IETF. C’est ainsi que le standard de signalisation H.323 est créé.
En 1997, l'IETF conçoit un système de signalisation SIP (Session Initiation Protocol) adapté à la philosophie IP, contrairement à
H.323 qui s'inspire des circuits télécoms.
2.2. La norme H323
2.2.1. Le standard
La norme, recommandation de l’ITU, propose des bases pour le transport de la voix, de la vidéo et des données sur des
réseaux IP. H.323 est issue de la norme H.320 (visiophonie sur RNIS), et répond aux problèmes liés à IP (pas de garantie de
délais). H.323 fonctionne en mode non connecté et sans garantie de QoS selon une stratégie bout à bout qui lui confère une
transparence vis-à-vis des évolutions du réseau. H323 s’appuie sur des protocoles de communication (RTP, RTCP, …), mais
également sur des codecs audio (G.711,G723.1, G.728,…) et des codecs vidéo (H.261 et H.263).
2.2.2. Les fonctions offertes
Les composants majeurs qui interagissent avec un réseau IP sont les suivants : la gateway, le gatekeeper, les MCU (Multi
Control Unit) et les terminaux classiques et IP.
Les fonctions dédiées à H.323 sont les suivantes :
• Contrôle de la procédure d'appel : requête, établissement et suivi de l'appel.
• Gestion des flux multimédias : liste de codecs recommandés ou obligatoires.
• Gestion des conférences multipoint : modèle de conférence géré par une entité centrale.
• Gestion de la bande passante : le gatekeeper devient un centre de contrôle et a les moyens de limiter les
connexions et d'allouer la bande passante disponible.
• Interconnexion à d'autres réseaux : ATM, RNIS, RTC.
2.2.3. Les interactions avec les autres protocoles
La signalisation qu’elle nécessite se fait avec d’autres protocoles tel que : le protocole RAS qui gère l’admission et l’état des
communications, le protocole Q.931 qui gère les appels et le raccrochage déjà en place sur le réseau RNIS et, le protocole H.245 qui gère l’utilisation des canaux et de leur capacités.
2.3. La norme SIP
2.3.1. Le standard
SIP (Session Initiation Protocol) est un protocole d'ouverture de session destiné à être utilisé sur des PABX-IP, des intranets, …
pour devenir le standard des communications unifiées (voix, vidéo et e-mail) en temps réel dans le monde IP.
SIP est un protocole sorti directement de l’Internet contrairement à H.323 issu de la téléphonie et de l’UIT. Il a été spécifié par
l'IETF et a été conçu pour favoriser la tenue de téléconférences multimédias sur Internet. En d’autres termes, SIP est un
protocole de signalisation de niveau applicatif qui établit, modifie et termine des sessions multimédias interactives sur IP entre
des terminaux.
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 5/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
2.3.2. Des fonctionnalités offertes
Le protocole client-serveur de type textuel permet d’être utilisé par des localisateurs universels de ressources (URL) pour
l'adressage, comme l’est HTTP. Cette origine facilite son intégration aux réseaux IP d'entreprise et permet d’activer quelques
services tels que la réponse vocale interactive Web : une page Web s'affiche pour compléter le message vocal.
2.3.3. Des fonctionnalités manquées
Bien que lancé avec une offensive marketing forte et armé d’un socle de fonctionnalités porteuses de nouveaux services
réseaux, le protocole SIP n'a pas percé dans la téléphonie IP, face à H.323.
En d’autres termes, SIP ne prend pas encore en compte de nombreux services actuellement utilisés dans les réseaux
téléphoniques pour pouvoir remplacer le protocole H.323. Il ne gère encore la récupération des données de taxation du réseau
téléphonique public commuté, ou les touches DTMF utilisées par les services vocaux interactifs (touches * ou #).
2.3.4. Un espoir
Cependant, sous réserve de séduire les industriels, de bousculer H.323, et d'être enrichi de fonctionnalités encore manquantes,
SIP pourrait être à l'origine d'une profonde évolution des services téléphoniques, mettant à profit tout le potentiel des
technologies de l'Internet : On pense déjà à la combinaison de la voix avec des services IP, telle la téléconférence sur le web.
(Un tel outil qui associerait des outils de gestion Web, des participants et des partages d’applications).
2.4. Les normes MGCP et MEGACO
MGCP (Media Gateway Control Protocol), contrairement à H.323 qui couvre toutes les couches supérieures à IP, se contente
d'assurer un service fiable et rapide au niveau des couches 3 et 4.
Cependant, pour faire converger ce protocole avec un projet de norme équivalente commune à UIT-T et IETF, MEGACO a été
adopté et n’est qu’une évolution MGCP. Son protocole définit les échanges entre passerelle et MGC (Media Gateway
Controler) pour proposer des services indépendants de la passerelle utilisée et de son contrôleur.
Cette approche a permis la construction de terminaux simples et bons marché : on la retrouve aujourd’hui dans la Freebox, offre
proposée par le fournisseur d’accès Internet Free dans les zones dégroupées. Outre ses fonctions locales (modem, routeur, set
top box, …) elle inclut une simple passerelle entre le poste téléphonique et le réseau Internet localisant l’intelligence dans le
réseau.
Les Firewalls applicatifs
1. Limites des firewall et NAT 1.1. Firewall
1.1.1. Définition
Avec la croissance rapide de l’Internet, la sécurité des réseaux est un souci important. Quand on relie un réseau privé à
l'Internet, on relie physiquement ce réseau à une quantité d’autres réseaux inconnus. Bien que cela permet de partager
beaucoup d’informations, la plupart des réseaux privés contiennent des informations qui ne devraient pas être partagées avec
les utilisateurs extérieurs sur l'Internet.
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 6/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
Un pare-feu ou firewall est un point de défense entre deux réseaux. Il protège un réseau contre l'autre grâce à un principe de
filtrage des paquets entrants et sortants du réseau privé de l’entreprise sur lequel il a été installé. Il analyse chaque paquet
entrant ou sortant du réseau privé suivant la politique de sécurité qui a été définie sur le réseau. Cette politique est constituée
d’un ensemble de règles, appelées access list (ACL), qui autorise ou interdit le trafic en fonction d’un certain nombre de
paramètres : réseau source/destination, protocoles utilisés (IP, UDP, TCP, …) et ports source/ destination. Tout paquet entrant
ou sortant est soumis à chacune des règles dans l’ordre où elles apparaissent dans le fichier de configuration du firewall. Dès
que le paquet correspond à une règle, on la lui applique et ce paquet est ignoré des règles suivantes. Par contre, si ce paquet
ne correspond à aucune des règles définies dans le fichier de configuration, le paquet est détruit.
Exemple de règles :
!
access-list 101 deny ip any 195.51.150.0 0.0.0.255
access-list 101 permit ip any any
!
Ordre des règles :
1. On refuse l’accès des paquets ip allant de n’importe quel réseau vers le
réseau 195.51.150.0
2. On autorise tous les autres paquets IP allant de n’importe quel réseau
vers n’importe quel réseau
1.1.2. Limites
Un firewall respecte quelques principes :
Il reconnaît les réseaux internes et externes, il permet aux paquets de transiter de l’intérieur vers l’extérieur, il permet aux flux
externes de rentrer s’ils sont déjà raccordés avec l’intérieur, il interdit aux paquets externes de rentrer vers l’intérieur et enfin,
beaucoup d’entre eux ne travaillent qu’avec des trafics entrants basés sur des ports standards connus (=WELL-KOWN PORTS
compris entre 0-1024).
Les deux derniers points sont des obstacles importants pour le transit des flux multimédias entre les réseaux internes et les
réseaux externes d’une entreprise. En effet, si l’on prend les flux médias de la voix « RTP/UDP », il est asymétrique et il utilise
aléatoirement des ports compris entre 16384 et 32767 qui n’appartiennent pas aux Well-Kown ports. Par conséquent le firewall
filtrera ces flux multimédias qui sont pourtant indispensables à une communication basée sur le protocole H 323.
Le schéma ci-dessous illustre comment le firewall bloque les flux VoIP en bloquant simplement le protocole RTP :
figure 3 : problème firewall
1.2. Nat
1.2.1. Définition
Un routeur Network Translation Adresse (NAT : RFC1631) est un routeur qui est utilisé dans des réseaux où l'on veut limiter
l'accès de l’Internet au réseau interne ou partager une connexion Internet en utilisant une seule @IP publique. Par conséquent,
de l’Internet seul l’équipement NAT est visible et toutes les requêtes semblent provenir de lui. Les stations situées dans le
réseau interne ne sont donc pas visibles et sont ainsi protégées contre des attaques provenant de l’Internet.
Il existe plusieurs types de NAT :
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 7/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
CONE PLEIN : cette méthode consiste, à chaque nouvelle demande de connexion vers l’Internet, à remplacer l’@ip source et le
numéro de port du paquet par celle du routeur NAT. Lorsque le routeur NAT reçoit des paquets, il les envoie au poste qui a
précédemment ouvert la connexion, aucune vérification sur l’origine du paquet n’est effectuée. La machine peut recevoir une
réponse de n’importe quel poste de l’Internet.
Cela est particulièrement utile lorsqu’une application doit être accessible de l’extérieur du réseau interne tel qu’un serveur de
mail, Web, DNS, etc…Ainsi si un serveur derrière le NAT envoie un paquet avec le couple {adresse :port} {A :B}, le NAT traduit
{A :B} en {X :Y}. Tous les paquets entrants destinés à {X :Y} seront donc transmis à {A :B} quelque soit l’adresse source ou le
numéro de port de ce paquet.
figure 4 : Cône plein
CONE RESTRICTIF : cette méthode est quasiment identique à la précédente sauf que lors de la réception du paquet par le
routeur NAT il y a vérification du poste source. Seuls les paquets provenant des postes adressés de l’Internet par les
connexions sortantes vont être acceptés. La même chose peut être effectuée en faisant une restriction non plus sur les postes
adressés mais sur les ports adressés. Ainsi si un serveur derrière le NAT envoie un paquet avec le couple {adresse :port} {A :B}, le NAT traduit {A :B} en {X :Y}. Seuls
les paquets entrants destinés à {X :Y} ayant pour adresses sources celles des postes adressés seront transmis à {A :B}.
figure 5 : Cône restrictif
CONE SYMETRIQUE : cette méthode diffère des techniques ci-dessus dans la manière de traiter les paquets sortants. Il s’agit
ici d’assigner l’@IP du routeur NAT et un port aléatoirement à chaque demande sortante. En ce qui concerne les connexions
entrantes, ce type de NAT agit comme les cônes restrictifs sur les ports.
figure 6 : Cône symétrique
1.2.2. Limites
Le processus de NAT représente un problème au transit des flux multimédias entre le réseau interne et externe de l’entreprise.
En effet, quand les équipements multimédias ouvrent des canaux de contrôle, de signalisation et de communication média, ils
utilisent des @IP et de numéros de ports source et destination qu’ils inclus dans l’entête des PDU (Protocol Data Unit) de
niveau 4 du modèle TCP/IP (couche 5 à 7 modèle OSI). Ces infos se retrouvent alors incluses dans le champ données du
datagramme IP qui ne seront pas utilisées par le NAT qui intervient au niveau de l’entête IP du datagramme IP. Cela pose donc
des problèmes de cheminement de bout en bout entre les points finaux.
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 8/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
figure 7: NAT problème
Figure 8: NAT casse la communication de bout en bout des flux médias
Pour conclure, les obstacles au passage des flux multimédias à travers les firewalls et les NAT sont le fait que :
• Les firewalls et les NAT travaillent nativement sur la couche 3 du modèle OSI et que les protocoles applicatifs travaillent
sur la couche 4 et au-dessus.
• Les firewalls filtrent les paquets entrants et n’hésitent pas à les détruire si aucune communication n’a été établie au
préalable, et sous certaines conditions, avec le réseau interne.
• Le processus de NAT cache les @IP et les numéros de ports des connexions sortantes du réseau sur lequel il a été
installé.
• Les applications multimédias sont constituées d’une multitude de protocoles : SIP, MGCP, H323 pour le signalement ;
SDP, H225 et h245 pour la capacité d’échange et RTP/RTCP pour le contrôle et les flux audio/média.
• Enfin, il reste le fait que certains protocoles utilisent des ports dynamiques supérieurs aux Well-Kown ports.
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 9/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
1.3. Protocoles et ports utilisés par H323, SIP et MGCP
1.3.1. La norme H323
Système de contrôle& interfaceutilisateur
Applications auxdonnées utilisateurs
T.120
E/S EquipementsAudio
E/S EquipementsVidéo
H245contrôle
H225.0RAS contrôle
H225.0contrôle appel
H261 H263Codec Vidéo
G711 G722G723
G723.1G728 G729Codec Audio
Receive path delay
Couche H225.0
Pile LAN
Figure 9 : Pile de protocoles utilisés pour H323 Figure 10 : Flux de signalisation d’un appel avec H323
Figure 11 : Requêtes H323 qui inclus @IP et port
1.3.2. La norme SIP
Figure 12 : Pile de protocoles utilisés pour SIP Figure 13 : Flux de signalisation d’un appel avec SIP
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 10/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
Figure 14 : Requêtes H323 qui inclus @IP et port
1.3.3. La norme MGCP
Figure 15 : Pile de protocoles utilisés pour MGCP Figure 16 : Flux de signalisation d’un appel avec MGCP
Figure 17 : Requêtes H323 qui inclus @IP et port
2. 1ère solution : les relais Face aux problèmes que pose les firewalls et les NAT, plusieurs solutions ont été proposées. Celles-ci peuvent être regroupées
en deux catégories : les solutions utilisant un relais que nous verrons dans cette partie, et les solutions utilisant une
communication directe que nous verrons dans la partie suivante.
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 11/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
Dans cette partie, nous présentons des solutions utilisant un dispositif de relais afin d’acheminer l’information entre deux entités
effectuant une communication poste à poste.
2.1. Serveur d’application Cette technique utilisant un serveur d’application consiste à le déployer :
soit dans un domaine privé :
soit dans une zone démilitarizée (DMZ, domaine neutre) :
Dans ces deux cas, le serveur joue le rôle de relais entre des postes désireux de communiquer ensemble.
L’utilisation de cette technique permet la traversée de tous les dispositifs de sécurité et de toutes les topologies :
Dispositif Appel sortant Appel entrant
Pare-feu • •
Cône plein • •
Cône restrictif • •
Cône restrictif sur les ports • •
Symétrique • •
Topologie • •
Réseau public • •
Réseau interne • •
Réseau interne avec un accès au
réseau public • •
Réseau avec un chaîne de pare-feu • •
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 12/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
ou de routeurs NAT
Cette technique présente aussi bien des avantages que des inconvénients :
Avantages Inconvénients
Technique simple, éprouvée, déployée et utilisée Déploiement et maintenance d’un serveur
Aucune modification des éléments du réseau, des applications
ou des protocoles de communication
Utilisation d’un serveur d’application
=> solution propriétaire et spécifique à un protocole
Sécurité du réseau non compromise
En conclusion, il s’agit d’une solution simple mais peu polyvalente et donc non adaptée aux besoins en services multimédias
diversifiés, appelés à prendre de l’expansion. De plus, étant donné que cette solution réside en un relais, les temps de latence
peuvent amoindrir de manière significative les performances des applications multimédias.
2.2. 2.2.2. Serveur d’application avec agent : Cette technique consiste à reprendre la solution précédente (serveur d’application dans un réseau public ou démilitarisé) en y
ajoutant un agent, situé à l’intérieur du réseau privé :
Les deux entités (serveur et agent) vont permettre de créer un tunnel d’informations, dans lequel transiteront les différentes
communications établies entre postes de travail du réseau public et du réseau privé. Les communications s’effectuent par des
ports prédéfinis et autorisés auprès des firewalls et des routeurs NAT.
Cette solution offre à des clients de profiter d’un serveur de relais, et ce, en ayant peu ou pas de contrôle sur les éléments et les
topologies du réseau.
Comme pour la solution précédente, celle-ci traverse tous les dispositifs de sécurité (pare-feu, cône plein, cône restrictif, cône
restrictif sur les ports, symétrique) ainsi que toutes les typologies (réseaux public, interne, interne avec accès au réseau public,
réseau avec chaîne de pare-feu ou de routeurs NAT).
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 13/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
En terme d’avantages, en plus de ceux cités précédemment on peut ajouter un modèle plus polyvalent pour les différents
services étant donné que le serveur est normalement déployé dans le domaine public. Le serveur peut donc être accessible par un plus grand nombre d’utilisateurs tout en offrant le même niveau de sécurité au niveau des réseaux privés.
Les désanvantages restent les mêmes que pour la solution avec un simple serveur d’application si ce n’est que la maintenance
d’une telle technique risque d’être accrue ainsi que les temps de latence augmentés du fait de la multiplication des dispositifs.
2.3. 2.2.3. Passerelle de la couche d’application (ALG) :
La technique de la passerelle d’application va faire de simple firewall/Routeur NAT, des firewalls et routeurs NAT « intelligents »
c’est-à-dire capables de filtrer non plus au niveau 3 mais au niveau 7 (couche applicative). Ils seront ainsi capables d’interpréter
un protocole spécifique. Plutôt que de vérifier uniquement l’entête du paquet à traiter, les passerelles réalisent une inspection
complète des données dans le corps du paquet. Les passerelles agissent donc en tant que relais spécialisé pour un protocole
précis (SIP par ex.) :
1. Pare-f
Pas
Couche physique
Couche liaison donn
Couche réseau
Couche transpor
Couche session
Couche présentati
Couche applicatio
Attention à ne pas conf
« filtrage » est effectué d
routeurs NAT qui se cha
Ainsi dans le cas d’un r
contenu complet du paq
réseau public. Suite à ce
Dans ce modèle, et com
librement.
30/09/2004 VIGODA/LAH
serelle de la couche « Application » utilisée en tant que relais
Couche physique
Couche liaison données
Couche réseau
Couche transport
Couche session
Couche présentation
Couche
Couche physique
Couche liaison données
Couche réseau
Couche transport
Couche session
Couche présentation
Couche
ées
t
on
n
ondre serveurs application (§ 2.2.1.) et passerelles de la couche application. En effet,
ans le premier cas par les serveurs d’application alors que dans le second cas, ce sont le
rgent d’effectuer le traitement.
éseau privé utilisant une passerelle de la couche application « SIP », le firewall/routeur N
uet, va modifier adresse IP et port inscrits dans le paquet afin de pouvoir transmettre le pa
la, le firewall/routeur NAT ouvrira un « trou d’épingle » afin que la communication ait lieu li
me dans les autres précédemment cités, dispositifs techniques et topologies peuvent êt
OCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias
eu/Routeur NAT
le travail de
s pare-feux /
AT va lire le
quet dans le
brement.
re traversées
14/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
Avantages Inconvénients
Technique simple. Modification des éléments réseaux
(pare-feu et routeurs NAT).
Sécurité accrue. Adaptabilité difficile (1 passerelle = 1 application)
Ressources limitées des pare-feu et routeurs NAT qui limitent
par la même le nombre d’utilisateurs simultanés du service.
Temps de latence importants dû au traitement complet et
individuel des paquets.
2.4. 2.2.4 Traversal Using Relay NAT (TURN)
Principe de TURN
TURN est un protocole en cours développement et de standardisation auprès de l’IETF, il s’agit en fait d’un serveur de relais : il
permet à des clients situés dans des réseaux équipés de firewalls et de routeurs NAT de communiquer ensemble en passant
par un serveur de relais.
A l’inverse des solutions précédemment citées, TURN est complètement indépendant vis-à-vis des protocoles de
communication utilisés. C’est ce qui fait son point fort.
Développé après STUN (cf § correspondant), TURN comble certains manques de celui-ci : il permet à des postes de
communiquer entre eux indépendamment de la topologie utilisée, des éléments de sécurité déployés et du protocole de
communication employé.
Avantages Inconvénients
Technique simple à comprendre et à déployer Technique encore en cours de développement
Aucune modification sur le réseau Peu répandu
Conservation de l’intégrité du réseau Modification des programmes nécessaire pour qu’il puissent
intégrer TURN
TURN n’est lié à aucun protocole de communication Latence accrue car les données ne transigent plus directement
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 15/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
3. 2ème solution : la communication directe La technique utilisant une communication directe permet de traverser les firewalls et les processus de NAT pour établir une
communication entre postes en modifiant les protocoles de communication ou les éléments réseaux mais sans utilisation de
relais. Il existe 5 grandes catégories de communication directe : tunnel de données, UPnP, STUN, Midcom et ICE.
3.1. Tunnel de données Cette technique consiste à créer un tunnel de données grâce à un Réseau Virtuel Privé (RVP) utilisant des protocoles de
communication standards et existants tels que PPTP, L2TP et IPSec. Le RPV va mettre les postes dans un même domaine
privé pour ensuite acheminer tous les paquets nécessaires vers tous les postes.
Figure 18 : Principe du tunnel de données
Cette technique permet de traverser tous les dispositifs de sécurité tels que les firewalls et tous les différents types de NAT et
sur toutes les topologies réseaux : réseau interne, réseau interne avec un accès public, réseau public, et réseau avec une
chaîne de firewalls et de routeurs NAT.
Avantages Désavantages
Utilisation de protocoles existants et largement utilisés pour
permettre une communication virtuelle.
Aucune modification des éléments réseaux ou applications.
Déploiement facile pour une entreprise multisites.
Besoin d’établissement d’un RPV entre deux postes avant
toute communication.
Niveau de maintenance élevé.
3.2. Universal Plug and Play (UPnP) UPnP est un nouveau standard de communication soutenu par Microsoft Corporation et Intel. Il a été développé pour des
petites entreprises et des réseaux résidentiels (SOHO - Small Office HomeOffice) dans l'optique d'être un standard convivial et
flexible aux réseaux non gérés.
UPnP est plus qu'une simple extension du standard de périphériques Plug and Play. Cela signifie que les firewalls et les
équipements NAT sont détectés par les stations de travail de façon automatique et que ces postes peuvent ouvrir, au besoin,
des trous sur les routeurs NAT et les firewalls de façon dynamique. Ce standard, contrairement à la technique précédente, permet de traverser tous les dispositifs de sécurité tels que les firewalls
et les NAT mais pas dans la topologie où le réseau est constitué d’une chaîne de firewalls et de routeurs NAT. En effet, les
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 16/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
communications entre dispositifs UPnP s'effectuent seulement entre deux dispositifs au sein d'un même sous réseau. Les
chaînes de firewall et de dispositifs NAT n'étant pas dans le même sous réseau, les dispositifs ne peuvent donc pas
communiquer entres eux.
Avantages Désavantages
Convivial et interaction transparente des protocoles.
Standard existant dans les réseau SOHO.
Plusieurs dispositifs UPnP déjà présents sur le marché.
Modification des applications afin de communiquer avec des
équipements UpnP.
Firewalls et équipements NAT doivent supporter le UpnP.
Problème de sécurité : UPnP peut créer des brèches dans le
réseau par ces trous générés sans authentification.
3.3. Midcom Midcom est un standard en cours de développement rendant « intelligents » les firewalls et les équipements NAT pour créer
dynamiquement des trous. Il diffère de la technique des passerelles de la couche application et du standard UPnp vu
précédemment. En effet, Midcom n'est pas lié à un protocole de communication, il ne va pas décortiquer les protocoles de
communication jusqu'au niveau application comme le fait les passerelles. De plus, il se contente d'ouvrir des trous mais suite à
une authentification ou un contrôle d’accès de l'usager.
Comme UPnP, il ne peut exister sur les réseau dont la topologie met en œuvre une chaîne de firewalls et d’équipements NAT.
Avantages Désavantages
En voie de standardisation.
Traverse tous les protocoles de communication.
Authentification.
Aucun réseau MIDCOM actuellement.
Communication adaptée aux dispositifs MIDCOM.
3.4. Simple Traversal of UDP Through Network Address Translation devices (STUN) STUN est un protocole énoncé dans la RFC3489 et développé par le groupe de travail de MIDCOM. Il permet de traverser les
routeurs NAT en affectant une @IP et un numéro de port public à un poste situé dans le réseau privé pour effectuer une
communication de type UDP avec un réseau public. Pour ce faire, une série de requêtes à un serveur STUN est effectuée et
les réponses du serveur servent à caractériser l’@ip et le numéro de port d'un poste à communiquer.
Figure 19 : Principe STUN : il ne gère pas les flux de signalisation ni de média.
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 17/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
Ce protocole va permettre aux protocoles multimédias de traverser tous les types de NAT sauf le NAT de type symétrique et les
firewalls. En effet, les firewalls filtrants systématiquement tous les paquets, cela empêche toutes ouvertures de session. De
plus, le caractère aléatoire du NAT symétrique empêche de prévoir le comportement de la translation et donc empêche
également d’ouvrir une session.
Ce protocole s’adapte à un grand nombre de topologie de réseaux. Cependant il ne permet pas de traverser les chaînes
d’équipements NAT car il n’arrive pas à déterminer l’@IP à utiliser avec les utilisateurs situés entre le réseau de l’appelant et
l’Internet. Il détermine uniquement l’@IP du domaine public.
Avantages Désavantages
Protocole standardisé.
Peu d’infrastructure : seul 1 serveur doit être déployé pour
effectuer les requêtes.
Aucune modification de l’architecture réseau.
Adaptation des programmes existants.
Requêtes/réponses pouvant être vus comme des attaques par
firewalls…
Ne traverse pas tous les firewalls et dispositifs de NAT.
Ne peut pas être cumulé à des passerelles applicatives.
@IP mal déterminée lors de communications en interne.
3.5. Interactive Connectivity Establishment(ICE) ICE est une technologie en cours de développement qui consiste à intégrer STUN et TURN au sein des clients SIP pour
déterminer toutes les connections possibles entre deux postes.
Ce protocole caractérise les transmissions de média entre les postes et le réseau public par des requêtes STUN à un serveur
combinant STUN/TURN. Ensuite, il gère une liste d'@IP par lesquelles chaque poste peut être contacté et détermine enfin la
meilleure communication possible entre deux postes. Si aucune communication directe n’est possible entre deux postes, ICE
utilise alors les services d'un serveur TURN pour générer la communication. Contrairement à l’utilisation de STUN tout seul, ICE permet de traverser tous types de dispositifs NAT et n’importe quel type de
topologie de réseaux : qu’il y ait ou non des chaînes de firewall et NAT. Cependant ICE ne gère pas les communications s’il faut
traverser des firewalls.
Avantages Désavantages
ICE en cours de standardisation.
STUN est standardisé.
Traverser de toutes types de dispositifs et de topologie
réseaux sauf les firewalls.
Aucune modification de la politique de sécurité réseau.
Peu de déploiement : un serveur STUN/TURN uniquement.
Temps d’établissement d’un appel long.
Les échanges pour caractériser les communications peuvent
être perçues comme des attaques.
Besoin de démultiplexeur car les flux STUN & TURN se
partagent le même port.
Modification des serveurs et clients pour le déploiement.
4. Conclusion protocolaire Plusieurs solutions ont donc été créées pour permettre aux protocoles multimédias de traverser les firewalls et les dispositifs de
NAT.
4.1. Avantages des solutions de communication directes Les solutions dites de « communication par relais » ont montré quelques désavantages comme l’augmentation du temps de
latence du réseaux, ou la spécificité de chaque relais à un protocole particulier : SIP, H323, MGCP, etc…
Les solutions dites de « communication directes » sont rapidement apparues pour limiter ces lacunes. Elles ont notamment
permis de diminuer les temps de latence, ou d’étendre plus facilement les réseaux n’étant plus liés à un protocole en particulier.
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 18/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
4.2. Avantages de la solution Midcom Comparativement, bien que pas encore déployée, la solution Midcom présente la technique théorique la plus avantageuse. Elle
présente tout d’abord l’avantage de ne pas être une solution relais. Ensuite, face à la méthode de « tunnel de données » elle
nécessite des coûts de maintenance et d’opération moins élevés. Face à la solution « UpnP », Midcom offre davantage de
sécurité en apportant un niveau d’authentification lors de la création des trous de communication. Face à « STUN », Midcom
gère la traversée des NAT de type symétrique. Enfin, face à la technologie « ICE », Midcom traverse les firewalls car il n’est
pas perçu par les firewalls comme des attaques de sécurité.
Cependant, il ne faut pas oublier que Midcom présente quelques inconvénients qui peuvent le freiner à son déploiement dans
les réseaux. Il s’agit notamment du fait qu’il ne soit pas encore reconnus comme un standard (étant encore en phase
d’élaboration), qu’il ne traverse pas les chaînes de dispositifs NAT ou bien qu’il exige des modifications des équipements du
réseau (serveurs, firewalls, etc…).
L’état de l’art Les constructeurs de firewalls ont, depuis peu, accentué leur recherche quant au support de la VoIP dans leur matériel.
Depuis quelques mois maintenant, les principaux fournisseurs de firewall ont inondé le segment H323 tandis que les solutions
liées au protocole SIP devraient véritablement apparaître courant 2006.
Nous pouvons cependant vous donner une liste non exhaustive de matériels capables de supporter les protocoles multimédias :
- la société Netrake (http://www.netrake.com/index.asp) produit des « Session Contrôler » qui sont des nouveaux
matériels réseaux éxecutant les fonctions requises pour des communications en temps réels .
Ils sont une combinaison des sous-fonctions suivantes :
- Signaux :
- SIP Proxy
- H323
- MGCP proxy
- Security :
- Firewall
- NAT
- Dos Protection
- …
- la société suédoise Intertex (www.intertex.se) produit trois sortes de firewalls supportant SIP. Ce sont des firewalls
incluant un serveur SIP (avec un proxy SIP et un registre SIP) qui contrôlent en temps réel les besoins en ouverture de ports.
Commercialisés sous le nom de IX66, ils présentent des fonctionnalités avancées et ce, pour un prix équivalent à un firewall
classique.
Références
Requests For Comments : 1918 adressage privé public; 3489 STUN; 1631 NAT
www.ietf.org
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 19/20
FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA
Généralistes VoIP
www.guillnet.com
www.commentcamarche.net
Généralités NAT
www.cisco.com/warp/public/556/nat-cisco.shtml
Problème NAT et firewall:
CISCO : www.cisco.com/warp/public/788/voip/voip-nat.html#topic3
Newport NETWORK : www.newport-networks.com/whitepapers/nat-traversal.html
TERENA Cookbook : www.terena.nl/tech/IPtel/
Darmstadt UNIVERSITY of Technology : ww.iptel.org/2000/pr/H323FW.PDF
INSTITUTE for Open Communication Systems : www.iptel.org/~jiri/students/tu/2004-june-tu.pdf
UNIVERSITY of Sherbrooke : ww.iro.umontreal.ca/~jaumard/Research_Projects/Mitacs_Project2/Publications/Report1.pdf
DYNAMIC soft : www.dynamicsoft.com/news/presentations/springvon2002_sip-nat-frwl.pdf
Etat de l’art:
techupdate.zdnet.com/techupdate/stories/main/0,14179,2914709,00.html?tag=tu.tk.6587.f3
30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 20/20