Come catturare tutti i comandi digitati in Unix/Linux da qualsiasi utente?

Question

Vorrei catturare tutti i comandi digitati in Unix/Linux da qualsiasi utente. Ci sono poche alternative come usare il comando script o l'utility acct. Ma il problema con loro è che stupidamente tutto dal terminale a un file o semplicemente fornire il riepilogo dei comandi. Sto cercando un programma di utilità in cui mi fornirà tutti i comandi digitati da qualsiasi utente con gli argomenti per i comandi. È possibile? Ci sono alternative come fare un gancio nelle chiamate di sistema per ottenere questo?

Answer 1

Sembra esserci un buon articolo sul controllo shell a http://administratosphere.wordpress.com/2011/05/20/logging-every-shell-command/.

Questo considera cose come l'affidabilità dei file di cronologia utente (e fornisce informazioni su come migliorarlo), ma discute anche delle funzionalità di auditing esplicite incorporate nelle shell. Può essere che qualunque ambiente tu stia usando non ha le shell compilate con le funzionalità di auditing abilitate, ma se hai l'origine e la configurazione per le tue build disponibili (come faresti almeno per qualsiasi distribuzione Linux), non dovrebbe essere troppo difficile per abilitare la funzione di auditing mantenendo il resto della configurazione come nella distribuzione di default.

Ciò che questo approccio lascerebbe ancora aperti sono i comandi eseguiti tramite un altro comando o funzionalità del sistema operativo richiamata da alcuni programmi. Quindi, es. se hai perl, o qualsiasi altro interprete del linguaggio di programmazione disponibile sulla macchina, mentre puoi controllare l'esecuzione di perl, non puoi dire cosa l'utente ha detto all'interprete perl a fare. D'altra parte, anche con il controllo della shell, non sono sicuro se l'esecuzione di perl verrebbe vista se è stata eseguita f.ex. dall'interno di qualche editor (come vi) come filtro per elaborare qualsiasi cosa sia stata scritta all'interno dell'editor.

Quindi, mentre il controllo della shell fornirà un livello di auditing, il guadagno non è così grande a meno che l'ambiente non sia realmente stretto rispetto ad altri percorsi di esecuzione rispetto alla shell.

È necessario valutare se gli utenti da verificare richiedono effettivamente l'accesso alla shell e, in caso contrario, fornire loro qualcosa di più limitato, con funzionalità di controllo. Un piccolo sistema di menu basato sul testo, forse?

Answer 2

Grab /home/victim/.bash_history o /home/victim/.config/fish/fish_history

Questi vi permetterà di vedere tutti i comandi bash e crostacei con args che il prodotto WS immessi dall'utente.

Answer 3

Il modo più semplice per risolvere questo problema, è se si è root e in grado di modificare i file di sistema da reindirizzare la console stessa in questo modo:

Se si utilizza ad esempio /bin/sh come console predefinita, spostarlo in /bin/hs e creare un file come questo sotto /bin/sh:

#!/bin/hs 

ORIGSHELL=/bin/hs 
LOGFILE=/var/log/whatyoulike 

OPTIONS="$@" 

USER=`whoami` 
WEBUSER=web 
WILD=NO 
WARN=NO 



if [ "$USER" = "$WEBUSER" ] 
then 

    #Ok then - are we doing something wild? 
    for ARG in $@ 
    do 
    case "$ARG" in 
    *\/lynx) 
     WILD=YES 
     ;; 
    *\/wget) 
     WILD=YES 
     WARN=YES 
     ;; 
    *\/curl) 
     WILD=YES 
     WARN=YES 
     ;; 
    *\/links) 
     WILD=YES 
     WARN=YES 
     ;; 
    *\/fetch) 
     WILD=YES 
     WARN=YES 
     ;; 
    esac 
    done 

    #Are we wild? 
    if [ "$WILD" = "YES" ] 
    then 
    HOST=`hostname` 
    IPADDR=`resolveip -s $HOST` 
    NETSTAT=`/usr/bin/nighthawk -ape --numeric-hosts --numeric-ports --tcp | grep 'ESTABLISHED web'` 

    # Log it. 
    echo "`date` [$USER] $IPADDR "$@"" >> $LOGFILE 
    echo "$NETSTAT" >> $LOGFILE 
    fi 
    #Are we REALLY wild? 
    if [ "$WARN" = "YES" ] 
    then 
    # Mail it! 
    mail -s 'HACKATTACK' youremail@domain.com < $LOGFILE & 
    fi 
fi 

# Now, do it. 
exec $OPERATION "$@" 

#we never come here... 
exit 0 

Questo è solo un esempio, come può essere utilizzato per monitorare tutto trasparente. Puoi fare ciò che vuoi controllare l'input. Lo script precedente viene utilizzato per trovare anche il mittente della shell corrente, in modo che tu possa reagire. Ovviamente i controlli dei casi di cui sopra non sono quelli che usiamo veramente;) - ma un buon campione.

Speranza che aiuta, Jimmy

Answer 4

Afferra la fonte bash. Aggiungi un logger al richiamo exec. Compilarlo Eseguilo come primo comando dopo aver effettuato l'accesso.

Tutto il resto vuole davvero i poteri di root.

Answer 5

So che questo è vecchio, ma penso che il comando di script potrebbe essere quello che stava cercando?

> script my_output_file 
Script started, file is my_output_file 

http://www-users.cs.umn.edu/~gini/1901-07s/files/script.html

Answer 6

ci sta permettendo di revisione contabile, registrazione tty, hack e strumenti gratuiti per fare quello che vuoi, però, a seconda della scala dell 'ambiente che si sta cercando di controllare, si può essere meglio utilizzando sia Audit sia prodotti focalizzati sulla gestione della sfida che si desidera affrontare. Fra i più molto popolare, percorso solo pochi clienti di servizi finanziari sono [Observe-IT, Centrify e PowerBroker

Spero che questo aiuti

Answer 7

È possibile utilizzare Snoopy Logger

Che cosa è: una semplice libreria che inserisce stesso tra process e execv/e() syscalls tramite LD preloading. Registra tutti i comandi eseguiti su syslog.

ciò che non è: Security Solution/auditing - può essere facilmente aggirata. Non registra i comandi shell incorporati (poiché sono interni e quando vengono chiamati, shell non crea un nuovo processo - echo vs/bin/echo per esempio).

Informativa: manutentore corrente di snoopy qui.

Answer 8

Per la registrazione sporadici di solito corro

ssh localhost | tee -a registrati-session.log

Questo funziona abbastanza bene.