Pourquoi su root plutôt que de se connecter en tant que root?


33

J'ai souvent entendu dire qu'il est préférable de placer root sur root plutôt que de se connecter directement en tant qu'utilisateur root (et bien sûr, les utilisateurs disent également qu'il est préférable d'utiliser sudo). Je n'ai jamais vraiment compris pourquoi on est meilleur que les autres, perspicacité?


2
Pensez-vous aux connexions ssh ou également aux connexions à partir de la machine physique?
Télémaque le

Réponses:


43

L'inférence est à seulement suou sudolorsque nécessaire.

La plupart des tâches quotidiennes ne nécessitent pas de shell racine. Il est donc recommandé d’utiliser un shell non privilégié comme comportement par défaut et d’élever uniquement à la racine lorsque vous devez effectuer des tâches spéciales.

Ce faisant, vous réduisez le risque d'erreurs dangereuses (scripts incorrects, caractères génériques égarés, etc.) et de vulnérabilités de toutes les applications que vous utilisez. Surtout ceux qui se connectent à Internet - voir le vieil adage "Ne pas IRC en tant que root" .

sudo est souvent recommandé car il vous permet de vérifier et de vérifier l’utilisation de tels privilèges.

En observant ces pratiques, vous êtes également en mesure de désactiver les connexions racine à distance. Cela augmente la barre d’entrée pour tout attaquant potentiel, car il devrait compromettre à la fois un compte utilisateur ordinaire membre du groupe "wheel" et, idéalement, uniquement autorisé par les clés publiques SSH, puis le compte root lui-même.


1
Pourriez-vous préciser pourquoi la connexion root à distance est une "vulnérabilité relativement importante"?
thepocketwade

5
Étant donné que le monde entier connaît le nom d'utilisateur ('root'), il ne s'agit que de déterminer le mot de passe. Et ils peuvent le faire par la force brute et prendre en charge votre ordinateur.
Shalom Craimer

2
Un autre avantage de sudo: la journalisation des commandes exécutées.
Manuel Faux

C'est la vérification;)
Dan Carley

1
While sudoest supérieur, suvous permet également d'utiliser l' -mindicateur pour que les variables d'environnement restent les mêmes lorsque vous êtes dans un terminal root. Rien ne me pousse plus bonkers que sude rooter un peu, seulement de faire quelque chose avec ~le nom du répertoire et de ne pas le faire fonctionner.
tj111

27

Vous devez désactiver l’accès root à distance afin qu’un attaquant ne puisse pas compromettre la racine sans compromettre au préalable un utilisateur, puis passer à la racine. Nous activons l'accès root uniquement sur la console.

De plus, cela crée une responsabilité. :)


+1 court et au point
lexu

15

La raison principale est de créer une piste d'audit. Si vous devez vous connecter à un système en tant qu'utilisateur normal, puis en tant que su, il est possible de déterminer qui est responsable des actions données.


Une fois que quelqu'un a exécuté su-root, comment déterminez-vous les commandes qu'il a exécutées? Est-ce enregistré quelque part?
Dobes Vandermeer

10

sudo enregistre également automatiquement chaque commande dans syslog et vous pouvez définir les commandes que chaque utilisateur peut utiliser.


3
En ce qui concerne la journalisation: c'est le cas pour chaque commande précédée de 'sudo', mais dans le cas où sudo est utilisé pour passer à un shell racine, les commandes ne sont consignées que dans les zones traditionnelles (en particulier l'historique du shell).
Zenham

2
En effet, si sudo vim foo.txtvous accédez à un shell à partir de vim, vous obtiendrez un shell racine sans la journalisation sudo habituelle.
Ophidian

Ou juste sudo -ipour avoir une session interactive ...
Kamil Kisiel

Je ne comprends pas le problème avec sudo vim foo.txt. J'ai couru ça, puis je suis sorti de vim et j'étais toujours moi-même. Y at-il quelque chose qui me manque?
thepocketwade

vous pouvez "piéger" sudo pour vous donner un shell en tapant sudo su - ou sudo vim puis passer dans un nouveau sous-shell. Mais si vous utilisez sudo parce que vous voulez que tout soit consigné dans syslog (centralisé) et que vous sachiez qu'il peut également être utilisé pour obtenir un autre sous-shell, alors je ne vois rien de mal à cela, c'est juste un bonus tant que Je ne dépends pas seulement de ça.
Jure1873

