[PLUTO-security] Squid e trasparent proxy...

[Andrea Dinale]

Alle 14:21, mercoledì 30 luglio 2003, Fabio Panigatti ha scritto:
> > Ciao Maestro!
>
> Piantala3 :-)

lo sapevo che rispondevi cosi :-P

> Mi autoquoto da icsv:

Mi sono letto tutto il thread, come al solito chiaro ed esplicativo.

Questo e` l'URLo per chi lo volesse leggere
http://www.google.it/groups?hl=it&lr=&ie=UTF-8&oe=UTF-8&threadm=MPG.1985e694b4f5328b989fe2%40powernews.libero.it&rnum=1&prev=/groups%3Fq%3D%2B%2522Durante%2Bil%2Bbrowsing%2Bdel%2Bweb%2Bcapita%2Bmolto%2Bspesso%2B%2522%2Bgroup:it.comp.sicurezza.varie%26hl%3Dit%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3DMPG.1985e694b4f5328b989fe2%2540powernews.libero.it%26rnum%3D1

> necessaria, ma la cosa diventa complicata e la configurazione
> automatica del client con proxy.pac e' meno onerosa IMHO.

Ok, il proxy.pac lo conosco solo di nome e di fama, ma non ho mai visto 
una sua implementazione. 
Vabbe'... echo "documentarsi su proxy.pac" > to-do
(vedi che l'ho letto davvero il thread :-)

Ma il metodo proxy.pac e` completamente "trasparente" come il proxy 
trasparente??? (che schifo di frase).
Cioe' e' il client che deve richiedere al webserver la pagina proxy.pac, 
e dopo puo` cominciare a navigare, giusto?

> Se invece lo scopo e' solo la riduzione del traffico sulla
> connessione all'isp il proxy trasparente e' comodo, perche' senza
> toccare i client (che uscirebbero comunque con il routing) riesci a
> fare il caching della maggior parte del traffico (almeno quello su
> 80/tcp e 443/tcp).

si, questa e` la soluzione che sto cercando (per adesso), infatti il 
traffico in uscita e` regolato da netfilter. Non e` ancora una 
soluzione ottimale, infatti (come hai fatto notare) un malware sarebbe 
cmq in grado di uscire su internet usando la porta 80.
Tieni conto che fino a ieri il proxy non c'era.

> Se fai REDIRECT funziona...

si, ora e` tutto chiaro, non avevo letto bene il post iniziale e non mi 
sono accorto che parlava di DNAT e non di REDIRECT :-(

> >intendi il traffico "di ritorno"? non ho capito molto bene.
>
> Si, il traffico di ritorno: se <ip client> tenta di connettersi a un
[CUT]
Chiarissimo, non potevo sperare in una spiegazione migliore!

> stati sostituiti gli header con quelli corretti. Un possibile
> workaround puo' essere quello di usare una netmask a 32 bit sul
> proxy: in questo modo tutto il traffico ripassera' comunque dal
> default gateway (si presume che sia il firewall, in questo caso) e
> dovrebbe essere reinstradato al client con gli header corretti (non
> l'ho mai provato ma dovrebbe andare). Se no... SNAT, ma si perde
> l'informazione su quale ip ha visto quale sito.

ma se setti una netmask a 32 bit riesce a raggiungere il defalt gateway? 
In teoria anche il gateway dovrebbe essere fuori dalla sua subnet e 
nemmeno pingabile, giusto?

ciao
Andrea