Question:
Pourquoi la désactivation de root est-elle nécessaire pour la sécurité?
Randomblue
2016-02-16 03:04:36 UTC
view on stackexchange narkive permalink

Cette page sur le renforcement des serveurs prétend:

La désactivation du compte root est nécessaire pour des raisons de sécurité.

Pourquoi désactiver le compte root nécessaire pour des raisons de sécurité?

Je crois que votre réponse se trouve dans la section juste au-dessus de votre citation "Créer un" utilisateur fantôme "avec des pouvoirs sudo"
Le lien suggère uniquement de désactiver le mot de passe du compte root en utilisant [passwd -l] (http://man7.org/linux/man-pages/man1/passwd.1.html), pas de désactiver le root compte d'une manière plus grande. Vous pouvez toujours faire «su».
BTW, je ne peux pas dire que je pense que c'est un excellent article.
Si vous utilisez un serveur Ubuntu, essayez `tail -f / var / log / auth.log` et voyez combien d'attaquants essaient de se connecter en tant que root.
Un compte root non désactivé n'est protégé que par la force de son mot de passe. Si ce mot de passe est compromis, votre système est compromis.
Et tout cela reflète essentiellement que le modèle de sécurité original sous Unix de root étant omnipotent ne fonctionne pas bien dans le monde de l'Internet. Une granularité plus fine est nécessaire.
Une page sur le durcissement du serveur qui continue longuement sur l'importance de sécuriser / tmp, mais parvient à confondre / tmp et / var / tmp ([ce ne sont pas les mêmes!] (Http: //www.pathname. com / fhs / pub / fhs-2.3.html # VARTMPTEMPORARYFILESPRESERVEDBETWEE)) et en quelque sorte * ne pas * mentionner [libpam-tmpdir] (https://launchpad.net/ubuntu/trusty/+package/libpam-tmpdir)? Bien qu'il y ait certainement de bonnes suggestions, il est clair que cette page ne devrait * pas * être considérée comme un évangile.
Related, from Unix Stack Exchange: [Quel est le moyen le plus sûr d'obtenir les privilèges root: sudo, su ou login?] (Http://unix.stackexchange.com/questions/8581/which-is-the-safest-way- pour-obtenir-les-privilèges-root-sudo-su-ou-login /)
@ThorbjørnRavnAndersen: "Un compte root non désactivé n'est protégé que par la force de son mot de passe": Donc, si l'on désactive la connexion par mot de passe pour root et utilise à la place une paire de clés ssh, le problème est résolu! Ou est-ce?
@SteveJessop c'est un pas dans la bonne direction. Vous voudrez peut-être voir ce qu'Apple a fait avec "rootless" dans OS X. http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really
Six réponses:
Ohnana
2016-02-16 03:12:38 UTC
view on stackexchange narkive permalink

Si vous n'utilisez pas Root, vous utilisez sudo! Sudo est un excellent moyen de devenir root uniquement lorsque vous en avez besoin.

  1. Root est une cible géante. Quel est le nom d'utilisateur de root? Racine! Je suis si intelligent :)
  2. Journalisation. Sudo a une plus grande maîtrise de la journalisation d'audit (de sorte que lorsque quelqu'un utilise sudo pour faire quelque chose de stupide, vous pouvez le signaler au serveur de journalisation central). Dans certains cas, cela est utile pour l'analyse médico-légale.
  3. Autorisations granulaires. La racine est un grand marteau flippin. Ne donnez pas de BFH à vos utilisateurs. Sudo vous permet de spécifier qu'un utilisateur peut exécuter des commandes de mise à jour comme aptitude sans mot de passe, mais tout est interdit! Vous ne pouvez pas faire cela avec le BFH qui est root. L'informatique vous permet de sanctionner certaines commandes pour les utilisateurs, mais d'en interdire d'autres. Cela vous permet de créer une politique de sécurité qui n'exige pas qu'un administrateur se connecte physiquement à une machine chaque fois qu'une machine doit être mise à jour (ou une autre tâche secondaire).
  4. Anti-idiot. Pourquoi ne donnez-vous pas aux utilisateurs un BFH? Parce qu'ils sont stupides. Pourquoi utiliser sudo au lieu de root? Je suis stupide. Dumb signifie des erreurs, et les erreurs signifient des failles de sécurité et des problèmes d'administrateur système.
Ensuite, l'utilisateur tape: `sudo bash`
Et si vous disposez d'une stratégie d'audit appropriée, l'utilisateur verra: `Autorisation refusée. Cet incident sera signalé. »
Ensuite, l'utilisateur tape `SHELL = / mon / programme apt-get install ` et obtient un shell car un paquet a confondu `$ SHELL` pour` sh`.
Ou l'utilisateur crée un package avec un shell setuid, puis l'installe. Ou installez une ancienne version d'un démon racine qui a des vulnérabilités connues.
Bien que vous ayez un bon argument pour utiliser `sudo` sur le compte root, je ne suis pas sûr que vous ayez réellement un argument pour désactiver le mot de passe root.
@Gilles À moins que vous n'autorisiez uniquement les mises à jour ou que vous disposiez d'une liste blanche de packages.
@Ohnana vous pouvez faire tout cela tout en ayant un compte root activé. Vous ne devez le désactiver que si les personnes utilisant votre système doivent être obligées de suivre les règles (c'est-à-dire qu'elles sont stupides ou ne peuvent pas être entièrement fiables).
@TomLeek `sudo su` semble mieux fonctionner, car il configure correctement l'environnement, exécute un shell de connexion, etc.
@PyRulez Autoriser uniquement les mises à jour n'aiderait pas. Cependant, la configuration sudo par défaut sur de nombreuses distributions où elle nettoie la plupart des variables d'environnement, y compris `SHELL`, résout * cette * avenue d'escalade particulière. Il y en a probablement d'autres qui impliquent des packages avec une configuration interactive, bien que n'autoriser que les mises à niveau réduise beaucoup le risque.
@immibis Exécuter `sudo su` au lieu de` sudo bash` est à la fois sans importance (le point de Tom est que l'utilisateur exécute un shell, après quoi il peut faire tout ce qu'il veut) et inutile (`sudo su` ne" configure pas l'environnement correctement ”Pas plus que` sudo bash`, et n'exécute pas de shell de connexion - il exécute le shell de connexion de l'utilisateur (champ `pw_shell` de la base de données utilisateur), mais pas comme un shell de connexion (` -bash` ou similaire exécutez `.profile`)).
Mon seul problème avec cela est l'utilisation du terme «anti-idiot». On peut rendre un système infaillible, mais seulement résistant aux idiots. Une véritable protection contre les idiots est impossible, car l'Univers continue de fabriquer de meilleurs idiots.
On pourrait soutenir que l'utilisation d'un compte root dédié et le démarrage permanent d'un shell root est plus sûr que `sudo`, car` sudo` met en cache les informations d'identification (permettant à un programme malveillant de se cacher en arrière-plan et de se déplacer sur les coattails d'un légitime request), ou vous oblige à taper votre mot de passe si souvent que cela devient une habitude.
@Gilles @immibis l'implication est que l'utilisateur pourrait être malveillant, auquel cas l'utilisation de `sudo` n'est pas une option
@immibis, `sudo su` ne fait rien que` sudo -i` ne le fait pas, à part appeler inutilement des exécutables inutiles.
Alors pourquoi ne pas renommer root?
@Joshua qui est une chose incroyablement difficile à faire et qui vous hantera probablement pour le reste de la vie du système. Tout le monde dépend de la racine! Il est préférable de désactiver la connexion et de travailler à partir de là.
@Ohnana: vim / etc / password est facile. Les fichiers appartiennent à l'identifiant et non au nom.
@Joshua / etc / shadow, / etc / groups aussi. De plus, `find / etc -type f -exec grep -l root {} +` est le nombre de fichiers de configuration qui recherchent root en tant que root et non UID 0. Et cela ne compte pas tous les outils que vous pourriez avoir à recompiler pour le nouveau système configuration ... Dans un monde parfait, tout le monde dirait UID 0 au lieu de root, mais ces foutues bouchées continuent de tout mélanger.
Vous négligez le fait que je l'ai essayé avec succès.
La plus grande raison de la connexion sudo sur root pour moi: si vous devez donner un accès root à plusieurs personnes, vous voulez le révoquer pour une personne (par exemple, il ou elle quitte l'entreprise). Avec sudo, c'est simple. Si vous avez donné le mot de passe root à ces personnes, vous devez le changer et tout le monde doit mémoriser le nouveau mot de passe.
@Ohnana [Cet incident sera signalé] (https://xkcd.com/838/) en effet.
schroeder
2016-02-16 03:11:58 UTC
view on stackexchange narkive permalink

Le site vers lequel vous créez un lien ne vous explique pas très bien ce qu'il vous incite à faire. Le compte root n'est pas désactivé, mais le mot de passe pour root est désactivé. C'est ce que fait passwd -l .

Le but de ces instructions est de faire en sorte que les gens ne puissent pas se connecter en tant qu'utilisateur root, car le compte root est facile à deviner. Je ne suis pas sûr que leur approche de création d'un pseudo-utilisateur avec un "nom difficile à deviner" sera d'autant plus sûre ...

root est en effet la cible principale des bots ssh. Si vous oubliez de le désactiver dans `sshd_config`, le système d'exploitation vous sauvegardera.
Tom Leek
2016-02-16 03:12:25 UTC
view on stackexchange narkive permalink

C'est une vieille tradition de l'époque du Mainframe. L'idée est que root peut faire ce qu'il veut avec la machine, y compris le remplacement du noyau ou la destruction des variables UEFI, ce qui peut brique la machine. Alors qu'un compte non root ne le peut pas - à moins que ce compte ne dispose de droits administratifs via sudo , ce que vous aurez avec Ubuntu, et cela détruit totalement la justification ci-dessus.

Vraiment, la désactivation du compte root est désormais utilisée exclusivement pour apaiser les dieux aînés, qui:

  1. sont grincheux;
  2. sont obsolètes;
  3. sont morts depuis des décennies, mais sont toujours vénérés par une puissante caste de grands prêtres, collectivement appelés «auditeurs de conformité».

En pratique , votre vie numérique est entièrement accessible à partir de votre compte utilisateur normal, donc faire une protection relative à l'utilisateur root n'a pas beaucoup de sens. Le déblayage avec la distinction racine / non- racine appartient au passé, lorsque les machines étaient de gros serveurs partagés entre des centaines d'utilisateurs qui étaient peut-être hostiles les uns aux autres.

«votre vie numérique est complètement accessible depuis votre compte utilisateur normal» - demande OP dans le contexte du durcissement du * serveur *. Cela suppose un système de bureau.
De plus, `sudo` enregistre des trucs, je crois.
Il y a un aspect de responsabilité sur les machines multi-utilisateurs. Root est un compte générique, donc tout ce qui est fait par root ne peut pas être lié à un utilisateur (sauf si la connexion a été élevée à partir d'un compte d'utilisateur spécifique).
Cette réponse est-elle ironique? Ou utilisez-vous toujours l'authentification par mot de passe au lieu de paires de clés?
Mike McManus
2016-02-17 04:51:41 UTC
view on stackexchange narkive permalink

Veuillez noter que (au moins sur Ubuntu et ses dérivés), il y a un compromis à faire avec la désactivation du mot de passe root.

En cas de sinistre sur votre système, vous voudrez démarrer le système en mode de récupération (ou mono-utilisateur) à partir de la console. Si le mot de passe root est désactivé (comme c'est le cas par défaut), alors aucune authentification quelle qu'elle soit peut être requise lors du démarrage en mode mono-utilisateur, car le compte root n'a pas d'informations d'identification à utiliser à cette fin, et aucun autre compte ne peut être garanti de fonctionner dans ces circonstances. Ceci est géré par un code de cas spécial dans le programme sulogin.

Dans l'ensemble, cependant, c'est un échange facile à faire: vous évitez toute une classe d'attaques à distance tout en ouvrant le système à une racine non authentifiée Connectez-vous depuis la console physique. N'oubliez pas que vous ne pouvez jamais sécuriser un système contre un attaquant avec un accès physique à celui-ci de toute façon. C'est pourquoi il existe des centres de données sécurisés avec des contrôles d'accès électroniques.

Alexander C. Solon
2016-02-16 11:46:49 UTC
view on stackexchange narkive permalink

La racine est généralement désactivée pour fournir une couche supplémentaire de sécurité dans tout le système d'exploitation Linux. L'utilisateur root a la capacité de changer littéralement n'importe quoi, quelle que soit son importance. Cela en fait une cible courante de pirates, de virus, etc. Le désactiver (ou plutôt désactiver le mot de passe) garantit que le compte ne peut pas être connecté si le mot de passe est récupéré (ce n'est pas si difficile à faire).

En fait, il peut être assez difficile de "récupérer" un mot de passe root complexe sur les systèmes Linux modernes, malgré l'erreur de base de l'utilisateur.
Il y a toujours des méthodes de force brute, ou si elles utilisent un mot de passe avec n'importe quel type de mot, une table arc-en-ciel pourrait être utilisée. Quoi qu'il en soit, il est possible de le faire, et si vous utilisez un serveur qui pourrait être une cible populaire (par exemple un serveur pour Google, Facebook ou quelque chose du genre), il serait préférable de vous assurer que cela ne se produira pas de toute façon.
Cela dépend de la configuration, mais bonne chance pour forcer brutalement un mot de passe root complexe qui a été stocké avec bcrypt. Et comme les mots de passe sont salés (dans à peu près toutes les configurations possibles, y compris la plupart par défaut), les tables arc-en-ciel sont inutiles.
GAD3R
2016-02-16 17:21:36 UTC
view on stackexchange narkive permalink

Par défaut, le mot de passe du compte root est verrouillé dans Ubuntu.

Parce que si le compte de cet utilisateur est compromis par un attaquant, l'attaquant peut également obtenir les privilèges root la prochaine fois que l'utilisateur le fait. Le compte utilisateur est le maillon faible de cette chaîne et doit donc être protégé avec le même soin que root.

Le mot de passe du compte root n'a pas besoin d'être partagé avec tous ceux qui ont besoin d'effectuer un certain type d'administration tâches sur le système.

Pour désactiver votre compte root, utilisez la commande suivante: 

  sudo passwd -dl root


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...