Sécurité des systèmes d’exploitation et du logiciel

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Discretionary Access Control (DAC)

• Exemple : contrôle d’accès aux fichiers dans Unix

•

Contrôle d’accès discrétionnaire – Suppose que l’on puisse définir un propriétaire pour chaque ressource – Ne satisfait pas le « principe du moindre privilège » : un utilisateur peut

transmettre plus de droits que nécessaire à un autre utilisateur

05/11/2014

LAABIDI Mounira

17

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Discretionary Access Control (DAC)

• Contrôle d’accès discrétionnaire

– Un droit d’accès peut être transmis sans que son propriétaire soit informé: A

donne un droit en lecture à B sur un de ses fichiers, B copie ce fichier, B étant propriétaire de la copie, transmet son droit de lecture à C

 A doit faire confiance à B • La confiance ne suffit pas :

– A possède un fichier sensible, B n’est pas autorisé à le lire – B implémente un cheval de Troie, et réussit à convaincre A de l’utiliser – Si A exécute le programme, le programme acquiert les droits de A le temps de l’exécution, et peut copier le fichier sensible dans un fichier auquel B a accès

• En résumé, le contrôle d’accès discrétionnaire

– Permet de limiter l’accès d’utilisateurs honnêtes et d’éviter l’altération

d’information.

– N’est pas adapté au contexte où l’information est très sensible.

05/11/2014

LAABIDI Mounira

18

Mandatory Access Control (MAC)

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

 Contrôle d’accès obligatoire/par mandats  Objectif :

 Contrôler la diffusion de l’information même si les applications

ne sont pas de confiance.

 Assurer le cloisonnement des informations.

 Principes :

 Basé sur le contenu, i.e. la sensibilité de l’information.  Un niveau de sensibilité (label) est attribué aux objets.  Un utilisateur doit obtenir un « mandat » (une autorisation)

pour accéder à une information sensible.

 Seule l’organisation a le pouvoir de donner des droits.

 Dans la pratique :

 Modèle le plus répandu : multi-niveau sécurisé dans le domaine de la

défense.

 Modèle de Bell LaPadula.

05/11/2014

LAABIDI Mounira

19

Role Based Access Control (RBAC)

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

 Contrôle non centré sur les notions de sujets/objets  Basé sur les rôles (RBAC) : l’accès à un objet est accepté/refusé non pas en fonction du sujet mais de son rôle (exemple sa fonction dans l’entreprise)(Peut être implémenté avec des privilèges)

Sujets

Rôles Opérations

 Contrôlé par l’origine : le sujet qui a créé l’objet (ou l’information qu’il contient) peut contrôler la dissémination de l’information

 Orienté Tâches (TBAC) : autorisation à différents points durant la

complétion d’une tâche (« workflow management »)

05/11/2014

LAABIDI Mounira

20

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

EXERCICE

Classifier chacune des politiques de sécurité suivantes selon son type de contrôle d’accès

1. Les mécanismes de contrôle d’accès des fichiers Unix,

2. Une politique d’une organisation militaire dans laquelle généraux peuvent entrer dans une salle

les

seuls particulière,

3. Une politique d’une université dans laquelle il est stipulé que l’accès au registre d’un étudiant par un professeur (dans lequel un professeur de l’université peut consulter les notes de l’étudiant) est permis si l’étudiant en question a donné une autorisation écrite au professeur (le professeur ne pouvant les diffuser à un tiers).

05/11/2014

LAABIDI Mounira

21

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Modèles de contrôle d’accès

Bell LaPadula

 HRU

Domain and type

enforcement

RBAC

05/11/2014

LAABIDI Mounira

22

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Contrôle d’accès multi-niveaux

 Pour certaines politiques de sécurité, il est nécessaire de

considérer différents « niveaux » de sécurité

 Niveaux de sécurité

– Niv: ensemble des niveaux : les objets sont classifiés en fonction de

leur sensibilité :

– Exemples

Niv est complètement ordonné, T>S>C>NC et R>Prop>Sens>Pub

05/11/2014

LAABIDI Mounira

23

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Catégories de sécurité

 Cat : ensemble des catégories, permet de partitionner les

objets de manière non hiérarchique – Principe du besoin d’en savoir (« need to know ») : l’information n’est

transférée qu’aux sujets qui en ont besoin

– Exemples

– Ensemble non ordonné – Les parties de Cat sont partiellement ordonnées par ⊆

05/11/2014

LAABIDI Mounira

