Newsgroup: it.comp.reti.locali
Titolo: Proxy e posta

Salve a tutti.
Domanda forse banale, ma ho gugolato un bel po' e ho le idee ancora 
confuse...
Vorrei implementare, in una LAN, un sistema per cui solo un computer 
(con Linux) abbia accesso diretto a Internet, sia per HTTP(S) che FTP, 
POP (forse non indispensabile), SMTP e qualsiasi altra cosa, e tutti gli 
altri possano accedere a Internet solo tramite lui, con autenticazione 
(sul dominio), qualche limitazione e registrazione completa delle 
attività (previa comunicazione agli interessati ecc. ecc. per la 
privacy).
Ok. Router impostato per far passare solo la macchina proxy, e per 
HTTP(S) ed FTP tutto ok: squid, acl opportune, autenticazione ntlm.
...ma per la posta?
In generale leggo che è necessario un proxy che supporti SOCKS... ma 
quale? Su Debian Sarge vedo solo un socks4-server... e socks 5?
E poi avrà le stesse possibilità di squid per log ed eventuali 
limitazioni, come limiti sulla dimensione dei trasferimenti o diverse 
impostazioni da utente a utente, con autenticazione sul dominio?
Da quanto leggo su 
www.socks.nec.com
, SOCKS v5 sembrerebbe quasi adatto 
per tutte le mie necessità. Ma ne esiste un'implementazione open? 
Cercando in rete ho trovato SS5, ma qualcosa di bello pronto 
impacchettato e testato su Sarge?
Altrove ho letto il suggerimento di usare un mailserver locale 
attraverso il quale far passare la posta, ma non so quanto sia pratico 
nel mio caso...
Infine da qualche parte ho letto anche che per la posta basta un proxy 
che supporti il metodo CONNECT... squid lo supporta, ma non mi pare che 
sia sufficiente... o sì?
Grazie per eventuali info. Spero di aver ben esplicitato la mia 
confusione. %-)
-- 
Ciao,
  Marco.

 impacchettato e testato su Sarge?
Vedi il dante
Non quoto e non rispondo al resto ma ti faccio un paio di considerazioni 
sull'architettura che disegni.
I socks proxy sono abbastanza una pigna. C'è stato un periodo in cui 
pareva dovessero essere la soluzione a tutto, poi pian pianino son stati 
accantonati: andarsi a configurare ogni client (ammesso che tutti quelli 
necessari lo supportino) per usare un socks proxy con autenticazione non 
è molto comodo. Io personalmente li sopporto poco (ma è gusto personale, 
eh..)
Nelle situazioni simili alla tua, l'approccio che va per la maggiore 
attualmente è piuttosto diverso: un captive portal per l'autenticazione 
dell'utente (se vuoi autenticare su utenze di dominio, una cosa molto 
comoda è abilitare IAS su un server Win e andare a validare le 
autenticazioni con un banale client radius, senza impaciugarsi con samba).
Il firewall/proxy che usa iptables (partendo dal presupposto che sia 
linux, ma nulla ti vieta di fare altrettanto su altre architetture) per 
tenere tutto chiuso a tutti come default.
Quando un utente si autentica con successo sul captive portal, si 
provvedere a inserire nel ruleset delle regole che lascino accesso alle 
risorse necessarie per le comunicazioni provenienti dalla coppia 
IP/MAC_address usata dall'utente autenticante.
Periodicamente, vengono rimosse dal ruleset le abilitazioni "vetuste" 
(come stabilire quando siano tali è altro discorso...).
A questo punto, la veicolazione del traffico verso l'esterno può essere 
"costretta" a passare attraverso transparent proxy generici 
per-protocollo (senza necessità che questi supportino alcuna 
configurazione esotica) per poter loggare quello che ti pare, o per 
imporre policy/ACL/content-filtering o tutto quello che ti aggrada...

 IP/MAC_address usata dall'utente autenticante.
già che ci siamo, sarebbe un'ottima idea implementare un mailserver
interno che si preoccupi di scaricare/inviare la posta e bloccare l'accesso
dei client verso servers esterni, quantomeno servers SMTP/IMAP in modo
da "limitare i danni" nei casi in cui una o più macchine della LAN venissero
infettate da "spamming worms"
Ciao

 imporre policy/ACL/content-filtering o tutto quello che ti aggrada...
Ma se l'autenticazione avviene prima, sul captive portal, come fa poi il 
proxy ad applicare ACL o registrare le informazioni sui singoli utenti 
nei log? Voglio dire, nell'idea di partenza è lo stesso squid a fare sia 
autenticazione che log, e quindi ha le informazioni necessarie, ma in 
questo caso?
-- 
Ciao,
  Marco.

 infettate da "spamming worms"
Hmm... premettendo che la questione della posta è ancora molto da 
decidere, quindi non so bene di cosa avrò bisogno... se si volesse 
permettere agli utenti di accedere via POP alle proprie caselle private 
(Libero, Tiscali... cosa che forse non si farà, ma intanto ci penso), 
non sarebbe un po' complicato (non solo per gli aspetti pratici) farlo 
tramite mailserver interno?
Per quanto riguarda la protezione da spamming worms, se questi ultimi 
usassero l'SMTP impostato nel client di posta, non sarebbe la stessa 
cosa usare un SMTP interno o esterno? A parte l'eventuale possibilità di 
rilevare in automatico eventuali attività SMTP anomale... forse è questo 
il vantaggio?
Grazie a entrambi.
-- 
Ciao,
  Marco.

 questo caso?
In questo caso lui non ne sa nulla (d'altra parte, non puoi usare squid 
come transparent proxy e fargli autenticare tutto insieme) ma hai la 
disponibilità dei dati necessari a correlare gli accessi incrociando i 
log dei proxy con quelli dell'autenticatore.
Ovviamente, la cosa ha dei limiti, nella misura in cui non puoi 
applicare ACL diverse per-user, ad esempio.
Uno scamuffo per questo caso è usare ACL per-group, e avere istanze 
diverse del proxy in ascolto su porte diverse, selezionando in fase di 
autenticazione dove effettuare redirection dell'utente. E' sporca, ma 
funziona...

 tramite mailserver interno?
Beh.. tutto dipende da come volete organizzare la cosa, avere un server
centralizzato ti permetterebbe di mettere in piedi filtraggi
antivirus/antispam
eliminando così parecchia "robaccia" dalla mail in ingresso, inoltre, per
quanto riguarda SMTP, è vero che beccando un worm quest'ultimo potrebbe
tentare di usare il server interno per l'invio, ma è anche vero che
abilitando
la scansione ANCHE delle e-mail in uscita riuscirai a "tappare" parecchie
falle ed evitare diversi problemi
Ciao

 funziona...
Hm, la cosa si complica, accidenti... mi aspettano lunghe giornate di 
studio e prove.
Grazie delle indicazioni.
-- 
Ciao,
  Marco.

 sufficiente implementare radius (c'è, c'è :-D) e configurare m0n0 all'uopo
Ehm... sarò duro di comprendonio, ma... che m0n0wall supporti radius ok, 
l'avevo letto, però radius "c'è" in un dominio windows in che senso? Io 
parlo di Samba, che non mi sembra integri di suo il supporto per 
radius... quindi immagino di dover inserire nel mezzo un server radius 
(freeradius?), che per l'autenticazione si appoggi al backend di 
autenticazione configurato in Samba in qualche modo, forse tramite 
plugin.
È questo che intendevi?
Grazie.
-- 
Ciao,
  Marco.