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
nome ACL
tipo ACL
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.
Cosa accade quando un utente proveniente dall'indirizzo IP 10.10.10.1 esegue il confronto con la ACL che specifica l'indirizzo di destinazione www.sun.com?
Squid incontra la ACL paperino e ne autorizza l'accesso. La nostra richiesta viene confrontata con la ACL paperino che ne verifica l'indirizzo IP di provenienza (10.10.10.1), in questo caso le regole successive non verranno verificate.
Cosa accade invece se arriva una richiesta per il sito www.sun.com proveniente dall'indirizzo IP 10.10.10.5?
la richiesta non confronta con la prima regola ACL ma collima con la seconda ACL pippo, la richiesta verrà dunque negata. In questo caso l'utente riceverà un messaggio di richiesta negata da parte di Squid.
Cosa accade se arriva una richiesta per il sito www.linux.com proveniente dall'indirizzo IP 10.10.10.5?
La richiesta non confronta la prima ACL paperino, non si abbina nemmeno con la seconda ACL pippo perchè www.linux.com è differente da www.sun.com però si confronta con la terza regola ACL topolino perchè il metodo di richiesta HTTP utilizzato è GET.
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.