WEBVpn, SSL/TLS en action

Topic présentant un peu de théorie sur les tunnels SSL/TLS et Ipsec configurables entre un client et un routeur CISCO.

Pourquoi et pourquoi faire ?

Imaginons un utilisateur connecté sur une borne WIFI dans une gare, Il doit impérativement accéder à des documents se trouvant sur le serveur de fichiers de son entreprise. Comment le faire de manière sécurisée : au moyen d'un tunnel VPN entre son ordinateur et le routeur ou firewall qui est le point d'entrée dans l'entreprise. En fonction de la politique de sécurité, de l'environnement logiciel et matériel mais aussi des droits accordés aux utilisateurs il va falloir déployer ces technologies VPN de manière différente.

La théorie du complot.

On trouve deux grandes familles de tunnels VPN : les tunnels utilisant les protocoles TLS/SSL et ceux utilisant IPsec. Les deux fournissent les mêmes capacités en termes de protection des données.

On trouve ensuite deux grands modes d'encapsulation des données.

Clientless VPN.

Aucun software n'est installé sur la machine cliente. L'utilisateur va utiliser un navigateur web pour accéder au router WebVPN. Celui-ci va proposer une page web contenant des liens et des bookmarcks vers différents services dans le LAN.

FullTunneling VPN.

Un software, dans notre cas ce sera CISCO AnyConnect, est installé sur la machine du client ou nous disposons d'un routeur (comme dans une configuration site à site). Contrairement au clientless VPN qui va se limiter à un accès via http, nous avons ici un accès complet à toutes les ressources de notre LAN.

Pour résumer nous pouvons configurer :

Un tunnel clientless TLS/SSL.

Avantages : facile à configurer et pas de soucis de pare feu, la technologie utilisant le protocole https.

Problèmes : ne supporte pas toutes les applications IP, les clients peuvent utiliser des ordinateurs non sécurisés pour accéder au réseau

Après une authentification bi-directionnelle le client arrive sur une page web fournie par le routeur. On accède ainsi aux ressources : page web ou partage de fichier. Il est possible via JAVA d accéder à de plus amples services.

Un tunnel FullTunneling TLS/SSL

Avantages : accès à toutes les ressources du réseau, pas de soucis de pare feu.

Problèmes : nécessite l'installation d un software.

Le principe de ce tunnel est que le routeur devient transparent une fois le tunnel VPN actif, le client se retrouve dans la plage d adresse IP du LAN, ce qui lui donne accès à toutes les ressources disponibles.

Un tunnel FullTunneling IPsec

Avantages : accès à toutes les ressources du réseau

Problèmes : nécessite l'installation d un software /mise en place d'un routeur, difficulté à traverser des pare feu.

Les fonctionnalités sont identiques au FullTunneling TLS/SSL. Attention à ne pas s arracher les cheveux avec les pare feu, le NAT … c'est une vraie misère !!!! Le VPN utilise le protocole IPsec, la configuration est quasi-similaire à une tunnel site a site, profil ISAKMP et IPsec, attention cependant à X-AUTH.

Mise en pratique : WebVPN clientless TLS/SSL

Place a la configuration !!!

Nous allons dans ce topic configurer un tunnel entre une station client Seven et notre réseau d' entreprise. Le but est de pouvoir accéder au serveur IIS héberge sur une plate-forme 2012. Nous afficherons également un message bonjour aux utilisateurs qui se connectent au portail.

Dans un premier temps nous allons utiliser un self-signed certificate pour authentifier notre routeur auprès du client. Cette méthode requiert très peu de configuration, cependant, elle n'est pas la plus sûre (vous verrez pourquoi dans la suite),

Voici la configuration de la passerelle (ici R6) :

Ssl trustpoint pointe vers notre self-signed certicate

Pour info, le trustpoint associé est visible via un show run classique :

Inservice va activer la fonctionnalité WebVPN

On peut changer les paramètres des protocoles utilises en utilisant la commande ssl encryptions

Passons maintenant à la configuration des context et des policies.

Un context, lié à une passerelle, va contenir plusieurs policies qui vont être appliquées aux utilisateurs qui tentent de se connecter. On peut citer « comment authentifier l utilisateur », « quels bookmarks vont apparaître sur notre passerelle », …

Dans mon exemple nous allons utiliser la manière la plus simple d'authentifier un utilisateur, en utilisant la base locale de notre routeur. Dans un prochain topic, nous utiliserons notre AD pour effectuer cette tache.

Tout d abord la création du context

Ici, on lie notre contexte à notre passerelle. Nous l'activons via la commande inservice.

Les polices.

Chose à savoir : il existe une police par défaut. On peut appliquer une police en se basant sur des RADIUS-Assigned Session Attributes. Ceci sera développé dans un prochain topic, conjointement avec la mise en place d'une authentification des users via AD.

Voici la configuration :

Création dans un premier temps d' un utilisateur sur notre routeur avec les privilèges les plus bas.

Attention à ne pas donner de droits d administrations !!!!

Nous configurons dans un second temps l'accès au routeur via un aaa new-model et une authentication locale (ici nommée VPN). Attention à bien en créer une spécifique à l'accès WEBVpn, n'utiliser pas celle par défaut.

En fonction de l'IOS qui tourne sur le routeur, le résultat d'un show run va être différent. Si j'applique par exemple mon aaa authentication list VPN dans ma police par défaut, le résultat s'affichera directement sous le context.

Le grand test !

Avec le navigateur de votre choix, accéder à votre WEBVpn via https. Ici l'adresse configurée est 212.49.64.2

Constat : le navigateur affiche une erreur de sécurité, il ne peut pas vérifier le certificat affiché par le routeur !

Nous entrons maintenant sur le portail en utilisant notre compte utilisateur sans droit créé précédemment.

Nous n'avons créer aucun bookmarck, ce sera pour un prochain topic. Néanmoins nous pouvons naviguer dans notre LAN. Mon serveur IIS a pour adresse 192.168.1.100, je tape celle-ci dans le champs URL. ET là, la magie du VPN opère : nous nous connectons sur notre serveur à travers le routeur, pour preuve, checker l'URL dans la barre de navigation !

Moui, c'est un peu petit pour voir l'URL : https://213.49.64.2/http:/0/192.168.1.100/

Bon clic à tous,