1- Etude des différentes solutions – Avantages/Inconvénients

L’étude des différentes solutions a donné lieu à un rapport complet expliquant en détail les principaux protocoles, soit IP Sec, SSL/TLS, PPTP, LTF, L2TP, L2P. Je n’ai évidemment pas reproduit ici cette étude par manque de place.

En bref, nous pouvons dire que les VPN (Virtual Private Network ou Réseau Privé Virtuel) ont les avantages et les inconvénients suivants :

Avantages : Maîtrise totale des échanges de données / utilisation du réseau public Internet / mise en œuvre moins élevée qu’avec une liaison sécurisée.

Inconvénients : Nécessite une infrastructure logicielle souvent importante / nécessité de respecter les réglementations en vigueur sur le chiffrement.

2- Mise en œuvre de la solution VPN

Dans le cadre du projet, on m’a demandé d’étudier la mise en place d’un VPN reliant une machine sous LINUX et une autre sous NT (qui aurait migré sous UNIX ultérieurement) en utilisant le protocole IPSec, qui est le protocole le plus connu. Avec ce protocole, il existe deux types de transformations pour protéger les paquets IP : l’AH (Authentication Header) et l’ESP (Encapsulating Security Payload).

3- Le protocole IPSec

Une étude beaucoup plus complète est disponible ici, mais je me suis limité à rappeler les choses les plus importances dans ce contexte.

a) Authentication Header (AH)

Figure 1 : AH en mode tunnel

Cette transformation authentifie, protège en intégrité les datagrammes IP (y compris les champs des entêtes qui ne varient pas lors de la transmission) et assure une protection "anti-replay" (chaque paquet est numéroté par le champ "Sequence Number" de l'entête AH) et les paquets rejoués ne sont pas pris en compte. Elle n'apporte cependant pas de confidentialité. Coté expéditeur, cette transformation consiste en un MAC^(*) (Message Authentification Code) qui est calculé sur l'ensemble du datagramme et dont le résultat est ensuite joint au datagramme. Coté destinataire, il suffira de recalculer le MAC afin de vérifier l'authenticité et l'intégrité des données. Les transformations AH peuvent se faire en mode transport ou en mode tunnel et obéissent aux spécifications définies dans les Security Associations.

Mais dans mon cas, le fournisseur d’accès à Internet utilise la NAT, ainsi que moi-même dans mon Firewall pour certains services…ce qui fait que le paquet émis va être modifié par le Firewall qui va changer la véritable adresse source pour la remplacer par la sienne. Parfait. Mais comme le destinataire va avoir à recalculer le MAC afin de vérifier l'authenticité et l'intégrité des données, il va évidemment trouver que le paquet a été altéré et que l’adresse IP n’est plus celle avec qui il dialogue. Par conséquent tout paquet émis ou reçu va être trouvé altéré pour la simple raison que l’adresse source va changer. De plus, nous ne parlons pas des erreurs provoquées lors de vérifications de codes de redondance cyclique ou de "cheksums"! AH ne peut donc pas marcher dans notre cas. Voyons maintenant rapidement ESP.

b) Encapsulation Secutity protocol (ESP)

Figure 2 : ESP en mode tunnel

La transformation ESP permet d'assurer la confidentialité, l'authentification et l'intégrité des datagrammes IP en les chiffrant conformément à ce qui est défini par les Security Association. ESP assure aussi une protection contre le rejeu des paquets, grâce au champ "Sequence Number" de l'entête ESP. Les transformations ESP chiffrent des portions des datagrammes, peuvent encapsuler ces portions dans d'autres datagrammes IP et peuvent effectuer des contrôles d'intégrité via un Integrity Check Value (ICV).

Tout comme AH, l'ESP peut se décliner en mode transport. L'entête IP du datagramme original est conservé et les autres champs sont sécurisés et précédés d'une entête ESP:

En mode tunnel, un entête IP est généré, précédent le datagramme sécurisé et ne contenant aucune option IP, même si l'entête initiale en contenait. Ce mode est typiquement utilisé pour les communications "gateway-to-gateway", où il permet de masquer les adresses IP des expéditeurs et destinataires originaux. Mais c’est là qu’apparaît le même problème que précédemment lorsque l’on utilise la NAT.

Par conséquent, utiliser IPSec avec la NAT ne semble pas possible (à moins sans doute de trouver une solution commerciale complexe qui résolve ce problème par un moyen ou un autre). Mais de plus, je n’ai pas trouvé de logiciel qui permet de faire un IPSec avec Linux.

4- SSL/TLS

Je me suis donc rabattu sur SSL/TLS (TLS est la dernière version de SSL), mais je me suis heurté à un nouveau problème : j’ai pu trouver un freeware pour LINUX (OpenSSL), mais il n’y avait presque pas de documentation et réussir à établir un VPN dans ce cas avec OpenSSL semblait requérir une parfaite connaissance de toute une série de commandes. Mais de toute façon, il m’a été impossible de trouver un freeware pour NT, ce qui rendait l’établissement d’un VPN impossible.

5- PPTP

Ce protocole est assez simple d’utilisation, mais .malheureusement dans le cadre de mon stage, je devais établir un tunnel entre deux machines dont une tournait sous Windows NT, mais l’autre tournait sous Linux et devait évoluer sous UNIX ultérieurement. Le problème est que PPTP et un protocole propriétaire (Microsoft), et par conséquent non utilisable avec autre chose que des machines tournant sous Windows.

Il aurait été intéressant de savoir s’il était possible d’établir un VPN comme suit :

Cette architecture aurait eu l’avantage d’être indépendante des systèmes d’exploitations utilisés. Les deux ordinateurs intermédiaires appartiendraient à l’entreprise qui offrirait ce service, et les deux ordinateurs au bout seraient les nôtres qui tournent sous des OS différents. Il nous suffirait de connecter chaque ordinateur à nous à son correspondant compatible du point de vue de l’OS, et l’entreprise prestatrice assurerait l’interfaçage entre les deux.

Il doit probablement exister de telles architectures sur Internet, mais je n’éi pas eu le temps de voir comment faire pour en mettre une en place ou de voir qui offrirait ce genre de solutions.

SUITE>>

Présentation de AQSACOM

RAPPORT :

La mise en place du pare feu sous LINUX

Le sniffage discret d’un réseau

La sécurisation de machines sous NT et LINUX

ANNEXES