10.3. Capire il funzionamento delle ACL

Nel paragrafo precedente abbiamo potuto visualizzare più di 20 diversi tipo di ACL, questi possono riferirsi ad alcuni aspetti di una richiesta o anche di una risposta HTTP, tali aspetti possono variare dall'indirizzo IP del client (src) al nome di origine del server di destinazione (dstdomain) per finire al metodo di richiesta HTTP (method). Abbiamo anche detto che le Access Control List vengono utilizzate per impostare svariati livelli di controllo per l'accesso al proxy server Squid. E' possibile impostare diversi tipi di ACL, il formato utilizzato da Squid nella realizzazione delle ACL è il seguente

acl nomeacl tipoacl valore 
acl nomeacl tipoacl "file"
  

quando al posto di un valore viene utilizzato un file, ogni ACL deve contenere un solo file per essere realizzata correttamente, tutte le espressioni utilizzate nelle ACL sono case sensitive e quindi sono importanti sia i caratteri minuscoli che i caratteri maiuscoli. Possiamo affermare che una ACL quindi si compone di tre componenti

  1. nome ACL

  2. tipo ACL

  3. valore per il tipo

vediamo alcuni esempi di ACL

acl paperino src 10.10.10.1/32
acl pippo dstdomain www.sun.com
acl topolino method GET
  

l'elemento ACL dal nome paperino confronta una richiesta che proviene dall'indirizzo IP 10.10.10.1, l'elemento ACL dal nome pippo contronta con la URL www.sun.com e l'elemento ACL topolino confronta l'esistenza di una richiesta HTTP del tipo GET. Possiamo impostare autorizzazioni e negazioni, per molti tipi di ACL è anche possibile esprimere un valore che contiene delle espressioni multiple

acl gandalf src 10.10.10.4/32 10.10.10.24/32 10.10.10.84/32
acl legolas dstdomain www.sun.com www.linux.com www.cisco.com
acl aragorn method PUT POST
  

l'espressione multipla esegue una comparazione con una richiesta per ogni valore inserito nell'espressione stessa. La ACL gandalf esegue una comparazione tra una richiesta proveniente dagli indirizzi IP 10.10.10.4, 10.10.10.24 e 10.10.10.84. La ACL legolas verifica la rispondenza con i siti di sun, linux e cisco, mentre la ACL aragorn esegue una comparazione sul tipo di richiesta HTTP ed in particolare che la stessa sia conforme ai metodi PUT o POST.

Ora che abbiamo mostrato al lettore alcuni tipi di ACL, assicuriamoci di applicare queste ACL in maniera graduale e corretta. Abbiamo detto che una richiesta può essere permessa o negata, nell'esempio seguente mostreremo una lista di regole che si riferiscono ad elementi di tipo ACL, facendo riferimento al nome assegnato alle ACL, concederemo o negheremo l'accesso, in questo contesto è bene sottolineare che il nome della ACL diviene una parola chiave

acl paperino src 10.10.10.1/32
acl pippo dstdomain www.sun.com
acl topolino method GET
http_access allow paperino
http_access deny pippo
http_access allow topolino
  

le regole della ACL vengono rigorosamente applicate nell'ordine nel quale sono state scritte, la decisione viene presa sempre quando la relativa ACL viene confrontata, ritornando sull'esempio precedente analizzeremo alcune situazioni che possono venire a delinearsi.

Le regole che abbiamo visto sino a questo momento sono state impostate con delle ACL semplici, non dimentichiamo però che Squid è in grado di combinare in maniera molto interessante anche elementi multipli per singole ACL, possiamo ora mostrare un semplice esempio

acl paperino src 10.10.10.1/32
acl pippo dstdomain www.sun.com
acl topolino method GET
http_access allow paperino pippo
http_access deny topolino
  

tutte le richieste provenienti dall'indirizzo IP 10.10.10.1 che contengono come URL di destinazione www.sun.com vengono autorizzate, il metodo di richiesta HTTP è del tipo GET e viene vietato nel momento in cui si esegue la verifica della prima ACL, poi tutto è poi consentito. Se la prima regola ACL non viene confrontata, il metodo di richiesta HTTP del tipo GET verrà bloccato e Squid avviserà gli utenti con un messaggio di richiesta negata.

Ecco di seguito un esempio di regole ACL piuttosto frequente

acl all src 0/0
acl servers 192.168.1.4/32 192.168.1.10/32 192.168.1.14/32
icp_access allow servers
icp_access deny all
  

qui vediamo una relazione di parentela tra cache adiacenti che ricorrono al protocollo ICP, dove tutte le richieste provenienti dagli indirizzi IP 192.168.1.4, 192.168.1.10 e 192.168.1.14 verranno soddisfatte, mentre quelle provenienti da altri indizzi verranno negate.

Ecco di seguito un esempio che contiene una regola più complessa

acl gandalf src 10.10.10.4/32 10.10.10.24/32 10.10.10.84/32
acl legolas dstdomain www.sun.com www.linux.com www.cisco.com
acl aragorn method PUT POST
http_access deny gandalf legolas aragorn
http_access allow gandalf legolas
http_access deny aragorn
  

