1.1. Pubblicazioni su carta

RedHat Magazine - The journal for Linux System Administrators (Anno I - Num. 3 - Marzo/Aprile 2003) - WPAD: riconoscimento automatico del proxy server (pagina 10) - l'articolo è un dettagliato approfondimento del capitolo relativo al WPAD Protocol che contiene la descrizione di una vera e propria soluzione "corporate".

1.2. Note sul libro

Questo libro viene fornito con le stesse garanzie della maggioranza dei software commerciali: non esiste alcuna garanzia, né implicita, né esplicita relativamente all'adeguatezza per uso particolare o per la commerciabilità. L'autore non si assume alcuna responsabilità per eventuali danni diretti o indiretti che questa documentazione potrebbe arrecare al vostro sistema informatico. L'utilizzo è a Vostro rischio e pericolo ;-)

1.3. Note sull'autore

Stefano Tagliaferri è Network & Security manager, System Engineer e Red Hat Certified Engineer, le principali specializzazioni sono la progettazione di infrastrutture informatiche, tecnologiche, dei sistemi informativi e delle reti perimetrali. Le conoscenze sistemistiche vanno dagli apparati di rete della Cisco Systems (routers, firewall ecc..) alle piattaforme UNIX®-like (Linux e *BSD) nonchè sistemi Windows (NT/Active Directory) ed OS/2.

1.4. Altre annotazioni

Questo libro si è perfezionato senza tenere conto di eventuali protezioni di brevetti d'invenzione, inoltre i nomi coperti da eventuale marchio registrato vengono utilizzati senza tenerne conto.

1.5. Licenza d'utilizzo

Questo libro viene rilasciato sotto la GNU Free Documentation License ( http://www.gnu.org/licenses/licenses.html), chiunque può modificarlo e migliorarlo rispettandone la sola proprietà intellettuale dell'Autore o di chi con l'Autore ha collaborato, citando in modo visibile, in tutte le sue pagine: "Versione originale di Stefano Tagliaferri (squid(at)merlinobbs.net - http://www.merlinobbs.net), alla stesura di alcune parti del documento ha partecipato Leo Pedone (lan.to(at)tiscalinet.it). Questo libro è rilasciato sotto GNU Free Documentation License - © 1999 - 2005 Stefano Tagliaferri". L'autore e chi ha collaborato alla realizzazione di questa opera si riservano il diritto di rilasciare opere derivate utilizzando licenze diverse.

Per divenire mirror autorizzato della distribuzione in HTML o in altri formati è necessario richiedere espressa autorizzazione a Stefano Tagliaferri (squid(at)merlinobbs.net),l'elenco dei mirror autorizzati dall'autore viene specificato in un capitolo del libro stesso.

Il censimento dei mirror, oltre ad essere una questione di pura "statistica", consente anche di mantenere una versione sempre aggiornata e centralizzata dell'opera.

Questo libro si è perfezionato senza tenere conto di eventuali protezioni di brevetti d'invenzione, inoltre, i nomi coperti da eventuale marchio registrato vengono utilizzati senza tenerne conto.

1.6. Riferimenti

La presente documentazione fa parte del progetto Squid (http://www.squid-cache.org/Doc/#non-english). Oltre al lavoro svolto personalmente ed ai contributi di Leo Pedone, Federico Lombardo, Guido Serassio e Antonio Fragola, cito anche tutti i riferimenti che hanno permesso la stesura di alcune parti di questo documento

• URLs del progetto Squid: http://www.squid-cache.org/

• Mirror italiano del progetto Squid: http://www1.it.squid-cache.org/

• URLs Security Focus per la security: http://www.securityfocus.com/

• Squid Frequently Asked Questions (FAQ) ©2001 Duane Wessels: http://www.squid-cache.org/Doc/FAQ/

• Squid Configuring Hierarchical Squid Caches di Duane Wessels: http://www.squid-cache.org/Doc/Hierarchy-Tutorial/

• Squid Programmers Guide di Duane Wessels: http://www.squid-cache.org/Doc/Prog-Guide/

• Squid User's Guide di Oskar Pearson: http://squid-docs.sourceforge.net/

• IRCache Project: http://www.ircache.net/

• Benefits of Web Caching di Joe Cooper alla URLs: http://www.swelltech.com/support/benefits/

• Designing a Web Caching Infrastructure for Your Network di Joe Cooper alla URLs: http://www.swelltech.com/support/sizecache/index.html

1.7. Convenzioni utilizzate

• corsivo

  con questo tipo di carattere verranno indicati i nomi di prodotto, i comandi del sistema operativo, i termini più importanti e significativi, i nomi delle directory nei sistemi Unix®

• codice

  questo è un esempio di codice

  la riga di comando del sistema operativo, il codice sorgente, il contenuto dei file di log, i TAG del file di configurazione

• il carattere %

  % ls -l /usr/local/etc

  indica il prompt della shell ovvero delimita l'inizio della riga di comando nei sistemi Unix®

• il carattere \

  % snmpget -m SQUID-MIB -c public localhost:3401 \ enterprises.nlan

  indica il frazionamento per una linea di comando UNIX®

• il carattere #

  # commento al codice sorgente o al TAG

  indica uno o più commenti al codice sorgente o al listato originale o ancora indica i commenti ai TAG del file di configurazione

2.1. Preambolo

Squid è il più conosciuto nonchè il più utilizzato dei Proxy Server attualmente in commercio, il suo codice sorgente è libero e fornisce funzionalità di caching e proxing per il traffico HTTP, FTP e Gopher. Squid può anche essere utilizzato come motore HTTP/HTTPs per eseguire avanzate tecniche di reverse proxy. Il progetto nasce come evoluzione di CERN HTTP Server che già nel lontano 1994 includeva un modulo per la gestione della cache. Il progetto Harvest nacque nel 1994 per migliorare i sistemi di gestione della cache ma ebbe vita molto breve visto che fù sciolto nell'anno successivo. Il progetto Harvest fù ripreso sia a scopi commerciali (Network Appliance) che a scopi scientifici determinando la nascità di Squid. Duane Wessels è l'autore di Squid che durante il lavoro svolto presso il National Laboratory of Applied Network Research (NLANR), all'interno del gruppo Information Resource Caching (IRcache) fondato dalla National Science Foundation, riprese in mano il progetto originario Harvest e lo rinominò in Squid che fù rilasciato secondo l'accordo di licenza GPL General Pubblic License (http://www.gnu.org/copyleft/gpl.html).

2.2. Il Core Development Team

Il Core Development Team di Squid ad oggi é composto da:

• Adrian Chadd

• Alex Rousskov

• Duane Wessels

• Francesco "Kinkie" Chemolli

• Guido Serassio

• Henrik Nordström

• Joe Cooper

• Robert Collins

Maggiori dettagli sono disponibili su http://dokuwiki.squid-cache.org/doku.php?id=dev:developers/.

2.3. Un programma libero

Come abbiamo detto, Squid è un programma libero (Free Software) ed è coperto da copyright "Regents of the University of California San Diego" (http://www.squid-cache.org/Doc/FAQ/squid-copyright.txt) e può essere ridistribuito e modificato secondo quanto previsto dall'accordo della Licenza Pubblica GNU (http://www.gnu.org/licenses/licenses.html) e viene distribuito all'utente finale senza nessuna garanzia.

Nella GNU Pubblice License (http://www.gnu.org/licenses/gpl.html) sono contenuti tutti i dettagli che regolano la distribuzione del prodotto, come già sappiamo Squid trae le sue origini dal programma cached che fu realizzato dalla ARPA-Founded Harvest Research. Per distinguere questo nuovo prodotto da quello realizzato dalla Harvest, Duane Wessels decise di chiamarlo con il nome del progetto iniziale: Squid ovvero "il calamaro". Henrik Nordstrom, uno dei migliori hackers del progetto Squid, a tale proposito afferma: "il nome Squid non è una abbreviazione, il calamaro è un animale marino che in qualche modo si comporta proprio come il nostro proxy. Le cache gerarchiche ed il protocollo Internet Cache Protocol (ICP) possono essere paragonati ai tentacoli utilizzati da un calamaro per fare suo tutto quello che lo interessa" (http://www.squid-cache.org/mail-archive/squid-users/200404/0954.html).

2.4. Mailing lists

Per migliorare l'utilizzo di Squid, le sue funzionalità, le performance e per contribuire al lavoro di miglioramento nonchè alla continua correzione dei problemi, è possibile aderire a cinque mailing lists

• squid-users@squid-cache.org - discussioni generali sull'utilizzo di squid

• squid-announce@squid-cache.org - lista per il rilascio delle nuove release

• squid-bugs@squid-cache.org - lista per l'annuncio dei nuovi bugs e problemi

• squid@squid-cache.org - lista per il feedback e nuove idee

• squid-faq@squid-cache.org - lista per il feedback, gli aggiornamenti e contributi addizionali per le Squid FAQ

mailing lists non strettamente legate al progetto Squid

• cache-snmp@ircache.net - lista sulle implementazioni del protocollo SNMP in ambito webcaching

• icp-wg@ircache.net - lista dell'ICP Working Group e di Internet Engineering Task Force (IETF - http://www.ietf.org/)

2.5. Le origini dello Squid-Book

Questo saggio nasce nell'estate del 1999 perchè all'epoca, in Italia, ancora nessuno aveva avuto l'idea di scrivere della documentazione su Squid per facilitarne e sponsorizzarne l'utilizzo. In particolare il documento prendeva corpo come risposta alle esigenze dei partecipanti del gruppo di discussione della rete usenet italiana it.comp.os.os2.

Gli utenti del gruppo desideravano avere maggiori informazioni sulle funzionalità di Squid ed allora decisi di creare quello che nessuno in Italia aveva mai realizzato: le FAQ in lingua Italiana.

Le prime versioni dell'opera sono state pubblicate alla URLs http://merlino.ghostbbs.cx/, in seguito, le nuove versioni, complete di nuove informazioni, sono state pubblicate alla URLs http://www.merlinobbs.net/.

Negli anni la documentazione è rimasta a disposizione della comunità internet sino a quando alcuni individui decisero di copiare l'opera perseguendo evidenti scopi di lucro: la pubblicazione avvenne senza avvertire e/o citare i legittimi proprietari del lavoro.

Alla nascita ed allo sviluppo primordiale di questo documento ha collaborato con grande entusiasmo Leo Pedone (lan.to(at)tiscalinet.it), al quale sarò sempre grato per tutti i grandi ed i piccoli insegnamenti che mi ha voluto donare. Anche se il documento ben presto divenne un vero e proprio punto di riferimento per chi lavorava nell'ambito delle interconnessioni di rete, nessun membro della comunità OS/2 italiana ha mai contribuito allo sviluppo successivo o all'integrazione dell'opera.

Per questi motivi e per altre questioni che in questo contesto non sono degne di nota, l'opera non è stata più disponibile agli utenti internet. Contemporaneamente decisi di abbandonare lo studio e la ricerca sulla piattaforma OS/2 e tutte le modifiche apportate successivamente al documento si sono evolute, in prima istanza, sulla piattaforma GNU Linux. In particolare molte informazioni contenute in questo tomo fanno riferimento alla distribuzione commerciale Red Hat Linux (http://www.redhat.com).

Viste le politiche di supporto e il nuovo modello commerciale imposto dall'attuale business alle varie distribuzioni Linux, negli ultimi tempi si è provveduto a migrare tutte le configurazioni operative e di produzione sulla piattaforma FreeBSD (4.10-STABLE e 5.3-STABLE).

Con il rilascio della versione 1.27 questo libro è tornato nuovamente a disposizione degli utenti internet. L'idea nacque durante una discussione con gli amici del Latina LUG (http://www.llg.it/) e l'unico vincolo imposto all'utilizzo del libro è il rispetto della licenza GNU Free Documentation License e delle note in "addendum" volute dall'autore stesso.

Qualche anno fa questa era l'umile FAQ aperta al contributo di tutti coloro che utilizzavano Squid in Italia.

2.6. Chi sviluppa oggi lo Squid-Book

Attualmente il progetto "Italian Squid-Book: oltre le FAQ" viene sviluppato da una squadra di professionisti e di ricercatori nel campo dell'ICT, queste persone si sono poste l'ambizioso obiettivo di rendere questo lavoro un vero e proprio punto di riferimento multipiattaforma in lingua italiana

• responsabile del progetto: Stefano Tagliaferri

• schemi di autenticazione ed integrazione in Active Directory, progetto Squid per Windows: Guido Serassio

• integrazione in Active Directory, external ACL, sicurezza e sistemi di logging: Federico Lombardo

• revisioni, forma espositiva, formattazione e rilascio delle nuove versioni: Stefano Tagliaferri

• formattazione e distribuzione nei vari formati incluso SGML: Antonio Fragola aka Mr.Shark

Le ultime versioni del libro che hanno ampliato e sviluppato piuttosto approfonditamente tutte le funzionalità più importanti offerte da Squid, riflettono fondamentalmente due tipi di approccio sull'utilizzo del Proxy stesso. Da una parte c'è l'utente ed il sistemista di rete esigente, che viene impersonificato dal lavoro svolto da Stefano, dall'altra c'è l'approccio proprio del programmatore che viene impersonificato dalla figura di Guido. Le due concezioni nell'approccio all'utilizzo di Squid finiscono per fondersi dando all'opera quel tocco di fruibilità e di funzionalità che certo non guasta e rende interessante l'intero progetto documentale. Lo Squid-Book rimane comunque aperto all'eventuale contributo di nuovi sviluppatori, per maggiori dettagli fare riferimento al responsabile del progetto.

2.7. Squid, il software libero e la situazione Italiana

I proxy servers, oltre ad essere utilizzati anche sulla rete internet, vengono installati soprattutto nelle LAN/WAN private di grandi dimensioni. Come vedremo in seguito, gli amministratori di rete possono trarre grande vantaggio dall'utilizzo di Squid grazie alle sue comprovate capacità di velocizzazione, di controllo sugli accessi, di gestione delle risorse e del suo elevatissimo livello di sicurezza.

In Italia sino a qualche anno fa era molto difficile trovare in produzione dei software Open Source con queste caratteristiche, molto spesso il compito di caching veniva affidato ad alcuni software commerciali che non presentavano nè la stabilità nè le performance applicative che sono proprie di un prodotto come Squid Proxy. La situazione, grazie anche a questo documento, sta rapidamente evolvendo ed il numero dei programmi installati è in continua crescita.

Ancora una volta ci troviamo di fronte il dilemma tra lo scegliere un prodotto commerciale che viene supportato da uno specifico produttore, ed il software libero che viene invece sorretto da una immensa comunità di sviluppatori, appassionati ed utenti. Le risorse economiche del business contrapposte alla conoscenza, alla genialità ed all'ingegno. L'immobilità della cattedrale contrapposta con la velocità del modello bazar (cfr. saggio di Eric S. Raymond disponibile alla URL http://www.apogeonline.com/openpress/doc/cathedral.html).

3.1. Preambolo

Prima di iniziare a trattare questo argomento è fondamentale effettuare alcune premesse per comprendere le funzionalità di un sistema proxy dedicato che esegue anche tecniche di webcache.

Squid è un proxy server ovvero è un intermediario di una transazione HTTP che accetta le richieste provenienti dai client (browser web) e le processa eseguendone il forward verso il server di origine. Le richieste possono essere registrate e modificate anche prima che vengano girate al server di origine.

Squid è un apparato di webcache che registra i contenuti web in uno spazio disco dedicato e quando possibile ne riutilizza il contenuto, i contenuti web prendono il nome di oggetti (object), gli oggetti presenti nella cache prendono il nome di HIT mentre gli oggetti che non sono stati memorizzati prendono il nome di MISS.

3.2. Fattori basilari che intervengono nella trasmissione dei dati

Prima iniziare ad analizzare il funzionamento di un sistema di caching e prima di affermare che lo stesso può aiutare a migliorare le performance riducendo eventualmente anche i costi, analizziamo alcuni dei fattori che intervengono nella trasmissione dei dati

3.3. Come lavora un apparato di webcache

Per quanto corcerne qualsiasi aspetto del calcolo con gli eleboratori elettronici ed i sistemi di rete il concetto di caching è uno standard. I microprocessori includo una cache per le istruzioni ed una per i dati, i sistemi operativi utilizzano la cache per lavorare con le unità a disco e con i filesystems. I filesystem distribuiti come NFS (Network File System) ed AFS (Andrew File System) utilizzano un sistema di caching che gli consente di ottenere delle prestazioni superiori alla media, anche il Domain Name System (DNS) ricorre ad un sistema di cache che gli consente di memorizzare la risoluzione dei nomi degli host nei corrispondenti indirizzi IP.

Un dispositivo di webcache memorizza una copia degli oggetti web e dei dati maggiormente richiesti in uno spazio disco dedicato (cfr. capitolo dedicato al Cache Store di Squid). Un utente che si trova all'interno di una rete che non fa ricorso all'utilizzo di questi apparati visualizzerà una pagina web eseguendo una richiesta diretta che verrà inoltrata dal proxy al servente remoto. Il giorno successivo lo stesso utente richiederà nuovamente quella pagina web e probabilmente ne disporrà di una copia memorizzata nella cache del suo browser. Se nello stesso momento più utenti all'interno della medesima rete richiederanno l'accesso alla stessa pagina web, effettueranno ciascuno una connessione al server d'origine utilizzando sempre la stessa banda. L'installazione di una o più device di webcache consente di richiedere il contenuto di un oggetto web una sola volta per poi memorizzarlo sulla cache locale rendendolo disponibile a tutti gli utenti.

3.4. Riduzione delle esigenze di banda

Quando una device di webcache viene inserita in un network sarà il solo apparato di rete abilitato a contattare i serventi di origine dei dati. In questo contesto l'apparato viene normalmente situato all'interno di una Local Area Network (LAN) e solo gli utenti accreditati all'interno di quella rete potranno accedervi. I dati transiteranno unicamente sulla rete locale senza appesantire le esigenze di banda relative alla connettività internet ed il maggior traffico dati avverrà tra il client (browser web) e l'apparato di webcache stesso.

3.5. Fattori che determinano il risparmio di banda

Il relativo risparmio di banda che abbiamo già quantificato in precedenza con un valore percentuale tra il 30% e il 40% nel caso di pagine totalmente statiche, può variare sulla base di diversi fattori.

3.6. Controllo e sicurezza

Vedremo in seguito come un'apparato di webcache sia in grado di migliorare la sicurezza della rete. Nell'ambito di una organizzazione commerciale circa il 40% degli utenti visitano dei siti internet che non hanno nulla a che vedere con l'attività "core business" dell'organizzazione stessa.

L'utilizzo di uno strumento come Squid quale device di webcache consente di pianificare e stabilire delle regole che potrebbero rappresentare la politica di utilizzo delle risorse internet. Nell'ambito delle normative vigenti in materia di "data privacy" Squid consente di sorvegliare il rispetto delle regole predefinite ed i log del proxy possono anche essere utilizzati per creare dei report sugli accessi; inoltre consentirà agli amministratori di rete di mettere in pratica la politica di sicurezza filtrando i siti secondo i criteri impostati all'interno della policy stessa.

Nel segmento di rete che si trova all'interno dell'organizzazione è possibile collegare l'apparato di webcache con il database aziendale che assolve ai servizi di directory (il database che si occupa di eseguire l'autenticazione e l'autorizzazione degli utenti). In questo caso Squid controllerà le corrette autorizzazioni relativamente all'accesso utilizzando diversi schemi di autenticazione che tratteremo dettagliatamente in seguito.

Squid come apparato di webcache può dunque incorporare un database di siti internet accessibili o vietati e tale sistema può contenere delle parole chiave (keyworld) in grado di identificare i siti da rendere irraggiungibili (ad es. siti pornografici, video giochi, internet radio ecc....).

In definitiva un sistema di webcache si occupa di gestire la "policy" internet, le politiche di accesso per classi di indirizzi IP o di singoli indirizzi e, per finire, può eseguire delle limitazioni per i gruppi di utenti che accedono al sistema.

3.7. Una piccola panoramica su HTTP

Clients e servers utilizzano diversi protocolli di trasporto per scambiare informazioni, questi protocolli vengono trasportati all'interno del TCP/IP e rappresentano la maggioranza del traffico internet oggi. HTTP è l'acronimo di Hypertext Transfer Protocol (HTTP - RFC 2616 - http://www.ietf.org/rfc/rfc2616.txt) e si tratta di un metodo standard per l'invio dei documenti attraverso la rete web. In particolare possiamo definire HTTP come un protocollo di livello sette che viene utilizzato per trasferire gli ipertesti tra gli HTTP servers (Apache, Internet Information Server, etc) e gli HTTP client (Mozilla, Opera, Konqueror, Internet Explorer....). HTTP ricorre al protocollo TCP per trasportare i pacchetti sulla rete, stabilendo dunque una connessione TCP tra il client ed il server. Gli HTTP server sono anche conosciuti come server web e normalmente restano in attesa di richieste sulla porta 80. Gli HTTP client prendono il nome di browser web e per trasferire le informazioni dal server utilizzano una richiesta conforme al protocollo HTTP 1.1 oppure ricorrono ad una richiesta conforme con la vecchia implementazione HTTP 1.0.

3.8. Una piccola panoramica su FTP

File Transfert Protocol (FTP) è stato ed è ancora uno dei protocolli più importanti utilizzati sulla rete internet, a partire dal 1971 lo standard per il trasferimento dei file è sempre stato rappresentato dal protocollo FTP. Lo standard attuale per questo protocollo che viene definito dalla RFC 959 (http://www.ietf.org/rfc/rfc0959.txt?number=959) che è molto differente dalla specifiche originarie che furono definite nella RFC 172 (http://www.ietf.org/rfc/rfc0172.txt?number=172). FTP utilizza un canale di controllo per i comandi ed un canale separato per i dati che vengono trasferiti. Prima che avvenga un trasferimento di dati devono essere utizzati circa 6 comandi all'interno del canale di controllo, i client possono accedere al server FTP solo dopo essersi autenticati tramite l'utilizzo di una userid e di una password. Molti server FTP possono essere configurati per dare accesso anonimo agli utenti, il protocollo FTP supporta inoltre diversi comandi come CWD (change working directory) e LST (directory listing).

3.9. Una piccola panoramica su SSL/TSL

Netscape nel 1994 ha inventato il protocollo Secure Socket Layer (SSL) per promuovere l'applicazione e l'evoluzione del commercio elettronico sulla rete internet. SSL fornisce un canale crittografato del tipo end-to-end tra il client ed il server. Prima che venisse scoperto questo tipo di protocollo le transazioni avvenivano in chiaro e potevano tranquillamente essere intercettate (sniffate). La standardizzazione del protocollo SSL è stata portata all'interno dello IETF[1] dove ha preso il nome di Transport Layer Security (TLS) e viene documentata nella RFC 2246 (http://www.ietf.org/rfc/rfc2246.txt?number=2246). Il protocollo TLS non è legato al protocollo HTTP e può essere utilizzato con altre applicazioni come la posta elettronica, quando parliamo di HTTP e TSL dovremmo utilizzare il termine HTTP over TSL che viene descritto nella RFC 2818 (http://www.ietf.org/rfc/rfc2246.txt?number=2818).

3.10. Una piccola panoramica su Gopher

Il protocollo Gopher è piuttosto simile alle specifiche dell'HTTP/0.9. Il client invia una singola linea di richiesta alla quale il server risponde con l'invio dei contenuti richiesti, tutte le opzioni fornite da HTTP/1.0 ed HTTP/1.1 hanno reso il protocollo del gopher obsoleto.

3.11. Una piccola panoramica su WWWCACHE

Il world wide web cache viene implementato dai proxy server. Come abbiamo visto anche in precedenza, normalmente i browser web effettuano una connessione diretta al server HTTP contattandone la porta 80, ma possono anche essere configurati per raggiungere direttamente ai proxy server: in tal caso è specificatamente quest'ultimo che inoltra le richieste al server web, frapponendosi e mediando la connessione. La memoria cache del Proxy si occupa di salvare sul disco le pagine web che sono state maggiormente richieste, rendendone così la consultazione veloce ed immediata. Come abbiamo visto uno dei benefici indotti dall'utilizzo dei proxy server è quello di ridurre il traffico, nelle WAN di grandi dimensioni ed in presenza di pagine statiche, una cache web può ridurre il traffico HTTP anche del 30% - 40%.

3.12. Cosa sono le cache gerarchiche

Le cache gerarchiche sono un'estensione logica del concetto di cache, le cache gerarchiche utilizzano i protocolli di intercache, questo tipo di protocolli forniscono delle informazioni che possono essere utilizzate da un apparato di webcache per ridurre il tempo di ricerca di un oggetto. Un gruppo di proxy server può trarre beneficio dalla condivisione degli oggetti contenuti nella propria cache così come un gruppo di client (browser). Tuttavia, oltre ai vantaggi, é possibile identificare anche possibili aspetti negativi che possono essere determinati da situazioni specifiche

• I principali vantaggi sono

  • un maggior numero di cache hits: in generale, ci si può aspettare che almeno il 10% delle richieste ricevute da una cache si traducano in cache hit (risposte positive) in quelle adiacenti

  • routing delle richieste: eseguendo un routing verso una certa cache adiacente, é possibile instradare il traffico HTTP su un determinato percorso. Per esempio, avendo due link di connessione con la rete internet, é possibile instradare il traffico HTTP su uno dei due, lasciando il secondo collegamento a disposizione per tutti gli altri utilizzi

• Alcuni possibili svantaggi possono essere

  • maggiore complessità della configurazione: per ogni singola relazione di "parentela" é necessario coordinare gli interventi di configurazione di entrambi i nodi coinvolti ed al crescere del numero delle cache componenti la gerarchia, l'attività di configurazione tende a divenire più impegnativa

  • maggiore ritardo nella risoluzione di un cache miss (risposta negativa): il fatto che l'utilizzo od il mancato utilizzo di una cache adiacente si traduca in un aumento della velocità percepita dall'utente finale può dipendere da svariati fattori: il ritardo tra i nodi, la congestione dei link, l'utilizzo o il mancato utilizzo di protocolli di comunicazione intercache ed altro ancora

Squid offre supporto per le seguenti architetture di cache gerarchiche

• Internet Cache Protocol (ICP)

• Cache Array Routing Protocol (CARP)

• Hyper Text Caching Protocol (HTCP)

• Cache Digest

3.13. Concludendo

Squid HTTP Proxy è il più conosciuto nonchè il più utilizzato dei Web Proxy Server che fornisce funzionalità di caching e proxing per il traffico HTTP, FTP e Gopher. Fornisce inoltre un framework per il webcaching, per il controllo degli accessi e per il controllo dei contenuti. Squid può anche essere utilizzato come motore HTTP/HTTPs per eseguire avanzate tecniche di reverse proxy. Il motore della sua webcache è stato anche disegnato per supportare le connessioni di tipo SSL/TLS (Secure Soket Layer/Transport Layer Security). Squid controlla completamente gli accessi grazie alle sue potenzialità di logging delle connessioni, inoltre supporta il concetto di caching cooperativo implementando protocolli come ICP, HTCP e Cache Digest. Per finire il sistema di cache storage, o memoria cache di Squid, viene sistemato gerarchicamente ed esistono diversi strumenti che consentono di interpretare anche visivamente i log delle transazioni.

A livello applicativo Squid è composto da un proxy server vero e proprio e da diversi programmi esterni. Nelle prime versioni uno dei programmi esterni che veniva maggiormente utilizzato era l'applicazione che effettuava la risoluzione dei nomi, ovvero assolveva il compito di tradurre il nome internet nel corrispettivo indirizzo IP. Nel contesto attuale uno dei programmi esterni più diffusi è quello che consente di eseguire l'autenticazione degli utenti. A partire dalla release 2.3, la risoluzione dei nomi viene demandata direttamente al server DNS presente sulla LAN/WAN (ISC Bind) o, in alternativa, al server DNS di proprietà dell'Internet Service Provider. Oggi Squid risolve i nomi di dominio utilizzando lo standard di tutti i Sistemi UNIX®, riferendosi direttamente ai server DNS che sono stati specificati nel file /etc/resolv.conf.

4.1. Preambolo

In particolari situazioni la scelta del sistema operativo può essere un fattore decisivo, molte organizzazioni scelgono un tipo di sistema operativo per la gestione delle loro infrastrutture focalizzando l'attenzione unicamente sui prodotti supportati da quel sistema. In molti casi è l'hardware che determina la scelta del sistema operativo, una macchina a 64 bit basata sul prodotto Sun richiede il sistema operativo Sun Solaris. Vi sono diverse possibilità di scelta nel caso in cui si disponga di macchine basate sull'architettura IA32[4], infatti con questo tipo di configurazione è possibile scegliere tra molti dei sistemi UNIX® a codice libero come Linux, FreeBSD, NetBSD ed OpenBSD. Per l'architettura IA32 sono anche disponibili i sistemi UNIX® proprietari come SCO e Solaris nonchè i vari sistemi Windows come NT, 2000 e 2003.

Nel caso dovessimo trovarci nella fortunata condizione di poter scegliere tra vari sistemi operativi, dovremmo tenere in considerazione alcune caratteristiche di un sistema operativo che ci consentiranno di orientare per il meglio la nostra scelta

1. la stabilità del sistema è un requisito fondamentale per ottenere la continuità del servizio, un sistema stabile è sempre disponibile per l'utilizzo, si consiglia di consultare la rete usenet per capire le differenze tra vari sistemi operativi

2. la sicurezza del sistema è un requisito fondamentale se si vuole realizzare un ambiente idoneo ad eseguire un proxy server. Verificheremo i tempi di rilascio delle patch da parte dei vari produttori nel caso dovessero insorgere problematiche legate alla sicurezza. Tra i sistemi a codice libero, OpenBSD è un sistema operativo interamente focalizzato sulla sicurezza

3. la facilità di utilizzo del sistema è un'altro elemento importante e varia da amministratore ad amministratore. Abbiamo chi preferisce utilizzare il mouse è chi trova confortevole utilizzare la riga di comando

4. il servizio di supporto al sistema è un'altro elemento importante, per alcune organizzazioni può divenire un elemento vitale. I sistemi proprietari come Windows, SCO, OS/2, Solaris ed alti vengono supportati dai rispettivi produttori, mentre i sistemi a codice libero come Linux, FreeBSD, OpenBSD e NetBSD vengono invece supportati dalla comunità degli sviluppatori

5. le prestazioni sono un altro elemento determinante, nel nostro caso è fondamentale utilizzare un sistema operativo che garantisca eccellenti tempi di I/O e che implementi un file system affidabile (UFS, Ext2, Ext3, RaiserFS sono solo alcuni esempi)

per concludere diciamo che Squid è stato disegnato per funzionare con qualsiasi sistema UNIX® di nuova generazione, di seguito elenchiamo tutti i sistemi operativi con i quali è oggi possibile utilizzare Squid proxy server

• Linux

• FreeBSD

• NetBSD

• OpenBSD

• BSDI

• OSF and Digital Unix®

• IRIX

• SunOS Solaris

• NeXTStep

• SCO Unix

• AIX

• HP-UX

• OS/2

• Windows NT

• Windows 2000

• Windows 2003 & XP

i problemi che possono essere ricondotti alle specifiche piattaforme devono essere segnalati sulla mailing list squid-bugs@squid-cache.org

4.2. Piattaforme specifiche

In questo capitolo è nostra intenzione trattare alcune delle piattaforme e dei sistemi operativi sui quali viene oggi sviluppato Squid. OS/2 è la piattaforma sulla quale si è sviluppato inizialmente questo documento, GNU Linux e FreeBSD sono le piattaforme UNIX® per eccellenza mentre la piattaforma Windows rappresenta un nuovo ramo nello sviluppo di Squid. Su questi sistemi operativi sono stati eseguiti i test e sono anche state provate moltissime delle configurazioni che verranno trattate in seguito.

4.3. Sistemi UNIX®

Come abbiamo detto Squid è un software studiato per i sistemi UNIX® di ultima generazione e da diverso tempo Linux e FreeBSD si sono dimostrate tra le piattaforme migliori.

4.4. Sistemi Windows

A partire dalla versione 2.5.STABLE1, Squid é disponibile anche per i sistemi Windows e può essere compilato con due differenti modalità

1. modalità nativa

2. modalità emulata

La modalità emulata si caratterizza per un livello di prestazioni inferiori, mentre la modalità nativa può non supportare alcune delle funzionalità che sono disponibili per altri sistemi operativi. In modalità nativa, Squid può essere compilato utilizzando l'ambiente di sviluppo Open Source MinGW (http://www.mingw.org/) o utilizzando l'ambiente di sviluppo proprietario Microsoft Visual Studio 6.0 SP5. In modalità emulata Squid viene compilato utilizzando l'ambiente Open Source Cygwin (http://www.cygwin.com/), purchè sia stato correttamente installato e configurato anche sul sistema sul quale si intende eseguirlo.

Le configurazioni trattate da questo libro si applicano per entrambi gli ambienti e sono state solitamente implementate su macchine Windows 2000 e testate da Guido Serassio. Il progetto di porting di Squid su Windows è sponsorizzato da Acmeconsulting S.r.l. e viene seguito in prima persona da Guido Serassio. Gli eseguibili per le piattaforme Win32 e tutte le informazioni sullo stato di avanzamento del progetto possono essere reperite alla URL http://www.acmeconsulting.it/SquidNT/.

4.5. Sistemi OS/2

Il porting di Squid per OS/2 viene effettuato tramite alcune librerie di runtime denominate EMX (http://homepages.tu-darmstadt.de/~st002279/os2/html/porting.html) ovvero "The UN*X to OS/2-EMX Porting", l'autore del porting è Peter Meerwald <seawood(at)very.priv.at> e non è previsto alcun supporto commerciale. Attualmente è in fase di sviluppo il progetto "Squid Cache Version 2.5.OS2_VAC", si tratta del port di Squid-2.5 sviluppato in maniera nativa utilizzando lo strumento VACPP. Maggiori informazioni sul progetto sono disponibili alla URLs http://www.laser.ru/evgen/soft/Squid2/index_l.html.

5.1. Preambolo

Nel 1998 è stata sviluppata la versione 2 di Squid ed in questa release sono state introdotte moltissime migliorie progettuali che gli hanno poi consentito di affermarsi come una delle migliori applicazioni nel suo segmento di mercato.

Tra le varie novità possiamo citare

• un basso utilizzo della VM (Virtual Machine)

• gli oggetti in transito non vengono salvati nella memoria RAM

• le directory dedicate al cache storage possono anche essere indipendenti

• i messaggi di errore possono essere modificati sulla base delle nostre esigenze

• il sistema FTP è stato integrato come processo interno di Squid

• è stato inserito il supporto opzionale per la scrittura asincrona delle operazioni del disk I/O

• le icone per il supporto FTP e GOPHER sono un processo interno

• è stato inserito supporto SNMP (Simple Network Management Protocol) per consentire un miglior controllo sulle operazioni svolte da Squid

• le richieste di routing vengono basate su un numero AS

• è stato inserito il supporto per il Cache Digest

in questo capitolo è nostra intenzione analizzare le differenze, che sono anche sostanziali, tra la versione 2.5 di Squid e le precedenti releases. Comprendere le differenze aiuterà il lettore a valutare al meglio l'evoluzione di Squid Proxy Server nel corso del tempo, ma prima di addentrarci nei dettagli analizzeremo i punti cardine che caratterizzano la versione 2.5

• completa riprogettazione e riscrittura di tutto il supporto d'autenticazione dell'accesso alla cache e dell'algoritmo di ricerca e visita all'interno delle ACL

• supporto per la traduzione e l'instradamento di connessioni SSL (Secure Socket Layer)

• supporto delle richieste a link Satellitari

• varie altre migliorie per aumentare le performance

5.2. Autenticazione

Nella versione 2.5 di Squid la struttura del sistema di autenticazione è stata riprogettata per facilitare l'inserimento di nuovi schemi di autenticazione

• digest

• NTLM

• basic

Come vedremo più avanti nelle configurazioni specifiche, lo schema di autenticazione basic si occuperà di gestire il sistema di autenticazione così come avveniva nelle precedenti versioni di Squid. Per essere precisi, secondo la RFC 2617 (http://www.ietf.org/rfc/rfc2617.txt), questa tipologia di autenticazione identifica una procedura con la quale le credenziali vengono inviate sulla rete in "chiaro" per ogni sessione.

Ricordiamo però che questa funzionalità viene usata in congiunzione con gli helpers, che nel nostro caso possono sfruttare le più disparate caratteristiche come PAM, NCSA, LDAP ecc.

Lo schema digest a sua volta ci fornirà una struttura d'autenticazione basata su parole chiave in modalità digest (fare sempre riferimento alla RFC 2617 - http://www.ietf.org/rfc/rfc2617.txt). L'invio delle credenziali nel formato CheckSum ci permetterà di verificare la veridicità delle credenziali stesse. Con questa modalità di autenticazione le password transitano sulla rete in formato crittato.

L'NTLM ci permetterà l'integrazione con il sistema di autenticazione nativo di Microsoft Windows (Protocollo NTLMv1, NTLMv2) che può avvenire con modalità diverse a secondo del tipo di helpers che verrà utilizzato. Nei capitoli seguenti analizzeremo tutte le possibili configurazioni. Ricordiamo per completezza che lo schema di autenticazione NTLM rispetta uno standard di validazione proprietario della Microsoft e può quindi funzionare automaticamente soltanto utilizzando il browser Internet Explorer (almeno sino alla data odierna).

A riguardo delle tre modalità di autenticazione, vale la pena citare anche un'altra metodologia denominata External. Tale sistema consente di integrare tutti i validatori non direttamente interni a Squid che rispettano le caratteristiche di ritorno di un helper. External può essere considerato una diretta estensione dello schema di funzionamento delle ACL che viene applicato tramite alcuni programmi esterni. Con la parola helper identifichiamo nello specifico un programma che viene utilizzato da Squid per verificare le credenziali di un'utente sulla base dello schema di autenticazione che abbiamo deciso di utilizzare (digest, NTLM e basic).

5.3. SSL Gatewaying

Questa nuova funzionalità consente, nelle configurazioni di "acceleratore", di utilizzare Squid come un server SSL (Secure Socket Layer) per instradare connessioni caratterizzate da tale tecnologia e creare un'amministrazione controllata dei certificati del richiedente.

5.4. Link Satellitari

Nella nuova versione 2.5 di Squid è stata migliorata sia la modularità di configurazione sia la tecnica di richiesta delle informazioni nel caso in cui una istanza faccia riferimento ad un link satellitare. Non ci dilungheremo ora nella spiegazione delle problematiche inerenti le connessioni satellitari, diciamo che tali richieste sono caratterizzate da un RTT (Round Trip Time) di funzionamento diverso ed da una latenza differente rispetto a quanto richiesto da un link terrestre via cavo. Squid si può comportare in modo da bilanciare le connessioni tra il satellite ed il cavo quando il primo link è in sovraccarico, utilizzando appunto le variabili sopracitate.

5.5. modifiche al file squid.conf

Il passaggio da Squid-2.4 alla release 2.5 è stato un vero e proprio salto tecnologico che ha determinato alcune modifiche alla sintassi del file squid.conf oltre all'aggiunta di nuovi TAG. Le modifiche hanno riguardato sopratutto la sintassi dei TAG relativi all'autenticazione, come abbiamo visto, con Squid-2.5 viene introdotto il concetto degli schemi di autenticazione, la versione 2.4 invece lavorava esclusivamente con lo schema di autenticazione basic. Tra i nuovi TAG citiamo quello relativo all'acceleratore SSL (https_port) che consente anche la gestione dei certificati digitali, altre modifiche hanno riguardato le tipologie delle ACL (Access Control List) e l'inserimento dei TAG relativi alla gestione delle external ACL (external_acl_type), maggiori dettagli a riguardo possono essere reperiti nelle note di release (http://www.squid-cache.org/Versions/v2/2.5/RELEASENOTES.html).

In linea di massima si sconsiglia sempre al lettore di riutilizzare lo stesso file di configurazione. Questa regola è sempre valida quando si intende passare da una major release all'altra. Consigliamo sempre di eseguire una copia di sicurezza del vecchio file di configurazione, riportando gli stessi TAG nel nuovo file che comunque contiene i commenti a tutte le nuove features offerte dalla nuova major release. A tale riguardo possono aiutarci i comandi UNIX® more(8) e tail(8), maggiori dettagli ed esempi sulla migrazione verranno trattati in seguito.

5.6. Considerazioni

La versione 2.5 di Squid probabilmente può essere considerata come una release di transizione, l'elemento che la contraddistingue fortemente è l'inserimento degli schemi di autenticazione ed in particolare dell'integrazione con i domini Windows NT o con le Active Directory di Windows 2000 Server. Questa nuova features è intrinsecamente legata allo sviluppo di Samba (http://www.samba.org/), il team di sviluppo di Squid ha lavorato intensamente con il team di sviluppo di Samba per integrare al meglio questo schema di autenticazione. Samba è una applicazione fondamentalmente basata sul processo di reverse engineering del protocollo SMB adottato dai sistemi Microsoft per la condivisione di files e stampanti.

La dipendenza tra Squid e Samba, se da una parte svincola gli amministratori di sistema dalle briglie dei protocolli proprietari, dall'altra introduce lo stato di transizione. A partire dalla release 2.5.STABLE5 è stata decisamente migliorata l'integrazione ed il funzionamento dello schema di autenticazione NTLM sia per queanto concerne l'helper nativo ntlm_auth che per l'helper esterno basato su Samba. Ora gli amministratori di sistema possono finalmente utilizzare senza problemi sia il protocollo NTLMv1 che NTLMv2.

Utile, indicato e necessario è il supporto per l'accelerazione HTTPs con la relativa gestione dei certificati digitali. In questo caso si tratta di un grande passo in avanti, la soluzione è particolarmente indicata per gli amministratori si sistema che hanno la necessità di gestire degli apparati di content caching particolarmente efficenti e performanti.

6.1. Sistemi in test

La configurazione del server sul quale è stato testato originariamente Squid a partire dalla sua versione 2.1 e sino alla versione 2.4 era basata sulla seguente configurazione:

• motherboard MSI bus 100Mhz chipset ADI Alladin 5, processore AMD K6/333 Mhz, 196 Mb di Ram (Dimm 100Mhz).

  Per un lungo periodo è stato adottato il sistema operativo IBM OS/2 Warp 4.0, FixPack 14 con stack TCP/IP v. 4.1 di diretta derivazione *BSD (a partire dal FixPack 13 il kernel del sistema è IBM OS/2 Warp Server for E-Business). La stessa configurazione ha anche lavorato con un sistema Linux Red Hat 7.1 (Kernel 2.4.18-27)

attualmente i nuovi test vengono effettuati su Squid 2.5 e vengono eseguiti su diverse macchine che sono così equipaggiate:

• motherboard MSI bus 100Mhz chipset ADI Alladin 5, processore AMD K6/333 Mhz, 64 Mb di SRAM (Dimm 100Mhz), il sistema operativo attuale è FreeBSD 4.11-STABLE, ufs Disk Store, filesystem UFS

• motherboard Asus P4PE, processore Pentium IV 2 Ghz, 1Gb di RAM (Dimm 233Mhz), il sistema operativo attuale è FreeBSD 5.3-STABLE, diskd Disk Store, filesystem UFS2

• motherboard ECS-K7S5A Pro, processore AMD Athlon XP+ 2400, 256 Mb di DRAM (Dimm 233Mhz), il sistema operativo attuale è FreeBSD 4.11-STABLE, ufs Disk Store, filesystem UFS

• motherboard ASUS-A7V600-X, processore AMD Athlon XP+ 3000, 512 Mb di DRAM (Dimm 333Mhz), il sistema operativo attuale è DragonFlyBSD 1.3-stable, ufs Disk Store, filesystem UFS

• motherboard ASUS-K7M, processore AMD Athlon 500 Mhz, 256 Mb di SRAM (Dimm 133 Mhz), il sistema operativo attuale è NetBSD 2.0.2_STABLE, ufs Disk Store, filesystem FFS

• motherboard P51430PX Titanium, processore AMD K6/3D 300Mhz, 98 Mb di DRAM (Simm), il sistema operativo attuale è FreeBSD 4.11-STABLE, filesystem UFS

6.2. Sistemi in produzione

Di seguito viene fornito anche un'elenco di server che sono attualmente in produzione e che eseguono il proxy server Squid in realtà aziendali molto diverse tra loro, verrà specificata anche la versione di Squid in produzione e alcune informazioni relative al carico ed alla configurazione.

• Server HP Netserver Lp 2000r -PIII 933Mhz - 512MB RAM - dischi SCSI RAID1

  • FreeBSD 4.11-STABLE

  • Squid-2.5.STABLE10

  • 300 utenti

  • diskd disk store (filesystem UFS [5]), autenticazione ntlm in AD[6]

• Server Fujitsu-Siemens Primergy L200 - PIII 1,3GHz - 1GB RAM - dischi SCSI RAID 5 [7]

  • FreeBSD 4.11-STABLE

  • Squid-2.5.STABLE10

  • 300 utenti

  • diskd disk store (filesystem UFS), autenticazione ntlm in AD

• Server Compaq Proliant - PII 450 MHz - 128 MB RAM - disco SCSI

  • FreeBSD 4.11-STABLE

  • Squid-2.5.STABLE10

  • 50 utenti

  • ufs disk store (filesystem UFS), autenticazione ntlm in AD

• Server IBM x340 e-Server 2xPIII 1.2 Ghz - 1 GB RAM - dischi SCSI RAID 5

  • Linux Slackware Kernel 2.4

  • Squid-2.5STABLE1

  • 300 utenti

  • diskd disk store (filesystem RaiserFS), autenticazione ntlm in AD

• PC AMD Duron 1,3 GHz - 512 MB RAM - 2 x IDE 40 GB RAID 1 HW Promise FastTrack TX100

  • Debian GNU/Linux 3.0r1 kernel 2.4.20

  • Squid-2.5STABLE3

  • 80 utenti

  • aufs disk store [8] (filesystem Ext3), autenticazione basic NCSA

• PC PII 266 MHz - 512 MB RAM - 2 x IDE 30 GB mirror SW

  • Windows 2000 Server SP4

  • Squid-2.5STABLE4

  • 15 utenti

  • awin32 disk store (filesystem NTFS), autenticazione basic e NTLM in AD

• PC AMD Athlon XP 1,4 GZ - 256 MB RAM - 1 x IDE 20 GB (SO) con 2 x IDE 120 GB

  • Red Hat Linux 7.3 kernel 2.4.20-30.7.legacy

  • Squid-2.5.STABLE6

  • 10 utenti

  • aufs disk store (file system ext3), autenticazione BASIC

7.1. Preambolo

Nel settore informatico, così come accade per moltissime altre attività ed altri aspetti della vita quotidiana, si tende sempre a generalizzare anche su questioni che nel futuro potranno rivelarsi di importanza strategica, purtroppo siamo nell'era del profitto e per il denaro saremmo disposti anche ad immolare il futuro dei nostri figli.

Prepararsi per installare un sistema di web cache come Squid, comporta una serie di scelte progettuali che devono essere effettuate prima di procedere con l'installazione vera e propria. I fattori che determineranno questo tipo di scelta vanno dalla realtà nella quale si dovrà operare, al numero degli utenti che si dovranno servire. La scelta del Sistema Operativo, la RAM, il tipo di CPU e la modalità di preparazione dei codici sorgenti di Squid, rappresentano la strategia che ci consentirà di ottenere un ambiente performante, stabile ed affidabile. In questo capitolo tratteremo molti dei fattori che possono influenzare la scelta del sistema migliore, questa decisione determinerà il successo o il fallimento del progetto.

Tratteremo alcune informazioni di carattere generale relativamente al processo di postinstazione di Squid, spiegheremo agli utenti quanto sia determinante il corretto utilizzo del file di configurazione squid.conf. Infine elencheremo e spiegheremo alcuni dei TAG principali contenuti nel file squid.conf per consentire i lettori ad utilizzare con successo Squid.

7.2. Scegliere il Sistema Operativo

I più moderni sistemi a codice libero di classe UNIX® forniscono delle prestazioni piuttosto simili e tutti i Sistemi Operativi compatibili allo standard POSIX vengono supportati da Squid. I Sistemi Operativi che utilizzano il compilatore GNU C, le librerie gcc e i Sistemi Operativi genericamente compatibili con lo standard ANSI C, rappresentano la scelta migliore per utilizzare Squid.

Ci sono anche molte distribuzioni Linux che includono dei package precompilati secondo diversi standard. Fedora Core, Red Hat Linux (non più supportata), Mandrake Linux e SuSe Linux forniscono i loro pacchetti RPM, Debian GNU Linux include i pacchetti deb e per finire i classici pacchetti tgz vengono inclusi nella distribuzione Linux Slackware.

Un'ottima scelta può essere rappresentata da un Sistema Operativo *BSD, per quello che concerne l'esperienza di chi scrive, FreeBSD è senza dubbio una scelta di eccellenza perchè fornisce la giusta miscela di funzionalità e standardizzazione. Non dimentichiamo che, a livello di performance, FreeBSD si posiziona in testa al gruppo dei Sistemi Operativi che abbiamo sinora elencato. A livello di compatibilità con il codice sorgente, il Sistema Operativo che meglio si integra con Squid è GNU Linux. A tale riguardo si consiglia di installare con il Sistema Operativo anche tutti i tools necessari allo sviluppo del software, in questo modo potremmo avere la possibilità di mantenere una versione di Squid sempre aggiornata compilata sulla macchina in produzione. A tale riguardo, nel proseguio di questo capitolo, vedremo come preparare delle versioni personalizzate di Squid compilando ed installando direttamente il codice sorgente.

Parleremo anche dei Sistemi Operativi "proprietari" come Sun Solaris, Digital UNIX®, OS/2 (oramai non più supportato o quasi) ed i Sistemi Windows NT/2000/2003/XP per i quali esistono dei ports perfettamente in linea con le versioni per i sistemi a codice libero.

7.3. Regole da rispettare

Una delle risorse più importanti da offrire a Squid è la memoria RAM, non è infatti fondamentale avere un processore particolarmente veloce e non è da sottovalutare il sottosistema dischi.

7.4. Il sistema ottimale

Proponiamo ora al lettore una configurazione che può essere presa come punto di riferimento nella costruzione di una webcache appliance efficente. I valori sono riferiti all'attuale mercato dell'Information and Communication Technology

• Si consiglia una CPU Intel Pentium =>300 Mhz o AMD K6 => 300 Mhz

• Si consiglia una CPU di tipo i686/K7/Athlon se si intende utilizzare Squid in modalità threaded[16]

• La tecnologia SCSI o SATA è altamente raccomandata

• É possibile utilizzare un disco IDE UDMA 66/100

• Le capacità del disco devono essere tipicamente => 9Gb

• Nel caso si utilizzino unità a disco EIDE/UDMA 66/100 è consigliabile utilizzare una CPU veloce per compensare il gap sul consumo dei cicli di clock[17]

• Una o più schede di rete ad alta capacità 10/100Mb/s sono sufficenti

• Nei valori da impostare per ottenere un corretto dimensionamento della memoria RAM di sistema è bene non dimenticare il fatto che per ogni Gb di disk storage sono richiesti circa 6Mb di RAM, quindi 8Gb di cache_dir rappresentano 48 Mb di memoria RAM

• RAM minima: 128 Mb

• RAM massima: 1024 Mb

Ulteriori dettagli alla URLs: http://www.squid-cache.org/Doc/FAQ/FAQ-3.html#ss3.1

7.5. I file sorgenti di Squid

I file che contengono i codici sorgenti di Squid possono essere prelevati direttamente dal sito ufficiale del progetto di Squid alla URL http://www.squid-cache.org/Versions/v2/, il formato dei file contenenti i sorgenti è un file in formato compresso. I file con estensione .bz2 sono stati trattati con bzip(8), bzip2 è un nuovo algoritmo per la compressione dei dati che generalmente crea file che sono pari al 60-70% della dimensione dei corrispondenti ottenuti usando gzip (http://www.digistar.com/bzip2/index.html)

squid-2.5.STABLE4.tar.bz2
  

oppure è possibile prelevare un file compresso con estensione .gz che è stato trattato con gzip(8), GNU zip è un programma destinato a rimpiazzare compress, ovvero il programma originario di compressione dei sistemi UNIX®, le specifiche applicative sono descritte nelle RFC 1951 e 1952 (http://www.ietf.org/rfc/rfc1951.txt - http://www.ietf.org/rfc/rfc1952.txt)

squid-2.5.STABLE4.tar.gz
  

dove 2.5 indica la versione, STABLE4 indica la sottoversione della release STABLE. Seguendo lo standard appena descritto il file contenente l'archivio dei codici sorgenti per la versione squid-2.5STABLE6 sarà dunque

squid-2.5.STABLE6.tar.bz2
  

oppure

squid-2.5.STABLE6.tar.gz
  

% touch .cvspass
% cvs -d :pserver:anoncvs@cvs.squid-cache.org:/squid login
CVS password:
    

% cvs -z3 -d :pserver:anoncvs@cvs.squid-cache.org:/squid co -P squid
    

% cd squid
% cvs -z3 update -dP
    

% cvs -d :pserver:anoncvs@cvs.squid-cache.org:/squid login
CVS password:
    

% cd squid
% more configure | grep VERSION
VERSION=2.5.STABLE7-RC3-CVS
    

% fetch ftp://ftp.squid-cache.org/pub/squid-2/STABLE/squid-2.5.STABLE6.tar.gz
Receiving squid-2.5.STABLE6.tar.gz (1355951 bytes): 100%
1355951 bytes transferred in 18.9 seconds (69.94 kBps)
   

% bunzip2 squid-2.5.STABLE5.tar.bz2
% tar xvf squid-2.5.STABLE5.tar
squid-2.5.STABLE5/
squid-2.5.STABLE5/CONTRIBUTORS
...
% cd squid-2.5.STABLE5
% ./configure
   

% ./configure --prefix=/usr/local/squid/ \
--bindir=/usr/local/sbin \
--sysconfdir=/usr/local/etc/squid \
--datadir=/usr/local/etc/squid \
--libexecdir=/usr/local/libexec/squid \
--localstatedir=/usr/local/squid \
--enable-removal-policies="lru heap" \
--enable-auth="basic ntlm digest" \
--enable-basic-auth-helpers="NCSA PAM YP MSNT winbind" \
--enable-digest-auth-helpers=password \
--enable-external-acl-helpers="ip_user unix_group wbinfo_group winbind_group" \
--enable-ntlm-auth-helpers="SMB winbind" \
--enable-async-io --with-pthreads \
--enable-storeio="ufs diskd null aufs" \
--enable-snmp \
--enable-ssl \
--enable-htcp \
--disable-http-violations \
--disable-ident-lookups \
--enable-useragent-log \
--enable-arp-acl \
--enable-err-languages="English Italian" \
--enable-default-err-language="Italian" \
--prefix=/usr/local
   

% cd squid-2.5.STABLE6
% ./config.status --recheck
   

% make clean
% ./configure --enable-snmp
   

% cd squid-2.5.STABLE5
% patch < /tmp/nome_file.patch
   

% make distclean
% ./configure
% make
% make install
   

% fetch http://www.squid-cache.org/Versions/v2/2.5/squid-2.5.STABLE6-20040926.tar.gz
Receiving squid-2.5.STABLE6-20040926.tar.gz (1361403 bytes): 100%
1361403 bytes transferred in 19.2 seconds (69.40 kBps)
   

% tar zxvf squid-2.5.STABLE6-20040926.tar.gz
...
...
% cd squid-2.5.STABLE6-20040926
% ./configure --enable-removal-policies="lru heap" \
--enable-auth="basic ntlm digest" \
--enable-basic-auth-helpers="NCSA PAM YP MSNT winbind" \
--enable-digest-auth-helpers=password \
--enable-external-acl-helpers="ip_user unix_group wbinfo_group winbind_group" \
--enable-ntlm-auth-helpers="SMB winbind" \
--enable-async-io --with-pthreads \
--enable-storeio="ufs diskd null aufs" \
--enable-snmp \
--enable-ssl \
--enable-htcp \
--disable-http-violations \
--disable-ident-lookups \
--enable-useragent-log \
--enable-arp-acl \
--enable-err-languages="English Italian" \
--enable-default-err-language=Italian
   

% make
% make install
% make clean
   

% ./configure --prefix
   

% ./configure -exec-prefix=/usr/local/sbin
   

% ./configure --prefix=/usr/local/squid
   

% ./configure --localstatedir=/var/log
   

% ./configure --sysconfdir=/usr/local/etc/squid
   

% ./configure --help
   

Usage: configure [options] [host]
Options: [defaults in brackets after descriptions]
Configuration:
  --cache-file=FILE       cache test results in FILE
  --help                  print this message
  --no-create             do not create output files
  --quiet, --silent       do not print `checking...' messages
  --site-file=FILE        use FILE as the site file
  --version               print the version of autoconf that created configure
Directory and file names:
  --prefix=PREFIX         install architecture-independent files in PREFIX
                          [/usr/local/squid]
  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
                          [same as prefix]
  --bindir=DIR            user executables in DIR [EPREFIX/bin]
  --sbindir=DIR           system admin executables in DIR [EPREFIX/sbin]
  --libexecdir=DIR        program executables in DIR [EPREFIX/libexec]
  --datadir=DIR           read-only architecture-independent data in DIR
                          [PREFIX/share]
  --sysconfdir=DIR        read-only single-machine data in DIR [PREFIX/etc]
  --sharedstatedir=DIR    modifiable architecture-independent data in DIR
                          [PREFIX/com]
  --localstatedir=DIR     modifiable single-machine data in DIR [PREFIX/var]
  --libdir=DIR            object code libraries in DIR [EPREFIX/lib]
  --includedir=DIR        C header files in DIR [PREFIX/include]
  --oldincludedir=DIR     C header files for non-gcc in DIR [/usr/include]
  --infodir=DIR           info documentation in DIR [PREFIX/info]
  --mandir=DIR            man documentation in DIR [PREFIX/man]
  --srcdir=DIR            find the sources in DIR [configure dir or ..]
  --program-prefix=PREFIX prepend PREFIX to installed program names
  --program-suffix=SUFFIX append SUFFIX to installed program names
  --program-transform-name=PROGRAM
                          run sed PROGRAM on installed program names
Host type:
  --build=BUILD           configure for building on BUILD [BUILD=HOST]
  --host=HOST             configure for HOST [guessed]
  --target=TARGET         configure for TARGET [TARGET=HOST]
Features and packages:
  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
  --x-includes=DIR        X include files are in DIR
  --x-libraries=DIR       X library files are in DIR
--enable and --with options recognized:
  --disable-dependency-tracking Speeds up one-time builds
  --enable-dependency-tracking  Do not reject slow dependency extractors
  --enable-maintainer-mode enable make rules and dependencies not useful
                          (and sometimes confusing) to the casual installer
  --enable-dlmalloc[=LIB] Compile & use the malloc package by Doug Lea
  --enable-gnuregex       Compile GNUregex
  --enable-xmalloc-statistics
                          Show malloc statistics in status page
  --enable-carp           Enable CARP support
  --enable-async-io[=N_THREADS]
                          Shorthand for
                          --with-aufs-threads=N_THREADS
                          --with-pthreads
                          --enable-storeio=ufs,aufs
  --with-aufs-threads=N_THREADS
                          Tune the number of worker threads for the aufs object
                          store.
  --with-pthreads         Use POSIX Threads
  --with-aio              Use POSIX AIO
  --with-dl               Use dynamic linking
  --enable-storeio="list of modules"
                          Build support for the list of store I/O modules.
                          The default is only to build the ufs module.
                          See src/fs for a list of available modules, or
                          Programmers Guide section <not yet written>
                          for details on how to build your custom store module
  --enable-heap-replacement
                          Backwards compability option. Please use the
                          new --enable-removal-policies directive instead.
  --enable-removal-policies="list of policies"
                          Build support for the list of removal policies.
                          The default is only to build the lru module.
                          See src/repl for a list of available modules, or
                          Programmers Guide section 9.9 for details on how
                          to build your custom policy
  --enable-icmp           Enable ICMP pinging
  --enable-delay-pools    Enable delay pools to limit bandwidth usage
  --enable-useragent-log  Enable logging of User-Agent header
  --enable-referer-log    Enable logging of Referer header
  --disable-wccp          Disable Web Cache Coordination Protocol
  --enable-kill-parent-hack
                          Kill parent on shutdown
  --enable-snmp           Enable SNMP monitoring
  --enable-cachemgr-hostname[=hostname]
                          Make cachemgr.cgi default to this host
  --enable-arp-acl        Enable use of ARP ACL lists (ether address)
  --enable-htcp           Enable HTCP protocol
  --enable-ssl            Enable ssl gatewaying support using OpenSSL
  --with-openssl[=prefix]
                          Compile with the OpenSSL libraries. The path to
                          the OpenSSL development libraries and headers
                          installation can be specified if outside of the
                          system standard directories
  --enable-forw-via-db    Enable Forw/Via database
  --enable-cache-digests  Use Cache Digests
                          see http://www.squid-cache.org/FAQ/FAQ-16.html
  --enable-default-err-language=lang
                          Select default language for Error pages (see
                          errors directory) 
  --enable-err-languages="lang1 lang2.."
                          Select languages to be installed. (All will be
                          installed by default) 
  --with-coss-membuf-size COSS membuf size (default 1048576 bytes) 
  --enable-poll           Enable poll() instead of select().  Normally poll
                          is preferred over select, but configure knows poll
                          is broken on some platforms.  If you think you are
                          smarter than the configure script, you may enable
                          poll with this option.
  --disable-poll          Disable the use of poll().
  --disable-http-violations
                          This allows you to remove code which is known to
                          violate the HTTP protocol specification.
  --enable-ipf-transparent
                          Enable Transparent Proxy support for systems
                          using IP-Filter network address redirection.
  --enable-pf-transparent
                          Enable Transparent Proxy support for systems
                          using PF network address redirection.
  --enable-linux-netfilter
                          Enable Transparent Proxy support for Linux 2.4.
  --with-large-files      Enable support for large files (logs etc).
  --enable-large-cache-files
                          Enable support for large cache files (>2GB).
                          WARNING: on-disk cache format is changed by this option
  --with-build-environment=model
                          The build environment to use. Normally one of
                          POSIX_V6_ILP32_OFF32   32 bits
                          POSIX_V6_ILP32_OFFBIG  32 bits with large file support
                          POSIX_V6_LP64_OFF64    64 bits
                          POSIX_V6_LPBIG_OFFBIG  large pointers and files
                          XBS5_ILP32_OFF32       32 bits (legacy)
                          XBS5_ILP32_OFFBIG      32 bits with large file support (legacy)
                          XBS5_LP64_OFF64        64 bits (legacy)
                          XBS5_LPBIG_OFFBIG      large pointers and files (legacy)
                          default                The default for your OS
  --enable-leakfinder
                          Enable Leak Finding code.  Enabling this alone
                          does nothing; you also have to modify the source
                          code to use the leak finding functions.  Probably
                          Useful for hackers only.
  --disable-ident-lookups
                          This allows you to remove code that performs
                          Ident (RFC 931) lookups.
  --disable-internal-dns  This prevents Squid from directly sending and
                          receiving DNS messages, and instead enables the
                          old external 'dnsserver' processes.
  --enable-truncate       This uses truncate() instead of unlink() when
                          removing cache files.  Truncate gives a little
                          performance improvement, but may cause problems
                          when used with async I/O.  Truncate uses more
                          filesystem inodes than unlink..
  --disable-hostname-checks
                          Squid by default rejects any host names with
                          odd characters in their name to conform with
                          internet standards. If you disagree with this
                          you may use this switch to turn off any such
                          checks, provided that the resolver used by
                          Squid does not reject such host names.. This
                          may be required to participate in testbeds for
                          international domain names.
  --enable-underscores    Squid by default rejects any host names with _
                          in their name to conform with internet standards.
                          If you disagree with this you may allow _ in
                          hostnames by using this switch, provided that
                          the resolver library on the host where Squid runs
                          does not reject _ in hostnames...
  --enable-auth="list of auth scheme modules"
                          Build support for the list of authentication schemes.
                          The default is to build support for the Basic scheme.
                          See src/auth for a list of available modules, or
                          Programmers Guide section authentication schemes
                          for details on how to build your custom auth scheme
                          module
  --enable-auth-modules="list of helpers"
                          Backwards compability alias for --enable-basic-auth-helpers
  --enable-basic-auth-helpers="list of helpers"
                          This option selects which basic scheme proxy_auth
                          helpers to build and install as part of the normal 
                          build process. For a list of available
                          helpers see the helpers/basic_auth directory.
  --enable-ntlm-auth-helpers="list of helpers"
                          This option selects which proxy_auth ntlm helpers
                          to build and install as part of the normal build 
                          process. For a list of available helpers see
                          the helpers/ntlm_auth directory.
  --enable-digest-auth-helpers="list of helpers"
                          This option selects which digest scheme authentication
                          helpers to build and install as part of the normal build
                          process. For a list of available helpers see the
                          helpers/digest_auth directory.
  --enable-ntlm-fail-open Enable NTLM fail open, where a helper that fails one of the
                          Authentication steps can allow squid to still authenticate
                          the user.
  --enable-external-acl-helpers="list of helpers"
                          This option selects which external_acl helpers to
                          build and install as part of the normal build
                          process. For a list of available helpers see the
                          helpers/external_acl directory.
  --with-samba-sources=/path/to/samba-source-tree
                          Path where the correct Samba source files can be
                          found while building winbind helpers. (defaults to
                          use internal copies of the headers from Samba-2.2.7)
  --disable-unlinkd       Do not use unlinkd
  --enable-stacktraces    Enable automatic call backtrace on fatal errors
  --enable-x-accelerator-vary
                          Enable support for the X-Accelerator-Vary
                          HTTP header. Can be used to indicate
                          variance within an accelerator setup.
                          Typically used together with other code
                          that adds custom HTTP headers to the requests.
  --with-maxfd=N          Override maximum number of filedescriptors. Useful
                          if you build as another user who is not privileged
                          to use the number of filedescriptors you want the
                          resulting binary to support
   

7.6. Il problema dei file descriptor

I sistemi UNIX® utilizzano i descrittori di files per leggere e scrivere su disco i files ed i socket di rete, un file descriptor identifica quindi un file o un socket che viene aperto da una connessione di rete o da un processo locale. Ogni volta che un processo di sistema apre un file o un socket viene allocato un descrittore di file, quando questo viene chiuso il relativo file descriptor verrà liberato. Per gestire l'accesso ai file e ai socket, Squid utilizza una tabella di processo che contiene l'elenco di tutti i file descriptor aperti. La dimensione di questa tabella é statica e viene impostata al momento dell'esecuzione del comando ./configure. I diversi Sistemi Operativi oggi sul mercato utilizzano uno schema proprietario nella gestione dei processi e può accadere che il valore dei file descriptor predefinito nel Kernel del Sistema sia troppo piccolo per garantire il funzionamento di alcuni apparati di webcache la cui peculiarietà è quella di gestire dei carichi di traffico molto elevati. Può quindi rendersi necessario aumentare il valore dei file descriptor prima di eseguire il comando ./configure. Per determinare un valore adeguato si deve tenere conto dei seguenti fattori

1. la singola richiesta HTTP utilizza contemporaneamente sino a 3 file descriptor

   connessione HTTP lato client, connessione HTTP lato server e la scrittura o la lettura della cache su disco (scrivere nella cache un MISS o leggere nella cache un HIT)

2. la scrittura delle informazioni nei file di log utilizza contemporaneamente sino a 4 file descriptor

   Squid utilizza solitamente quattro file di log principali (access.log, cache.log, store.log e swap.state) e nel momento in cui accede a detti file apre un file descriptor

3. le comunicazioni tra Squid ed i processi esterni utilizzano mediamente sino a 20 file descriptors

   gli autenticatori, i redirectors e le porte in ascolto, mantengono sempre un certo numero di file descriptors attivi, il valore medio dipende molto dal numero degli helpers utilizzati e dal numero dei socket che vengono aperti da Squid (porte HTTP, ICP, SNMP ed altro).

4. un browser web esegue mediamente 2 o 3 richieste HTTP persistenti (idle time)

   ciò significa che per ogni browser web, volendo fare un dimensionamento pessimistico, si deve prevedere un utilizzo di circa 8 file descriptor.

2004/04/03 13:08:29| With 1024 file descriptors available
   

2004/04/12 21:33:22| WARNING! Your cache is running out of file descriptors
   

Active file descriptors:
File Type   Tout Nread  * Nwrite * Remote Address        Description
---- ------ ---- -------- -------- --------------- ------------------------------
   3 Log       0       0        0                  /usr/local/squid/var/logs/cache.log
   4 Socket    0       0        0  .0              DNS Socket
   5 File      0       0     1177                  /usr/local/squid/var/logs/access.log
   6 Pipe      0       0        0                  unlinkd -> squid
   7 File      0       0     1609                  /usr/local/squid/var/logs/store.log
   8 File      0       0        0                  /home/var/spool/squid/swap.state
   9 Pipe      0       0        0                  squid -> unlinkd
  10 Socket 1440      70*       0  127.0.0.1.51740 cache_object://127.0.0.1/filedescriptors
  11 Socket    0       0*       0  .0              HTTP Socket
  12 Socket    0       0*       0  .0              ICP Socket
  13 Socket    0       0*       0  .0              HTCP Socket
  14 Socket    0       0*       0  .0              SNMP Port
   

% ulimit -n
1024
   

% vi /usr/include/bits/typesizes.h
#define __FD_SETSIZE 4096
   

% cat /proc/sys/fs/file-max
104857
   

fs.file-max = 102400
   

% sysctl -p
   

echo 102400 > /proc/sys/fs/file-max
   

% ulimit -Hn 4096
% ulimit -n 4096
   

% make clean
% ./config.status --recheck
...
checking Default FD_SETSIZE value... 4096
checking Maximum number of filedescriptors we can open... 4096
checking Default UDP send buffer size... 65535
checking Default UDP receive buffer size... 65535
checking Default TCP send buffer size... 16384
checking Default TCP receive buffer size... 87380
Limiting receive buffer size to 64K
checking if sys_errlist is already defined... (cached) no
checking for libresolv _dns_ttl_ hack... no
checking if inet_ntoa() actually works... yes
checking for working statvfs() interface... yes
checking for _res.nsaddr_list... (cached) yes
creating ./config.status
...
   

% make
% make install
   

ulimit -HSn 4096
   

set rlim_fd_max = 4096
   

maxusers      0
   

options       MAXFILES=8192
    

% sysctl -a | grep kern.maxfiles
kern.maxfiles: 4040
kern.maxfilesperproc: 3636
    

% ulimit -n
4040
    

kern.maxfiles=4040
kern.maxfilesperproc=3636
    

% netstat -m
129/320/65536 mbufs in use (current/peak/max):
        129 mbufs allocated to data
128/260/16384 mbuf clusters in use (current/peak/max)
600 Kbytes allocated to network (1% of mb_map in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
    

options               NMBCLUSTERS=32768
    

SET EMXOPT=-h#
   

7.7. Il problema dell'insieme delle porte

Lo stack TCP/IP assegna un certo numero di porte locali per le connessioni in uscita, quando Squid esegue una connessione verso un server di origine degli oggetti, il kernel del sistema operativo assegna un numero di porta ad ogni socket locale, il numero di queste porte si incastra in un determinato intervallo. L'occupazione di queste porte può essere un collo di bottiglia di un certo rilievo per alcuni sistemi molto trafficati, può succedere infatti che il sistema occupi tutte le porte definite nell'intervallo.

7.8. Installare Squid dai sorgenti

La lettura e la compresione di quanto scritto nei paragrafi precedenti è fondamentale per precedere con l'installazione di Squid utilizzando il codice sorgente, di seguito spiegeremo in maniera dettagliata la procedura da seguire.

% make
   

% make install
   

% ./configure --prefix=/usr/local/squid 
   

% ls /usr/local/squid/
totale 28
drwxr-xr-x    2 root     root         4096 apr 10 12:26 bin
drwxr-xr-x    2 root     root         4096 apr 10 12:16 etc
drwxr-xr-x    2 root     root         4096 apr 10 12:26 libexec
drwxr-xr-x    3 root     root         4096 apr  3 12:40 man
drwxr-xr-x    2 root     root         4096 apr 10 12:26 sbin
drwxr-xr-x    4 root     root         4096 apr 10 12:16 share
drwxr-xr-x    5 root     root         4096 apr  3 13:01 var
   

% make && make install
% cd src/
% make install-strip
   

% strip -s /usr/local/squid/bin/* /usr/local/squid/sbin/* /usr/local/squid/libexec/*
strip: /usr/local/squid/bin/RunAccel: File format not recognized
strip: /usr/local/squid/bin/RunCache: File format not recognized
strip: /usr/local/squid/libexec/wbinfo_group.pl: File format not recognized
   

% make install-pinger
   

% mkdir /usr/local/squid/var/run
% chown -R nobody:nobody /usr/local/squid/var/*
   

/usr/local/squid/etc/squid.conf
   

7.9. Disponibilità di pacchetti precompilati

Come abbiamo detto, sono molti gli amministratori di Sistema che non utilizzano le versioni di Squid precompilate, questi infatti ritengono che la compilazione del codice sorgente su una specifica piattaforma, consenta di ottenere particolari ottimizzazioni e performance superiori alle media. Per verificare l'esistenza di package precompilati si faccia riferimento ai siti internet legati in qualche modo con le piattaforme specifiche.

8.1. Preliminari

Prima di procedere con una configurazione minimale di Squid è obbligatorio dire che alcuni files ed alcune directory devono poter essere utilizzate dal processo Squid. Per problemi legati alla sicurezza è consigliato non eseguire il processo di Squid con l'utente root, l'applicazione infatti funziona utilizzando un utente valido (censito in /etc/passwd) al quale assegneremo dei permessi molto limitati. Approfondiremo successivamente questo argomento, nel contempo diciamo che tra le directory accedibili da Squid includeremo il percorso dove verranno salvati i files di log, il file di processo ed il percorso dove verrà memorizzata la cache directory. Queste directory vengono identificate nel file di configurazione di Squid dai TAG cache_dir, cache_access_log, cache_store_log, cache_swap_log e pid_file_name, come valore di default queste directory si trovano in

/usr/local/squid/var/logs
/usr/local/squid/var/cache
  

questo percorso può variare sulla base della direttiva --prefix che è stata utilizzata dallo script di ./configure in fase di compilazione e di installazione. Analizzeremo in seguito il corretto utilizzo di queste direttive di configurazione, nel nostro esempio assumiamo che si utilizzi l'utente nobody per eseguire Squid. Dopo aver compilato ed installato il software dovremmo utilizzare alcuni comandi UNIX® per settare i permessi corretti per le directory che contengono i files di log, il file di processo e la cache

% chown -R nobody:nobody /usr/local/squid/var/logs
% chown -R nobody:nobody /usr/local/squid/var/cache
  

ora che abbiamo installato Squid, impostato i permessi di accesso alle porzioni di filesystem dedicate alla cache, dovremo iniziare a parlare dei alcune delle opzioni a linea di comando che vengono offerte dal programma squid(8), parleremo anche del significato di alcune delle direttive più importanti che sono contenute nel file di configurazione squid.conf, si consiglia agli utenti di effettuare sempre una copia di sicurezza di questo file prima di dare corso a qualsiasi tipo di modifica. Squid normalmente viene avviato in modalità daemon (processo di background) ma può anche essere eseguito in modalità di foreground attraverso la quale è possibile visualizzare in una finestra terminale lo stato di funzionamento del proxy server. Il processo Squid può eseguire diverse opzioni come la rotazione dei file di log, lo stop del processo e la riconfigurazione della applicazione tramite la rilettura del file di configurazione squid.conf

8.2. Opzioni offerte dal comando squid(8)

Il comando squid(8) mette a disposizione degli utenti diverse opzioni a riguardo dell'avvio del processo Squid, queste possono essere impostate direttamente dalla shell di sistema UNIX® oppure dalla linea di comando (cmd) dei sistemi OS/2 o Windows NT/2000/2003. Le opzioni messe a disposizione dal comando squid(8) consentono di ottenere un controllo molto accurato relativamente ai processi che possono essere avviati

• -a port

  l'opzione port viene utilizzata per sovrascrivere la configurazione impostata nel file squid.conf ed indicare una porta alternativa per l'ascolto di eventuali richieste HTTP, questa opzione viene generalmente utilizzata per delle configurazioni non standard

• -d level

  l'opzione level viene utilizzata da Squid per scrivere i messaggi di debug, può essere espressa da un valore compreso da 0 a 9, il valore specifica il livello stderr per il messaggio di debug

• -f file

  l'opzione file viene utilizzata per specificare un file di configurazione alternativo a squid.conf, l'opzione deve contenere il percorso (/usr/local/etc/squid/squid.conf.test)

• -h

  questa opzione visualizza le informazioni sull'utilizzo del comando squid, è utile per ottenere i messaggi di aiuto e le modalità di utilizzo del comando

• -k

  questa opzione indica a Squid di eseguire diverse funzioni amministrative, tra queste elenchiamo: reconfigure | rotate | shutdown | interrupt | kill | debug | check | parse

  • -k reconfigure

    l'opzione reconfigure invia un segnale di HUP al server causando la rilettura del file di configurazione squid.conf

  • -k rotate

    l'opzione rotate invia un segnale di TERM al server causando la riscrittura dei files di log, se nel file di configurazione il TAG logfile_rotate è posto sul valore 0 (zero), Squid chiude e riapre tutti i files di log

  • -k shutdown

    l'opzione shutdown invia un segnale di TERM al server causando la chiusura del processo Squid, tale operazione si verificherà solo dopo il termine dell'ultima connessione sospesa. L'ammontare del tempo dedicato alla chiusura di Squid è contenuto nel TAG shutdown_lifetime

  • -k interrupt

    l'opzione interrupt invia un segnale di INT al server causando la chiusura immediata di Squid senza attendere il termine dell'ultima connessione attiva

  • -k kill

    l'opzione kill invia un segnale di KILL al server causando la chiusura immediata del processo, tale operazione avverrà senza preventivamente tenere conto delle connessioni attive e files di log

  • -k debug

    l'opzione debug invia un segnale di USR2 causando la generazione dei messaggi di debug da parte di Squid. E' necessario un'altro segnale USR2 per bloccare la generazione dei messaggi

  • -k check

    l'opzione check invia un segnale di ZERO al file di processo (pid) di Squid. Si tratta di un controllo sull'attività di processo avviata da Squid

  • -k parse

    l'opzione parse esegue la verifica della correttezza della sintassi che viene utilizzata nel file di configurazione squid.conf, si consiglia di utilizzare questa opzione ogni volta che si procede alla modifica del file di configurazione

• -s

  l'opzione -s abilita il log sul syslog di sistema, Squid utilizza la facility LOCAL4, il livello 0 di debug utilizza la priority LOG_WARNING mentre il livello 1 di debug utilizza la priority LOG_NOTICE, per registrare questo tipo di attività dovremmo modificare il file /etc/syslogd.conf

  local4.warning /var/log/squid.log

• -u port

  l'opzione -u port consente di specificare una porta alternativa per il protocollo ICP e sovrascrive il TAG icp_port impostato nel file squid.conf, viene utilizzato per le configurazioni non standard

• -v

  l'opzione -v consente di visualizzare i dati sulla versione utilizzata di Squid incluse tutte le opzioni di configurazione (./configure) utilizzate

• -z

  l'opzione -z consente di generale le directory per lo swap della memoria cache, questa opzione deve essere utilizzata la prima volta che viene avviato Squid, le directory verranno generate sulla base del percorsospecificato nella TAG cache_dir del file squid.conf

• -D

  l'opzione -D non effettua il test iniziale del DNS, Squid normalmente verifica la risoluzione dei nomi all'avvio per consentire un corretto funzionamento, in alternativa può essere rimosso il TAG dns_testnames nel file squid.conf

• -F

  Squid rifiuta qualsiasi richiesta prima della rigenerazione dei metadati dello storage, se la cache è particolarmente occupata l'opzione -F riduce il tempo di rigenerazione degli oggetti contenuti nella cache

• -N

  l'opzione -N indica a Squid di non diviene automaticamente un processo di background

• -R

  l'opzione -R non abilita l'opzione SO_REUSEADDR prima di eseguire il binding della porta HTTP

• -V

  l'opzione -V abilita il supporto per gli host virtuali per l'acceleratore, il TAG httpd_accel_host virtual contenuto nel file squid.conf può sostituire questa opzione

• -X

  l'opzione -X abilita il debug completo, il TAG debug_options ALL,9 all'interno del file squid.conf sostituisce questa opzione

• -Y

  quando viene eseguito il rebuild dei metadati contenuti all'interno della cache l'opzione -Y consente una rigenerazione veloce della cache in quanto è in grado di ritornare un messaggio ICP_MISS_NOFETCH al posto di ICP_MISS

8.3. Il file di configurazione

Il file di configurazione di Squid è squid.conf, il suo formato è molto simile ad altri file di configurazione di altri programmi UNIX®. Tutte le linee contengono una direttiva di configurazione che in questo libro chiameremo anche TAG, questa linea è seguita da una serie di numeri/chiavi o valori

acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
  

le linee vuote vengono totalmente ignorate al momento dell'esecuzione di Squid, mentre le linee che presentano il simbolo # indicano una linea di commento

#  TAG: cache_mem       (bytes)
#       NOTE: THIS PARAMETER DOES NOT SPECIFY THE MAXIMUM PROCESS SIZE.
#       IT ONLY PLACES A LIMIT ON HOW MUCH ADDITIONAL MEMORY SQUID WILL
#       USE AS A MEMORY CACHE OF OBJECTS. SQUID USES MEMORY FOR OTHER
#       THINGS AS WELL. SEE THE SQUID FAQ SECTION 8 FOR DETAILS.
  

le direttive incluse nel file di configurazione seguono generalmente un ordine logico, le access list ne sono un esempio, molte direttive all'interno del file squid.conf sono del tipo case-sensitive (i caratteri maiuscoli e minuscoli sono diversi) ed il file di configurazione di default, ovvero il file che viene generato con la compilazione e l'installazione di Squid, si chiama squid.conf.default

8.4. Numero delle porte

Squid è un server che per offrire il servizio deve rimanere in ascolto di eventuali richieste su una porta specifica, è dunque fondamentale definire le porte sulle quali rimarrà in ascolto il proxy server

il TAG http_port per il protocollo HTTP

http_port 3128
  

il TAG icp_port per il protocollo ICP

icp_port 3130 
  

questi TAG definiscono i numeri di porta che verranno utilizzati da Squid per rimanere in ascolto delle eventuali richieste che verranno effettuate da parte dei client, sia per quanto riguarda il protocollo HTTP che il protocollo ICP (Internet Cache Protocol).

http_port 1.2.3.4:3128
http_port 1.2.3.5:8080
  

nel caso si esegua Squid su un Sistema del tipo dual-homed che prevede una interfaccia di rete interna (inside) ed una interfaccia di rete esterna (outside), è raccomandabile specificare sempre l'indirizzo IP assegnato all'interfaccia di rete interna. Questo tipo di configurazione consente a Squid di essere raggiungibile unicamente dalle subnet presenti sulla rete interna.

A partire dalla versione 2.3 di Squid, è possibile specificare diversi TAG http_port, definendo con un'unico comando, diverse porte sulle quali Squid rimane in ascolto di eventuali richieste.

8.5. Definire una cache gerarchica

Possiamo utilizzare un'altro proxy server come cache di appoggio ricorrendo al protocollo Internet Cache Protocol (ICP) e al concetto delle cache gerarchiche

il TAG cache_peer

cache_peer [proxy.domain.com] [type] [port] [port]
  

può essere utilizzato nel caso si disponga di un proxy server esterno sul quale appoggiarsi come quello del Vostro Provider Internet. L'istruzione proxy.domain.com identifica il nome di un host all'interno di un dominio qualificato (fqdn) o l'indirizzo internet del proxy genitore, l'istruzione type invece definisce il grado di parentela che può essere uguale a sibling (fratello germano) o a parent (genitore). Per finire l'istruzione port identifica il numero di porta sulla quale rimane in ascolto il proxy parente al quale desideriamo appoggiarci, la prima istruzione port identifica la porta sulla quale il proxy rimane in ascolto a riguardo del protocollo TCP, la seconda istruzione port è quella dedicata al protocollo ICP. Ecco un esempio completo

cache_peer proxy.merlinobbs.net sibling 3128 0
  

8.6. Files di log, memoria e cache

I log sono una fonte importante di informazioni relative alle attività svolte da Squid e consentono di misurare le prestazioni del nostro proxy server. I log di sistema registrano non soltanto le informazioni relative all'accesso, ma anche gli eventuali errori di configurazione del sistema ed il consumo delle risorse, come la memoria e lo spazio su disco. Alcuni file di log devono essere attivati in maniera esplicità durante la compilazione di Squid, atri possono essere disattivati durante l'esecuzione del processo Squid, il linea di principio nessuno dei files di log deve essere cancellato quando il Squid è in esecuzione.

cache_access_log /usr/local/squid/var/logs/access.log
   

cache_log /usr/local/squid/var/logs/cache.log
   

cache_store_log /usr/local/squid/var/logs/store.log 
   

cache_swap_log /usr/local/squid/var/cache/swap.state
   

useragent_log /usr/local/squid/var/logs/useragent.log
   

%./configure --enable-useragent-log
   

referer_log /usr/local/squid/var/logs/referer.log
   

%./configure --enable-referer-log
   

emulate_httpd_log on 
   

logfile_rotate 10
   

% squid -k rotate
   

01 1 * 1 * /usr/local/squid/sbin/squid -k rotate
   

logfile_rotate 0
   

cache_access_log /dev/null
cache_store_log none
cache_log /dev/null
   

cache_access_log none
cache_store_log none
cache_log /dev/null
useragent_log none 
referer_log none 
   

mime_table /usr/local/squid/etc/mime.conf 
   

pid_filename /usr/local/squid/var/run/squid.pid 
   

cache_mem 64 MB 
   

high_memory_warning 80 MB
   

cache_dir ufs /squid/cache 100 16 256 
   

8.7. Parametri amministrativi

E' possibile impostare l'indirizzo e-mail dello Squidmanager (amministratore della cache) nonchè il nome dell'host

utilizzeremo il TAG cache_mgr

cache_mgr netmaster@nomedominio.com 
  

questo TAG identifica l'indirizzo di posta elettronica dell'amministratore del proxy dove nomedominio.com è il nome di dominio internet qualificato (fqdn)

il TAG visible_hostname

visible_hostname proxy1.nomedominio.com 
  

identifica il nome dell'host visualizzato da Squid nel caso si incontri un messaggio di errore o di semplice messaggio amministrativo dove proxy1.nomedominio.com è il il nome dell'host all'interno di un dominio internet qualificato (fqdn), questo TAG serve inoltre anche per "puntare" gli oggetti interni di Squid come le icone, i messaggi di errore ed altro

il TAG unique_hostname

unique_hostname proxy1.nomedominio.com
  

è utile si si dispone di una macchina che è stata configurata per rispondere a più nomi nell'ambito di un dominio internet qualificato. Con questo sistema è possibile impostare un nome univoco per l'host che esegue Squid

il TAG append_domain

append_domain .nomedominio.com
  

è stato incluso nelle versioni più recenti di Squid, questo TAG aggiunge automaticamente il nome di dominio locale.

8.8. Utente e Gruppo (UID e GID)

I processi ed i file all'interno di un sistema UNIX® hanno un loro utente ed un loro gruppo proprietario, per far funzionare correttamente Squid dovremo selezionare un'utente ed un gruppo dedicati, questo fatto riduce la possibilità che Squid possa essere violato da un utente remoto o da un utente locale.

Il TAG cache_effective_user

cache_effective_user nobody
  

ed il TAG cache_effective_group

cache_effective_group nobody
  

definiscono l'utente ed il gruppo che nei sistemi di classe UNIX® eseguono Squid Proxy Server, il nome dell'utente e del gruppo devono essere validi ovvero devono essere contenuti nel file /etc/passwd. In particolare c'è da dire che l'utente dovrà essere configurato con una classe di permessi molto limitati. E' necessario portare molta attenzione ai permessi di scrittura e di lettura nelle directory dove Squid esegue il disk storage e dove scrive i suoi log.

8.9. Controlli di accesso

Tratteremo questo argomento molto dettagliatamente all'interno del capitolo dedicato alle ACL, la configurazione di default di Squid nega l'accesso a qualsiasi tipo di richiesta venga effettuata dai client, per consentire l'accesso dovremo inserire delle regole addizionali nel file squid.conf. Un'approccio molto semplice è quello di definire una ACL che consenta tutto il traffico proveniente dai nostri client, si supponga che la nostra Local Area Network (LAN) venga identificata dalla subnet 192.168.0.0/24

acl locallan src 192.168.0.0/255.255.255.0
http_access allow locallan
  

nel file squid.conf sono contenute delle regole basilari, vengono inoltre indicati i punti nei quali possiamo inserire i nostri controlli di accesso

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
  

per iniziare possiamo prendere spunto dalle regole base preimpostate nel file squid.conf alle quali aggiungeremo una ACL che concede accesso ai soli client presenti all'interno della nostra Local Area Network (LAN)

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 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 locallan src 192.168.0.0/255.255.255.0
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 localhost
http_access allow locallan
http_access deny all
  

abbiamo così mostrato al lettore una piccola serie di Access Control List (ACL), questa piccola configurazione ci consentirà di avviare Squid concedendo accesso ai nostri utenti.

8.10. Redirect

Squid può riscrivere una URLs implementando un processo esterno che prende il nome di redirector. Squid può essere configurato per passare qualsiasi richiesta di URLs direttamente verso un processo esterno che rielabora la richiesta ricevuta e la sostituisce con un messaggio predefinito. Il redirector consente all'amministratore della cache di controllare le locations sulle quali vorrebbero accedere gli utenti, il redirector stesso si fa carico di leggere la richiesta di URLs o l'input di tipo standard che riceve traducendolo in una falsa URLs. Il redirector può anche fornire una linea bianca come output di uscita standard. In buona sostanza un redirector quindi ridirige una specifica URLs richiesta dai client verso un'altra URLs falsa

il TAG redirect_program

redirect_program /usr/local/bin/squid_redirect
  

consente di specificare il percorso di un file eseguibile esterno a Squid al quale è possibile reindirizzare tutte le richieste HTTP, il programma esterno può funzionare anche da filtro facendo passare solo le richieste che soddisfino determinate regole. Tra i programmi redirector più famosi e più utilizzati citiamo squidGuard e SQUIRM. Di seguito pubblichiamo un semplice esempio di URL redirector realizzato in perl

#!/usr/local/bin/perl
$|=1;
while (<>) {
s@http://www.pippo.it@http://www.pluto.it@;
print;
}
  

8.11. La configurazione di startup (squid.conf)

Come abbiamo detto nel file squid.conf è contenuta la configurazione di Squid, in questo capitolo abbiamo affrontato quelli che possiamo definire come gli aspetti essenziali relativi alla preparazione, alla configurazione e alla installazione minimale di Squid. Abbiamo trattato di alcune impostazioni basilari e, alla luce di quanto sinora scritto, siamo finalmente in grado di mostrare un file di configurazione minimale e di avviare Squid

http_port 3128
icp_port 3130
cache_mem 8 MB
cache_dir ufs /usr/local/squid/var/cache 100 16 256
cache_access_log /usr/local/squid/var/logs/access.log
cache_log /usr/local/squid/var/logs/cache.log
cache_store_log /usr/local/squid/var/logs/store.log
emulate_httpd_log off
mime_table /usr/local/squid/etc/mime.conf
pid_filename /usr/local/squid/var/run/squid.pid
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 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 locallan src 192.168.0.0/255.255.255.0
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 localhost
http_access allow locallan
http_access deny all
cache_mgr squid@miodominio.net
cache_effective_user nobody
cache_effective_group nobody
visible_hostname proxy.nomedominio.net
append_domain .miodominio.net
  

nei capitoli successivi approfondiremo i temi che abbiamo accennato, le nozioni che abbiamo descritto in questo capitolo ci hanno consentito solo di inquadrare in maniera superficiale le potenzialità offerte da Squid, questa configurazione solo minimale ancora non consente al lettore di utilizzare al meglio Squid.

9.1. Preambolo

Le prestazioni di una webcache come Squid possono dipendere da diversi fattori come il tipo di Sistema Operativo, il suo filesystem e dal modello di Cache Store che viene utilizzato da Squid. In questo capitolo considereremo valide le conclusioni di uno studio realizzato da Duane Wessels che è liberamente disponibile alla URLs http://conferences.oreillynet.com/presentations/os2002/wessels_duane.ppt e che fa esplicito riferimento alle seguenti variabili

• Sistemi Operativi: Linux, NetBSD, OpenBSD, FreeBSD e Solaris

• Filesystem utilizzati: UFS, ext2fs, ext3fs, xfs, raiserfs

• Opzioni dei Filesystem: noatime, softupdates, async

• Schemi di Storage: ufs, aufs, diskd

• Versione di Squid: squid-2.4.STABLE5, cache_dir: 3 x 7500 MB, sistema di logging disabilitato, cache_mem: 8 MB

le soluzioni prese in considerazione sono state paragonate utilizzando la medesima piattaforma Hardware

• IBM Netfinity 4000R

• 500 MHz Pentium III

• 1GB RAM

• 3 x 18GB dischi SCSI di cui uno esterno

• scheda di rete Integrata Intel 10/100)

lo studio definisce anche i livelli di performance migliori che vengono rappresentati dalle seguenti soluzioni

• FreeBSD 4.5-STABLE

  tipo di filesystem utilizzato UFS con softupdates montato con l'opzione noatime, diskd Disk Storage, parametri di ottimizzazione del Kernel (MAXFILES=8192, MNBCLUSTERS=32768)

• Linux Kernel 2.4.9-13 con la patch SGI XFS_1.0.2

  tipo di filesystem utilizzato ext2fs montato con l'opzione noatime, aufs Disk Storage, parametri di ottimizzazione del Kernel (8192 file descriptors e l'opzione di configurazione with-aio-threads=32), altre applicazione Xfsprogs 1.3.13 e reiserfsprogs 3.x.0j

A questo punto proviamo ad analizzare nel dettaglio alcune problematiche legate al tipo di file system utilizzato incluse le componenti di una Cache Store, solo in questo modo potremo configurare al meglio la nostra piattaforma scegliendo, tra molte soluzioni, il miglior livello di compromesso.

9.2. Alcune problematiche legate al tipo di filesystem

Tra gli obiettivi da raggiungere da parte di un'amministratore di un Sistema Squid troviamo quello di aumentare sensibilmente le prestazioni del sottosistema di I/O. In precedenza abbiamo trattato di altre questioni, anche piuttosto importanti, che sono legate alle prestazioni del sottosistema di disk I/O ed in particolare abbiamo affrontato il problema dei dischi e delle tecnologie utilizzate per il tipo di bus (SCSI, ATA) relativamente alla nostra configurazione.

Squid utilizza uno schema di storage piuttosto semplice in quanto le attività di disk I/O vengono eseguite direttamente dal processo Squid. Utilizzando un file system UNIX® tradizionale come UFS[22] o ext2[23] alcune operazioni di I/O possono bloccare alcuni processi, in quanto il Sistema Operativo deve allocare ed inizializzare alcune strutture di dati sul disco. Le chiamate di Sistema (System Call) molto spesso non ritornano al Sistema almeno sino a quando l'operazione di I/O non sia stata ultimata definitivamente. Questo fatto può determinare un blocco del processo Squid per un periodo anche piuttosto lungo.

9.3. Eseguire l'ottimizzazione del file system

Vi sono alcune impostazioni di Sistema che possono migliorare decisamente le performance di un filesystem con Squid. Un filesystem può essere montato con l'opzione noatime, questa funzionalità non aggiorna il tempo di accesso sul file quando lo stesso viene letto e può essere utilizzata sui quei file system dove sono stati memorizzati moltissimi files. In questo caso le prestazioni sono più importanti se paragonate con il tempo di accesso ai files, nessun file system di rete attualmente supporta questo tipo di opzione

# Device    Mountpoint FStype Options                        Dump Pass#
/dev/da0s1g /cache     ufs    rw,nosuid,nodev,noexec,noatime 2    2
  

per avere maggiori informazioni possiamo consultare la pagina man del comando mount(8). Un'altra opzione interessante è async, abilitando questa funzionalità del file system potremo eseguire le operazioni di disk I/O in modalità asincrona. Dobbiamo informare gli utenti che l'utilizzo di questo tipo di flag viene considerato piuttosto pericoloso.

A riguardo dei file system c'è da dire che i sistemi *BSD dispongono di una features denominata softupdates, i softupdates, per le loro peculiarità, possono essere paragonati ai file systems di tipo journaled che sono stati inseriti anche nei sistemi GNU Linux.

Con i file system UFS ed ext2 gli aggiornamenti vengono scritti immediatamente, quando vengono inseriti nuovi dati le informazioni verranno scritte immediatamente sul disco. Un journaling filesystem scrive i metadati all'interno di un file di log, questo file è un semplice file sequenziale nel quale vengono memorizzate tutte le informazioni prima che un qualsiasi comando venga eseguito dal Sistema, i metadati verranno successivamente trasferiti dal file di log alla loro reale destinazione. Se una unità a disco va in errore, sarà proprio il file di log che consentirà di riportare i dati sul disco ad una condizione consistente.

I softupdates dei sistemi *BSD al pari dei journaled file system, riordinano e raggruppano le diverse operazioni di modifica dei metadati. Questo modello elimina i problemi che potrebbero affliggere una macchina rimasta priva di alimentazione o una macchina andata in crash. Come abbiamo detto sono diversi i file system del tipo journaled che sono disponibili per i diversi Sistemi Operativi, su GNU Linux possiamo scegliere tra ext3, reiserfs, XFS e JFS, ext3 è un file system ext2 che prevede un file di log per le transazioni del tipo jurnaled.

9.4. Riservare correttamente lo spazio al Cache Storage

Molto spesso viene dedicata una partizione del disco al Cache Storage di Squid. Diciamo subito che non è consigliabile utilizzare tutto lo spazio disponibile sul disco ma è necessario riservare una parte di spazio che sarà dedicata alle operazioni supplementari che vengono effettuate da parte del file system nonchè da parte del Sistema Operativo. Attualmente, Squid non è molto tollerante se il suo Disk Storage viene impostato per funzionare su tutto lo spazio del disco, la dimensione ottimale del disco dedicato al Disk Storage dovrebbe essere di circa 9GB e non tutti i fornitori di unità a disco creano dei supporti che dispongono dello stesso spazio ed un disco da 9GB nella realtà dispone di circa circa 8.5GB di spazio effettivamente utilizzabile. La prima cosa da fare è quella di preparare un file system per l'intera superfice del disco e montarlo per renderlo disponibile a Sistema Operativo.

Solo a questo punto potremmo verificare lo spazio disponibile utilizzando il programma df(8) che, se utilizzato senza argomenti, visualizza la quantità di spazio utilizzato e quello disponibile su tutti i filesystem attualmente montati. Notiamo che verrà perso un certo spazio di disco, tale spazio verrà dedicato agli overheads del file system quali i superblocks, gli inodes e gli indici. Inoltre ricordiamo che UNIX® mantiene normalmente libero il 10% dello spazio disco per le sue operazioni.

Tenendo conto di queste considerazioni, un disco di 9GB dopo la formattazione renderà disponibile per l'utilizzo poco più di 8GB. Successivamente suggeriamo di togliere ulteriore spazio disponibile per un altro 10% che verrà dedicato agli overheads di Squid oltre che ad un buffer per la sicurezza. Inoltre notiamo ancora che Squid lavora molto meglio quando lo spazio libero sul disco è decisamente superiore. Se le prestazioni sono un fattore importante, lo spazio disponibile su disco deve essere ancora di più. Su un disco da 9GB si suggerisce uno spazio dedicato alla cache_dir pari a 6000 - 7500 megabyte

cache_dir ufs /cache1 7000 16 256
  

quando il disco si riempie è necessario verificare l'utilizzo dello spazio su disco, se troviamo spazio inutilizzato in abbondanza, allora dovremmo aumentare le dimensioni della cache_dir.

9.5. Le componenti del Cache Store

Il Cache Store di Squid è caratterizzato da tre componenti fondamentali che sono in stretta relazione tra di loro

• Disk Storage

• Memory Storage

• Memory e Cache Replacement Policy

le performance di una webcache come Squid possono essere fortemente influenzate dalla configurazione del tipo di Cache Store che viene utilizzato. Nei paragrafi seguenti andremo ad analizzare nel dettaglio tutte le possibili opzioni di configurazione.

9.6. Disk Storage

La direttiva cache_dir contenuta nel file di configurazione squid.conf, definisce una tipologia di Disk Storage che non ha nulla a che vedere con il tipo di file system fisicamente utilizzato dal Sistema Operativo. Il Disk Storage di Squid definisce unicamente il metodo di accesso e di implementazione utilizzati internamente dal processo Squid per la gestione del Disk I/O. Attualmente vengono implementati ben 5 differenti sistemi di Disk Storage

• ufs

• aufs (awin32 in Windows)

• diskd

• null

• coss

la scelta del tipo di Disk Storage da attivare, viene effettuata nel momento della configurazione dei parametri di compilazione di Squid

% ./configure --enable-storeio="elenco disk storage"
  

dove l'elenco dei Disk Storage da attivare contiene i nomi (case sensitive) delle cartelle che sono incluse nel source tree di Squid e che ne contengono i sorgenti. Il Disk Storage che viene compilato come default é ufs

% ./configure --enable-storeio="ufs aufs diskd null"
  

nell'esempio precedente abbiamo selezionato i Disk Storage ufs, aufs, diskd e null. Selezionando uno qualunque di questi sistemi di Disk Storage, viene automaticamente impostato e compilato anche il Disk Storage ufs in quanto necessario al corretto funzionamento di tutti i tipi di Disk Storage selezionati. La selezione del Disk Storage da utilizzare avviene tramite il TAG cache_dir di squid.conf, la sintassi generica è la seguente

cache_dir Type Directory-Name Fs-specific-data [options]
  

I valori di default sono

cache_dir ufs /usr/local/squid/var/cache 100 16 256
  

le options sono comuni a tutti i tipi di Disk Storage e si suddividono in

read-only
max-size=n
  

read-only indica che questa cache_dir é di sola lettura mentre max_size identifica la dimensione massima di oggetto che questa cache_dir può immagazzinare. É possibile specificare in squid.conf più di una definizione di cache_dir, anche se la stessa utilizza un differente tipo di Disk Storage, infatti a partire dalla versione 2 di Squid, è possibile aggiungere nuove cache_dir in qualsiasi momento e renderle attive senza ricavarne alcun effetto collaterale.

cache_dir ufs Directory-Name MBytes L1 L2 [options]
   

cache_dir ufs /usr/local/squid/var/cache 4096 16 256
   

cache_dir aufs Directory-Name MBytes L1 L2 [options]
   

cache_dir aufs /usr/local/squid/var/cache 8192 16 256
   

% ./configure --with-aio-threads=32
   

% squidclient mgr:squidaio_counts
HTTP/1.0 200 OK
Server: squid/2.5.STABLE5
Mime-Version: 1.0
Date: Tue, 06 Apr 2004 19:08:27 GMT
Content-Type: text/plain
Expires: Tue, 06 Apr 2004 19:08:27 GMT
Last-Modified: Tue, 06 Apr 2004 19:08:27 GMT
X-Cache: MISS from portatilo.miodominio.net
Proxy-Connection: close
ASYNC IO Counters:
Operation       # Requests
open    93
close   93
cancel  93
write   0
read    108
stat    0
unlink  5
check_callback  9312
queue   0
   

cache_dir awin32 Directory-Name MBytes L1 L2 [options]
   

cache_dir awin32 c:/squid/var/cache 4096 16 256
   

cache_dir diskd Directory-Name MBytes L1 L2 [options] [Q1=n] [Q2=n]
   

diskd_program diskd-path
   

cache_dir diskd /usr/local/squid/var/cache 8192 16 256 Q1=72 Q2=64
diskd_program /usr/local/squid/libexec/diskd
   

% squidclient mgr:diskd
HTTP/1.0 200 OK
Server: squid/2.5.STABLE5
Mime-Version: 1.0
Date: Tue, 06 Apr 2004 19:56:57 GMT
Content-Type: text/plain
Expires: Tue, 06 Apr 2004 19:56:57 GMT
Last-Modified: Tue, 06 Apr 2004 19:56:57 GMT
X-Cache: MISS from proxy.miodominio.net
Proxy-Connection: close
sent_count: 132233
recv_count: 132233
max_away: 26
max_shmuse: 25
open_fail_queue_len: 0
block_queue_len: 0
             OPS SUCCESS    FAIL
   open   21674   21663      11
 create    5478    5478       0
  close   27141   27141       0
 unlink   21294    5873   15421
   read   36111   36100       0
  write   20535   20535       0
   

cache_dir diskd Directory-Name MBytes L1 L2 [options] [Q1=n] [Q2=n]
    

cache_dir diskd /usr/local/squid/cache 7500 16 256 Q1=72 Q2=64
    

options         SYSVMSG
    

options         MSGMNB=16384    # max # of bytes in a queue
options         MSGMNI=41       # number of message queue identifiers
options         MSGSEG=2049     # number of message segments per queue
options         MSGSSZ=64       # size of a message segment
options         MSGTQL=512      # max messages in system
    

    kernel.msgmnb=8192
    kernel.msgmni=40
    kernel.msgmax=8192
    

set msgsys:msginfo_msgmax=2048
set msgsys:msginfo_msgmnb=8192
set msgsys:msginfo_msgmni=40
set msgsys:msginfo_msgssz=64
set msgsys:msginfo_msgtql=2048
    

options         SYSVSHM
    

options         SHMSEG=16       # max shared mem id's per process
options         SHMMNI=32       # max shared mem id's per system
options         SHMMAX=2097152  # max shared memory segment size (bytes)
options         SHMALL=4096     # max amount of shared memory (pages)
    

kernel.shmall=2097152
kernel.shmmni=32
kernel.shmmax=16777216
    

set shmsys:shminfo_shmmax=2097152
set shmsys:shminfo_shmmni=32
set shmsys:shminfo_shmseg=16
    

cache_dir null Directory-Name [options]
   

cache_dir null /tmp
   

cache_dir coss File-Name MBytes max-size=n [options] [block-size=b]
   

cache_dir coss /usr/local/squid/var/cache/CossFile01 2048 max-size=65536 block-size=2048
cache_dir coss /usr/local/squid/var/cache/CossFile02 6744 max-side=1000000 block-size=2048
   

/usr/src/sys/i386/conf/MIOKERNEL
    

options SYSVSHM           # SYSV-style shared memory
                          # Squid Shared Memory DiskD Tuning
options SHMSEG=16         # max shared mem id's per process
options SHMMNI=32         # max shared mem id's per system
options SHMMAX=2097152    # max shared memory segment size (bytes)
options SHMALL=4096       # max amount of shared memory (pages)
    

options MAXFILES=8192
options NMBCLUSTERS=32768
    

options VFS_AIO
    

options SYSVMSG           # SYSV-style message queues
                          # Squid Message Queues DiskD Tuning
options MSGMNB=16384      # max of bytes in a queue
options MSGMNI=41         # number of message queue identifiers
options MSGSEG=2049       # number of message segments per queue
options MSGSSZ=64         # size of a message segment
options MSGTQL=512        # max messages in system
    

% cd /usr/src
% make buildkernel KERNCONF=MIOKERNEL
% make installkernel KERNCONF=MIOKERNEL
% reboot
    

% ./configure --enable-storeio=diskd,ufs 
    

% cd /usr/ports/www/squid
% make config
% make 
% make install clean
    

cache_dir ufs /usr/local/squid/var/cache 6744 16 256
    

cache_dir aufs /usr/local/squid/var/cache 6744 16 256
    

cache_dir awin32 c:/squid/var/cache 6744 16 256
    

9.7. Memory storage

Abbiamo detto anche in precedenza che Squid utilizza un'elevata quantità di memoria RAM per garantire le massime prestazioni. In Squid 2.5, per ogni oggetto presente su disco viene mantenuta in memoria una StoreEntry di 72 byte (104 byte nei sistemi a 64 bit). Un apposita area di memoria definita con il TAG cache_mem di squid.conf viene riservata per contenere i seguenti tipi di oggetto

• In-Transit objects

• Hot objects

• Negative-Cached objects

Gli oggetti di tipo In-Transit hanno sempre priorità sugli altri. Quando è necessario dello spazio addizionale per i dati in arrivo, gli oggetti di tipo Negative-Cached e Hot vengono rilasciati. Possiamo anche dire che gli oggetti di tipo Negative-Cached e Hot possono occupare solamente lo spazio inutilizzato che quindi non è necessario agli oggetti del tipo In-Transit.

cache_mem bytes 
high_memory_warning bytes
maximum_object_size bytes
minimum_object_size bytes
maximum_object_size_in_memory bytes
   

cache_mem 64 MB
   

high_memory_warning 80 MB
   

maximum_object_size 8192 Kb
   

mimum_object_size 1 Kb
   

maximum_object_size_in_memory 64 Kb
   

9.8. Memory e Cache Replacement Policy

La memory e la Cache Replacement policy è l'algoritmo che determina quali oggetti dovranno essere eliminati e/o sostituiti sul disco quando lo spazio è esaurito ed è necessario nuovo spazio nel Memory Storage o nel Disk Storage. Attualmente vengono implementate 4 differenti cache replacement policy

• LRU - Si tratta della policy originaria che viene utilizzata da Squid, LRU rimuove gli oggetti (object) che non sono stati più richiesti da diverso tempo, l'algoritmo può essere implementato su semplici liste LRU

• heap LRU - LRU implementata usando un heap

  LRU e heap LRU conservano gli oggetti referenziati più recentemente

• heap GDSF - Greedy-Dual Size Frequency

  Heap GDSF ottimizza l'hit rate conservando in cache gli oggetti piccoli e più frequenti in modo da avere maggiori probabilità di hit. Fornisce dei minori byte hit rate rispetto a heap LFUDA in quanto scarta gli oggetti di maggiori dimensioni.

• heap LFUDA - Least Frequently Used con aging dinamico

  Heap LFUDA mantiene gli oggetti più frequenti in cache a prescindere dalle dimensioni, ottimizzando il byte hit rate a discapito dell'hit rate, impedendo a molti oggetti piccoli meno frequenti di essere cached.

Utilizzando heap LFUDA, il parametro maximum_object_size di squid.conf deve essere aumentato oltre il suo default di 4096 KB in modo da massimizzarne i potenziali miglioramenti al byte hit rate. Per maggiori informazioni su GDSF e LFUDA consultare le seguenti URLs: http://www.hpl.hp.com/techreports/1999/HPL-1999-69.html e http://fog.hpl.external.hp.com/techreports/98/HPL-98-173.html. La scelta dei tipi di Replacement Policy da attivare, viene effettuata al momento della configurazione dei parametri di compilazione di Squid

% ./configure  --enable-removal-policies="elenco policy"
  

dove l'elenco delle Policy da attivare contiene i nomi (case sensitive) dalle cartelle presenti nel source tree di Squid che ne contengono appunto i sorgenti. La Replacement Policy compilata di default é lru.

% ./configure --enable-removal-policies="lru heap"
  

nell'esempio precedente abbiamo selezionato le Replacement Policy lru e heap

cache_replacement_policy policy
memory_replacement_policy policy
cache_swap_low  low-water-mark
cache_swap_high high-water-mark
   

lru
heap GDSF
heap LFUDA
heap LRU
   

cache_replacement_policy heap LFUDA
   

lru
heap GDSF
heap LFUDA
heap LRU
   

memory_replacement_policy heap GDSF
   

cache_swap_low 85
   

cache_swap_high 90
   

9.9. Indicazione dimensionamento del cache store

Per dimensionare correttamente il Cache Store di una webcache è necessario tener conto di vari aspetti. Il parametro di configurazione cache_mem specifica la quantità massima di memoria utilizzabile da Squid per contenere gli oggetti di tipo In-Transit, Hot e Negative-Cached. Per identificare al meglio il fabbisogno di memoria fare riferimento al paragrafo note sull'utilizzo della memoria RAM. Non dimentichiamo mai che il valore espresso in MByte assegnato al Memory Storage di Squid non dovrebbe mai superare 1/4 della memoria RAM totale installata sul sistema. Se una macchina dispone di 196 Megabytes di RAM fisica è consigliabile impostare un TAG cache_mem pari a 49 MByte

cache_mem 49 MB 
  

un'altra variabile da tenere in considerazione al fine di ottenere delle ottime performance, è quella di definire approssimativamente il numero degli utenti che dovranno utilizzare Squid. La letteratura disponibile in materia, consiglia una assegnazione di circa 20 MByte di spazio cache_dir per ogni utente che accede al proxy server Squid. Dunque 20 utenti contemporanei dovrebbero rappresentare 400 MByte di cache_dir storage

cache_dir ufs /usr/local/squid/cache 400 16 256 
  

un'altra soluzione empirica è quella di definire 10 MByte di RAM per ogni GByte di cache_dir, per le piattaforme a 64 bit come Alpha ed Opteron, il valore deve essere di 14 MByte per ogni GByte, più ulteriori 10 - 20 MByte (15 - 30 nei sistemi a 64 bit). La memoria fisica presente nel sistema dovrebbe essere pari ad almeno il doppio del risultato del precedente calcolo. Tenendo conto delle indicazioni sinora esposte si presenta uno schema di cache implementato con successo in un'ambiente di livello enterprise.

Squid utilizza la memoria del Sistema Operativo per eseguire diverse operazioni

• lettura o scrittura dei buffers su disco

• lettura o scrittura del network I/O buffer

• gestione dei contenuti della cache IP

• gestione dei contenuti della cache di FQDN (Fully Qualify Domain Name)

• misurazione del database NetDB ICMP

• informazioni sulle richieste

• collezioni delle statistiche

si raccomanda inoltre una ulteriore quantità di memoria RAM che verrà utilizzata da parte del sistema operativo per aumentare le prestazioni dell'I/O, nonchè per tutte le altre applicazioni che possono essere eseguite da un Sistema Operativo che esegue, oltre a Squid, anche altri servizi di rete. Un ulteriore livello minimo di memoria RAM è richiesto per il management dei processi, per il logging ed altre routines che vengono sempre eseguite dal Sistema Operativo.

10.1. Preambolo

Tra le funzioni primarie svolte da Squid citiamo quella di inteconnettere una rete privata ad Internet, è possibile implementare diverse politiche di utilizzo per definire le modalità con cui tale accesso debba effettivamente avvenire. Definendo delle liste di controllo di accesso, acronimo di Access Control List o ACL con diverse regole associate, é possibile impedire o consentire agli utenti di accedere a determinati siti o a determinati contenuti ed ancora, è possibile limitare l'accesso nell'utilizzo di particolari protocolli di rete.

Quando Squid elabora una richiesta in uscita, verifica nelle ACL se l'accesso debba essere consentito o negato. É estremamente importante pianificare a priori una strategia completa di accesso prima di iniziare a creare le ACL, solo in questo modo potremmo avere la certezza che le regole che si andranno ad implementare soddisfino le reali necessità.

10.2. Elementi che compongono le ACL

Vediamo ora alcune informazioni sulla tipologia delle ACL che possono essere utilizzate da Squid, le tipologie sono aggiornate alla versione 2.5.STABLE5. Squid è oggi in grado di riconoscere i seguenti tipi di ACL

• src

  indirizzo IP del sorgente (client)

• dst

  indirizzo IP di destinazione (server) o indirizzo IP del server di destinazione

• myip

  l'indirizzo IP locale di una macchina che esegue una connessione client

• srcdomain

  il nome di dominio sorgente (client)

• dstdomain

  il nome di dominio di destinatizione (server)

• srcdom_regex

  espressione regolare che identifica un pattern contenuto in un indirizzo sorgente (client)

• dstdom_regex

  espressione regolare che identifica un pattern contenuto in un indirizzo di destinazione (server)

• time

  orario per giorno o giorno della settimana

• url_regex

  espressione regolare che identifica una URL

• urlpath_regex

  espressione regolare che identifica una URL-path, non viene specificato il protocollo e l'eventuale hostname

• port

  seleziona e specifica il numero di porta per il server di destinazione (server)

• myport

  seleziona e specifica il numero di porta che il client utilizza per connettersi a

• proto

  protocollo di trasferimento (http, ftp, ecc.)

• method

  metodo di richiesta HTTP (get, post, ecc.)

• browser

  espressione regolare che identifica una richiesta che viene effettuata da un browser web specifico

• ident

  stringa che si combina con un nome utente

• ident_regex

  espressione regolare che identifica uno user name specifico

• src_as

  numero di un Sistema Autonomo sorgente (client)

• dst_as

  numero di un Sistema Autonomo di destinazione (server)

• proxy_auth

  autenticazione degli utenti attraverso un processo esterno

• proxy_auth_regex

  autenticazione degli utenti attraverso un processo esterno

• snmp_community

  definizione di una SNMP community string

• maxconn

  un limite al numero massimo di connessioni che arrivano da un singono indirizzo IP

• req_mime_type

  espressione regolare che identifica un header del tipo content-type incluso in una richiesta

• arp

  comparazione con un Ethernet (MAC) addres

• rep_mime_type

  espressione regolare che identifica un pattern che viene inviato come risposta (downloaded content) all'intestazione del tipo content-type. Questo tipo di ACL può essere utilizzato unicamente nelle direttive http_reply_access ma non nelle direttive http_access

• external

  esegue il lookup ricorrendo a degli acl helper esterni che sono stati definiti da delle ACL del tipo external_acl_type

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.

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

10.4. Utilizzare le ACL per autenticare degli utenti

Un'altra interessante opzione offerta da Squid è rappresentata dalla possibilità di limitare l'accesso al proxy tramite eventuale autorizzazione, autenticazione ed accounting. In una rete geografica di grandi dimensioni l'utilizzo di Squid può rilevarsi utile per il controllo degli accessi.

Non dimentichiamo che un proxy è un gateway a livello applicativo (Layer 7 della pila OSI) e può essere utilizzato anche come firewall tra due reti, va sottolineato, per i puristi del TCP/IP, che il termine firewall in questo caso non è corretto in quanto Squid non esegue alcun filtraggio di pacchetti.

Squid può essere utilizzato come applicazione per il controllo e la verifica, grazie alle sue funzionalità si rivelerà molto utile nell'implementazione di una politica di sicurezza. Per attivare il controllo di accesso a livello utente é necessario attivare almeno uno schema di autenticazione ed aggiungere nelle ACL i seguenti TAG

acl password proxy_auth REQUIRED
http_access allow password
  

quando viene impostata un qualsiasi tipo di ACL del tipo proxy_auth tramite le regole http_access, tutte le ACL successive alla regola proxy_auth non verranno più considerate da Squid in quanto o l'accesso sarà stato consentito oppure verrà generato un errore di acceso negato alla cache. Se si deve configurare un proxy in maniera granulare è quindi necessario portare molta attenzione nell'applicazione delle regole http_access. In buona sostanza, una volta che ci si è autenticati su un sistema Squid è tutto permesso tranne quello che è stato esplicitamente negato nelle regole http_access precedenti alla regola http_access proxy_auth

http_access allow localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny locallan102
http_access deny porn
http_access deny badlang
http_access deny entertain
http_access deny games
http_access deny mp3
http_access deny pirate
http_access deny pron
http_access deny ftpblock
http_access allow sitiok
http_access allow password
  

come abbiamo visto sopra, è possibile l'accesso all'host locale, successivamente procediamo con la definizione di una serie di blocchi che riguardano le reti non autorizzate, i vari siti non consoni all'utilizzo del proxy, autorizziamo i siti censiti come visitabili e successivamente procediamo con la richiesta di autenticazione del tipo basic. L'utente, dopo aver proceduto ad autenticarsi, sarà autorizzato a fare tutto quello che non gli sia già stato esplicitamente negato.

10.5. External ACL

Squid 2.5 introduce la possibilità di estendere gli elementi che compongono le ACL con una nuova classe di ACL denominata external, tale classe si basa sul risultato di un helper esterno che agisce in modo similare al sistema di autenticazione.

Questa nuova funzionalità rende agevole, ad esempio, l'implemetazione di meccanismi di controllo relativo alla appartenenza di un utente a determinati gruppi, oppure esegue dei controlli più complessi tra i quali citiamo la corrispondenza tra un utente ed un indirizzo IP prefissato.

Al momento gli helper disponibili sono ancora pochi e sono esclusivamente dedicati al controllo di accesso a livello utente. La scelta degli helper da attivare viene effettuata al momento della configurazione dei parametri di compilazione di Squid, il nome dell'helper da specificare è il nome (case sensitive) dalla cartella presente nel source tree di Squid che contiene i sorgenti dell'applicazione

./configure --enable-external-acl-helpers="winbind_group ip_user"
  

l'esempio di cui sopra rappresenta le instruzioni necessarie alla compilazione di due helpers esterni quali winbind_group e ip_user.

external_acl_type wb_group concurrency=5 ttl=900 %LOGIN \
/usr/squid/libexec/wb_group 
   

acl password proxy_auth REQUIRED
acl internetfull external wb_group -i "/usr/squid/etc/internetfull" 
acl internetnormal external wb_group -i "/usr/squid/etc/internetnormal" 
acl internettodow external wb_group -i "/usr/squid/etc/internettodow" 
acl internettonav external wb_group -i "/usr/squid/etc/internettonav"
acl time_acl time M T W H F 8:30-19:00
acl nointernet src "/usr/squid/etc/nointernet"
acl goodurl url_regex -i "/usr/squid/etc/goodurl" 
acl badurl url_regex -i "/usr/squid/etc/badurl" 
acl badmime url_regex -i "/usr/squid/etc/badmime"
http_access allow password internetfull 
http_access allow password internetnormal time_acl !badurl !badmime 
http_access allow password internettonav time_acl !badmime 
http_access allow password internettodow time_acl !badurl 
http_access deny all 
   

-c use case insensitive compare
-d enable debugging
-h this message
   

% /usr/squid/libexec/wb_group -d
/wb_group[14984](wb_check_group.c:267):
External ACL winbindd group helper build Jan 15 2003, 13:29:15 starting up...
DOMINIO\\Utente Gruppo <--- inserire così (con il doppio "\")
/wb_group[14984](wb_check_group.c:286): Got 'DOMINIO\\Utente Gruppo' from Squid (length: 35).
/wb_group[14984](wb_check_group.c:188): SID: S-1-5-21-1836190980-1428173729-311576647-1168
/wb_group[14984](wb_check_group.c:154): Windows group: Gruppo1, Squid group: Gruppo
/wb_group[14984](wb_check_group.c:188): SID: S-1-5-21-1836190980-1428173729-311576647-512
/wb_group[14984](wb_check_group.c:154): Windows group: Domain Admins, Squid group: Gruppo
/wb_group[14984](wb_check_group.c:188): SID: S-1-5-21-1836190980-1428173729-311576647-1510
/wb_group[14984](wb_check_group.c:154): Windows group: Gruppo, Squid group: Gruppo OK
   

external_acl_type wb_group concurrency=5 ttl=900 %LOGIN /usr/squid/libexec/wbinfo_group
   

external_acl_type NT_global_group %LOGIN c:/squid/libexec/win32_check_group.exe -G
external_acl_type NT_local_group %LOGIN c:/squid/libexec/win32_check_group.exe
acl GProxyUsers external NT_global_group GProxyUsers
acl LProxyUsers external NT_local_group LProxyUsers
acl password proxy_auth REQUIRED
http_access allow password GProxyUsers
http_access allow password LProxyUsers
http_access deny all
   

-G start helper in Global Group mode
-c use case insensitive compare
-d enable debugging
-h this message
   

external_acl_type ldap_group %LOGIN /usr/local/squid/libexec/squid_ldap_group ...
acl gruppo1 external ldap_group Gruppo1
acl gruppo2 external ldap_group Gruppo2
acl password proxy_auth REQUIRED
http_access allow password Gruppo1
http_access allow password Gruppo2
http_access deny all
   

squid_ldap_group -b "base DN" -f "LDAP search filter" 
                 [options] [ldap_server_name[:port]...|URI] 
   

external_acl_type Linux_group %LOGIN /usr/local/squid/libexec/squid_unix_group
acl gruppo1 external Linux_group Gruppo1
acl gruppo2 external Linux_group Gruppo2
acl password proxy_auth REQUIRED
http_access allow password Gruppo1
http_access allow password Gruppo2
http_access deny all
   

squid_unix_group [-g group1 -g group2 -g group3 ...] [-p] 
   

external_acl_type IP_Check %SRC %LOGIN /usr/local/squid/libexec/ip_user_check -f /usr/local/squid/etc/ip_user_check.conf
acl resticted external IP_Check
acl password proxy_auth REQUIRED
http_access allow password restricted
http_access deny all
   

ip_user_check -f <configuration_file> 
   

ip[/mask]             utente
   

ip[/mask]             @gruppo
   

ip[/mask]             NONE
   

ip[/mask]             ALL
   

# Tutti gli utenti della rete 192.168.1.0/24 sono autorizzati
192.168.1.0/255.255.255.0     ALL
#
# Gli utenti della rete 192.168.2.0/24 non sono autorizzati
# tranne l'utente `boss´ che può autenticarsi ovunque
0.0.0.0/0.0.0.0       boss
192.168.2.0/255.255.255.0     NONE
#
# L'utente `gianni´ può autenticarsi solo dall'indirizzo IP delle propria stazione
192.168.3.45  jayk
#
# Gli utenti appartenenti al gruppo `cad´ possono autenticarsi solo dalla propria VLAN
10.0.0.0/255.255.0.0  @cad
   

10.6. Controllo d'accesso sui siti web

La politica di sicurezza può naturalmente prevedere delle limitazioni di accesso su taluni siti web: siti a sfondo sessuale o ludico possono essere vietati. Squid può essere utilizzato anche come potente strumento di content management. É possibile limitare i contenuti a parte della rete aziendale: la rete degli utenti può essere monitorata e filtrata utilizzando il sistema di autenticazione e la procedura di content managment.

acl porn url_regex "/squid/etc/blocked/porn.block.txt" 
acl notporn url_regex "/squid/etc/blocked/porn.unblock.txt" 
acl badlang url_regex "/squid/etc/blocked/badlang.block.txt" 
acl entertain url_regex "/squid/etc/blocked/entertain.block.txt" 
acl games url_regex "/squid/etc/blocked/games.block.txt" 
acl pirate url_regex "/squid/etc/blocked/pirate.block.txt" 
   

http_access deny porn 
http_access deny badlang 
http_access deny entertain 
http_access deny games 
http_access deny pirate 
   

.sex.de
.playboy.com.br
.clubhardcore.com
www-cache.fh-bingen.de
.monkeylove.com
.amateur-pages.com
.hitboss.com
.peep.com
.erotism.com
.sinfulmail.com
.nookie.com
.snapshots.com
.onlyteens.com
heavyhangers
.dailydirt.com
hustler
.brunclik.cz
.desibaba.com
.picturepost.com
.haloo.fi
.smut.com
   

acl allowed_hosts src 192.168.0.0/255.255.255.128
acl allowed_hosts1 src 192.168.0.128/255.255.255.128
acl allowed_hosts2 src 192.168.1.0/255.255.255.0
acl porn url_regex "/etc/squid/block/porn.block.txt"
acl consentiti url_regex "/etc/squid/block/consentiti.txt"
acl nonconsentiti url_regex "/etc/squid/block/nonconsentiti.txt"
acl snmpManager src 192.168.0.4/255.255.255.255
acl snmppublic snmp_community public
   

http_access allow localhost
http_access allow allowed_hosts
http_access allow consentiti
http_access deny nonconsentiti
http_access allow allowed_hosts1
http_access deny manager all
http_access deny all
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
   

www.totallyspies.com
www.it.barbie.com
www.myscene.com
www.witchmagazine.it
www.streghe.net
go.to/streghe
www.antoniogenna.net
disney
www.diddl.com
www.pollypocket.com
www.cartoonnetwork.it
www.repubblica.it
merlinobbs.net
www.foxkids
www.melevisione.rai.it
www.xmen
www.batman
powerrangers
   

% more nonconsentiti.txt
.
   

acl cisco dstdomain .cisco.com
always_direct allow cisco
   

Gator/5.0 Script FD6B41F906B248C3B5711814B3F375B8 2 0.00 Gator/5.0 Precision Time \ 
   

acl gator browser Gator/5.0
Http_access deny gator
   

Windows-Media-Player/9.00.00.3128
   

acl WMP browser Windows-Media-Player/*
http_access deny WMP
   

acl reqmsn req_mime_type -i ^application/x-msn-messenger
acl repmsn rep_mime_type -i ^application/x-msn-messenger
   

http_access deny reqmsn
http_reply_access deny repmsn
   

acl all src 0/0
no_cache deny all
   

10.7. ACL basate sul MAC address

E' possibile impostare delle ACL basate sul MAC address, questo tipo di configurazione può essere utilizzato addizionamente o in sostituzione delle ACL "canoniche" che sono basate sugli indirizzi IP. E' opportuno dire che questo tipo di ACL non funziona con tutti i sistemi operativi supportati da Squid. Attualmente le ``ARP ACLs'' sono pienamente supportate sui seguenti sistemi operativi:

• Linux

• Solaris

• FreeBSD 4.11-STABLE

• con molta probabilità sono supportare anche da FreeBSD 5.3-STABLE nonchè le altre varianti dei sistemi BSD

E' opportuno dire che Squid è in grado di determinare il MAC address dei client che si trovano all'interno della stessa subnet, ne consegue che se il client si trova su una subnet differente, Squid non sarà in grado di identificare l'indirizzo di MAC address. Per utilizzare i controlli ARP (MAC) access è necessario compilare il codice opzionalmente fornito con i sorgenti, per procedere con questa operazione è necessario compilare Squid con la direttiva --enable-arp-acl come opzione di configurazione

% ./configure --enable-arp-acl ...
  

se src/acl.c non compila o va in errore è ipotizzabile supporre che le ARP ACLs non sono supportate dal sistema operativo che state utilizzando, se contrariamente tutto compila correttamente è possibile inserire le linee relative alle ARP ACL direttamente nel file di configurazione di Squid squid.conf

acl M1 arp 01:02:03:04:05:06
acl M2 arp 11:12:13:14:15:16
http_access allow M1
http_access allow M2
http_access deny all
  

11.1. Preambolo

Il principio che risiede alla base della autenticazione è molto semplice, il client invia il proprio nome utente e la propria password, Squid verifica le credenziali dell'utente consultando o il file dove vengono memorizzati gli utenti di sistema e le loro password oppure interroga un servizio di directory esterno. Di seguito elenchiamo nel dettaglio gli schemi di autenticazione implementati da Squid proxy server. In particolare tratteremo le specifiche relative agli schemi proposti da Squid ed entreremo nel merito di alcune implementazioni del sistema di autenticazione utilizzato da Squid nei diversi contesti operativi.

11.2. Schemi di autenticazione

In precedenza abbiamo già fornito alcune nozioni di base per quello che concerne gli schemi di autenticazione. Per "schema di autenticazione" si intende definire il tipo di protocollo che viene utilizzato per la validazione delle credenziali utente tra Browser web ed il Server, dove quest'ultimo può essere un Proxy Server o un Web Server. Ad oggi Squid supporta tre schemi di autenticazione

• Basic

• NTLM

• Digest

A partire da Squid-2.5-STABLE1, tutta la parte relativa alla autenticazione è stata totalmente modularizzata, permettendo l'utilizzo contemporaneo di un maggior numero di schemi di autenticazione. La scelta dei moduli da attivare viene effettuata al momento della configurazione dei parametri di compilazione di Squid

% ./configure --enable-auth="elenco schemi" 
  

nell'esempio di cui sopra, il valore "elenco schemi" può assumere i valori ntlm, basic e digest.

Nelle versioni precedenti, in particolare le releases 2.3 e la 2.4, era disponibile il solo schema di autenticazione basic.

Nel caso in cui siano attivi più schemi di autenticazione, il Browser web seleziona automaticamente quello da lui supportato scegliendo quindi il livello di sicurezza dichiarato come più alto, l'ordine di priorità è il seguente

• Digest

• NTLM

• Basic

11.3. Parametri di Configurazione

Per il processo di autenticazione Squid utilizza dei programi esterni detti helper che si occupano della verifica delle credenziali utente. Tutti i parametri relativi alla configurazione dei tre schemi di autenticazione supportati sono specificati in squid.conf tramite la direttiva auth_param, il suo formato generico è

auth_param schema parametro [valore]
  

per attivare uno schema di autenticazione é sufficiente configurare l'helper ad esso associato e riavviare Squid (squid -k reconfigure). L'ordine con cui gli schemi di autenticazione vengono proposti al browser web segue l'ordine con cui sono definiti nel file di configurazione squid.conf. Alcune versioni di Internet Explorer, a causa di un noto bug, non seguono fedelmente le specifiche RFC 2617 (http://www.faqs.org/rfcs/rfc2617.html) e, anche in presenza di schemi più sicuri, utilizzano erroneamente lo schema Basic, se questo viene proposto per primo al browser web. Per ovviare a questo problema, si raccomanda di definire gli schemi nel file di configurazione nell'ordine Digest, NTLM e Basic.

Una volta che uno schema di autenticazione é stato totalmente configurato, l'unico modo per terminarne l'esecuzione é riavviare Squid, modifiche alla configurazione possono essere eseguite "al volo" tramite il comando squid -k reconfigure. Per esempio, é possibile cambiare il tipo di l'helper utilizzato, ma non è possibile disattivarne del tutto l'utilizzo, in quanto lo stesso è legato ad uno schema di autenticazione attivo. Per utilizzare l'autenticazione è necessario definire un TAG con una acl nella quale venga specificata almeno la seguente direttiva

acl password proxy_auth REQUIRED
  

tale direttiva definisce l'elemento ACL password che potrà essere utilizzato in tutte le acl standard di Squid. La scelta degli helper da attivare viene effettuata al momento della configurazione dei parametri di compilazione di Squid

% ./configure --enable-schema-auth-helpers="elenco helper"
  

dove schema può assumere i valori ntlm, basic e digest, il nome dell'helper da specificare è il nome (case sensitive) dalla cartella nel source tree di Squid che ne contiene i sorgenti

% ./configure --enable-auth="ntlm basic" \
--enable-ntlm-auth-helpers="fakeauth winbind SMB" \
--enable-basic-auth-helpers="NCSA winbind MSNT" 
  

nell'esempio precedente abbiamo selezionato gli schemi di autenticazione Basic e NTLM, contemporaneamente abbiamo anche definito gli helper NCSA, winbind e MSNT relativamente allo schema Basic. Abbiamo anche definito gli helpers Fakeauth, winbind ed SMB relativamente allo schema NTLM.

Nota: In Squid 2.4, dove non esistono altri schemi di autenticazione oltre al Basic, la scelta degli helper da attivare può essere effettuata utilizzando la seguente opzione del comando ./configure

% ./configure --enable-auth-modules="elenco helpers" 
  

Il funzionamento globale del motore di autenticazione di Squid é controllato dalle seguenti direttive

authenticate_cache_garbage_interval timespan
authenticate_ttl timetolive
authenticate_ip_ttl timetolive
  

il TAG authenticate_cache_garbage_interval timespan

Definisce l'intervallo con cui vengono effettuati i cicli di garbage collection sul contenuto della username cache. Il valore predefinito é 1 ora, e rappresenta un compromesso tra l'utilizzo di memoria (intervalli lunghi, per esempio 2 giorni) e di CPU (intervalli brevi, per esempio 1 minuto). Si raccomanda di non variare questa impostaziona senza una valida motivazione

authenticate_cache_garbage_interval 1 hour
  

il TAG authenticate_ttl timetolive

Indica la durata del periodo per cui vengono mantenute in cache le credenziali relative ad un utente a partire dalla sua ultima richiesta. Quando viene iniziato un ciclo di garbage, tutte le credenziali utente il cui TTL é spirato vengono eliminate dalla memoria. Il valore predefinito é 1 ora.

authenticate_ttl 1 hour
  

il TAG authenticate_ip_ttl timetolive

Questa direttiva controlla quanto a lungo Squid conserva l'associazione indirizzo IP/utente quando si utilizza uno o più schemi di autenticazione in concomitanza con una ACL di tipo 'max_user_ip'. Si raccomanda l'utilizzo di un valore piccolo (per esempio 60 secondi) se si prevede che gli utenti possano cambiare indirizzo IP spesso, come nel caso di connessioni di tipo dialup. In reti locali di tipo corporate con indirizzi tendenzialmente statici é raccomandabile l'utilizzo di valori maggiori (per esempio 2 ore). Il valore predefinito é 0 secondi.

authenticate_ip_ttl 0 seconds
  

11.4. Basic Authentication

Lo schema di autenticazione Basic era già disponibile in tutte le precedenti versioni di Squid, ma a partire dalla versione 2.5 la sintassi delle direttive di configurazione contenute in squid.conf é sensibilmente variata rispetto alla versione precedente, per completezza analizzeremo entrambe le versioni.

auth_param basic program cmdline
auth_param basic children numberofchildren
auth_param basic realm realmstring
auth_param basic credentialsttl timetolive
   

auth_param basic program /usr/local/squid/libexec/ncsa_auth \
/usr/local/squid/etc/passwd
   

auth_param basic children 5
   

auth_param basic realm Squid proxy-caching web server
   

auth_param basic credentialsttl 2 hours
   

authenticate_program cmdline
authenticate_children numberofchildren
   

authenticate_program /usr/local/squid/libexec/ncsa_auth /usr/local/squid/etc/passwd
   

authenticate_children 5
   

auth_param basic program /usr/local/squid/libexec/ncsa_auth \
/usr/local/squid/etc/passwd
auth_param basic children 10
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 30 minutes
   

% htpasswd -c /usr/local/squid/etc/passwd stefano 
New password: 
Re-type new password: 
Adding password for user stefano 
    

auth_param basic program /usr/local/squid/libexec/pam_auth
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 45 minutes
   

-n service_name  The PAM service name (default squid)
-t ttl           PAM connection ttl in seconds (default 0)
                 during this time the same connection will be reused
                 to authenticate all users
-o               Do not perform account mgmt (account expiration etc)
-1               Only one user authentication per PAM connection
   

% touch /etc/pam.d/squid 
    

Auth required     /lib/security/pam_stack.so service=system-auth
Auth required     /lib/security/pam_nologin.so 
account required  /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required  /lib/security/pam_stack.so service=system-auth
    

squid auth required /lib/security/pam_unix.so.1
squid account required /lib/security/pam_unix.so.1
    

auth_param basic program /usr/local/squid/libexec/squid_ldap_auth -b \
dc=your,dc=domain 
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 30 minutes
   

squid_ldap_auth -b basedn [-s searchscope]
               [-f searchfilter] [-D binddn -w bindpasswd]
               [-u attr] [-h host] [-p port] [-P] [-R] [ldap_server_name[:port]] ...
   

squid_ldap_auth -b ou=people,dc=your,dc=domain ldapserver
    

squid_ldap_auth -b dc=your,dc=domain -f uid=%s ldapserver
    

squid_ldap_auth -b dc=your,dc=domain -f (&(uid=%s)(specialattribute=value)) ldapserver
    

squid_ldap_auth -u cn -b cn=Users,dc=your,dc=domain ldapserver
    

squid_ldap_auth -P -R -b dc=your,dc=domain \
-D cn=squid,cn=users,dc=your,dc=domain -w secretsquidpassword \
-f (&(userPrincipalName=%s)(objectClass=Person)) activedirectoryserver
    

auth_param basic program /usr/local/squid/libexec/wb_auth
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 30 minutes
   

-d enable debugging
-h this message
   

auth_param basic program /usr/local/squid/libexec/msntauth
auth_param basic children 8
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 15 minutes
   

# 
#      PDC       BDC         DOMAIN 
#      --------- ----------- ----------- 
server paperino  pippo       mio_dominio 
# 
denyusers /usr/local/squid/etc/denyusers 
allowusers /usr/local/squid/etc/allowusers
   

11.5. NTLM Authentication

In questa sezione tratteremo lo schema di autenticazione NTLM (v1 e v2) che è stato implementato a partire versione 2.5 di Squid, faremo riferimento al protocollo NTLM, analizzando le modalità di utilizzo di questo sistema di validazione.