Quel est le moyen le plus sûr d'obtenir les privilèges root: Sudo, su ou login?
Je voudrais avoir le compte root en toute sécurité même si mon utilisateur non privilégié est compromis.
Sur Ubuntu, vous ne pouvez utiliser Sudo que pour des "raisons de sécurité" par défaut. Cependant, je ne suis pas sûr que ce soit plus sûr que de simplement utiliser la connexion sur une console en mode texte. Il y a trop de choses qui peuvent mal tourner si un attaquant peut exécuter du code en tant qu'utilisateur normal. Par exemple, ajouter des alias, ajouter des éléments à mon CHEMIN, définir LD_PRELOAD et les enregistreurs de frappe X11 pour n'en mentionner que quelques-uns. Le seul avantage que je peux voir est le délai d'attente, donc je n'oublie jamais de me déconnecter.
J'ai les mêmes doutes à propos de su mais cela n'a même pas de limite de temps. Certaines opérations (en particulier IO) sont plus pratiques avec su mais en termes de sécurité, cela semble être pire.
La connexion sur une console en mode texte semble être la plus sûre. Puisqu'il est démarré par init si un attaquant peut contrôler PATH ou LD_PRELOAD il est déjà root. Les événements de pression de touche ne peuvent pas être interceptés par des programmes fonctionnant sur X. Je ne sais pas si les programmes fonctionnant sur X peuvent intercepter [ctrl] + [alt] + [f1] (et ouvrir une fenêtre plein écran qui ressemble à une console) ou il est sûr comme [ctrl] + [alt] + [del] sous Windows. En plus de cela, le seul problème que je vois est le manque de timeout.
Alors est-ce que je manque quelque chose? Pourquoi les gars d'Ubuntu ont-ils décidé de n'autoriser que sudo? Que puis-je faire pour améliorer la sécurité de l'une des méthodes?
Et SSH? Traditionnellement, root ne peut pas se connecter via SSH. Mais utiliser la logique ci-dessus ne serait-ce pas la chose la plus sûre à faire:
- autoriser root via SSH
- passer en mode texte
- connectez-vous en tant que root
- ssh vers l'autre machine
- vous connecter en tant que root?
La sécurité consiste toujours à faire des compromis. Tout comme le serveur proverbial qui est dans un coffre-fort, débranché, au fond de l'océan, root serait le plus le plus sûr s'il y avait n'y avait aucun moyen d'y accéder du tout.
Les attaques LD_PRELOAD et PATH comme celles que vous décrivez supposent qu'un attaquant a déjà accès à votre compte, ou au moins à vos fichiers dot. Sudo ne protège pas très bien contre ça - s'ils ont votre mot de passe, après tout, pas besoin d'essayer de vous tromper pour plus tard ... ils peuvent simplement utiliser Sudo maintenant .
Il est important de considérer à quoi Sudo a été conçu à l'origine: délégation de commandes spécifiques (comme celles pour gérer les imprimantes) à des "sous-administrateurs" (peut-être des étudiants diplômés dans un laboratoire) sans dévoiler complètement la racine. Utiliser Sudo pour faire tout est l'utilisation la plus courante que je vois maintenant, mais ce n'est pas nécessairement le problème que le programme était censé résoudre (d'où la configuration ridiculement compliquée syntaxe de fichier).
Mais, Sudo-for-unrestricted-root résout un autre problème de sécurité: la gérabilité des mots de passe root. Dans de nombreuses organisations, ceux-ci ont tendance à être distribués comme des bonbons, écrits sur des tableaux blancs et laissés pour toujours. Cela laisse une grande vulnérabilité, car la révocation ou la modification de l'accès devient un gros chiffre de production. Même garder la trace de quelle machine a quel mot de passe est un défi - sans parler de savoir qui sait lequel.
N'oubliez pas que la plupart des "cybercrimes" viennent de l'intérieur. Avec la situation du mot de passe root décrite, il est difficile de savoir qui a fait quoi - quelque chose que Sudo avec la journalisation à distance gère assez bien.
Sur votre système domestique, je pense que c'est plus une question de commodité de ne pas avoir à mémoriser deux mots de passe. Il est probable que de nombreuses personnes les définissaient simplement de la même manière - ou pire, les définissaient initialement comme les mêmes, puis les laissaient se désynchroniser, laissant le mot de passe root pourrir.
L'utilisation de mots de passe pour SSH est dangereuse, car les démons ssh de Troie reniflant les mots de passe sont mis en place dans quelque chose comme 90% des compromis du système réel J'ai vu. Il est préférable d'utiliser des clés SSH, ce qui peut également être un système viable pour l'accès root à distance.
Mais le problème est que vous êtes maintenant passé de la gestion des mots de passe à la gestion des clés, et les clés ssh ne sont pas vraiment très gérables. Il n'y a aucun moyen de restreindre les copies, et si quelqu'un fait une copie, il a toutes les tentatives qu'il souhaite pour forcer la phrase secrète. Vous pouvez définir une politique stipulant que les clés doivent être stockées sur des périphériques amovibles et montées uniquement en cas de besoin, mais il n'y a aucun moyen de les appliquer - et vous avez maintenant introduit la possibilité qu'un périphérique amovible soit perdu ou volé.
La sécurité la plus élevée va venir des clés à usage unique ou des jetons cryptographiques basés sur l'heure/le compteur. Cela peut être fait par logiciel, mais le matériel inviolable est encore mieux. Dans le monde open source, il y a WiKiD , YubiKey , ou LinOTP , et bien sûr il y a aussi le poids lourd propriétaire RSA SecurID . Si vous êtes dans une organisation de taille moyenne à grande, ou même dans une petite entreprise soucieuse de la sécurité, je vous recommande vivement d'examiner l'une de ces approches pour l'accès administratif.
C'est probablement exagéré pour la maison, cependant, où vous n'avez pas vraiment les tracas de gestion - tant que vous suivez des pratiques de sécurité raisonnables.
C'est une question très complexe. mattdma déjà couvert de nombreux points .
Entre su et Sudo, lorsque vous considérez un seul utilisateur, su est un peu plus sécurisé en ce sens qu'un attaquant qui a trouvé votre mot de passe ne peut pas obtenir immédiatement les privilèges root. Mais tout ce qu'il faut, c'est que l'attaquant trouve un trou racine local (relativement rare) ou installe un cheval de Troie et attend que vous exécutiez su.
Sudo présente des avantages même par rapport à une connexion à une console lorsqu'il y a plusieurs utilisateurs. Par exemple, si un système est configuré avec des journaux infalsifiables à distance, vous pouvez toujours savoir qui a exécuté Sudo pour la dernière fois (ou dont le compte a été compromis), mais vous ne savez pas qui a tapé le mot de passe root sur la console.
Je soupçonne que la décision d'Ubuntu était en partie dans l'intérêt de la simplicité (un seul mot de passe à retenir) et en partie dans l'intérêt de la sécurité et de la facilité de distribution des informations d'identification sur les machines partagées (professionnelles ou familiales).
Linux ne dispose pas d'une clé d'attention sécurisée ou d'une autre interface utilisateur sécurisée pour l'authentification. Pour autant que je sache, même OpenBSD n'en a pas. Si vous êtes préoccupé par l'accès root, vous pouvez désactiver complètement l'accès root à partir d'un système en cours d'exécution: si vous voulez être root, vous devrez taper quelque chose à l'invite du chargeur de démarrage. Ce n'est évidemment pas adapté à tous les cas d'utilisation. (* BSD securelevel fonctionne comme ceci: à un niveau de sécurité élevé, il y a des choses que vous ne pouvez pas faire sans redémarrer, comme abaisser le niveau de sécurité ou accéder directement aux périphériques bruts montés.)
Restreindre les façons de devenir root n'est pas toujours un gain de sécurité. Rappelez-vous le troisième membre de la triade de sécurité : confidentialité , intégrité , disponibilité . Le verrouillage de votre système peut vous empêcher de répondre à un incident.
Les concepteurs de la distribution sécurisée OpenWall GNU/*/Linux ont également exprimé des opinions critiques sur su (pour devenir root) et Sudo. Vous pourriez être intéressé par la lecture de ce fil:
... malheureusement, su et Sudo sont subtilement mais fondamentalement défectueux.
En plus de discuter des défauts de su et d'autres choses, Solar Designer cible également une raison spécifique d'utiliser su:
Oui, il était une sagesse courante de l'administrateur système de "su root" plutôt que de se connecter en tant que root. Les quelques personnes qui, lorsqu'on leur a demandé, pouvaient en fait trouver une raison valable pour cette préférence, se réfèreraient à une meilleure responsabilisation obtenue avec cette approche. Oui, c'est vraiment une bonne raison pour cette approche. Mais c'est aussi le seul. ...(Lire la suite)
Dans leur distribution, ils ont "complètement débarrassé des programmes racine SUID dans l'installation par défaut" (c'est-à-dire, y compris su; et ils n'utilisent pas de capacités pour cela):
Pour les serveurs, je pense que les gens doivent reconsidérer et, dans la plupart des cas, interdire l'invocation de su et Sudo par les utilisateurs. Il n'y a pas de sécurité supplémentaire de l'ancien "login en tant que non root, puis su ou Sudo pour rooter" sysadmin "wisdom", par rapport à la connexion en tant que non root et en tant que root directement (deux sessions distinctes). Au contraire, cette dernière approche est la seule correcte, du point de vue de la sécurité:
http://www.openwall.com/lists/owl-users/2004/10/20/6
(Pour la responsabilité de plusieurs administrateurs système, le système doit prendre en charge plusieurs comptes à privilèges root, comme Owl.)
(Pour les ordinateurs de bureau avec X, cela devient plus délicat.)
Vous devez aussi absolument faire face à ...
BTW, ils devaient remplacer sulogin par msulogin pour permettre la configuration avec plusieurs comptes root: msulogin permet de saisir le nom d'utilisateur également en passant en mode mono-utilisateur (et préserver la "responsabilité") (cette info vient de cette discussion en russe ).
Vous semblez supposer que l'utilisation de Sudo préserve toujours les variables d'environnement, mais ce n'est pas toujours le cas. Voici un extrait de la page de manuel Sudo:
Il existe deux façons distinctes de gérer les variables d'environnement. Par défaut, l'option env_reset sudoers est activée. Cela entraîne l'exécution de commandes avec un environnement minimal contenant TERM, PATH, HOME, Shell, LOGNAME, USER et USERNAME en plus des variables du processus d'appel autorisées par les options env_check et env_keep sudoers. Il existe effectivement une liste blanche pour les variables d'environnement.
Si, cependant, l'option env_reset est désactivée dans sudoers, toutes les variables qui ne sont pas explicitement refusées par les options env_check et env_delete sont héritées du processus d'appel. Dans ce cas, env_check et env_delete se comportent comme une liste noire. Puisqu'il n'est pas possible de mettre sur liste noire toutes les variables d'environnement potentiellement dangereuses, l'utilisation du comportement env_reset par défaut est encouragée.
Dans tous les cas, les variables d'environnement dont la valeur commence par () sont supprimées car elles pourraient être interprétées comme des fonctions bash. La liste des variables d'environnement que Sudo autorise ou refuse est contenue dans la sortie de Sudo -V lorsqu'il est exécuté en tant que root.
Donc si env_reset est activé (par défaut), un attaquant ne peut pas remplacer votre PATH ou d'autres variables d'environnement (sauf si vous les ajoutez spécifiquement à une liste blanche de variables qui doivent être conservées).
L'approche la plus sûre est la connexion ssh en utilisant (au moins) la clé longue 2048 (avec la connexion par mot de passe désactivée) en utilisant un périphérique physique pour stocker la clé.
Je veux juste ajouter quelque chose d'un peu hors sujet. (pour le sujet, cochez '/ bin/su -' ici après)
Je pense que la "sécurité" ci-dessus devrait également être liée aux données réelles que nous voulons sécuriser.
Ce sera et devrait être différent si nous voulons sécuriser: my_data, my_company_data, my_company_network.
Habituellement, si je parle de sécurité, je parle aussi de "sécurité des données" et de sauvegarde. Nous pouvons également ajouter des systèmes tolérants aux pannes et similaires.
Compte tenu de cela, je pense que la sécurité dans son ensemble est un équilibre entre l'utilisabilité, la "sécurité des données" et l'effort requis pour mettre en œuvre un système sécurisé.
La cible d'Ubuntu était, et est toujours le plus souvent, l'utilisateur final: Sudo est la valeur par défaut.
Fedora est la version gratuite de RedHat qui à son tour est davantage orientée serveurs: Sudo était auparavant désactivé.
Pour les autres distributions, je n'ai pas d'informations directes.
J'utilise en ce moment, principalement, Fedora. Et en tant qu'utilisateur à l'ancienne, je n'ai jamais tapé "su". Mais je peux taper "/ bin/su -" en très peu de temps même si je ne suis pas exactement une dactylo. La variable PATH .. ne devrait pas poser de problème (je tape le chemin). De plus, le "-" (moins) devrait en principe supprimer mes variables d'environnement utilisateur et ne charger que celles de racine. c'est-à-dire en évitant certains problèmes supplémentaires possibles. Probablement aussi le LS_PRELOAD.
Pour le reste, je suppose que @mattdm était assez précis.
Mais mettons-le dans la bonne case. Supposons qu'un kit intelligent de script ait accès à mes données. Que diable pensez-vous qu'il va en faire? - Publier mes photos? mon? - Essayer de découvrir le nom de ma petite amie et lui dire que je visite des sites porno?
Dans l'image d'un utilisateur unique, les deux pires situations sont: - L'enfant supprime toutes mes données: pour le plaisir ou par erreur - L'enfant utilise ma machine pour créer une nouvelle attaque contre une autre entité. Ou des cibles similaires.
Pour le premier cas, je l'ai mentionné ci-dessus, il vaut mieux mettre des efforts sur une sauvegarde que sur la sécurité du réseau. Oui, vous êtes sauvé. Je veux dire qu'un crash matériel n'est pas si différent.
Le deuxième cas est plus subtil. Mais il y a des signaux sur ces activités. En tout cas, vous pouvez faire le possible, mais je ne configurerais pas mon PC personnel pour qu'il soit protégé des attaques terroristes!
Je vais sauter les autres scénarios.
cheers F
Si le problème est qu'un compte d'utilisateur compromis peut être utilisé pour renifler le mot de passe utilisé pour Sudo ou su, utilisez un code d'accès unique pour Sudo et su.
Vous pouvez forcer l'utilisation de clés pour les utilisateurs distants, mais cela peut ne pas réussir à des fins de conformité. Il pourrait être plus efficace de configurer une boîte de passerelle SSH qui nécessite une authentification à deux facteurs, puis d'autoriser l'utilisation des clés à partir de là. Voici la documentation sur une telle configuration: Sécurisez votre déploiement SSH avec l'authentification à deux facteurs WiKID .
Vous pouvez également jeter un œil à privacyIDEA , qui vous offre non seulement la possibilité d'utiliser OTP pour vous connecter à la machine (ou pour faire su/Sudo) mais il peut également faire OTP hors ligne.
De plus, il est capable de gérer vos clés SSH. C'est à dire. si vous avez plusieurs machines et plusieurs utilisateurs root, toutes les clés SSH sont stockées de manière centralisée. Ainsi, il est facile de "révoquer"/supprimer une clé SSH, si la clé n'est plus fiable.
Bien sûr, il existe des tâches organisationnelles et des workflows pour sécuriser le système.