[e-privacy] Cifroserver 2 - la vendetta

[Marco A. Calamari]

On Mon, 2005-08-22 at 17:39 +0200, Leandro Noferini wrote:
> Il giorno lun, 22/08/2005 alle 10.42 +0200, Marco A. Calamari ha
> scritto:
>  
> > > La prima soluzione data è stata quella di avviare il sistema in una
> > > modalità "temporanea" nella quale non venivano avviati tutti i servizi
> > > ma solo quelli necessari perché il computer fosse raggiungibile e
> > > utilizzabile via rete. Purtroppo questa soluzione ha presentato troppi
> > > problemi perché fosse poi realizzabile e quindi è stata scartata.

......

> Il problema che abbiamo riscontrato con l'altra soluzione era dato dal
> fatto che la distribuzione si avviava in uno stato ben poco
> "funzionale" (ad esempio mancava del tutto l'avvio di urandom e cose
> così) come sta scritto in
> https://lists.firenze.linux.it/pipermail/e-privacy/2005-June/001972.html

Come *non* sta scritto in ....
E' questo il tipo di info che aiutano!

Da quel che ho esaminato, del documento che ho allegato,
 la root criptata va su con tutti i device che ci sono dentro.
Salvo verifica pratica, ovviamente.

....

> > 
> > Ora provo a sottolineare cosa penso che sarebbe meglio fare.
> > 
> > - le precauzioni prese sul serverone sono utili, ma poco
> >  informatiche; in particolare non criptare nulla fa un po'
> >  onco ...... siamo esposti ad un possibile altro attacco fisico.
> > 
> > - essendo il serverone fisicamente vicino, in attesa che si
> >  riesca ad attuare una procedura di reboot remoto con dischi
> >  criptati, suggerirei di implementare subito una soluzione
> >  intermedia, in cui il serverone possa ripartire solo in
> >  presenza fisica di uno dei root che vi inserisce temporaneamente
> >  una chiave usb contenente la chiave di criptazione.
> > 
> > Il serverone bootstrappa una volta all'anno, in media,
> >  quindi con 3 (anche 4, mi candido al ruolo) root fiorentini
> >  in possesso della chiave direi che proprio non ci siano problemi.
> > 
> > I vantaggio e' che potremmo avere subito un server non ottimizzato
> >  come disponibilita' (magari ci vorrebbe qualche ora in piu' per
> >  farlo risalire) ma blindato come sicurezza.
> > 
> > Cosa ne pensate ?
> 
> Che le due cose non sono necessariamente collegate:
> - il cifroserver parte dalla necessità di "proteggere" non il serverone
> ma altri server, di tipo casalingo e molto più specializzati del
> serverone;

Mah, anche questa e' una cosa che capiro' (forse) appena enunciata.

> - il tuo approccio ha il gravissimo handicap di dipendere dalla
> disponibilità di un ristretto numero di persone e di non rendere
> disponibile il computer via rete;

Forse hai letto affrettatamente; il mio approccio e' una soluzione
 tampone (e soddisfacente) al problema di prevenire, e non solo
 rilevare, una altro raid sul serverone. Se lo spengono, ci si fanno
 le pippe. Il prezzo ? Alzarsi dal letto ed andare a riavviare
 se e quando capita, ed assicurarsi che almeno uno di noi (pardon,
 dei root) rimanga a firenze in ogni momento.

Tra l'altro il riavviatore potrebbe anche non conoscere la
 password di root, ma solo avere la chiave.

> - quello che voglio ottenere io non è solo il farlo ma anche (e forse
> soprattutto) il raccontarlo così che altri possano farlo.

Sfondi una porta spalancata. Appunto, raccontiamolo

> Infine non sono poi così convinto che la cifratura sia una soluzione per
> il serverone ma sto andando fuori tema.

Per capire se una cosa e' la soluzione, bisogna prima enunciare,
  il problema, ed essere d'accordo sul quale e'.
Altrimenti capirsi diventa difficile.

Ciao.   Marco

-- 

+--------------- http://www.winstonsmith.info ---------------+
| il Progetto Winston Smith: scolleghiamo il Grande Fratello |
| the Winston Smith Project: unplug the Big Brother          |
| Marco A. Calamari marcoc at dada.it http:// www.marcoc.it     |
| DSS/DH:  8F3E 5BAE 906F B416 9242 1C10 8661 24A9 BFCE 822B |
+ PGP RSA: ED84 3839 6C4D 3FFE 389F 209E 3128 5698 ----------+

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
URL: <http://lists.winstonsmith.org/pipermail/e-privacy/attachments/20050822/7cada5d8/attachment.pgp>