Lorsque vous souhaitez accorder un accès administratif à certains de vos utilisateurs tout en contrôlant et en vérifiant ce qu'ils font sur vos systèmes, vous utilisez sudo . Cependant, même avec sudo , il y a pas mal de problèmes invisibles - pensez simplement à donner l'accès au shell. sudo récent publie des fonctionnalités supplémentaires qui vous permettent de voir ces problèmes et même de les contrôler. Par exemple, vous pouvez activer des messages de journal plus détaillés et plus faciles à traiter et consigner chaque commande exécutée dans une session shell.
Certaines de ces fonctionnalités sont inédites. Certains d'entre eux s'appuient sur des fonctionnalités introduites dans la version 1.9.0 ou même antérieure. Par exemple, sudo pourrait enregistrer tout ce qui s'est passé sur un terminal, même dans la version 1.8. Cependant, le système stockait ces enregistrements localement et ils étaient faciles à supprimer, en particulier ceux où les enregistrements étaient les plus utiles :les sessions Shell. La version 1.9.0 a ajouté une collecte d'enregistrements de session centrale, de sorte que les enregistrements ne peuvent pas être supprimés par l'utilisateur local, et les versions récentes ont ajouté des relais, rendant la collecte encore plus robuste.
Si vous ne connaissez que les bases de sudo ou utilisé uniquement la version 1.8 auparavant, je vous recommande de lire mon article précédent.
1. Journalisation au format JSON
La première nouvelle fonctionnalité que je souhaite introduire est la journalisation au format JSON. Je suis un fanatique de la journalisation (j'ai commencé à travailler sur le syslog-ng projet il y a douze ans), et cette fonctionnalité est la première introduite depuis mon article sur Opensource.com. Lorsqu'il est activé, sudo enregistre beaucoup plus d'informations et le fait d'une manière plus facile à analyser.
syslog traditionnel messages par sudo sont courts et ne contiennent que le minimum d'informations nécessaires. Cela est dû aux contraintes de l'ancien syslog implémentations : les messages de plus de 1 k de taille ont été supprimés ou tronqués :
Jan 28 13:56:27 localhost.localdomain sudo[10419]: czanik : TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
syslog plus récent les implémentations peuvent gérer des tailles de message beaucoup plus importantes. syslog-ng accepte les messages de journal jusqu'à 64 Ko par défaut (mais bien sûr, il peut être plus petit ou plus grand, selon la configuration réelle).
Le même événement contient beaucoup plus d'informations s'il est enregistré au format JSON. Plus ne signifie pas plus difficile à gérer :les messages au format JSON sont plus faciles à analyser par de nombreuses applications logicielles de gestion des journaux. Voici un exemple :
Jan 28 13:58:20 localhost.localdomain sudo[10518]: @cee:{"sudo":{"accept":{"uuid":"616bc9efcf-b239-469d-60ee-deb5af8ce6","server_time":{"seconds":1643374700,"nanoseconds":222446715,"iso8601":"20220128125820Z","localtime":"Jan 28 13:58:20"},"submit_time":{"seconds":1643374700,"nanoseconds":209935349,"iso8601":"20220128125820Z","localtime":"Jan 28 13:58:20"},"submituser":"czanik","command":"/bin/bash","runuser":"root","runcwd":"/home/czanik","ttyname":"/dev/pts/0","submithost":"localhost.localdomain","submitcwd":"/home/czanik","runuid":0,"columns":118,"lines":60,"runargv":["/bin/bash"],"runenv":["LANG=en_US.UTF-8","HOSTNAME=localhost.localdomain","SHELL=/bin/bash","TERM=xterm-256color","PATH=/home/czanik/.local/bin:/home/czanik/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin","MAIL=/var/mail/root","LOGNAME=root","USER=root","HOME=/root","SUDO_COMMAND=/bin/bash","SUDO_USER=czanik","SUDO_UID=1000","SUDO_GID=1000"]}}}
Vous pouvez activer les messages de journal au format JSON dans les sudoers fichier :
Defaults log_format=json
Vous pouvez en savoir plus sur l'utilisation des messages de journal au format JSON à partir de sudo depuis mon blog syslog-ng.
2. Collecte centralisée des journaux à l'aide de sudo_logsrvd
Une autre fonctionnalité liée à la journalisation dans 1.9.4 collecte tous les sudo consigner les messages (y compris les échecs) à l'aide de sudo_logsrvd . Auparavant, le système n'enregistrait les sessions réussies que lorsque sudo_logsrvd effectivement fait un enregistrement. La journalisation se fait toujours via syslog par défaut à la fin.
Pourquoi est-ce important? Tout d'abord, vous pouvez collecter tout ce qui concerne sudo en un seul endroit :les enregistrements de session et tous les messages de journal correspondants. Deuxièmement, il peut également garantir une journalisation correcte de tous les sudo -événements liés, comme sudo peut refuser d'exécuter des commandes si sudo_logsrvd est inaccessible.
Vous pouvez activer la journalisation vers sudo_logsrvd avec le paramètre suivant dans les sudoers fichier (bien sûr, remplacez l'adresse IP):
Defaults log_servers=172.16.167.150
Si vous voulez des messages de journal au format JSON, vous avez besoin du paramètre suivant dans le [eventlog] section du sudo_logsrvd configuration :
log_format = json
Sinon, sudo_logsrvd utilise le traditionnel sudo format de journal avec une simple modification :il inclut également des informations sur l'hôte d'où provient le journal :
Nov 18 12:40:16 centos8splunk.localdomain sudo[21028]: czanik : 3 incorrect password attempts ; HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
Nov 18 12:40:23 centos8splunk.localdomain sudo[21028]: czanik : HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; TSID=00000A ; COMMAND=/bin/bash
Nov 18 12:40:30 centos8splunk.localdomain sudo[21028]: czanik : command rejected by I/O plugin ; HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
En savoir plus sur les administrateurs système
- Activer le blog Sysadmin
- L'entreprise automatisée :un guide pour gérer l'informatique avec l'automatisation
- Livre électronique :Automatisation Ansible pour les administrateurs système
- Témoignages du terrain :guide de l'administrateur système sur l'automatisation informatique
- eBook :Un guide de Kubernetes pour les SRE et les administrateurs système
- Derniers articles sur l'administrateur système
3. Relais
Quand ils ont initialement introduit sudo_logsrvd (version 1.9.0) pour la collecte centrale des enregistrements de session, les clients ne pouvaient envoyer que des enregistrements directement. La version 1.9.7 a introduit le concept de relais. Avec les relais, au lieu d'envoyer des enregistrements directement, vous pouvez envoyer des enregistrements à plusieurs niveaux d'hôtes intermédiaires, qui structurent votre réseau.
Pourquoi est-ce important? Tout d'abord, les relais permettent de collecter les enregistrements de session même si l'hébergeur central est indisponible en raison de problèmes de réseau ou de maintenance. Par défaut, sudo refuse de s'exécuter lorsqu'il ne peut pas envoyer d'enregistrements, afin que les relais puissent s'assurer que vous pouvez utiliser sudo 24 heures sur 24.
Deuxièmement, cela vous permet également d'avoir des contrôles plus stricts sur votre réseau :au lieu d'ouvrir le pare-feu pour tous les hôtes au sudo_logsrvd central , il vous suffit d'autoriser le passage de votre relais.
Enfin, il vous permet de collecter des enregistrements de session à partir de réseaux sans accès direct à Internet, comme les réseaux privés AWS, où vous pouvez installer sudo_logsrvd en mode relais sur l'hôte passerelle.
Lorsque vous utilisez des relais, configurer le sudo clients et le sudo_logsrvd central reste le même. Sur l'hôte relais, ajoutez la ligne suivante au [relay] section de sudo_logsrvd.conf :
relay_host = 172.16.167.161Si la connexion réseau vers le serveur central est connue pour être problématique, vous pouvez configurer le relais pour stocker les enregistrements avant de les retransmettre :
store_first = true4. Sous-commandes de journalisation
Avez-vous déjà voulu savoir ce qui se passe dans une session shell démarrée via sudo ? Oui, les enregistrements de session sont là, mais regarder des heures d'enregistrements juste pour voir quelques commandes exécutées est ennuyeux et une énorme perte de temps. Heureusement, la version 1.9.8 a introduit des sous-commandes de journalisation. Il suffit maintenant de vérifier régulièrement les messages de votre journal et de ne regarder les enregistrements que lorsqu'un événement suspect se produit.
Vous n'avez même pas besoin d'une règle pour autoriser l'accès au shell à accéder au shell, juste l'accès à un éditeur. La plupart des éditeurs peuvent exécuter des commandes externes. Mon éditeur préféré est JOE, et c'est ce que vous pouvez voir quand je le lance via sudo :
Aug 30 13:03:00 czplaptop sudo[10150]: czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/joeRien d'intéressant, juste un éditeur, même si je crée un shell et supprime quelques fichiers et partitions de ce shell. Voyons maintenant ce qui se passe lorsque vous activez les sous-commandes de journalisation :
Aug 30 13:13:14 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/joe
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/sh -c /bin/bash
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/readlink /proc/10889/exe
[...]
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/sed -r s@/*:|([^\\]):@\1\n@g;H;x;s@/\n@\n@
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/tty
Aug 30 13:13:42 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/id
Aug 30 13:13:56 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/ls -A -N --color=none -T 0 /usr/share/syslog-ng/include/scl/
J'ai omis des dizaines de lignes pour économiser de l'espace, mais vous pouvez toujours voir que j'ai démarré un shell, et les commandes exécutées par bash_profile sont également disponibles dans les logs.
Vous pouvez activer les sous-commandes de journalisation dans les sudoers fichier en utilisant le paramètre suivant :
Defaults log_subcmds
Dans le traditionnel sudo logs, vous pouvez voir à partir du sudo ID de processus indiquant que ces journaux proviennent du même sudo session. Si vous activez la journalisation au format JSON, comme indiqué précédemment, sudo enregistre beaucoup plus d'informations dans les journaux, ce qui facilite leur analyse.
5. Intercepter les sous-commandes
Les sous-commandes de journalisation suppriment la plupart des problèmes cachés de sudo , mais il y a des situations où vous ne voulez pas seulement regarder ce qui se passe mais aussi contrôler le flux des événements. Par exemple, vous devez accorder un accès shell à un utilisateur, mais vous souhaitez toujours l'empêcher d'exécuter une commande spécifique. L'interception est idéale dans de tels cas. Il existe, bien sûr, certaines limitations, comme vous ne pouvez pas limiter les commandes intégrées des shells.
Disons le who la commande est dangereuse. Vous pouvez activer l'interception en deux étapes :la première l'active, la seconde la configure. Dans ce cas, mon utilisateur n'est pas autorisé à exécuter who :
Defaults intercept
czanik ALL = (ALL) ALL, !/usr/bin/who
Voici ce qui se passe lorsque je démarre une session root shell via sudo et essayez d'exécuter who :
$ sudo -s
# who
Sorry, user czanik is not allowed to execute '/usr/bin/who' as root on czplaptop.
bash: /usr/bin/who: Permission denied
Vous pouvez facilement désactiver complètement les shells en cours d'exécution :
Defaults intercept
Cmnd_Alias SHELLS=/usr/bin/bash, /usr/bin/sh, /usr/bin/csh
czanik ALL = (ALL) ALL, !SHELLS
Cependant, cela signifie également que vous ne pouvez pas démarrer de sessions shell via sudo . Non seulement cela, mais vous ne pouvez pas non plus exécuter de commandes externes à partir d'éditeurs. C'est ce qui se passe lorsque j'essaie de démarrer le ls commande depuis vi :
$ sudo vi /etc/issue
Sorry, user czanik is not allowed to execute '/bin/bash -c /bin/ls' as root on czplaptop.
Cannot execute shell /bin/bash
Press ENTER or type command to continue
Quelle est la prochaine ?
J'espère que la lecture de mon article vous donnera envie d'essayer vous-même ces nouvelles fonctionnalités. Vous pouvez installer le dernier sudo sur de nombreuses distributions Linux et variantes UNIX à partir de votre gestionnaire de packages, ou utilisez un programme d'installation binaire disponible sur le site Web Sudo.
Cet article vous donne juste un aperçu des nouvelles possibilités. Si vous souhaitez en savoir plus sur ces fonctionnalités, visitez le site Web, qui héberge des pages de manuel, ainsi que le blog Sudo.