In einigen Umgebungen ist es Pflicht, jede Nutzeraktivität auf einem spezifischen System zu protokollieren. Die meisten dieser Systeme sind zertifiziert, weswegen wir eine Lösung für ein auf RHEL 6 laufendes System suchen. Das System hat keinen gepatchten Kernel und keine nicht-unterstützen Hacks.

Wir haben einige Lösungen untersucht und bewertet. Keine ist wirklich zufriedenstellend.

Das Problem

Das Problem ist schnell umschrieben:

• Ein legitimierter Nutzer loggt sich mit sah oder Konsole in ein System ein und startet eine Shell. Wir wollen dies überwachen und alle Kommandos, die er auf dem System ausführt, protokollieren.
• Für einen unprivilegierten Nutzer sollte es nicht möglich sein, den Auditmechanismus zu umgehen.
• Für einen superuser sollte es schwierig sein, den Auditmechanismus zu umgehen oder ihn zu manipulieren. Oder der superuser sollte zumindest benachrichtigt werden.

Lösungen

Eine Lösungen wie Skripts, Bush Funktionen, Pipes und so weiter können über DuckDuckGo gefunden werden und funktionieren irgendwie. Aber diese Lösungen haben alle ihre Limiten. Speziell die Lösungen, die durch Bash Funktionen oder umgeschriebene PROMPT_s erreicht werden können von _unprivilegierten Nutzern manipuliert oder ausgeschaltet werden.

Nach einigen ersten Tests haben wir uns entschlossen, die folgenden Tools genauer anzusehen:

• auditd
• rootsh
• pam_tty_audit.so
• sudo

auditd

auditd ist die Userspace-Komponente des Linux Auditing Systems. Es ist verantwortlich dafür, dass Audit Records auf eine Festplatte geschrieben werden. Besonders interessant ist hierbei die Option -S, die SYSCALL_s verfolgt, und insbesondere der Syscall EXECVE. Wir haben der auditd.conf zwei Regeln hinzugefügt, die _unprivilegierte Nutzer wie auch privilegierte Nutzer und deren Aktivitäten unterschiedlich taggt. Die auditd Policy:

# logging _bash_ commands
-a exit,always -F arch=b64 -F euid=0 -S execve -k rootact
-a exit,always -F arch=b32 -F euid=0 -S execve -k rootact
-a exit,always -F arch=b64 -F euid>=1000 -S execve -k useract
-a exit,always -F arch=b32 -F euid>=1000 -S execve -k useract

auditd ist nicht wirklich dazu gedacht, Shellaktivität zu überwachen. Es ist sehr verbose loggt schier unendliche Logs voll Details und muss vorsichtig konfiguriert werden, da auditd grossen Einfluss auf die Systemperformance hat.

Das grösste Problem ist, dass die Kommandoparameter auf separaten Linien geloggt werden.

• SYSCALL Linie: Userparameter
• EXECVE Linie: Kommandos und Kommandoparameter

Andererseits können wir die Nutzeraktivität gut überwachen und Standardkomponenten wie aureport dazu nutzen, das Audit Log zu durchsuchen und zu rapportieren. Zum Beispiel wenn ein Nutzer ein Kommando ausführt:

[admin@mos ~]$ ls -lisa

Das _auditd_-Log zeigt:

[root@mos pam.d]# aureport --tty -ts today
...
type=SYSCALL msg=audit(1432238948.640:38103): arch=c000003e syscall=59 success=yes exit=0 a0=1124430 a1=11289c0 a2=112de40 a3=7fffcf153270 items=2 ppid=13513 pid=16214 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts3 ses=19 comm="ls" exe="/bin/ls" subj=unconfined_u:unconfineer:unconfined_t:s0-s0:c0.c1023 key="useract"
type=EXECVE msg=audit(1432238948.640:38103): argc=3 a0="ls" a1="--color=auto" a2="-lisa"
...

 ;

rootsh

rootsh ist ein sogenannter Logging Wrapper für Shells .Es startet eine Shell und loggt Input/Output. Sie können rootsh als alleinstehende Applikation laufen lassen, wenn Sie nur Ihre eigene User Session überwachen wollen. Wenn Sie rootsh mit zusätzlichen Kommandos rufen, dann werden diese an die Shell weitergereicht. Also setzen wir die Shell des unprivilegierten Nutzers auf rootsh in /etc/passwd, damit es für den Nutzer sehr schwer wird, aus rootsh auszubrechen.

Der unprivilegierte Nutzer kann eine sh oder bash starten, aber rootsh wird die Aktivität, den Input und den Output loggen. Das Tool loggt die Aktivitäten sehr gut und ist extrem übersichtlich. Aber es fehlt ein grundlegendes Feature des Auditings: Der Timestamp.

Wir können zwar einen Nutzer und dessen Aktivität genau verfolgen, aber können nur mit Sicherheit sagen, wann er seine Shell Session begonnen hat. Alle Kommandos und Outputs haben keinen relativen Timestamp, daher können wir nicht genau feststellen, wann der Nutzer was getan hat.

