Novembre – Décembre 2005 Version 1.01 1 État de lart de la sécurité informatique Chapitre 3...

1Novembre – Décembre 2005 Version 1.01

État de l’art de la sécurité informatique

Chapitre 3 – Sécurité des accès

Auteurs :

Stéphan GUIDARINI – Consultant Senior

Sébastien DESSE – Expert Réseaux et Sécurité


SommaireSécurité des Accès

Authentification Mots de passe Authentification/Authentification forte

Les protocoles / Utilisation RADIUS TACACS / TACACS+ Kerberos 802.1x


Introduction

La sécurité des accès fait intervenir un certain nombre de mécanismes que nous avons décrits dans les sections précédentes Filtrage des échanges par un Firewall Filtrage des échanges par un relais applicatif Authentification des tiers

Algorithmes à clefs publiques Nous allons développer ce point en présentant d’autres solutions

d’authentification

Cette section a également pour but de présenter les protocoles permettant de gérer l’authentification et les accès au système d’information de l’entreprise Le concept du « Single Sign On » Les protocoles RADIUS, TACACS, Kerberos


Authentification – Bases (1)

Identification : Identité numérique Personne Chaque personne ayant accès au système d’information doit se voir

attribuer un IDENTIFIANT UNIQUE

L’authentification = Challenge L’authentification repose toujours sur un challenge lancé par le

système de destination à l’intention du client afin que celui-ci prouve sont identité

Mot de passe, clef privée, empreinte digitale, …

La réussite du challenge valide l’association client Identifiant

Qui êtes vous ?

Prouvez le.Dupond

= 1 identifiant

Mon mot de passeest toto

OK, c'est DUPOND


Authentification – Bases (2)

Trois méthodes d’authentification La connaissance

Secret connu (ex : mot de passe) La possession

Possession d’un objet (ex: Carte, badge, clef) L’entité

Caractéristique physique (ex :biométrie)

Prise une à une ces techniques ont toutes des points faibles, C’est la combinaison de plusieurs méthodes

d’authentification qui permet de mettre en place des solutions d’authentification forte


Mots de passe Utilisation de mots de passe

Gestion Indispensable Création, Modification, Déblocage, Suppression

Problème : stockage, transfert sur le réseau, rejeu, mémorisation difficile pour les utilisateurs, gestion pour l’administrateur

Des règles simples rarement respectées 8 caractères minimum Non prédictible (Prénom, nom, identifiant, …) Renouvellement régulier Jamais écrit

La plupart des intrusions ont pour origine un mot de passe trivial, un compte système ou applicatif ayant conservé son mot de passe par défaut


Badges et cartes

Cartes d’identité (sans mot de passe) Code barre, Carte magnétique, puce Problèmes :

Copie, vol, liaison lecteur Serveur, rejeu

Cartes d’identité + mot de passe Authentification double facteur Problèmes :

Liaison lecteur Serveur, rejeu En cas copie ou de vol le pirate doit « simplement » résoudre un problème de mot de passe


Mot de passe unique OTP (One Time Password)

Mot de passe utilisable une seule fois Protection contre le rejeu Non prédictible si l’algorithme est gardé secret

Pour parer aux problèmes de vol on adjoint souvent au code généré un code personnel (PIN)

Plusieurs techniques Asynchrone (challenge/réponse)

Envoi d’un challenge par le serveur, l’utilisateur possède une calculatrice qui transforme le challenge en un mot de passe qu’il saisit. Le serveur fait la même opération et compare.

Synchrone dépendant du temps Le mot de passe est fonction du temps et est généré à intervalle régulier.

Le challenge (utilisé dans le mode asynchrone) est en fait la date et l’heure.

Synchrone indépendant du temps Utilisation d’un compteur interne à la calculatrice incrémenté à chaque

utilisation. Le serveur est synchronisé sur ce compteur et n’accepte pas de code antérieur au compteur


Biométrie

Se base sur les propriétés du corps humain et la faible probabilité de trouver des caractéristiques identiques sur deux personnes différentes S’assure de l’association physique de l’identifiant avec la

