Introduzione

Un server proxy all'interno di una rete ha la fondamentale funzione di controllare i processi di autenticazione degli utenti durante i loro accessi ad Internet.

Per poter fare ciò è necessario configurare ogni client in modo che nel momento in cui tenta di connettersi ad internet passi per il nodo che funge da server proxy, il quale dovrà a sua volta richiedere l'autenticazione dell'utente e del client e controllare le credenziali di accesso fornite e la loro rispondenza ai criteri stabiliti dal server proxy.

Il proxy server è pertanto un controllore centrale delle credenziali di accesso ad un sistema che opera con ACL sia a livello utente che a livello host , nonché selezionando siti e percorsi di ricerca da accettare o scartare.

Una volta ottenuta la convalida dell'autenticazione, ciascun client ha accesso al servizio fornito dal proxy server, in questo caso l'accesso alle pagine internet.

Tali pagine richieste dai client vengono risolte nel primo accesso direttamente dal server proxy e poi ogni successiva richiesta della stessa pagina da parte di un client verrà evasa usando l'informazione che il proxy ha nella sua memoria cache.

Ritorna il principio di località dell'informazione in base al quale la minimizzazione dei temnpi di accesso ad una determinata informazione è garantito dall'uso di una memoria locale e volatile ad accesso molto rapido.

Prima di installare

Prima di cominciare, come prerequisito, è necessario:

• Pianificare un corretto partizionamento del disco

• Dedicare, se possibile, una partizione apposita per /var/log ed una specifica per /var/cache/squid

Installazione

Per installare il server proxy aprire una shell e digitare

sudo apt-get -y install squid

Questo installerà i pacchetti necessari per il servizio proxy.

Configurazione

La directory di configurazione del server proxy è /etc/squid ed il file è squid.conf.

I file di log sono contenuti all'interno della directory /var/log/squid e contengono informazioni sugli accessi e sugli hit o miss di ogni pagina (ovvero sull'efficienza del proprio server proxy).

A tal proposito occorre precisare che il tasso di hit riflette l'efficienza del server proxy poiché tanto più alto è il numero di pagine richieste dai client e trovate nella memoria cache del sevrer proxy tanto minore sarà il numero di richieste che il server proxy stesso dovrà fare per ottenere tali pagine.

Tale fattore di efficienza dipende sia dalle dimensioni della cache che dal tipo di richieste dei client e solitamente anche dal tempo trascorso dalla fine del setup del proxy server.

Come detto il file per la configurazione del servizio proxy è /etc/squid/squid.conf. Adesso si vedrà nel dettaglio cosa bisogna modificare per ottenere un proxy perfettamente funzionante.

Innanzitutto, è necessario specificare l'indirizzo IP e la porta su cui il sevrer proxy sarà in ascolto attraverso la direttiva :

http_port 192.168.20.101:3128

In questo esempio è in ascolto sull'IP 192.168.20.101 e sulla porta 3128. Bisogna configurare l'IP e la porta su tutti i client che dovranno usufruire del servizio proxy.

A questo punto occorre specificare le dimensioni della memoria cache da usare per il servizio proxy come segue :

cache_mem 8MB

Nell'esempio, il valore predefinito è 8MB. È possibile modificarlo in base alle dimensioni della propria RAM.

Il valore di questo parametro dipende dalle dimensioni degli oggetti che il proxy deve memorizzare e dal numero di questi ultimi. Ad esempio, se si hanno 1000 client che richiedono ciascuno una pagina diversa delle dimensioni medie di 500KB servono 500*1000=500MB di cache!! Questo è un caso limite, ma aiuta a capire come determinare con semplici conti la quantità di cache necessaria.

Altri parametri importanti sono:

• maximum_object_size: gli oggetti con dimensioni maggiori di quelle riportate non vengono scritti su disco (ovvero non sono sottoposti a swapping)

• minimum_object_size: gli oggetti con dimensioni minori di quelle riportate non vengono scritti su disco (ovvero non sono sottoposti a swapping)

