Protokollieren Sie alle Befehle, die von Administratoren auf Produktionsservern ausgeführt werden

Es ist eine Unternehmensrichtlinie für Administratoren, sich über einen persönlichen Benutzernamen bei den Servern anzumelden und dann sudo -izu root zu werden. Beim Ausführen erstellt sudo -isudo eine Umgebungsvariable namens SUDO_USER, die den Benutzernamen des ursprünglichen Benutzers enthält.

Gibt es eine Möglichkeit, ALLE Befehle in syslog mit der folgenden Syntax zu protokollieren :

${TIME/DATE STAMP}: [${REAL_USER}|${SUDO_USER}]: ${CMD}

Ein Beispieleintrag wäre:

Sat Jan 19 22:28:46 CST 2013: [root|ksoviero]: yum install random-pkg

Offensichtlich muss es nicht genau die obige Syntax sein, es muss nur ein Minimum des realen Benutzers (z. B. root), des sudo-Benutzers (z. B. ksoviero) und des vollständigen ausgeführten Befehls (z. B. yum) enthalten installiere random-pkg).

Ich habe es bereits versucht snoopy, aber die SUDO_USERVariable war nicht enthalten .

Update : 2 weitere Dinge, die in den Kommentaren und in den Folgefragen aufgetaucht sind:

• Auf auditddiese Weise wird das Protokollvolumen erheblich erhöht, insbesondere wenn das System über die Befehlszeile stark ausgelastet ist. Passen Sie Ihre Protokollaufbewahrungsrichtlinie an.
• AuditdProtokolle auf dem Host, auf dem sie erstellt wurden, sind genauso sicher wie andere Dateien auf derselben Box. Leiten Sie Ihre Protokolle an einen Remote-Protokollsammlungsserver wie ELK oder Graylog weiter, um die Integrität Ihrer Protokolle zu gewährleisten. Zusätzlich zu dem obigen Punkt können alte Protokolle aggressiver gelöscht werden.

Wie von Michael Hampton vorgeschlagen, auditdist hier das richtige Werkzeug für den Job.

Ich habe dies auf einer Ubuntu 12.10-Installation getestet, sodass Ihre Laufleistung auf anderen Systemen variieren kann.

• Installieren Sie auditd:

  apt-get install auditd

• Fügen Sie diese 2 Zeilen hinzu zu /etc/audit/audit.rules:

  -a exit, immer -F arch = b64 -F euid = 0 -S execve
  -a exit, immer -F arch = b32 -F euid = 0 -S execve

Diese verfolgen alle Befehle, die von root ( euid=0) ausgeführt werden. Warum zwei Regeln? Der execveSyscall muss sowohl im 32- als auch im 64-Bit-Code verfolgt werden.

• Um auid=4294967295Nachrichten in Protokollen loszuwerden , fügen Sie audit=1die Cmdline des Kernels hinzu (durch Bearbeiten /etc/default/grub).

• Legen Sie die Linie

  session required pam_loginuid.so

in allen PAM-Konfigurationsdateien, die für login ( /etc/pam.d/{login,kdm,sshd}) relevant sind , aber nicht in den Dateien, die für suoder relevant sind sudo. Auf diese auditdWeise können Sie den anrufenden Benutzer uidbeim Anrufen von sudooder korrekt ermitteln su.

• Starten Sie Ihr System jetzt neu.

• Lassen Sie uns einloggen und einige Befehle ausführen:

    $ id -u
    1000
    $ sudo ls /
    bin boot data dev etc home initrd.img initrd.img.old lib lib32 lib64 lost + found media
    $ sudo su -
    # ls / etc
    [...]

Dies wird in etwa so aussehen /var/log/audit/auditd.log:

----
time->Mon Feb  4 09:57:06 2013
type=PATH msg=audit(1359968226.239:576): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968226.239:576): item=0 name="/bin/ls" inode=2117 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968226.239:576):  cwd="/home/user"
type=EXECVE msg=audit(1359968226.239:576): argc=2 a0="ls" a1="/"
type=SYSCALL msg=audit(1359968226.239:576): arch=c000003e syscall=59 success=yes exit=0 a0=10cfc48 a1=10d07c8 a2=10d5750 a3=7fff2eb2d1f0 items=2 ppid=26569 pid=26570 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ls" exe="/bin/ls" key=(null)
----
time->Mon Feb  4 09:57:06 2013
type=PATH msg=audit(1359968226.231:575): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968226.231:575): item=0 name="/usr/bin/sudo" inode=530900 dev=08:01 mode=0104755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968226.231:575):  cwd="/home/user"
type=BPRM_FCAPS msg=audit(1359968226.231:575): fver=0 fp=0000000000000000 fi=0000000000000000 fe=0 old_pp=0000000000000000 old_pi=0000000000000000 old_pe=0000000000000000 new_pp=ffffffffffffffff new_pi=0000000000000000 new_pe=ffffffffffffffff
type=EXECVE msg=audit(1359968226.231:575): argc=3 a0="sudo" a1="ls" a2="/"
type=SYSCALL msg=audit(1359968226.231:575): arch=c000003e syscall=59 success=yes exit=0 a0=7fff327ecab0 a1=7fd330e1b958 a2=17cc8d0 a3=7fff327ec670 items=2 ppid=3933 pid=26569 auid=1000 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="sudo" exe="/usr/bin/sudo" key=(null)
----
time->Mon Feb  4 09:57:09 2013
type=PATH msg=audit(1359968229.523:578): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968229.523:578): item=0 name="/bin/su" inode=44 dev=08:01 mode=0104755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968229.523:578):  cwd="/home/user"
type=EXECVE msg=audit(1359968229.523:578): argc=2 a0="su" a1="-"
type=SYSCALL msg=audit(1359968229.523:578): arch=c000003e syscall=59 success=yes exit=0 a0=1ceec48 a1=1cef7c8 a2=1cf4750 a3=7fff083bd920 items=2 ppid=26611 pid=26612 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="su" exe="/bin/su" key=(null)
----
time->Mon Feb  4 09:57:09 2013
type=PATH msg=audit(1359968229.519:577): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968229.519:577): item=0 name="/usr/bin/sudo" inode=530900 dev=08:01 mode=0104755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968229.519:577):  cwd="/home/user"
type=BPRM_FCAPS msg=audit(1359968229.519:577): fver=0 fp=0000000000000000 fi=0000000000000000 fe=0 old_pp=0000000000000000 old_pi=0000000000000000 old_pe=0000000000000000 new_pp=ffffffffffffffff new_pi=0000000000000000 new_pe=ffffffffffffffff
type=EXECVE msg=audit(1359968229.519:577): argc=3 a0="sudo" a1="su" a2="-"
type=SYSCALL msg=audit(1359968229.519:577): arch=c000003e syscall=59 success=yes exit=0 a0=7fff327ecab0 a1=7fd330e1b958 a2=17cc8d0 a3=7fff327ec670 items=2 ppid=3933 pid=26611 auid=1000 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="sudo" exe="/usr/bin/sudo" key=(null)
----
time->Mon Feb  4 09:57:09 2013
type=PATH msg=audit(1359968229.543:585): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968229.543:585): item=0 name="/bin/bash" inode=6941 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968229.543:585):  cwd="/root"
type=EXECVE msg=audit(1359968229.543:585): argc=1 a0="-su"
type=SYSCALL msg=audit(1359968229.543:585): arch=c000003e syscall=59 success=yes exit=0 a0=13695a0 a1=7fffce08a3e0 a2=135a030 a3=7fffce08c200 items=2 ppid=26612 pid=26622 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="bash" exe="/bin/bash" key=(null)
----
time->Mon Feb  4 09:57:11 2013
type=PATH msg=audit(1359968231.663:594): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968231.663:594): item=0 name="/bin/ls" inode=2117 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968231.663:594):  cwd="/root"
type=EXECVE msg=audit(1359968231.663:594): argc=3 a0="ls" a1="--color=auto" a2="/etc"
type=SYSCALL msg=audit(1359968231.663:594): arch=c000003e syscall=59 success=yes exit=0 a0=7fff8c709950 a1=7f91a12149d8 a2=1194c50 a3=7fff8c709510 items=2 ppid=26622 pid=26661 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ls" exe="/bin/ls" key=(null)

Die auidSpalte enthält den aufrufenden Benutzer uid, mit dem Sie nach Befehlen filtern können, die dieser Benutzer ausführt

 ausearch -ua 1000

Dies listet sogar Befehle auf, die der Benutzer als root ausgeführt hat.

Quellen:

• http://www.woitasen.com.ar/2011/11/auditing-user-actions-after-sudo/
• http://linux.die.net/man/8/pam_loginuid
• http://linux.die.net/man/8/auditd

Denken Sie daran, dass sudo selbst alle sudo-Befehle im syslog protokolliert. Daher sollten alle Benutzer mit Privilegien dazu angehalten werden, nicht nur sudo zu verwenden, um eine Root-Shell zu erhalten, sondern:

sudo command p1 p2 ... pn

Das Problem bei diesem oder einem anderen Ansatz, an den ich gedacht habe, ist, dass es als rootBenutzer ziemlich schwierig ist, einen Benutzer daran zu hindern, sich einer bestimmten Art der Protokollierung zu entziehen. Daher ist alles, was Sie versuchen, <100%. Es tut mir leid, das zu sagen.

Aufklärung, Dokumentation, Durchsetzung und vor allem Vertrauen ist gefragt.

