Come tenere traccia delle attività dei superutente

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.

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.

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.

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.

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.

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).

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

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.

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.

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.

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?