Що означає помилку "X немає у файлі sudoers. Повідомлятиметься про цей випадок ". Філософсько / логічно мається на увазі?

Поряд із запитанням " Ім'я користувача відсутнє у файлі судорів. Про цей інцидент буде повідомлено ", який пояснював програмні аспекти помилки та пропонував деякі обходи, я хочу знати: що ця помилка означає?

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

Колишня частина помилки пояснює, очевидно, помилку. Але друга частина говорить, що "Про цю помилку буде повідомлено" ?! Але чому? Чому про помилку буде повідомлено і де? Кому? Я і користувач, і адміністратор, і не отримував жодного звіту :)!

Адміністратор (и) системи, ймовірно, захоче знати, коли непривілейований користувач намагається, але не виконує команди за допомогою sudo. Якщо це станеться, це може бути ознакою

1. цікавий законний користувач, який просто випробовує речі, або
2. хакер, який намагається зробити "погані речі".

Оскільки sudoсамі по собі не можуть розрізнити це, невдалі спроби використання sudoдоводяться до відома адміністраторів.

Залежно від того, як sudoналаштовано у вашій системі, будь-яка спроба (успішна чи ні) використання sudoбуде зареєстрована. Успішні спроби реєструються з метою аудиту (щоб можна було відслідковувати, хто що робив коли), і невдалі спроби безпеки.

Якщо у мене є досить ванільна установка Ubuntu, це зареєстровано /var/log/auth.log.

Якщо користувач тричі вводить неправильний пароль, або якщо їх немає у sudoersфайлі, електронному листу надсилається кореневий лист (залежно від конфігурації sudo, див. Нижче). Саме це означає "повідомлення про цей інцидент".

Електронний лист матиме важливу тему:

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

Тіло повідомлення містить, наприклад, відповідні рядки з лог-файлу

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

(Тут, користувач nobodyнамагався втекти lsчерез sudoяк корінь, але не так як вони були не в sudoersфайлі).

Не надсилається електронний лист, якщо (локальна) пошта не була налаштована в системі.

Усі ці речі також настроюються, і локальні варіанти в конфігурації за замовчуванням можуть відрізнятися між варіантами Unix.

Погляньте на mail_no_userналаштування (та пов’язані з цим mail_*настройки) у sudoersпосібнику (мій акцент нижче):

mail_no_user

Якщо встановлено, пошта буде надіслана користувачеві поштового зв’язку, якщо користувач, який викликає, не знаходиться у sudoersфайлі. Цей прапор увімкнено за замовчуванням .

У Debian та його похідних sudoреєструються звіти про інциденти, /var/log/auth.logякі містять інформацію про авторизацію системи, включаючи входи користувачів та механізми аутентифікації:

$ 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

Цей файл журналу, як правило, доступний лише користувачам admгрупи, тобто користувачам, які мають доступ до системних завдань моніторингу :

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

З Вікі Debian :

Груповий адміністратор використовується для завдань системного моніторингу. Члени цієї групи можуть читати багато файлів журналу в / var / log та можуть використовувати xconsole. Історично / var / log був / usr / adm (і пізніше / var / adm), таким чином, назва групи.

Користувачі в admгрупі, як правило, є адміністраторами , і цей дозвіл групи призначений для того, щоб вони могли читати файли журналів без необхідності su.

За замовчуванням sudoвикористовується програма Syslog authдля ведення журналів . sudoПоведінка реєстрації журналу може бути змінено за допомогою параметрів logfileабо syslogв /etc/sudoersабо /etc/sudoers.d:

• logfileПараметр задає шлях до sudoфайлу журналу.
• Цей syslogпараметр встановлює об'єкт Syslog, коли syslog(3)він використовується для ведення журналу.

Syslog authоб'єкт перенаправляються /var/log/auth.logв etc/syslog.confнаявності наступної строфи конфігурації:

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

Технічно це нічого не означає. Багато (якщо не всі) іншого програмного забезпечення реєструються, не вдалося або в інший спосіб. Наприклад sshdі 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

Крім того, багато систем мають певну автоматику для виявлення надмірних помилок аутентифікації, щоб мати можливість вирішувати можливі спроби грубої сили або просто використовувати інформацію для відновлення подій після появи проблем.

sudoтут не робиться нічого особливо виняткового. Все повідомлення означає, що автор програми, sudoсхоже, взяв дещо агресивну філософію у спілкуванні з користувачами, які, як правило, виконують команди, які вони не можуть використовувати.

Це просто означає, що хтось намагався використовувати sudoкоманду (для доступу до привілеїв адміністратора), хто не має дозволу на її використання (тому що вони не вказані у файлі sudoers). Це може бути спроба злому або якийсь інший ризик безпеки, тому в повідомленні йдеться про те, що про спробу використання sudoбуде повідомлено системного адміністратора, щоб вони могли розслідувати.