24

24

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Labels de sécurité

• L’ensemble des labels de sécurité : LS=Niv×P(Cat) • Exemple de label : (T,{US,EUR}) • Relation d’ordre partielle induite : dom (« domine »)

(niv1,ens_cat1) dom (niv2,ens_cat2) ssi niv1 ≥ niv2 et ens_cat2 ⊆ ens_cat1

• Exemple : (T,{US,EUR}) dom (S,{US})

– (LS,dom) est un treillis (dom est une relation d’ordre partielle et il existe

une borne inf et une borne sup pour chaque couple (l1,l2) de LS)

• Exercice : construire le treillis pour Niv={C,S} et Cat={US,EUR}

05/11/2014

LAABIDI Mounira

25

25

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Treillis des labels de sécurité

• Le treillis pour Niv={C,S} et Cat={US,EUR}

05/11/2014

LAABIDI Mounira

26

26

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Modèles de contrôles d’accès

 Un modèle de contrôle d’accès est une représentation abstraite partielle d’une classe de politiques de sécurité exprimée de manière plus ou moins formelle :

 Formule précisément les règles de la politique  Explicite comment le système réalise, autorise ou interdit  Abstrait des détails, se focalise sur une propriété spécifique ou un

comportement donné

 Intérêts :

 Donne des fondements théoriques au contrôle d’accès ou de

flux d’information

 Formalise des principes informels de sécurité comme le principe

de la séparation des fonctions, la séparation des tâches …

 Permet de prouver des propriétés sur une politique de sécurité

(détection de conflits, ...)

 Nécessaire dans le cadre d’un processus d’évaluation de la sécurité (Critères Communs, certification niveau EAL5)

05/11/2014

LAABIDI Mounira

27

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Modèles de contrôles d’accès  Modèles pour la confidentialité : assurent la non-divulgation

d’information

 Modèle de Bell La Padula (BLP)  Application : modélisation d’OS

 Modèles pour l’intégrité : assurent la non modification/

falsification de données:  Modèle de Biba  Application : sécurisation de bases de données

 Modèles spécifiques à un domaine:

 « Muraille de chine » (Brewer & Nash)  Modèle de sécurité « commercial » (plutôt intégrité, exemple Clark

& Wilson)

 Modèles hybrides:

 Contrôle d’accès basé sur des rôles (RBAC)

 Modèles pour la disponibilité

05/11/2014

LAABIDI Mounira

28

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Modèle Bell-Lapadula

 Historique:

 BLP : modèle basé sur une machine à état conçu au MITRE  Un des modèles de sécurité les plus influents depuis 30 ans

 Caractéristiques

 Capture les aspects confidentialité du contrôle d’accès  Modèle multi-niveaux : l’information ne peut circuler d’un

niveau donné à un niveau inférieur  BLP et Matrice de contrôle d’accès :

• BLP utilise une matrice de contrôle d’accès pour décrire

les contrôles d’accès discrétionnaires

05/11/2014

LAABIDI Mounira

29

Modèle Bell-Lapadula

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

 Date des années 70, modèle de sécurité sur la confidentialité

des flux de données.

 Pour système multi niveau (top secret, secret, confidentiel,

non classifié) ; utilise des labels.

 Objectif principal : empêcher que des infos secrètes puissent

être accédées de manière non autorisée.

 Modèle pour lequel il est prouvé mathématiquement qu’il empêche les données d’un niveau de sécurité supérieur de fuir vers un niveau de sécurité inférieur.

05/11/2014

LAABIDI Mounira

30

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Modèle Bell-Lapadula

 Principe :

 Un sujet d’un niveau donné ne peut pas lire des données d’un

niveau supérieur.

 Un sujet d’un niveau donné ne peut pas écrire des données dans

un niveau inférieur.

 Un sujet qui a le droit d’écrire et de lire ne peut le faire qu’à son

niveau (rien au dessus, rien en dessous)

05/11/2014

LAABIDI Mounira

31

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Modèle Bell-Lapadula

 BLP a joué un rôle important dans la conception d’OS

sécurisés

 Unix System V/MLS (AT&T, 1984), Purple Penelope (DERA,

1998).

 Inconvénients:

 Traite uniquement de confidentialité, pas d’intégrité  Ne prend pas en compte la gestion des droits d’accès (pas

de mécanisme de modification des droits)

 N’empêche pas les canaux cachés

• flux d’information non contrôlé par un mécanisme de

