Newsgroup: it.comp.os.linux.sys
Titolo: [OT] sicurezza

salve ragazzi...
...gentilmente un consiglio...
vorrei mettere on-line un web server; per quanto concerne la 'sicurezza'
(...senza spendere cifre 'esagerate'!)cosa mi consigliereste:
- router/firewall commerciali
( ad es: "Digicom Michelangelo pro VPN", US Robotics adsl+switch 4p,...)
- pc 'reciclato' con s.o. Linux 'opportunamente' configurato
  (...ad es. utilizzando 'Smoothwall')
Ringrazio chi vorrà darmi qualche consiglio
(magari motivandolo!)...
Lucio
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 ...gentilmente un consiglio...
Gia` considerato Engarde ?
www.engardelinux.com
-- 
SpeedTech
ing. Roberto Gerola
Email : roberto_dot_gerola_at_speedtech_dot_it
WWW : 
http://www.speedtech.it

 produzione, un disco fisso da 1GB vecchio di 10 anni.
Ed uno di 2 Gb vecchio di 5 ?
Davide
-- 
| The Information Revolution will be fought on the command line.      --
| From a Slashdot.org post 
| 
| 

   (...ad es. utilizzando 'Smoothwall')
Scusa, ma se deve essere solo un webserver, perchè non limitarsi a
configurarlo come bastion e fargli fare da "firewall" per se stesso?
La maggior parte delle mie macchine un firewall manco lo ha: quello che
non serve si toglie, quello che rimane lo si wrappa via hosts.allow...
Iptables lo si mette solo liddove i daemon utilizzati non permettono
granularità di questo genere...
Non è che il fatto di avere "il firewall davanti" sia di per sè garanzia
di maggiore sicurezza...
-- 
the Skull says:
+---------------------------------------------------------------------+
 We are Pentium of Borg. Division is futile. You will be approximated.

 Ed uno di 2 Gb vecchio di 5 ?
... ed uno di 4Gb vecchio di 2,5 ? :)
Vabbč... il concetto era chiaro, no ?


 granularità di questo genere...
GRANDEEEE
Finalmente uno che la pensa come me!!!!
A che pro' mettere una macchina con 10000 porte aperte e poi impazzirsi a
filtrarle con un firewall? Non si aprono e basta.
E poi un firewall copre solo una parte dei problemi legati alla sicurezza.
Se io ho un webserver il firewall non deve chiudermi il traffico http
ovviamente, e se sono un webmaster che scrive cgi da cani il firewall cosa
puo' farci?

 E poi un firewall copre solo una parte dei problemi legati alla sicurezza.
Non solo. Non e` raro che introducano falsi sensi di sicurezza (tanto
c'e` il firewall!).
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Any sufficiently advanced technology is indistinguishable from magic.

 filtrarle con un firewall? Non si aprono e basta.
... e se da DENTRO la lan volessi avere qualche servizio in più ?
Se sviluppassi, che so, con Homesite da win e preferissi uploadare con 
samba ?
Questione opinabile, certo, ma io preferisco nattare con iptables.
OVVIAMENTE questo NON serve a rimediare le falle causate dai CGI fatti 
col c..o, ma mi permette di essere più rilassato con i servizi aperti 
sulle singole macchine e fare packet filtering una volta per tutte, nel 
luogo dove ha più senso farlo (IMHO).


 ... e se da DENTRO la lan volessi avere qualche servizio in più ?
Faresti bene a valutare una macchina dedicata.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
In God we trust. (All others pay cash.)

 Faresti bene a valutare una macchina dedicata.
In che senso ?


 In che senso ?
Che e` una pessima idea quella che hai proposto. O quantomeno, un modo
per cercarsi dei guai. Un server di LAN, deve stare in LAN. Un server
internet, deve stare in internet.
Se hai bisogno di ambedue le cose, dovresti valutare due server.


 Se hai bisogno di ambedue le cose, dovresti valutare due server.
Certo è la soluzione migliore, ma:
Non in tutti gli ambienti è giustificato l'acquisto di due server.
Esiste il concetto di DMZ (e ancora una volta, serve iptables a monte)
:)


 
Mi pare giusto, anche io di solito i serverini tipo 
'il-cliente-si-puo'-connettere-per-vedere-lo-stato-del-suo-ordine' li configuro 
cosi'. Mi sembra un sistema veloce, abbastanza sicuro ed economico, buono anche 
per webservers con poco traffico.
RRb sohe.

 ... e se da DENTRO la lan volessi avere qualche servizio in più ?
A parte che e' una pessima idea... ma se proprio vuoi farlo il discorso e'
sempre lo stesso.... chi cavolo ti obbliga ad aprire samba a tutto il mondo?
I parametri host allow e host deny da mettere niei globali dentro smb.con
non ti dicono nulla?
Ciao.

 non ti dicono nulla?
Oh, beh, sono già opportunamente settati se è per questo.
Ma se ciò che faccio io è una pessima idea, quello che mi stai 
proponendo è ancora peggio:
1. Il mondo SAPREBBE che c'e' samba, lì, e non ne vedo il motivo.
2. Se PER CASO faccio casino con smb.conf, non succede niente (non sono 
solito fare casino, e ad oggi ho un tasso di "incidenti" pari a zero, ma 
non ho nemmeno la presunzione di non poter sbagliare mai).
Se il tuo problema riguarda il fatto che chi bucasse il server si 
trovasse in lan, il problema si risolve mettendo il server in DMZ, dove 
la lan non viene manco vista.
Così la LAN è al riparo, e per quanto riguarda la macchina stessa 
nessuno ti impedisce di chrootare apache, se lo ritieni necessario.
La securiry per come la vedo io non è un fatto ASSOLUTO, ma un 
compromesso che va tarato in base alle esigenze e alle strutture che ci 
sono, caso per caso.
Ovviamente, tutto IMHO. :)


...approfitto per ringraziare tutti
per l'interessamento!!


 proponendo è ancora peggio:
Ooops,
credo che il 3d stia prendendo una brutta piega, sembra quasi un flame... e
allora voglio precisare.
Io non sto dicendo assolutamente che l'utilizzo di un firewall e' stupido o
inutile.
Sto solo dicendo che in alcuni "contesti" puo' essere superfluo.
Ora il "contesto" e' quello giusto per prospettare una soluzione che puo'
andar bene "anche" senza firewall. L'idea era giustificata semplicemente
dalla richiesta:
web_server + fattore_economico = webserver_senza_porte_inutili_aperte.
E' chiaro che se poi sul server e' necessario mettere altra roba che deve
essere fruibile "solo dalla lan" il firewalling esterno diventa
necessario... ma non troppo dato che alcuni servizi si possono mettere in
sicurezza egregiamente senza firewall.
Per esempio potrei evitare di filtrare l'ssh se uso opportunamente gli
host.deny e allow.
Ma non sto negando (sarei stupido se lo facessi) che comunque un firewall
aumenta sicuramente il livello di sicurezza, mettendoti al riparo da errori
come quelli che tu giustamente indicavi.... ma poi... scusa non hai mai
visto un firewall configurato male? In fondo siamo sempre noi che mettiamo
le mani in smb.conf a configurare sto firewall no? ^__^
Ciao.

 allora voglio precisare.
[..]
Non era mia intenzione aprire flames ! E' solo che mi diverte discutere 
un po' animatamente, in effetti spesso uso toni un po' "provocatori"...
L'uso delle -> :-) intendeva sottolineare il fatto che, cmq, non 
intendevo offendere nè tantomeno creare flames... semmai "punzecchiare" 
un po' ... :)
Cmq sia tu sia Maurizio avete scritto cose certamente sensate, volevo 
solo proporre un altro "punto di vista".


 Esiste il concetto di DMZ (e ancora una volta, serve iptables a monte)
Temo che non ti sia ben chiaro il concetto di dmz, sai.
Esso, _semplificando molto_ e`:
permissive-firewall
internet servers (questa e` la dmz)
restrictive firewall
LAN (e lan servers)
Ed e` _fisicamente_ separata dalla lan, altrimenti non e` una dmz, e`
una fesseria.
L'idea e` che se ti ownano la macchina esposta, non sono ancora in lan e
magari nemmeno entrano.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Paranoia is a survival asset.

 samba ?
va a zappare, che è meglio.

 non ho nemmeno la presunzione di non poter sbagliare mai).
idem

 Questione opinabile, certo, ma io preferisco nattare con iptables.
Ok, ma allora non hai più un "webserver a cui apri solo la porta 80"...
In questo caso ha un senso (posto che iptables anche in questo caso ha
la stessa efficacia a girare sulla macchina stessa), ma non se ne
parla...


 non ho nemmeno la presunzione di non poter sbagliare mai).