personne Fond de l’œil, empreinte digitale, voix

Problèmes : Création des authentifiants (fiabilité) Liaison lecteur Serveur, rejeu Ne fonctionne pas avec le matériel


Authentification Unique

SSO (Single Sign On) Le Single Sign On est une facilité permettant à un utilisateur de

ne s’authentifier qu’une seule fois pour accéder à un ensemble de ressources hétérogènes ; on distingue :

Le « SSO Poste » appliqué aux autorisations pour l’accès aux serveurs applicatifs du Système d’information

Le « SSO Serveur » appliqué aux applications Web type Intranet, Services Internet, …

Le Single Sign On permet à l’utilisateur de n’avoir qu’un seul mot de passe pour l’accès à un ensemble d’applications

Le bénéfice pour la sécurité est la réduction du nombre de mots de passe à mémoriser par l’utilisateur, évitant en théorie les mots de passe trop simples ou écrits sur un papier

Pour l’administrateur, la centralisation de la base des mots de passe garantie une administration simplifiée et homogène de la politique d’authentification


Inconvénients Le bénéfice apporté par le SSO en terme de sécurité est

grandement atténué par le fait qu’il permet de contourner d’une certaine manière le processus d’authentification en l’automatisant Comment garantir que c’est bien l’utilisateur qui se trouve devant son

poste si celui-ci n’a plus à intervenir pour s’authentifier ? Le SSO implique la mise en place de mécanismes garantissant la

présence PHYSIQUE de l’utilisateur devant son poste Carte à puce dans un lecteur par exemple

L’utilisateur devant enlever la carte à puce du lecteur à chaque fois qu’il s’absente ; l’obligeant à répéter le processus d’authentification à son retour…

Le SSO est souvent présenté par les constructeurs comme un moyen de préparer l’arrivée des PKI (car préparant l’infrastructure à l’intégration des PKI) mais pour beaucoup le SSO semble être une fonctionnalité des PKI à ne pas exploiter Cf. « CDROM/Infrastructure à clefs publiques/Ten Risks of PKI.doc »

Par Carl Ellison et Bruce Schneier deux experts en cryptographie et sécurité


SSO Serveur

3 alternatives d’architecture SSO Reverse Proxy: L’accès aux applications et

l’authentification primaire sont réalisés par un serveur de sécurité installé en mode reverse proxy,

SSO proxy web: L’accès aux applications et l’authentification primaire sont réalisés par un serveur de sécurité installé en mode proxy web ou associé à un portail d’entreprise,

SSO basée sur des agents filtres: Un agent installé sur chaque serveur est intercalé entre le poste client et le serveur de sécurité dont il est le client.

Les 3 architectures peuvent être associées pour répondre aux contraintes imposées par l’environnement technique et applicatif.


SSO Serveur (2)

Architecture SSO Reverse ProxyPROCESSUS

ETAPE 1: Le client demande au DNS l’@ IP du serveur intranet , le DNS lui communique l’@ IP du Reverse Proxy SSO. ETAPE 2: Le client réalise une authentification primaire auprès du reverse proxy SSO et demande la connexion au serveur intranet, le reverse proxy SSO interroge l’annuaire pour valider les droits de client et récupérer le couple L/P correspondant à l’Intranet,

ETAPE 3: Le reverse proxy SSO établit une connexion avec le serveur intranet en présentant le coupe L/P du client.

ANNUAIRE

Client web

Reverse Proxy web@Y

Application RH Portail INTRANET@ X

DNS

ETAPE 1

ETAPE 2

ETAPE 3


SSO Serveur (3)

Architecture SSO Proxy Web

PROCESSUS

ETAPE 1: Le client web se connecte au serveur proxy web SSO. ETAPE 2: Le client réalise une authentification primaire auprès du proxy web SSO et demande la connexion au serveur intranet, le proxy web SS0 interroge l’annuaire pour valider les droits de client et récupérer le couple L/P correspondant à l’Intranet,

ETAPE 3: Le proxy web SSO établit une connexion avec le serveur intranet en présentant le coupe L/P du client.

