Co oznacza błąd „X nie znajduje się w pliku sudoers. Ten incydent zostanie zgłoszony. ”Filozoficznie / logicznie?

Obok pytania „ Nazwa użytkownika nie ma w pliku sudoers. Ten incydent zostanie zgłoszony ”, który wyjaśnił programowe aspekty błędu i zasugerował pewne obejścia, chcę wiedzieć: co oznacza ten błąd?

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

Poprzednia część błędu jasno wyjaśnia błąd. Ale druga część mówi, że „ten błąd zostanie zgłoszony” ?! Ale dlaczego? Dlaczego błąd zostanie zgłoszony i gdzie? Do kogo? Jestem zarówno użytkownikiem, jak i administratorem i nie otrzymałem żadnego raportu :)!

Administrator systemu może chcieć wiedzieć, kiedy nieuprzywilejowany użytkownik próbuje, ale nie wykonuje poleceń za pomocą sudo. Jeśli tak się stanie, może to oznaczać

1. ciekawy, legalny użytkownik, który po prostu próbuje rzeczy lub
2. haker próbuje zrobić „złe rzeczy”.

Ponieważ sudosamo w sobie nie jest w stanie ich rozróżnić, sudoadministratorzy zwracają uwagę na nieudane próby użycia .

W zależności od sudokonfiguracji w systemie każda próba (pomyślna lub nie) użycia sudozostanie zarejestrowana. Pomyślne próby są rejestrowane do celów kontrolnych (aby móc śledzić, kto co zrobił, kiedy) i nieudane próby bezpieczeństwa.

W dość waniliowej konfiguracji Ubuntu, którą mam, jest to zalogowane /var/log/auth.log.

Jeśli użytkownik trzy razy poda nieprawidłowe hasło lub nie ma go w sudoerspliku, wiadomość e-mail zostanie wysłana do katalogu głównego (w zależności od konfiguracji sudo, patrz poniżej). To właśnie oznacza „ten incydent zostanie zgłoszony”.

Wiadomość e-mail będzie miała ważny temat:

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

Treść wiadomości zawiera na przykład odpowiednie wiersze z pliku dziennika

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

(Tutaj użytkownik nobodypróbował uruchomić lspoprzez sudojako root, ale nie powiodło się, ponieważ nie były one w sudoerspliku).

Wiadomość e-mail nie jest wysyłana, jeśli (lokalna) poczta nie została skonfigurowana w systemie.

Wszystkie te rzeczy są również konfigurowalne, a lokalne odmiany w domyślnej konfiguracji mogą się różnić między wariantami Uniksa.

Spójrz na mail_no_userustawienie (i powiązane mail_*ustawienia) w sudoersinstrukcji (moje podkreślenie poniżej):

mail_no_user

Jeśli jest ustawiony, poczta zostanie wysłana do użytkownika mailto, jeśli wywołującego użytkownika nie ma w sudoerspliku. Ta flaga jest domyślnie włączona .

W Debianie i jego pochodnych sudorejestrowane są raporty o incydentach, /var/log/auth.logktóre zawierają informacje o autoryzacji systemu, w tym dane logowania użytkownika i mechanizmy uwierzytelniania, które zostały użyte:

$ 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

Ten plik dziennika jest zazwyczaj dostępny tylko dla użytkowników w admgrupie, tj. Użytkowników mających dostęp do zadań monitorowania systemu :

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

Z Debian Wiki :

Group adm służy do monitorowania systemu. Członkowie tej grupy mogą czytać wiele plików dziennika w / var / log i mogą korzystać z xconsole. Historycznie, / var / log to / usr / adm (a później / var / adm), stąd nazwa grupy.

Użytkownicy w admgrupie są zwykle administratorami , a to uprawnienie grupy ma na celu umożliwienie im odczytu plików dziennika bez konieczności su.

Domyślnie do logowania sudoużywa narzędzia Syslogauth . sudo„s zachowanie rejestrowania można modyfikować przy użyciu logfilelub syslogopcje w /etc/sudoerslub /etc/sudoers.d:

• Ta logfileopcja ustawia ścieżkę do sudopliku dziennika.
• Ta syslogopcja ustawia funkcję Syslog, gdy syslog(3)jest używana do rejestrowania.

Syslog'a authobiekt jest przekierowywany /var/log/auth.logna etc/syslog.confobecność następującej konfiguracji pokoju:

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

Technicznie nic to nie znaczy. Wiele (jeśli nie wszystkie) inne oprogramowanie loguje się, nie powiodło się lub w inny sposób. Na przykład sshdi 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

Ponadto wiele systemów ma pewną automatyzację w wykrywaniu nadmiernych błędów uwierzytelniania, aby móc poradzić sobie z możliwymi próbami użycia siły lub po prostu użyć tych informacji do odtworzenia zdarzeń po pojawieniu się problemów.

sudonie robi tu nic szczególnie wyjątkowego. Wszystko wskazuje na to, że autor sudonajwyraźniej przyjął nieco agresywną filozofię komunikowania się z użytkownikami, którzy akurat wykonują polecenia, których nie mogą użyć.

Oznacza to po prostu, że ktoś próbował użyć sudopolecenia (aby uzyskać dostęp do uprawnień administratora), który nie ma uprawnień do korzystania z niego (ponieważ nie ma ich w pliku sudoers). Może to być próba włamania lub inne ryzyko związane z bezpieczeństwem, więc komunikat mówi, że próba użycia sudozostanie zgłoszona administratorowi systemu, aby mógł to zbadać.