Protocoles utilisant des mécanismes d'authentification: TACACS+, RADIUS et Kerberos

Transcription

1 Sécurisation des systèmes Protocoles utilisant des mécanismes d'authentification: TACACS+, RADIUS et Kerberos Tarik BOUDJEMAA Sadek YAHIAOUI Master 2 Professionnel STIC Informatique Sécurisation des systèmes

2 L'authentification L'authentification est la procédure qui consiste, pour un système informatique, à vérifier l'identité d'une entité (personne, ordinateur...), afin d'autoriser l'accès de cette entité à des ressources (systèmes, réseaux, applications...). Qu'est ce que l'authentification réseau Il s'agit d'authentifier une machine lorsqu'elle se branche sur le réseau Afin de lui autoriser ou refuser l'usage du réseau. 2

3 L'authentification Pourquoi faire de l authentification réseau? Sécuriser un réseau Pour éviter une utilisation illicite du réseau par des «inconnus» Pour interdire les postes inconnus Pour donner des autorisation spécifiques sur le réseau (vlan,application, ) Pour savoir quelle machine est connectée et où elle est connectée 3

4 TACACS+ RADIUS KERBEROS 4

5 TACACS+ TACACS+ (Terminal Access Controller Access Control System Plus) protocole de sécurité inventé dans la fin des années 90 par CISCO Systems. il a fini par remplacer les protocoles TACACS et XTACACS, TACACS+ n est pas basé sur ces derniers TACACS+ est un serveur d authentification permettant de centraliser les autorisations d accès (Les mots de passe utilisés sont gérés dans une base de données centrale ) TACACS+ permet de vérifier l identité des utilisateurs distants mais aussi, grâce au modèle AAA, d autoriser et de contrôler leurs actions au sein du réseau local. 5

6 TACACS+ : AAA TACACS+ se base sur le framework AAA qui signifie : Authentication(authentification) Authorization(autorisation) Accounting(Comptabilisation) Cette séparation permet une modularité au niveau des technologies utilisées pour chaque fonction. On peut par exemple grâce à ce principe choisir RADIUS pour l authentification et TACACS+ pour le reste des fonctions. 6

7 TACACS+ : AAA Authentification (authentication) Mécanisme permettant la détermination de l identité de l utilisateur. Cette opération peut se faire de différentes façons : En utilisant ce que l utilisateur sait (mot de passe, code PIN etc.) En utilisant ce que l utilisateur possède (Carte à puce, clé d authentification) En utilisant ce qui constitue physiquement un utilisateur (Biométrie) 7

8 TACACS+ : AAA Autorisation (authorization) Permet de déterminer ce que l utilisateur a le droit de faire, le type de service ou de ressource qu il peut utiliser. Autorisation (authorization) Permet de savoir les actions faites par l utilisateur depuis l authentification jusqu'à la fin de sa session dans le système Il est généralement utilisé pour la génération d audits et de rapports dans une optique de sécurité 8

9 TACACS+ : Les acteurs 3 Acteurs L'utilisateur : émetteur de la requête d'authentification ( poste de travail, un portable, un PDA ) Le client TACACS+:le point d'accès au réseau Le serveur TACACS+: relié à une base d'authentification (Base de données, annuaire LDAP) 9

10 TACACS+ : Architecture d un utilisateur distant souhaitant se connecter à son réseau d entreprise par une connexion point à point L utilisateur distant se connecte grâce à son modem au Serveur d accès de son entreprise Le serveur d accès va, par la suite interroger, le serveur TACACS+ afin de déterminer : la validité de l utilisateur (authentification) les services auquel il a droit (autorisation) et de contrôler ses actions à l intérieur du réseau C est donc le serveur d accès qui va agir en tant que Client TACACS+ et communiquer les informations au serveur TACACS+ 10

11 TACACS+ : Architecture cas d un utilisateur WIFI souhaitant se connecter à son réseau local d entreprise. l utilisateur «wifi» se connecte à son point d accès qui va jouer le rôle de client TACACS+ auprès du serveur. 11

