Squid e DansGuardian - 6
Author: Giancarlo Dessi'

Il tuo browser non supporta i fogli di stile. Per i dettagli vai a fondo pagina.

# Intestazione

Salta e vai al contenuto principale

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

Vai all'intestazione

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

`
`

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à

Il tuo programma di navigazione non supporta il CSS 2, pertanto i contenuti sono accessibili in modalità testuale secondo un ordine lineare definito con la struttura del documento.
Se il tuo programma di navigazione non supporta i fogli di stile i motivi sono essenzialmente i seguenti:

1. Sti usando una vecchia versione di un browser ormai obsoleta. Per fruire dell'impaginazione grafica è necessario un browser che supporti i fogli di stile a cascata.
2. Hai disattivato i fogli di stile. Ti consiglio di verificare nella configurazione del tuo browser se l'applicazione dei fogli di stile è stata disattivata accidentalmente.
3. Stai usando un browser testuale.
4. Stai usando un sintetizzatore vocale, un lettore di schermo o altro dispositivo di ausilio per i disabili.

Torna su