Newsgroup: it.comp.sicurezza.unix
Titolo: OpenBSD e sicurezza

Ciao a tutti.
Sto configurando un firewall con OpenBSD. Mi confermate che ho scelto il
prodotto migliore ?
Si, lo so che la sicurezza dipende sempre da come un amministratore e'
capace di configurarla, ma a parita' di amministratore, dovrebbe essere il
prodotto piu' sicuro, o sbaglio ?
Ciao.Alberto.

prodotto piu' sicuro, o sbaglio ?
E` un po' come dire che la panda e` piu` affidabile della mercedes
perche` ha meno accessori.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *
      | (Ri)scoprire fidonet: 
http://bbs.mi.linux.it

 perche` ha meno accessori.
Non e' invece come dire che una FIAT Campagnola e' piu' resistente ed
affidabile di una Mercedes, se devi andare in giro per campi incolti?
	analogalmente,
	   Cthulhu
-- 
       Ph'nglui mglw'nafh Cthulhu 
http://www.rlyeh.it
 wgah'nagl fhtgan!
		       <cthulhu at flashnet dot it>

 perche` ha meno accessori.
con tutto rispetto, dici cosi' solo xke' sei completamente innamorato di
linux.
OpenBSD e' il sistema + sicuro in assoluto.  come strumento di firewalling
ha un interfaccia come ipfiltrer che ipchains non lo vede nemmeno di quanto
gli sta' sopra, uno stack tcp/ip SERIO, un fracco di features che linux si
sogna e ora come ora possono essere usate con iproute2 e una buona lettura
della man page.
come firewall e' il meglio in assoluto, se non vuoi appoggiarti a prodotti
commerciali come un Chekpoint FW-1 o un Cisco PIX.
e' evidente che se devi configurarlo adeguatamente dovrai sudare un po' +
che con una debian, ma ne vale la pena.
per quanto riguarda il paragone e' proprio fuori luogo.

affidabile di una Mercedes, se devi andare in giro per campi incolti?
Il paragone non e` pertinente, linux configurato in modo sicuro IMO e`
sicuro tanto quanto OpenBSD.


sicuro tanto quanto OpenBSD.
Il problema e' sempre il solito. Come esce dal distributore/produttore
e' piu' o meno sicuro ?
Ovvio che poi io posso benissimo fare un auditing intensivo su di una
linux, ma se qualcuno l'ha gia' fatto e' meglio.
Inoltre da una macchina unix io di certo non ho bisogno ne del
plug&play ne della configurazione bellina in grafica.. :-)
Bye Marco
--
Re Marco(Laza) (CBR 900 & Clito 16 Vulve) laza@world+
online.it
Official Sughero Of Spidi Fan Club
Very Bastard Inside Racing Team
------------------------------------------------------------
Ti do' un consiglio: mai sputare in un tornado!
------------------------------------------------------------

 
In che termini scusa, l'affermazione e' un po' generico/dogmatica, mi
piacerebbe capirle queste superiorita'. 
Ciao
-- 
Simone Piccardi
Microsoft is NOT the answer. Microsoft is the Question.
The answer is: "NO!"

 affidabile di una Mercedes, se devi andare in giro per campi incolti?
Mai visto una Mercedes Serie G ????

 che con una debian, ma ne vale la pena.
Quindi OpenBSD e' meglio perche' non e' stato fatto un lavoro accurato
da chi lo ha sviluppato ?????

 sicuro tanto quanto OpenBSD.
IMO Linux configurato in modo sicuro e' un Linux privato della
stragrande maggioranza di accessori e suppellettili, quindi e' il tuo
paragone tra panda e mercedes a non essere pertinente. :)
	limatamente,


 Mai visto una Mercedes Serie G ????
Azz, sono le camionette in dotazione ai Carabinieri?
Effettivamente, non me ne ricordavo, ma non credo che siano a livello
di comfort di una CLK. :)
	suppostamente,


 da chi lo ha sviluppato ?????
