Intestazione

Squid e DansGuardian
Come gestire e controllare gli accessi al Web dalle reti scolastiche
di Giancarlo Dessì, gian at cettolini.it

Accesso rapido: Inizio [1] - Precedente [2] - Successivo [3] - Ultimo [4] - Licenza [5]

Contenuto principale

6. Configurazione di Squid

L'installazione di Squid crea il file di configurazione generico

/usr/local/squid/etc/squid.conf

L'essenza della funzionalità del proxy è in questo file perciò è fondamentale dedicarci la dovuta attenzione per allestire un efficace strumento di rete. Gli estimatori delle interfacce grafiche potrebbero storcere il naso alla vista di questo file, tuttavia l'apparente difficoltà delle configurazioni basate su file di testo è a mio parere un punto di forza: i commenti inseriti nel codice hanno il duplice scopo di guidare l'amministratore nella configurazione e nel tempo stesso dare un suggerimento sulla possibile impostazione da abilitare o disabilitare. In generale questi file di configurazione sono abbastanza intuitivi, ma dove non basta l'intuito può sempre venire in aiuto la documentazione presente in Rete. Sembrerà strano sono trascorsi due anni prima di capire come dovevo configurare il proxy commerciale Wingate malgrado la sua semplice ed elegante interfaccia grafica. Per Squid è bastata un'ora per documentarmi una ventina di minuti per configurarlo usando un banalissimo editor di testo.

In conformità ad una prassi consolidata negli ambienti UNIX/Linux, la struttura di squid.conf è molto semplice: il file è un elenco di direttive o tag arricchito di commenti per rendere leggibile e intuitivo il contenuto. Le righe che iniziano con il carattere # (cancelletto) sono commenti, pertanto saranno ignorate dal processore del proxy. Saranno ignorate anche le righe completamente vuote e gli spazi ripetuti. Insomma, più facile di così... La sintassi delle direttive è anch'essa molto semplice:

direttiva [argomenti]

In altre parole, ogni direttiva deve occupare una riga e iniziare con il nome della direttiva, facendo seguire l'argomento ossia il valore che specifica l'impostazione.

Il file va modificato togliendo i commenti o commentando le righe non necessarie e modificando gli argomenti delle direttive. Il numero di direttive da impostare dipende dal livello di personalizzazione che s'intende applicare al proxy. L'installazione crea un sistema preconfigurato perciò gli impazienti possono già essere operativi. Naturalmente le impostazioni di configurazione di partenza fanno riferimento ad un contesto generico perciò si tenga presente che dedicare una o due ore di tempo, per documentarsi e adattare la configurazione alle esigenze, permetterà di ottenere un efficace strumento di rete.

Quello che segue è un esempio di configurazione. Non è completo perché ho volutamente omesso impostazioni avanzate delle quali si può fare a meno demandando a Squid il compito di applicare le impostazioni predefinite per le direttive omesse. I commenti descrivono brevemente gli scopi delle direttive che seguono.

# Indirizzo IP e porta d'ascolto
http_port 192.168.10.1:3128

# Pagine Web dinamiche da non memorizzare nella cache
acl CGI urlpath_regex cgi-bin \?
acl ASP urlpath_regex asp \?
acl PHP urlpath_regex php \?
acl JSP urlpath_regex jsp \?
no_cache deny CGI ASP PHP JSP

# Dimensioni massime e minime delle
# risorse da memorizzare in cache
maximum object size 10240 KB
minimum_object_size 10 KB

# Identificazione delle reti locali a cui
# faranno riferimento le direttive d'accesso
acl all src 0.0.0.0/0.0.0.0
acl localnet src 192.168.10.0/255.255.255.0
acl localnet src 192.168.11.1-192.168.11.20/255.255.255.255
acl localhost src 127.0.0.1/255.255.255.255
acl manager proto cache_object

# Definizione dei metodi di connessione a cui
# faranno riferimento le direttive d'accesso
acl CONNECT method CONNECT

# Identificazione delle porte TCP a cui
# faranno riferimento le direttive d'accesso
acl SSL_ports  port 443 563
acl Safe_ports port 80            # http
acl Safe_ports port 21            # ftp
acl Safe_ports port 443 563       # https, snews
acl Safe_ports port 70            # gopher
acl Safe_ports port 210           # wais
acl Safe_ports port 1025-65535    # unregistered ports
acl Safe_ports port 280           # http-mgmt
acl Safe_ports port 488           # gss-http
acl Safe_ports port 591           # filemaker
acl Safe_ports port 777           # multilink http
acl Safe_ports port 901           # SWAT

# Definizione delle estensioni dei file a cui
# faranno riferimento specifiche direttive d'accesso
acl banna_mp3 url_regex -i  \.mp3$   
acl banna_exe url_regex -i  \.exe$

# Identificazione di un file di testo contenente
# una lista di espressioni regolari a cui 
# faranno riferimento le direttive d'accesso
acl forbidden url_regex "/usr/local/squid/etc/forbidden.txt"

# Direttive d'accesso (http_access):
# definiscono le regole di accesso al proxy
http_access allow manager localhost
http_access deny manager 
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports  
http_access deny banna_mp3 
http_access deny banna_exe
http_access deny forbidden 
http_access allow localnet
http_access allow localhost          # permette l'accesso dal loopback

# Direttiva che vieta l'accesso a tutti i
# casi non contemplati 
# Deve essere l'ultimo tag http_access
http_access deny all

Come si può osservare, gran parte delle direttive prese in considerazione nell'esempio fanno capo a due forme:

A. Direttive acl