9

Une autre bonne raison: lorsqu’elle passe à la racine via sudo, un utilisateur s’authentifie avec ses propres informations d’identité, ce qui signifie qu’il ne doit pas nécessairement lui attribuer le mot de passe root, ce qui simplifie le verrouillage lorsque quelqu'un quitte votre organisation.


4

Si vous souhaitez créer un journal d'audit et que vous ne voulez pas être victime des problèmes "sudo su -" ou "sudo vim foo.txt" mentionnés ici, vous pouvez utiliser "sudosh". Distribuez l'accès root via sudo, mais définissez la seule commande autorisée à exécuter "sudosh".

sudosh est un shell de journalisation, et vous pouvez rejouer toute la session de terminal ultérieurement, en affichant exactement ce que l'utilisateur a vu sur son terminal.


Cela suppose bien sûr que le sudosh est disponible sur le système. Je viens de vérifier et je ne l’ai sur aucune de mes machines Linux.
John Gardeniers

Vous pouvez également utiliser le nouveau ksh93 avec la journalisation du journal d'audit activée. Consultez cet article à IBM developerWorks: ibm.com/developerworks/aix/library/au-korn93/...
Mei

Assez facile à contourner en exécutant simplement un script shell (que vous effacerez ensuite). Créez le script sous un nom inoffensif en tant qu'utilisateur non audité (ou scp le à partir de votre poste de travail), puis lancez-le et exécutez-le. Vous pouvez même vraiment le cacher en le nommant 'ls' ou quelque chose de ce genre et en le mettant dans $ PATH (en modifiant $ PATH si besoin est), et en le faisant faire son sale boulot en appelant / bin / ls pour qu'il ait l'air normal. Essuyez-le ensuite. Le journal d'audit ne saura pas que / home / anthony / bin contenait un 'ls'.
derobert

Oui, ce n'est pas parfait nous le savons - mais c’est un site sacrément meilleur que le simple "sudo su -" à mon humble avis. Et oui, il n'est pas installé par défaut n'importe où, autant que je sache. Cependant, il fonctionne assez facilement sous Solaris et Linux.
Mibus

1

Vous devriez pratiquer la sécurité en profondeur.

Interdit l'accès root à distance (ou au moins l'accès root via des mots de passe). (Si vous autorisez l'accès à la racine via des clés, contrôlez soigneusement ces clés ou, mieux encore, utilisez quelque chose comme kerberos qui permet la révocation centralisée des clés).

Je désactiverais su et utiliser sudo. De cette manière, les utilisateurs utilisent des clés (de préférence chiffrées) pour accéder au système. Ils utilisent ensuite leur mot de passe uniquement pour élever les privilèges. Vous pouvez restreindre l'accès aux programmes auxquels les utilisateurs ont accès avec sudo, mais vous limitez principalement l'accès à ceux qui connaissent le mot de passe root.

Dans un monde idéal, vous devriez être capable de publier vos mots de passe root sur Internet, peu importe, même si vous donniez l'accès à votre machine à des personnes (sans les mettre dans le fichier / etc / sudoers). Bien sûr, vous ne devriez pas publier le mot de passe root, mais l’idée est de protéger vos systèmes avec des couches de protection concentriques.


0

L'idée est de désactiver la connexion root, et donc de ne pas avoir de compte administrateur par défaut. De cette façon, un attaquant doit deviner le nom d'utilisateur et le mot de passe (et pas seulement le mot de passe).


0

Si vous utilisez régulièrement root, il se peut que vos autorisations soient erronées ou que vous deviez octroyer des droits sudo ou de nouveaux droits de groupe pour r / w / x les fichiers ou les répertoires.

Les bons schémas d’autorisations sont quelque chose que même les utilisateurs de longue date de Linux se trompent ou ne réalisent pas à quoi ils correspondent.

Ne me dites même pas ce que Ubuntu a fait!


-2

Cela vous évite de lancer rm -r -f / je viens de le courir il y a 2 jours (en tant qu'utilisateur non privilégié, je voulais exécuter rm -r -f *)


La réponse acceptée contenait déjà toutes les informations.
Theuni
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.