Configuration du pare-feu avec le protocole d’authentification Kerberos

Nommer d’après le chien à trois têtes qui garde les portes des Enfers dans les mythes grecs anciens, le protocole Kerberos fournit un service d’authentification sécurisé pour les réseaux informatiques. Il réalise une authentification mutuelle entre l’utilisateur et le serveur avec l’aide d’un centre de distribution de clés de confiance (KDC) qui fournit le service d’authentification et de distribution de tickets. Tous les principaux systèmes d’exploitation, y compris Microsoft Windows, Linux, Apple OS X et FreeBSD, prennent en charge le protocole Kerberos.

Les messages du protocole Kerberos sont protégés contre les attaques par rejeu et l’interception grâce à la cryptographie à clé secrète partagée. Le but principal de Kerberos est d’éviter la transmission de mots de passe cryptés sur le réseau. Il élimine la menace des renifleurs de paquets et améliore la sécurité globale du réseau.

Bien que le fournisseur de support de sécurité de Kerberos traite efficacement des menaces de sécurité sévères, il peut être difficile à mettre en œuvre en raison d’une variété de limitations :

• Si le serveur Kerberos est en panne, les utilisateurs ne peuvent pas se connecter. Le problème peut être résolu en utilisant des mécanismes d’authentification de secours et plusieurs serveurs Kerberos.
• Les horloges des hôtes impliqués doivent être synchronisées. Sinon, l’authentification échouera, car les tickets Kerberos ont une certaine période de validité.
• Kerberos ne peut pas être utilisé lorsque les utilisateurs souhaitent se connecter à des services à partir de systèmes non fiables.
• En cas d’utilisation de la cryptographie symétrique, la compromission de l’infrastructure d’authentification permettra à un attaquant de se faire passer pour n’importe quel utilisateur.
• Chaque service réseau nécessitant un nom d’hôte différent aura besoin de son propre ensemble de clés Kerberos.

Comment fonctionne l’authentification Kerberos

Le centre de distribution de clés se compose du serveur d’authentification (AS) et du serveur de distribution de tickets (TGS). Le TGT est un ticket de distribution de tickets.

1. L’utilisateur entre son identifiant et son mot de passe. L’identifiant utilisateur en clair va au serveur d’authentification (AS) avec une demande de services au nom de l’utilisateur.
2. L’AS vérifie si l’identifiant utilisateur est dans la base de données. S’il y a des informations sur cet utilisateur, alors l’AS peut générer la clé secrète du client en fonction de l’identifiant et du mot de passe de l’utilisateur. L’AS envoie à l’utilisateur :
   • Clé de session Client/TGS (chiffrée avec la clé secrète du client) ;
   • TGT incluant l’identifiant utilisateur, l’adresse réseau et la période de validité du ticket + clé de session Client/TGS (chiffrée avec la clé secrète du TGS).
3. L’utilisateur décode le premier message mais ne peut pas décoder le deuxième, car l’utilisateur n’a pas la clé secrète du TGS. Le client envoie un message au TGS :
   • TGT reçu de l’AS + identifiant serveur + clé secrète TGS/client (chiffrée avec la clé secrète du TGS) ;
   • Authentificateur incluant l’identifiant client et l’horodatage (chiffré avec la clé de session Client/TGS).
4. Le TGS déchiffre le premier message, obtient le TGT + clé de session TGS/Client, avec laquelle il déchiffre le deuxième message. Le TGS vérifie si l’identifiant utilisateur du premier message correspond à l’identifiant du deuxième message et si l’horodatage ne dépasse pas la période de validité du ticket. Si tout est correct, le TGS envoie à l’utilisateur :
   • Identifiant utilisé, adresse réseau, période de validité du ticket + clé de session Client/Serveur (chiffrée avec la clé secrète du serveur) ;
   • Clé de session Client/Serveur (chiffrée avec la clé secrète Client/TGS).
5. Le client envoie ce qui suit au serveur auquel il essaie d’accéder :
   • Identifiant utilisé, adresse réseau, période de validité du ticket + clé de session Client/Serveur (chiffrée avec la clé secrète du serveur) ;
   • Authentificateur incluant l’identifiant et l’horodatage (chiffré avec la clé de session Client/Serveur).
6. Le serveur ciblé déchiffre les messages utilisateur, vérifie si les identifiants utilisateur des deux messages ont la même valeur et si la période de validité n’est pas dépassée, puis envoie au client le paramètre suivant pour confirmer son identité :
   • Horodatage + 1 (chiffré avec la clé de session Client/Serveur)

Le client vérifie si la valeur d’horodatage est horodatée + 1, ce qui montre la véritable identité d’un serveur. Si c’est le cas, le client peut faire confiance au serveur et commencer à travailler avec lui.

Configuration du pare-feu pour travailler avec le protocole d’authentification Kerberos

Le pare-feu de base de données DataSunrise prend en charge le protocole d’authentification Kerberos. Certains changements de configuration doivent être mis en œuvre pour permettre les opérations Kerberos, ils peuvent varier selon le produit SGBDR utilisé. Dans cet article, nous allons montrer comment personnaliser Kerberos sur MS SQL Server.

Lorsqu’on travaille dans Active Directory, l’autorisation des utilisateurs est effectuée via l’interface de fournisseur de support de sécurité (SSPI). Deux protocoles peuvent être utilisés : NTLM et Kerberos. NTLM est un protocole plus lent et moins sécurisé, nous allons donc uniquement examiner la personnalisation de Kerberos. Pour activer Kerberos, plusieurs conditions doivent être remplies :

1. La délégation pour les utilisateurs et les ordinateurs Active Directory doit être activée.
   • Accédez à Utilisateurs et ordinateurs Active Directory.
   • Trouvez le compte d’ordinateur où DataSunrise est installé.
   • Accédez à l’onglet Délégation et passez à l’état “Faire confiance à cet ordinateur pour sa délégation à tout service”.
2. L’adresse du proxy doit correspondre au SPN enregistré du service MSSQLSvc. Utilisez l’outil SetSPN pour enregistrer deux SPN requis pour le compte de l’ordinateur pour lequel vous avez autorisé la délégation : setspn -A MSSQLSvc/proxy-host:proxy-port proxy-host setspn -A MSSQLSvc/full-fqdn-proxy-host:proxy-port proxy-host

   La liste de tous les SPN enregistrés peut être obtenue avec la commande suivante :

   setspn -L proxy-host

   Pour supprimer le proxy SPN, effectuez l’opération suivante :

   setspn -D MSSQLSvc/proxy-host:proxy-port proxy-host

   Pour tester le schéma d’autorisation, exécutez la commande suivante après la connexion au serveur :

   select auth_scheme from sys.dm_exec_connections where session_id=@@spid

   Le résultat correspondra au schéma d’authentification utilisé par le serveur : SQL, NTLM ou KERBEROS.

3. En cas d’erreur “Impossible de générer le contexte SSPI”, reportez-vous aux instructions de support Microsoft pour savoir comment résoudre le problème avec l’interface de fournisseur de support de sécurité.