20.3. Squid e la sicurezza

L'obiettivo di questo capitolo è quello di dare una panoramica delle possibili soluzioni relative alla sicurezza da implementare utilizzando Squid, divideremo quindi questo paragrafo in tre sezioni principali analizzando diverse aree di interesse:

Storicamente non si ricordano importanti problematiche di sicurezza inerenti l'attività di sviluppo di Squid.

Per i pignoli ricordiamo che tutti gli advisor possono essere controllati nell'url http://www.squid-cache.org/Advisories/. Utilizzare l'ultima versione di Squid da sempre la certezza di avere il codice allo stato dell'arte, il codice dell'ultima release stabile risolve tutti i problemi riscontrarti durante l'utilizzo del proxy server, le ultime versioni considerate sicure alla data del 6 Aprile del 2004' sono

in questo paragrafo non è nostra intenzione dilungarci per disquisire sul controllo degli accessi, la questione è stata infatti approfonditamente affrontata in questo libro nei capitoli relativi alle ACL, all'autenticazione, all'autenticazione con Linux, all'autenticazione con Windows e relativamente al controllo accesso. Considereremo come "dato di fatto" che l'utente sia già a conoscenza del comportamento di Squid o di come Squid si configuri.

Lo scopo ultimo di questa sezione è sensibilizzare l'admin sui motivi per i quali le politiche di sicurezza proposte diventino un dovere e molto spesso una necessità. Accade troppo spesso infatti che, per quanto cerchiamo di "blindare" i nostri servizi, non riusciamo mai a proteggerci dagli attacchi e dagli abusi d'utilizzo.

20.3.1. Sicurezza in quanto Servizio

Più passa il tempo, più si può felicimente notare un aumento dell'utilizzo di Squid nelle realtà aziendali. Con la dilatazione del numero di utenze non può mancare un corretto rapporto tra l'utilizzo del servizio stesso e le politiche di profilazione che si adottano per la sicurezza aziendale e non.

La stesura di questa parte del documento nasce dalla presa di coscienza che, una volta creato un servizio e reso disponibile alla comunità d'utenza aziendale, automaticamente il fruitore (utente o chi per esso) si sentirà in diritto di utilizzare il servizio a proprio piacimento. Questo comportamento "improprio" in genere, si verifica genericamente in assenza di una regolamentazione scritta.

Troppe volte infatti accade che i "gestori/manutentori" devono saper sopperire a questioni e problematiche che vengono causate dall'utilizzo improprio di un servizio, questa problematica naturalmente si manifesta con molteplici sfaccettature che toccano sicuramente ed in maniera tangibile i seguenti argomenti:

Lasciando per ora da parte le implicazioni giuridiche legate alla sicurezza informatica, in questo contesto infatti indichiamo (per lo più) la possibile corruzione del dato da parte di terzi o l'accesso non autorizzato. Squid, oltre che avere un efficente sistema di web-cache può risolvere il problema di migliorare la sicurezza di un sistema informativo, ovvero quella di lasciare ad un unico punto logico l'accesso diretto a internet.

Questo fa si che il singolo pc dell'utente finale debba demandare qualsiasi richiesta di accesso ad internet al nostro cache server. Non solo, Squid fa in modo che l'utente possa essere profilato in modo da permettere la generazione demandata di alcune determinate connessioni (cfr. capitoli sul controllo accesso, sulla privacy e sulle indicazioni sulle dimensioni della cache) alle quali può sopperire (FTP, HTTP ed HTTPS). Il fine primo di questa azione è quello di risolvere le seguenti problematiche:

Un esempio pratico per l'attuazione di queste politiche di sicurezza si fonda sui seguenti divieti e sui controlli che possono essere definiti sul livello di accesso al sistema di web-cache:

Il primo passo è la discriminazione d'accesso sulla base alle credenziali dell'utente, naturalmente ci saranno diverse profilazioni per l'utilizzo della cache. Dopo aver impostato questo tipo di controllo è possibile lavorare sul tipo di download nonchè sui mimetypes: un esempio di desinenze per i file "vietati", poichè potenzialmente pericolosi (veicolo per l'introduzione dei virus) può essere la negazione per alcune estensioni di files come i file .exe, .com, .bat .vbs etc. etc. (cfr. capitolo sulle limitazioni della banda per classi, voce "acl ftp_block")

Possono essere inoltre vietate le pagine e le URLs che possiedono alcuni tipi di contenuti:

I criteri di "scelta" degli URLs e del loro contenuto viene affidato ad un algoritmo che effettua un controllo su parole chiave predefinite (cfr. capitoli sulla configurazione, sull'autenticazione in generale e sul controllo degli accessie sulle limitazioni di banda), altre possibili soluzioni per la gestione del content filtering possono essere reperite con l'utilizzo dei seguenti applicativi:

Nota: per quello che concerne la profilazione degli utenti ed il content filering bisogna fare attenzione alla regolamentazione giuridica italiana in materia di data-privacy nonchè da quanto previsto dallo statuto dei lavoratori.

Vediamo ora una caso particolare per quanto riguarda il DIRECT CONNECT. Alcuni servizi di rete (come ad esempio l'https) necessitano del metodo CONNECT per funzionare. Utilizzando questa modalità Squid non fa altro che creare un vero e proprio TUNNEL tra il client richiedente ed il server. Una sbagliata configurazione potrebbe permette ad un utente malintenzionato di servirsi di questo metodo per creare delle vere e proprie connessioni da usare a proprio piacimento per qualsiasi servizio.

E' buona prassi quindi negare il metodo CONNECT su tutte le porte ad eccezione di quelle SSL. (cfr. capitolo sulle limitazioni di banda voce: "http_access deny CONNECT !SSL_ports")