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

[Fabio Panigatti]

> Ciao Maestro!

Piantala3 :-)

> Per quali motivi non ti piace il trasparent proxy? sicurezza? 
> affidabilita? etica?
> Trovo che sia molto comodo inserire un proxy in una rete e non dover 
> configurare alcun client, ma se il gioco non vale le candela e` meglio 
> non farlo :-)

Mi autoquoto da icsv:

<< Durante il browsing del web capita molto spesso d'incappare in GET
   che puntano a porte diverse dalla 80. Non funzionerebbe l'ftp via
   browser. I malware che non saprebbero scoprire da se il proxy http 
   per uscire dalla rete se lo trovano servito su un piatto d'argento >>

Se lo scopo e' la sicurezza (vedi subject) a mio parere quella del proxy 
trasparente e' una soluzione quanto meno incompleta, perche' di fatto
obbliga a aprire comunque il routing (con eventuale nat) verso internet,
se si vuole mantenere la piena raggiungibilita' delle risorse. Ovviamente 
si puo' fare un redirect per ogni porta necessaria, ma la cosa diventa 
complicata e la configurazione automatica del client con proxy.pac e'
meno onerosa IMHO.

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).

> per prova, nel mio server[ino] domestico, ho installato squid, ho 
> aggiunto le quattro direttive httpd_accel_* nello squid.conf ed ho 
> inserito una regola che fa il redirect della porta da 80 a 3128.
> e tutto funziona.

Se fai REDIRECT funziona...

> > Mi sono dimenticato un pezzo: il problema e' che il server squid vede
> > che <ip client> e' nella sua stessa subnet e, quindi, tenta di
> > inviare direttamente a lui il traffico, senza passare nuovamente dal
> > firewall.
>
>intendi il traffico "di ritorno"? non ho capito molto bene.

Si, il traffico di ritorno: se <ip client> tenta di connettersi a un server
remoto <ip remoto> sulla porta 80/tcp emettera' un SYN e rimarra' con un 
socket in SYN_SENT su cui attende una risposta SYN/ACK da dalla porta 80/tcp
di <ip remoto>. Gli header IP e TCP del SYN verranno pero' riscritti dal 
firewall inserendo come destinazione <ip proxy>:3128 e lasciando <ip client>
e <porta client> come sorgenti. Ovviamente il firewall sta tenendo traccia di
questo cambiamento, implicitamente pronto a SNATtare le risposte su questa 
sessione per renderle comprensibili al client. Squid, pero', riceve il SYN
e, vedendo che proviene dalla sua stessa subnet, invia la risposta SYN/ACK
direttamente a <ip client> senza passare dal firewall. La risposta sara'
diretta alla corretta porta di destinazione di <ip client> ma proverra' 
dall'ip e dalla porta sbagliati, perche' non e' passato per il firewall e 
non gli sono 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.

Nel caso del REDIRECT il pacchetto di risposta passa ovviamente (non esce
neanche) dal firewall che sta gestendo lo stato della connessione e viene
quindi SNATtato correttamente prima di essere inviato al client.


Fabio