12 TACACS+ : Architecture Cas d un utilisateur itinérant souhaitant se connecter à réseau d entreprise à distance en utilisant un canal VPN L utilisateur se connecte ici en VPN par Internet au serveur d accès de son entreprise qui jouera le rôle de client TACACS+. Cas de l administration d un matériel CISCO lorsque l utilisateur se connecte et saisit ses informations d authentification sur le matériel CISCO, ce dernier interroge le serveur TACACS+ afin de l identifier. 12

13 TACACS+ : Fonctionnement Description d'un paquet TACACS+ TACACS+ utilise pour communiquer le port TCP (port 49) La taille d une entête d un paquet TACACS+ est de 12 Octet Format d un paquet TACACS+ : Major version : donne le Numéro de la version Majeure de TACACS+ Minor version : donne le Numéro de la version Mineure de TACAS+ 13

14 TACACS+ : Fonctionnement Type : définit s il s agit d un paquet d authentification, d autorisation, ou de comptabilisation (conformément au AAA) Seq_no : numéro de séquence s incrémentant de 1 pour chaque paquet envoyé lors d une session. Flags : différents drapeaux permettant entre autre de crypter le paquet entier grâce à l algorithme MD5. Length : taille du paquet. Nous allons détailler le fonctionnement de TACACS + pour chaque fonction AAA : 14

15 TACACS+ : Authentification La phase d authentification peut supporter plusieurs protocoles comme des techniques de type RAP ou encore CHAP le client envoie un paquet «START» au serveur TACACS+ des paires de message de type REQUEST/REPONSE contenant des paires <attributs valeur> seront échangés Par exemple il peut envoyer un prompt au client pour lui permettre de fournir les informations sur le nom d utilisateur, ainsi que son mot de passe. serveur TACACS+ vérifie et envoie dans un paquet «REPLY» sa réponse 15

16 TACACS+ : Autorisation Quand un utilisateur demande l utilisation d un service particulier, il passe par l intermédiaire du client TACACS+ qui envoie un paquet «REQUEST» Ce paquet comprend des arguments de types «attributs valeurs» qui permette de définir les commandes qui doivent être exécutés Exemple : si l utilisateur veut utiliser le protocole FTP, le client TACACS+ enverra comme argument protocol = «ftp». serveur TACACS+ vérifie dans sa base et envoie dans un paquet «RESPONSE» sa réponse 16

17 TACACS+ : Comptabilisation Lors d une action de l utilisateur, le client TACACS+ envoie un paquet «REQUEST» comprenant toujours des arguments «attributs valeurs» qui permettent, entre autres, de savoir le début, la fin et le type d action exécuté par l utilisateur. Le serveur TACACS+ enregistre alors les informations dans sa base et renvoie un paquet «RESPONSE» avec le résultat de l enregistrement (échec ou succès). 17

18 TACACS+ : Exemple d une session TACACS+ 18

19 Protocoles TACACS+ RADIUS KERBEROS 19

20 RADIUS Remote Authentication Dial In User Service RADIUS est un mécanisme de transport des données d'authentification Un moyen pour les FAI de centraliser leurs bases de données utilisateurs Protocole de type AAA (Authentication Authorization Accounting ) Dernière version du protocole RADIUS normalisée par l'ietf dans la RFC

