Lỗi X không có gì trong tập tin sudoers. Sự cố này sẽ được báo cáo. Ý nghĩa triết học / logic?

Bên cạnh câu hỏi " Tên người dùng không có trong tệp sudoers. Sự cố này sẽ được báo cáo " giải thích các khía cạnh lập trình của lỗi và đề xuất một số cách giải quyết, tôi muốn biết: lỗi này có nghĩa là gì?

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

Phần trước của lỗi giải thích, rõ ràng, lỗi. Nhưng phần thứ hai nói rằng "Lỗi này sẽ được báo cáo"?! Nhưng tại sao? Tại sao lỗi sẽ được báo cáo và ở đâu? Cho ai? Tôi là cả người dùng và quản trị viên và không nhận được bất kỳ báo cáo nào :)!

(Các) quản trị viên của một hệ thống có thể muốn biết khi nào người dùng không có đặc quyền cố gắng nhưng không thực thi các lệnh bằng cách sử dụng sudo. Nếu điều này xảy ra, nó có thể là một dấu hiệu của

1. một người dùng hợp pháp tò mò chỉ cần thử mọi thứ, hoặc
2. một hacker đang cố gắng làm "những điều xấu".

Vì sudobản thân nó không thể phân biệt giữa những điều này, những lần thử sử dụng thất bại sudođược đưa đến sự chú ý của các quản trị viên.

Tùy thuộc vào cách sudocấu hình trên hệ thống của bạn, mọi nỗ lực (thành công hay không) sử dụng sudosẽ được ghi lại. Các nỗ lực thành công được ghi lại cho mục đích kiểm toán (để có thể theo dõi ai đã làm gì khi nào) và các nỗ lực không thành công cho bảo mật.

Trên một thiết lập Ubuntu khá vanilla mà tôi có, điều này đã được đăng nhập /var/log/auth.log.

Nếu người dùng cung cấp mật khẩu sai ba lần hoặc nếu chúng không có trong sudoerstệp, một email sẽ được gửi đến root (tùy thuộc vào cấu hình của sudo, xem bên dưới). Đây là những gì có nghĩa là "sự cố này sẽ được báo cáo".

Email sẽ có một chủ đề nổi bật:

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

Phần thân của thông báo chứa các dòng có liên quan từ logfile, ví dụ

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

(Ở đây, người dùng nobodyđã cố chạy lsqua sudoroot, nhưng không thành công vì chúng không có trong sudoerstệp).

Không có email nào được gửi nếu thư (cục bộ) chưa được thiết lập trên hệ thống.

Tất cả những điều này cũng có thể cấu hình được và các biến thể cục bộ trong cấu hình mặc định có thể khác nhau giữa các biến thể Unix.

Hãy xem mail_no_usercài đặt (và các mail_*cài đặt liên quan ) trong sudoershướng dẫn sử dụng (nhấn mạnh của tôi bên dưới):

mail_no_user

Nếu được đặt, thư sẽ được gửi đến người dùng mailto nếu người dùng gọi không có trong sudoerstệp. Cờ này được bật theo mặc định .

Trong Debian và các dẫn xuất của nó, các sudobáo cáo sự cố được ghi lại /var/log/auth.logchứa thông tin ủy quyền hệ thống, bao gồm thông tin đăng nhập người dùng và cơ chế xác thực đã được sử dụng:

$ 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

Tệp nhật ký này thường chỉ có thể truy cập đối với người dùng trong admnhóm, tức là người dùng có quyền truy cập vào các tác vụ giám sát hệ thống :

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

Từ Wiki Wiki :

Quản trị nhóm được sử dụng cho các nhiệm vụ giám sát hệ thống. Thành viên của nhóm này có thể đọc nhiều tệp nhật ký trong / var / log và có thể sử dụng xconsole. Trong lịch sử, / var / log là / usr / adm (và sau đó là / var / adm), do đó là tên của nhóm.

Người dùng trong admnhóm thường là quản trị viên và quyền này của nhóm nhằm mục đích cho phép họ đọc tệp nhật ký mà không cần phải su.

Theo mặc định, sudosử dụng authtiện ích Syslog để đăng nhập . sudoHành vi ghi nhật ký có thể được sửa đổi bằng cách sử dụng logfilehoặc syslogtùy chọn trong /etc/sudoershoặc /etc/sudoers.d:

• Các logfiletùy chọn thiết lập đường dẫn đến sudotập tin đăng nhập.
• Các syslogtùy chọn thiết lập cơ sở Syslog khi syslog(3)đang được sử dụng cho khai thác gỗ.

Các Syslog authcơ sở chuyển hướng đến /var/log/auth.logtrong etc/syslog.confsự hiện diện của đoạn thơ cấu hình sau:

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

Về mặt kỹ thuật, nó không có nghĩa gì nhiều. Nhiều (nếu không phải tất cả) các phần mềm khác đăng nhập đăng nhập, thất bại hoặc cách khác. Ví dụ sshdvà 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

Ngoài ra, nhiều hệ thống có một số loại tự động hóa để phát hiện lỗi xác thực quá mức để có thể xử lý các nỗ lực vũ phu có thể hoặc chỉ sử dụng thông tin để xây dựng lại các sự kiện sau khi sự cố xuất hiện.

sudokhông làm gì đặc biệt ở đây Tất cả các thông điệp có nghĩa là tác giả sudodường như đã có một triết lý hơi tích cực trong việc giao tiếp với người dùng xảy ra để chạy các lệnh mà họ không thể sử dụng.

Điều đó chỉ có nghĩa là ai đó đã cố gắng sử dụng sudolệnh (để truy cập các đặc quyền của quản trị viên), người không có quyền sử dụng nó (vì họ không được liệt kê trong tệp sudoers). Đây có thể là một nỗ lực hack hoặc một số rủi ro bảo mật khác, vì vậy thông báo nói rằng việc sử dụng đã cố gắng sudosẽ được báo cáo cho quản trị viên hệ thống, để họ có thể điều tra.