Newsgroup: it.comp.macintosh
Titolo: Firewall

Buonasera,
avevo gią chiesto un buon firewall hardware per Apple tempo fa. Ora il boss 
vuole finalmente prenderlo e pensavo di suggerirgli (anche per semplicitą di 
configurazione) una base Airport. Ora vi chiedo questo:
1) č un buon firewall? non sono convinto, perchč mi avevate consigliato i 
Cisco;
2) ci sono due Apple in rete: uno con ed uno senza la scheda interna per 
ricevere/trasmetter da/verso la base. Farli (finalmente) dialogare č la 
ragione per cui gli suggerirei la base. Sicuramente quello senza la Airport 
express (un Imac G4 flat screen dello scorso anno) non puą dialogare 
wireless senza la scheda (ovvio), ma si puņ connettere tramite un comune 
cavo ethernet?
Vi ringrazio sin d'ora.
Davide 

 Cisco;
Mi pare (ma puo` darsi che sia disinformato) che le basi Airport, come
firewall, siano limitate: non hanno la capacita` di trackare lo "stato"
di ogni connessione, cioe` filtrano pacchetto x pacchetto e basta.
Mi sgolo a ripeterlo, ma lo raccomando anche a tutti i miei clienti (sia
che mi paghino anche per consulenze di sicurezza, oltre a quelle SW che
sono il mio business principale, o meno): il miglior firewall del mondo
e` uno scatolotto economico ma solido (mi spiace dirlo ma nella mia
esperienza er mejo e` uno scatolotto con Duron, 256 o 512 MB di RAM,
disco piccolotto diciamo 30GB che da di meno al giorno d'oggi non ha
senso; + che abbastanza per firewallare connessioni dedicate a 10 Mbps o
meglio...; adesso che i Duron non ci sono + non so, i Sempron non li ho
provati, gli Athlon comunque sono ok; evitare intel; evitare [sigh, mi
spiace _davvero_ dirlo] PPC...), con due schede Ethernet separate sul
bus (le intel sono ottime, ma ce ne sono comunque tante di buone), e
OpenBSD 3.ultimosubrelease (3.5 oggi; esce 2 volte l'anno e la 3.6 e`
imminente ma non ho seguito bene che migliorie abbia).
Il firewall pf incluso in OpenBSD e`, nella mia esperienza, il migliore
da ogni punto di vista.  E OpenBSD stesso e` una roccia, impagabile.  Se
il boss insiste che sia un "firewall _hardware_" si possono trovare
scatolotti precotti che usano e integrano OpenBSD e pf senza le normali
comodita` di una macchina OpenBSD general purpose, ma onestamente il
concetto mi schifa tanto che consulenze gratis, in merito, non ne
faccio: "pagando s'intende" posso raccomandare, o anche procurare (col
mio margine di profitto, ovvio: devo pur campare...!-) marche e modelli.
I _cosiddetti_ "firewall HW" sono sempre dei computer con su un sistema
operativo e un software di firewall, comunque.  I vantaggi di OpenBSD in
questo tipo di applicazioni sono semplicemente troppi, a mio parere (e
per fortuna non solo mio;-).  Cisco e` una ditta seria ed e` probabile
che ci si possa fidare alla cieca (e cosi` bisogna fare perche` i
sorgenti, da fare esaminare dal tuo preferito consulente sicurezza, non
te li fanno vedere;-).  Ma alla probabilita`, e alla fiducia a scatola
chiusa, io personalmente (e riesco di solito a convincere i clienti!)
preferisco la sicurezza e la tranquillita` di una soluzione i cui
sorgenti _sono_ stati esaminati e rigirati da _tanti_ esperti per
rimuovere ogni vulnerabilita`.
L'insistenza su "FW HW" non e` assurda: il concetto di "firewall" (ha!)
che girano sulla macchina stessa che proteggono e` assai piu` debole di
quello di una macchina dedicata a fare da firewall per l'intera
LAN/WLAN, con schede separate e praticamente nessun altro compito (c'e`
una piccola gamma di servizi che si possono ragionevolmente far
risiedere sulla stessa macchina senza danni, ma se non hai un esperto a
spiegarti quali e come e` meglio niente che non correre rischi).  Sono
contento di avere di sistema un FW decente sul mio iBook, perche` lo
porto tanto in giro, e troppe volte devo connettermi a WLAN i cui
livelli di protezione sono incogniti e probabilmente scarsi.  Ma,
potendo, non lo uso INVECE di un'adeguata protezione della WLAN/LAN
tutta.  (Si possono poi fare anche architetture piu` paranoiche, ma
pochi clienti sono davvero interessati, e non e` che abbiano tutti i
torti).
Ma le implementazioni di FW sono tutte in SW.  L'importante e` che sia
software buono e giri su di una macchina dedicata allo scopo, con un SO
solidissimo, fatto da paranoici che mettono la sicurezza al primo,
secondo E terzo posto di classifica, sacrificando qualsivoglia richiesta
di features e supporti vari assortiti.  OpenBSD e` appunto questo...
Alex

 da ogni punto di vista.
Post lockato!
-- 
http://www.dorelli.com
 - AIM: danmagma
In the shadow of the cargoes I take you one time
And we're counting all the numbers down to the waterline.

 un comune cavo ethernet?
Se son vicini un bel cavo ethernet o firewire è la scelta migliore.
Alex

 mio margine di profitto, ovvio: devo pur campare...!-) marche e modelli.
Come firewall per usi "seri" mi sento di sconsigliare l'uso dell'ipfirewall 
embedded nei vari so BSD-like. Per quanto abbiano aggiunto le rule dinamiche 
non si tratta di una piena statefull inspection. Ad esempio non č possibile 
modellare con le dynamic rule uno scenario tipico di VOIP in cui la'pertura 
delle porte per gli stream RTP deve essere dinamica e conseguente allo 
scambio della segnalazione.
Alex

 wrote:

Per SIP ed RTP, in situazioni ad alto rischio, ci puo` volere un
firewall con supporto diretto, ad esempio con un session control proxy,
e che io sappia per pf a oggi non ne e` ancora stato scritto uno (o
almeno non open source).  Ma la stateful (con una L sola) inspection
c'e` tutta, questo non significa che sia incorporata in pf la conoscenza
di ogni possibile protocollo, che va invece delegata, modularmente, a
proxy appositi.  Se a qualcuno, ad esempio un'azienda che produce
firewall basati su OpenBSD, interessa finanziare lo sviluppo di un SCP
del genere, io qui sto (da negoziare, oltre al costo e i tempi, le
possibilita` di rilascio opensource e dopo quanto tempo di "esclusiva"
per il committente); non avendola io come esigenza personale e
specifica, non mi metto certo a svilupparlo (lavoro non banale) gratis
et amore.  E come me tanti altri magari anche piu` bravi di me (almeno
in questo campo specifico).  In generale i BSD open source vanno avanti
in questo modo (Darwin e` un po' un'eccezione), "per commesse".
Se un release GPL fosse accettabile, si puo` ridurre il costo di
sviluppo lavorando per adattare prodotti esistenti (per altri firewall
free o open source) come siproxd (mai esaminato a fondo, non avendo
appunto avuto esigenze specifiche e personali, ma sarebbe interessante).
Comunque non mi pare che la situazione sia "intercambiabile", come
sembri indicare, fra IPFW (che pare sia quello che intendi tu), pf, e
ipf.  Al di la` della somiglianza dei nomi e di qualche aspetto della
sintassi delle regole, gli internals sono piuttosto diversi...
Alex

 sintassi delle regole, gli internals sono piuttosto diversi...
Se ipfw è un po complicato da configurare, ipf è un vero incubo! :(
Alex

 Se ipfw è un po complicato da configurare, ipf è un vero incubo! :(
Mai provato pf?  Nell'attuale OpenBSD 3.6 (data ufficiale di rilascio 1
Novembre, ma stanno gia` spedendo i CD a chi li ordina), pfctl ha anche
un ottimizzatore che ti permette di scrivere le regole di filtraggio in
modo piu` "rilassato" e provvede a riordinarle, combinarle in tabelle,
ecc, per migliorare le prestazioni (ovviamente la cosa e` importante
solo per una macchina che filtra un traffico enorme, ma nel parco di
utenti di OpenBSD di usi del genere non ne mancano certo).
Alex
 

 utenti di OpenBSD di usi del genere non ne mancano certo).
Sempre complesse da scrivere sono...
Alex

 Sempre complesse da scrivere sono...
Ma quando mai?  Noto che non rispondi alla domanda quindi immagino che
la risposta sia no, mai usato pf; e per conto mio non ho mai usato alcun
prodotto Checkpoint (l'ho visto usare dagli amici sysadm, ma in una fase
della mia vita in cui mi occupavo solo di sviluppo sw, non di
amministrazione di reti; ma di moccoli glie ne ho sentiti tirare...),
quindi facciamo pari e non abbiamo una vera base per il dibattito.
Peraltro, il concetto di _dovere_ usare una GUI per configurare un
firewall, senza avere accesso diretto al db delle regole, mi disgusta (o
l'hanno finalmene cambiata, 'sta limitazione del [expletive deleted]?!).
Alex

 l'hanno finalmene cambiata, 'sta limitazione del [expletive deleted]?!).