Ich war einmal mit dem gleichen Problem konfrontiert und musste eine schnelle und schmutzige Lösung finden - jeder sudo-Benutzer hat seine eigene Verlaufsdatei, sobald er den Befehl ausführt sudo -i

In /root/.bashrcder folgenden Zeile habe ich hinzugefügt -

 export HISTFILE=/root/.bash_history-$SUDO_USER
 export HISTTIMEFORMAT="%F %T "

Jeder Benutzer, der sich als root-Benutzer ausgibt, hat eine Verlaufsdatei .bash_history-username.

Eine andere Methode -

Fügen Sie den folgenden Code hinzu, /root/.bashrcund der Benutzername, der Sudo-Benutzer und der Befehl werden an die Protokolldatei angehängt, wo immer die Benachrichtigungsebene festgelegt ist, höchstwahrscheinlich / var / log / messages.

function log2syslog
{
   declare COMMAND
   COMMAND=$(fc -ln -0)
   logger -p local1.notice -t bash -i -- "${USER}:${SUDO_USER}:${COMMAND}"
}
trap log2syslog DEBUG

Gutschrift an - http://backdrift.org/logging-bash-history-to-syslog-using-traps

Eine Reihe von Einrichtungen untersagt die Verwendung von auditd, da es ressourcenintensiv ist und die Möglichkeit von Denial-of-Service-Angriffen besteht.

Eine Lösung besteht darin, die neueste Korn-Shell (ksh-93, siehe http://kornshell.com/ für Details) so zu konfigurieren, dass alle als Root ausgeführten Befehle auf einem Remote-Syslog-Server protokolliert werden und diese dann, außer im Notfall, nach Richtlinien erforderlich sind In bestimmten Situationen melden sich Sysadmins mit persönlichen Konten an und führen die erweiterte Korn-Shell über sudo aus. Durch die Prüfung der Protokolle kann festgestellt werden, wann ein Administrator eine andere Shell von der genehmigten Shell aus startet, um deren Spuren zu verwischen, und die SA kann dann nach Bedarf geschult werden.

Sudo hat etwas, das als Sudoreplay bezeichnet wird, wenn aktivierte Sitzungen protokolliert werden und später wiedergegeben werden können. Es funktioniert ähnlich wie der scriptBefehl, mit dem ein Typoskript einer Terminalsitzung erstellt wird, das später mit dem scriptreplayBefehl wiedergegeben werden kann .

Nicht, dass mit den anderen Antworten etwas nicht stimmt, aber wenn Sie der Meinung sind, dass sudodie Protokollierung über syslogzufriedenstellend ist, kann ich einen Fehler vorschlagen: Protokollieren Sie ihn über das Netzwerk auf einem Remote-Überwachungshost.

Dies umgeht das Problem: "Jetzt, wo ich root geworden bin, kann ich jede Spur meines Fehlverhaltens aus den Protokollen entfernen." Möglicherweise sind Sie jetzt in der lokalen Box als Root angemeldet, können dieses Protokollpaket jedoch nicht vom Netzwerk zurückrufen und verfügen (vermutlich) nicht über Root-Berechtigungen auf dem Remote-Überwachungshost.

Ich mache dies mit einigen der Netzwerke, die ich seit Jahren verwalte, und es hat zwei weitere Signalvorteile:

Erstens gibt es einen Ort im Netzwerk, an dem alle Syslogs überprüft werden können, was die Korrelation von Vorfällen erheblich vereinfacht. Dies ist auch eine zentrale Anlaufstelle für Untersuchungen wie "Wann hat junosich der NFS-Server beschwert, heranicht geantwortet? Hat sich jemand beschwert?" das Gleiche zur gleichen Zeit? Wenn ja, heraist es wahrscheinlich das Problem, mal sehen, was sie protokolliert hat; wenn nicht, ist junodie Netzwerkverbindung verdächtiger, mal sehen, was junozu dieser Zeit noch protokolliert wurde. "

Zweitens wird die Syslog-Protokollrotation einfacher: Sie bewahren Kopien von Protokollen nicht länger als einige Tage auf lokalen Hosts auf, stellen jedoch sicher, dass der Überwachungsserver über sehr viel Speicherplatz verfügt, und lassen alle Syslogs mehrere Jahre dort. Wenn Sie sie beispielsweise für forensische Überprüfungszwecke auf WORM-Medien schreiben möchten, müssen Sie nur ein WORM-Laufwerk kaufen.

Seit Version 2.0.0 kann snoopy beliebige Umgebungsvariablen protokollieren.

In einem kürzlich veröffentlichten Beitrag wurde jedoch darauf hingewiesen, dass der Holzeigentümer von tty eine ziemlich effektive und elegante Antwort auf die Frage "Wer hat diesen Befehl als Root ausgeführt?" Ist.

Offenlegung: Ich bin snoopy Betreuer.