ANNUAIRE

Client web avec config url « Proxy.ccinca.fr »

Proxy.ccinca.fr


ETAPE 2

ETAPE 3

ETAPE 1


SSO Serveur (4)

Architecture SSO Agents

PROCESSUS

ETAPE 1: Le client web se connecte au serveur portail sur lequel est installé l’agent SSO et fournit son couple L/P. ETAPE 2: L’agent interroge le serveur SSO pour valider le couple L/P. Ce dernier interroge l’annuaire et retourne la réponse.

ETAPE 3: Le client à cliqué sur l’icône intranet dans le portail. L’agent transmet au serveur SSO l’identité du client et du serveur cible (intranet). Le serveur SSO interroge l’annuaire et envoi à l’agent du serveur intranet le couple L/P secondaire. Ce dernier joue l’authentification.

ANNUAIREOU SGBD

Client web

Serveur SSO


?

ETAPE 3

ETAPE 1

OK

HTTPCouple L/P portail

ETAPE 2

Jeton

LDAP/SQL

L/P Intranet


Radius

RADIUS (Remote 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


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épond4.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 serveur5.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)


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


Exemple d’utilisation RADIUS Accès nomades

Commutateur

Serveur Radius

Authentification avec clé partagée( preshared key )

Opérateur Tiers

Réseau privé

Dial Elève

Serveur Radius

Opérateur

NASOpérateur

Authentification avec clé partagéeRadius Opérateur ( preshared key )


Exemple d’utilisation RADIUS (2)

Réseaux Wifi

Commutateur

ServeurW2000

Borne WifiPortable

WEP

RADIUSAuthentification EAP

W2000AD

Serveur Radius

Authentification domaine AD

DHCP

RelaisDHCP

Adresse IP Options DHCP

Authentification PEAP

Enrôlement domaine ( filaire )


TACACS 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

Date du temps de ARPANET… 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


TACACS+ 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


Pourquoi utiliser TACACS+

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) Rejeu, 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


RADIUS/TACACS+ Radius

Utilise UDP Publique, normalisé, forte interopérabilité et modularité Plus léger que TACACS+ (dans son concept) Regroupe dans un seul profil utilisateur authentification et

autorisation TACACS+

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

On trouve cependant quelques implémentations sur d’autres produits

Supporte plus de protocoles que RADIUS AppleTalk Remote Access, Net BIOS Frame, …

Dissocie les profils d’authentification et d’autorisation


Kerberos

Kerberos a été conçu au MIT (Massachusetts Institute of Technology) dans les années 1980. Aujourd’hui Kerberos V tend à se répandre.

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)


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


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

« Principal » Triplet (nom, instance, domaine)

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


Terminologie (2)

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) Service délivrant les tickets à partir du TGT obtenu auprès de l’AS


Anatomie d’un TicketDomain

Principal Name

Ticket Flags

Encryption Key

Domain

Principal Name

Start Time

End Time

Host Address

Authorization Data

Chiffré avec le mot de passe de l’utilisateur

32 bits indiquant les propriétés du ticket

Champ utilisé, dans Microsoft 2000 par exemple, pour ajouter les autorisations concernent l’utilisateur (propriétaire)

Adresse du client

Clef de session


Architecture


Kerberos - Problèmes NAT

Le ticket contient l’adresse du client Le support de ticket pouvant être utilisé au travers du NAT a été ajouté à

Kerberos V (par désactivation de la vérification de l’adresse) Pour les versions précédentes il convient de désactiver la vérification de

l’adresse source manuellement Facilite le rejeu

Problèmes de sécurité Rejeu

Il convient de synchroniser correctement les horloges

Les passphrases trop simples Peut permettre un « brute force » du mot de passe et donc une usurpation

d’identité Rejoint les problèmes classiques de mots de passe

Postes utilisés par plusieurs personnes Rejoint les problèmes du Single Sign On


802.1x

Nouvelle norme 802.1x Fonctionnement Utilisation Faiblesse(s) Évolutions