21 Protocoles utilisant des mécanismes d'authentification: TACACS+, RADIUS, KERBEROS et FORTEZZA RADIUS : Mode opératoire type 3 Acteurs L'utilisateur : émetteur de la requête d'authentification ( poste de travail, un portable, un PDA ) Le client RADIUS:le point d'accès au réseau (NAS, firewall, point d'accès wireless, etc...) Le serveur RADIUS: relié à une base d'authentification (Base de données, annuaire LDAP) 21

22 RADIUS : Mode opératoire type l'utilisateur émet une requête d'authentification auprès du client RADIUS Protocole comme PPP ou Telnet Le client radius demande à l'utilisateur ses informations d'authentification ( user name, password ) Dans le cas de PPP : il utilise les informations déjà présentes dans le paquet Le client transmet la requête au serveur Radius Requête de type Access Request : (de manière sécurisée) Le serveur Radius retourne l une des réponses suivantes Access Accept : Acceptation la requête du client Access Reject : pour spécifier au client que sa requête est rejetée. 22

23 RADIUS : Mode opératoire type L'authentification mode Challenge RADIUS peut utiliser un mode Challenge En fonction de la zone d accès demandée et des droits de l utilisateur, le serveur RADIUS peut exiger des informations supplémentaires pour l authentification. Réponse: Access CHALLENGE :éviter de transmettre le mot de passe. Le client envoie alors une autre requête répondant au Challenge pour s'authentifier 23

24 RADIUS : Couche de transport RADIUS utilise le protocole UDP sur le port 1812 La surcharge induite par une session TCP n'est pas justifiée La retransmission TCP est adaptée au transfert de données, pas à l'authentification Il permet d'utiliser de façon transparente un autre serveur en cas d'indisponibilité 24

25 RADIUS : Implémentations Plusieurs implémentations du protocole RADIUS sont disponibles Versions commerciales NPS (Network Policy Server) pour Windows Server Vista, IAS pour Windows Serveur 2000/2003 Versions libres Cistron Radius, Livingston Radius et FreeRadius, OpenRadius 25

26 RADIUS :Paquets RADIUS Encapsulé dans un datagramme UDP Format : Code 1 Access Request 2 Access Accept 3 Access Request 4 Accounting Request 5 Accounting Response 11 Access Challenge 12 Status Server (expérimental) 13 Status Client (expérimental) 255 Reserved Identifier Pour correspondre les requêtes et leurs réponses Nombre que le client incrément à chaque requête. Longueur Longueur totale du paquet, en incluant les attributs Longueur minimale 20 octets,maximale 4096 octets 26

27 RADIUS :Paquets RADIUS Authentificateur Request Authenticator :requêtes du client Nombre aléatoire de 16 octets Response Authenticator :réponses du serveur utilisé pour authentifié la réponse du serveur ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret). Le client est alors en mesure de vérifier que le serveur qui répond est bien celui qu'il a contacté. Attributs et valeurs Ensemble d'attributs et leur valeur qui indique quels services sont demandés ou autorisés. 27

28 RADIUS : Les attributs RADIUS Richesse des informations qui peuvent être transmises entre le serveur et le client Informations appelées attributs ils permettent au client de communiquer des informations au serveur (password, MAC adresse ) ils permettent au serveur de communiquer les paramètres des autorisations qu'il délivre (vlan ) ou bien demander des informations complémentaires. Inclus à la fin d'un paquet RADIUS, selon un format Type, Longueur, Valeur (TLV). 28

29 RADIUS : Les attributs RADIUS Type Définit le rôle de l'attribut Les attributs qui doivent ou peuvent être inclus dans un paquet dépendent du type de ce paquet Exemple, un paquet Access Request doit contenir les attributs User Name et User Password, mais d'autres peuvent être inclus, comme l'attribut Callback Number qui précise le numéro de téléphone à rappeler. Longueur Valeur longueur totale de l'attribut, incluant le type, la longueur et la valeur. Peut être une chaîne de caractères, données binaires, entier sur 32 bits, adresse IP sur 32 bits,une valeur de temps sur 32 bits. Les attributs Vendor Specific définissent leurs propres types de données. 29

30 RADIUS : les attributs Radius Attributs Standards Called Station Id Contient l'adresse MAC de l'équipement NAS Calling Station Id Contient l'adresse MAC de la machine de l'utilisateur. NAS IP Address Adresse IP de l'équipement NAS NAS Port Port sur lequel est connecté le supplicant User Name Chaque attribut possède un numéro d'identification. User Password Seul ce numéro est transmis dans les paquets. La correspondance entre le nom de l'attribut, son numéro et son type est réalisé dans un dictionnaire. 30