No, anzi, se proprio devo dire quella che e' la mia impressione a
pelle, non dimostrata da fatti ne tantomento teorie e completamente
personale, OpenBSD da un immagine migliore perche' coordinato da un
gruppo determinato di persone a loro volta coordinate tra loro.
Linux, al contrario, spesso genera l'impressione di uno sfuggente
essere multi cellulare dove pero' ogni cellula procede nell'evoluzione
in modo anarchico. Un patchwork pulsante, in continuo cambiamento, che
riesci a far funzionare se riesci ad entrare in sintonia con le
innumerevoli menti facenti parte dell'entropia vivente.
A quel punto, indubbiamente, funziona bene. :)
Mi sa che a me lo smog di Roma me fa 'no strano effetto.
	alteratamente,


plug&play ne della configurazione bellina in grafica.. :-)
No, pero` a me fa piacere non dovere compilare su ogni macchina trenta o
quaranta programmi che uso e che OpenBSD non ha per scelta progettuale.


che con una debian, ma ne vale la pena.
No, e` evidente che se devi *usarlo* dovrai perdere un mucchio di tempo
a compilare tutto il software che non viene fornito di serie per dare
l'illusione della sicurezza.


 da chi lo ha sviluppato ?????
tutt'altro, avendo OpenBSD hai la certezza che il software che avrai sara'
ai limiti della perfezione. certo, anche debian ha in suo periodo di freeze
dove vengono testati i pacchetti che verranno inseriti nella prossima
versione, ma OpenBSD come primo scopo ha l'auditing e la verifica del
codice, la sicurezza e la flessibilita' delle applicazioni di rete.
alla fine questa mail e' nata quando e' stato chiesto se OpenBSD andasse
bene come firewall, la risposta e', da parte mia: SI, senza ombra di dubbio.

 piacerebbe capirle queste superiorita'.
la superiorita' di ipfilter sopra ipchains e' scontata, e si qui non ci sono
dubbi.
la validita'di questi prodotti commerciali e' che non ti appoggi ad un
prodotto freeware ma a un prodotto commerciale, potendo godere di supporto
tecnico e non perdendo performarce in senso tecnico.
ciao :)

 l'illusione della sicurezza.
cd /usr/src/ports
make
make install.
questa lunga operazione che occupa un sacco di tempo la devi fare al massimo
10 volte, il fatto e' che un OpenBSD usato come firewall non deve essere
*usato*, non penso che su un sistema simile metterai su gestori di mailing
list MTA e simili, metti il firewall e basta, al massimo, OpenSSH per
l'amministrazione da remoto.
(e non OpenSSH perche' e' stato sviluppato dall'open team, ma perche' e'
nettamente piu' sicuro di ssh1 e ssh2, senza contare la fluidita' della
trasmissione dovuta ad una migliore implementazione del protocollo).
se mi vuoi dire che la compilazione del kernel e' + lunga... ti do' ragione.
ma ripeto che ne vale la pena.
ciao ciao

make install.
Non scherzare. I port non sono nemmeno paragonabili ai pacchetti debian.
Quel che e` peggio e` che gli upgrade sono un macello, mentre con debian
sono quasi completamente automatici ed indolore.


 l'illusione della sicurezza.
D'altra parte, usando software gia' compilato, chi ti assicura che con
quella particolare versione di libc e con le particolari
ottimizzazioni usate in congiunzione col processore che usi, non
escano fuori problemi?
	verificatamente,


 solo comando?
Perche' aspettare che saltino fuori? 
Preferisco prendere direttamente il sorgente... se poi con i pacchetti
debian con un solo comando riesci a compilarli ed installari, meglio
ancora. 
Con il rischio che l'installazione sia stata 'personalizzata', pero'.
	paranoicamente,


 della man page.
Accidenti, non pensavo di avere scatenato un thread :) E' c'e' pure il mio
amico cthulhu :))
Comunque sono contento che qualcuno apprezzi OpenBSD, quando lavoro su di
lui, ho una sensazione di controllo completo della macchina, cosa che gia'
la Debian, che forse e' la migliore delle distribuzioni linux, non mi da.
Ciao.Alberto.

 la Debian, che forse e' la migliore delle distribuzioni linux, non mi da.
Ah, ma allora vuoi far arrabbiare VERAMENTE MdI? :)
	provocatamente,