• maximum_object_size_in_memory: gli oggetti con dimensioni maggiori di quelle riportate non vengono mantenuti nella memoria cache (cioè vengono scartati)

E' evidente che l'ultimo parametro deve essere abbastanza alto da permettere che il più grande oggetto richiesto dai client serviti sia mantenuto nella cache, e pertanto tale valore dipende dalla "qualità" delle richieste dei client (ovvero dal tipo di pagine ed oggetti richiesti).

I parametri che seguono riguardano il tipo di algoritmi usati per la gestione della memoria cache e della RAM da parte del proxy :

• cache_replacement_policy lru: significa che il proxy rimpiazzerà gli oggetti nella cache usati meno di recente (least recently used algorithm)

• memory_replacement_policy lru: significa che il proxy rimpiazzerà gli oggetti nella memoria usati meno di recente (least recently used algorithm)

Generalmente questi parametri sono impostati in modo predefinito.

La direttiva successiva riguarda la directory su disco da usare come area di caching delle richieste degli oggetti pervenute al proxy dai client:

cache_dir ufs /var/spool/squid 80000 16 256

La directory è di tipo ufs (il tipo di filesystem usato per il caching dei documenti richiesti) e /var/spool/squid ed i parametri specificati di seguito sono:

• 80000: è la dimensione massima che questa directory può raggiungere prima che venga applicato l'algoritmo lru per lo svuotamento della cache stessa;

• 16: è il numero di sotto cartelle di primo livello create di default dal server proxy in /var/spool/squid;

• 256: è il numero di sotto cartelle di secondo livello create di default dal server proxy in /var/spool/squid

In generale, si potrebbe voler specificare una diversa cartella per il caching delle pagine squid (soprattutto se avete predisposto una partizione dedicata a ciò in fase di preparazione del sistema) ed un diverso valore della massima dimensione della memoria cache.

I parametri successivi riguardano i file di log e sono :

• cache_access_log in /var/log/squid/access.log: specifica il file contenente i log degli accessi (le richieste di oggetti pervenute al proxy)

• cache_log in /var/log/squid/cache.log: specifica il file di log che vi dice come si sta comportando il vostro server proxy (tasso di hit e miss delle pagine richieste)

• cache_store_log in /var/log/squid/store.log: specifica il log file che mostra dove e come sono gestiti gli oggetti nella cache

Il parametro successivo è:

• dns_nameservers 192.168.20.101: questo specifica l'IP del DNS cui devono essere girate le query DNS per la localizzazione degli host che posseggono le pagine richieste.

È evidente che il server proxy lavorerà a stretto contatto con un DNS, pertanto non sarebbe una cattiva idea implementare un caching DNS interno per velocizzare la risoluzione DNS.

Definizione delle ACL su backend LDAP

A questo punto viene la parte fondamentale ovvero quella in cui vengono definite le liste di controllo degli accessi in base alle quali il proxy selezionerà gli utenti ed i client che possono accedere ai servizi offerti dal proxy stesso.

La sezione fondamentale al riguardo è auth_param.

Poiché il nostro proposito è quello di configurare un proxy server le cui ACL siano definite in rapporto ad un backend LDAP , è necessario specificare il gruppo di utenti che saranno assoggettati ad autenticazione e l'eseguibile che dovrà interrogare il DB LDAP per convalidare le credenziali di accesso fornite.

I parametri da specificare sono:

• auth_param basic program /usr/lib/squid/squid_ldap_group -b dc=example,dc=com -f uid=%v

  questo dice al server proxy di usare il programma squid_ldap_group per autenticare tutti gli utenti LDAP del dominio base dc=example,dc=com (cambiatelo con il vostro)

• auth_param basic children 5

  questo dice che il numero di sottoprocessi di autenticazione allo startup del server proxy deve essere 5

• auth_param basic credentialsttl 2 hours

  questo vi dice che dopo 2 ore le credenziali di accesso dovranno essere reinserite perchè il vostro proxy le richiederà

