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

71

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 .

Soviero
quelle
13
Du brauchst auditd.
Michael Hampton
1
Dies ist eine kurze Einführung in auditd
Deer Hunter
1
Könnte jemand dies bitte als Antwort posten? Bitte geben Sie an, wie ich alle von Benutzern ausgeführten Befehle streng protokollieren würde. Das "kurze Intro zu auditd" war nützlich, enthielt aber nichts, was mit dem Aufzeichnen von tatsächlichen Befehlen zu tun hatte (soweit ich es überhaupt beurteilen konnte).
Soviero
1
Ok, ich habe angefangen, damit zu spielen auditd, und obwohl ich alle ausgeführten Befehle protokolliert habe, enthält es die SUDO_USERVariable (oder entsprechende Informationen) nicht und ich kann keinen Weg finden, sie einzuschließen. Jede Hilfe wäre sehr dankbar!
Soviero
2
Und was wird das Unternehmen tun mit dieser Aufzeichnung aller von Administratoren eingegebenen Befehlen?
ewwhite

Antworten:

83

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:

fuero
quelle
+50 Diese Antwort scheint die umfassendste zu sein, obwohl ich ein bisschen enttäuscht bin, dass sie ziemlich kompliziert geworden ist. Danke für Ihren Beitrag.
Graswurzel
Beachten Sie, dass diese Änderungen das Protokollvolumen in /var/log/audit/audit.log erheblich erhöhen können. Mein Protokollvolumen in dieser Datei hat sich mehr als verdoppelt, nachdem ich die zwei Zeilen zu audit.rules hinzugefügt habe
JDS
11

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.

mdpc
quelle
3
Ich verstehe, dass nichts perfekt sein wird, aber wir werden niemals alle dazu bringen, so zu arbeiten, wie Sie es beschreiben. Dies sind Sysadmins, über die wir reden;)
Soviero
3
Nicht wahr ... Mindestens zwei sehr große Unternehmen, mit denen ich persönlich zusammengearbeitet habe und die aus einer großen Anzahl von Systemadministratoren bestehen, haben genau diese Richtlinie eingeführt! Auch hier funktioniert es mit Aufklärung und Durchsetzung.
mdpc
2
mdpc ist zu 100% korrekt. Genau dafür ist der Befehl sudo gedacht. Ich bin in einem Geschäft mit zehn Sysadmins mit Hunderten von Hosts und wir verwenden für alles einzelne sudo-Befehle - es gibt eine spezielle Richtlinie, die es verbietet, über su - root zu werden. Dies ist die einzige vernünftige Methode, um sicherzustellen, dass Administrationsvorgänge ordnungsgemäß überwacht werden.
Jeff Albert
4
-1 Bildung wird es niemals schaffen. Wir leben in einer ausgelagerten Welt, in der Sie nur einer der vielen Kunden Ihrer Systemadministratoren sind.
Graswurzel
7

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

Daniel t.
quelle
Nizza Ansatz, obwohl nicht ganz das, was gefragt wurde. Ich würde gerne eine auditd oder ähnliche Lösung sehen.
Graswurzel
ok, ich habe es aktualisiert, um auf Trap-Methode zu verlassen.
Daniel t.
3
Und für legitime Benutzer funktioniert dies. Aber wenn das Konto geknackt wurde, konnte der Cracker schnell Bash Geschichte deaktivieren , indem Sie laufen /bin/sh, unset HISTFILEoder /bin/bash --norc.
Stefan Lasiewski
3

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.

Mike McManus
quelle
3

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 .

Nacht
quelle
2

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.

MadHatter
quelle
2

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.

Bostjan Skufca
quelle
Bitte geben Sie anstelle eines einfachen Links Anweisungen zum Einrichten gemäß den Anforderungen des OP. Vielen Dank.
Andrea Lazzarotto
1
-1. Dies ist nur ein Plug für Snoopy. Sie sind der Offenlegung gefolgt, haben die Frage in Ihrem Beitrag jedoch noch nicht beantwortet. Sie haben gerade mit Ihrem Projekt verlinkt.
Duncan X Simpson