Configurare Squid Proxy privato su Ubuntu 20.04

Perché Squid privato va impostato con ACL e non “aperto e basta”

Su Ubuntu 20.04 Squid è ancora una scelta sensata quando serve un proxy esplicito, controllato e osservabile: navigazione filtrata, cache locale, tracciabilità degli accessi e, soprattutto, una superficie d’esposizione molto più piccola rispetto a un proxy lasciato libero sulla rete. La differenza tra un proxy utile e un problema di sicurezza sta quasi tutta nella configurazione iniziale: ascolto limitato, accesso ristretto, autenticazione se serve e log leggibili.

Il punto da chiarire subito è questo: un proxy “privato” non significa solo non esporlo su Internet. Significa definire con precisione chi può usarlo, da quali subnet, con quale metodo di autenticazione e con quali eccezioni. Se ometti questi vincoli, Squid diventa facilmente un open proxy, cioè un servizio abusabile da terzi e, nella pratica, un rischio operativo e reputazionale.

Installazione su Ubuntu 20.04

Il pacchetto ufficiale è sufficiente per la maggior parte degli scenari interni. L’installazione base è lineare:

sudo apt update
sudo apt install squid

Verifica subito che il servizio sia attivo e che il binario sia stato installato correttamente:

systemctl status squid --no-pager
squid -v

Se il servizio risulta attivo ma non ascolta sulla porta attesa, il problema di solito è nella configurazione o nel binding delle interfacce. Su Ubuntu 20.04 il file principale è /etc/squid/squid.conf, ma nella pratica conviene trattarlo come punto di ingresso e spostare la logica in file separati inclusi con include, così la manutenzione resta pulita.

Struttura minima della configurazione

Prima di toccare il file, fai un backup versionato. Non è un dettaglio: Squid è molto permissivo nella sintassi e un errore banale può portare il servizio a non ripartire.

sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.$(date +%F).bak

Per una installazione privata semplice, la struttura minima dovrebbe includere: porta di ascolto, ACL della rete interna, regole di accesso, DNS, log e limiti di cache. Un esempio pulito, da adattare alla tua subnet, può essere questo:

http_port 3128
visible_hostname proxy01 acl localnet src 192.168.10.0/24
acl localhost src 127.0.0.1/32
acl SSL_ports port 443
acl Safe_ports port 80 443 1025-65535
acl CONNECT method CONNECT http_access allow localhost
http_access allow localnet
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny all

La logica è semplice: consenti prima localhost e la tua rete, poi nega tutto il resto. L’ordine conta. In Squid le regole vengono valutate dall’alto verso il basso: se metti un deny all troppo presto, tagli fuori anche gli accessi legittimi; se lo metti troppo in basso o dimentichi una ACL troppo ampia, lasci aperto il servizio.

Limitare davvero l’accesso al proxy

Il controllo sul livello applicativo non basta da solo. Se il server ha più interfacce o se la macchina è raggiungibile da reti che non dovrebbero vedere il proxy, conviene vincolare anche il binding di ascolto. In questo modo Squid accetta connessioni solo sull’indirizzo previsto, non su tutte le interfacce disponibili.

http_port 192.168.10.20:3128

Questo è utile in ambienti con VLAN o server multi-homed. Se invece vuoi esporre il proxy solo localmente a un reverse tunnel o a un bastion, puoi ascoltare su 127.0.0.1:3128 e pubblicarlo con un tunnel SSH o con un accesso controllato a monte. In quel caso la superficie d’attacco resta molto più contenuta.

Controlla anche il firewall. Con UFW, ad esempio, non ha senso aprire la porta a tutto il mondo se il proxy deve servire solo una subnet interna:

sudo ufw allow from 192.168.10.0/24 to any port 3128 proto tcp
sudo ufw status numbered

Se usi nftables o iptables, il principio non cambia: consenti solo l’origine necessaria e verifica che la regola sia coerente con l’ACL di Squid. La doppia barriera riduce gli errori di configurazione e rende più difficile trasformare per sbaglio il proxy in un servizio pubblico.

Autenticazione: quando serve e quando è meglio evitarla

