• Aucun résultat trouvé

Authentification AAA sur matériel Cisco

Dans le document Authentification centralisée (Page 13-27)

EXISTANT

Tout le matériel réseau de l’entreprise est de marque Cisco1 : celui-ci est très utilisé dans le monde professionnel, car de grande qualité. Avant mon arrivée, chaque matériel était configuré pour être administré par une connexion avec un seul utilisateur et un mot de passe : ceci pose différents problèmes :

 de sécurité (ancien personnel connaissant les mots de passe) ;

 de confidentialité (il est indispensable de divulguer ces mots de passe à quelques personnes de l’entreprise) ;

 de suivi (qui s’est connecté, et quand ?)

BESOIN

Parfois, l’équipe systèmes et réseaux a besoin de se connecter aux matériels d’interconnexion afin d’effectuer des modifications de configuration, ou toute autre opération de maintenance.

L’entreprise dispose d’un annuaire Active Directory : celui-ci permettrait de récupérer les comptes utilisateurs, et de vérifier quels droits a chacun sur le matériel réseau (par exemple technicien, ingénieur, etc.), et si cette personne a effectivement le droit de se connecter pour administrer le matériel.

Je vais étudier les différentes solutions possibles pour mettre une authentification comme celle-ci en place : ce type d’authentification porte le nom d’AAA2

Pour se faire, je vais donc orienter mes études sur trois possibilités : l’authentification via Cisco Secure Access Server, via un serveur Kerberos et via un serveur Radius.

Ces trois solutions sont, globalement, les seules méthodes permettant de mettre en place une politique AAA au sein d’une entreprise. Le protocole Radius semble le plus utilisé, mais il est possible que d’autres protocoles soient plus performants, ou offrent plus de possibilités. Je vais donc étudier ces différentes possibilités, afin de répondre au mieux au besoin.

1 Equipementier leader mondial de télécommunications

2 Authentication, Authorization and Accounting (authentification, autorisation et traçabilité)

J’étudierai également, pour le protocole retenu, quelle solution logicielle sera la plus opportune afin de mettre en place ces authentifications, en fonction principalement de critères :

 de coût ;

 d’adaptabilité (rajout de fonctionnalités dans le futur)

 de maintenance

 de configuration

Cette réflexion mènera à une solution complète d’authentification AAA pour les équipements Cisco, et sera, dans l’idéal, adaptative à d’autres besoins ultérieurs.

RECHERCHE

CISCO SECURE ACCESS SERVER

Cisco vend une solution appelée Cisco Secure Access Server, qui est une plateforme de contrôle d’accès, qui fonctionne sur plusieurs appareils :

 autorise la connexion des administrateurs de matériels ;

permet d’authentifier des utilisateurs VPN, d’accès distant ;

 authentifie des utilisateurs au niveau des connexions sans-fil et propose des sécurités spécifiques ;

 communique et audite les serveurs pour renforcer le contrôle d’admission.

Pour faire simple, Cisco Secure ACS permet de gérer l’accès aux ressources réseau pour une grande variété de types d’accès, matériels, et groupes utilisateurs. Etant donné qu’elle est développée par Cisco, cette solution est celle qui offrirait la plus grande flexibilité, et le plus grand nombre de possibilités pour l’administration des équipements.

Cependant, les prix pour une solution TACACS débutent à plus de 9000€. Pour des contraintes de coût, elle sera dans un premier temps écartée, le temps que les autres solutions puissent être étudiées en profondeur.

KERBEROS

PRÉSENTATION Kerberos est un protocole d’authentification créé au MIT3.

Il utilise des clés secrètes pour fonctionner, et remplace les mots de passe par des tickets, rendant plus difficile l’interception de ces mots de passe.

Son nom provient du nom grec de Cerbère, gardien des Enfers.

On pourrait faire une analogie de son fonctionnement avec le fonctionnement d’une billetterie de cinéma, se déroulant en 3 étapes :

1. Le client paye son ticket

2. A l’entrée, un employé du cinéma déchire le ticket et en garde la moitié

3. Si besoin, on peut vérifier que les deux morceaux vont ensemble et n’ont pas été falsifiés

Sa durée de vie est limitée (1 séance, généralement)

3 Massachussets Institute of Technology

FONCTIONNEMENT

FIGURE 3 : PROCESSUS D'AUTHENTIFICATION KERBEROS