E` proprio qui che ti sbagli. Permettere accesso da internet e` di per
se, un "punto debole". Non hai garanzie che non si riesca a farne un uso
improprio.
I primi esempi che mi vengono in mente, e che non partono dal
presupposto di codice buggato (ne in apache, ne in cgi/php/whatever),
sono:
tunnel/incapsulamenti ip-over-http
firewall piercing
implementazioni tpc/ip over http (tipo questa:
http://www-2.cs.cmu.edu/~fox/foxnet.html
)
uso improprio di qualche modulo a run-time di apache (mod_proxy su
tutti)
E altro ancora.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Confidence is the feeling you have before you understand the situation.

 bindi il servizio solo sull'interfaccia interna.
Non e` un ideona, eh.
Ragazzi, dmz non significa che i server hanno due interfacce: una con ip
pub, e una con ip privato. Questo e` un fantastico modo per farsi aprire
come una cozza.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Vote Cthulhu. Why choose the lesser evil?

 LAN (e lan servers)
preferisco molto due segmenti ethernet disgiunti, uniti solo per il proxy,
il quale non mostra nessuna porta all'esterno, se non l'ssh su richiesta
per l'amministrazione remota. sulla lan non c'è gw, se vuoi uscire devi
passare per il proxy, il quale provvede a castrare gli utenti.
Il firewall prima del proxy non mi serve, non ho nulla da chiudere. Chi
obietta che col firewall ci si para il culo da eventuali backdoor
installate che attivano servizi indesiderati non tiene conto che comunque
quando viene installata la backdoor si ha già subito l'esecuzione di
codice indesiderato, quindi comunque lo si è già preso in culo.
Un analogo discorso si fare per i server sul segmento pubblico. Firewall?
solo se non c'è altro modo più furbo per chiudere le porte.

 tutti)
