Sudoer-Benutzer mit Root-Rechten aufdecken, die Befehl X ausgeführt haben?

Ich bin der Hauptsystemadministrator eines Systems. Im System gibt es 3 Sudoer-Benutzer mit Root-Rechten.

Das System führt im Hintergrund ein Skript aus, das den Hash der Systemdienstprogramme überprüft, um mögliche böswillige Änderungen zu erkennen. Heute wurde ich benachrichtigt, dass sich der sshHash des Dienstprogramms geändert hat.

Bisher gab es keine Updates, und ich denke, einer der Sudoer ist dafür verantwortlich. Ist es möglich zu erkennen, welcher Sudoer das sshDienstprogramm geändert hat ?

Ich werde eine Antwort mit Blick auf RHEL schreiben, aber ich weiß nur, dass es Analoga für das geben wird, was ich beschreibe, wenn Sie in einer SuSE- oder Debian-basierten Distribution arbeiten.

Wenn Sie nur überprüfen möchten, ob es sich um ein Systemupdate handelt und nicht um jemanden, der versucht, den Computer zu rooten, können Sie das openssh-clientsPaket zunächst wie folgt "überprüfen" :

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

Ich habe es auch getan, openssh-serverdamit Sie sehen können, wie es aussieht, wenn sich etwas ändert. Der wichtige Teil ist die "5", die uns sagt, dass sich die md5sum der Datei von der in der RPM-Datenbank vorhandenen unterscheidet. Wenn das auscheckt, lag es wahrscheinlich an einem Systemupdate.

Wenn sie yum verwendet haben (sehr wahrscheinlich), wird ein /var/log/yum.log-Eintrag für dieses RPM aktualisiert. Dies ist nützlich, um die genaue Zeit abzurufen, zu der das Update für eine spätere Überprüfung durchgeführt wurde yum history.

Wenn sie rpmdirekt verwendet werden, können Sie entweder etwas queryformatzaubern oder rpm -q openssh-clients --lastdas Datum ermitteln, an dem es passiert ist (obwohl es so klingt, als ob Sie diese Informationen bereits kennen).

Es gibt einen yumUnterbefehl namens history, der die auid / loginuid des aufrufenden Benutzers aufzeichnet:

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

Die Loginuid ist nicht fälschbar, da Kinder von init, wenn sie ausgegliedert werden, mit einer Loginuid von -1 (negative) beginnen. Wenn Sie sich über eine tty oder sshdpam_loginuid anmelden (es gibt andere Module, die dies ebenfalls tun), wird diese auf die UID des authentifizierten Benutzers gesetzt. Einmal auf etwas anderes als -1root gesetzt, kann dieser Wert nicht geändert werden (allerdings nur in neueren Kerneln), da er nicht funktionsfähig / nur buchhalterisch ist und berücksichtigen muss, dass ein Angreifer möglicherweise root gewonnen hat. Alle Kinder erben die Loginuid des Elternteils. Obwohl sudoein Programm mit der EUID Null (oder welcher Benutzer auch immer) erstellt wird, haben Sie immer noch dieselbe Loginuid.

Sie können dies testen, indem Sie einfach Ihren Anteil an sudos tun und dies cat /proc/self/loginuidjedes Mal tun , wenn der Benutzer, bei dem Sie sich ursprünglich angemeldet haben, unabhängig davon, wie viele suoder sudoAufrufe Sie seitdem durchgeführt haben. So yum historyweiß jadavis6es dort oben yum update, obwohl ich sie alle als Root-Benutzer gemacht habe.

Wenn zwischen zwei Yum-Transaktionen Unklarheiten bestehen, können Sie eine yum history info <transID>ähnliche Aktion ausführen, wenn ich mehr über diese letzte Transaktion erfahren möchte:

[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

Ich habe es abgeschnitten, weil es so aussieht, als wäre dies ein ziemlich langwieriges Systemupdate.

AFAIK gibt es keine Möglichkeit, es zurückzuverfolgen, wenn sie über rpmdirekt außerhalb der Konfiguration aktualisiert wurden auditd, um Änderungen an den RPM-Datenbankdateien zu überwachen. Wenn Sie dies tun ausearch, können Sie eine Liste der PIDs anzeigen, die Änderungen vorgenommen haben, sowie die zugehörige Loginuid (die als angezeigt wird auid).

Wenn sie es direkt außerhalb von RPM geändert haben, müssen Sie jede der Dateien, die Sie überwachen möchten, auf Änderungen überwachen, bevor die Änderung vorgenommen wird. Im Nachhinein können Sie nicht viel tun, aber Sie könnten überlegen, etwas auditdzu tun , um Dateien zu überwachen, die Sie als Rootkit-Ziele betrachten. Zu viel zu tun kann das System blockieren. Erwähnenswert ist auch, dass Sie diese Protokolle außerhalb des Servers versenden sollten, um böswillige Manipulationen zu verhindern.

Ich hoffe, das hilft.

BEARBEITEN:

Eine Sache zu beachten, es sieht so aus, als ob root die Loginuid ändern kann , wenn dies der Fall ist CAP_SYS_AUDITCONTROL(nicht erforderlich, wenn die Loginuid aktuell ist -1), aber Sie sollten in der Lage sein, diese Funktion aus dem Begrenzungssatz des Systems zu entfernen, wodurch der Angreifer das System neu starten müsste Erhalten Sie diese Fähigkeit, die eine verdammt laute Operation ist, bei der überall überprüfbare Ereignisse zurückbleiben, sodass es unwahrscheinlich ist, dass sie dies tun.

Wenn Sie sich die /var/log/audit/audit.logDatei ansehen , sollten Sie in der Lage sein, die Uhrzeit und das Datum sshanzugeben , an dem die Datei geändert wurde, als sich einer der drei Benutzer mit Sudoers-Berechtigungen angemeldet hat.

Die audit.logDatei enthält folgende Zeilen:

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

Sie können die AUID (Affective User ID - auch bekannt als der Benutzer, der den sudoBefehl ausgeführt hat) zurückverfolgen .

AUID 500 ist also dieser Typ auf meinem System:

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

Jetzt audit.logkann das gepackt werden, aber es ist viel einfacher, das Tool ausearchzum Durchsuchen zu verwenden . Zum einen wird der Zeitstempel des Überwachungsprotokolls in einer besser lesbaren Form gedruckt:

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

Hier suche ich in der Protokolldatei nach Übereinstimmungen, die die ausführbare Datei sudo ( -x /usr/bin/sudo) enthalten.

Hast du nachgesehen syslog? Laut man sudo: sudo kann sowohl erfolgreiche als auch erfolglose Versuche (sowie Fehler) in syslog (3), einer Protokolldatei oder beiden protokollieren. Standardmäßig protokolliert sudo über syslog (3), dies kann jedoch zum Zeitpunkt der Konfiguration oder über die sudoers-Datei geändert werden.

Ich würde denken, wenn sie die Protokolldatei nicht absichtlich gelöscht haben, sollten Sie in der Lage sein, die Informationen dort zu erhalten. Um den Zeitrahmen einzugrenzen, können Sie den geänderten Datumsstempel auf dem SSH-Dienstprogramm überprüfen.