Frage Protokolliere alle Befehle, die von Admins auf Produktionsservern ausgeführt werden


Es ist die Unternehmensrichtlinie für Administratoren, sich über einen persönlichen Benutzernamen bei den Servern anzumelden und anschließend zu starten sudo -i um Wurzel zu werden. Nach dem Laufen sudo -i, sudo erstellt eine Umgebungsvariable namens SUDO_USER, die den Benutzernamen des ursprünglichen Benutzers enthält.

Gibt es eine Möglichkeit zu loggen? ALLES Befehle innerhalb von Syslog mit etwas ähnlich der folgenden Syntax:

${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 (zB root), des sudo-Benutzers (zB. Ksoviero) und des vollständigen Befehls, der ausgeführt wurde (z. B. yum installiere Zufalls-pkg).

Ich habe es schon versucht snoopy, aber es enthielt nicht die SUDO_USER Variable.


61
2018-01-20 04:35


Ursprung


Du brauchst auditd. - Michael Hampton♦
Das ist ein kurze Einleitung zu auditd - Deer Hunter
Könnte jemand bitte dies als Antwort posten? Bitte geben Sie an, wie ich alle von Benutzern ausgeführten Befehle strikt protokollieren würde. Das "kurze Intro zu auditd" war nützlich, aber es enthielt nichts, was mit der Protokollierung von tatsächlichen Befehlen zu tun hatte (soweit ich das beurteilen konnte). - Soviero
Ok, ich habe angefangen mit zu spielen auditd, und während ich es geschafft habe, alle ausgeführten Befehle zu protokollieren, enthält es nicht die SUDO_USER Variable (oder gleichwertige Informationen), und ich kann keinen Weg finden, es einzuschließen. Jede Hilfe würde sehr geschätzt werden! - Soviero
Und was wird die Firma? tun mit dieser Aufzeichnung aller Befehle von Administratoren eingegeben? - ewwhite


Antworten:


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

  • Verwenden auditd Auf diese Weise wird das Protokollvolumen erheblich erhöht, insbesondere wenn das System über die Befehlszeile stark genutzt wird. Passen Sie Ihre Aufbewahrungsrichtlinien für Protokolle an.
  • Auditd Loggen auf dem Host, wo sie erstellt werden, sind genauso sicher wie andere Dateien auf der gleichen Box. Leiten Sie Ihre Protokolle an einen entfernten Protokollauflistungsserver wie ELK oder Graylog weiter, um die Integrität Ihrer Protokolle zu erhalten. Darüber hinaus können ältere Protokolle noch aggressiver gelöscht werden.

Wie es von Michael Hampton vorgeschlagen wurde, auditd ist das richtige Werkzeug für den Job hier.

Ich habe das auf einer Ubuntu 12.10-Installation getestet, so dass Ihre Laufleistung auf anderen Systemen variieren kann.

  • Installieren auditd:

    apt-get install auditd

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

    -a Ausgang, immer -F bogen = b64 -F eud = 0 -S ausführen
    -a Ausgang, immer -F bogen = b32 -F eud = 0 -S ausführen

Diese werden alle von root ausgeführten Befehle verfolgen (euid=0). Warum zwei Regeln? Das execve syscall muss in 32- und 64-Bit-Code nachverfolgt werden.

  • Loswerden auid=4294967295 Nachrichten in Protokollen, hinzufügen audit=1 zur Kernel-Befehlszeile (durch Bearbeiten /etc/default/grub)

  • Platziere die Linie

    session required pam_loginuid.so

in allen PAM-Konfigurationsdateien, die für die Anmeldung relevant sind (/etc/pam.d/{login,kdm,sshd}), aber nicht in den relevanten Dateien su oder sudo. Dies wird erlauben auditd um den Anrufer zu erhalten uid richtig beim Anrufen sudo oder su.

  • Starten Sie Ihr System jetzt neu.

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

    $ id -u
    1000
    $ sudo ls /
    bin intro.img initrd.img.old lib lib32 lib64 verloren + gefunden media mnt opt ​​proc root run sbin scratch selinux srv sys tmp usr var vmlinuz vmlinuz.old
    $ sudo su -
    # ls / etc
    [...]

Dies wird in etwa so etwas ergeben /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)

Das auid Spalte enthält den Namen des anrufenden Benutzers uid, mit der Sie nach Befehlen filtern können, die von diesem Benutzer ausgeführt werden

 ausearch -ua 1000

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

Quellen:


72
2018-02-04 09:16



+50 Diese Antwort scheint die umfassendste zu sein, obwohl ich ein wenig enttäuscht bin, dass sie ziemlich kompliziert geworden ist. Danke für Ihren Beitrag. - grassroot
Seien Sie gewarnt, dass diese Änderungen das Protokollvolumen erheblich in /var/log/audit/audit.log erhöhen können. Mein Protokollvolumen für diese Datei hat sich nach dem Hinzufügen der twoexecve-Zeilen zu audit.rules mehr als verdoppelt - JDS


Denken Sie daran, dass sudo selbst alle sudo-Befehle im syslog protokolliert, sodass alle privizierten Benutzer darauf erzogen werden sollten, nicht einfach sudo zu verwenden, um eine root-Shell zu erhalten, sondern:

sudo command p1 p2 ... pn

Das Problem mit diesem oder jedem Ansatz, an den ich gedacht habe, ist der als root Benutzer ist es ziemlich schwierig zu verhindern, dass ein Benutzer eine bestimmte Art der Protokollierung ausweicht. Also alles was du probierst ist <100% Es tut mir leid zu sagen.

Bildung, Dokumentation, Durchsetzung und vor allem Vertrauen ist notwendig.


8
2018-01-20 06:46



Ich verstehe, dass nichts perfekt sein wird, aber wir werden niemals alle dazu bringen, so zu arbeiten, wie Sie es beschreiben. Das sind Systemadministratoren, von denen wir reden;) - Soviero
Nicht wahr .... zumindest zwei sehr große Unternehmen, mit denen ich persönlich zusammengearbeitet habe, bestehend aus einer großen Anzahl von Systemadministratoren, haben genau diese Richtlinie eingeführt! Mit Bildung und Durchsetzung funktioniert es wieder. - mdpc
MDPC ist 100% richtig. Genau dafür ist der Sudo-Befehl zuständig. Ich bin in einem Laden mit zehn Systemadministratoren mit Hunderten von Hosts und wir verwenden individuelle Sudo-Befehle für alles - es gibt eine spezielle Richtlinie, die verbietet, über su - root zu werden. Dies ist der einzige vernünftige Weg, um sicherzustellen, dass Verwaltungsvorgänge ordnungsgemäß geprüft werden. - Jeff Albert
-1 Bildung wird es nie tun. Wir leben in einer ausgelagerten Welt, in der Sie nur einer der vielen Kunden Ihrer Systemadministratoren sind. - grassroot


Ich war einmal mit dem gleichen Problem konfrontiert und musste mir eine schnelle und schmutzige Lösung einfallen lassen - jeder Sudo-Benutzer wird seine eigene Verlaufsdatei haben, sobald er den Befehl ausgeführt hat sudo -i

Im /root/.bashrc Ich habe die folgende Zeile hinzugefügt -

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

So hat jeder Benutzer, der sudos root hat, eine Verlaufsdatei .bash_history-username.

Eine andere Methode -

Fügen Sie den folgenden Code hinzu /root/.bashrc und es wird den Benutzernamen, den sudo-user und den Befehl an die Protokolldatei anhängen, wo immer die Benachrichtigungsstufe gesetzt 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

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


5
2018-01-31 20:03



Netter Ansatz, obwohl nicht ganz, was gefragt wurde. Ich würde gerne eine auditedd oder ähnliche Lösung sehen. - grassroot
Ok, ich habe es aktualisiert, um auf die Trap-Methode zu vertrauen. - Daniel t.
Und für legitime Benutzer funktioniert das. Aber wenn dieser Account geknackt wurde, konnte der Cracker den Bash-Verlauf schnell deaktivieren, indem er ausgeführt wurde /bin/sh, unset HISTFILE oder /bin/bash --norc. - Stefan Lasiewski


Eine Reihe von Einrichtungen verbietet die Verwendung von auditd tatsächlich, da sie ressourcenintensiv ist und möglicherweise zu Denial-of-Service-Angriffen führen kann.

Eine Lösung besteht darin, die neueste Korn-Shell zu konfigurieren (ksh-93, see http://kornshell.com/ (Details) um alle Befehle, die als root ausgeführt werden, an einem Remote-Syslog-Server zu protokollieren und dann per Richtlinie zu fordern, dass sich Systemadministratoren außer in Notfällen mit persönlichen Konten anmelden und die erweiterte Korn-Shell über sudo ausführen. Die Untersuchung der Protokolle kann erkennen, wenn ein Administrator eine andere Shell aus der genehmigten Shell startet, um ihre Spuren zu decken, und die SA kann dann bei Bedarf erzogen werden.


3
2018-02-06 19:28





Seit Version 2.0.0 schnüffeln kann beliebige Umgebungsvariablen protokollieren.

Jüngster Beitrag wies jedoch darauf hin, dass Logging-Besitzer von tty ist eine ziemlich effektive und elegante Antwort auf die Frage, "Wer hat diesen Befehl ausgeführt, als root?".

Offenlegung: Ich bin Snoopy Maintainer.


3
2017-11-05 23:20



Bitte geben Sie Anweisungen zur Einrichtung gemäß den Anforderungen von OP und nicht nur einen einfachen Link. Vielen Dank. - Andrea Lazzarotto
-1. Dies ist nur ein Plug für Snoopy. Sie haben die Offenlegung verfolgt, aber Sie haben die Frage in Ihrem Post immer noch nicht beantwortet; Sie haben gerade mit Ihrem Projekt verbunden. - Duncan X Simpson


Sudo hat etwas genannt Sudoreplay Wenn aktivierte Sitzungen protokolliert werden und später wieder abgespielt werden können, funktioniert das ähnlich wie das script Befehl, der ein Typoskript der Terminalsitzung erstellt, die später mit dem scriptreplay Befehl.


3
2018-04-21 21:09





Nicht, dass irgendwas mit den anderen Antworten falsch wäre, aber wenn Sie das entscheiden sudoLogging über syslog ist zufriedenstellend, kann ich eine Falte vorschlagen: Loggen Sie es über das Netzwerk zu einem Remote-Audit-Host.

Das geht um das Problem herum: "Jetzt bin ich zur Wurzel geworden, kann ich jede Spur von meinem Fehlverhalten aus den Protokollen entfernen". Sie befinden sich jetzt möglicherweise in der lokalen Box, aber Sie können dieses Protokollpaket nicht vom Netzwerk zurückrufen, und Sie haben (vermutlich) keine Root-Rechte auf dem Remote-Audit-Host.

Ich mache das mit einigen der Netzwerke, die ich seit Jahren führe, und es hat zwei weitere Signalvorteile:

Erstens gibt es einen Platz im Netzwerk, um alle Syslogs zu überprüfen, was eine viel einfachere Korrelation von Vorfällen ermöglicht, und so ist eine zentrale Anlaufstelle für Untersuchungen wie "Wann junobeschwerte sich über den NFS-Server hera reagierte nicht, hat sich sonst noch jemand zur selben Zeit über dasselbe beschwert? Wenn ja, hera ist wahrscheinlich das Problem, mal sehen, was sie protokolliert hat; wenn nicht, junoDie Netzwerkverbindung ist verdächtiger, mal sehen was sonst noch juno zu dieser Zeit eingeloggt. "

Zweitens wird die Syslog-Protokollrotation einfacher: Sie speichern keine Kopien von Protokollen auf lokalen Hosts für mehr als ein paar Tage, aber Sie stellen sicher, dass der Audit-Server viel Speicherplatz auf der Festplatte hat und alle syslogs für mehrere Jahre dort bleiben. Wenn Sie beispielsweise WORM-Medien für forensische Prüfzwecke schreiben möchten, müssen Sie nur ein WORM-Laufwerk kaufen.


1
2018-02-04 09:27