Come tenere traccia delle attività dei superutente


21

Mi piacerebbe sapere quali sono i migliori approcci per tenere traccia delle attività dei superutente in un ambiente Linux.

In particolare, sto cercando queste funzionalità:

  • A) Registrazione delle sequenze di tasti su un server syslog protetto
  • B) Capacità di riprodurre sessioni di shell (qualcosa come scriptreplay)
  • C) Idealmente, dovrebbe essere qualcosa di impossibile (o abbastanza difficile) da aggirare senza avere accesso fisico al server.

Pensaci da un punto di vista della sicurezza / controllo, in un ambiente in cui diversi amministratori di sistema (o anche terze parti) devono poter eseguire operazioni privilegiate su un server.

Ogni amministratore avrebbe il proprio account nominale e ogni sessione interattiva dovrebbe essere completamente registrata, con la possibilità di riprodurla se necessario (ad esempio, se qualcuno usasse mc per cancellare o modificare file critici, non sarebbe sufficiente sapere che quella persona ha emesso il comando mc; ci deve essere un modo per vedere esattamente cosa è stato fatto dopo aver lanciato mc).

Note aggiuntive :

  1. Come ha sottolineato Womble, potrebbe essere l'opzione migliore non avere persone che accedono con i privilegi di root per eseguire modifiche sui server, ma invece farlo attraverso un sistema di gestione della configurazione. Quindi supponiamo che una situazione in cui non abbiamo un tale sistema e abbiamo bisogno di garantire l'accesso root a persone diverse nel corso dello stesso server .
  2. Non mi interessa affatto farlo di nascosto: ogni persona che accede a un server con i privilegi di root sarebbe pienamente consapevole che la sessione verrà registrata (nello stesso modo in cui, ad esempio, gli operatori di call center sanno che le loro conversazioni sono in fase di registrazione)
  3. Nessuno userebbe un account superutente generico ("root")
  4. Sono a conoscenza di ttyrpld e sembra fare quello che sto cercando. Ma prima di andare in quel modo, vorrei sapere se questo può essere risolto usando un kernel non modificato. Voglio sapere se ci sono strumenti per Debian in particolare (o Linux in generale) che consentono il controllo completo degli account di superutente senza patchare la shell o il kernel.

2
(prende sedia e popcorn) dovrebbe essere buono ...
Avery Payne,

+1 ... stava pensando esattamente la stessa cosa. LOL
KPWINC,

Nota anche questa domanda correlata: serverfault.com/questions/46614/…
sleske,

Penso ancora che dovresti usare un sistema di gestione della configurazione. (burattino / cfengine / chef / systemimager / chef / ecc ...)
KevinRae

Kevin, sono d'accordo con te. Vedi ad esempio il mio commento alla risposta di Womble: serverfault.com/questions/50710/… . Sfortunatamente, questa non è un'opzione su questo ambiente, ed è per questo che ho chiesto di assumere uno scenario in cui un sistema di gestione della configurazione non è disponibile. Ad ogni modo, vorrei ringraziarvi per il vostro feedback su questo argomento.
mfriedman,

Risposte:


8

Per gli ambienti con più amministratori, non utilizzare root, se possibile.

Usa sudo per tutto: sudo è estremamente configurabile e facilmente registrabile.

Accedi a / tutti gli accessi o i su per eseguire il root e investigali mentre qualcuno sta seguendo le tue regole stabilite.


3
Sì, sudo ha un'ottima registrazione: tutte quelle voci "womble ran / bin / sh as root" sono davvero utili. Senza la gestione della configurazione, le persone diventeranno sempre root per svolgere attività amministrative e qualcuno che vuole fare qualcosa di malvagio potrebbe semplicemente fare le proprie cose nella stessa sessione root eseguendo un'attività valida. La copertina perfetta.
Womble

La politica deve scoraggiare semplicemente sborsare come root perché questo sia un bene, ovviamente, e non sarai in grado di sapere cosa hanno fatto una volta che hanno lasciato la prenotazione, ma restringe l'elenco dei sospetti ...
dmckee

2
Politica: "sudo / bin / sh" = licenziato / investigato. Soluzione abbastanza chiara e abbastanza facile.
Karl Katzke,