Der Logging-Typus ist im Wesentlichen ein Dump des Terminals: Was Sie in Ihrer Shell sehen ist genau das, was im Log festgehalten wird.

pam_tty_audit.so

Eine spezifische Komponente des Auditsystems nutzt das pam_tty_audit.so PAM Modul um Auditing des TTY-Inputs für spezifizierte Nutzer ein- oder auszuschalten. Wenn sich ein Nutzer einloggt, dann werden seine Tastenanschläge genau festgehalten und in der Datei /var/log/audit/audit.log abgelegt.

Das Modul ist Teil des auditd_-Frameworks, daher stellen Sie sicher, dass das aktiviert wird bevor _pam_tty_audit.so konfiguriert wird. Es kann generell aktiviert werden, oder nur für einige Nutzer oder für alle bis auf einige Nutzer, was das Modul recht flexibel macht.

Das Modul loggt Tastenanschläge. Sprich: Wenn Sie DEL oder Backspace drücken, dann wird im audit.log oft , , und so weiter auftauchen. Das ist etwas unbequem, aber gut genug, um Nutzeraktivitäten zu rekonstruieren.

Da dies eine auditd_-Komponente ist, können wir _aureport mit -tty-Parameter, die alle Records aus dem Log des Moduls rapportiert.

Das Logging wird nicht immer in Echtzeit angezeigt: Die Tastenanschläge werden gebuffert wenn der Nutzer eine neue sh öffnet und das Log wird geschrieben, wenn er die sh verlässt.

Anforderungen an das Modul:

[root@mos pam.d]# cat /etc/pam.d/system-auth
...
session	  required   pam_tty_audit.so enable=*
...

Das Resultat in der Logfile:

[root@mos pam.d]# aureport --tty -ts today
...
15. 05/25/2015 16:57:34 106664 1000 ? 51 _bash_ <ret>
16. 05/25/2015 16:57:39 106666 1000 ? 51 _bash_ "su oper",<ret>
20. 05/25/2015 16:58:17 107808 1000 ? 50 _bash_ <up>,<ret>
21. 05/25/2015 16:58:24 107811 1000 ? 51 _bash_ "ls .lisa",<backspace>,<backspace>,<backspace>,<backspace>,<backspace>,<backspace>," -lisa",<ret>,"cd",<ret>,<ret>,<ret>,"find / -name test",<ret>,"exit",<ret>
...

 ;

sudo

sudo erlaubt es einem Benutzer ein Kommando als privilegierter Nutzer oder als anderer User auszuführen, ganz nach Einstellung der Security Policy. Sudo unterstützt das Logging von Kommandoinputs und -outputs. I/O Logging ist nicht standardmässig aktiviert, aber kann mittels LOG_INPUT und LOG_OUTPUT Flags eingeschaltet werden.

Zum Beispiel können wir alle Aktivitäten der Admins und Operators loggen, indem wir folgende Konfiguration verwenden:

...
%admin ALL = (ALL) NOPASSWD: LOG_INPUT: LOG_OUTPUT: ALL
%oper ALL = NOPASSWD: LOG_INPUT: LOG_OUTPUT: SOFTWARE, SERVICES, PROCESSES
...

Das Log wird recht kryptisch aussehen: Für jeden Nutzer wird ein eigenes Verzeichnis erstellt, das mehrere Dateien enthält, die den Input/Output aufzeichnen.

Diese Lösung ist nützlich, um eine Referenz zu haben. Aber seien Sie vorbereitet, Zeit in die Rekonstruktion der Nutzeraktivität zu stecken.

[root@mos ~]# cd /var/log/sudo-io/
[root@mos ~]# find .
.
./00
./00/00
./00/00/02
./00/00/02/timing
./00/00/02/stderr
./00/00/02/log
./00/00/02/ttyin
./00/00/02/ttyout
./00/00/02/stdin
./00/00/02/stdout

Zusammenfassung

Die perfekte Lösung haben wir nicht gefunden. Aber um die Pros und Contras aller hier vorgestellten Lösungen zusammenzufassen:

Jede Lösung hat ihre Stärken und ihre Schwächen. Da auditd und sudo Standards in jedem sicheren System sind, haben wir am Ende diese zwei Tools verwendet und konfiguriert.

Über den Autor

Rocco Gagliardi ist seit den 1980er Jahren im Bereich der Informationstechnologie tätig. In den 1990er Jahren hat er sich ganz der Informationssicherheit verschrieben. Die Schwerpunkte seiner Arbeit liegen im Bereich Security Frameworks, Routing, Firewalling und Log Management.

Links

• http://linux.die.net/man/1/rootsh
• http://linux.die.net/man/8/auditd
• http://linux.die.net/man/8/aureport
• http://linux.die.net/man/8/pam_tty_audit
• http://www.sudo.ws
• https://duckduckgo.com/?q=log+_bash_+commands&ia=qa