31 RADIUS : les attributs Radius Attributs Vendor Les fabricant de matériel réseau (NAS) ont parfois intégré à leurs équipements des attributs spécifiques en plus des attributs standards définis dans le RFC. Ces attributs sont encapsulés dans l'attribut standard vendor specific qui a pour numero 26. Ils sont appelés VSA = Vendor Specific Attribut Vendor ID N d'immatriculation du fabricant Attribut number Comme pour les attributs standards, les vendor attributs possèdent un numéro d'identification. Ce numéro est répertorié dans un dictionnaire spécifique au fabricant. Longueur Valeur 31

32 RADIUS : Sécurité Secret partagé Élément principal de la sécurité RADIUS entre le client et le serveur Secret partagé différent peut être défini pour chaque client Possibilité d'avoir un secret unique pour tous les clients (plus pratique mais moins sécurisé Ce secret peut être de n'importe quelle longueur, mais il est mieux d'avoir un secret d'au moins 16 caractères et d'une bonne complexité Le secret est utilisé pour vérifier l'authenticité du serveur: MD5(Code +ID+Length+RequestAuth+Attributes+Secret). Le secret est aussi utilisé par le client pour encrypter le mot de passe envoyé pour l'authentification Pour éviter évite le sniffing du mot de passe Mot de passe encrypté en tant que hash MD5 du secret avec le Request Authenticator, le tout combiné par un xor avec le mot de passe. 32

33 RADIUS : Faiblesses Sécurité relative reposant sur le secret partagé. Certaines implémentations clientes limitent en plus sa taille. Possibilité de trouver le secret en utilisant une attaque brute force ou par dictionnaire en interceptant à la fois le Access Request envoyé par le client et la réponse du serveur. Chiffrement de l attribut User password par une fonction de hashage MD5, plutôt réservé pour des opérations de signature. Rejeu des réponses du serveur est possible Si le client envoie des requêtes utilisant le même Request Authenticator que dans une requête précédemment interceptée avec sa réponse C'est susceptible de se produire si l'implémentation du client n'utilise pas une valeur aléatoire comme recommandée dans la norme 33

34 Protocoles RADIUS TACACS+ KERBEROS 34

35 Kerberos Kerberos est apparu au milieu des années 1980 au cours du projet Athena du MIT Standardisé par l IETF Buts Fournir un accès réseau à plusieurs milliers de stations de travail Décharger les serveurs d'applications présents sur le réseau de la gestion de l'authentification Sécuriser un échange sur un réseau non sécurisé Afin de garantir la confidentialité et l'intégrité des données, toutes les communications qui transitent par le serveur Kerberos sont chiffrées avec le système DES. 35

36 Kerberos Afin de réaliser correctement l'authentification des différents principaux(un principal est une entité présente sur le réseau définit par un identifiant unique ), le protocole Kerberos fais appel à 3 acteurs différents Le client : Utilisateur ou programme ayant besoin d'un service (ftp, mail, web, etc) fourni par un serveur distant.. Le serveur d'application : Il fourni le service demandé par le client après que celui ci se soit authentifié. Le serveur de distribution des clés KDC (Key Distribution Center ) : Il permet l'authentification de tous les clients sur le réseau dont il a la responsabilité Kerberos se décompose en trois sous protocoles Service d'authentification : permet d'authentifier les clients Le service de délivrement de TGS : permet de fournir l'authentification auprès des serveurs d'application Service d'authentification Client / Serveur qui permet d'établir une communication sécurisée entre le client et le serveur d'applications 36

37 Kerberos : système à tickets L authentification Kerberos repose sur le principe que chaque client d'un réseau donné doit s'identifier sur un serveur global Le client doit présenter au serveur un ticket d'authentification que lui a préalablement fourni ce dernier Tout client muni de ce ticket est considéré comme authentifié Sécurisation du réseau puisque aucune données d'authentification non chiffrée ne circule sur celui ci 37

38 Kerberos : Fonctionnement du service de ticket L utilisateur tente d'accéder à un service fourni par un serveur distant nécessitant une authentification un serveur web ou ftp par exemple Le client envoie une requête d'authentification au KDC (serveur kerberos) Si le client réussi à s'authentifier auprès du serveur KDC Le serveur lui renvoie un ticket lui permettant d'accéder au service demandé Le client se présente au serveur d'application avec le ticket d'authentification Le serveur d application fournit au client le service demandé Le serveur d'application ne peut en aucun cas contredire une décision prise par le serveur d'authentification Ce système nécessite donc une confiance absolue envers le serveur Kerberos. 38

