Comment sécuriser plusieurs serveur sous NIS
ric22
Messages postés
3
Statut
Membre
-
ric22 Messages postés 3 Statut Membre -
ric22 Messages postés 3 Statut Membre -
Bonjour,
J'ai un soucis de sécurité et je suis à cours d'idée :(
Nous avons un serveur principal sous solaris 9 qui fait office de serveur NIS et de serveur de fichiers pour les utilisateurs (/home/<user> exporté en NFS vers les autres serveurs). Mot de passe root inconnu des utilisateurs. Ainsi les utilisateurs peuvent se connecter sur n'importe quel serveur unix client NIS et retrouver leur environnement habituel.
Par contre, nous avons 3 serveurs linux (client NIS et /home du solaris monté en NFS) servant de test et dev. Les utilisateurs peuvent se connecter directement sous leur comptes grace à NIS/NFS, mais ils connaissent aussi le pwd root de ces 3 serveurs (obligé cause tests d'install)...
S' ils se connectent en root local des serveurs test, ils ne peuvent acceder aux repertoires /home exporté, mais rien ne les empeche de faire un "su <utilisateur NIS>" pour se retrouver dans le repertoire de l'utilisateur avec tous ses droits :( !
le fait que le pwd root soit different entre le serveur maitre NIS et les clients n'y change rien. A partir du moment ou qqn à le pwd root d'un serveur client, il peut acceder à toutes les données utilisateurs !
Je ne sais comment remedier à ceci... Si quelqu'un à la solution (differencier le root des serveurs de test et celui du serveur principal ?), il est le bienvenu !
Merci en tout cas...
J'ai un soucis de sécurité et je suis à cours d'idée :(
Nous avons un serveur principal sous solaris 9 qui fait office de serveur NIS et de serveur de fichiers pour les utilisateurs (/home/<user> exporté en NFS vers les autres serveurs). Mot de passe root inconnu des utilisateurs. Ainsi les utilisateurs peuvent se connecter sur n'importe quel serveur unix client NIS et retrouver leur environnement habituel.
Par contre, nous avons 3 serveurs linux (client NIS et /home du solaris monté en NFS) servant de test et dev. Les utilisateurs peuvent se connecter directement sous leur comptes grace à NIS/NFS, mais ils connaissent aussi le pwd root de ces 3 serveurs (obligé cause tests d'install)...
S' ils se connectent en root local des serveurs test, ils ne peuvent acceder aux repertoires /home exporté, mais rien ne les empeche de faire un "su <utilisateur NIS>" pour se retrouver dans le repertoire de l'utilisateur avec tous ses droits :( !
le fait que le pwd root soit different entre le serveur maitre NIS et les clients n'y change rien. A partir du moment ou qqn à le pwd root d'un serveur client, il peut acceder à toutes les données utilisateurs !
Je ne sais comment remedier à ceci... Si quelqu'un à la solution (differencier le root des serveurs de test et celui du serveur principal ?), il est le bienvenu !
Merci en tout cas...
A voir également:
- Comment sécuriser plusieurs serveur sous NIS
- Changer serveur dns - Guide
- Serveur dns gratuit - Guide
- Serveur entrant et sortant - Guide
- Comment désactiver le mode sécurisé - Guide
- Comment sécuriser un dossier sur pc - Guide
4 réponses
Pour avoir connu à peu près le même cas, à mon avis pas beaucoup de solutions, root == tout le pouvoir.
- séparer les machines Linux du réseau NIS
- limiter l'export Solaris NFS et placer les uilisateurs Linux sur les Linux
- utiliser des outils qui ne donnent les droits root que pour certaines commandes comme RBAC, sudo
- séparer les données utilisateurs Linux sur les serveur Solaris sur 2 volumes et changer les règles d'export
- séparer les machines Linux du réseau NIS
- limiter l'export Solaris NFS et placer les uilisateurs Linux sur les Linux
- utiliser des outils qui ne donnent les droits root que pour certaines commandes comme RBAC, sudo
- séparer les données utilisateurs Linux sur les serveur Solaris sur 2 volumes et changer les règles d'export
Merci pour la réponse ! J'etais malheureusement arrivé à a peu pres cette conclusion :(
En fait je vais shooter la commande "SU' sur les serveurs test. Ainsi, les utilisateurs se logeront soit avec leur login/pwd (no pb), soit directement en root, mais dans ce cas ils ne pourront plus faire un SU <utilisateur>. Il faudra qu'ils se deconnectent -> demande de pwd...
C'est un peu plus lourd pour eux mais faut faire un choix !
En fait je vais shooter la commande "SU' sur les serveurs test. Ainsi, les utilisateurs se logeront soit avec leur login/pwd (no pb), soit directement en root, mais dans ce cas ils ne pourront plus faire un SU <utilisateur>. Il faudra qu'ils se deconnectent -> demande de pwd...
C'est un peu plus lourd pour eux mais faut faire un choix !
Effectivement, mais comme root il peuvent en récupérer une ailleurs, faire un prog. C ou un script en SUID ... . Créer un .rhost chez l'utilisateur et faire un rlogin, faire passwd pour changer le mot de passe d'un utilisateur, etc, etc
Sinon sudo qui permet de limiter les commandes exécutables en tant que root.
chez nous, la solution avait été PAS DE ROOT
faire un mini su c'est aussi simple que
echo /bin/ksh > zzz
chown user zzz
chmod 4700 zzz
./zzz
ici, je suis user, pas root
Sinon sudo qui permet de limiter les commandes exécutables en tant que root.
chez nous, la solution avait été PAS DE ROOT
faire un mini su c'est aussi simple que
echo /bin/ksh > zzz
chown user zzz
chmod 4700 zzz
./zzz
ici, je suis user, pas root
oui, j'imagine que ce n'est pas dur de contourner le shootage du SU, mais c'est juste pour éviter de tenter les utilisateurs (trop rapide de faire un su <login> ).
Apres la majorité sont des ingés en info qui n'auraient aucun mal à acceder à certaines données si ils se donnait un peu de temps pour le faire, mais dans ce cas ce serait une volonté délibéré d'acceder à des données non permises. (et ils ne s'en sortiraient pas avec un "oops, je me suis trompé dans mon 'su').
C'est une démarche plus pour responsibiliser les users que mettre les datas dans un coffre fort...
Apres la majorité sont des ingés en info qui n'auraient aucun mal à acceder à certaines données si ils se donnait un peu de temps pour le faire, mais dans ce cas ce serait une volonté délibéré d'acceder à des données non permises. (et ils ne s'en sortiraient pas avec un "oops, je me suis trompé dans mon 'su').
C'est une démarche plus pour responsibiliser les users que mettre les datas dans un coffre fort...
