Wie protokolliere ich Befehle in einem "sudo su -"?

Wenn ich:

[user@notebook ~] sudo echo 123456uu
123456uu
[user@notebook ~] 

Dann kann ich das in den Protokollen sehen:

[root@notebook /var/log] grep 123456uu *
auth.log:Jan  9 17:01:51 notebook sudo: user : TTY=pts/3 ; PWD=/home/user ; USER=root ; COMMAND=/bin/echo 123456uu
[root@notebook /var/log] 

aber wenn ich:

[user@notebook ~] sudo su -
[root@notebook ~] echo 1234567zz
1234567zz
[root@notebook ~] 

Ich kann es nicht in den Protokollen sehen:

[root@notebook /var/log] grep 1234567zz *
[root@notebook /var/log] echo $?
1
[root@notebook /var/log] 

Meine Frage: Wie kann ich die Anmeldung für die Befehle im "sudo su -" einschalten?

OS ist ein Ubuntu 12.04, aber die Frage ist im Allgemeinen.

UPDATE 1:

[user@notebook ~] sudo su -
[sudo] password for user: 
[root@notebook ~] echo zizizi
zizizi
[root@notebook ~] cd /var/log
[root@notebook /var/log] grep -iIR 'zizizi' *
[root@notebook /var/log] grep 'COMMAND=/bin/su -' *
auth.log:Jan 10 15:42:42 notebook sudo: user : TTY=pts/1 ; PWD=/home/user ; USER=root ; COMMAND=/bin/su -
[root@notebook /var/log]

Da Sie unter Ubuntu 12.04 arbeiten, sehen Sie sich die E / A-Protokollierungsfunktionen an, die über die Optionen log_inputund aktiviert wurden log_output.

log_input

Wenn festgelegt, sudowird der Befehl in einer Pseudotty ausgeführt und alle Benutzereingaben protokolliert. Wenn die Standardeingabe aufgrund der E / A-Umleitung oder weil der Befehl Teil einer Pipeline ist, nicht mit dem tty des Benutzers verbunden ist, wird diese Eingabe ebenfalls erfasst und in einer separaten Protokolldatei gespeichert.

Die Eingabe wird in dem von der iolog_dirOption angegebenen Verzeichnis ( /var/log/sudo-iostandardmäßig) mit einer eindeutigen Sitzungs-ID protokolliert, die in der normalen Sudo-Protokollzeile enthalten ist und mit einem Präfix versehen ist TSID=. Die iolog_fileOption kann verwendet werden, um das Format der Sitzungs-ID zu steuern.

Beachten Sie, dass Benutzereingaben möglicherweise vertrauliche Informationen wie Kennwörter enthalten (auch wenn diese nicht auf dem Bildschirm angezeigt werden), die unverschlüsselt in der Protokolldatei gespeichert werden. In den meisten Fällen ist nur die Protokollierung der Befehlsausgabe über log_output erforderlich.

log_output

Wenn gesetzt, sudowird der Befehl in einer Pseudotty ausgeführt und die gesamte Ausgabe protokolliert, die an den Bildschirm gesendet wird, ähnlich wie beim Befehl script (1). Wenn die Standardausgabe oder der Standardfehler aufgrund der E / A-Umleitung oder weil der Befehl Teil einer Pipeline ist, nicht mit dem tty des Benutzers verbunden ist, wird diese Ausgabe ebenfalls erfasst und in separaten Protokolldateien gespeichert.

Die Ausgabe wird in dem von der iolog_dirOption angegebenen Verzeichnis ( /var/log/sudo-iostandardmäßig) mit einer eindeutigen Sitzungs-ID protokolliert, die in der normalen Sudo-Protokollzeile enthalten ist und mit dem Präfix versehen ist TSID=. Die iolog_fileOption kann verwendet werden, um das Format der Sitzungs-ID zu steuern.

Ausgabeprotokolle können mit dem Dienstprogramm sudoreplay (8) angezeigt werden, das auch zum Auflisten oder Durchsuchen der verfügbaren Protokolle verwendet werden kann.

UMSETZUNG: Sudo-Version mindestens: 1.7.4p4 erforderlich.

/etc/sudoersÄnderung: Sie müssen lediglich zwei Tags zu allen erforderlichen sudoers-Einträgen hinzufügen (wobei "su" angegeben ist, entweder mit Befehl oder Alias). LOG_INPUT und LOG_OUTPUT.

Beispiel:

%admins         ALL=(ALL) NOPASSWD: LOG_INPUT: LOG_OUTPUT: ALL

Fügen Sie die folgende Standardstruktur für das Protokollverzeichnis hinzu sudoers:

Defaults iolog_dir=/var/log/sudo-io/%{user}