Le serveur hébergeant l’AD utilise déjà Kerberos, puisque c’est le protocole utilisé nativement pour l’authentification des ordinateurs clients dans un domaine Microsoft. Il devrait donc être possible d’authentifier les matériels Cisco via cet AD, directement. De plus, les switchs, routeurs et firewalls Cisco sont compatibles Kerberos depuis IOS4 version 11.2

Cependant, le protocole Kerberos ne fournit que le service d’Authentification (qui permet de savoir si une personne a le droit de se connecter au matériel). Il faudra se tourner vers d’autres solutions pour mettre en place l’Autorisation (qui indique quels droits à la personne sur le matériel) et la Traçabilité (qui s’est connecté, quand, et sur quel équipement)

Pour des raisons de facilité de mise en œuvre, de limitation du nombre de protocoles utilisés et de limitations techniques et de maintenance, la mise en place de Kerberos sera malheureusement également écartée.

4 IOS : Système d’exploitation des matériels CISCO

RADIUS

PRÉSENTATION

LE PROTOCOLE RADIUS (REMOTE AUTHENTICATION DIAL-IN USER SERVICE) EST UN PROTOCOLE D’AUTHENTIFICATION STANDARD. LE FONCTIONNEMENT DE RADIUS EST BASÉ SUR UN SYSTÈME CLIENT/SERVEUR CHARGÉ DE DÉFINIR LES ACCÈS D’UTILISATEURS DISTANTS À UN RÉSEAU. […]. LE PROTOCOLE RADIUS REPOSE PRINCIPALEMENT SUR UN SERVEUR, RELIÉ À UNE BASE D’IDENTIFICATION COMME UNE BASE DE DONNÉES OU UN ANNUAIRE, ET UN CLIENT RADIUS, FAISANT OFFICE D’INTERMÉDIAIRE ENTRE L’UTILISATEUR FINAL ET LE SERVEUR.

L’ENSEMBLE DES TRANSACTIONS ENTRE LE CLIENT RADIUS ET LE SERVEUR EST CHIFFRÉ ET AUTHENTIFIÉ GRÂCE À UN SECRET PARTAGÉ. [1]

Le protocole RADIUS est implémenté dans IOS depuis la version 11.1

FONCTIONNEMENT

FIGURE 4 : FONCTIONNEMENT D'UNE ARCHITECTURE RADIUS SUR CONNEXION WIFI

Sur cette figure, on voit le déroulement d’une authentification par Radius, qui se déroule en 5 étapes :

1. PC-portable envoie à Borne-WiFi les identifiants et mot de passe de l’utilisateur qui désire se connecter au réseau ;

2. Borne-WiFi chiffre le mot de passe grâce au secret qu’il partage avec Serveur Radius, et transmet ces informations à celui-ci ;

3. Serveur Radius lit le mot de passe de l’utilisateur qu’il a dans sa base de données (l’administrateur est libre de choisir plusieurs méthodes de stockage des utilisateurs), chiffre celui-ci avec le secret partagé puis le compare avec celui envoyé par Borne-WiFi (c’est le principe d’irréversibilité du chiffrage, qui permet de chiffrer un mot de passe avec un secret partagé mais ne permet pas de le déchiffrer : le MD5 fonctionnera sur le même principe) ;

4. Serveur Radius renvoie sa réponse :

a. Access-Accept, s’il autorise la connexion b. Access-Reject, s’il refuse la connexion

c. il peut également renvoyer d’autres attributs, en fonction de sa configuration 5. Borne-Wifi reçoit la réponse de Serveur Radius, et accepte, ou non, l’utilisateur en

fonction de celle-ci.

Il est bien évidemment primordial que le secret partagé reste secret entre la borne et le serveur, car dans le cas contraire la sécurité des mots de passe risquerait d’être compromise.

PROTOCOLES ET SERVICES RENDUS

FIGURE 5 : TABLEAU DES MÉTHODES SUPPORTÉES PAR LES DIFFÉRENTS PROTOCOLES

La figure ci-dessus indique le support de chaque protocole au niveau des 3 méthodes (Authentification, Autorisation et Traçabilité), pour les matériels de type ASA principalement (les autres équipements ne supportant pas nécessairement tous ces protocoles).

Il est donc facile de remarquer que le TACACS+ (protocole de Cisco) est compatible avec tout, tandis que Kerberos est uniquement limité à l’Authentification.

