L'environnement NFS est une manière puissante et pratique de partager des systèmes de fichiers sur un réseau comprenant plusieurs architectures informatiques et systèmes d'exploitation différents. Cependant, les mêmes fonctions qui font que le partage des systèmes de fichiers à l'aide des opérations NFS est pratique posent également des problèmes de sécurité. Historiquement, la plupart des implémentations NFS utilisaient l'authentification UNIX (ou AUTH_SYS), mais aussi des méthodes d'authentification plus fortes comme AUTH_DH étaient également disponibles. Lorsque vous utilisez l'authentification UNIX, un serveur NFS authentifie une demande de fichier en authentifiant l'ordinateur qui effectue la demande, mais pas l'utilisateur. Par conséquent, un utilisateur client peut exécuter de vous connectersu en tant que superutilisateur et usurper l'identité du propriétaire d'un fichier. Si l'authentification DH est utilisée, le serveur NFS authentifie l'utilisateur, ce qui rend ce type d'usurpation d'identité beaucoup plus difficile.
Avec un accès à la racine et des connaissances en programmation réseau, n'importe qui peut introduire des données arbitraire dans le réseau et extraire des données du réseau. Les attaques les plus dangereuses concernent l'introduction de données. Un exemple est l'usurpation de l'identité d'un utilisateur effectuée en générant les bons paquets ou en enregistrant des conversations et en les rejouant ultérieurement. Ces attaques ont une incidence sur l'intégrité des données. Les attaques qui impliquent l'écoute passive, qui correspond simplement à l'écoute du trafic réseau sans usurpation d'identité, ne sont pas aussi dangereuses, car l'intégrité des données n'est pas compromise. Les utilisateurs peuvent protéger la confidentialité des informations sensibles en chiffrant les données envoyées sur le réseau.
Une approche courante aux problèmes de sécurité réseau consiste à laisser la solution à chaque application. Une meilleure approche consiste à mettre en oeuvre un système d'authentification standard à un niveau qui couvre toutes les applications.
Le système d'exploitation Oracle Solaris inclut un système d'authentification au niveau du RPC, qui est le mécanisme sur lequel les opérations NFS sont construites. Ce système, appelé RPC sécurisé, améliore considérablement la sécurité d'un environnement réseau et fournit une sécurité supplémentaire pour les services tels que le système NFS. Un système NFS utilisant les fonctions qui sont fournies par RPC sécurisé est appelé système NFS sécurisé.
RPC sécurisé est une composante fondamentale du système NFS sécurisé. L'objectif de RPC sécurisé est de construire un système qui est au moins aussi sécurisé qu'un système travaillant en temps partagé. Dans un système travaillant en temps partagé tous les utilisateurs partagent le même ordinateur et les utilisateurs sont authentifiés via mot de passe de connexion. Avec l'authentification DES (Data Encryption Standard), le même processus d'authentification est terminé. Les utilisateurs peuvent se connecter sur n'importe quel ordinateur distant tout comme les utilisateurs peuvent se connecter sur un terminal local. Les mots de passe de connexion sont leur assurance de la sécurité du réseau. Dans un environnement en temps partagé, l'administrateur système a une obligation éthique de ne pas modifier un mot de passe pour usurper l'identité quelqu'un. Dans RPC sécurisé, l'administrateur réseau n'est pas autorisé à modifier les entrées d'une base de données qui stocke les clés publiques.
Un système d'authentification RPC utilise des justificatifs et des vérificateurs. Comme pour les cartes d'identité, les données d'identification sont ce qui identifie une personne : un nom, une adresse et une date de naissance. Le vérificateur est la photo sur la carte. Vous pouvez vérifier que la carte n'a pas été volée en vérifiant la photo sur la carte et en la comparant à la personne qui la détient. Dans RPC, le processus client envoie les informations d'identification et de connexion et un vérificateur au serveur avec chaque demande RPC. Le serveur renvoie uniquement un vérificateur car le client connaît déjà les informations d'identification et de connexion du serveur.
L'authentification RPC est illimitée, ce qui signifie qu'une grande variété de systèmes d'authentification peuvent y être raccordés, comme UNIX, DH et KERB.
Lorsque l'authentification UNIX est utilisée par un service réseau, les informations d'authentification et de connexion contiennent le nom d'hôte du client, l'UID, le GID et la liste d'accès de groupe. Cependant, dans la mesure où aucun vérificateur n'existe, un superutilisateur peut falsifier les informations d'identification et de connexion appropriées à l'aide des commandes telles que su. Un autre problème de l'authentification UNIX est qu'elle suppose que tous les ordinateurs d'un réseau sont des ordinateurs UNIX. L'authentification UNIX ne fonctionne pas lorsqu'elle est appliquée à d'autres systèmes d'exploitation dans un réseau hétérogène.
Pour surmonter les problèmes de l'authentification UNIX, le RPC sécurisé utilise l'authentification DH.
L'authentification DH utilise la cryptographie par clé publique DES (Data Encryption Standard) et Diffie-Hellman pour authentifier les utilisateurs et les ordinateurs du réseau. DES est un mécanisme de chiffrement standard. Le chiffrement par clé publique Diffie-Hellman est un système de chiffrement qui implique deux clés : une publique et une secrète. Les clés publiques et secrètes sont stockées dans l'espace de noms. NIS stocke les clés dans la mappe de clé publique. Ces mappes contiennent la clé publique et la clé secrète pour tous les utilisateurs potentiels. Pour plus d'informations sur la configuration des mappes, reportez-vous à la section Utilisation des services de noms et d’annuaire Oracle Solaris 11.2 : DNS et NIS .
La sécurité de l'authentification DH est basée sur la capacité d'un expéditeur à chiffrer l'heure actuelle, que le destinataire peut ensuite déchiffrer et vérifier par rapport à son propre horloge. L'horodatage est chiffré à l'aide de DES. Les deux agents doivent s'accorder sur l'heure en cours et l'expéditeur et le destinataire doivent utiliser la même clé de chiffrement.
Si un réseau exécute un programme de synchronisation d'heure, l'heure sur le client et le serveur est synchronisée automatiquement. Si un programme de synchronisation n'est pas disponible, les horodatages peuvent être calculés à l'aide de l'heure de serveur au lieu de l'heure du réseau. Le client demande l'heure au serveur avant le démarrage de la session RPC, puis calcule la différence de temps entre sa propre horloge et celle du serveur. Cette différence est utilisée pour compenser l'horloge du client lors du calcul des horodatages. Si les horloges du client et du serveur se désynchronisent, le serveur commence à rejeter les requêtes du client. Le système d'authentification DH sur le client permet d'effectuer une resynchronisation avec le serveur.
Le client et le serveur arrivent à la même clé de chiffrement en générant une clé de conversation aléatoire, également appelée clé de session, et en utilisant le chiffrement par clé publique pour déduire une clé commune. La clé commune est une clé que seuls le client et le serveur sont capables de déduire. La clé de conversation est utilisée pour chiffrer et déchiffrer l'horodatage du client. La clé commune est utilisée pour chiffrer et déchiffrer la clé de conversation.
Tenez compte des points suivants si vous avez l'intention d'utiliser le RPC sécurisé :
Si un serveur s'arrête brutalement et que personne n'est à proximité (à la suite d'une panne de courant, par exemple), toutes les clés secrètes qui sont stockées dans le système sont supprimées. Aucun processus ne peut accéder aux services réseau sécurisés ou monter un système de fichiers NFS. Les processus importants lors d'un redémarrage s'exécutent généralement en tant que root. Par conséquent, ces processus fonctionneraient si la clé secrète de la racine était stockée, mais personne n'est disponible pour saisir le mot de passe qui la déchiffre. keylogin -r permet à root de stocker les clé secrètes effacées dans /etc/.rootkey, que keyserv lit.
Certains systèmes s'initialisent en mode monoutilisateur, avec un shell de connexion root sur la console et aucune invite de mot de passe. La sécurité physique est indispensable dans de tels cas.
L'initialisation d'un ordinateur sans disque n'est pas totalement sécurisée. Quelqu'un pourrait usurper l'identité du serveur d'amorçage et initialiser un noyau retors qui, par exemple, effectuerait un enregistrement de la clé secrète sur un ordinateur distant. Le système NFS sécurisé offre une protection uniquement lorsque le noyau et les clés du serveur sont en cours d'exécution. Dans le cas contraire, aucun moyen ne permet d'authentifier les réponses qui sont données par le serveur d'initialisation. Cette limitation pourrait être un problème grave, mais la limitation nécessite une attaque sophistiquées, à l'aide du code source du noyau. En outre, il resterait des preuves du crime. Si vous avez interrogiez le réseau pour les serveurs d'initialisation, vous pourriez détecter l'emplacement du serveur d'initialisation retors.
La plupart des programmes setuid appartiennent à root. Si la clé secrète pour root est stockée dans /etc/.rootkey, ces programmes se comportent comme ils ont toujours fait. Si un programme setuid est détenu par un utilisateur, cependant, le programme setuid risque de ne pas toujours fonctionner. Par exemple, supposons qu'un programme setuid est détenu par dave et que dave ne s'est pas connecté à l'ordinateur depuis qu'il a démarré. Le programme ne sera plus capable d'accéder aux services de réseau sécurisé.
Si vous vous connectez à un ordinateur distant (à l'aide de login, rlogin ou telnet) en utilisant keylogin pour obtenir l'accès, vous ouvrez l'accès à votre compte. Votre clé secrète est transmise au serveur de clé de l'ordinateur qui stocke ensuite votre clé secrète. Ce processus est un problème uniquement si vous ne faites pas confiance à l'ordinateur distant. Si vous avez des doutes, cependant, ne vous connectez pas à un ordinateur distant si l'ordinateur distant nécessite un mot de passe. Au lieu de cela, utilisez l'environnement NFS pour monter des systèmes de fichiers qui sont partagés par l'ordinateur distant. Vous pouvez également utiliser keylogout pour supprimer la clé secrète du serveur de clés.
Si un répertoire d'accueil est partagé avec l'option –o sec=dh, établir des connexions distantes peut être un problème. Si les fichiers /etc/hosts.equiv ou ~/.rhosts ne sont pas définis pour demander un mot de passe, la connexion est établie. Toutefois, les utilisateurs ne peuvent pas accéder à leurs répertoires d'accueil car aucune authentification n'a été effectuée localement. Si les utilisateurs sont invités à saisir un mot de passe, ils ont accès à leurs répertoires personnels si le mot de passe correspond au mot de passe du réseau.