sécurité

 Ne prend pas en compte le partage de fichiers

05/11/2014

LAABIDI Mounira

32

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Modèle Bell-Lapadula

• Eléments de base :

– S ens. de sujets, O ens. d’objets – A ens. d’attributs d’accès :

• Observation sans altération : read (r) • Observation et altération : write (w) • Altération sans observation : append (a) • Ni observation, ni altération : execute (e) • Beaucoup de modifs/ajouts selon les auteurs

05/11/2014

LAABIDI Mounira

33

33

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Modèle Bell-Lapadula

05/11/2014

LAABIDI Mounira

34

34

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Modèle Bell-Lapadula

05/11/2014

LAABIDI Mounira

35

35

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Le modèle HRU

Établi par [Harrison et al. 1976], le modèle HRU décrit les politiques de contrôle d’accès discrétionnaires traditionnelles.

Une matrice P représente l’ensemble des droits d’accès des sujets vers les objets. De plus, les sujets peuvent créer de nouveaux sujets ou objets, et ajouter des droits.

HRU propose de modéliser la protection dans les systèmes d’exploitation comme suit :

l’ensemble des sujets S et l’ensemble des objets O sont tous deux l’ensemble des entiers de 1 à k. R est l’ensemble des droits génériques (tels que possession, lecture, écriture, exécution).

05/11/2014

LAABIDI Mounira

36

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Le modèle HRU

Le système d’exploitation contient un ensemble fini C de commandes 1, . . . , n, qui représente toutes les opérations fournies par le système d’exploitation (création de fichier, modification des droits...).

Du point de vue de la protection, les commandes de l’ensemble C ont toutes la même forme : elles prennent en paramètre des sujets et objets, et suivant la présence de certains droits dans la matrice P, elles effectuent un ensemble d’actions élémentaires sur le système.

 Ces actions élémentaires sont : enter et delete pour l’ajout et la suppression de droits, create subject et create object pour la création de nouveaux sujets et objets et enfin destroy subject et destroy object pour la destruction de sujets et objets.

 La configuration du système de protection est le triplet (S,O, P). LAABIDI Mounira

05/11/2014

37

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Le modèle HRU

• HRU : Harrison, Ruzzo, et Ullman

– Prend en compte la création/suppression de sujets ou d’objets et le

changement de droit – Droits : own, read, write – Format des requêtes ou commandes

– M désigne la matrice de permission d’accès

05/11/2014

LAABIDI Mounira

38

38

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Le modèle BIBA

• Objectif : assurer l’intégrité

– Interdire toute propagation d’information d’un objet situé à un certain niveau d’intégrité vers un objet de niveau d’intégrité inférieur

– Interdire à tout sujet situé à un certain niveau d’intégrité

de modifier un objet possédant niveau d’intégrité supérieur

05/11/2014

LAABIDI Mounira

39

39

Le modèle de Biba

40

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Modèles de contrôles d’accès

Le modèle “Domain and Type Enforcement” (DTE)

Crée en1985, est assez différent des précédents, il ne cherche pas à garantir la sûreté de la protection .

 Il s’agit d’un mécanisme générique à partir duquel on peut implanter diverses politiques de sécurité dans un système d’exploitation.

 Dans un SE, les politiques de sécurité définies via le modèle DTE visent à :

 Restreindre les ressources accessibles par un programme, notamment les programmes privilégiés (s’exécutant sous le compte root), suivant le principe de “moindre privilège”.

 Contrôler quels programmes ont accès aux ressources “sensibles”, et empêcher l’accès par tout autre programme.

05/11/2014

LAABIDI Mounira

41

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Modèles de contrôles d’accès

Par exemple: DTE peut être utilisé pour contrôler un programme tel que le serveur Web apache, afin de garantir par exemple que même s’il s’exécute sous le compte root, il n’a accès qu’à ses fichiers de configuration, ses librairies et aux pages web.

Le modèle reprend les principes de sujet, d’objet et de matrice d’accès. Toutefois, les lois d’accès n’opèrent pas sur les sujets, mais les domaines, et de même les objets sont englobés dans des types. Ainsi chaque objet du système possède un type, et chaque processus s’exécute dans un domaine précis, dont découlent des droits d’accès.

05/11/2014

LAABIDI Mounira

42

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Le modèle RBAC

Role-Based Access Control

 Les permissions d’accès sont attribuées en fonction de rôle qu’occupe un utilisateur dans une entreprise ou une organisation. C’est ainsi qu’est conçu le modèle RBAC (Role-Based Access Control) ou contrôle d’accès déterminé par le rôle.

