Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
nis [Le 07/05/2018, 10:47]
78.252.111.98 [Configuration du client NIS] révision mineure (orthographe...)
nis [Le 07/05/2018, 11:21] (Version actuelle)
78.252.111.98 [Sécurité]
Ligne 80: Ligne 80:
 ===== Sécurité ===== ===== Sécurité =====
  
-NIS est quelque chose de dangereuxN'​importe qui pouvant accéder au démon ​peut récupérer ​vos listes de mots de passe. ​Si ils peuvent le faire alors ils ont vos mots de passe. Peu importe qu'ils soient ​cryptés; il sont l'​équivalent des mots de passe clairs ​depuis que l'authentification s'​effectue à l'aide de mots de passe cryptés vous n'avez pas besoin du mot de passe clair, il faut juste écrire une application qui présentera ​correctement la version ​cryptées ​au système d'​authentification. Aussi assurons nous que cela n'arrive pas. Comment? Et bien, d'​abord en restreignant les accès:  +NIS est un service qui comporte des risques en terme de sécuritéTout utilisateur malveillant ayant accès a serveur ​peut récupérer ​les listes de mots de passe. ​Qu'ils soient ​stockés en clair ou chiffréscette information reste exploitable. Il suffit d'​écrire une application qui présente ​correctement la version ​chiffrée du mot de passe au système d'​authentification ​pour qu'elle soit authentifiée.
-  * N'​autorisez que certains membres du domaine à contacter les services appropriés dans le "​hosts.allow"​. Ceci implique que le "​hosts.deny"​ est paramétré à **ALL** afin que cela fonctionne.  +
-  * Limitez les clients à qui le serveur répondra en mettant les membres du domaine dans "/​etc/​securenets" ​.+
  
-Bien, nous avons restreint l'accès à des adresses IP spécifiqueson est doué quand même, non ? Et bien, pas tant que ça. Que se passe-t-il si quelqu'​un ejecte une de vos machines ​ du réseau,lui pique son adresse IP et récupère ​le fichier ​de mot de passe ? Vous êtes mort. **Solution:** **IPSec** (Allez voir le **IPSecHowTo**)Vous pouvez ​paramétrer tous les membres ​de votre domaine à ne communiquer ​que sur IPSec ce qui permettra ​de vérifier ​que vos clients sont bien qui ils affirment êtreComment? Et bien, le client crypte le trafic à destination du serveur avec la clé du serveur, et le serveur répond à chaque demande en cryptant avec la clé du client. Le trafic est décrypté avec les clés respectives. Ainsi, un client ne disposant pas des clés qu'il est supposé avoir ne pourra ni envoyer ni recevoir de données. Le fichier contenant les clés et raisonnablement protégé (lisible ​que par root), vous ne pouvez obtenir les clés sans compromettre le client. ​Si vous compromettez le client, ​vous pouvez tout de même obtenir la liste de mots de passe, ainsi l'​attaquant vous aura tout de même (ce qui est une faille dans la plupart des systèmes d'​authentification de domaine). ​+Pour éviter ce genre d'attaqueil est primordial ​de contrôler qui a accès à cette information : 
 +  * [[:​tutoriel:​comment_editer_un_fichier|Éditer ​le fichier]] **/​etc/​hosts.allow** et référencer les clients légitimes pour chaque service. [[:tutoriel:​comment_editer_un_fichier|Éditer le fichier]] ​**/​etc/​hosts.deny** avec **ALL** afin que cela fonctionne. 
 +  * [[:​tutoriel:​comment_editer_un_fichier|Éditer ​le fichier]] ​**/​etc/​securenets** afin de limiter à quels clients membre du domaine le serveur répondra. 
 + 
 +Ceci ne suffit cependant pas à prévenir le cas où une machine ennemie prend l'​adresse IP d'un client légitime. Pour prévenir ce genre de situation, il faut s'​appuyer sur [[http://​www.ipsec-howto.org/​t1.html|IPSec]]. L'​idéal est de paramétrer tous les membres ​du domaine ​de sorte à ce qu'​ils ​ne communiquent ​que par IPSec. Ceci permet ​de s'​assurer ​que chaque client est légitimeEn effet, le client crypte le trafic à destination du serveur avec la clé du serveur, et le serveur répond à chaque demande en cryptant avec la clé du client. Le trafic est décrypté avec les clés respectives. Ainsi, un client ne disposant pas des clés qu'il est supposé avoir ne pourra ni envoyer ni recevoir de données. Le fichier contenant les clés est raisonnablement protégé (il n'​est ​lisible ​qu'​avec des droits [[:root|root]]). Les clés peuvent être obtenues ​sans compromettre le client. 
 + 
 +Toutefois, si un client ​légitime est compromisl'​attaquant peut obtenir la liste de mots de passe (ce qui est une faille dans la plupart des systèmes d'​authentification de domaine). ​
  
  
  • nis.txt
  • Dernière modification: Le 07/05/2018, 11:21
  • par 78.252.111.98