Registra tutti i comandi eseguiti dagli amministratori sui server di produzione


71

È politica aziendale per gli amministratori accedere ai server tramite un nome utente personale e quindi eseguire sudo -iper diventare root. Durante l'esecuzione sudo -i, sudo creerà una variabile ambientale denominata SUDO_USER, che contiene il nome utente dell'utente originale.

C'è un modo per registrare TUTTI i comandi all'interno di syslog con qualcosa di simile alla seguente sintassi:

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

Una voce di esempio sarebbe:

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

Ovviamente non deve essere esattamente la sintassi di cui sopra, deve solo includere un minimo dell'utente reale (ad es. Root), l'utente sudo (ad es. Ksoviero) e il comando completo che è stato eseguito (ad es. Yum installa random-pkg).

Ho già provato snoopy, ma non includeva la SUDO_USERvariabile.


13
Hai bisogno auditd.
Michael Hampton


1
Qualcuno potrebbe pubblicare questo come una risposta? Per favore, includi come registro rigorosamente tutti i comandi eseguiti dagli utenti. La "breve introduzione a auditd" è stata utile, ma non includeva nulla relativo alla registrazione dei comandi effettivi (per quanto ne sapessi dire comunque).
Soviero,

1
Ok, ho iniziato a giocare auditde, anche se l'ho ottenuto per registrare tutti i comandi in esecuzione, non include la SUDO_USERvariabile (o informazioni equivalenti) e non riesco a trovare un modo per includerla. Qualsiasi aiuto sarebbe molto apprezzato!
Soviero,

2
E quale sarà l'azienda che fare con questo disco di tutti i comandi inseriti dagli amministratori?
ewwhite,

Risposte:


83

Aggiornamento : altre 2 cose che sono spuntate nei commenti e nelle domande di follow-up:

  • L'utilizzo in auditdquesto modo aumenterà notevolmente il volume del registro, soprattutto se il sistema è ampiamente utilizzato dalla riga di comando. Modifica i criteri di conservazione del registro.
  • Auditdi log sull'host in cui sono stati creati sono altrettanto sicuri degli altri file nella stessa casella. Inoltra i registri a un server di raccolta registri remoto come ELK o Graylog per preservare l'integrità dei registri. Inoltre, aggiungendo al punto sopra, consente di eliminare in modo più aggressivo i vecchi registri.

Come suggerito da Michael Hampton, auditdè lo strumento giusto per il lavoro qui.

Ho provato questo su un'installazione di Ubuntu 12.10, quindi il tuo chilometraggio può variare su altri sistemi.

  • Installa auditd:

    apt-get install auditd

  • Aggiungi queste 2 righe a /etc/audit/audit.rules:

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

Questi seguiranno tutti i comandi eseguiti da root ( euid=0). Perché due regole? Il execvesyscall deve essere tracciato sia in codice a 32 che a 64 bit.

  • Per sbarazzarsi dei auid=4294967295messaggi nei registri, aggiungere audit=1al cmdline del kernel (modificando /etc/default/grub)

  • Posiziona la linea

    session required pam_loginuid.so

in tutti i file di configurazione PAM rilevanti per login ( /etc/pam.d/{login,kdm,sshd}), ma non nei file rilevanti per suo sudo. Ciò consentirà auditddi ottenere uidcorrettamente l'utente chiamante durante la chiamata sudoo su.

  • Riavvia il tuo sistema ora.

  • Accediamo ed eseguiamo alcuni comandi:

    $ id -u
    1000
    $ sudo ls /
    bin boot dati dev etc home initrd.img initrd.img.old lib lib32 lib64 lost + found media mnt opt ​​proc root run sbin scratch selinux srv sys tmp usr var vmlinuz vmlinuz.old
    $ sudo su -
    # ls / ecc
    [...]

Questo produrrà qualcosa del genere in /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)

La auidcolonna contiene l'utente chiamante uid, che consente di filtrare i comandi eseguiti da questo utente con

 ausearch -ua 1000

Questo elenca anche i comandi che l'utente ha eseguito come root.

fonti:


+50 Questa risposta sembra la più completa, anche se sono un po 'deluso dal fatto che sia diventato piuttosto complicato. Grazie per il tuo contributo.
grassroot

Tieni presente che queste modifiche possono aumentare notevolmente il volume del registro in /var/log/audit/audit.log. Il mio volume di log in questo file è più che raddoppiato dopo aver aggiunto le righe twoexecve a audit.rules
JDS

11

Ricorda che sudo stesso registra tutti i comandi sudo nel syslog, quindi tutti gli utenti privati ​​dovrebbero essere educati a non semplicemente sudo per ottenere una shell di root ma a:

sudo command p1 p2 ... pn

Il problema con questo o qualsiasi approccio a cui ho pensato è che, in quanto rootutente, è abbastanza difficile impedire a un utente di eludere qualsiasi tipo specifico di registrazione. Quindi qualsiasi cosa tu provi sarà <100%, mi dispiace dirlo.

Istruzione, documentazione, applicazione e soprattutto fiducia sono ciò che è necessario.


3
Capisco che nulla sarà perfetto, ma non saremo mai in grado di far lavorare tutti come descrivi. Questi sono amministratori di sistema di cui stiamo parlando;)
Soviero