Les utilisateurs ont un certain rôle, qui caractérise leur activité.

Chaque rôle est associé à un ensemble de permissions, qui représentent des possibilités d’accès aux objets du système.

Enfin, l’utilisateur exerce son activité dans le cadre de sessions, durant lesquelles il peut activer un sous-ensemble des rôles auxquels il appartient

05/11/2014

LAABIDI Mounira

43

Exercice 1 : Contrôle d’accès multi-niveaux

• On considère un treillis de labels de confidentialité construit à partir de 4 niveaux de sécurité Top Secret >Secret > Confidentiel > Non Confidentiel, et 3 catégories de sécurité A, B et C. Dans les exemples ci-dessous, spécifiez quels sont les modes d’accès (observation, altération) permis suivant le modèle de Bell-LaPadula (on suppose que le contrôle d’accès discrétionnaire ne refuse pas l’accès).

•

–

–

– –

–

M. V ayant pour label (Top Secret,{A,C}) veut accéder à un document ayant pour label (Secret,{B,C}) ; M. W ayant pour label (Confidentiel,{C}) veut accéder à un document ayant pour label (Confidentiel,{B,C}) ; M. X ayant pour label (Secret,{C}) veut accéder à un document ayant pour label (Secret,{C}) ; Mme Y ayant pour label (Top Secret,{A,C}) veut accéder à un document ayant pour label (Confidentiel,{A}) ; Mme Z ayant pour label (Non Confidentiel,∅) veut accéder à un document ayant pour label (Confidentiel,{B}).

44

Exercice 1 : Contrôle d’accès multi-niveaux

– M. V ayant pour label (Top Secret,{A,C}) veut accéder à un document ayant pour label

(Secret,{B,C}) ;

Pas d’accès car Top Secret> Secret mais {B,C}{A,C} – M. W ayant pour label (Confidentiel,{C}) veut accéder à un document ayant pour

label (Confidentiel,{B,C}) ; Altération car {C}{C,D} – M. X ayant pour label (Secret,{C}) veut accéder à un document ayant pour label

(Secret,{C}) ;

Altération et modification – Mme Y ayant pour label (Top Secret,{A,C}) veut accéder à un document ayant pour

label (Confidentiel,{A}) ;

Observation car Top Secret> Secret et {A}  {A,C} – Mme Z ayant pour label (Non Confidentiel,∅) veut accéder à un document ayant pour

label (Confidentiel,{B}).

Altération

45

Exercice 2 : Système Unix Data General B2

Le système Unix Data General B2 (DG/UX B2) fournit un modèle multi-niveaux. Ce contrôle utilise des labels de sécurité correspondant à des « zones » distinctes, détaillées sur le schéma 1. La zone « administrative region » est dédiée aux données tels que les logs, la définition des labels MAC. Les programmes systèmes sont situés dans la zone « virus prevention region ».

•

•

46

Exercice 2 : Système Unix Data General B2

Vu qu’il s’agit d’un système UNIX sécurisé, quelle technique de contrôle d’accès est utilisée par ce système?

•

• Quel est le modèle de sécurité utilisé ? •

Pourquoi la zone «virus prevention region» est-elle en-dessous de la zone «user region»? Pourquoi la zone « administrative region » est-elle au-dessus de la zone « user region » ?

•

47

Exercice 2 : Système Unix Data General B2

Vu qu’il s’agit d’un système UNIX sécurisé, quelle technique de contrôle d’accès est utilisée par ce système?

•

MAC • Quel est le modèle de sécurité utilisé ? BEL-LAPADULA •

Pourquoi la zone «virus prevention region» est-elle en-dessous de la zone «user region»?

La zone « virus prevention region » contient les programmes systèmes. D’après la propriété de confinement de BLP aucun sujet de la zone « user region » (utilisateur) ne peut donc les modifier. D’après la propriété simple de BLP un utilisateur peut les exécuter. Le nom de la zone « virus prevention region » provient du fait qu’un virus nécessite l’altération d’un exécutable. (no write down) •

Pourquoi la zone « administrative region » est-elle au-dessus de la zone « user region » ?

D’après la propriété simple de BLP, les utilisateurs ne peuvent lire les données de la zone « administrative region » qui est réservée à des données auxquelles les utilisateurs ne doivent pas avoir accès (définition des labels, logs). (no read up)

