Transparent Proxy con Squid

Già discussi e ridiscussi sono i benefici di un proxy all'interno nella infrastruttura di rete, primo fra tutti la gestione centralizzata delle restrizioni ai siti consentiti alla navigazione. La personalizzazione in questo contesto può essere mirata nel dettaglio, inutile dire che la presenza di numerose macchine sotto proxy aumenta proporzionalmente le difficoltà di gestione, favorendo ad esempio la possibilità di abusi da parte di utenti legittimi.

La funzione del Transparent Proxy è quella di intercettare ogni richiesta di un particolare servizio (in questo caso richiesta HTTP) per poi redirigerla a un proxy (Squid) affinchè svolga tutte le funzioni del caso (semplice content filtering piuttosto che caching). Nel dettaglio la funzionalità di intercettare traffico appartiene ai vari packet filtering, Squid assolve eslusivamente i compiti di proxy.

I benefici portati da una implementazione simile sono notevoli: la forzatura a utilizzare il proxy lato client è trasparente per l'utente; l'amministratore è relativamente certo di controllare il traffico HTTP per tutte le workstation che gestisce.

L'analisi viene effettuata su un'unica macchina che assolve entrambi i compiti di packet filtering e proxyserver (opzione sicuramente discutibile).

Si considera la config di Squid:
...
# Forzo il binding di Squid su localhost
http_port 127.0.0.1:3128
...
# Direttive minime per le funzionalità di proxy
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

L'opportuna gestione delle ACL di Squid terminerà la config del proxy, implementando politiche di navigazione per indirizzi ip / subnet ip che daranno origine alla richiesta.
Lato packet filtering si considera la configurazione per pf (OpenBSD):
#/etc/pf.conf
...
rdr on $int_if inet proto tcp from any to any port www -> 127.0.0.1 port 3128
...
e iptables (Linux):
#iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
in entrambi i casi si redirige il traffico HTTP sullo Squid locale.

Osservazioni
Come già accennato risulta sicuramente discutibile la scelta di integrare packet filter e proxy sulla stessa macchina, da valutare in base al contesto di utilizzo della soluzione.

Inoltre, l'attuale configurazione redirige OGNI richiesta HTTP, incurante della sorgente e delle destinazione del traffico (da rivalutare con l'eventualità di webserver all'interno della rete).

Infine, una centralizzazione di questo tipo porta a un "single point of failure" rappresentato dal proxy; anche in questo caso risulta doverosa l'analisi sulla eventuale implementazione di una soluzione ridondata.

Privacy Policy