5
ci sono così tanti modi per ottenere una shell da programmi che le persone dovranno legittimamente eseguire (ad es. da sudo vi) che ha poco senso bloccare semplicemente 'sudo /bin/sh'... a meno che tu possa essere certo di aver bloccato ogni possibile metodo, avresti appena lanciato una sfida per trovare modi più oscuri. in ogni caso: a) a volte sudo / bin / sh è necessario eb) è un problema di gestione, non di tecnologia.
CAS

Chris fa un ottimo punto: problema di gestione, non problema tecnico.
Karl Katzke,

2

Per uno, che tipo di accesso utente root stai cercando di monitorare? Stupidi errori di amministrazione o insider maliziosi? Il primo: ti consigliamo una buona soluzione di gestione della configurazione, come è già stato suggerito. Quest'ultimo - se sanno cosa stanno facendo, puoi solo sperare di catturare abbastanza per indicare che è successo qualcosa che vale la pena indagare. Volete solo sapere che è iniziata una qualche forma di attività non autorizzata ed essere avvisati di questo fatto. Se sono intelligenti, disabiliteranno la maggior parte degli accessi (modificando lo stato del server o portando i propri strumenti), ma spero che tu possa cogliere l'inizio dell'incidente.

Detto questo, suggerisco un paio di strumenti che puoi usare. Innanzitutto, inizia con una buona politica sudo (che è già stata suggerita). In secondo luogo, controlla sudoshell se hai bisogno di dare a quegli amministratori l'accesso alla shell root. Terzo, probabilmente la soluzione migliore (anche se più intensiva), controlla l'auditing del kernel Linux.


+1 Grazie per aver suggerito il sudoshell, e specialmente per la metionizzazione del sistema di controllo del kernel Linux, potrebbe essere un complemento eccellente per quello che sto cercando di ottenere.
mfriedman,

2

Quello che potresti fare è usare questa libreria per sudo, dare a tutti il ​​proprio account utente e inserire sudo -i nel profilo di tutti. In questo modo hanno accesso root immediato e ogni comando che usano viene registrato.


+1 Non sapevo di quella biblioteca. Grazie per aver condiviso!
mfriedman,

1

Hanno radice. Il meglio che puoi sperare è almeno vedere quando hanno deciso di uscire dalla tua piccola utopia di monitoraggio, ma oltre a ciò che hanno fatto è la supposizione di chiunque.

L'opzione "migliore" che mi viene in mente è quella di imporre l'uso dell'automazione e della gestione della configurazione pervasiva, e gestire i tuoi manifest usando un sistema di controllo di revisione e distribuire gli aggiornamenti attraverso quello. Quindi impedire accessi root effettivi ai server. (L'accesso di emergenza "oh noes ho rotto qualcosa" può essere fornito da una password o chiave SSH non distribuita e cambiata dopo ogni utilizzo, e tutti possono guardare l'amministratore di sistema che ha rovinato tutto per assicurarsi che non cambiare qualcosa).

Sì, questo sarà scomodo e fastidioso, ma se sei abbastanza paranoico da voler monitorare le azioni di tutti a questo livello, immagino che tu sia in un ambiente che è scomodo e abbastanza fastidioso in altri modi che questo ha vinto sembra un grosso problema.


Devo essere d'accordo con te L'opzione migliore sarebbe non avere le persone che accedono con i privilegi di root per eseguire modifiche sui server, ma invece farlo attraverso un sistema di gestione della configurazione. Trovo i tuoi commenti utili per perfezionare e chiarire la mia domanda.
mfriedman,

1

Come altri hanno già detto, non c'è praticamente modo di registrare gli utenti con accesso root completo in un modo che non possono disabilitare, ma se stai eseguendo debian / ubuntu dai un'occhiata a snoopy , che si avvicina molto a quello che vuoi

snoopy è semplicemente una libreria condivisa che viene utilizzata come wrapper per la funzione execve () fornita da libc per registrare ogni chiamata a syslog (authpriv). gli amministratori di sistema possono trovare snoopy utile in attività come il monitoraggio del sistema leggero / pesante, il monitoraggio delle azioni di altri amministratori e anche una buona "sensazione" di ciò che sta accadendo nel sistema (ad esempio apache che esegue script cgi).


Grazie per la risposta. Supporta la registrazione dei tasti o solo la registrazione dei comandi?
mfriedman,

0

Sono d'accordo con i commenti di disabledleopard sull'uso di sudo per tutto. Certamente rende le cose un po 'più facili da registrare.