48

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Les protocoles / Utilisation

 RADIUS  TACACS / TACACS+  Kerberos  802.1x

05/11/2014

LAABIDI Mounira

49

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Radius

RADIUS (Remote Authentication Dial-In User Service)  Radius est un protocole qui permet à un serveur d’accès (au sens large du terme) de communiquer avec un serveur central pour authentifier les utilisateurs et autoriser les accès.

 Modèle Client-serveur, standard de l’IETF RFC 2138.

 Toutes les transactions RADIUS sont authentifiées par l'utilisation d'un

secret qui n'est jamais transmis sur le réseau. De plus les communications sont en partie chiffrées en utilisant une clef secrète définie sur le serveur et le client.

 Le client RADIUS est souvent intégré dans les serveurs d’accès (NAS) émettant les requêtes pour authentifier les utilisateurs qui tentent d’accéder au réseau.

 La modularité du protocole permet son utilisation pour une grande variété

d’applications et notamment les proxys applicatifs.

05/11/2014

LAABIDI Mounira

50

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Radius exemple

05/11/2014

LAABIDI Mounira

51

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Radius: principe

1.L’utilisateur initie une connexion PPP avec le serveur d’accès 2.Le serveur d’accès demande l’identifiant et le mot de passe (PAP) ou envoi un challenge (CHAP – MD5) 3.L’utilisateur répond 4.Le client RADIUS (le NAS) envoi l’identifiant et le mot de passe au serveur RADIUS (authentification) en le chiffrant avec la clef qu’il partage avec le serveur 5.Le serveur RADIUS répond avec les messages Accept, Reject, or Challenge. 6.Le client RADIUS se configure en fonction du contenu des messages Accept ou Reject (autorisation)

05/11/2014

LAABIDI Mounira

52

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Pourquoi utiliser RADIUS

 AAA (Authorization Authentication Accounting)

 Radius fournit en plus de l’Authentification, un moyen de gérer

les autorisations d’accès et la journalisation des échanges

 Protocole robuste et très répandu

 NAS, VPN, Authentification domaine, Proxy, …

 Modularité permettant une adaptation à la plupart des

contextes

 Attributs configurables

05/11/2014

LAABIDI Mounira

53

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Exemple d’utilisation RADIUS

 Accès nomades

NAS Opérateur

Dial

Elève

Opérateur Tiers

Authentification avec clé partagée ( preshared key )

Serveur Radius Opérateur

Authentification avec clé partagée Radius Opérateur ( preshared key )

Réseau privé

Commutateur

Serveur Radius

05/11/2014

LAABIDI Mounira

54

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Exemple d’utilisation RADIUS (2)

 Wifi

Adresse IP Options DHCP

WEP

Relais DHCP

Portable

Borne Wifi

Commutateur

RADIUS Authentification EAP

Authentification PEAP

DHCP

Serveur W2000

Serveur Radius

W2000 AD

Authentification domaine AD

05/11/2014

Enrôlement domaine ( filaire )

LAABIDI Mounira

55

TACACS

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

 TACACS (Terminal Access Controller Access Control System)

 TACACS est un ancien protocole du monde Unix qui permet à un serveur d’accès de faire suivre vers un serveur d’authentification les authentifiants (login/mot de passe) d’un utilisateur afin de déterminer quelles autorisations peuvent lui être attribuées

 TACACS est un protocole plus ancien et beaucoup moins sûr que

RADIUS et TACACS+

 TACACS ainsi qu’une version plus récente XTACACS (eXtended

TACACS – Cisco 1990) sont deux protocoles normalisés par l’IETF RFC 1492

 Cisco a déclaré en 1997 la fin du support de ces protocoles ceux-

ci ayant été remplacés

 TACACS et XTACACS ne sont plus utilisés de nous jours

05/11/2014

LAABIDI Mounira

56

TACACS+

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

 En dépit de son nom TACACS+ n’est pas une évolution de

TACACS mais un nouveau protocole

 TACACS+ est, au même titre que RADIUS un protocole qui

permet à un serveur d’accès de communiquer avec un serveur central pour authentifier les utilisateurs et autoriser les accès

 L’implémentation diffère cependant de celle de son

« concurrent » RADIUS sur certains points

 AAA (Authorization Authentication Accounting)

– TACACS+ fournit en plus de l’Authentification, un moyen de gérer les

autorisations d’accès et la journalisation des échanges

 TACACS+ a fait l’objet d’un Draft de la part de Cisco mais n’a

