Ok, se siete arrivati fino a questo punto vuol dire che la guida vi sembra interessante e, soprattutto, le vostre due installazioni di squid sono startate correttamente. E’ il momento di affrontare la fase di

Configurazione degli Squid

Ricordiamoci innanzitutto cosa vogliamo ottenere di base: lo Squid installato sulla DMZ deve fare da parent proxy per lo Squid installato sulla zona di workgroup. La configurazione che segue si occupa solo e soltanto di spiegarvi come ottenere l’effetto voluto da questa guida. E’ quindi necessario che facciate un po’ di scouting per conoscere e studiare i vari parametri di configurazione di Squid (che sono veramente un’infinità), in modo da creare una piattaforma che sia esattamente adatta alle vostre reali esigenze. Diciamo, più generalmente, che per riuscire in questa installazione, è necessario avere un po’ di dimestichezza con concetti classici di Squid, come le acl, i permessi di accesso relativi e altri parametri di configurazione base.

Configurazione parent proxy

Innanzitutto configuriamo i due nodi perchè comunichino in una gerarchia di “padre-figlio”. Per farlo è necessario impostare sul parent-proxy una acl che permetta all’host in WKG di contattare il servizio squid sulla porta di riferimento che, di default, è la 3128.
Qui un piccolo inciso è utile: generalmente si tende a modificare la porta di ascolto del proxy Squid portandola sull’8080 per aderire a degli standard classici di configurazione. Il consiglio che vi do è quello di NON utilizzare la porta 8080 per lo squid parent; questo perchè, tale servizio, per sua stessa natura (ricordiamoci che si trova in DMZ) dovrebbe essere messo in alta sicurezza e dovrebbe accettare connessioni in entrata solo dall’host sul quale è installato il “child”. Di conseguenza, anche utilizzare una porta considerata “non-standard” può aiutare.

Detto ciò passiamo ai parametri di configurazione. Aprite il file di configurazione squid.conf del parent-proxy e nelle righe relative alle acl di Squid, aggiungete questa:

e fra le righe di http_access aggiungete:

Con la prima istruzione create una acl chiamata child_proxy per tutte le richieste che abbiano un predefinito ip o fqdn. Con la seconda, semplicemente, state dicendo a Squid di accettare queste richieste.
In questo modo vi garantite che il vostro parent proxy riceva ed accetti richieste solo da parte del child proxy. Ricordiamoci, infatti, che stiamo maneggiando un applicativo in DMZ: dobbiamo sempre gettare un’occhio alla sicurezza.

ATTENZIONE: in questo esempio verranno prese in considerazione solo comunicazioni attraverso protocollo HTTP. Ovviamente se desiderate utilizzare anche comunicazioni via ICP o HTCP dovete abilitare la acl “child_proxy” anche nelle sezioni relative a questi due protocolli.

Ora abilitiamo la comunicazione fra il nostro parent proxy e l’istanza di Symantec Scan Engine che ci è stata messa a disposizione. I due prodotto parleranno via ICAP.
Raggiungete la parte di configurazione relativa a questo protocollo e aggiungete le seguenti righe (o decommentatele se le trovate già scritte):

Con la prima riga abilitate le comunicazioni via ICAP. Nella seconda definite il servizio icap che vi occorre, chiamandolo avscan in modalità respmod_precache e selezionate l’indirizzo e la porta dove è possibile individuarlo. Il nome “avscan” non è casuale: il servizio Symantec Antiviral Engine si chiama proprio così!
Le righe seguenti definiscono la classe icap a qui fa parte questa chiamata (il nome è avclass…potete definire ovviamente altri servizi icap nella stessa classe) e quindi (come per le istruzioni precedenti) consentiamo il servizio.
Ok la configurazione del nostro parent è conclusa. E’ il momento di passare al child!

Configurazione child proxy

Il chlld proxy sarà quello raggiungibile dai nostri clients e, quindi, per comodità, lo faremo salire sulla porta 8080, la classica porta per i proxy-server. Apriamo il solito file di configurazione squid.conf e andiamo alla riga relativa all’istruzione http_port:

Ovviamente se volete modificare la nostra porta di accesso al proxy, siete liberissimi di farlo!!!

Come detto questa installazione di squid ci permetterà di parlare con il nostro parent-proxy, far controllare il nostro contenuto all’oggetto Symantec e consentire l’utilizzo del proxy solo agli utenti autenticati sul nostro ldap-server. Non definiremo il tipo di ldap server poichè ognuno può utilizzare il proprio: tuttavia può esservi utile sapere che ho implementato questa soluzione con successo utilizzando l’ldap Tivoli Directory Service.
Per consentire l’accesso all’ldap, nel paragrafo relativo al sistema di autenticazione di squid aggiungiamo

Ovviamente potete aggiungere molte altri parametri alla vostra configurazione dell’ldap, eseguendo un po’ di tuning della vostra piattaforma. Anche qui: leggete leggete leggete…è l’unico vero modo di imparare! L’istruzione riportata sopra è abbastanza semplice: state invocando lo squid helper relativo a ldap (squid_ldap_auth), gli passate il vostro Base_Dn (è necessaria un po’ di conoscenza del sistema ldap per capire fino in fondo questa istruzione), gli specificate che la query ldap va costruita utilizzando come pattern “uid” e, infine, indirizzo e porta del vostro server ldap.

Per attivare l’autenticazione è necessario fare un ultimo passo: nella sezione delle acl aggiungete:

E’ il momento di dire al nostro child proxy che esiste un parent al quale deve essere collegato e dal quale deve attingere le informazioni di caching. Nella sezione relativa al cache_peer (che è la nostra istruzione fondamentale) aggiungiamo:

In questo modo il child proxy utilizzerà la cache del parent per rispondere alle requests dei clients. Per informazioni aggiuntive sul tipo di istruzione e sui parametri relativi ed aggiuntivi rimando alla documentazione ufficiale di Squid.

In ultimo, per linkare anche il nostro child proxy ad una istanza di Symantec Scan Engine per il controllo dei contenuti web, è possibile replicare le istruzioni già inserite nel parent.

Ovviamente ha senso duplicare il controllo sui web contents sia sul parent che sul child solo in caso di alto carico sul proxy, laddove può essere utile avere una istanza di Scan Engine che si occupa (per esempio) solo di blacklist-check e un’altra che si occupa solo dello scanning vero e proprio dei web contents.

Conclusioni

Mi sembra di aver detto praticamente tutto quello che vi è necessario sapere per comprendere (innanzitutto) e in secondo luogo implementare un’architettura di proxying complesso e distribuito per ambienti molto grandi di respiro enterprise. Nella guida l’architettura si compone di Squid in versione 3.0 STABLE1: sul sito ufficiale di Squid (http:www.squid-cache.org), che vi consiglio di visitare per conoscere meglio i segreti di questo capolavoro dell’opensource, potete già trovare la versione 3.1. Questa guida non è stata testata con la nuova versione: resta inteso che potrebbe funzionare…magari sarà necessario adattare qualcosa ma… d’altronde è il mestiere del sistemista!

Buona vita
Daniele

Bookmark It