Il 30/10/07, Eugenio<eugenio.adami@xxxxxxxxx> ha scritto: > Stavo ripassando un passaggio preso qui: > > http://www.itvc.net/educational/creare_reti_sicure_con_le_dmz.htm ... > 2) Non mangiare neve gialla, quindi praticamente la mia seconda regola > è non installare mai Linux in una DMZ... " > > La seconda affermazione viene quindi piu avanti così spiegata: > > "Personalmente evito di installare Linux in una DMZ, e il perchè è > abbastanza semplice. Linux è un sistema operativo open-source, il che > significa che il codice del kernel, come la maggior parte delle > applicazioni, sono disponibili a tutti. Quindi, un exploit è scritto e > trovato più facilmente in un sistema Linux, e sento che c'è un'alta > probabilità che ci siano exploit per Linux non ancora riportati, > facendolo diventare un sistema difficile da rendere sicuro. Basandosi > su queste linee guida, ho scelto hardware Sun."...... Mi sembra una farneticazione. E' tutto da dimostrare che la sicurezza diminuisca se l'implementazione è sotto gli occhi di tutti. Guarda caso, tutti i crittografi sono concordi nel dire che un algoritmo è sicuro SOLO SE è completamente pubblico e specificato (e regge nonostante questo). Tra l'altro, il tizio parla di sw, e poi dice "ho scelto hardware Sun" ? E' la solita questione della secuity by obscurity. Ci credono in pochi ormai; il grosso problema è che tagli fuori chi aiuta a risolvere i problemi, mentre il fatto di avere un sistema opaco non ferma affatto chi i problemi vuole crearli. Mi sembra l'atteggiamento di uno che ha una davanti un pezzo di emmenthal e pensa che avvolgendolo nella stagnola diventi un pezzo di grana. rob > > Non ho ben capito il punto della questione: un componente a codice > chiuso sarebbe più sicuro??? > Eugenio > -- > Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO > "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx > > > -- Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx