Dans quelle mesure NOPASSWD est-il sécurisé en mode Sudo sans mot de passe?
Sur toutes nos boîtes, nous avons un accès ssh via des clés. Toutes les clés sont protégées par mot de passe. En ce moment, le mode Sudo est pas sans mot de passe. Étant donné que le nombre de machines virtuelles augmente dans notre configuration, nous étudions l'utilisation de Ansible .
Ansible lui-même dit dans le docs :
L’utilisation de Sudo sans mot de passe facilite l’automatisation, mais ce n’est pas obligatoire.
Cela m'a fait penser à Sudo sans mot de passe et j'ai trouvé quelques questions/réponses ici. Cependant, je ne pouvais pas vraiment trouver quoi que ce soit sur les problèmes de sécurité de Sudo sans mot de passe en soi.
Cela pourrait arriver dans le futur utilisateur Bob a un mot de passe différent sur la machine X que Y. Lorsque Bob est un sudoer, cela pose des problèmes avec Ansible pour entrer un mot de passe Sudo pour toutes les boîtes. Étant donné que ssh se fait via des clés, les clés sont protégées par mot de passe et tous les comptes d'utilisateurs ont des mots de passe (donc su bob est impossible sans mot de passe): comment la sécurité est-elle affectée lorsque NOPASSWD est défini dans le fichier Sudo?
NOPASSWD n'a pas d'impact majeur sur la sécurité. Son effet le plus évident est de fournir une protection lorsque l'utilisateur quitte son poste de travail sans surveillance: un attaquant disposant d'un accès physique à son poste de travail peut ensuite extraire des données, effectuer des actions et planter des logiciels malveillants avec les autorisations de l'utilisateur, mais pas élever son accès à la racine. Cette protection est d'une utilité limitée car l'attaquant peut planter un programme de type enregistreur de frappe qui enregistre le mot de passe de l'utilisateur la prochaine fois qu'il le saisit à une invite Sudo ou dans un économiseur d'écran.
Néanmoins, exiger le mot de passe élève la barre pour l'attaquant. Dans de nombreux cas, la protection contre les attaquants non sophistiqués est utile, en particulier dans les scénarios de postes de travail sans surveillance où l'attaque est souvent une opportunité et l'attaquant peut ne pas savoir comment trouver et configurer des logiciels malveillants discrets à court terme. En outre, il est plus difficile de masquer les logiciels malveillants lorsque vous ne disposez pas des autorisations root - vous ne pouvez pas vous cacher de root si vous ne disposez pas de root.
Il existe des scénarios réalistes où l'absence de mot de passe protège même contre des attaquants sophistiqués. Par exemple, un ordinateur portable volé: l'ordinateur portable de l'utilisateur est volé, avec des clés SSH privées; soit le voleur parvient à deviner le mot de passe du fichier de clé (peut-être par force brute), soit il y accède à partir d'un vidage de mémoire d'un agent clé. Si le vol est détecté, c'est un signal pour enquêter sur l'activité récente sur le compte de cet utilisateur, et cela signifie qu'un malware installé devrait être détecté. Si l'attaquant n'avait qu'un accès de niveau utilisateur, tout ce qu'il a fait laissera des traces dans les journaux; si l'attaquant a obtenu le mot de passe de l'utilisateur et exécuté Sudo, tous les journaux sont désormais compromis.
Je ne sais pas si les inconvénients de NOPASSWD équilibrent les avantages de votre cas d'utilisation. Vous devez équilibrer cela avec tous les autres facteurs de votre situation. Par exemple, il semble que vous autorisiez mais n'imposiez pas d'avoir des mots de passe différents. Pouvez-vous utiliser à la place une base de données de comptes centralisée? De combien de confinement avez-vous besoin entre vos systèmes? Envisagez-vous des alternatives à Ansible qui prendraient en charge différents mots de passe Sudo? Avez-vous envisagé d'autres mécanismes d'authentification?
Il y a deux cas spécifiques pour lesquels vous ne voulez pas de Sudo sans mot de passe:
- Il s'agit d'un mécanisme de défense contre les utilisateurs malveillants qui accèdent à un compte administratif. Cela peut être dû à l'exploitation ou au fait qu'un administrateur laisse son poste de travail sans surveillance sans verrouiller sa session.
- Le fait de devoir ré-émettre le mot de passe lors de l'utilisation de Sudo donne aux utilisateurs impulsifs le temps de réfléchir à deux fois avant d'effectuer l'action.
À propos de l'automatisation:
Je suis d'accord que vous pouvez le faire sans mot de passe, mais en n'exigeant pas le mot de passe Sudo, vous donnez en fait TOUS accès à votre outil d'automatisation. Pensez maintenant à ce que l'outil doit réellement faire? A-t-il vraiment besoin de tous ces accès? Probablement pas.
Sudo est livré avec une fonctionnalité intéressante qui vous permet de configurer des commandes spécifiques avec l'indicateur NOPASSWD dans le fichier sudoers:
username myhost = (root) NOPASSWD: /sbin/shutdown
username myhost = (root) NOPASSWD: /sbin/reboot
Une chose qui ne ressemble à personne ne l'a souligné pour une raison quelconque (corrigez-moi si je me trompe) est qu'il permet à n'importe quel programme que vous exécutez d'accéder à la racine sans que vous le sachiez. Normalement, si vous exécutez accidentellement un programme ou un script malveillant en tant qu'utilisateur non root sans Sudo, alors même s'il peut encore faire beaucoup de dégâts, il (à moins d'un exploit séparé) n'aura toujours pas les privilèges root. Ainsi, vous n'aurez pas au moins à vous soucier d'un rootkit ou de quoi que ce soit. Mais avec le mode NOPASSWD, vous n'avez pas cette protection. Tout programme exécuté sous votre utilisateur pourra passer à la racine en se ré-invoquant avec Sudo. Le malware doit encore être programmé spécifiquement pour ce faire, et il n'aura pas d'accès root sinon, mais qu'en est-il du code malveillant qui fait cela?
Étant donné que ssh se fait via des clés, les clés sont protégées par mot de passe et tous les comptes d'utilisateurs ont des mots de passe (donc su bob est impossible sans mot de passe)
Soyons clairs ici. Les mots de passe utilisés pour protéger les clés SSH et les mots de passe des comptes d'utilisateurs NE SONT PAS LES MÊMES.
NOPASSWD permet simplement à l'utilisateur d'exécuter des commandes en tant qu'autre utilisateur sans entrer son mot de passe. Cela n'affecte pas le fait que l'utilisateur doit entrer son mot de passe lors de la connexion SSH dans le système.
Ansible peut utiliser diverses choses pour l'automatisation: comme Sudo avec un mot de passe Sudo ou NOPASSWD. Ou utilisez su, suexec, doas ou autre.
Aujourd'hui, nous parlons de:
become: yes
become_user:root
become_method: Sudo
Gardez juste à l'esprit que idéalement ansible devrait être utilisé pour l'automatisation (infra comme code), pas pour une utilisation interactive. Les utilisateurs humains peuvent toujours utiliser des mots de passe, ils peuvent d'ailleurs tomber sur des politiques d'expiration.
Ansible Tower et AWX peuvent stocker toutes sortes d'informations d'identification cryptées et déléguer leur utilisation pour des tâches spécifiques, sans divulguer les clés ou les mots de passe.
Une alternative consiste à utiliser des clés ssh temporaires (signées). Hashicorp Vault peut gérer ces
Il y a des avantages et des inconvénients à ce que l'utilisateur entre un mot de passe pour accéder à Sudo.
Pro: meilleure protection si quelqu'un accède à un compte administrateur. par exemple via un terminal déverrouillé, ou une sorte d'exploit.
Inconvénient: l'utilisateur entre un mot de passe en texte brut qui est chiffré en transit, mais ensuite déchiffré avant qu'il n'atteigne le shell de l'utilisateur. Quelqu'un pourrait par exemple trafiquer le script bashrc pour exécuter un enregistreur de frappe. Selon votre configuration et les habitudes des utilisateurs qui peuvent autoriser l'utilisation du mot de passe pour la connexion directe au compte des utilisateurs sur cette machine, et peut-être également sur d'autres machines. Les gens réutilisent trop souvent les mots de passe.