☰

发现运行命令 X 的具有 root 权限的 sudoer 用户？

tag-icon • tag-icon security sudo logs audit
发现运行命令 X 的具有 root 权限的 sudoer 用户？

我是系统的主要系统管理员。系统中有3个具有root权限的sudoers用户。

系统在后台运行一个脚本，该脚本检查系统实用程序的哈希值以检测可能的恶意更改。今天我收到警报，该ssh实用程序的哈希值发生了变化。

到目前为止还没有任何更新，我认为其中一位 sudoers 对此负责。是否可以检测哪个 sudoer 更改了ssh实用程序？

答案1

我将用 RHEL 来写一个答案，但要知道，如果您使用的是基于 SuSE 或 Debian 的发行版，那么将会有与我所描述的类似的内容。

首先，如果您只想验证它是否是系统更新，而不是有人试图对计算机进行 rootkit，您可以openssh-clients像这样“验证”该软件包：

[root@hypervisor scsd]# rpm -V openssh-clients
[root@hypervisor scsd]#
[root@hypervisor scsd]# rpm -V openssh-server
S.5....T.  c /etc/pam.d/sshd
S.5....T.  c /etc/ssh/sshd_config
[root@hypervisor scsd]#

我openssh-server也这样做了，这样你就可以看到事情发生变化时的样子。重要的部分是“5”，它告诉我们该文件的 md5sum 与 RPM 数据库中存在的不同。如果检查出来的话，可能是由于系统更新所致。

如果他们使用 yum（很可能），将会有一个正在更新的 RPM 的 /var/log/yum.log 条目。这对于获取更新发生的具体时间以供以后查看非常有用yum history。

如果他们rpm直接使用，你可以做一些queryformat魔术或rpm -q openssh-clients --last获取它发生的日期（尽管听起来你已经知道了这一点信息）

有一个yum名为 的子命令history记录调用用户的 auid/loginuid：

[root@hypervisor scsd]# yum history
Loaded plugins: product-id, refresh-packagekit, rhnplugin, security, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
This system is receiving updates from RHN Classic or RHN Satellite.
ID     | Login user               | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
    54 |  <jadavis6>              | 2013-07-15 09:03 | Install        |    2
    53 |  <jadavis6>              | 2013-07-09 17:25 | Update         |   23
    52 |  <jadavis6>              | 2013-06-24 10:10 | Install        |    3  <
    51 |  <jadavis6>              | 2013-06-14 22:33 | Install        |    1 >
    50 |  <jadavis6>              | 2013-06-14 07:47 | E, I, U        |   90
    49 | root <root>              | 2013-06-14 00:58 | Update         |    1
    48 |  <jadavis6>              | 2013-06-03 08:28 | Install        |    3
    47 |  <jadavis6>              | 2013-05-28 11:57 | Install        |    3  <
    46 |  <jadavis6>              | 2013-05-20 18:25 | Install        |    1 >
    45 |  <jadavis6>              | 2013-05-20 12:00 | Install        |    1
    44 |  <jadavis6>              | 2013-05-19 15:29 | Install        |    6
    43 |  <jadavis6>              | 2013-05-18 20:16 | Install        |    3
    42 |  <jadavis6>              | 2013-05-16 16:21 | Install        |    2  <
    41 |  <jadavis6>              | 2013-05-16 12:48 | Install        |    1 >
    40 |  <jadavis6>              | 2013-05-10 09:28 | Install        |    1
    39 |  <jadavis6>              | 2013-05-10 09:28 | Install        |    1
    38 |  <jadavis6>              | 2013-04-29 19:45 | Install        |    2  <
    37 |  <jadavis6>              | 2013-04-29 18:51 | Install        |    8 >
    36 |  <jadavis6>              | 2013-04-29 18:35 | Update         |   11
    35 |  <jadavis6>              | 2013-04-27 15:44 | E, I, O, U     |  429 EE
history list
[root@hypervisor scsd]#

loginuid 是不可伪造的，因为当 init 的子进程被剥离时，它们以 -1（负数）的 loginuid 开始。当您通过 tty 或sshdpam_loginuid（还有其他模块也执行此操作）登录时，将其设置为经过身份验证的用户的 UID。一旦设置为-1除 root 以外的其他值，则无法更改此值（不过，仅在较新的内核中），因为它仅具有非功能性/会计功能，并且需要考虑到攻击者可能已获得 root 权限。所有子进程都会继承父进程的loginuid，因此即使sudo生成一个EUID 为零（或任何用户）的程序，您仍然会拥有相同的loginuid。

您可以通过执行您的 sudo 操作来测试这一点，并且cat /proc/self/loginuid每次您最初登录的用户都应该执行 a 操作，无论此后您执行了多少次调用su。sudo这就是yum history上面知道的jadavis6方式，yum update即使我以 root 用户身份完成了所有这些操作。

如果两个 yum 事务之间存在一些歧义，yum history info <transID>如果我想了解有关最后一个事务的更多信息，您可以这样做：

[root@hypervisor scsd]# yum history info 35
Loaded plugins: product-id, refresh-packagekit, rhnplugin, security,
              : subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