A costo di sembrare monotono vorrei ri-chiedere a voi estimatori di
OpenBSD quali sono le differenze (con un minimo di contenuto tecnico, le
affermazioni che e' meglio mi paiono poco motivate) che lo rendono tanto
superiore.
Lungi da me ogni scopo polemico, ma siccome non lo conosco vorrei avere
qualche informazione in piu' (la sensazione di controllo completo
francamente non mi pare un dettaglio tecnicamente rilevante).


francamente non mi pare un dettaglio tecnicamente rilevante).
Ti parlo da Linuxaro :-)
Non so darti una panoramica completa di un confronto a livello di
sicurezza tra Linux e OpenBSD, pero` uno degli aspetti dove attualmente
OpenBSD e` superiore (non lo sara` per molto :-) e` il sistema di
hashing delle password. Certo non riguarda il kernel ma fa pur sempre
parte del sistema operativo.
Dove Linux usa il DES o l'MD5 per implementare crypt(), OpenBSD usa
Blowfish per implementare l'omologa, bcrypt().
Blowfish e` un algoritmo di crittazione relativamente giovane ma
(si dice) molto robusto e versatile.
E` stato anche candidato all'AES, "Advanced Encription Standard",
un concorso indetto dal NIST per eleggere il nuovo algoritmo di
crittazione standard dopo il pensionamento del DES.
Ora non mi ricordo se e` ancora presente o no...
In ogni caso, la sua superiorita` rispetto al DES e` che oltre ad
essere intrinsecamente piu` sicuro e` la possibilita` di modificare
i parametri dell'algoritmo. In particolare e` possible variare la
complessita` del key-scheduling e quindi la velocita` dell'algoritmo
in modo da rendere un eventuale dictionary attack impraticabile.
Per darti un'idea basti pensare che una ventina di anni fa un VAX
riusciva a fare 3/4 crypt() al secondo e che bcrypt() rende un
Alpha non proprio come il vecchio VAX ma lo tortura parecchio!
In breve, e` molto piu` facile attaccare password crittate con
DES e MD5 piuttosto che con Blowfish.
Ovviamente questo e` lo scenario peggiore visto che /etc/shadow
e` stato violato e quindi il sistema e` gia` compromesso.
In questo senso OpenBSD offre una garanzia in piu` rendendo la
vita molto piu` difficile al cracker che ha rubato gli hash.
Inoltre sul fronte reti OpenBSD supporta IPsec.
Questo e` un breve riassunto, tutti i dettagli li trovi facilmente
su 
www.openbsd.org
.
Ultima nota, c'e` un progetto interessante che si chiama Trusted BSD
www.trustedbsd.org
. Consiste in una serie di patches che quando
saranno completate aspireranno a rendere FreeBSD un sistema sicuro
di classe B1, quindi ACL, Mandatory Access Control, auditing ecc.
Insomma, attualmente vedo i *BSD e Linux press'appoco allo stesso
livello tranne OpenBSD che e` un piccolo gradino piu` su per certi
aspetti. In futuro potremo vedere un BSD certificato B1 ma anche sul
fronte Linux si sta lavorando visto che SGI ha in progetto di portare
Linux allo stesso livello di sicurezza e ha gia` rilasciato del codice.
http://oss.sgi.com/projects/ob1
-- 
Lorenzo
"Given enough eyeballs, all bugs are shallow", Linus'Law
(address rot13 encoded)


www.trustedbsd.org
. Consiste in una serie di patches che quando
Ci sono almeno un paio di progetti simili per linux. L'utilita` nel real
world non e` molto chiara.


L'utilita` nel real world non e` molto chiara.
E` vero ma se si stanno muovendo anche sul quel fronte vuol dire che
qualche utilita` ce l'avra`, credo. Non cadiamo nella tentazione di
ritenere una cosa poco utile solo perche` Linux non la possiede, ora.
Io del resto non e` che possa giudicare molto visto non ho la tua
esperienza mi fai da punto di riferimento, pero` mi piacerebbe vedere
un atteggiamento piu` aperto.
Adoro Linux per la sua velocita` di evoluzione, per il fatto che tutti
i giorni ci lavorano decine di magliaia di sviluppatori (solo al kernel)
e basta leggere la mia signature per accorgersi dell'importanza di cio`.
Considero questo una qualita` *vincente* rispetto al codice "statico" dei
*BSD dove lo sviluppo e` piu` basato su un modello a Cattedrale per
dirla alla Eric Raymond.
Spero di aver riparato questo piccolo incidente diplomatico :-)


qualche utilita` ce l'avra`, credo. Non cadiamo nella tentazione di
Spiegamela, io sono sempre qui.


Spiegamela, io sono sempre qui.
Per esempio il mandatory access control e` indispensabile per
coprire certe falle della protezione offerta dalle sole ACL.
Questo e` tratto da "A GUIDE TO UNDERSTANDING DISCRENTIONARY ACCESS CONTROL"
del NATIONAL COMPUTER SECURITY CENTER
http://www.radium.ncsc.mil/
So gia` che conosci il problema e non ami la roba militare (anch'io :-)
ma lo riporto per completezza.
6.2 AN EXAMPLE OF A TROJAN HORSE
   Consider a system where an access control list mechanism (as described
   in Section 7.3) is used to implement discretionary access control.
   There are two users on this particular system: an honest user, DOE;
   and a dishonest user, DRAKE. DOE has a data file which contains highly
   sensitive data; this file is known as DOESFILE. He has diligently set
   the ACL to allow only himself to read the file. No other users are
   authorized to access the file. DOE is confident that no one but
   himself will be able to access his data file.
 
   DRAKE is determined to gain access to DOESFILE. He has legitimate
   access to the system which allows him to implement a useful utility
   program. In this utility DRAKE embeds a covert function to read
   DOESFILE and copy the contents into a file in DRAKE's address space
   called DRAKESFILE. DRAKESFILE has an ACL associated with it that
   allows processes executing on DOE's behalf to write to it, while
   allowing DRAKE's processes to read it.
 
   DRAKE induces DOE to execute his utility program by telling him how
   useful and efficient it is. DRAKE is careful not to tell DOE about the
   covert function (Trojan horse) that is resident in the utility
   program. DOE executes the corrupted program and it appears to perform
   perfectly. However, while it is operating on DOE's behalf, it assumes
   his identity and thus his access rights to DOESFILE. At this time it
   copies the contents of DOESFILE to DRAKESFILE. This copying takes
   place completely within the constraints of the DAC mechanism, and DOE
   is unaware of what is happening.
 
   This example should make clear the danger of Trojan horse attacks and
   the inadequacy of most DAC mechanisms to protect against such attacks.
   It should be noted that an elaborate DAC mechanism may provide
   illusory security to users who are unaware of its vulnerability to
   Trojan horse attacks.
...
   A reference monitor which implements a mandatory security policy which
   includes the *-property would provide robust protection against Trojan
   horse attacks. The mandatory access control implementation would
   prevent the Trojan horse from disclosing the information to a user who
   is not permitted access to the information under the mandatory access
   rules. Assume the same scenario as was described previously with the
   following changes. The computer system now implements a mandatory
   security policy with two hierarchical sensitivity levels. For the sake
   of simplicity, the levels are called sensitive and non-sensitive. DOE
   operates at the sensitive level, and DOESFILE is sensitive. DRAKE is
   not authorized to access sensitive data, so he operates at the
   non-sensitive level. DRAKE is only allowed to read non-sensitive
   files, so DRAKESFILE is non-sensitive. As before, DRAKE's Trojan horse
   program is executed by DOE. The program takes on the sensitivity level
   and the identity of DOE. Within the constraints of the mandatory and
   the discretionary security policies, the program reads DOESFILE.
   However, when the Trojan horse tries to write the sensitive data to
   DRAKESFILE, the reference monitor disallows the operation. Since the
   Trojan horse is now executing at the sensitive level, the program
   cannot be allowed to write to a non-sensitive file. That would be a
   violation of the *-property [1].
   This example should show the reader that discretionary access control
   is only effective to restrict the `honest'' user in browsing through
   other users' files and preventing accidental disclosure or destruction
   of information. The malicious user who is determined to gain
   unauthorized access to data on the computer system must be restricted
   by other means, such as mandatory access controls.
Qui *c'e`* un problema.
Il software autenticato certe volte non basta, per esempio il caso
di un programma che gira con privilegi root che potrebbe andare in
core dump a causa di un bug interno di qualsiasi natura e il core
dump potrebbe contenere informazione sensibile.
In passato ci sono stati diversi buffer overflow del server X11 che
permettevano di leggere /etc/shadow, con il MAC questo non potrebbe
mai accadere. Software autenticato non implica software corretto
purtroppo e in questo caso qualunque cosa che giri con alti privilegi
e` relativamente pericolosa. Cosa ne pensi?
Ti prego non massacrarmi, voglio solo imparare :-)


 qualche informazione in piu' (la sensazione di controllo completo
L'unico vero modo per scegliere e' provarli entrambi, e lasciare che
sia uno di loro a scegliere te. :)
	consigliamente,


e` relativamente pericolosa. Cosa ne pensi?
Che le cose piu` semplici spesso sono le piu` sicure.


Che le cose piu` semplici spesso sono le piu` sicure.
Sono d'accordo a meta`.
Le cose semplici mi piacciono molto, perche` solo facili da gestire
e si fanno meno errori. Tuttavia in certi casi la flessibilita` e`
piu` importante.
Le ACL sono piu` complicate da gestire ma permettono un controllo
degli accessi piu` preciso e quindi piu` sicuro.
E` possibile escludere l'accesso al solo utente "cattivo" di un gruppo.
Non fare caso all'esempio stupido, e` solo per esprimere il concetto.
Con il mandatory access control e` la stessa cosa, si infittiscono
le maglie della sicurezza aumentando la quantita` e la qualita` dei
controlli.
D'altra parte sono d'accordo con te che aumentando la complessita`
l'essere umano tende a sbagliare, e se lo fa root mette cerca di
districarsi tra permission bits, ACL e MAC i risultati possono
essere disastrosi.


il soggetto e` gerarchicamente superiore al file. In questo modo
                                ^^^^^^^^^
                                inferiore


Nella realta` e` cosi`?
Lo sara` tra qualche mese, il codice nel kernel c'e` gia` tutto.


 poco che fare un auditing "completo" e` un compito relativamente veloce.
Mah. Veramente in fatto di crittografia integrata,
ad esempio, Linux č ridotto molto pių "all'osso"
di quanto non lo sia OpenBSD.

 l'illusione della sicurezza.
E quale sarebbe questa montagna di software che uno
deve prendersi la briga di compilare per poterlo
usare? Io lo uso e c'ho aggiunto ben poco, e di
certo nessun programma che dà particolari problemi
di sicurezza.

 sia uno di loro a scegliere te. :)