Ihr , grepwenn dabei sudo su -versagt , weil Sie nicht laufen echo 1234567zz, du läufst su -, die startet eine Shell. Die Shell läuft dann deine echo.

Dies ist absichtlich und das Protokollieren jeder einzelnen Befehlsausführung würde Ihr Syslog mit nutzlosen Informationen überfluten (es gibt normalerweise Tonnen von Programmen, die hinter den Kulissen ausgeführt werden, die Sie normalerweise nicht sehen).

Wenn Sie Ihr grep auf ändern, werden grep 'COMMAND=/bin/su -' *Sie es sehen.

sudo su -ist auch eine nutzlose Verwendung von su. sudo -imacht das gleiche.

In zunehmender Komplexität gibt es drei Möglichkeiten, die im "sudo su -" ausgegebenen Befehle zu protokollieren:

1. Verlassen Sie sich auf die Geschichte der Bash-Befehle
2. Installieren Sie einen Wrapper für die Ausführungsprotokollierung
3. Verwenden Sie SELinuxs auditd

Welche Methode geeignet ist, hängt davon ab, was Sie mit der Protokollierung erreichen möchten.

1) Bash-Befehlsverlauf

Sie sollten die Verlaufsfunktion konfigurieren, um sicherzustellen, dass genügend Zeilen vorhanden sind, nicht aus verschiedenen Sitzungen überschrieben, Befehle nicht ignoriert und die entsprechenden Zeitstempel verwendet werden. (Siehe HIST * -Variablen im bash-Handbuch ). Einfaches Umkehren durch Bearbeiten der Verlaufsdatei, Bearbeiten der Umgebung oder Ausführen einer anderen Shell.

2) Wrapper ausführen

Snoopylogger ist einer. Fügen Sie eine Überprüfung hinzu, /etc/profiledass sich die Logger-Bibliothek in der Speicherzuordnung des Prozesses befindet ( /proc/<pid>/maps), und setzen Sie sie gegebenenfalls LD_PRELOADund starten Sie sie neu (mit exec $SHELL --login "$@"). Alternativ können Sie einen Eintrag zu /etc/ld.so.preload mit $LIB/snoopy.sooder gleichwertige Pfade zu Ihren 32/64-Bit-Versionen von snoopy.so hinzufügen.

Obwohl dies schwieriger ist, kann die LD_PRELOADVersion der Umgebungsvariablen von oben immer noch durch Manipulieren der Ausführungsumgebung untergraben werden, sodass der Snoopy-Code nicht mehr ausgeführt wird.

Syslog sollte sofort gesendet werden, damit der Inhalt vertrauenswürdig ist.

3) auditd

Etwas einfacher zu konfigurieren als der Execve-Wrapper, aber schwerer zu extrahieren. Dies ist die Antwort auf die Frage, die Sie wahrscheinlich wirklich stellen: "Gibt es eine Möglichkeit zu protokollieren, welche Auswirkung der Benutzer auf ein System nach dessen Ausgabe hatte? sudo su -". Syslog sollte sofort gesendet werden, damit der Inhalt vertrauenswürdig ist.

Diese Serverfault-Antwort scheint eine ziemlich umfassende Konfiguration zur Verwendung mit auditd zu sein.

Es gibt einige andere Vorschläge zu einer ähnlichen Frage zu Serverfehler .

Warum?

Weil es sudodie Protokollierung ist; Es protokolliert Sudo-Befehle. Im ersten Fall sudo echowird protokolliert. Im zweiten Fall sudo suwird angemeldet (suchen Sie danach in /var/log/auth.log).

suist "Benutzer wechseln", standardmäßig auf root. Alles, was Sie danach tun, geht nicht durch sudo. Es ist ungefähr so, als ob Sie sich als root angemeldet hätten. Die Anmeldung selbst wird protokolliert, aber nicht jeder einzelne Befehl.

Wie andere gesagt haben, sudokann das nicht.

Verwenden Sie stattdessen auditd. Wenn Sie alles protokollieren möchten, was von root erledigt wurde (einschließlich z. B. von crontab), verwenden Sie Folgendes:

sudo auditctl -a exit,always -F euid=0

ETA: Beachten Sie, dass sich die Protokollierung auf die Leistung auswirkt. Sie sollten sie daher möglicherweise etwas einschränken. Siehe man auditctlBeispiele.

Wenn Sie nur Systemaufrufe protokollieren möchten, bei denen die ursprüngliche Anmelde-UID nicht root ist, verwenden Sie stattdessen Folgendes:

sudo auditctl -a exit,always -F euid=0 -F auid!=0

Die Protokolle werden normalerweise in /var/log/audit/audit.log gespeichert. Sie können sie mit suchen ausearch.