Vorrei anche aggiungere periodicamente il backup del file cronologico di bash. Apparentemente spesso trascurato, ma a volte può essere una grande fonte di informazioni ... basta chiedere a Goldman Sachs. ;-)

http://www.guardian.co.uk/business/2009/jul/12/goldman-sachs-sergey-aleynikov


2
ho uno script .bash_logout che crea una copia della cronologia della cronologia in /var/lib/history/$user.$tty-or-IP.$yymmddhhss se mi interessasse di più, impostarei l'account di processo o corretto strumenti di auditing ... ma non è proprio per la sicurezza, è così che posso scoprire chi ha fatto qualcosa di stupido e dire loro a) di non farlo di nuovo eb) come farlo correttamente. aumentare il livello di indizio dei giovani è molto più un problema qui che la fiducia.
CAS

1
Mi ricorda la storia in cui un ragazzo delle vendite junior fa saltare l'accordo da un milione di dollari. Si aspetta che il capo lo licenzi e il capo dice "Al diavolo no! Mi è costato solo un milione di dollari PER FORMARTI!" Riesco a sentire il "livello di indizio" dei giovani che aumenta mentre parliamo. ;-)
KPWINC,

0

Sarebbe difficile ...

root può eseguire script ben testati che possono violare tutte le misure di sicurezza (uccidere i processi di monitoraggio), distruggere i file di registro / eliminarli ecc ... Ma comunque ...

Supponendo che più amministratori con il privilegio di root stiano lavorando in team. E root può anche uccidere qualsiasi processo di monitoraggio. E sfortunatamente, quel login / password diventa pubblico. Oppure ottengono una compagnia indesiderata.

La creazione di più account di root con UID 0 sebbene non sia consigliata, potrebbe essere applicabile qui.

In / etc / ssh / sshd_config Modifica della riga in: PermitRootLogin no

è raccomandato. In questo modo, qui, un utente accede usando il suo account normale (il datetime stamp è registrato insieme (forse indirizzo IP contraffatto)) Quindi passa a root. usando il comando su

E l'accesso diretto come root è impedito in questo modo.

Dobbiamo pensare a ciò che root non può fare qui.

sudo dovrebbe essere buono. Il backup dei file di configurazione della directory / etc dovrebbe essere buono. / var / directory I file di registro devono essere inviati periodicamente via e-mail o archiviati su NFS separato.

Che ne dici di scrivere script che integrano le API di aziende Mobile Gateway che raggruppano SMS su tutti i cellulari dell'utente root, che uno di loro è fuori casa per lavorare. So che sarebbe irritante, ma comunque.

La rottura di SSH è per lo più fuori discussione.


0

Abbiamo la seguente configurazione sul sito di un cliente:

  • Allo stesso modo, aperto per l'autenticazione con Kerberos su AD (account personali)
  • Autorizzazione solo a determinati gruppi AD di amministratori Unix
  • sudoers group == gruppo AD
  • Agenti OSSEC HIDS su ogni server e un manager su un server rinforzato
  • UI Web OSSEC
  • Splunk 3 con Splunk-per-OSSEC

Registra ogni utilizzo di sudo sui server e tiene traccia di eventuali modifiche ai file, installazione di pacchetti, processi sospetti, ecc.


0

Abbiamo diversi server terminal per accedere a tutte le nostre apparecchiature, il che significa che è possibile accedere a qualsiasi cosa dal terminal server o se si ha accesso fisico.

Sshd su server terminal è patchato con http://www.kdvelectronics.eu/ssh-logging/ssh-logging.html , funziona bene, ma non è stato aggiornato per molto tempo. L'ho modificato un po 'per funzionare su openssh 4.7, ma non ci sono riuscito con 5.1. Segfaults di sshd rattoppati, e finché non ho abbastanza tempo per sistemarlo, sono quasi passato a ttyrpld.


0

Finora, questo è quello che ho:

  • sudosh : sembra supportare A e B (non del tutto sicuro di A però)
  • Sudoscript : sembra supportare B (Sudoscript ha un componente chiamato sudoshell, e se questo è ciò che suggeriva Romanda, grazie per il suggerimento)
  • Snoopy Logger o sudo_exetrace : non esattamente quello che sto cercando, ma potrebbe essere un buon complemento (grazie all'altra ricevente e al blauwblaatje per quei link)

Conosci altri strumenti simili che non comportano l'applicazione di patch al kernel o ad altri componenti del sistema?

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.