pas été normalisé et reste propriétaire

05/11/2014

LAABIDI Mounira

57

Pourquoi utiliser TACACS+

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

 En environnement Cisco celui-ci semble plus sûr que RADIUS

 Chiffrement de la totalité du message  Utilisation de TCP

 TACACS+ soufre cependant de quelques vulnérabilités (au

même titre que RADIUS)

 Rejet, la taille du mot de passe peut être déterminée en fonction

de la taille du paquet, ...

 Celles-ci ont normalement été corrigées, mais combien

d’anciennes version de l’IOS continuent encore à être utilisées ?

 TACACS+ reste très populaire sur les réseaux Cisco

05/11/2014

LAABIDI Mounira

58

RADIUS/TACACS+

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Radius Radius

 Utilise UDP  Utilise UDP  Publique, normalisé,  Publique, normalisé, forte interopérabilité et forte interopérabilité et

modularité modularité

 Plus léger que TACACS+ (dans  Plus léger que TACACS+ (dans

son concept) son concept)

 Regroupe dans un seul profil  Regroupe dans un seul profil utilisateur authentification et utilisateur authentification et autorisation autorisation

TACACS+ TACACS+

 Utilise TCP  Utilise TCP  Chiffre la totalité des messages  Chiffre la totalité des messages  Propriétaire Cisco  Propriétaire Cisco

• On trouve cependant quelques • On trouve cependant quelques

implémentations sur d’autres produits implémentations sur d’autres produits

 Supporte plus de protocoles que  Supporte plus de protocoles que

RADIUS RADIUS

• AppleTalk Remote Access, Net BIOS • AppleTalk Remote Access, Net BIOS

Frame, … Frame, …

 Dissocie les profils d’authentification  Dissocie les profils d’authentification

et d’autorisation et d’autorisation

05/11/2014

LAABIDI Mounira

59

Kerberos

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

 Kerberos a été conçu au MIT (Massachusetts Institute of

Technology) dans les années 1980.

 Kerberos est un protocole d’authentification réseau

 Fournit l’authentification mutuelle grâce à des clefs partagées et

du chiffrement (DES ou 3DES) ou un tiers de confiance

 Utilise un mécanisme à base de Tickets  Principe : tous les mots de passe et les droits d’accès sont stockés

sur un serveur sécurisé

 Les constituants d’une infrastructure utilisant Kerberos sont :

 Les clients Kerberos  Les serveurs d’accès supportant Kerberos (routeur, passerelle ou

serveur d’accès)

 Les serveurs compatibles Kerberos  Le serveur de génération de Tickets (Key Distribution Center)

05/11/2014

LAABIDI Mounira

60

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Pourquoi utiliser Kerberos

 Authentification mutuelle sécurisée  Chiffrement des échanges

 Pas de transmission de mot de passe

• Transmission de clefs de session chiffrées

 Gestion centralisée de l’authentification

• Administration centralisée et audit facilité

 Kerberos permet le Single Sign On… • Facilite la vie de l’utilisateur

 Possibilité de Kerberisation de toutes les applications =>

Utilisation d’API Kerberos

 Facilite la convergence vers la PKI

• Dans la mesure ou une partie du travail aura déjà été fait

05/11/2014

LAABIDI Mounira

61

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Terminologie (1)

 Client

 Entité pouvant obtenir un ticket (user/host)

 Service

 Machine ou application (ftp, pop, ssh, …)

 Ticket

 Crédit (identité d’un client pour un service)

 TGT (Ticket Granting Ticket)

 Sorte de super-ticket obtenu à la première authentification, qui permet ensuite l’obtention de tickets pour les services accédés

 REALM (royaume)

 Domaine d’authentification

• 1 base de donnée Kerberos + 1 ou plusieurs KDC

 Organisation hiérarchique entre les domaines avec authentification

05/11/2014

LAABIDI Mounira

62

Chapitre 3: Sécurité des systèmes d’exploitation et du logiciel

Terminologie (2)

 « Principal »

 Triplet (nom, instance, domaine)

• ex: user/group@REALM ou service/host.domain@REALM

 KeyTab

 Fichier du client contenant une ou plusieurs clefs

 KDC (Key Distribution Center)

 Contient la base des clients et des serveurs ainsi que les clefs

• Gère les clefs pour les « principales » et tickets

 AS (Authentication Server/Service)

• Fournit au client une clef de session et un TGT

 TGS (Ticket Granting Server/Service)<