Comment renommez-vous root?

Non pas que ce soit une très bonne idée de le changer, mais pour le plaisir. Selon ce poste, il y a encore quelques problèmes , même après avoir changé entrées /etc/passwd, /etc/shadowet /etc/sudoers. Aucune suggestion?

Théoriquement, le changer /etc/passwdet /etc/shadowserait tout ce dont vous avez besoin pour «renommer» la racine. Le problème se produit car à peu près tous les logiciels Unix existants supposent que le nom d'utilisateur «root» existe et qu'il s'agit du superutilisateur - alias de messagerie, divers démons, cron ...

Si vous êtes vraiment déterminé à l'essayer, cela find /etc -type f -exec grep -l root {} +devrait être un bon début pour trouver une liste de tous les fichiers de configuration que vous devrez probablement changer - mais comme vous l'avez déjà dit, c'est une très mauvaise idée dans presque toutes les situations imaginables.

EDIT Une autre pensée - si vous ne l'avez pas déjà fait (ce que vous devriez avoir), assurez-vous qu'il /etc/aliasescontient une entrée pour rootet un nom d'utilisateur qui existe ou une adresse e-mail qui évalue correctement. Un grand nombre de tâches automatisées à l'échelle du système ( cronpar exemple) envoient leur sortie par courrier électronique à root, qui est traditionnellement alias aux administrateurs système responsables des opérations de ce système.

Toute cette peur qui fait peur, en disant "Ne le fais pas!" est ridicule. À un moment donné, oui, cela a probablement cassé beaucoup de scripts mal écrits, mais je soupçonne que ceux-ci ne sont plus si courants; du moins pas dans les distributions standard.

On nous a dit de renommer le compte root sur un sous-ensemble de serveurs Linux. Ainsi, après avoir tenté de rechercher comment procéder correctement, j'ai trouvé à la place de nombreux messages disant "Ne le faites pas!" avec de nombreux avertissements terribles de "mauvaises choses" qui se produisent si vous choisissez de le faire. Mais je n'en ai pas encore trouvé d'exemples concrets des "mauvaises choses" qui pourraient arriver.

Alors, permettez-moi de revenir en arrière et d'expliquer où je suis, et comment nous sommes arrivés ici. Nous construisons un environnement conforme à la norme PCI, et l'un des outils qui nous aide à répondre à ces «exigences» nous dit que nous devons renommer les comptes racine et administrateur et les comptes invités en autre chose. Pour ceux qui ne sont pas éduqués sur PCI, vous avez la possibilité de suivre les directives ou de documenter pourquoi vous ne pouvez pas ou choisissez de ne pas suivre ces directives, et quelle stratégie d'atténuation vous avez pour assurer la sécurité des systèmes. Donc, j'imagine que la plupart des endroits documentent pourquoi ils ne vont pas renommer leurs comptes root, cependant, notre groupe a décidé que, si nous pouvons renommer les comptes d'administrateur Windows sans problème, nous allons également renommer les comptes root linux.

Je connais bien les arguments de la «sécurité par l'obscurité»; Je sais que le simple fait de changer le nom du compte root n'améliore pas vraiment la sécurité, root devrait être désactivé chez SSH, etc. Je ne suis pas non plus intéressé par plus d'avertissements "le ciel va tomber". Je recherche des déclarations comme celle-ci: "> cette mauvaise chose <se produira avec> ce package standard <(sauf si vous> faites cela <)".

Jusqu'à présent, j'ai 3 systèmes CentOS (RHEL) qui n'ont apparemment aucun problème avec le changement de nom du compte root. Voici ce que j'ai fait: j'ai changé le nom du compte dans / etc / passwd, / etc / shadow, / etc / group et / etc / gshadow. Ensuite, j'ai recherché le nom root dans / etc / et modifié le fichier d'alias postfix pour que root soit un alias de notre nouveau nom de compte, appelez-le rojotoro. (Quelque chose de similaire devrait être fait pour les autres systèmes de messagerie). J'ai également constaté que je devais changer certaines configurations pour logrotate lors de la description des propriétaires des fichiers qu'il créerait automatiquement. Et c'est tout ce que j'ai changé jusqu'à présent.