aspetta che prendano piede le applicazioni serializzate in xml.
Poi si ride (per non piangere).

Sgranocchiando il cranio di Ottavio Campana, vi trovai inciso:

Occhio che, almeno nella mia accezione,
"firewall" != "router con packet filter"
Puoi fare degli ottimi firewall con iptables, ma nulla ti vieta di farli
con application proxy, transparent o no...
Nel tuo schema, quindi, il proxy dual homed non è "la risorsa da
proteggere", ma il "firewall" stesso...
PS: Approposito di transparent proxy, qualcuno ha fatto prove con zorp,
dei presenti?
Uno skull che quell'articolo di 'sto mese su LJ...


 va a zappare, che č meglio.
... ma LOL ! Argomentazioni un po' piů ... come dire ... fondate ?


 
http://www-2.cs.cmu.edu/~fox/foxnet.html
)
-> vado a leggermelo.


 una fesseria.
Vediamo... la separazione FISICA non la vedo.
Puoi, comunque, dare tre interfacce di rete al primo router/firewall e 
creare una dmz da lě (configurando opportunamente 
NAT/routing/portforwarding).
internet ---- FW ---- LAN
                |
                '----- DMZ
Ora, tu potrai storcere il naso sostenendo che chi "ownasse" il mio FW 
farebbe quello che vuole. Certamente, ma la cosa accadrebbe ugualmente 
se qualcuno bucasse il tuo "restrictive firewall".


 ... ma LOL ! Argomentazioni un po' piů ... come dire ... fondate ?
