Quel est le moyen le plus sûr d’obtenir les privilèges root: sudo, su ou login?

J'aimerais avoir le compte root en 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 d'utiliser simplement la connexion sur une console en mode texte. Trop de problèmes peuvent se produire si un attaquant peut exécuter du code comme étant mon utilisateur normal. Par exemple, ajouter des alias, ajouter des éléments à mon chemin PATH, configurer LD_PRELOAD et les enregistreurs de frappe X11, pour n'en citer que quelques-uns. Le seul avantage que je peux voir est le délai d'attente afin que je n'oublie jamais de me déconnecter.

J'ai les mêmes doutes à propos de su mais il n'y a même pas de limite de temps. Certaines opérations (en particulier la redirection IO) sont plus pratiques avec su, mais sur le plan de la sécurité, cela semble être pire.

La connexion sur une console en mode texte semble être la plus sûre. Comme il est lancé par init, si un attaquant peut contrôler PATH ou LD_PRELOAD, il est déjà root. Les événements de frappe ne peuvent pas être interceptés par les programmes fonctionnant sous X. Je ne sais pas si les programmes exécutés sous X peuvent intercepter [ctrl] + [alt] + [f1] (et ouvrir une fenêtre plein écran qui ressemble à une console) ou c'est sûr comme [ctrl] + [alt] + [del] sous Windows. En plus de cela, le seul problème que je vois est le manque de temps mort.

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 de ces méthodes?

Qu'en est-il de SSH? Traditionnellement, root ne peut pas se connecter via SSH. Mais en utilisant la logique ci-dessus, cela ne serait-il pas la chose la plus sûre à faire:

• autoriser la racine via SSH
• passer en mode texte
• se connecter en tant que root
• ssh à l'autre machine
• se 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, rootserait plus sûr s'il n'y avait aucun moyen d'y accéder du tout.

Les attaques LD_PRELOAD et PATH telles que celles que vous décrivez supposent l'existence d'un attaquant ayant déjà accès à votre compte, ou tout au moins à vos fichiers points. Sudo ne protège pas du tout contre cela. S'ils ont votre mot de passe, après tout, inutile d'essayer de vous tromper pour plus tard ... ils peuvent simplement l'utiliser sudo maintenant .