Cependant, le protocole Radius tire son épingle du jeu avec quasiment toutes les méthodes supportées. Il ne reste que l’autorisation de l’administrateur, qui, via IOS, se contourne en utilisant un utilisateur fictif nommé $enabXX, où XX est remplacé par un nombre compris entre 1 et 15, et qui représente le niveau d’autorisation accordé : ainsi, on peut créer 15 niveaux d’autorisation différents, tous avec un mot de passe différent : malheureusement, il n’est pas possible d’affecter à un compte d’utilisateur un niveau d’autorisation, bien que le serveur Radius le permette et le prenne en charge : c’est une limitation du système de Cisco, IOS.

CHOIX FINAL DU PROTOCOLE

Après étude des principaux protocoles permettant l’authentification AAA sur un équipement Cisco, il ressort principalement 2 critères d’exclusion concernant les deux premiers :

Cisco Secure Access Server, et son protocole TACACS+, est écarté pour son coût trop élevé ;

Kerberos est écarté par sa limitation technique et sa complexité de mise en œuvre.

Il reste donc le protocole Radius, qui semble, lui, n’avoir aucun aspect négatif à son utilisation, notamment parce que :

il est sécurisé ;

il n’est pas lié à l’achat de serveurs spécifiques ;

il est très compatible, polyvalent, et semble pouvoir s’adapter à toute quantité de situations.

La partie suivante va donc faire un comparatif entre deux solutions mettant en œuvre le protocole Radius : NPS, le serveur Radius intégré à Windows Server 2008, et FreeRadius, solution libre la plus utilisée au monde5.

NPS, SERVEUR RADIUS DE MICROSOFT

WINDOWS SERVER

Windows Server est une marque, déposée par Microsoft, pour sa gamme de systèmes d’exploitation dédiée pour les serveurs.

Un serveur est une machine, parfois physique, parfois virtualisée (cf p. Error: Reference source not found : Error: Reference source not foundError: Reference source not found), destinée à rendre un service à un ou des clients, comme par exemple l’affichage d’un site web, le partage de données, etc.)

Tout serveur de type Windows Server est capable d’héberger un serveur NPS, qui fait office de serveur Radius : la dernière version sur le marché est la version 2008 R2, la suivante étant la version 2012, la précédente étant la version 2003. Généralement, les sorties de nouvelles versions de Windows Server coïncident avec une sortie d’un système pour le grand public :

 Windows server 2003 est sorti avec Windows XP ;

 Windows Server 2008 est sorti avec Windows Vista ;

 Windows Server 2012 sortira avec Windows 8, prévu pour le 26 octobre 2012.

5 voir http://freeradius.org/

CWF, parmi sa centaine de serveurs, migre progressivement ses anciens serveurs Windows Server 2003 vers des versions 2008, et n’installe de nouveaux serveurs qu’avec cette version. Cela permet à CWF d’être toujours à jour au niveau de sa sécurité et des fonctionnalités rendues.

Windows Server 2008 est décomposé en plusieurs versions, permettant plus ou moins de fonctionnalités, et à des tarifs différents, avec notamment, pour principales :

 Web Server ;

 Standard ;

 Enterprise ;

 Datacenter ;

 Foundation.

CWF installe principalement des versions Standard, moins coûteuses que les versions Enterprise, mais bien moins limitées que les versions Web Server, destinées uniquement pour l’hébergement de sites web.

NPS

NPS6 est le remplaçant, sous Windows Server 2008, d’IAS7, présent lui sur les systèmes Windows Server 2003.

Il a pour principale fonctionnalité de servir de serveur Radius, et peut servir également de proxy ou de sécurisation d’accès.

La version Standard de Windows Server 2008 limite à 50 le nombre de clients Radius (un client étant par exemple une borne WiFi, ou un équipement Cisco). Cependant, cette limite n’est pas clairement indiquée par le système : c’est en ajoutant le 51ème client qu’un message d’erreur assez peu explicite fait son apparition, empêchant l’ajout d’un client supplémentaire.

Une solution à cette limite existe, et elle consiste à passer sur une version supérieure de 2008 Server, par exemple la version Enterprise ou Datacenter, qui suppriment cette limite de clients. Cela a un coût, et s’il n’est pas possible de trouver une solution moins coûteuse, on la retiendra.

Cependant, une alternative semble possible avec Freeradius.

6 Network Policy Server

7 Internet Authentication Service