39 Kerberos : Le KDC Le KDC est basé sur deux entités Le serveur d authentification (AS: Authentication Server) : prend en charge la partie authentification du client. Permet au client de communiquer au TGS (grâce à un ticket d accès). Le serveur de distribution de tickets (TGS : Ticket Granting Server) prend en charge les demandes d accès aux services des clients déjà authentifiés L ensemble des infrastructures du serveur Kerberos AS et TGS est appelé le centre de distribution de clés (KDC : Key Distribution Center). Ils sont généralement regroupés sur le même serveur. 39

40 Kerberos : Mécanismes d authentification Le client a sa propre clé privée Kc Le serveur a sa propre clé privée Ks. Le TGS a sa propre clé privée Ktgs et connaît la clé privée du serveur Ks L AS connaît les clés privées du client et du TGS. Le TGS et AS sont deux entités normalement de confiance. 40

41 Kerberos : Mécanismes d authentification Le client désir accéder au serveur pour obtenir un service. ( Application Server). 1. AS_REQ : le client s identifie auprès de l AS à l aide d un mot de passe 2. L AS vérifie dans sa base que le client existe. Il génère une clé de session Kc,tgs, il envoie au client AS_REP Une clé de session Kc,tgs chiffrée avec Kc, qui fera office de mot de passe temporaire pour chiffrer les communications suivantes. Un ticket d'accès T1 au service de délivrement de ticket, chiffré avec Ktgs,Il contient notamment l heure de l opération, sa durée de validité, l adresse de la machine cliente ainsi que la clé de session Kc,tgs 41

42 Kerberos : Mécanismes d authentification 3. TGS_REQ : le client fait une demande de ticket auprès du TGS. Le ticket d accès T1 que l AS lui avait donné. Un identifiant contenant des informations sur le client avec la date d émission, chiffrées avec la clé de session Kc,tgs 42

43 Kerberos : Mécanismes d authentification 4. Le TGS : Déchiffre avec sa clé, le ticket d accès T1. Il obtient la clé de session Kc,tgs. Le TGS est maintenant certain que le client a bien obtenu le T1 de l AS. Déchiffre alors les informations que le client avait précédemment chiffré avec la clé de session. Il vérifie que la durée de validité est correcte. Puis le TGS envoie au client TGS_REP qui comprend Un ticket T2 pour accéder au serveur d application. Il est chiffré avec la clé privé de ce serveur Ks Une seconde clé de session Kc,s pour les communications entre le serveur final et le client. Cette clé a été chiffrée avec la clé initiale Kc,tgs. 43

44 Kerberos : Mécanismes d authentification 5. Le client déchiffre la seconde clé de session Kc,s avec Kc,tgs Il envoie AP_REQ au serveur d application Un nouvel identifiant chiffré avec Kc,s Le ticket d accès T2 6. Le serveur d application vérifie que le ticket est valide en déchiffrant T2 avec Ks. Il obtient Kc,s. Le serveur vérifie la cohérence entre les deux informations.(exemple:demande conforme à ce qui est autorisé par le ticket.) Une réponse positive ou négative AP_REP est envoyée au client. 44

45 Kerberos : Points forts Le transit des mots de passe sur le réseau est chiffré. Il permet aux utilisateurs de s authentifier une fois pour toutes lors du login. Séparation des rôles : l AS et le TGT. C est la base de Kerberos. Mais dans la réalité, ces deux rôles sont regroupés en une même entité (KDC). Impossible de rejouer un échange deux fois de la même manière (grâce au timestamps). 45

46 Kerberos : Points faibles Le chiffrement symétrique nécessite un partage des clés entre l AS et le client. Les horloges doivent être parfaitement synchronisées : en effet, l antirejeu s appuie sur le «timestamps». L authentification mutuelle n est pas disponible lors du premier échange entre l AS et le client. Le client ne peut pas certifier que l AS et bien celui qu il prétend être. 46