Qu'est-ce que l'erreur “X n'est pas dans le fichier sudoers. Cet incident sera signalé. "Signifie philosophiquement / logiquement?

Parallèlement à la question "Le nom d' utilisateur n'est pas dans le fichier sudoers. Cet incident sera signalé " qui expliquait les aspects programmatiques de l'erreur et suggérait quelques solutions de contournement, je veux savoir: que signifie cette erreur?

X is not in the sudoers file.  This incident will be reported.

La première partie de l'erreur explique clairement l'erreur. Mais la deuxième partie dit que "Cette erreur sera signalée"?! Mais pourquoi? Pourquoi l'erreur sera signalée et où? À qui? Je suis à la fois utilisateur et administrateur et n'ai reçu aucun rapport :)!

Les administrateurs d'un système sont susceptibles de vouloir savoir quand un utilisateur non privilégié essaie mais échoue à exécuter des commandes à l'aide de sudo. Si cela se produit, cela pourrait être un signe de

1. un utilisateur légitime curieux essayant simplement les choses, ou
2. un pirate essayant de faire de "mauvaises choses".

Comme sudoen soi, il ne peut pas faire la distinction entre ceux-ci, les tentatives infructueuses d'utilisation sudosont portées à l'attention des administrateurs.

Selon la sudoconfiguration de votre système, toute tentative d'utilisation (réussie ou non) sudosera enregistrée. Les tentatives réussies sont enregistrées à des fins d'audit (pour pouvoir suivre qui a fait quoi, quand) et les tentatives de sécurité ont échoué.

Sur une configuration Ubuntu assez vanille que j'ai, c'est connecté /var/log/auth.log.

Si un utilisateur donne trois fois le mauvais mot de passe ou s'il ne figure pas dans le sudoersfichier, un e-mail est envoyé à root (selon la configuration de sudo, voir ci-dessous). C'est ce que l'on entend par "cet incident sera signalé".

L'e-mail aura un sujet important:

Subject: *** SECURITY information for thehostname ***

Le corps du message contient les lignes pertinentes du fichier journal, par exemple

thehostname : Jun 22 07:07:44 : nobody : user NOT in sudoers ; TTY=console ; PWD=/some/path ; USER=root ; COMMAND=/bin/ls

(Ici, l'utilisateur a nobodytenté de s'exécuter lsen sudotant que root, mais a échoué car il ne figurait pas dans le sudoersfichier).

Aucun e-mail n'est envoyé si le courrier (local) n'a pas été configuré sur le système.

Toutes ces choses sont également configurables, et les variations locales de la configuration par défaut peuvent différer entre les variantes Unix.

Jetez un œil au mail_no_userparamètre (et aux mail_*paramètres associés ) dans le sudoersmanuel (je souligne ci-dessous):

mail_no_user

S'il est défini, le courrier sera envoyé à l'utilisateur mailto si l'utilisateur appelant n'est pas dans le sudoersfichier. Ce drapeau est activé par défaut .

Dans Debian et ses dérivés, les sudorapports d'incident sont enregistrés et /var/log/auth.logcontiennent des informations d'autorisation système, y compris les connexions utilisateur et les mécanismes d'authentification qui ont été utilisés:

$ sudo su
[sudo] password for regularjohn: 
regularjohn is not in the sudoers file.  This incident will be reported.

[as root]

$ tail -n 1 /var/log/auth.log
Jun 21 16:30:26 marvin sudo: regularjohn : user NOT in sudoers ; TTY=pts/19 ; PWD=/home/regularjohn ; USER=root ; COMMAND=/bin/su

Ce fichier journal n'est généralement accessible qu'aux utilisateurs du admgroupe, c'est-à-dire aux utilisateurs ayant accès aux tâches de surveillance du système :

$ ls -la /var/log/auth.log
-rw-r----- 1 syslog adm 76189 Jun 21 16:30 /var/log/auth.log

Depuis le wiki Debian :

Le groupe adm est utilisé pour les tâches de surveillance du système. Les membres de ce groupe peuvent lire de nombreux fichiers journaux dans / var / log et peuvent utiliser xconsole. Historiquement, / var / log était / usr / adm (et plus tard / var / adm), d'où le nom du groupe.

Les utilisateurs du admgroupe sont généralement des administrateurs , et cette autorisation de groupe est destinée à leur permettre de lire les fichiers journaux sans avoir à le faire su.

Par défaut, sudoutilise la fonction Syslog authpour la journalisation . sudoLe comportement de l' enregistrement de » peut être modifié en utilisant la logfileou syslogoptions /etc/sudoersou /etc/sudoers.d:

• L' logfileoption définit le chemin d'accès au sudofichier journal.
• L' syslogoption définit la fonction Syslog lorsqu'elle syslog(3)est utilisée pour la journalisation.

La fonction Syslog authest redirigée vers /var/log/auth.login etc/syslog.confpar la présence de la strophe de configuration suivante:

auth,authpriv.*         /var/log/auth.log

Techniquement, cela ne signifie pas grand-chose. De nombreux autres logiciels (sinon tous) se connectent, ont échoué ou autrement. Par exemple sshdet su:

Jun 21 17:52:22 somehost sshd[25807]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=::1  user=root
Jun 21 17:52:22 somehost sshd[25807]: Failed password for root from ::1 port 37268 ssh2
Jun 21 17:52:23 somehost sshd[25807]: Connection closed by ::1 port 37268 [preauth]
Jun 21 17:52:28 somehost su[25809]: pam_unix(su:auth): authentication failure; logname= uid=1000 euid=0 tty=/dev/pts/15 ruser=someuser rhost=  user=root
Jun 21 17:52:28 somehost su[25809]: pam_authenticate: Authentication failure
Jun 21 17:52:28 somehost su[25809]: FAILED su for root by someuser

En outre, de nombreux systèmes disposent d'une sorte d'automatisation pour détecter les erreurs d'authentification excessives afin de pouvoir faire face à d'éventuelles tentatives de force brute, ou simplement utiliser les informations pour reconstruire les événements après l'apparition des problèmes.

sudone fait rien d'exceptionnel ici. Tout le message signifie que l'auteur de sudosemble avoir adopté une philosophie quelque peu agressive en communiquant avec les utilisateurs qui exécutent des commandes qu'ils ne peuvent pas utiliser.

Cela signifie simplement que quelqu'un a essayé d'utiliser la sudocommande (pour accéder aux privilèges d'administrateur), qui n'a pas l'autorisation de l'utiliser (car ils ne sont pas répertoriés dans le fichier sudoers). Il peut s'agir d'une tentative de piratage ou d'un autre type de risque pour la sécurité. Le message indique donc que la tentative d'utilisation de sudosera signalée à l'administrateur système afin qu'il puisse enquêter.