queste tre linee autorizzando i client della ACL gandalf (10.10.10.4, 10.10.10.24 e 10.10.10.84) ad accedere ai server specificati nella ACL legolas (www.sun.com, www.linux.com, and www.cisco.com) ma negano l'utilizzo dei metodi HTTP del tipo PUT o POST. I client provenienti dalla ACL gandalf non sono autorizzati ad accedere agli altri server.

Le ACL possono divenire lunghe e complicate, una buona regola da seguire per l'inserimento delle ACL è quella di editare prima le regole specifiche e dopo quelle meno specifiche. Non dimentichiamo mai che, come già detto in precedenza, le regole ACL vengono sempre applicate in ordine. E' buona norma negare una richiesta definendo una ACL specifica per poi concedere autorizzazione a tutte le altre ACL

acl vietato dstdomain www.nonautorizzato.it 
acl all src 0/0
http_access deny vietato
http_access allow all
  

in questo esempio a tutti gli utenti non è consentito accedere al sito www.nonautorizzato.it, vogliamo ora creare una eccezione per un indirizzo IP dal quale dovrà essere consentito visitare quel sito, la nuova ACL sarà

acl user_ok src 10.10.10.254/32
  

e la nuova regola dovrà dunque essere

http_access allow user_ok vietato
  

nel contesto generale delle regole che stiamo applicando, la nuova ACL dovrà essere inserita seguendo questo schema

http_access allow user_ok vietato
http_access deny vietato
http_access allow all
  

entriamo nello specifico visualizzando alcune delle impostazioni standard di Squid

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl locallans src 192.168.0.0/255.255.255.0
acl to_localhost dst 127.0.0.0/8
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         # multiling http
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow locallan
http_access deny all
  

con il TAG acl src vengono definite diverse liste di accesso basate sull'indirizzo IP, incluse quelle per gli host autorizzati dall'amministratore del sistema ad accedere al proxy server. Il TAG http_access allow consente a tutta la subnet 192.168.0.0 incluso l'host locale (127.0.0.1) di accedere al proxy, il TAG http_access deny impone una negazione di accesso.

I protocolli SMTP e HTTP sono delle implementazioni piuttosto simili, questo fatto può autorizzare qualche male intenzionato ad utilizzare il nostro proxy server come relay SMTP per inviare dei messaggi di posta non autorizzati. Per prevenire questo tipo di inconveniente dovremmo accertarci che Squid blocchi le richieste dirette verso la porta 25 che viene appunto utilizzata dal protocollo SMTP. Squid viene configurato in questo modo come default, nel file squid.conf vengono elencate una lista di porte fidate, a tale riguardo controllare la acl Safe_ports. Nel vostro file di configurazione dovreste avere un TAG http_access impostato in questo modo

acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
http_access deny !Safe_ports
  

con questo TAG http_access deny bloccheremo tutto il traffico diverso (!) da quello dichiarato nella acl Safe_ports. Naturalmente per impedire il relay non autorizzato di posta elettronica, la porta 25 non deve elencata nella acl Safe_ports. Possiamo utilizzare una ACL per impostare gli orari di accesso a Squid

acl work_time time MTWHF 08:00-17:30 
http_access allow work_time
  

con il TAG acl work_time viene impostato un orario per l'accesso al proxy server e il TAG http_access allow consente solo quell'orario. In questo esempio autorizziamo l'accesso al proxy server nei soli giorni festivi e nelle sole ore lavorative.

Possiamo impostare delle ACL anche per il protocollo ICP ed determinare delle relazioni di trusted tra macchine diverse nell'ambito di un cache peering

acl all src 0.0.0.0/0.0.0.0
acl locallans src 192.168.0.0/255.255.255.0
icp_access allow locallans 
icp_access deny all 
  

con il TAG icp_access vengono processate le ACL che autorizzano o negano accesso per le richieste ICP che vengono effettuate da altri proxy server.

Così abbiamo visto che è possibile impostare diversi tipi di ACL, i nomi delle ACL di tipo src non devono assolutamente contenere il simbolo "-", questo carattere infatti potrebbe essere interpretatato da Squid come una indicazione di intervallo (range). Ecco un esempio di una serie di ACL del tipo src impostata correttamente

acl locallan101 src 192.168.100.0/255.255.255.224   
acl locallan102 src 192.168.100.32/255.255.255.224  
acl locallan103 src 192.168.100.64/255.255.255.192  
acl locallan104 src 192.168.100.128/255.255.255.192 
acl locallan105 src 192.168.100.192/255.255.255.248 
acl locallan106 src 192.168.100.200/255.255.255.248 
acl locallan107 src 192.168.100.208/255.255.255.240 
acl locallan108 src 192.168.100.224/255.255.255.248 
acl locallan109 src 192.168.100.232/255.255.255.248 
acl locallan110 src 192.168.100.240/255.255.255.240
  

di seguito riportiamo una ACL del tipo src impostata in maniera errata

acl locallan-1-01 src 192.168.100.0/255.255.255.224
  

In linea di massima, questo tipo di indicazioni dovranno essere sempre rispettate, in particolare è proprio questa la sintassi consigliata per creare le ACL, si tratta infatti di una serie di regole fondamentale nel caso in cui si gestiscano dei Sistemi che prevedono un controllo molto granulare degli accessi al proxy server, Sistemi che concedono e negano accesso a diverse subnet che possono anche trovarsi sullo stesso segmento rete.