linux user group brescia

   Si, avevo abbastanza ben presente questi motivi, ed hanno assolutamente
  senso, ovviamente (grazie comunque per la conferma, sempre benvenuta).

   Chiaramente l'eventuale "soluzione furba" mi mette in pericolo, in senso
generale, e se gestissi un server aziendale, il pericolo da te delineato non
sarebbe  accettabile: perchè usare Tripwire se poi uno vanifica da sè la
propria  sicurezza?

   Però sto "difendendo" casa mia, non un nodo o un gruppo di host aziendali:
in questo caso, in altri prodotti, ho in passato notato una politica meno
draconiana (ed apprezzo le soluzioni draconiane... prima di prendere in mano
il martello e sfondarle, dandomelo poi sui calli da solo):  certe opzioni
intrinsecamente insicure sono accompagnate da un disclaimer  tipo "noi ti
abbiamo messo a disposizione un muro di acciaio blindato: devi  esser conscio
che, con la tua azione, stai aprendoci dei buchi" e ok, poi uno  si fa due
conti e vede se sta proteggendo Fort Knox (o Fort Meade ;)) oppure  il
carretto dei gelati. (e, come dici tu, in una soluzione enterprise, sganciando
quattrini, "la soluzione" te la mettono a disposizione)

   Il senso della mia domanda verteva più che altro nel sapere se qualcosa era
  sfuggito alle mie ricerche: non uso Linux tutti i giorni come tanti, qui, e
  magari c'era, sempre nell'ambito delle "soluzioni sporche", una soluzione "un
  pò meno sporca", tutto qui.

   Il tuo suggerimento relativo al cambio di password in chiaro, per ridurre
  l'impatto, di fatto credo non sia attuabile per lo stesso motivo per cui son
  "costretto" ad usare password in chiaro: cambiando la local key dovrei
  ricostruire il DB (init, non update), per evitare che l'intero sistema venga
  preso come falso positivo, e questo comporterebbe l'inserimento di una
  password... a mano.

   Forse potrei aggirare la cosa tramite un "generatore di password", che mi
  crea la clearpassword di volta in volta e la passa a Tripwire per il nuovo
  init, cosa che mi porta all'altra cosa che volevo evitare: l'usura dei dischi
  (dovrei anche memorizzare tutta la serie di clearpassword da qualche parte,
  per evitare di bloccarmi l'accesso da solo ai vecchi report e config... e
  siamo quasi al ridicolo).

   Di fatto so bene che sto usando Tripwire al 20% (cifra a caso) delle sue
potenzialità, ma pensavo più che altro ad un sistema che mi elencasse i vari
cambiamenti avvenuti nel sistema con la stessa granularità e, nel caso, poter
risalire al "perchè  è successo cosa": update automatico, update fatto da
me, tentativo (non  troppo esperto) di intrusione... non uno scenario alla NSA
insomma.

   Grazie comunque della risposta, Luca, stavo per scrivere in ML "lo prendo per
  un no" ed andare avanti sperimentando la soluzione "sporca". ;)

   Comunque, dopo quanto ho scritto (e quanto farò sul mio povero server) non
  potrò mai propormi come "esperto di security". :D

  E magari sto usando lo strumento sbagliato e ci sono altri software che fanno
un report settimanale dei "cambiamenti": in quel senso non ho cercato troppo.
Uso Tripwire solo per ragioni "storiche": un pò di anni fa (non ricordo se
con SuSE-6.0 o 8.0) lo usavo nel modo di cui sopra e non mi pareva d'aver
avuto problemi di report "ad accumulo"... ma forse ricordo solo male io, ero
più draconiano allora, e facevo gli update a mano.

  Ciao,
   LC

On Tue, 24 Feb 2015, Luca Giuzzi wrote:
>Date: Tue, 24 Feb 2015 18:55:14 +0100
> 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