Réponses:
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.)
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".
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.
fastbootoption, déverrouiller le compte root et redémarrer pour enfin exécuter fsckmanuellement.
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.
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?
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.
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.
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.
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.
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).