OpenBSD per me, grazie.

di quanto non lo sia OpenBSD.
Crittografia integrata? Che significa? Questa e` un'altra buzzword
inventata per spingere OpenBSD.
Quali funzioni crittografiche utili a qualcosa esistono in OpenBSD e
non, per esempio, in debian?


 non, per esempio, in debian?
OpenSSH
KerberosIV
S/Key
OpenSSL
PID random
adesso dimmi che esistono di default (e auditate) in debian.
E sto certamente dimenticando qualcosa.
Vai pure a 
http://www.openbsd.org/crypto.html
se vuoi vedere cosa ha in più in fatto di crittografia
rispetto a debian. E non sto qui ad elencare altre cose
che c'entrano con la sicurezza ma non troppo con la 
crittografia.
Con tutto il rispetto, se preferisci Linux ok, ha degli
aspetti migliori di OpenBSD per certi versi, ma io (e non
solo io) lo ritengo largamente inferiore dal punto di
vista della sicurezza. Poi ognuno fa come meglio crede.


Ah... ricompilando il kernel si può anche far sì
che lo swapping sia crittato (Blowfish, se non erro).

rispetto a debian. E non sto qui ad elencare altre cose
A parte IPsec, che e` ancora altamente sperimentale e poco usato, non
vedo nulla di significativo.


