[e-privacy] Cifroserver 2 - la vendetta
Leandro Noferini
lnoferin at cybervalley.org
Mon Aug 22 17:39:50 CEST 2005
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.
>
> Ciao Leandro,
>
> scusa se esordisco con un appunto, ma sarebbe meglio che anche i
> problemi venissero fatti circolare. Se questa e', come penso,
> una call per attivita' tecnica, sarebbe meglio che anche
> le attivita' fatte venissero relazionate pur se negative, ad evitare
> duplicazioni di sforzi.
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
> > Di conseguenza è necessario usare un altro approccio. Durante la
> > precedente discussione era stato suggerito di usare un initrd fatto ad
> > hoc: in sostanza la cosa consisterebbe nel realizzare un initrd (che è
> > un disco ram che può essere usato da un sistema linux per avviarsi, come
> > viene fatto comunemente nei dischi di installazione) che abbia il
> > supporto di rete e che faccia avviare anche un programma come ssh così
> > che l'amministratore possa montare le varie partizioni cifrate e poi far
> > terminare il processo di boot.
> >
> > Il problema mio è che di queste cose non ne so praticamente niente e
> > quindi chiedo se ci fosse qualcuno con maggiore esperienza in queste
> > cose così da cominciare a rompere il ghiaccio.
>
> Fatto salvo che quello che dico potrebbe essere viziato dal
> non sapere cosa e' stato fatto, vi allego due file di help
> che si trovano nella documentazione di cryptsetup.
>
> Sono come realizzare una root criptata che chieda la
> password in console, ed uno script che fa la stessa
> cosa leggendo le chiavi da una chiavetta usb.
>
> 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;
- 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;
- quello che voglio ottenere io non è solo il farlo ma anche (e forse
soprattutto) il raccontarlo così che altri possano farlo.
Infine non sono poi così convinto che la cifratura sia una soluzione per
il serverone ma sto andando fuori tema.
--
Ciao
leandro
......e saluti al brigadiere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.winstonsmith.org/pipermail/e-privacy/attachments/20050822/d85e1feb/attachment.pgp>
More information about the E-privacy
mailing list