Re: [ml] RootKitHunter

.yo.mo. wrote:
>> In ambienti "promiscui", dove tante persone conoscono la password di
>> root, non si riesce mai a sapere chi ha fatto qualcosa.
>> Se si costringono gli amministratori ad entrare con il loro account e
>> fare 'su', si riesce a capire qualcosa in piu'.
> Domanda polimica :-)
> Quello che dici e' capitato anche a me. Quello che non capisco e' perche' 
> in ambiente windows si tende a creare n amministratori, e quindi non 
> usare mai l'amministratore creato in installazione, mentre in ambienti 
> unix like sembra che non si possa fare a meno di utilizzare root con 
> relativa condivisione di password. Perche'?

ormai siamo un attimo ot..

beh, se chi fa in questo modo lo sente come un problema
dovrebbe cambiare prassi (ma magari il vero problema e' che
quella e' l'unica prassi che conosce)

comunque il tutto deriva dal fatto che solitamente se sei
"amministratore" o meno viene controllato sull'uid e non il gid
e altrettanto solitamente il valore dell'uid di root e' harcodato

1) con sudo ognuno ha la sua passwd personale (vedi l'altra mia mail)

2) se si vuole sapere che cosa viene fatto e da chi su puo' usare
   l'exec logging di grsec, magari single group di audit (anche se
   personalmente preferisco loggare tutto)

3) nessuno ti dice che non si possano fare altri utenti "simil root",
   basta giocarsela con i permessi su disco e con passwd/group

3) ma in base a cosa si cerca di ricostruire i comandi?
   la history nella home? personalmente non mi fiderei mai di quello
   che c'e' scritto li dentro, una volta mi era venuta la grande
   idea di mettere le history con chattr append only (che significa che
   l'unica fopen che funziona su quel file e' fopen(fp, a) o fopen(fp,
   a+) e quindi nessuno puo' troncare, modificare o cancellare quel
   file)

   ma poi qualche utente mi fece un bel cat /dev/random sulla
   history e capi' che non era possibile risolvere completamente
   il problema dato che se usavo gli ulimit per limitare dos di quel
   tipo ad un certo punto il file sarebbe diventato "pieno"

   da quel giorno il mio approccio e' questo: syslogd remoto in tcp
   (ntsyslog ma ce ne sono anche alti di buoni) con grsec exec ed altri
   logging su stunnel o vpn e lascio che chiunque possa cannibalizzare
   la sua history

ciaoo

--
ascii - http://www.ush.it