J'utilise Zabbix pour surveiller mon environnement et zabbix_agentd
exécute comme utilisateur zabbix
un script personnalisé toutes les 60 secondes; Il utilise Sudo
pour exécuter ce script comme root
.
Dans /var/log/auth.log
Je vois toutes les 60 secondes:
Aug 11 17:40:32 my-server Sudo: pam_unix(Sudo:session): session opened for user root by (uid=0)
Aug 11 17:40:32 my-server Sudo: pam_unix(Sudo:session): session closed for user root
Je veux arrêter ce message d'inonder mon journal. J'ai ajouté la ligne suivante à /etc/pam.d/Sudo
Dossier, immédiatement avant session required pam_unix.so
:
session [success=1 default=ignore] pam_succeed_if.so service in Sudo quiet uid = 0
et le message a disparu.
mais le problème est que cette façon, j'ai supprimé chaque message PAM lorsque quelqu'un exécute un script avec Sudo
comme root
.
Je veux arrêter le message uniquement pour l'utilisateur zabbix
(pas tous les autres utilisateurs). Sudo
sait que zabbix
utilisateur souhaite exécuter le script avec root
privilèges et y a-t-il un moyen de dire à PAM qui? Comment puis-je dire à PAM de ne pas vous connecter à un utilisateur spécifique lors de l'utilisation Sudo
?
NOTE: J'ai essayé de filtrer les messages dans Syslog; Bien que cela fonctionne, il a le même problème que ce qui précède, à savoir qu'il est trop indiscriminé, car le message de journal n'indique pas quel utilisateur est en train de devenir root.
Vous semblez assez près de votre ligne PAM Conf:
session [success=1 default=ignore] pam_succeed_if.so service in Sudo quiet uid = 0
En regardant la page manuelle de pam_succeed_if
, Je pense que vous voulez tester que l'utilisateur demandeur (ruser
) est zabbix
.
Donc je suggère:
session [success=1 default=ignore] pam_succeed_if.so quiet uid = 0 ruser = zabbix
Cela supprimera le prochain test lorsque l'utilisateur zabbix
devient root
(mais aucune autre transition). J'ai testé cela avec une paire de mes propres utilisateurs.
Retirer le uid = 0
Testez dans ce qui précède si vous souhaitez rester silencieux sur zabbix
devenant n'importe quel utilisateur, plutôt que de la racine.
J'ai enlevé le service in Sudo
Test: c'est redondant étant donné que cette ligne est en /etc/pam.d/Sudo
.
Basé sur la réponse de Toby, j'ai trouvé un moyen de configurer cela de manière légèrement différente sur Debian/Ubuntu. Pour le contexte, voir:
Donc, Debian/Ubuntu a ceci pam-auth-update
commande et quand vous regardez /etc/pam.d/Sudo
Cela ressemble à ceci:
#%PAM-1.0
@include common-auth
@include common-account
@include common-session-noninteractive
et /etc/pam.d/common-session-noninteractive
ressemble à ça:
#
# /etc/pam.d/common-session-noninteractive - session-related modules
# common to all non-interactive services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define tasks to be performed
# at the start and end of all non-interactive sessions.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.
# here are the per-package modules (the "Primary" block)
session [default=1] pam_permit.so
# here's the fallback if no module succeeds
session requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required pam_permit.so
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
# end of pam-auth-update config
Tellement sûr, je pouvais modifier l'un des fichiers ci-dessus, mais il existe clairement une "puissance supérieure" au travail ici. Comment obtenir mes modifications pour jouer sympa avec d'autres forfaits qui voudront peut-être ajouter des règles de PAM? Pour ce faire, il semblait que je ne pouvais pas simplement ajouter une ligne dans /etc/pam.d/Sudo
entre les deux @include
s comme ça ..
##### THIS DIDN'T WORK :( ######
@include common-auth
@include common-account
session [default=ignore] pam_succeed_if.so quiet_success service = Sudo uid = 0 ruser = myappuser
@include common-session-noninteractive
Après avoir lu les liens ci-dessus ainsi que d'autres exemples (voir /usr/share/pam-configs/unix
) Je suis venu avec ceci, dans /usr/share/pam-configs/myapp
:
# Don't log "session opened" messages for myapp user
# See: https://wiki.ubuntu.com/PAMConfigFrameworkSpec
# https://manpages.debian.org/stretch/libpam-modules/pam_succeed_if.8.en.html
Name: myapp disable session logging
Default: yes
Priority: 300
Session-Type: Additional
Session:
[default=ignore] pam_succeed_if.so quiet_success service = Sudo uid = 0 ruser = myappuser
Session
et Session-Type
contrôle quels fichiers sont édités et Priority
définit quel ordre ils entrent. Après avoir ajouté ce fichier et fonctionnant pam-auth-update
, /etc/pam.d/common-session-noninteractive
ressemble à ceci (en bas :)
#... omitted
session required pam_permit.so
# and here are more per-package modules (the "Additional" block)
session [default=ignore] pam_succeed_if.so quiet_success service = Sudo uid = 0 ruser = myappuser
session required pam_unix.so
# end of pam-auth-update config
... qui est ce que nous voulons parce que notre pam_succeed_if
la ligne doit venir avant session required pam_unix.so
. (Cette ligne vient de /use/share/pam-configs/unix
et a un Priority: 256
Cela finit donc par seconde.) Notez également que j'ai quitté le service = Sudo
Prédicat depuis common-session-noninteractive
peut également être inclus dans d'autres configures en plus de Sudo
.
Dans mon cas, j'avais déjà emballé mon code comme un installateur .deb alors j'ai ajouté le /usr/share/pam-configs/myapp
fichier et ajouté pam-auth-update --package
à mon postinst
et prerm
scripts et je suis bon d'aller!
Si vous lisez le article PamConfigFrameworkSpec sur lequel j'ai relié ci-dessus , il définit un Session-Interactive-Only
option, mais fait ne dispose pas de manière à spécifier uniquement des règles non interactives . Donc /etc/pam.d/common-session
était également mis à jour . Je ne pense pas qu'il y ait un moyen de voir ça. Si vous acceptez des sessions interactives, les sessions interactives ne sont pas connectées à cet utilisateur (IT IS un compte de service, non?) Ensuite, vous devriez être tout défini!
En plus de session openened|closed
lignes que pam émet, Sudo
enregistre des informations supplémentaires sur la commande exécutée. Cela ressemble à ceci:
[user] : TTY=unknown ; PWD=... ; USER=root ; COMMAND=...
Si vous aussi Voulez-vous supprimer cela, ouvrez ce lien puis continuez ci-dessous ...
Donc ... vous êtes probablement familier avec typique /etc/sudoers.d/___
Configuration qui pourrait faire quelque chose comme ceci pour un compte de service ayant besoin de superutilisateurs privilégiés pour quelques actions:
myuser ALL=(ALL) NOPASSWD: /bin/ping
cela pourrait aller dans /etc/sudoers.d/10_myuser
. Eh bien, entre autres choses vous pouvez également spécifier Defaults
. Notez spécifiquement cette syntaxe 'Defaults' ':' User_List
Maintenant, regardez la section Options Sudoers . Les bits intéressants incluent log_input
, log_output
Mais (probablement) plus important encore, syslog
et logfile
. Il me semble que dans des versions récentes de Debian, Rsyslog ou Sudo
Connectez-vous à stdout
ou stderr
par défaut. Donc, pour moi, cela se présentait dans le journal journalier pour mon service et non par ex. /var/log/auth.log
Où il ne serait pas mélangé dans mes journaux d'application. Pour supprimer la journalisation sudo, j'ai ajouté ce qui suit à /etc/sudoers.d/10_myuser
cela ressemble donc à:
Defaults:myuser !logfile, !syslog
myuser ALL=(ALL) NOPASSWD: /bin/ping
YMMV, si vous sentez la désactivation de la journalisation crée des problèmes avec des audits de sécurité, vous pouvez également essayer de résoudre ce problème via des filtres RSSLOG.
Après un assez peu d'essais effrayants et de recherches, j'ai trouvé une solution de travail pour l'étirement de Debian (sur la framboise). Il y a sûrement plus d'une façon d'accomplir ce que demander. Mais la documentation PAM est écrasante, la plupart des choses sont vraiment TL; DR.
/etc/rsyslog.d/anyname.conf
en utilisant::msg, contains, "session opened for user root by pi" stop
/etc/pam.d/Sudo
/usr/share/pam-configs/
/etc/sudoers.d/020_pi
Je vais vous montrer comment faire (2) et (4).
AVERTISSEMENT
Ne modifiez aucun fichier dans
/etc/pam.d/
Sans changer d'abord leur monde d'écrire des autorisations. Si vous ne le faites pas, et faites-vous une erreur, vous pouvez vous bloquer de toute utilisation future de sudo/s! Assurez-vous donc que vous avez testé les nouveaux paramètres avant de la modifier. (Par défaut est 644)
Nous voulons nous débarrasser de ce qui suit /var/log/auth.log
pourriel:
May 10 11:28:03 xxx Sudo[26437]: pam_unix(Sudo:session): session opened for user root by (uid=0)
May 10 11:28:07 xxx Sudo[26437]: pam_unix(Sudo:session): session closed for user root
Faites ceci:
# Sudo chmod 666 /etc/pam.d/Sudo
# Sudo cat /etc/pam.d/Sudo
#%PAM-1.0
@include common-auth
@include common-account
session [success=1 default=ignore] pam_succeed_if.so quiet_success uid = 0 ruser = pi
@include common-session-noninteractive
Ce qui est d'importance cruciale ici, est-ce que success=1
, signifie ignorer la clause suivante (ou dans PAM LINGO "sauter sur le module suivant de la pile"), en cas de succès.
De man pam.conf
:
Ignorer - Lorsqu'il est utilisé avec une pile de modules, l'état de retour du module ne contribuera pas au code de retour. L'application obtient l'application.
DONE - équivalent à OK avec l'effet secondaire de la terminaison de la pile de module et du PAM de retour immédiatement à l'application.
[~ # ~] n [~ # ~ ~] - équivalent à OK avec l'effet secondaire de sauter sur les n modules suivants dans la pile.
Ensuite, redémarrez et laissez-le courir quelques heures (pour vérifier les travaux de cron par exemple) pour tester cela. Assurez-vous ensuite de ré-instaurer les autorisations de fichier, sinon vous aurez un trou de sécurité béant dans votre système. (Sudo chmod 644 /etc/pam.d/Sudo
)
Nous voulons aussi vous débarrasser des messages comme celui-ci:
May 11 18:23:20 xxx Sudo: pi : TTY=unknown ; PWD=... ; USER=root ; COMMAND=/usr/bin/arp-scan -q -l
Dans mon cas, cela a été généré par un script IDS qui exécutait ARP-Scan toutes les quelques minutes. Pour le supprimer de l'affichage dans les journaux, créez le fichier suivant:
# Sudo nano /etc/sudoers.d/020_pi
# Sudo cat /etc/sudoers.d/020_pi
Defaults:pi !logfile, !syslog
pi xxx = (root) NOPASSWD: /usr/bin/arp-scan
(Ici xxx
est votre nom de machine et pi
est le nom d'utilisateur.)