Khám phá người dùng sudoer với quyền root đã chạy lệnh X?

Tôi là sysadmin chính của một hệ thống. Trong hệ thống có 3 người dùng sudoers với quyền root.

Hệ thống chạy một tập lệnh ở chế độ nền để kiểm tra hàm băm của các tiện ích của hệ thống để phát hiện các thay đổi độc hại có thể có. Hôm nay tôi được thông báo rằng sshhàm băm của tiện ích đã thay đổi.

Không có bất kỳ cập nhật nào cho đến bây giờ và tôi nghĩ một trong những sudoers chịu trách nhiệm cho việc này. Có thể phát hiện sudoer nào đã thay đổi sshtiện ích không?

Tôi sẽ viết một câu trả lời với RHEL trong đầu nhưng chỉ cần biết rằng nếu bạn đang sử dụng bản phân phối dựa trên SuSE hoặc Debian, sẽ có những điểm tương tự với những gì tôi mô tả.

Trước hết, nếu bạn chỉ muốn xác minh rằng đó là bản cập nhật hệ thống chứ không phải ai đó đang cố root máy, bạn có thể "xác minh" openssh-clientsgói như vậy:

[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]#

Tôi cũng đã làm openssh-servernhư vậy để bạn có thể thấy nó trông như thế nào khi có gì đó thay đổi. Phần quan trọng là "5" cho chúng ta biết rằng md5sum của tệp khác với những gì tồn tại trong cơ sở dữ liệu RPM. Nếu điều đó kiểm tra thì có lẽ là do cập nhật hệ thống.

Nếu họ đã sử dụng yum (rất có thể) sẽ có một mục /var/log/yum.log cho RPM đó được cập nhật. Điều này hữu ích để có được thời gian cụ thể cập nhật xảy ra để xem lại sau này yum history.

Nếu họ sử dụng rpmtrực tiếp, bạn có thể thực hiện một số queryformatphép thuật hoặc rpm -q openssh-clients --lastđể biết ngày xảy ra (mặc dù có vẻ như bạn đã biết chút thông tin đó)

Có một yumtiểu ban được gọi là historyghi lại auid / loginuid của người dùng đang gọi:

[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]#

Thông tin đăng nhập là không thể tha thứ bởi vì trẻ em của init bị loại bỏ, chúng bắt đầu với một loginuid -1 (số âm). Khi bạn đăng nhập thông qua tty hoặc sshdpam_loginuid (có các mô-đun khác cũng thực hiện việc này) sẽ đặt nó thành UID của người dùng được xác thực. Khi đã được đặt thành một cái gì đó khác với -1root thậm chí không thể thay đổi giá trị này (chỉ trong các hạt mới hơn) vì nó không có chức năng / chỉ tính toán và cần phải xem xét rằng kẻ tấn công có thể đã lấy được root. Tất cả trẻ em đều thừa hưởng loginuid của cha mẹ, mặc dù sudosinh ra một chương trình có EUID bằng 0 (hoặc bất kỳ người dùng nào) bạn vẫn sẽ có cùng một loginuid.

Bạn có thể kiểm tra điều này bằng cách chỉ chia sẻ sudo của mình và thực hiện cat /proc/self/loginuidmỗi lần người dùng mà bạn đăng nhập ban đầu, bất kể bạn đã thực hiện bao nhiêu lần suhoặc sudoyêu cầu. Đây là cách mà yum historytrên đó biết jadavis6được yum updatemặc dù tôi đã làm tất cả với tư cách là người dùng root.

Nếu có một sự mơ hồ giữa hai giao dịch yum, bạn có thể thực hiện yum history info <transID>như nếu tôi muốn biết thêm về giao dịch cuối cùng đó:

[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

Tôi đã cắt nó bởi vì có vẻ như đây là một bản cập nhật hệ thống khá dài.

AFAIK không có cách nào để theo dõi lại nếu họ cập nhật rpmtrực tiếp bên ngoài cấu hình auditdđể theo dõi các thay đổi đối với các tệp cơ sở dữ liệu RPM. Làm như vậy sẽ cho phép bạn thực hiện ausearchsẽ cho phép bạn xem danh sách các thay đổi của PID và đăng nhập được liên kết (sẽ được hiển thị dưới dạng auid).

Nếu họ trực tiếp thay đổi nó bên ngoài RPM, bạn sẽ phải xem từng tệp bạn muốn theo dõi để thay đổi trước khi thay đổi được thực hiện. Sau thực tế bạn không thể làm gì nhiều nhưng bạn có thể cân nhắc làm gì đó auditdđể giám sát các tệp mà bạn cảm thấy là mục tiêu rootkit. Làm quá nhiều có thể làm hỏng hệ thống xuống. Điều đáng nói là bạn nên gửi những bản ghi này ra khỏi máy chủ ở đâu đó để ngăn chặn hành vi giả mạo độc hại.

Mong rằng sẽ giúp.

BIÊN TẬP:

Một điều cần lưu ý, có vẻ như root có thể thay đổi loginuid nếu nó có CAP_SYS_AUDITCONTROL(không bắt buộc nếu hiện tại loginuid -1) nhưng bạn có thể xóa khả năng đó khỏi bộ giới hạn của hệ thống, điều này sẽ yêu cầu kẻ tấn công khởi động lại hệ thống đạt được khả năng đó, một hoạt động ồn ào như địa ngục để lại các sự kiện có thể nghe được ở khắp mọi nơi nên họ khó có thể làm điều đó.

Nếu bạn xem qua /var/log/audit/audit.logtệp, bạn sẽ có thể sắp xếp thời gian / ngày mà sshtệp được thay đổi khi một trong 3 người dùng có đặc quyền sudoers đăng nhập.

Các audit.logtập tin có chứa đường như thế này:

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)'

Bạn có thể quay lại AUID (ID người dùng có ảnh hưởng - hay còn gọi là người dùng đã chạy sudolệnh).

Vì vậy, AUID 500 là anh chàng này trong hệ thống của tôi:

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

Bây giờ audit.logcó thể được grepping nhưng sử dụng công cụ ausearchđể quét qua nó dễ dàng hơn nhiều . Đối với một điều, nó sẽ in dấu thời gian của nhật ký kiểm toán ở dạng dễ đọc hơn:

$ 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)'

Ở đây tôi đang tìm kiếm thông qua tệp nhật ký tìm kiếm các kết quả khớp có chứa sudo, ( -x /usr/bin/sudo).

Bạn đã kiểm tra syslogchưa Theo man sudo: sudo có thể ghi nhật ký cả những lần thử thành công và không thành công (cũng như lỗi) vào syslog (3), tệp nhật ký hoặc cả hai. Theo mặc định, sudo sẽ đăng nhập qua syslog (3) nhưng điều này có thể thay đổi theo thời gian cấu hình hoặc thông qua tệp sudoers.

Tôi sẽ nghĩ rằng, trừ khi họ cố tình xóa tệp nhật ký, bạn sẽ có thể lấy thông tin ở đó. Để thu hẹp khung thời gian, bạn có thể kiểm tra tem ngày đã sửa đổi trên SSH sử dụng.