802.1x – Historique et environnement

Quelques repères historiques dans la standardisation 1994-2003 : PPP (quelques dizaines de RFC!) 1997-2000 : RADIUS (RFC2058 remplacé par 2138, puis

2865) 1998 : EAP (RFC2284) 2001 : 802.1X

Environnement d’origine et évolution Connexion via un support physique (RTC, puis tous

réseaux) Prolonge jusqu’au niveau 2 le découplage entre

l’établissement de la connectivité et l’authentification Évolution ensuite vers les réseaux 802.11…..


802.1x – Objectifs

Standardiser un mécanisme de relais d’authentification au niveau 2 Pour les accès via des interfaces IEEE 802{.3 .5 .11} Intervient avant d’éventuels protocoles comme DHCP

Pour permettre un contrôle d’accès aux ressources Même si l’accès physique au réseau n’est pas contrôlable

Exemples d’utilisation : Accès Internet depuis une aire publique Affectation à un VLAN donné en fonction de l’authentification


802.1x – Fonctionnement Définitions

Authentificateur : Entité qui sur le port du réseau local facilite l’authentification d’une autre entité attachée sur le même port.

Serveur d’authentification : Entité qui procure un service d’authentification à un authentificateur. Ce service détermine, à partir des éléments de la requête du demandeur, les services qui lui sont accessibles. Ce serveur peut être sur la machine qui sert d’authentificateur ou accessible à ce dernier via le réseau.

Authentifié : Entité qui sur le port du réseau local qui est en train d’être authentifié par l’authentificateur (équivalent de peer dans EAP).

Point d’accès réseau : point d’accès physique (ex. prise RJ45 pour 802.3) ou logique (association pour 802.11) au réseau local (on emploie aussi le terme anglais de port, ou interface).

PAE (Port Access Entity) : Ensemble implémentant le protocole 802.1X, un même PAE peut jouer le rôle d’authentificateur ou d’authentifié.

Système : équipement qui est connecté au LAN par un ou plusieurs ports (ex: poste de travail, serveur, hub, commutateur, routeur…).

Système d’authentificationPoint d’accès au

réseau

Système à authentifié

Serveur authentification

Authentification 802.1X


802.1x - Utilisation

802.1X utilise le protocole EAP (Extensible Authentication Protocol), Protocole dédié au transport de crédits

d’authentification Plusieurs méthodes d’authentification

EAP-TLS : Authentification mutuelle du serveur et de l’utilisateur avec des certificats électroniquesEAP-TTLS: Seul le serveur doit disposer d’un certificat, l’utilisateur est authentifié par login/mot de

passeEAP-PEAP: Equivalent à EAP-TTLS mais propriétaire Microsoft. Cette méthode est disponible par défaut dans les systèmes Windows récents (XP, 2000, 2003)


802.1x - Faiblesses

Sont essentiellement dues à la conception du protocole dans un contexte de connexion physique

La norme 802.1x est vulnérable à deux types d’attaques (au moins) Attaque par interception

Le pirate envoi un message de fin de connexion au client en se faisant passer pour le point d’accès

Le pirate usurpe l’identité du client vis à vis du point d’accès

Attaque par interposition Le pirate se fait passer pour le point d’accès vis-à-vis du

client et relaye les flux vers le point d’accès à la manière d’un proxy


WPA

Wi-Fi Protected AccessConçu par la WiFi Alliance pour remplacer le

protocole Wired Equivalent PrivacyCombler une à une les failles du WEPRester compatible avec le matériel existant – il faut

encore utiliser le moteur WEPEnsemble de packages logiciels se superposant

au matériel:Authentification basée sur 802.1X et RADIUSRenouvellement des clés de chiffrement plus robuste

dans le temps (TKIP - Temporal Key Integrity Protocol)Meilleur mécanisme de contrôle d’intégrité (MIC)


802.11i

Les principes IEEE 802.11i est obligatoire dans IEEE 802.11g et

IEEE 802.11eReprend les mêmes mécanismes que WPALa gestion de la clé est la même que WPALe moteur WEP est remplacé par un moteur AES