In una rete piccola e ben segmentata, l’ACL per subnet può bastare. Se invece il proxy deve essere condiviso da utenti o dispositivi che non stanno tutti nella stessa rete fidata, aggiungere autenticazione è la scelta giusta. Il metodo più comune in ambienti semplici è basic_ncsa_auth con file password gestito localmente.

Installa l’utility per generare le credenziali e crea il file utenti fuori dal path di configurazione principale:

sudo apt install apache2-utils
sudo htpasswd -c /etc/squid/passwd proxyuser

Attenzione al permesso del file: deve essere leggibile da Squid ma non da tutti gli utenti del sistema.

sudo chown proxy:proxy /etc/squid/passwd
sudo chmod 640 /etc/squid/passwd

Nel file di configurazione aggiungi il blocco auth e collega l’ACL alla regola di accesso:

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd
auth_param basic realm Private Proxy
acl authenticated proxy_auth REQUIRED http_access allow authenticated localnet
http_access deny all

Qui c’è un punto pratico da non ignorare: se il proxy è usato da browser moderni, l’autenticazione basic va bene solo su canali di rete fidati. Se la tratta passa su segmenti non affidabili, il traffico proxy stesso dovrebbe essere protetto da tunnel o da una VPN. In chiaro, le credenziali non sono una buona idea.

Cache e spazio disco: dimensionare senza esagerare

Molti installano Squid per “fare caching”, poi si ritrovano con un disco saturo o con una cache che non porta benefici reali. Su un proxy privato moderno la cache ha senso se hai oggetti ripetuti, utenti numerosi o banda limitata. Altrimenti può restare piccola, giusto per evitare sprechi e logiche inutili.

Un’impostazione prudente su disco locale potrebbe essere questa:

cache_mem 256 MB
maximum_object_size 32 MB
cache_dir ufs /var/spool/squid 2000 16 256

Il valore di cache_dir va calibrato sullo spazio disponibile e sul carico. Se il server ha un disco piccolo o è una VM con storage condiviso, meglio mantenere margine. Prima di aumentare aggressivamente la cache, osserva se i benefici reali ci sono: hit ratio, consumo RAM, I/O su disco e tempi di risposta percepiti dagli utenti.

Per vedere se la cache sta lavorando, puoi guardare i log e, se necessario, interrogare lo stato del processo con gli strumenti di Squid:

squidclient mgr:info
squidclient mgr:5min

Se squidclient non è presente, installalo con il pacchetto di utility o verifica la build disponibile nella tua distribuzione. L’obiettivo non è inseguire numeri “belli”, ma capire se la cache sta davvero alleggerendo il traffico o se sta solo occupando spazio.

Log, rotazione e diagnosi operativa

I log sono la prima fonte di verità quando il proxy non funziona come previsto. I path tipici su Ubuntu sono /var/log/squid/access.log e /var/log/squid/cache.log. Il primo ti dice chi sta usando il proxy e con quale esito; il secondo ti mostra errori di configurazione, problemi di startup, DNS e cache.

Un controllo rapido utile è questo:

sudo tail -n 50 /var/log/squid/cache.log
sudo tail -n 50 /var/log/squid/access.log

Se il servizio non parte, cerca errori sintattici o riferimenti a file mancanti. Se parte ma rifiuta il traffico, controlla ordine delle ACL, rete sorgente, porta e firewall. Se i client ricevono errori DNS, verifica che Squid possa risolvere i nomi e che il resolver del sistema sia configurato correttamente.

La rotazione log è di solito gestita da logrotate. Non disattivarla per “semplificare”: dopo qualche giorno di traffico, gli accessi crescono velocemente e i file diventano ingestibili. Se personalizzi la retention, fallo con criterio e tenendo conto dello spazio disponibile e dei requisiti di audit.

Test del proxy dal client

Una volta attivato il servizio, il test migliore è un controllo esplicito dal client, senza passare da browser che possono mascherare errori di configurazione. Imposta temporaneamente il proxy nella shell o usa curl con l’opzione dedicata:

curl -I -x http://192.168.10.20:3128 https://example.com

Se l’autenticazione è abilitata, il test deve includerla:

curl -I -x http://proxyuser:password@192.168.10.20:3128 https://example.com

Il test non deve limitarsi al “risponde”. Verifica almeno tre cose: codice HTTP corretto, assenza di ritardi anomali e presenza della riga nel log accessi. Se il proxy è configurato bene, dovresti vedere l’accesso registrato con il client sorgente e l’URL richiesto.

Se vuoi forzare un controllo più netto, prova una destinazione HTTP e una HTTPS. La seconda è più importante perché passa dal metodo CONNECT e mette alla prova sia le ACL sia la gestione della porta consentita.

Hardening pratico senza complicare la vita

Per un proxy privato non serve un labirinto di regole. Bastano pochi accorgimenti fatti bene: ascolto limitato, ACL strette, autenticazione se necessaria, password gestite fuori dal repository e aggiornamenti regolari del pacchetto.

Se il server ospita solo Squid e pochi servizi d’appoggio, riduci al minimo i servizi esposti su rete. Controlla le porte in ascolto con:

ss -lntp | grep squid

Verifica anche che il processo giri con l’utente previsto e che i permessi sulle directory di cache e log siano coerenti. Un errore comune è lasciare file o directory troppo permissivi durante i test e dimenticarsene in produzione.

Se usi autenticazione, tratta il file password come materiale sensibile. Non inserirlo in chiaro in script o note operative. Se devi distribuirlo su più server, usa un meccanismo di provisioning sicuro e ruota le credenziali quando cambia il perimetro di accesso.

Manutenzione e aggiornamenti

Squid non richiede una manutenzione quotidiana pesante, ma va tenuto aggiornato come qualsiasi componente esposto in rete. Su Ubuntu 20.04, gli update di sicurezza arrivano tramite i repository della distribuzione. Prima di aggiornare, conviene sempre controllare la configurazione con un validatore sintattico e mantenere un backup del file attivo.

squid -k parse
sudo systemctl restart squid

Il primo comando è quello che ti salva da un reload fallito. Se il parsing passa, il restart diventa un’operazione ragionevole. Se non passa, il file va corretto prima di toccare il servizio. Questo approccio evita interruzioni inutili e riduce il rischio di fermare il proxy in orario lavorativo.

Se devi cambiare una regola ACL o aggiungere una subnet, modifica il minimo indispensabile e poi verifica con un test reale dal client. Non affidarti solo al fatto che il servizio sia “active”. Un demone attivo può comunque bloccare tutto per una regola sbagliata o per una porta non raggiungibile.

Configurazione completa di esempio

Per chiudere il cerchio, ecco un profilo base coerente per un proxy privato su Ubuntu 20.04 in una LAN dedicata. Va adattato alla tua rete, ma la logica è quella giusta: ascolto su interfaccia privata, accesso ristretto, autenticazione opzionale e logging attivo.

http_port 192.168.10.20:3128
visible_hostname proxy01 acl localhost src 127.0.0.1/32
acl localnet src 192.168.10.0/24
acl SSL_ports port 443
acl Safe_ports port 80 443 1025-65535
acl CONNECT method CONNECT auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd
auth_param basic realm Private Proxy
acl authenticated proxy_auth REQUIRED http_access allow localhost
http_access allow localnet authenticated
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny all cache_mem 256 MB
maximum_object_size 32 MB
cache_dir ufs /var/spool/squid 2000 16 256
access_log /var/log/squid/access.log squid
cache_log /var/log/squid/cache.log

Prima di attivare questa configurazione, assicurati che l’IP 192.168.10.20 esista davvero sulla macchina e che il file /etc/squid/passwd sia presente se hai abilitato l’autenticazione. In caso contrario, Squid può partire in modo inatteso o rifiutare l’accesso con messaggi poco chiari per chi non guarda i log.

In sintesi, un proxy privato ben fatto non è quello più complesso, ma quello più prevedibile: pochi ingressi, regole nette, log leggibili e test ripetibili. Su Ubuntu 20.04 questa impostazione è stabile e facile da mantenere, purché non si salti il controllo delle ACL e non si confonda “funziona sul mio client” con “è configurato in modo sicuro”.