avere un servizio attivo smb su un server pubblico č una soluzione
orrenda, considerando il fatto che tutti gli ide di sviluppo web hanno
almeno un client ftp integrato.

 
non è una soluzione furba rispetto a quella di mizio, perché il tuo
firewall in questo modo deve dare, per essere a parità di servizio, tutte
le libertà di quello permissivo più quelle del restrittivo. Quindi è
più vulnerabile.

 più vulnerabile.
Su questo non c'e' dubbio, non fosse altro che per il fatto di doverne 
bucare DUE. Ma non vedo, sinceramente, questo ABISSO di differenza. Non 
nego che ci sia una differenza... ma non è un ABISSO di differenza, imho.


 perché?
Perche` io che vengo dall'esterno, se posso "ownare" la macchina, ed ho
_anche_ un interfaccia collegata al filo interno, poco mi importa di
come l'hai configurata.
ifconfig lo so fare.
E a quel punto, anziche` il webserver (perdire), mi prendo tutta la
rete, file della contabilita` compresi (sempre per dire).
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Computers are not intelligent.  They only think they are.

 se qualcuno bucasse il tuo "restrictive firewall".
Non si tratta di "storcere" il naso. E` una questione di "probabilita`"
e Sforzo.
Ed e` piu` probabile che costi di piu` in termini di risorse e sforzo,
(e che non passi inosservato il tentativo), farsi una macchina che non
due.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------


 -> vado a leggermelo.
Dai una lettura al firewall-piercing-howto per farti un'idea di "la
porta A e` chiusa ma la B e` aperta e mi serve la A".
E non e` l'unico modo (sempre in assenza di bug qui e la, che sai quanto
me, e` un ipotesi su cui non puoi scommettere piu` di tanto).
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------


 come l'hai configurata.
ma se tu non ci puoi entrare nella macchina perché non ha porte aperte il
tuo discorso si schianta subito.
Ripensa a quello che ho scritto da un'altra parte: due segmenti disgiunti,
uno con server con ip pubblici, uno con la lan e con collante tra le due
un proxy, che permette ai client di uscire per i servizi abilitati e che
non offre _nessun_ servizio all'esterno (sempre con la variante dell'ssh).
posso casomai subire un dos perché mi floodi di merda, posso subire un
ping of death che fotte la macchina, ma da dove cavolo passi se è tutto
chiuso?

 Ripensa a quello che ho scritto da un'altra parte: due segmenti disgiunti,
Definisci "segmenti digiunti". Ma se stiamo parlando di un'altro caso,
specifica pure quello.
Se cmq, segmenti disgiunti, non e` a livello di "filo", ti avviso che
l'ultima analisi che ho fatto, trattava proprio di questo. Owned di un
server pubblico, e il piu` banale degli ifconfig eth0:0 192.168.1.123 up
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
question = ( to ) ? be : ! be;  -- Wm. Shakespeare

 specifica pure quello.
