linux user group brescia

Il motivo per cui tripwire richiede la chiave locale e' quello di
evitare che un attaccante (che abbia ottenuto i privilegi di root sul
sistema) possa generare una copia firmata del database (e quindi
"autentica") in cui ci sono valori compromessi per gli eseguibili.
Per intenderci: se in /root/.tripwire/mypsw tu metti la password di
tripwire, allora chi ha installato un rootkit puo' leggere quel file,
forzare un aggiornamento del db (eventualmente con date alterate: e'
root ... puo' fare quello che vuole) e poi tranquillamente sapere che
non sara' piu' individuato dal sistema di sicurezza.

Il fatto che un update "unattended" non possa essere eseguito e che
serva la presenza "fisica" dell'amministratore e' parte dei criteri di
progettazione, non uno "spiacevole inconveniente".

Teoricamente, ci sono metodi per implementare quello che tu vorresti
(Forward Secure Sealing; ad esempio http://lwn.net/Articles/512895/ )
ma non ho idea del se tali funzionalita' siano presenti nella versione
open di tripwire (credo quasi sicuramente di no, pero', visto che si
tratta esattamente del tipo di funzionalita' per cui far pagare i
clienti "enterprise").
 Soluzioni "a mano" me ne vengono in mente implementando una cosa
analoga a livello di password ma deve essere fatto manualmente:
offline salvi una Password_segreta; la prima password locale e'
Encoding("Password_segreta","0000...0000") e questa, fintanto che la
usi, la salvi in chiaro (sotto /root od ovunque tu voglia). Ogni volta
che aggiorni il db, cambi anche la local key, usando
Nuova_Local_Key=Encoding("Local_key","0000...0000")
 e cancellando la vecchia local_key.
 A questo punto un avversario puo' alterare l'ultima versione del db
ma non le precedenti (in quanto usavano chiavi differenti e se hai
usato, ad esempio, AES, non sono ricostruibili). Se tu vuoi leggere i
vecchi db per confrontarli con quello corrente e/o verificarli ti
basta rigenerare tutte le chiavi a partire dalla prima.

ciao,
 l


2015-02-22 17:52 GMT+01:00 Luca Coianiz <luca a coianiz.it>:
>     Salve a tutti,
>
>  sto tentando di automatizzare Tripwire in modo tale che, settimanalmente,
> mi faccia una scansione del sistema, mi dia (nel caso) un report in mail dei
> "delta" trovati, e poi aggiorni il suo DB in modo tale da non inviarmi, la
> settimana successiva, le stesse segnalazioni unite a quelle nuove.
>  Ho fatto un tot di ricerche, in rete, e mi pare d'aver capito che un
> intervento manuale sia comunque "quasi richiesto", nel senso: sia nel caso
> di aggiornamento globale (init) del DB delle firme (che preferirei evitare,
> per abbassare lo stress inutile dei dischi), sia nel caso di update del DB
> (preferibile), Tripwire comunque richiede l'inserimento di una password
> (quella che root ha definito come local key).
>  Questo ovviamente rende le cose non automatizzabili (ed ho letto il
> commento di un gestore di grossi sistemi, che non era molto contento della
> cosa).
>
>  Il mio stato attuale:
>
> - ho un cronjob settimanale che esegue la scansione del sistema, domenica
> notte, e nel caso di positivi manda una mail a root
> - sempre nel caso di positivi (quindi non tutte le volte) viene anche
> lasciato un Report in
> /var/lib/tripwire/report/<hostname>-yyyymmdd-hhmmss.twr
> - per tenere aggiornato il sistema almeno sugli aspetti critici (poi forse
> estenderò la cosa a tutto quanto), uso unattended-upgrades, quindi è facile
> che, in seguito ad updates di sicurezza, Tripwire mi trovi dei positivi: per
> verificare se sono voluti mi basta controllare il log di upgrades
>
>  Per dire, uso anche RootKitHunter (rkhunter) ma questo almeno ha la
> funzione di aggiornamento del DB senza la richiesta della password: in
> questo modo posso avere il delta giornaliero senza che sia "ad accumulo
> finchè non ci metto le mani".
>
>  Su Tripwire ho visto come posso scoprire se la scansione ha trovato
> positivi: i seguenti comandi possono esser dati da console, a mo di demo, ma
> anche, ovviamente, inseriti in uno script eseguito da cron
>
> export RPATH=/var/lib/tripwire/report/
> export RNAME=$RPATH$(ls -1 $RPATH | tail -n 1)
> [ $(date --date='yesterday' '+%Y%m%d') = $(date --date="$(stat -t -c %y
> $RNAME)" '+%Y%m%d') ] && echo true
>
>  Quindi posso sapere SE richiedere un update del DB, martedì mattina (anche
> se l'update DB non è un job pesante lo faccio girare verso le 7AM comunque
> ma, ad ogni modo, il check lo posso anche fare direttamente di lunedì con
> "today" e poi aggiornare)
>
> tripwire -m u -s -r $RNAME -a -Z low
>
>  Rimane il problema della password: alle 7/8 di mattina preferirei dormire
> e/o fare altro che non essere lì a dar la password a Tripwire. :D
>
>  Un modo, che mi pare "sporco", consiste nel memorizzare la password (in
> chiaro!!!) in un file tipo /root/.tripwire/mypsw (nota che è la password di
> Tripwire, non quella di root) e poi, credo
>
> tripwire -m u -s -r $RNAME -a -Z low -P $(cat /root/.tripwire/mypsw)
>
>  Prima di scegliere la strada sporca, quindi, torno alla domanda: qualcuno
> ha trovato un sistema più pulito per effettuare l'update senza dover
> lasciare in giro password in chiaro?
>
>  Grazie per l'attenzione,
>
>     LC
> --
> Info/Lamentele/Segnalazioni: andrea.gelmini a gmail.com