Es stehen weitere Informationen in den Manpages auditctl, audit.rulesund ausearch.

sudo su -wird in sein, ~/.bash_historywenn Ihre Muschel bash ist.

echo 1234567zzwird in sein, /root/.bash_historywenn Roots Shell bash ist.

Eine Erklärung dazu wurde bereits von Goldlöckchen gepostet.

Möchten Sie, dass sich su anmeldet, weil Sie der Meinung sind, dass es sich um eine Sicherheitslücke handelt? Haben Sie über diesen Befehl nachgedacht? sudo bashgenauso schlimm imho.

Wenn Sie sich Sorgen machen, was die Benutzer mit sudo machen können, müssen Sie die Verwendung einschränken. Sie können die Befehle einschränken, die sie auch ausführen können. Beschränken Sie den Zugriff auf / bin / su, wenn Sie sich Sorgen machen.

Was ist damit:

export HISTTIMEFORMAT="%d/%m/%y %T "
export PROMPT_COMMAND='builtin history 1 >> /var/log/sudo.log'
sudo -E su
unset PROMPT_COMMAND

oder

export HISTTIMEFORMAT="%d/%m/%y %T "
export PROMPT_COMMAND='builtin history 1 >> /var/log/sudo.log' 
sudo -E su --preserve-environment -
unset PROMPT_COMMAND

oder langer Einzeiler:

HISTTIMEFORMAT="%d/%m/%y %T " PROMPT_COMMAND='builtin history 1 >> /var/log/sudo.log' sudo -E su

sudo -E erhält die Umgebung aufrecht PROMPT_COMMAND wird vor jeder Eingabeaufforderung ausgeführt

Wenn dies hilft, können Sie die "NOEXEC" -Option von Sudoern verwenden.

Sie müssen es als definieren

USER_NAME         ALL=(ALL) NOEXEC : ALL

Dadurch werden Shell-Escapes verhindert und der Benutzer kann sudo -i oder sudo -s oder sudo su - nicht verwenden.

Dies hat jedoch den Nachteil, dass die Shell-Escape-Funktion deaktiviert wird. Auch das Ausführen von Skripten aus einem Skript heraus wird verweigert.

Machen wir das nicht kompliziert: Immer wenn sudoes aufgerufen wird, meldet es dies in einer Datei /var/log(auf Ihrem System ist es auth.log, auf meiner OS X-Box system.log). sudomeldet seine Kommandozeilenargumente, hat aber keine Ahnung, was in einem interaktiven Befehl wie passieren könntesu .

Dies bedeutet nicht, dass es keine Aufzeichnung darüber gibt, was in einer Root-Subshell passiert: Shell-Befehle werden im Verlauf der Shell gespeichert. Auf meinem System ist die Speicherung des Root-Verlaufs standardmäßig aktiviert. Ich muss also nur nach ~root/.sh_historyeiner Aufzeichnung suchen, was getan wurde (es sei denn, jemand hat daran manipuliert, aber er könnte genauso gut daran manipulieren /var/log).

Ich denke, das ist die beste Lösung für Sie. Wenn nicht, fahren Sie mit in die Stadt auditd, wie @Jenny vorgeschlagen hat.

PS. Wenn der Verlauf von root noch nicht aktiviert ist, hängt die Aktivierung davon ab, welche Shell verwendet wird. Für bash, setze HISTORYund HISTFILESIZEauf eine ausreichend große Zahl (Standard ist 500, mein Handbuch sagt). Wenn Sie möchten, können Sie angeben, wo der Verlauf gespeichert werden soll, indem Sie HISTFILEeinen Pfad festlegen (Standard $HOME/.sh_history).

Möglicherweise möchten Sie ein Typoskript Ihrer Sitzung erstellen, indem Sie Folgendes verwenden script(1):

$ sudo su -
# script -t /tmp/my_typescript 2> /tmp/my_typescript.timing
Script started, file is /tmp/my_typescript
# echo foobar
foobar
# echo hello world
hello world
# exit
exit
Script done, file is /tmp/my_typescript

Jetzt können Sie grep(beachten Sie, dass die #Eingabeaufforderungen tatsächlich in aufgezeichnet sind /tmp/my_typescript):

$ grep echo /tmp/my_typescript
# echo foobar
# echo hello world

Alternativ können Sie die ganze Sitzung auch noch einmal ansehen mit scriptreplay(1):

$ scriptreplay -t /tmp/my_typescript.timing /tmp/my_typescript

Die Datei /tmp/my_typescript.timingenthält Informationen, wenn jeder Befehl aufgerufen wurde. Es gibt weitere Tools wie ttyrecoder shelr, die noch mehr Schnickschnack haben.