Lo sara` tra qualche mese, il codice nel kernel c'e` gia` tutto.
Ti riferisci a XFree86 4.0?


 paragone tra panda e mercedes a non essere pertinente. :)
ma quando mai. Ti configuro una slackware a prova di bomba senza
levare niente. 
non mi piace questa filosofia tutta italiana del "togliere i servizi per
rendere piu' sicuro un sistema". voglio il finger ! voglio il telnet !
e insomma ! :)
-- 
MI DISGUSTA chi manda messaggi MIME, HTML o con attach. ICQ 36294456, PGP
asb...@kyuzz.org
, mex No (C) for non commercial use, 
www.kyuzz.org/asbesto

 tecnico e non perdendo performarce in senso tecnico.
io direi che e' il loro punto debole. supporto tecnico ? anche windows
ha un "supporto tecnico"
preferisco un prodotto di cui ho i sorgenti, gratuito o quasi, e di
cui posso trovare una soluzione in breve tempo sulla rete ...


Ti riferisci a XFree86 4.0?
No, mi riferisco alle capabilities. Guarda l'URL che ho postato.


 vita molto piu` difficile al cracker che ha rubato gli hash.
ma dai. tutta questa e' paranoia ! :) uno magari si sbatte con i tuoi
dizionari, e tu non dovresti nemmeno accorgerti di NIENTE, che ti hanno
fregato lo shadow ? e quello magari impiega 1 mese (se ha culo!) a trovare
la tua pw ? e tu tieni per 1 mese le stesse pw sul tuo sistema ? 
naaahhh! :)))


 vedo nulla di significativo.