J'ai regardé de nombreux scripts init.d, mais je n'ai rien changé, et tout semble bien commencer au démarrage. Je dois spécifier le nouveau compte lors de l'utilisation de sudo: "sudo -u rojotoro vim / etc / passwd" comme exemple, mais je n'ai en fait pas besoin de changer quoi que ce soit dans le fichier sudoers. Je m'attendais peut-être à des problèmes avec selinux que nous avons et appliquons, mais jusqu'à présent, je n'ai pas eu besoin de toucher à ce système.

Je peux également voir que les scripts mkdev ou mkfs peuvent avoir besoin d'être ajustés, mais je n'ai pas l'intention de les utiliser, donc je ne les ai pas examinés avec le contrôle qu'ils méritent.

S'il est vraiment aussi facile de changer sans aucun effet néfaste sur un système compatible selinux, pourquoi la poursuite de tous les alarmistes?

suggestion: ne faites pas ça.

Certains outils essaient de parler à root via uid, là vous ne devriez pas avoir de problèmes. certains outils supposent que votre compte root est appelé root et se cassera. à moins que vous ne soyez prêt à recompiler la moitié de votre système "pour le plaisir", n'essayez pas.

À mon avis, la chose la plus simple à faire est de créer un nouvel utilisateur (alias), avec UID 0 et /rootcomme domicile.

Pourquoi ne pas basculer le shell par défaut de votre racine sur /bin/falseou /sbin/nologin(pour que personne ne puisse s'y connecter, mais le système l'utilise toujours) et vous connecter au nouvel alias créé?

razvan@naboo ~ $ head -2 /etc/passwd
root:x:0:0:root:/root:/bin/nologin
root2:x:0:0:root:/root:/bin/bash
razvan@naboo ~ $ su -
Password:
su: Authentication failure
razvan@naboo ~ $ su root2
Password:
naboo razvan # whoami
root

Si vous changez le shell de root en nologin, le sudo, mail ou ftw ne seront pas endommagés.

Linux n'est pas Windows et root ne peut actuellement pas être renommé facilement sans créer de futurs problèmes inconnus.

La désactivation de la connexion distante et même locale en tant que root est une approche plus sûre car elle désactive activement la racine du compte! UBUNTU fait essentiellement cela et force sudo au lieu de l'accès root.

Essentiellement, personne ne peut utiliser le compte root pour attaquer votre système car il ne peut plus être utilisé pour se connecter au système!

Ce serait bien si un moyen standard était créé pour modifier facilement le nom du compte root ainsi que générer aléatoirement son UID lors de l'installation et si possible à chaque démarrage à froid pour empêcher le ciblage UID mais qui n'existe pas actuellement.

Ajuster / etc / passwd Modifier root: x: 0: 0: root: / root: / bin / nologin

Créez un seul compte administrateur de secours pour l'UTILISATION D'URGENCE UNIQUEMENT! fallbackadmin: x: 0: 0: root: / root: / bin / bash

Implémentez sudo pour tous les administrateurs afin que l'audit du journal des modifications puisse être implémenté pour suivre avec précision qui apporte des modifications pour la responsabilité!

Cela implémente les exigences PCI US Gov pour désactiver les comptes administrateur / invité par défaut et créer un compte administrateur à usage d'urgence unique.

Une façon d'archiver les journaux pour l'audit consiste à collecter l'historique du terminal de tous les utilisateurs avec un accès au compte sudo si l'AAA centralisé n'est pas implémenté.

Une solution pour implémenter des comptes administrateur uniquement consiste à créer un compte utilisateur uniquement et un compte activé sudo, puis forcer l'utilisateur à accéder à son compte activé sudo pour un accès administratif.

Vous pouvez également implémenter l'authentification par carte à puce si vous souhaitez une meilleure sécurité. Il existe des solutions disponibles pour GNU / Linux qui se comparent aux solutions CAC de la carte d'accès commune américaine pour l'authentification à deux facteurs.