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?
Réponses:
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 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.
la source
sudo
est très similaire au contrôle de compte d'utilisateur dans Windows Vista. Les deux sont en fait conçus non pas pour accroître la sécurité, mais pour faciliter la diminution de manière contrôlée. Mais comme ils facilitent l’élévation temporaire de vos privilèges de manière peu frottante, vous n’avez pas besoin d’exécuter avec des privilèges élevés pendant de longues périodes, ce qui accroît la sécurité. (Ce n'était pas un gros problème sous Unix, mais sous Windows, je me souviens d'avoir été administrateur pendant des jours, simplement parce que la commutation était si pénible.)root
mots de passe de votre entreprise sont également mentionnées comme dernier élément de la fiche de suivi des opérations , qu'il convient de lire.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.
la source
Les concepteurs de la distribution sécurisée OpenWall GNU / * / Linux ont également exprimé des avis critiques sur
su
(pour devenir root) etsudo
. 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
su
et d'autres choses, Solar Designer cible également une raison spécifique à utilisersu
: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):BTW, ils devaient remplacer
sulogin
parmsulogin
pour permettre la configuration avec plusieurs comptes root:msulogin
permet 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 ) .la source
Vous semblez supposer que l'utilisation
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:Donc, si
env_reset
est activé (valeur par défaut), un attaquant ne peut pas écraser votrePATH
ou les autres variables d’environnement (à moins que vous ne les ajoutiez spécifiquement à une liste blanche de variables qui devraient être préservées).la source
Password:
affiche rien lorsque je tape, envoie ce que je lui ai tapé, dit que le mot de passe est faux, puis exécute le vrai sudo.alias /usr/bin/sudo="echo pwned"
En plus de cela, il y a une tonne de programmes impliqués (X, xterm, le shell) dont chacun peut voler le mot de passe. C'est pourquoi j'ai dit qu'il y avait trop de problèmes avec la commutation en toute sécurité.bash: alias: `/usr/bin/sudo': invalid alias name
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é.
la source
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
la source
Si le problème est qu'un compte d'utilisateur compromis peut être utilisé pour détecter le mot de passe utilisé pour
sudo
ousu
, utilisez un code à usage unique poursudo
etsu
.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 .
la source
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.
la source