La GUI in cp puoi usarla o meno. La cosa figa di cp sono gli strumenti di 
engineering e distribuzione delle regole. Gestire e configurare un solo fw 
che fa da border element può essere relativamente banale. Gestire un gruppo 
di fw complesso e distribuito all'interno di una rete complessa è tutta 
un'altra cosa.
Alex

 le policy (potenza e semplicità van raramente d'accordo).
A me piacciono, invece, proprio le tecnologie che congiungono le due
cose, come Python, il Mac, e OpenBSD...!-)
Alex

 cose, come Python, il Mac, e OpenBSD...!-)
Peccato che spesso la semplicità è solo il risultato di una mancanza di 
feature!
Alex

 feature!
Per fortuna che invece in tutti i casi che ho elencato non e` cosi`.
Raramente, nella tecnologia attuale, la semplicita` viene da una
mancanza di feature _utili_.  Come a suo tempo nella battaglia fra
TCP/IP e ISO/OSI, spesso hai da una parte un progetto accuratamente
calibrato e studiato, dall'altra moby dick.  Quando votano (col
portafogli) i sempliciotti, come nella battaglia fra Windows e Mac,
capita spesso che vinca il peggiore -- il robazzo ridondante con
millanta feechurz che nessuno usa mai, e altrettanti bachi e falle di
sicurezza.  Quando le decisioni importanti le prende invece gente che ci
capisce qualcosa, le prospettive sono molto meno bieche.
Alex

 capisce qualcosa, le prospettive sono molto meno bieche.
Non va confusa la potenza con la potenzialità. Il C ha una potenza maggiore 
dell'assembler in quanto permette di implementare task più complessi con un 
effort minore da parte dello sviluppatore. Questa capacità è stata aggiunta 
dagli sviluppatori del linguaggio. L'assembler ha un potenziale maggiore del 
C (alcuni algoritmi a bassissimo livello non sono implementabili in C) ma è 
poco potente in quanto un task banale richiede un grandissimo effort da 
parte dello sviluppatore. Chiaramente un assemblatore richiede un effort 
enormemente minore da parte dello sviluppatore dell'assemblatore. Lo stesso 
discorso si applica nel paragone win/unix. Hanno potenziali simili, ma 
potenza diversa. Con tutto ciò che comporta. La scelta tra l'uno e l'altro 
dipende solo da dalla situazione.
Alex