3
Non è vero .... almeno due società molto grandi con cui ho lavorato personalmente, costituite da un gran numero di amministratori di sistema, hanno adottato questa politica! Ancora una volta, con l'educazione e l'applicazione funziona.
mdpc,

2
mdpc è corretto al 100%. Questo è esattamente lo scopo del comando sudo. Sono in un negozio di dieci amministratori di sistema con centinaia di host e utilizziamo i singoli comandi sudo per tutto - esiste una politica specifica che vieta di diventare root tramite su -. È l'unico modo ragionevole per garantire che le operazioni di amministrazione siano controllate correttamente.
Jeff Albert,

4
-1 L'istruzione non lo farà mai. Viviamo in un mondo in outsourcing dove sei solo uno dei tanti clienti dei tuoi amministratori di sistema.
grassroot

7

Una volta mi sono trovato di fronte allo stesso problema e ho dovuto trovare una soluzione rapida e sporca: ogni utente sudo avrà il proprio file di cronologia una volta eseguito il comando sudo -i

In /root/.bashrcho aggiunto la seguente riga -

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

Quindi ogni utente che esegue il root su root avrà un file di cronologia .bash_history-username.

Un altro metodo -

Aggiungi il seguente codice a /root/.bashrce aggiungerà il nome utente, sudo-user e il comando al file di registro, ovunque sia impostato il livello di avviso, molto probabilmente / var / log / messaggi.

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

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


Approccio piacevole, anche se non proprio quello che è stato chiesto. Mi piacerebbe vedere un auditd o una soluzione simile.
grassroot

ok l'ho aggiornato per fare affidamento sul metodo trap.
Daniel t.

3
E per gli utenti legittimi, funziona. Ma se quell'account è stato violato, il cracker potrebbe disabilitare rapidamente la cronologia di bash eseguendo /bin/sh, unset HISTFILEo /bin/bash --norc.
Stefan Lasiewski,

3

Numerosi stabilimenti in realtà vietano l'uso di auditd perché consumano molte risorse e possono comportare un'opportunità per attacchi denial of service.

Una soluzione è configurare la shell Korn più recente (ksh-93, vedere http://kornshell.com/ per i dettagli) per registrare tutti i comandi eseguiti come root su un server remoto syslog e quindi richiedere per politica che, tranne in caso di emergenza situazioni, gli amministratori di sistema accedono con account personali ed eseguono la shell Korn avanzata tramite sudo. L'esame dei registri può rilevare quando un amministratore avvia un'altra shell dalla shell approvata al fine di coprire le loro tracce e la SA può essere educata secondo necessità.


3

Sudo ha qualcosa chiamato sudoreplay quando le sessioni abilitate sono registrate e possono essere riprodotte in un secondo momento, funziona in modo simile al scriptcomando che crea un dattiloscritto di una sessione terminale che in seguito può essere riprodotto con il scriptreplaycomando.


2

Non che ci sia qualcosa di sbagliato in nessuna delle altre risposte finora, ma se decidi che sudola registrazione tramite syslogè soddisfacente, posso suggerire una ruga: accedila tramite la rete a un host di controllo remoto.

Ciò aggira il problema di "ora che sono diventato root, posso rimuovere qualsiasi traccia della mia malfunzionamento dai registri". Ora potresti essere root nella casella locale, ma non puoi richiamare quel pacchetto di log dalla rete e (presumibilmente) non hai i privilegi di root sull'host di controllo remoto.

Lo sto facendo con alcune delle reti che gestisco da anni e ha altri due vantaggi del segnale:

In primo luogo, c'è un posto nella rete dove andare a controllare tutti i syslog, che consente una correlazione molto più semplice degli incidenti, e quindi è un punto unico per indagini come "Quando junosi lamentava che il server NFS heranon rispondeva, qualcun altro si lamentava la stessa cosa allo stesso tempo? In tal caso, heraè probabile che sia il problema, vediamo cosa ha registrato; in caso contrario, junola connessione di rete è più sospetta, vediamo cos'altro ha junoregistrato in quel momento. ".

In secondo luogo, la rotazione dei registri syslog diventa più semplice: non conservate copie dei registri sugli host locali per più di qualche giorno, ma assicuratevi che il server di controllo disponga di enormi quantità di spazio su disco e conserviate tutti i syslog lì per diversi anni. Inoltre, se, ad esempio, si desidera scriverli su supporti WORM, ad esempio per scopi di controllo forense, è necessario acquistare un solo disco WORM.


2

Dalla versione 2.0.0 snoopy è in grado di registrare variabili ambientali arbitrarie.

Tuttavia, un recente contributo ha sottolineato che il proprietario di registrazione di tty è una risposta abbastanza efficace ed elegante alla domanda "Chi ha eseguito quel comando come root?".

Divulgazione: sono manutentore snoopy.


Fornire istruzioni su come configurarlo in base ai requisiti del PO, piuttosto che un semplice collegamento. Grazie.
Andrea Lazzarotto,

1
-1. Questa è solo una spina per snoopy. Hai seguito l'informativa, ma non hai ancora risposto alla domanda nel tuo post; ti sei appena collegato al tuo progetto.
Duncan X Simpson,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.