• auth_param basic casesensitive on

  questo dice che il vostro proxy è case-sensitive ovvero che distingue fra maiuscole e minuscole sia per username che per password immesse dagli utenti.

• Dopo aver detto al proxy che dovrà usare il modulo LDAP per l'autenticazione degli utenti che gli si presenteranno si passa alla definizione delle liste di controllo di accesso al servizio come segue:

  acl example proxy_auth REQUIRED

  questo dice che il gruppo di utenti example può accedere al servizio solo se autorizzato (richiesta di credenziali di accesso username e password da confrontare con quelle dei corrispondenti utenti LDAP). Questo parametro identifica un meccanismo di sicurezza basato sul controllo utenti.

• acl example.com src 192.168.20.0/24

  questo dice che soltanto i clients della sottorete 192.168.20.0/24 possono usufruire del servizio proxy (cioè una macchina con IP 10.0.0.1 non potrà usare il servizio proxy neanche in caso di utente autorizzato). Questo parametro identifica un meccanismo di sicurezza basato sul controllo dei clients.

• acl hotmail dstdomain .hotmail.com

  questo parametro configura una lista dei controllo accessi per tutti gli oggetti appartenenti al dominio .hotmail.com (cioè tutti gli oggetti in esso inclusi). Come si vede le ACL possono essere definite a livello di utenti, di computer o di oggetti gestiti dal proxy.

Dopo aver definito il metodo di autorizzazione usato dal server proxy e le ACL definiamo le azioni del server proxy sulle ACL così definite (ovvero permetti o blocca).

I parametri a ciò deputati sono:

• http_access allow example 

  questo dice al server proxy di accettare le richieste provenienti dagli utenti del gruppo example (che sono tutti quelli definiti nel gruppo LDAP dc=example,dc=com) soltanto se sono autorizzati (vedi la definizione di ACL proxy_auth REQUIRED)

• http_access allow example.com

  questo dice al server proxy di accettare le richieste provenienti dai client che appartengono alla subnet 192.168.20.0/24

• http_access allow hotmail

  questo dice al server proxy di accettare le richieste di tutti gli oggetti che appartegono al dominio hotmail.com

• http_access deny all

  questo dice al server proxy di respingere ogni altra richiesta

Infine potremmo voler indicare il nome con cui raggiungere il vostro proxy con la direttiva seguente :

visible_hostname proxy.example.com

questo vuol dire che ai vostri clients potrete passare il nome del server proxy.example.com che gli servirà per configurare l'uso del servizio proxy

Dando un'occhiata al file squid.conf vi renderete conto che esistono moltissime altre direttive di configurazione che potrete usare per ottimizzare il vostro servizio , ma quelle esposte corrispondono a quelle strettamente necessarie per un coretto funzionamento dello stesso.

Altri tipi di autorizzazione

In generale squid è molto flessibile e supporta 4 metodi di autorizzazione per le ACL :

• PAM attraverso il modulo

  /usr/lib/squid/pam_auth

• NCSA : è il tradizionale metodo di autenticazione del server Web Apache che sfrutta il modulo

  /usr/lib/squid/ncsa_auth

• Gli utenti devono essere creati in un file con il comando htpasswd, esempio:

  htpasswd /etc/squid/proxyusers utente

  la direttiva da specificare in squid.conf è /usr/lib/squid/ncsa_auth /etc/squid/proxyusers

• SMB è l'autenticazione samba tramite il modulo

  /usr/lib/squid/smb_auth 

  la direttiva da specificare ha la seguente forma :

  /usr/lib/squid/smb_auth -W example.com

• LDAP che sfrutta un database LDAP e utilizza per il controllo accessi i moduli

  /usr/lib/squid/ldap_auth
  /usr/lib/squid/squid_ldap_group

  la direttiva da specificare ha la seguente forma :

  /usr/lib/squid/squid_ldap_group -b dc=example,dc=com -f uid=%v

---

CategoryServer CategoryDaRevisionare