In generale identificano un contesto, come ad esempio una gamma di indirizzi di rete, un'espressione regolare contenuta negli URL un tipo di porta, eccetera. Ogni contesto definito è identificato con un nome che segue la parola chiave acl. La struttura sintattica di queste direttive pertanto è la seguente:

acl nome espressione

Ad esempio, la direttiva acl localnet src 192.168.10.0/255.255.255.0 identifica con il nome localnet un'intera sottorete di classe C. Per le postazioni che hanno un indirizzo di rete che rientra in questo contesto sarà specificata una direttiva d'accesso specifica.

B. Direttive http_access

Impostano le regole d'accesso per ogni contesto definito in precedenza. In altri termini sono le direttive d'accesso che indicano al proxy come dovrà comportarsi caso per caso. La struttura sintattica di queste direttive è la seguente:

http_access azione nome_acl1, nome_acl2, ...

L'azione è definita da due parole chiave alternative: deny vieta l'accesso ad Internet nel contesto associato alla direttiva, allow lo permette. Nella configurazione di esempio ho specificato dieci direttive d'accesso. Data l'importanza esaminiamole nel dettaglio:

  1. allow manager localhost. Permette l'accesso a due contesti abbinati: manager che definisce l'amministrazione del proxy con interfaccia grafica elaborata in PHP e localhost definisce l'indirizzo di loopback. Questa direttiva pertanto permette l'accesso all'interfaccia di amministrazione dalla postazione in cui è installato Squid.
  2. deny manager. Per analogia con il precedente, questa direttiva vieta l'accesso all'interfaccia di amministrazione da qualsiasi postazione remota. Per ovvie ragioni legate alla sicurezza si raccomanda d'inserire questa regola dopo quella precedente. In ogni caso si tenga presente che l'installazione di base di Squid non comprende alcuna interfaccia grafica d'amministrazione, che va installata a parte con un modulo PHP appositamente concepito.
  3. deny !Safe_ports. Le acl Safe_ports definiscono le porte TCP attraverso le quali si può stabilire una connessione per uno specifico protocollo di rete. Ad esempio, la porta 80 è lo standard predefinito per il protocollo HTTP. La direttiva d'accesso vieta l'uso di qualsiasi porta di numero inferiore a 1025 non prevista negli standard. Si tratta di una fondamentale impostazione di sicurezza che impedisce che qualche malintenzionato sfrutti una falla nella configurazione di Squid per accedere da Internet all'interno del nostro server di connessione usando una delle porte critiche (fino a 1024).
  4. deny CONNECT !SSL_ports. Per essere sinceri non so molto su questa direttiva. Si tratta di un'impostazione predefinita che vieta il metodo CONNECT attraverso porte diverse da quelle previste per la connessione crittografata. Probabilmente si tratta di un'impostazione di sicurezza.
  5. deny banna_mp3. Vieta lo scaricamento di file mp3. Un'impostazione di questo tipo, che può essere estesa ad altri formati multimediali, è sicuramente utile in connessioni a banda stretta per le quali è fondamentale prevenire eccessivi assorbimenti di banda.
  6. deny banna_exe. Impostazione analoga a quella precedente. In questo caso lo scopo potrebbe essere quello d'impedire lo scarimento di eseguibili che potrebbero essere dannosi per le postazioni Windows della rete locale.
  7. deny forbidden. Questa direttiva vieta lo scaricamento di pagine da indirizzi che contengono una o più parole chiave fra quelle elencate nel file di testo identificato dalla acl forbidden.
  8. allow localnet. Questa direttiva permette l'accesso al proxy solo alle postazioni che hanno un indirizzo di rete che s'identifica in una delle precedenti direttive acl. Impostazioni di questo tipo sono fondamentali per regolamentare gli accessi al proxy impedendo da un lato l'accesso da reti esterne e da un altro l'accesso da specifiche postazioni della rete locale. Impostando altre direttive - non contemplate in questa sede - si puograve; anche prestabilire una regolamentazione basata sugli orari e sul calendario. Ad esempio possiamo prestabilire che dalle postazioni delle aule si possa accedere al Web solo dalle 9 alle 12 in determinati giorni della settimana.
  9. allow localhost. Direttiva analoga alla precedente, ma fa riferimento all'indirizzo di loopback pertanto permette l'accesso al Web anche dalla postazione in cui è installato il proxy.
  10. deny all. Questa è una direttiva d'accesso particolare e di fondamentale importanza perchè vieta l'accesso in tutti i contesti non contemplati - in senso sia permissivo sia proibitivo - dalle direttive precedenti. Mantenere questa direttiva, per ultima dopo tutte le altre http_access è altamente raccomandato se vogliamo evitare di lasciare possibili vie d'accesso al proxy non previste nella nostra policy.

Per concludere, faccio presente che negli esempi ho trattato solo alcuni aspetti della configurazione di Squid focalizzando l'attenzione sulle impostazioni relative alla sicurezza e al rispetto della policy. Altre direttive fanno riferimenti a contesti particolari che potrebbero migliorare la funzionalità del sistema, come ad esempio il concatenamento con altri proxy. In generale si tratta di direttive che sfruttano ulteriormente le potenzialità di Squid ma che rientrano in una configurazione avanzata, pertanto rimando chi è interessato a documentazioni di approfondimento più particolareggiate rispetto a questa guida. In ogni modo, quando non si è sicuri sull'impostazione da applicare in una direttiva contemplata nel file di configurazione creato dall'installazione, consiglio di mantenere l'impostazione predefinita: è il modo migliore di avere uno Squid funzionante e in modo controllato, anche se non ottimizzato nelle sue funzioni.


Torna su

Note aggiuntive sull'accessibilità