This system is receiving updates from RHN Classic or RHN Satellite.
Transaction ID : 35
Begin time     : Sat Apr 27 15:44:57 2013
Begin rpmdb    : 959:3d300ae2e8dc239f9f972306ba2406bd22ba29bc
End time       :            15:50:39 2013 (5 minutes)
End rpmdb      : 972:381cb76592ea2f779ee4521a4e7221196520486a
User           :  <jadavis6>
Return-Code    : Success
Command Line   : update -y
Transaction performed with:
    Updated       rpm-4.8.0-27.el6.x86_64                       @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
    Updated       subscription-manager-0.99.19.4-1.el6_3.x86_64 @rhel-x86_64-server-6
    Updated       yum-3.2.29-30.el6.noarch                      @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
    Installed     yum-metadata-parser-1.1.2-16.el6.x86_64       @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
Packages Altered:
    Updated     NetworkManager-glib-1:0.8.1-34.el6_3.x86_64                    @rhel-x86_64-server-6
    Update                          1:0.8.1-43.el6.x86_64                      @rhel-x86_64-server-6
    Updated     PackageKit-0.5.8-20.el6.x86_64                                 @rhel-x86_64-server-6
    Update                 0.5.8-21.el6.x86_64                                 @rhel-x86_64-server-6
    Updated     PackageKit-device-rebind-0.5.8-20.el6.x86_64                   @rhel-x86_64-server-6

[...snip...]

    Updated     yum-3.2.29-30.el6.noarch                                       @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
    Update          3.2.29-40.el6.noarch                                       @rhel-x86_64-server-6
    Updated     yum-rhn-plugin-0.9.1-40.el6.noarch                             @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
    Update                     0.9.1-43.el6.noarch                             @rhel-x86_64-server-6
Scriptlet output:
   1 warning: /etc/shadow created as /etc/shadow.rpmnew
   2 No input from event server.
   3 warning: %postun(wdaemon-0.17-2.el6.x86_64) scriptlet failed, exit status 1
history info

我截断了它，因为看起来这是一个相当冗长的系统更新。

rpmAFAIK 如果它们通过直接在配置之外进行更新auditd来监控 RPM 数据库文件的更改，则无法追溯。这样做可以让ausearch您看到进行更改的 PID 列表以及关联的登录 ID（将显示为auid）。

如果他们直接在 RPM 之外对其进行更改，则您必须在进行更改之前监视要监视的每个文件的更改。事实上，您无能为力，但您可以考虑做一些事情来auditd监视您认为是 Rootkit 目标的文件。做得太多可能会使系统陷入困境。还值得一提的是，您应该将这些日志从服务器发送到某个地方，以防止恶意篡改。

希望有帮助。

编辑：

需要注意的一件事是，它看起来像 root能如果有的话，更改loginuid CAP_SYS_AUDITCONTROL（如果loginuid当前是则不需要-1），但是您应该能够从系统的边界集中删除该功能，这将需要攻击者重新启动系统才能获得该功能，这是一个吵闹的地狱操作会将可审计事件留在各处，因此他们不太可能这样做。

答案2

如果您查看该/var/log/audit/audit.log文件，您应该能够将ssh文件更改的时间/日期与 3 个具有 sudoers 权限的用户之一登录时的时间/日期对齐。

该audit.log文件包含如下行：

type=USER_START msg=audit(1374006520.730:480): user pid=28303 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: session open acct="root" : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=/dev/pts/7 res=success)'
type=CRED_ACQ msg=audit(1374006535.446:488): user pid=28352 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: setcred acct="root" : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=/dev/pts/7 res=success)'
type=USER_START msg=audit(1374006535.448:489): user pid=28352 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: session open acct="root" : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=/dev/pts/7 res=success)'

您可以回溯 AUID（情感用户 ID - 又名运行sudo命令的用户）。

所以 AUID 500 就是我系统上的这个家伙：

$ grep 500 /etc/passwd
sam:x:500:500:Sam M.:/home/sam:/bin/bash

现在audit.log可以 grep 了，但是使用该工具ausearch扫描它要容易得多。一方面，它将以更易于阅读的形式打印审核日志的时间戳：

$ ausearch -x /usr/bin/sudo
...
time->Thu Jul 18 14:41:48 2013
type=CRED_ACQ msg=audit(1374172908.936:45): user pid=21252 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: setcred acct="root" : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=/dev/pts/5 res=success)'
----
time->Thu Jul 18 14:41:48 2013
type=USER_START msg=audit(1374172908.937:46): user pid=21252 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: session open acct="root" : exe="/usr/bin/sudo" (hostname=?, addr=?, terminal=/dev/pts/5 res=success)'

在这里，我正在搜索日志文件，查找包含可执行文件 sudo ( -x /usr/bin/sudo) 的匹配项。

答案3

你检查了吗syslog？根据man sudo： sudo 可以将成功和不成功的尝试（以及错误）记录到 syslog(3)、日志文件或两者。默认情况下，sudo 将通过 syslog(3) 进行记录，但这可以在配置时或通过 sudoers 文件进行更改。

我认为，除非他们故意删除日志文件，否则您应该能够在那里获取信息。要缩小时间范围，您可以检查 SSH 实用程序上的修改日期戳。

相关内容