Sudo事件日志

codingman included in Linux

2017-11-25 1547 words 4 minutes

Contents

1. 概述

在 Linux 中使用sudo 命令时，我们可以获得 root 访问权限来执行某些活动。但是，并非所有用户都具有此访问权限。

当有人试图在未经许可的情况下提高他们的访问级别时，就会编写一份报告。我们可能希望定制或审查这些报告。

在本教程中，我们将了解在哪里可以找到 sudo报告、如何自定义它们以及如何通过电子邮件发送它们。

2. 典型的sudo事件报告

让我们看看系统如何对失败的执行事件做出反应。假设一个用户在没有适当权限的情况下尝试sudo ：

[unprivileged_user@host ~]$ sudo ls /root
[sudo] password for unprivileged_user:
unprivileged_user is not in the sudoers file. This incident will be reported.

在这里我们可以看到系统拒绝访问并警告正在报告事件。

我们希望在日志中找到尝试的详细信息：

Mar 22 21:51:07 fedora sudo[2866]: unprivileged_user : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/unprivileged_user ; USER=root ; COMMAND=/usr/bin/ls /root

因此，作为管理员，我们可以找出谁试图访问sudo以及访问时间和方式的详细信息。

3. sudo记录报告

有两个地方可以找到失败的sudo尝试的日志：journalctl 服务和rsyslog标准日志文件。

3.1. journalctl 命令

Linux 从各种资源和服务中收集日志数据。我们可以使用journalctl命令访问它，它是systemd-journald.service的一部分。

我们可以调用不带参数的命令来查找所有日志。但是，为此目的，让我们通过指定我们感兴趣的命令的绝对文件路径来应用过滤器：

$ journalctl /usb/bin/sudo
Apr 08 07:07:59 fedora sudo[3567]: unprivileged_user : TTY=pts/0 ; PWD=/home/unprivileged_user ; USER=root ; COMMAND=/usr/bin/less /etc/shadow
May 11 16:53:11 ubuntu sudo[22373]: tester : TTY=pts/0 ; PWD=/home/tester ; USER=root ; COMMAND=/etc/init.d/apache2 start

即使使用此过滤器，journalctl命令也可能会向我们显示我们不感兴趣的事件。因此，为了关注错误，让我们添加优先级标志*-p*，值为 3（错误状态）：

$ journalctl -p 3 /usr/bin/sudo

Mar 22 20:08:28 fedora sudo[3944]: unprivileged_user : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/unprivileged_user ; USER=root ; COMMAND=/usr/bin/less /etc/shadow
Mar 22 23:25:20 fedora sudo[3944]: unprivileged_user : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/unprivileged_user ; USER=root ; COMMAND=/usr/bin/service httpd stop

3.2. sudo日志文件

包含sudo事件的默认日志文件取决于特定的 Linux 发行版。更具体地说，对于最常见的 Linux 操作系统，可以在不同的文件中找到日志文件：

RPM-flavor (CentOS, Fedora) – /var/log/secure
Debian-Ubuntu 风格 (Ubuntu) – /var/log/auth.log
openSUSE – /var/日志/消息

我们可以通过编辑*/etc/sudoers和rsyslogd*系统配置文件来自定义这些日志文件。我们通过调用以下命令开始编辑配置文件：

$ sudo visudo

然后插入以下行以设置备用事件日志文件：

Defaults syslog=local1

接下来，通过使用我们喜欢的文本编辑器，我们编辑*/etc/rsyslog.conf文件（/etc/rsyslog.d/50-default.conf对于 Ubuntu 操作系统）。我们需要将local1*设施指令与所需的新日志文件相关联。为此，我们在其他定义的日志记录工具的顶部添加下一行：

local1.* /var/log/sudo.log

最后，为了激活更改，我们重新启动rsyslogd服务：

$ sudo systemctl restart rsyslog

4. sudo通过电子邮件报告

如果愿意，我们可以通过电子邮件传达sudo警告和一般信息。我们可以通过编辑*/etc/sudoers*配置文件来自定义它。

4.1. 电子邮件选项

让我们尝试配置我们的系统以通过电子邮件生成报告。首先，我们通过添加一些指令来定义将收集最终报告的电子邮件帐户：

Defaults        mailto="ubuntu@localhost"
Defaults        env_reset
Defaults        mail_no_user
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

现在，让我们看看当非特权用户tester 尝试设置crontab作业时会发生什么：

$ sudo crontab -e
[sudo] password for tester: 
tester is not in the sudoers file.  This incident will be reported.

由于不允许用户tester执行此类操作，系统会通过电子邮件向mailto电子邮件地址发出警告ubuntu@localhost

如果我们访问ubuntu用户本地邮箱：

$ mail

然后我们可以阅读记录的警告：

N 7 tester@ubuntu Wed May 11 19:16 16/581 *** SECURITY information for ubuntu ***

在这封电子邮件中，我们能够阅读与此事件相关的完整日志：

& 7
Message 7:
From tester@ubuntu  Wed May 11 19:16:06 2022
X-Original-To: ubuntu@localhost
To: ubuntu@localhost
From: tester@ubuntu
Auto-Submitted: auto-generated
Subject: *** SECURITY information for ubuntu ***
Date: Wed, 11 May 2022 19:16:06 +0000 (UTC)
ubuntu : May 11 19:16:06 : tester : user NOT in sudoers ; TTY=pts/0 ; PWD=/home/tester ; USER=root ; COMMAND=/usr/bin/crontab -e

同样，我们可以使用替代选项自定义电子邮件触发器，例如当用户使用不正确的密码执行sudo命令时（默认* mail_badpass*）或当sudo用户执行未在sudoers文件条目中列出或明确拒绝的命令时（默认* mail_no_perms*）。