Allora in questo abbiamo visioni diverse. Per come
la vedo io, dal lato sicurezza e' costruito in modo
molto piu' accurato OpenBSD di quanto lo siano
tutte le distribuzioni Linux (compresa la debian);
e tutto si può dire tranne che il team di OpenBSD
affidi la promozione dell'OS ad una serie di buzzword.

 e insomma ! :)
Meno porte aperte lasci, meno gente entra a curiosare. :)
	introversamente,


 Non ho visto faccine di sorta. Stai scherzando?
Sě infatti; non l'ho capito nemmeno io, ma spero che
stesse scherzando... poi "questa filosofia tutta
italiana"... bah... se c'č un assioma nella sicurezza
di qualsiasi sistema č proprio quella di levare i servizi
se non assolutamente necessari. Figuriamoci poi telnet,
finger e cose del genere, che fan giŕ ridere se nominate
nella stessa frase di "sicurezza".

nella stessa frase di "sicurezza".
Esistono demoni finger sicuri.


 Esistono demoni finger sicuri.
Lo so e preferisco comunque non usare finger tout court.

 
asb...@kyuzz.org
, mex No (C) for non commercial use, 
www.kyuzz.org/asbesto
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Remove ICE from e-Mail
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 Meno porte aperte lasci, meno gente entra a curiosare. :)
ma io voglio che entrino, curiosino, e si rendano conto che non
possono fare assolutamente nulla di male. :)


 Non ho visto faccine di sorta. Stai scherzando?
no, non sto scherzando


 nella stessa frase di "sicurezza".
gia', chissa' come fanno allora a funzionare le varie universita'
americane, o inglese (e se volete vi do qualche indirizzo). in ssh ?
macche'. telnet, e se ti serve sapere se c'e' qualcuno online
fai un finger. 
togliere servizi e' comodo ma non e' l'unica soluzione.


 americane, o inglese (e se volete vi do qualche indirizzo).
Nessuno ha mai detto che siano sicure.

 possono fare assolutamente nulla di male. :)
Entrare e curiosare?
FUORI DAI SERVER, TEPPA! 8)
	scacciatamente,


americane, o inglese
rotfl

Che le cose piu` semplici spesso sono le piu` sicure.
A proposito degli stack IP vorrei dire che quello di Linux e' riconosciuto
essere l'unico pienamente e totalmente conforme agli standard IPv4 e IPv6 senza
eccezzioni di sorta!


Esistono demoni finger sicuri.
Il solo poter raccogliere informazioni sull'utenza e' gia' considerato in
alcuni casi un baco di sicurezza!!


alcuni casi un baco di sicurezza!!
Se ne installo uno si vede che non mi ritengo uno di questi casi...
(Mah.)


 eccezzioni di sorta!
<ROFL>
ROFL...
</ROFL>
Da chi?
saluti
lele


1: Leggi le specifiche.
2: Leggi l'implementazione.
3: Fai anche quallche test.
.. e lo vedrai!