Réalisation d'un client serveur d'échange de paquets entre deux sous réseaux reliés par un VPN

1. Réalisation d'un client serveur d'échange de paquets entre deux sous réseaux reliés par un VPN Wilfried DUQUENNE, Sylvain CLERCQ & Mina BEN HADDOU Master TIIR - 2005

2. Sommaire • Introduction • Etude • Fonctionnement des différents protocoles • Avantages et inconvénients de ces protocoles • Problèmes définis • Réalisation • Solution proposée • Travail effectué • Travail restant à faire • Difficultés rencontrées • Conclusion

3. Introduction 1/2 • Pour assurer l’accès sécurisé des entreprises réparties sur de grandes distances géographiques, on met en place des VPN.  • Différentes solutions pour mettre en place un VPN non matériel : • Utiliser une technologie reposant sur un protocole comme IPSEC, PPTP, L2F ou L2TP. • Employer une autre technologie comme OpenVPN qui repose sur les tunnels SSL.

4. Introduction 2/2 • IPSEC s’impose dans ce domaine en plein développement, mais il souffre d’un défaut majeur. • But du projet : Réaliser un client / serveur d'encapsulation et de transit de paquets sur un VPN IPSEC, qui peut récupérer les paquets de broadcasts ou de multicasts sur un premier réseau et les envoyer sur un deuxième.

5. Fonctionnement de PPP (Point to Point Protocol) • BUT : Transférer des données sur un lien synchrone ou asynchrone. • Protocole Full Duplex. • Ordre d’arrivée des paquets est garanti. • Il encapsule les paquets IP, IPx et Netbeui dans des trames PPP, puis transmet ces paquets encapsulés au travers de la liaison point à point. • Trame PPP :

6. Phases d’une connexion PPP • Une méthode pour encapsuler les datagrammes. • Le protocole LCP (Link Control Protocol) • Les protocoles d'authentification (MS-CHAP, EAP) • Les protocoles NCP (Network Control Protocol)

7. Fonctionnement de PPTP(Point to Point Tunneling Protocol) • Principe : • Créer des trames sous le protocole PPP et de les encapsuler dans un datagramme IP. • Créer un tunnel de niveau 3 défini par le protocole GRE (Generic Routing Encapsulation) en établissant une connexion PPP à un serveur distant. • Point faible : • L’authentification (protocole MS-CHAP).

8. GRE(Generic Routing Encapsulation) • Protocole ouvert. • Conçu pour pouvoir encapsuler n'importe quel protocole de niveau 3 dans IP. • Avantages : • Possibilité d'ouvrir depuis un hôte donné autant de tunnels que l'on désire, vers différents réseaux distants. • Solution fort souple. • Inconvénient : • Trop peu sécurisé pour être utilisé sans risques.

9. Fonctionnement de L2TP(Layer Two Tunnel Protocol) 1/2 • Issu de la convergence de PPTP et L2F. • Développé et évalué conjointement par Cisco Systems, Microsoft, Ascend, 3Com. • Permet l'encapsulation des paquets PPP au niveau des couches 2 (FrameRelay et ATM) et 3 (IP).

10. Fonctionnement de L2TP(Layer Two Tunnel Protocol) 2/2 • Les 2 concepts de L2TP : • Les concentrateurs d'accès L2TP (LAC : L2TP Access Concentrator). • Les serveurs réseau L2TP (LNS : L2TP Network Server). • L2TP n'intègre pas directement de protocole pour le chiffrement des données. C'est pourquoi l'utilisation conjointe d'IPSec et L2TP estrecommandée.

11. Fonctionnement de IPSEC(Internet ProtocolSecurity) • Permet de sécuriser l'échange de données au niveau de la coucheréseau. • Basé sur 2 mécanismes de sécurité : • AH (Authentification Header) vise à assurer l'intégrité et l'authenticité des datagrammes IP. • ESP (Encapsulating Security Payload) assure la confidentialité et l’intégrité des données.

12. AH et ESP Bien qu'indépendants ces deux mécanismes sont presque toujours utilisés conjointement.

13. La gestion des clefs dans IPSEC • Problème fondamental de l’utilisation de cryptographie. • 2 catégories : • IKE (Internet Key Exchange) : système qui vise à fournir des mécanismes d'authentification et d'échange de clef adaptés à l'ensemble des situations qui peuvent se présenter sur l'Internet. • ISAKMP a pour rôle la négociation, l'établissement, la modification et la suppression des associations de sécurité et de leurs attributs.

14. Fonctionnement de SSL(Secure Sockets Layers) • Protocole de couche 4 (niveau transport) utilisé par une application pour établir un canal de communication sécurisé avec une autre application. • 2 fonctionnalités : • L’authentification du serveur et du client à l’établissement de la connexion. • Le chiffrement des données durant la connexion.

15. Segmentation des paquets en paquets de taille fixe. Compression (mais peu implémenté dans la réalité). Ajout du résultat de la fonction de hachage. (composé de la clé de cryptage, du numéro de message, de la longueur du message, de données ...) Chiffrement des paquets et du résultat du hachage à l’aide de la clé symétrique générée lors du Handshake. Ajout d’un en-tête SSL au paquet : Phases du protocole SSL(SecureSocketsLayers)

16. Exemple : OpenVPN • Solution logiciel complète de VPN qui peut s’adapter à un éventail de configurations (Linux, Windows 2000/XP, OpenBSD, FreeBSD, NetBSD, Mac OS X, et Solaris). • Le principe de base : • Utiliser une interface de capture standard du kernel Linux (tun ou tap) • Expédier ces données chiffrées et authentifiées via SSL sur un port UDP (éventuellement TCP) en utilisant un mot de passe ou une clé publique, éventuellement une PKI.

17. Avantages et inconvénients 1/2 • PPTP : • Avantage : • Intégré dans les environnements Windows. • Inconvénients : Sécurité. • Mauvaise gestion des mots de passe. • Faiblesses dans la génération des clés de session. • Faiblesses cryptographiques du protocole MS-CHAP 1 corrigées dans la version 2 (mais aucun contrôle sur cette version n’a été effectué par une entité indépendante). • Identification des paquets non implémentée : vulnérabilité aux attaques de type « spoofing ».

18. Avantages et inconvénients 2/2 • L2TP et IPSEC : • Avantages : • Mécanismes de sécurité robustes. • Inconvénients : • Ne permet d’identifier que des machines et non pas des utilisateurs (problématique pour utilisateurs itinérants). • Aucun mécanisme de QoS. (applis voies ou vidéos sur IP impossibles). • Lourdeur des opérations de cryptage/décryptage. • VPN-SSL : • Problèmes liés aux navigateurs web utilisés (ex : au niveau des certificats de sécurité à renouveler).

19. Problèmes définis • Problème de transfert des messages de broadcasts et de multicasts : • PPTP : • Interface PPP qui véhicule les paquets de données vers le serveur PPTP, à travers le tunnel. • Cette interface ne laisse passer que les paquets de type point à point et multicast. • Elle ne laisse pas passer les paquets de broadcasts. • IPSEC : • IPSEC est un protocole de sécurité d’ IP de couche 2, alors que les broadcasts et les multicasts fonctionnent sur la couche 3, d’ou le problème d’envoi et de réception de ces messages. • Remarque : IPSEC rejette les paquets de broadcasts et de multicasts sauf dans le cas ou il est associé à L2TP.

20. Solution proposée

21. Travail effectué 1/4 • Le sniffage des paquets de broadcasts : • Implémentation d’un démon en C. • Utilisation de la librairie pcap : • bibliothèque indépendante du système. • interface à la capture de paquets. • permet d'écouter le réseau. • inclut un mécanisme de filtrage basé sur le Berkeley Packet Filter (BPF).

22. Travail effectué 2/4 • L’encapsulation de ces paquets : • Notre étude  Utilisation de PPP. • Recherche du programme PPTP-Client. • Etude de ce code. • Encapsulation des trames de broadcasts en paquets HDLC. • Désencapsulation de ces trames.

23. Travail effectué 3/4 • Encaps_hdlc : • Calcul de la FCS (Frame Check Séquence) en fonction de la longueur du paquet, afin de vérifier la validité des paquets lors de leur réception. • Positionnement du HDLC_Flag. • Calcul, en fonction de la longueur du paquet, l’endroit où le FCS doit être inséré (fin de paquet). • Mise en place du HDLC_Flag en fin de paquet. • Injection du paquet dans le descripteur de fichier.

24. Travail effectué 4/4 • Decaps_hdlc : • Vérification de la validité du paquet en fonction de la longueur de celui-ci. • Reherche du HDLC_Flag. • Vérification de la FCS qui permet de déterminer si aucune erreur de transmission n’a eu lieu. • Lecture des données pour la reconstruction du paquet initial.

25. Travail restant à faire • Terminer le développement : • Côté client : • Récupérer les paquets encapsulés. • Les envoyer au serveur. • Côté serveur : • Récupérer et identifier les paquets encapsulés par le client. • Lancer la désencapsulation (fonction decaps_hdlc) • Récupérer les paquets et vérifier qu’ils sont conformes aux originaux. • Véhiculer ces paquets sur le sous-réseau destination.

26. Difficultés rencontrées • Documentation sur le problème de transfert de paquets de broadcasts : • Légère, car sujet en plein essor. • Parfois contradictoire. • Etude du code source de PPP et PPTP-Client : • Longue et assez complexe afin de déterminer le but et le traitement des fonctions.

27. Conclusion • Virtual Private Network : Domaine récent et en pleine évolution. • Projet intéressant au niveau des connaissances et expérience apportées. • Malheureusement, projet non terminé.  On espère que ce sera fait l’an prochain.

28. Merci et à vos questions !