FREERADIUS AVEC AUTHENTIFICATION SUR LDAP

FreeRadius est une implémentation libre et gratuite du protocole RADIUS, qui permet donc d’ajouter à son réseau un serveur répondant aux besoins de l’AAA. Il est considéré comme étant le plus utilisé au monde des serveurs RADIUS. Il peut s’authentifier auprès de fichiers texte, d’une base SQL, d’un annuaire LDAP, d’une base SQL, et auprès de bien d‘autres services par le biais de modules supplémentaires. Ici, on montrera l’authentification auprès d’un annuaire LDAP, qui stocke déjà actuellement des utilisateurs : cette solution a été retenue pour sa simplicité d’usage : en effet, il apparaîtrait trivial de récupérer la liste d’utilisateurs à intervalles réguliers, afin d’alimenter une seconde base, et d’obtenir une architecture soumise à beaucoup de risques :

 de synchronisation ;

 d’incompréhension (utilité d’avoir un réplica de la première base ?) ;

 de lourdeur (doublement des données).

Le choix de Freeradius s’est imposé parce que c’est une référence dans le domaine de l’authentification Radius, et que, de plus, il permet de conserver des coûts très limités (au vu de la licence libre et gratuite)

LDAP est protocole devenu un standard permettant l’interrogation et la modification des services d’annuaire, reposant sur TCP/IP. On peut trouver des annuaires compatibles LDAP sur toutes les plateformes, comme par exemple OpenLDAP sur un système GNU/Linux ou Active Directory sur un système Microsoft (Microsoft ayant ajouté des couches supplémentaires à son annuaire).

FONCTIONNEMENT

Dans la configuration de FreeRadius, il va falloir lui spécifier plusieurs renseignements, tels que le schéma de l’annuaire, son adresse, ainsi que le mot de passe de l’administrateur de celui-ci (cette obligation est due à Windows Server, qui n’autorise pas la connexion anonyme sur son annuaire). A chaque requête, notre serveur Radius va donc aller effectuer une requête auprès de la fonctionnalité LDAP de l’Active Directory, et celui-ci répondra si l’utilisateur est autorisé ou pas à se connecter.

Cependant, une seule configuration est envisageable : en effet, le module est configuré de telle sorte qu’il aille chercher, par exemple, les utilisateurs dans l’unité Personnes de l’annuaire : que se passe-t-il si, dans le futur, nous désirons rajouter une nouvelle fonctionnalité utilisant l’authentification Radius, telle que, par exemple, une authentification des clients sans-fil au sein de l’entreprise ?

La réponse est simple : il ne sera pas possible de cumuler les deux avec deux configurations différentes. On ne pourra par exemple pas authentifier une machine, il faudra obligatoirement authentifier un utilisateur, qui sera dans l’unité Personnes de l’annuaire, et qui enverra son mot de passe d’une manière non chiffrée (donc non sécurisée).

Dans le cadre d’un serveur voué à n’accueillir qu’un seul service d’authentification, cela pourrait suffire, mais l’entreprise étant en perpétuelle évolution, cette configuration n’est pas envisageable.

Dans la partie suivante, nous verrons qu’il est possible d’utiliser FreeRadius en tant que proxy, et les conséquences de ceci.

CONFIGURATION DE FREERADIUS EN TANT QUE PROXY Nous nous retrouvons donc avec, globalement, 2 contraintes :

 le coût d’une licence Enterprise, ou la limite à 50 clients Radius sur la version Standard de Windows Server 2008.

les problèmes de configurations multiples d’une authentification FreeRadius sur LDAP.

Serait-il possible, par exemple, d’obtenir les fonctionnalités de NPS, avec autant de clients que l’on souhaite, sans changer de licence et sans dépasser le nombre de 50 clients ?

INTRODUCTION AU FONCTIONNEMENT D’UN PROXY

Un serveur proxy est un serveur qui va servir d’intermédiaire entre un client et un autre serveur, en se faisant passer pour le client auprès de l’autre serveur. Généralement, ce système de proxy est utilisé afin d’augmenter la sécurité du parc informatique, ou d’augmenter les performances d’un réseau local, parce qu’il peut être associé de plusieurs services, tels que, dans l’exemple d’un proxy web (le plus couramment rencontré) :

 un service de cache (les éléments fréquemment demandés sont stockés en local) ;

 un service antiviral (les retours de requêtes vont être scannés) ;