(Advanced Encryption Standard) d’où le changement de matériel nécessaire


Lightweight Directory Access Protocol

Historique1988: La norme X500 (ISO)

Définit de manière très complète le moteur, les modules d’interrogation, les règles de nommage et les protocoles d’accès (D.A.P),

1993: Lightweight Directory Access Protocol V1Fournit une interface d’accès simplifiée aux annuaires X500,

fonctionne sur TCPIP.

1995: LDAP V2 (IETF RFC 1777).« Proposed standard »: Annuaire natif, gère sa propre base de

donnée.

1997: LDAP V3 (IETF RFC 2251 + 3377 de 09/02).Enrichit de mécanismes de chiffrement, partitionnement,

réplication, etc.


Lightweight Directory Access Protocol (2)

Le protocole LDAP Le protocole permettant d'accéder à l'information contenue dans

l'annuaire, Un modèle d'information définissant le type de données contenues

dans l'annuaire, Un modèle de nommage définissant comment l'information est

organisée et référencée, Un modèle fonctionnel qui définit comment on accède à l'information , Un modèle de sécurité qui définit comment données et accès sont

protégés, Un modèle de duplication qui définit comment la base est répartie

entre serveurs, Des APIs pour développer des applications clientes, LDIF, un format

d'échange de données.



Architecture hiérarchique mais distribuée : Le service d’annuaire ne repose généralement pas sur un

seul serveur mais s’étend sur une architecture technique distribuée apportant fiabilité, disponibilité et performance,

Notion de partitionnement: Il est possible de répartir les données sur plusieurs serveurs pour des raisons de capacité (taille), gestion, organisation,

Les différentes partitions sont néanmoins liées par des mécanismes de referral ou de duplication (réplication), un peu à l’image de l’annuaire D.N.S (Domain Name Service) utilisé pour résoudre les noms de domaines en adresses IP



Méta annuaire : Récupérer automatiquement les "informations d'entreprise" en

constituant un lien entre plusieurs annuaires ou bases disposant de schémas et d’espaces de nommage différents,

Agréger et fédérer ces informations dans la base d'annuaire LDAP. Il s’agit dans ce cas du mode « aggrégateur de contenu »,

Synchroniser ces informations d'une application à l'autre : envoi de l'adresse e-mail issue de la messagerie dans l'application RH, envoi du profil issu de l'application RH dans le serveur de résultats, etc. Pour ce faire, il va créer des associations entre les différentes sources de données et réaliser entre elles des synchronisations automatiques bidirectionnelles (mapping et translations entre les entrées et leurs attributs). Il s’agit dans ce cas du mode « courtier d’information ».



Annuaire et Single Sign On : L’annuaire constitue le socle nécessaire au contrôle des

identitésIl centralise et délivre de manière transparente les éléments

d'authentification, la liste des services et les droits associés à chaque utilisateur, que la personne authentifiée soit un employé ou un partenaire

Plate-forme d'authentification (agent ou serveur SSO) permet à l'utilisateur de s'authentifier une seule fois avant d'accéder à l'ensemble des services (systèmes, applications) auxquels il a droit.

Elle prend en charge la gestion et l'historique des connexions aux services autorisés sur la base des informations de sécurité fournies par l'annuaire.



Annuaire et PKI: L’annuaire est une des briques du socle technique

nécessaire à la mise en oeuvre d’une architecture à clé publique (P.K.I).

Stocker les certificats valides en permettant à tout utilisateur de trouver le certificat d’un autre par son nom ou adresse e-mail et de vérifier sa validité,

Stocker les certificats révoqués pour permettre à toute application d’effectuer les vérifications avant de lancer des traitements sensibles,

Sécuriser les accès en modification de l’annuaire en assurant des fonctions d’authentification utilisant les certificats X 509.

Novembre – Décembre 2005 Version 1.01 1 État de lart de la sécurité informatique Chapitre 3...

Documents

Transcript of Novembre – Décembre 2005 Version 1.01 1 État de lart de la sécurité informatique Chapitre 3...