Faut-il désactiver l'utilisateur root?


21

Faut-il supprimer le mot de passe root, désactiver la connexion à distance et obliger les administrateurs à utiliser sudo pour effectuer des actions administratives?

texte alternatif

Réponses:


16

Tous mes serveurs ont le compte root désactivé ( sp_pwdpdéfini sur *). Ceci est nécessaire sudopour tous les accès root. [1] Le but de ceci est de faire auditer toutes les activités des super-utilisateurs, afin que les gens puissent voir ce qui a été fait au système.

Pour une option plus hardcore, vous pouvez faire de l' sudoécriture dans un fichier journal (par opposition à syslog), et rendre le fichier en ajout uniquement (en utilisant chattrsous Linux ou chflagsBSD). De cette façon, personne ne peut modifier l'audit par la suite.

[1] J'ai également pour politique de ne pas exécuter un shell root, ou de faire des échappements shell à partir d'un processus root. ( sudo sh -c '...'Cependant, vous pouvez l'utiliser pour faire des pipelines ou des redirections.)


3
"Pas de tir d'obus non plus!" Uhm, savez-vous combien de programmes contiennent une commande "drop to shell"? Avant même de commencer à étudier le contrôle des tâches de shell ...
womble

Je parle de "pas de shell" comme une politique, pas comme une option sudo. (sudo a une option noexec, mais ce n'est évidemment pas étanche à moins que vous ne restreigniez les programmes spécifiques qu'un utilisateur est capable d'exécuter.)
Chris Jester-Young

Est-il possible de configurer sudo pour que "sudo -s" ne puisse pas être utilisé? Je n'ai utilisé que sudoers pour configurer des commandes individuelles.

@Graham: Vous le pouvez. Cependant, comme vous pouvez le voir dans les commentaires ci-dessus, cela n'arrête rien, si vos utilisateurs peuvent autrement exécuter quoi que ce soit. La seule solution étanche est une approche de liste blanche, où vous listez des programmes spécifiques que les utilisateurs peuvent exécuter, et ils doivent tous être liés dynamiquement (pour que l'option "noexec" puisse faire son travail).
Chris Jester-Young,

En tant que politique où vous faites confiance aux administrateurs, c'est bien. Vous pouvez voir quelles commandes les gens exécutent, ce qui peut être très utile lorsque vous essayez de comprendre ce qui a changé.
Hamish Downer

15

Je catégoriquement déconseille de désactiver l'utilisateur root. Désactivez ou limitez les connexions root (via securetty et via sshd_config et via PAM et via ce que vous avez) Si votre système le permet, limitez les privilèges de root ou divisez le rôle root (semblable à la façon dont RSBAC le fait.) Mais s'il vous plaît, s'il vous plaît , faites ne pas désactiver le compte root en supprimant le mot de passe, sinon il deviendra impossible de se connecter au système via sulogin. suloginest utilisé par tous les scripts que je connais en cas d'erreurs graves signalées par fsck - et cela signifie que vous serez verrouillé hors du système si le système de fichiers racine est corrompu.

Pour clarifier: Par «désactiver le compte root en supprimant le mot de passe», je veux dire les différents mécanismes qui aboutissent à un! ou un * dans le champ de mot de passe de / etc / shadow, ou similaire. Je ne veux pas dire "changer le mécanisme de connexion root afin que vous ne soyez pas invité à entrer un mot de passe".


Est-ce un problème dans des systèmes comme Ubuntu qui ne définissent jamais de mot de passe root? Il me semble que je peux exécuter "sudo sulogin", mais je ne comprends peut-être pas un aspect critique.
jldugger

Malheureusement, je ne connais pas la façon dont Ubuntu gère root. Mais si vous êtes capable de faire "sudo sulogin" et d'obtenir un shell root sans être invité à entrer un mot de passe root, alors non, ce n'est pas un problème, car le même mécanisme s'appliquera probablement au démarrage. Vous pouvez essayer de chercher du sulogin à travers les scripts pour vérifier quand et comment il est invoqué.
Mihai Limbăşan

1
Ubuntu n'utilise pas sulogin. Si vous passez en mode mono-utilisateur, vous obtenez immédiatement un shell racine. Cependant, lisez mon commentaire (dans mon article) pour voir pourquoi ce n'est pas un problème, dans la plupart des cas.
Chris Jester-Young

En outre, certains prétendent que le fait d'avoir suou sudode mettre votre système à la disposition des utilisateurs signifie plus de risques de sécurité que vous pouvez éviter si vous n'avez que des utilisateurs root dédiés. C'est une position défendue par les auteurs de la distribution sécurisée Owl (et le concepteur solaire parmi eux) - unix.stackexchange.com/questions/8581/… essaie de présenter leur position avec des références.
imz - Ivan Zakharyaschev

Je viens d'avoir ce problème: j'ai verrouillé mon utilisateur root et un fsck a été forcé à cause d'une réinitialisation matérielle. Heureusement, j'ai pu démarrer mon Linux défectueux avec l' fastbootoption, déverrouiller le compte root et redémarrer pour enfin exécuter fsckmanuellement.
tommyd

3

J'ai le compte root activé sur tous mes serveurs. Tous les administrateurs ont leur propre utilisateur et doivent s'y connecter. De là, ils passent à root. (root ssh est désactivé)

Gardez le nombre d'administrateurs bas. Seules les personnes qui ont vraiment besoin d'un accès root sur ce serveur ont le mot de passe.

Je ne suis pas fan de sudo. C'est beaucoup trop facile de faire simplement 'sudo bash' pour un shell root. Je sais que cela peut être désactivé, mais pourquoi s'embêter? Limitez simplement les utilisateurs qui peuvent effectuer des tâches d'administrateur et parler entre eux. Nous avons une politique pour ne pas laisser les terminaux root s'ouvrir sans surveillance. C'est donc se connecter, su, faire le travail, se déconnecter.

Remarque: Je travaille dans une assez petite entreprise (50 employés quelque chose) et nous nous déplaçons avec seulement 2 administrateurs à temps partiel (1 windows / 1 linux). Cette façon de faire n'est peut-être pas la meilleure lorsque vous avez plusieurs ordres de grandeur d'utilisateurs. Personnellement, je n'utiliserais toujours pas sudo. Il existe d'autres façons de consigner l'activité racine.


Si vous voulez un shell root à partir d'une console, vous pouvez simplement faire 'sudo -i' au lieu de l'ouvrir depuis sudo bash. Personnellement, je n'aime vraiment pas l'idée de me connecter directement en tant qu'utilisateur root, car elle est trop risquée pour la navigation malveillante (c'est-à-dire laisser accidentellement l'ordinateur déverrouillé avec le shell root ouvert).
Spoike

Cependant, vous perdez la journalisation / l'audit avec cela. Faites en sorte que tout le monde utilise sudo et interdisez aux gens de faire sudo bash, ou sudo -i, ou sudo -s avec la politique de l'entreprise. Cela vous donne une piste d'audit, et si vous poussez tous vos journaux vers un hébergeur central, il est facile de vérifier que les gens suivent les politiques.
Christopher Cashell,

C'est l'approche adoptée et préconisée par les auteurs de la distribution sécurisée Owl (et le concepteur solaire parmi eux) - unix.stackexchange.com/questions/8581/… essaie de présenter leur position avec des références.
imz - Ivan Zakharyaschev

2

La désactivation du mot de passe root est à mon humble avis une fausse "bonne idée". Le jour où vous en aurez besoin, vous en aurez vraiment besoin. (selon votre configuration vous pourriez en avoir besoin pour vous connecter en mode mono-utilisateur par exemple)

La désactivation de la connexion à distance root peut être pertinente, mais uniquement si vous pouvez vous connecter localement.

Et oui, sudo devrait être installé sur chacun de vos serveurs. Il est utile et facile à configurer. Pourquoi voudriez-vous ne pas l'utiliser?


Que faire si le démarrage en mode mono-utilisateur est une option grub?
jldugger

Quel est le but de désactiver le compte root? Que ferez-vous si vous freinez votre binaire ou configuration sudo (ou quel que soit l'outil que vous utilisez)?
Benoit

Disabling root remote login might be relevant but only if you are able to log on locally.C'est tout simplement faux. Vous pouvez vous connecter à distance avec n'importe quel compte; la désactivation de la connexion à distance root ne vous limite pas à l'accès local.
Dan

2

Je désactive simplement l'accès SSH pour root et demande aux utilisateurs (souvent des développeurs) d'utiliser des clés ssh. Il y a tout simplement trop d'attaques par dictionnaire et changer le port SSH n'est pas une option pour nous.

De cette façon, vous n'avez pas à faire confiance à la capacité de quiconque à écrire un bon mot de passe. Une fois à l'intérieur, seuls les administrateurs ont des autorisations pour sudo.


Changer le port SSH est de toute façon inutile. Un simple portscan le révèle facilement. Quand je telnet au port 22 sur ma machine, j'obtiens SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2
Matt Simmons

@MattSimmons Oui, mais la plupart des attaques par dictionnaire sont automatisées et très élémentaires. Ils ne se soucient pas de l'analyse des ports; ils tentent de se connecter à des adresses IP aléatoires sur le port 22 et s'ils expirent, ils passent à l'IP suivante dans leur liste. Ce n'est pas une mesure de sécurité, cela aide simplement à se débarrasser des attaques automatisées du port 22. De toute évidence, une attaque ciblée est un tout autre jeu de balle.
Dan

2

Je sais que ce fil est vraiment ancien mais il y a des défauts majeurs dans la logique des articles liés et je me sens "rant'ie" - sudo autorise à la fois la liste blanche et la liste noire. Pas seulement noir comme ils le spécifient dans l'article lié - Cela saute sur l'idée de AAA (authentification, autorisation et audit) - su & sudo permet à la fois une authentification graduée et une responsabilité.

Scénario 1 Un administrateur introduit accidentellement du code non autorisé dans un système, connecté en tant que root, le code a un accès complet et l'administrateur peut ne jamais savoir ce qui s'est passé. Au moins avec des connexions graduées (par exemple su / sudo), l'administrateur serait invité à s'authentifier si le code voyou essaie d'utiliser des droits élevés ... S'il n'élève pas, il est limité aux droits des utilisateurs, ce qui devrait entraîner un minimum de dommages.

Scénario 2 Un administrateur escroc veut obtenir des informations / apporter une modification. Ils se connectent à la console (accès à la console physique, HP iLo / similaire ou accès à la console vGuest), se connectent en tant que root et font ce qu'ils souhaitent. À moins qu'un compte / carte d'accès nommé ne soit utilisé pour accéder à la console, il n'y a probablement pas beaucoup de piste d'audit.

  1. Assurez-vous qu'ils sont vraiment ce qu'ils prétendent être. Le vol d'identité n'est pas le problème, la vérification d'identité l'est.
  2. Vérifiez leur autorisation, ne leur donnez que ce dont ils ont besoin à ce moment-là. Une autorisation graduée leur permet d'élever lorsqu'ils en ont besoin.
  3. Vérifiez tout cela, ayez un dossier pour savoir qui a fait quoi, quand et où. De préférence pourquoi aussi

1

Vous devez obliger tout le monde à utiliser sudo pour chaque commande root en tant que stratégie. Il n'y a jamais de raison d'exécuter "sudo bash" ou similaire, c'est uniquement pour des raisons de commodité, en raison de l'ignorance, ou pour couvrir ses traces.

Si vous désactivez les connexions au compte root directement, vous paralysez votre capacité à réparer le système en cas de problèmes graves.

Si vous ne pouvez pas convaincre vos administrateurs de se connecter en tant qu'eux-mêmes et d'exécuter sudo pour chaque commande exécutée en tant que root, et de ne pas en sortir dans un shell, vous avez de graves problèmes pour lesquels il n'y a pas de solution technique.


1

Les auteurs de Owl secure distribuion (et Solar designer) ont un point de vue opposé soigneusement justifié; voir, par exemple, la réponse /unix/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 pour une présentation de leurs revendications. Le problème de l'audit des actions du superutilisateur (quelle personne a fait quoi) est également abordé dans leur point de vue (fondamentalement, la solution est d'avoir plusieurs utilisateurs root avec des noms différents).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.