Il est important de considérer ce pour quoi Sudo a été conçu à l'origine: délégation de commandes spécifiques (comme celles permettant de gérer les imprimantes) à des "sous-administrateurs" (peut-être des étudiants diplômés d'un laboratoire) sans céder complètement la racine. Utiliser sudo pour tout faire est l'utilisation la plus courante que je connaisse maintenant, mais ce n'est pas nécessairement le problème que le programme était censé résoudre (d'où la syntaxe ridiculement compliquée du fichier de configuration).

Cependant, sudo-for-non-restreint-root répond à un autre problème de sécurité: la facilité de gestion 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é, puisque la révocation ou la modification de l’accès devient un grand nombre de production. Même le fait de savoir quelle machine a quel mot de passe est un défi - sans parler de qui sait qui.

Rappelez-vous que la plus grande partie de la "cybercriminalité" vient de l'intérieur. Avec la situation de mot de passe racine décrite, il est difficile de localiser qui a fait quoi - quelque chose que sudo gère assez bien avec la journalisation à distance.

Sur votre système domestique, je pense que c’est plus une question de commodité de ne pas avoir à retenir deux mots de passe. Il est probable que de nombreuses personnes les définissaient simplement comme identiques - ou pire, les configurant comme étant initialement identiques, puis les laissaient se désynchroniser, laissant pourrir le mot de passe racine.

L'utilisation de mots de passe pour SSH est dangereuse, car des démons ssh de Troie capturant des mots de passe sont mis en place dans environ 90% des compromis système réels que j'ai vus. Il est bien mieux d'utiliser des clés SSH, et cela peut également être un système utilisable pour un 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 que les clés ssh ne sont pas vraiment gérables. Il n'y a aucun moyen de restreindre les copies, et si quelqu'un en fait une, ils ont toutes les tentatives voulues pour forcer la phrase secrète de force. Vous pouvez définir une stratégie selon laquelle les clés doivent être stockées sur des périphériques amovibles et montées uniquement lorsque cela est nécessaire, mais il n'y a aucun moyen de le faire. Vous avez maintenant introduit la possibilité qu'un périphérique amovible soit perdu ou volé.

La sécurité la plus élevée passe par des clés uniques ou des jetons cryptographiques basés sur le temps et les compteurs. Celles-ci peuvent être réalisées à l'aide d'un logiciel, mais un matériel inviolable est encore meilleur. Dans le monde open source, il y a WiKiD , YubiKey ou LinOTP , et bien sûr, il y a aussi le poids lourd breveté RSA SecurID . Si vous appartenez à une entreprise de moyenne à grande taille, voire à une petite entreprise soucieuse de sa sécurité, je vous recommande vivement de rechercher l'une de ces approches d'accès administratif.

C'est probablement trop cher pour la maison, où vous n'avez pas vraiment de problèmes de gestion - du moment que vous suivez des pratiques de sécurité raisonnables.

C'est une question très complexe. mattdm a 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 il suffit que l’attaquant trouve un trou de 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 à la console lorsqu'il y a plusieurs utilisateurs. Par exemple, si un système est configuré avec des journaux inviolables à 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 saisi le mot de passe root sur la console.

Je pense que la décision d'Ubuntu était en partie liée à la simplicité (un seul mot de passe à retenir) et à la sécurité et à la facilité de distribution des informations d'identification sur des machines partagées (entreprise ou famille).

Linux n'a pas de clé d'attention sécurisée ni d'autre interface utilisateur sécurisée pour l'authentification. 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 devez taper quelque chose à l'invite du programme d'amorçage. Ce n'est évidemment pas adapté à tous les cas d'utilisation. (* Securelevel de BSD fonctionne comme ceci: à un niveau de sécurité élevé, il y a des choses que vous ne pouvez pas faire sans redémarrer, telles que baisser le niveau de sécurité ou accéder directement aux périphériques bruts montés.)

Restreindre les possibilités de devenir root ne constitue pas toujours un gain de sécurité. Rappelez-vous le troisième membre de la triade de sécurité : confidentialité , intégrité , disponibilité . Le fait de vous verrouiller hors de votre système peut vous empêcher de réagir à un incident.

Les concepteurs de la distribution sécurisée OpenWall GNU / * / Linux ont également exprimé des avis critiques sur su(pour devenir root) et sudo. Vous pourriez être intéressé à lire ce fil:

... malheureusement, su et sudo sont subtilement, mais fondamentalement imparfaits.

En plus de discuter des défauts de suet d'autres choses, Solar Designer cible également une raison spécifique à utiliser su:

Oui, il était courant que l'administrateur système ait l'habitude de "su root" plutôt que de se connecter en tant que root. Les quelques personnes qui, si on leur demandait, pourraient en réalité trouver une raison valable pour cette préférence se réfèreraient à la meilleure responsabilisation obtenue avec cette approche. Oui, c'est vraiment une bonne raison en faveur de cette approche. Mais c'est aussi le seul. ...(Lire la suite)

Dans leur distribution, ils se sont "complètement débarrassés des programmes racine SUID dans l'installation par défaut" (c'est-à-dire, y compris su; et ils n'utilisent pas de fonctionnalités pour cela):

Pour les serveurs, je pense que les utilisateurs doivent reconsidérer et, dans la plupart des cas, interdire l’invocation de su et sudo par les utilisateurs. L'ancien "login en tant que non-root, puis su ou sudo n'est pas ajouté à la sécurité", par rapport à la connexion "sysadmin" sagesse ", par rapport à la connexion en tant que non-root et directement en tant que root (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 rendre compte de plusieurs administrateurs système, le système doit prendre en charge plusieurs comptes à privilèges root, comme le fait Owl.)

(Pour les ordinateurs de bureau avec X, cela devient plus compliqué.)

Vous devez également absolument traiter avec ...

BTW, ils devaient remplacer suloginpar msuloginpour permettre la configuration avec plusieurs comptes root: msuloginpermet de taper le nom d'utilisateur même lorsque vous passez en mode utilisateur unique (et de préserver la "responsabilité") (cette information provient de cette discussion en russe ) .

Vous semblez supposer que l'utilisation sudopré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 manières distinctes de traiter les variables d'environnement. Par défaut, l'option env_reset sudoers est activée. Ainsi, les commandes sont exécutées dans un environnement minimal contenant TERM, PATH, HOME, SHELL, LOGNAME, USER et USERNAME, en plus des variables du processus d’appel autorisé par les options env_check et env_keep sudoers. Il existe effectivement une liste blanche pour les variables d'environnement.

Si, toutefois, l'option env_reset est désactivée dans les sudoers, toutes les variables non 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. Comme il n'est pas possible de mettre toutes les variables d'environnement potentiellement dangereuses dans la liste noire, l'utilisation du comportement par défaut env_reset 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'elle est exécutée en tant que root.

Donc, si env_resetest activé (valeur par défaut), un attaquant ne peut pas écraser votre PATHou les autres variables d’environnement (à moins que vous ne les ajoutiez spécifiquement à une liste blanche de variables qui devraient être préservées).

L'approche la plus sûre est la connexion SSH utilisant (au moins) une clé longue de 2048 (avec la connexion par mot de passe désactivée) à l'aide d'un périphérique physique pour stocker la clé.

Je veux juste ajouter quelque chose d'un peu hors sujet. (pour le sujet une vérification '/ bin / su -' ci-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 cela devrait être différent si nous voulons sécuriser: my_data, my_company_data, my_company_network.

D'habitude, 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érance de pannes, etc.

Cela étant dit, je pense que la sécurité dans son ensemble constitue un équilibre entre la convivialité, la "sécurité des données" et les efforts nécessaires pour mettre en place un système sécurisé.

La cible d'Ubuntu était, et reste encore principalement, l'utilisateur final: Sudo est la valeur par défaut.

Fedora est la version gratuite de RedHat qui, à son tour, est davantage orientée serveur: Sudo était auparavant désactivé.

Pour les autres distributions, je n'ai aucune information directe.

J'utilise actuellement, principalement, fedora. Et en tant qu'utilisateur de style ancien, 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 tout à fait dactylographe. La variable PATH .. ne devrait pas être un problème (je tape le chemin). De plus, le "-" (moins) devrait en principe supprimer mes variables d'environnement utilisateur et ne charger que les variables racine. c'est-à-dire en évitant quelques 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 obtienne l'accès à mes données. Qu'est-ce que tu crois qu'il va faire avec ça? - Publier mes photos? mon? - Essayer de connaître le nom de ma petite amie et de lui dire que je visite des sites porno?

Dans l’image utilisateur unique, les deux situations les plus graves sont les suivantes: - L’enfant supprime toutes mes données: par 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, j'ai mentionné ci-dessus, il est préférable de mettre des efforts sur une sauvegarde que sur la sécurité du réseau. Oui, vous êtes en train d'économiser. Je veux dire un crash matériel n'est pas si différent.

Le second cas est plus subtil. Mais il y a des signaux sur ces activités. Dans tous les cas, vous pouvez faire le possible, mais je ne configurerais pas mon ordinateur personnel de manière à ce qu’il soit protégé contre les attaques terroristes!

Je vais sauter les autres scénarios.

acclamations F

Si le problème est qu'un compte d'utilisateur compromis peut être utilisé pour détecter le mot de passe utilisé pour sudoou su, utilisez un code à usage unique pour sudoet su.

Vous pouvez forcer l'utilisation de clés pour les utilisateurs distants, mais cela pourrait ne pas passer au test pour des raisons de conformité. Il serait peut-être plus efficace de configurer une boîte de passerelle SSH nécessitant une authentification à deux facteurs, puis d'autoriser l'utilisation de la clé à 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 coup d'oeil à privacyIDEA , qui ne vous offre pas seulement la possibilité d'utiliser OTP pour vous connecter à la machine (ou pour faire su / sudo), mais il peut également le faire en mode hors connexion.

De plus, il est capable de gérer vos clés SSH. Par exemple, si vous avez plusieurs machines et plusieurs utilisateurs root, toutes les clés SSH sont stockées de manière centralisée. Il est donc facile de "révoquer" / supprimer une clé SSH, si la clé ne peut plus être fiable.

Bien entendu, il existe des tâches et des flux de travail organisationnels pour sécuriser le système.