un service de sécurité (certaines requêtes vont être autorisées, d’autres non).

FIGURE 6 : FONCTIONNEMENT D'UN PROXY

Cette figure illustre parfaitement le fonctionnement d’un proxy : à gauche se situe le réseau local, composé de machines clientes, et qui envoient toutes leurs requêtes vers la machine faisant office de proxy. Celle-ci contacte les serveurs Internet avec les requêtes des clients, en se faisant donc passer pour eux (en réalité, le serveur sur Internet croira que toutes les requêtes viennent de la même machine, qui est donc le serveur proxy), et répond aux clients en se faisant passer pour les serveurs présents sur Internet : le fonctionnement est donc totalement transparent pour les clients, qui, selon la configuration, peuvent ne pas s’apercevoir qu’ils passent au travers d’un proxy.

MISE EN PLACE ET CONFIGURATION

Une solution de proxy via Freeradius a été imaginée, et a semblé pertinente, à la fois pour des raisons de simplicité de et maintenance : en effet, Freeradius supporte, à l’instar des licences Enterprise et Datacenter de Windows Server, l’ajout de sous-réseaux en tant que clients. Cela permet donc d’ajouter très simplement un nombre important de clients, sans devoir les ajouter un par un, comme c’est le cas sur Windows Server Standard. De plus, l’aspect gratuit de la solution a joué dans la décision finale, ainsi que mon intérêt personnel pour les solutions open-source.

La configuration est assez simple, et fonctionnera sur tout mécanisme d’authentification choisi : en effet, le Freeradius n’agira qu’en tant que proxy, ce qui signifie qu’il ne fera que transférer les requêtes vers le serveur Windows Server, qui lui, n’aura donc qu’un seul client configuré.

Il suffira de spécifier dans les modules à activer de n’activer qu’IPASS, et de configurer les royaumes (REALMS) dans son fichier de configuration.

Le module détectera ensuite, selon qu’un nom de domaine soit indiqué ou non dans chaque requête : exemple OLIVIER\Administrateur, ou EPSI\utilisateur, le serveur vers lequel il doit

renvoyer cette requête afin qu’elle soit traitée. Il est possible de ne travailler qu’avec un serveur, ou bien, si l’on dispose de plusieurs royaumes, de définir un serveur pour chacun. Une fois le résultat reçu, le module retransmettra le résultat reçu au client.

FIGURE 7 : TOPOLOGIE DU RÉSEAU AVEC PROXY RADIUS

Sur cette figure, Switch0 et Switch1 servent d’interconnexion aux différents matériels possibles : ceux-ci sont administrables, et une configuration Radius leur sera appliquée.

Switch2 n’est présent que pour montrer qu’il est également possible de configurer des équipements

« esseulés », pouvant représenter n’importe quel équipement réseau.

Les PC portables se connecteront via une authentification Radius également, le proxy recevant donc toutes les connexions des machines et équipements et redirige tous ces flux vers le serveur Radius final, sans faire de distinction entre les différentes méthodes d’authentification (EAP, PEAP, LEAP, MsCHAP …).

Le serveur final, fonctionnant avec Windows Server, saura faire la distinction et appliquer la bonne procédure définie à chaque protocole d’authentification.

CONCLUSION QUANT À LA CONFIGURATION DE FREERADIUS

La configuration de Freeradius avec authentification via LDAP implique que le mot de passe de l’administrateur soit rentré dans un fichier de configuration : cela peut poser des problèmes de

sécurité. De plus, nous rencontrerons des problèmes lorsqu’une autre architecture va être installée sur l’infrastructure, notamment une authentification via Radius des clients WiFi.

En effet, la configuration effectuée dans le cas d’une authentification par LDAP est spécifique à un type de connexion, et toute requête arrivant au serveur sera traitée de la même manière par le module LDAP.

Ainsi, il faudra jongler, au niveau de l’AD, à détecter de quel endroit provient chaque requête, et adapter en conséquence : la maintenance en devient rapidement trop complexe.

Il ne sera donc pas idéal de devoir gérer au niveau de l’AD ces différentes requêtes. Pour cette raison, l’utilisation du module LDAP de Freeradius sera abandonnée, malgré sa simplicité d’usage et ses possibilités offertes. La configuration de Freeradius en tant que proxy apparaît la solution la plus stable, la moins coûteuse, et la plus maintenable possible.

Dans le document Authentification centralisée (Page 13-27)

Documents relatifs