due segmenti di ethernet sono disgiunti se i segnali elettrici del primo
non possono andare nel secondo e viceversa. Questo è l'unico per mettersi
sicuramente al riparo da sniffing e altre porcate per esempio con l'arp.
Se il segmento pubblico comprende router, server pubblici e cavi e switch
e cavi che li interconnetono e nel secondo metti computer, server switch e
cavi della rete aziendale i dati dell'uno non possono andare nell'altro
(topologicamente parlando il grafo non è connesso).
Se in mezzo tra i due pezzi giunti ci metti un proxy con due schede e gli
dici che il proxy deve bindarsi solo sulla interfaccia della rete interna
ottieni che la lan esce ma nessuno gli può entrare, perché non c'è
connessione diretta e l'unica soluzione sarebbe attaccare il proxy, il
quale però non ha porte aperte sul segmento pubblico. fine. (e il grafo
che modella la rete ancora non è connesso, ma permette agli utenti di
svolgere il loro lavoro)
fine... beh, insomma, c'è il discorso delle applicazioni serializzate in
xml, che diventerà una tragedia se mai dovessero prendere piede, ma
questo è un altro discorso.
Questa soluzione è comunque espandibile, perché se uno vuole caricare i
dai attraverso smb su un webserver è possibile creare una seconda
sottorete interna, digiunta dagli altri due segmenti dove uno va lì col
suo portatile, si attacca al server smb interno e carica. E all'esterno il
servizio smb non viene erogato.
Insomma, per fare uno schemetto:
                 rete pubblica
----------------------------------------
    |                             |
+--------+                    +-------+
| apache | .....              | proxy |
+--------+                    +-------+
    |                             |
---------------                ---------------
    |                             |
rete di upload                   lan aziendale
sui server
il server apache può andare giù per errori di programmazione delle
applicazioni o per altri errori, ma il proxy non eroga servizi sulla rete
pubblica, non può essere sfondato. Ed è propio questo che ti dicevo
quando scrivevo che non sono daccordo sul dire che fare il binding delle
applicazioni su solo alcune interfacce, non puoi fare l'ifconfig.

 deputato al filtering.
Occorre appunto che il kernel di quella macchina abbia un exploit. Ma in
questo caso, non esiste sicurezza che ti possa garantire quella
macchina.
-- 
Massimo Bacilieri AKA Crononauta 
ICQ:4005815

 deputato al filtering.
sul proxy non ho packet filtering perché è già tutto chiuso.
Se mi arrivasse un ping of death la macchina andrebbe giù e la
conseguenza immediata sarebbe l'isolamento della lan (che a dire il vero
è positivo).

 Insomma, per fare uno schemetto:
Ottavio, tu sai che ti sono amico: ti pare lo stesso caso in
discussione?
Il caso che hai presentato e` senz'altro un'ottima implementazione.
Ma e` ben lontano dal problema esposto.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Microsoft - Just say No.

 discussione?
ma scusa, il discorso è nato da: "bindi il servizio sulle sole interfacce
che ti serovono", e tu mi hai detto che era una fesseria. Invece quello
voglio dire è che imho non sembre binadre i servizi solo dalla parte
utile è una vaccata.
tutto qua.
la rete proposta da cujo imho è orrenda. io non implementerò mai reti
così perché ci si incasina e basta.

 utile è una vaccata.
Si, ma il presupposto e` "la macchina offre servizi". Un proxy, un
firewall, un router, non mi sento di definirla "macchina che offre
servizi".
L'affermazione e` letta in quel senso.
E` evidente che su un router ho due interfacce (per esempio) e ognuna
vede un pezzo di rete. E` il suo compito.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
There is no substitute for good manners, except, perhaps, fast reflexes.

> filtrarle con un firewall? Non si aprono e basta.
intendi dire che metti solo i servizi che ti servono e niente di piu'?

 intendi dire che metti solo i servizi che ti servono e niente di piu'?
Certamente!

 la rete proposta da cujo imho č orrenda.
... se ti metto su una "rete orrenda" ad hoc, mi mostri ciň che riesci a 
combinare ?


 combinare ?
il design delle  rete č brutto. Puň tenere botta adesso, ma se in futuro
ti esce un exploit e non fai in tempo a tapparlo sei terribilmente
vulnerabile.

 Paranoia is a survival asset.

 Non bastano 3 schede di rete?
Il problema non e` la scheda di rete, ma il _filo_.
ps:
Per cortesia, leggi 
http://learn.to/edit_messages
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
