Squid-Book Oltre Le FAQ

Squid-Book oltre le FAQ

Stefano Tagliaferri <squid(at)merlinobbs.net>
Diario delle Revisioni

Revisione 4.33 14 Dicembre 2005
utilizzare le ACL per bloccare msn-messanger
Revisione 4.32 20 Novembre 2005
Core developers, nuove opzioni di configurazione relative a Squid 2.5-STABLE12
Revisione 4.31 30 Aprile 2005
backport proxy anonimizzante
Revisione 4.30 12 Ottobre 2004
Squid, NTLM e Windows Update V5, specifiche dei protocolli HTTP, FTP, SSL/TSL e Gopher, definizione di latency,
bandwidth e serverload, bloccare gli spyware e le web TV, approfondimenti e ulteriori dettagli per monitorare Squid, file
descriptors con linux, il file di configurazione, prelevare i sorgenti utilizzando il CVS, ulteriore revisione ed aggiornamento
del documento
Revisione 4.20 25 Luglio 2004
Aggiornamento della versione di Squid, alcuni aggiornamenti sull'helper ntlm_auth
Revisione 4.10 23 Maggio 2004
Correzioni ed integrazioni varie relativamente agli schemi di autenticazione Basic ed NTLM, note sull'inserimento delle
macchine UNIX® nei domini Windows, proxy trasparente con ipfw(8) ed ipf(8), WCCP
Nuova riorganizzazione documento, il capitolo "Controllare Squid" è stato integrato con il paragrafo dedicato al cache
manager, rivisitato il capitolo dedicato alle ACL al quale sono state aggiunte le funzionalità dei nuovi helper external ACL
squid_unix_group, ip_user_check e win32_check_group, altre informazioni sulla compilazione, avviare una versione
compilata con Red Hat Linux, IRCACHE e GARR, i modelli di cache store, il tuning del file system, acceleratore SSL, alcune
aggiunte relative al capitolo dedicato ai delay pools, troubleshooting con il file access.log, codici di stato, metodi di richiesta e
codici gerarchici.
Revisione 3.60 27 Marzo 2004
Nuova riorganizzazione documento, il capitolo "Hardware consigliato per Squid" è stato integrato nel capitolo Configurare
Squid, lavorare con il codice sorgente di Squid, istruzioni per scegliere l'ambiente di lavoro ottimale, compilare ed installare
Squid, disponibilità dei pacchetti precompilati, il Cache Manager, Ad Zapping con Squid
Revisione 3.50 6 Marzo 2004
Introduzione a Squid: il concetto di webcache, i vantaggi di un sistema webcache tra performance, policy e sicurezza, elementi
che compongono le ACL, ACL basate sul MAC address. Configurare WPAD con ISC DHCP, WPAD round robin, ulteriori
riferimenti, revisioni ed aggiornamenti alla versione 2.5.STABLE5 (supporto NTLMv2)
Revisione 3.40 23 Gennaio 2004
Problemi comuni riscontrati con il sistema di autenticazione NTLM, descrizione delle funzionalità del nuovo helper external
acl "squid_ldap_group", integrazione delle istruzioni per l'avvio multipiattaforma, integrazione delle istruzioni per l'avvio con
GNU Debian Linux e i sistemi Windows, nuova riorganizzazione ed adeguamento
http://www.merlinobbs.net/Squid-Book/HTM/ (1 of 263)14/02/2006 11.31.52

Riorganizzazione ed adeguamento del capitolo relativo ai sistemi di autenticazione, riorganizzazione ed adeguamento del
capitolo relativo ai controlli di accesso a cura di Guido Serassio, aggiornamento della storia dello Squid-Book con relativo
riepilogo degli autori, addendum al capitolo relativo al controllo di accesso, aggiornamento del capitolo relativo
all'avviamento di Squid
HTCP e Cache Digest, privacy ed anonimato, TrendMicro InterScan Web Security Suite e Squid di Stefano Tagliaferri,
annotazioni sull'utilizzo di wb-group 1.20, alcuni cenni sull'Autenticazione con Samba 3.x, ampliamento della sezione sulle
Cache gerarchiche di Guido Serassio
Revisione 3.21 14 Settembre 2003
Alcune annotazioni sull'utilizzo delle acl e dei controlli di accesso
Revisione 3.20 19 Agosto 2003
Correzioni al paragrafo relativo alle pubblicazioni su carta e al paragrafo dei riferimenti, ulteriore integrazione al capitolo
relativo a MRTG e Squid, rielaborazione dello schema e dei riferimenti sulla questione dell'autenticazione, integrazione del
paragrafo relativo ai controlli di accesso sui siti web ed altro.
Revisione 3.10 26 Giugno 2003
Grazie al grande contributo di Antonio Fragola a.k.a. MrShark è stato possibile rilasciare la versione "portabile" dello Squid-
Book, apportate piccole modifiche alla Licenza utilizzo, revisione globale di tutti i capitoli.
Revisione 3.00 8 Giugno 2003
I log di Squid e la loro analisi, salvaguardare la privacy con Junkbuster e Privoxy, aggiornato la La storia di questo
documento, Squid Proxy Server, Configurare SNMP e le FAQ per il controllo accesso ai siti web.
GARR Network's FTP Archive diviene mirror ufficiale dello Squid-Book.
Autenticazione con NTLM nei domini Windows NT o in Active directory (Federico Lombardo - note per la compilazione di
Guido Serassio), commenti alle configurazioni operative e inserimento di nuove configurazioni fornite dagli utenti di Squid. Il
capitolo 19 è stato totalmente trasformato: gli utilizzi estremi ora sono security ed utilizzi estremi (determinante il contributo
di Federico Lombardo, le verifiche sono a cura dell'autore del libro)
Differenze tra rel. 2.4 e 2.5 (Federico Lombardo), schemi di autenticazione (Guido Serassio)
Modificato il capitolo con il quale si spiega cosa è Squid (aggiornato con il link relativo al porting per la piattaforma Win32)
Modificato il capitolo dedicato alle funzionalità di reverse proxy (aggiunta di esempi reali sul funzionamento dei reverse
proxy)
Revisione 1.27 15 Ottobre 2002
Rilascio della prima versione pubblica in formato HTML
Squid-Book oltre le FAQ (Squid-2.5-STABLE12) - L'unica guida in lingua italiana a Squid Proxy Server Copyright © 1999 -
2005 Stefano Tagliaferri

Split HTML - Single HTML
Sommario
1. Informazioni
1.1. Pubblicazioni su carta
1.2. Note sul libro
1.3. Note sull'autore
1.4. Altre annotazioni
1.5. Licenza d'utilizzo
1.6. Riferimenti
1.7. Convenzioni utilizzate
2. La storia di Squid e dello Squid-Book
2.1. Preambolo
2.2. Il Core Development Team
2.3. Un programma libero
2.4. Mailing lists
2.5. Le origini dello Squid-Book
2.6. Chi sviluppa oggi lo Squid-Book
2.7. Squid, il software libero e la situazione Italiana
3. Cosa è Squid
3.1. Preambolo
3.1.1. L'architettura Web
3.1.2. Clients e Servers
3.1.3. Proxies
3.1.4. Oggetti web
3.1.5. URL
3.1.6. Un sistema di webcache
3.2. Fattori basilari che intervengono nella trasmissione dei dati
3.2.1. Tempo di latenza (latency)
3.2.2. Capacità di banda (bandwidth)
3.2.3. Utilizzo delle risorse del server (server load)
3.3. Come lavora un apparato di webcache
3.4. Riduzione delle esigenze di banda
3.5. Fattori che determinano il risparmio di banda

3.5.1. contenuti pagina web

3.5.2. numero degli utenti
3.5.3. tipologia degli utenti
3.5.4. tipo di webcache utilizzata
3.5.5. tipologia della rete
3.6. Controllo e sicurezza
3.7. Una piccola panoramica su HTTP
3.8. Una piccola panoramica su FTP
3.9. Una piccola panoramica su SSL/TSL
3.10. Una piccola panoramica su Gopher
3.11. Una piccola panoramica su WWWCACHE
3.12. Cosa sono le cache gerarchiche
3.12.1. Internet Cache Protocol (ICP)
3.12.2. Cache Array Routing Protocol (CARP)
3.12.3. Hyper Text Caching Protocol (HTCP)
3.12.4. Cache Digest
3.13. Concludendo
4. I sistemi operativi che supportano Squid
4.1. Preambolo
4.2. Piattaforme specifiche
4.3. Sistemi UNIX®
4.3.1. GNU Linux
4.3.2. FreeBSD
4.4. Sistemi Windows
4.5. Sistemi OS/2
5. Differenze tra Squid 2.4 e Squid 2.5
5.1. Preambolo
5.2. Autenticazione
5.3. SSL Gatewaying
5.4. Link Satellitari
5.5. modifiche al file squid.conf
5.6. Considerazioni
6. Casi di studio
6.1. Sistemi in test
6.2. Sistemi in produzione
7. Configurare ed installare Squid
7.1. Preambolo
7.2. Scegliere il Sistema Operativo
7.3. Regole da rispettare
7.3.1. Utilizzo della memoria RAM
7.3.2. Tipo di CPU
7.3.3. Simmetric Multi Processor (SMP)
7.3.4. Sottosistema dischi e tecnologie
7.3.5. Sistemi in RAID
7.4. Il sistema ottimale
7.5. I file sorgenti di Squid
7.5.1. Accesso al CVS

7.5.1.1. Squid current

7.5.1.2. Squid vecchie versioni
7.5.1.3. verificare il CVS appena prelevato
7.5.2. Prelevare Squid
7.5.3. Compilare Squid
7.5.4. eseguire lo script di configurazione
7.5.5. eseguire nuovamente lo script di ./configure
7.5.6. Applicare le patch
7.5.7. Versione giornaliera autogenerata
7.5.8. Opzioni di configurazione
7.6. Il problema dei file descriptor
7.6.1. Determinare il numero corretto di file descriptor
7.6.2. File descriptor con Linux
7.6.3. File descriptor con Solaris
7.6.4. File descriptors con FreeBSD
7.6.4.1. MAXFILES
7.6.4.2. MBUF
7.6.5. File descriptors con Windows
7.6.6. File handles con OS/2
7.7. Il problema dell'insieme delle porte
7.8. Installare Squid dai sorgenti
7.8.1. Perchè installare Squid dai sorgenti
7.8.2. I comandi più importanti
7.8.3. L'albero delle directory di Squid
7.8.4. Pulire gli eseguibili dalle informazioni di debug
7.8.5. Altre informazioni per installare correttamente Squid dai sorgenti
7.9. Disponibilità di pacchetti precompilati
7.9.1. Package per i vari ambienti UNIX®
7.9.2. Package per Win32 ed OS/2
8. Postinstallazione
8.1. Preliminari
8.2. Opzioni offerte dal comando squid(8)
8.3. Il file di configurazione
8.4. Numero delle porte
8.5. Definire una cache gerarchica
8.6. Files di log, memoria e cache
8.6.1. Files di log principali
8.6.2. Files di log accessori
8.6.3. Formati dei files di log
8.6.4. Ruotare i files di log
8.6.5. Disabilitare i files di log
8.6.6. Mime tipe e file di processo
8.6.7. Memoria e cache_dir
8.7. Parametri amministrativi
8.8. Utente e Gruppo (UID e GID)
8.9. Controlli di accesso
8.10. Redirect

8.11. La configurazione di startup (squid.conf)

9. Il Cache Store di Squid
9.1. Preambolo
9.2. Alcune problematiche legate al tipo di filesystem
9.3. Eseguire l'ottimizzazione del file system
9.4. Riservare correttamente lo spazio al Cache Storage
9.5. Le componenti del Cache Store
9.6. Disk Storage
9.6.1. ufs storage
9.6.2. aufs storage
9.6.3. awin32 storage
9.6.4. diskd storage
9.6.4.1. Tuning dei parametri Q1 e Q2
9.6.4.2. Configurare la coda dei messaggi (message queues)
9.6.4.3. Coda dei messaggi con BSD
9.6.4.4. Coda dei messaggi con Linux
9.6.4.5. Coda dei messaggi con Solaris
9.6.4.6. Configurare la memoria condivisa (shared memory)
9.6.4.7. Memoria condivisa con BSD
9.6.4.8. Memoria condivisa con Linux
9.6.4.9. Memoria condivisa con Solaris
9.6.5. null storage
9.6.6. coss storage
9.6.7. Scelta del Disk storage più adatto
9.6.8. Esempi di configurazione
9.6.8.1. Configurare diskd con FreeBSD
9.6.8.2. Configurare ufs (multipiattaforma)
9.6.8.3. Configurare aufs con Linux
9.6.8.4. Configurare awin32 con Windows
9.7. Memory storage
9.7.1. Parametri di configurazione
9.8. Memory e Cache Replacement Policy
9.9. Indicazione dimensionamento del cache store
10. Controlli di accesso
10.1. Preambolo
10.2. Elementi che compongono le ACL
10.3. Capire il funzionamento delle ACL
10.4. Utilizzare le ACL per autenticare degli utenti
10.5. External ACL
10.5.1. wb_group
10.5.2. Utilizzo di wbinfo_group con Samba 3
10.5.3. win32_check_group
10.5.4. squid_ldap_group
10.5.5. squid_unix_group
10.5.6. ip_group_check
10.6. Controllo d'accesso sui siti web

10.6.1. Controlli di accesso e URL filtering

10.6.2. Definire una lista di siti visitabili
10.6.3. Raggiungere direttamente domini o siti predefiniti
10.6.4. Bloccare gli spyware
10.6.5. Bloccare web radio e TV
10.6.6. Bloccare msn-messanger (Yahoo Messanger)
10.6.7. No cache
10.7. ACL basate sul MAC address
11. Autenticazione degli utenti
11.1. Preambolo
11.2. Schemi di autenticazione
11.2.1. Basic authentication
11.2.2. NTLM authentication
11.2.3. Digest authentication
11.3. Parametri di Configurazione
11.4. Basic Authentication
11.4.1. Configurazione in Squid 2.5
11.4.3. helper NCSA
11.4.3.1. Generare il DB degli utenti
11.4.4. helper PAM
11.4.4.1. Red Hat Linux
11.4.4.2. Unix Standard
11.4.5. helper LDAP
11.4.5.1. Esempi di configurazione
11.4.6. helper Winbindd
11.4.7. helper MSNT
11.5. NTLM Authentication
11.5.1. Configurazione
11.5.2. Autenticazione NTLM nativa
11.5.2.1. helper SMB (ntlm_auth)
11.5.2.2. helper fakeauth & no_check
11.5.2.3. helper Windows win32_ntlm_auth
11.5.3. Autenticazione NTLM con Samba 2.2.x
11.5.3.1. Compilazione helpers
11.5.3.2. Configurazione di Samba2
11.5.3.3. helper wb_ntlmauth
11.5.4. Autenticazione NTLM con Samba3
11.5.4.1. helper esterno Samba 3.x ntlm_auth
11.5.4.2. Inserire nel dominio la macchina Samba 3.0
11.5.5. Problemi comuni con NTLM
11.5.5.1. Java runtime
11.5.5.2. ftp
11.5.5.3. Windows Update V5 (Windows XP-SP2)
11.5.5.4. Windows 2003
11.5.5.5. Utenti non autenticati
11.6. Digest Authentication

11.6.1.1. helper digest_pw_auth
12. Avviare Squid
12.1. Preambolo
12.2. Istruzioni multipiattaforma
12.2.1. Controllare il file di configurazione
12.2.2. Prepariamo lo spazio dedicato alla cache
12.2.3. Avviare Squid manualmente
12.2.4. Avviamo Squid come processo
12.3. Avviare Squid automaticamente con il boot del sistema
12.3.1. Avviare Squid utilizzando la tabella di inittab
12.3.2. Avviare Squid utilizzando il file rc.local
12.3.3. Avviare Squid con i sistemi *BSD (init.d e rc.d)
12.3.4. Fermare Squid
12.4. Avviare una versione compilata su Red Hat Linux
12.5. RedHat, Fedora Core e Mandrake Linux
12.6. Debian GNU/Linux
12.7. FreeBSD
12.8. OS/2 o EComStation
12.9. Windows NT/2000/XP/2003
13. Monitorare il funzionamento di Squid
13.1. Controlliamo la nostra cache
13.2. Analizziamo le informazioni
13.2.1. Request rate
13.2.2. Response time
13.2.3. bandwidth
13.2.4. stato delle connessioni
13.2.5. Altri fattori
13.2.6. Gli strumenti di controllo offerti da Squid
13.3. Due parole su SNMP
13.3.1. Configurare l'agent SNMP di Squid
13.3.2. Net-snmp
13.3.3. Controllare i processi utilizzando Net-snmp
13.3.3.1. process size
13.3.3.2. page fault rate
13.3.3.3. HTTP request rate
13.3.3.4. ICP request rate
13.3.3.5. Denied requests
13.3.3.6. HTTP service time
13.3.3.7. DNS service time
13.3.3.8. File descriptor aperti
13.3.3.9. Utilizzo della CPU
13.3.3.10. Spazio su disco
13.3.3.11. Hit ratio
13.4. MRTG e Squid
13.5. Risorse in rete per utilizzare Squid con MRTG
13.6. Il Cache Manager

13.6.1. Configurare cachemgr.cgi con Apache

13.6.2. Configurare cachemgr.cgi con IIS 6
13.6.3. Impostare la password di accesso al Cache Manager
13.6.4. Definire una ACL per consentire l'accesso al Cache Manager
13.6.5. Interrogare il Cache Manager utilizzando la linea di comando
13.6.5.1. Process size
13.6.5.2. Page Fault Rate
13.6.5.3. HTTP Request Rate
13.6.5.4. ICP Request Rate
13.6.5.5. DNS Service Time
13.6.5.6. File Descriptors
13.6.5.7. CPU Usage
14. Privacy
14.1. Preambolo
14.2. Note operative
14.3. Internet Junkbuster
14.3.1. Definizioni ed albero delle directory, file di configurazione
14.3.2. Verificare il funzionamento di Junkbuster
14.4. Privoxy
14.4.1. files di configurazione di Privoxy
14.5. Ad Zapping con Squid
14.5.1. Differenze con Junkbuster e Privoxy
14.5.2. Vantaggi della ridirezione
14.5.3. Prerequisiti di Ad Zapping
14.5.4. installare Ad Zapping
14.6. Fornire agli utenti un servizio di Web Caching anonimo
15. Comunicare con altri proxy server
15.1. Preambolo
15.2. Esempi e relazioni tra webcache
15.3. Alcune informazioni su IRCACHE
15.4. Alcune informazioni sul Servizio di Cache Nazionale GARR
16. Proxy trasparente
16.1. Preambolo
16.2. Concetto di inline cache
16.2.1. L'applicazione che esegue il filtro dei pacchetti
16.2.2. Alcune annotazioni
16.2.3. Filtraggio con GNU Linux
16.2.4. Filtraggio con FreeBSD
16.2.4.1. utilizziamo ipfw
16.2.5. Filtraggio con altri sistemi UNIX®
16.2.5.1. utilizziamo ipf
16.2.6. Esempi di inline cache con Linux
16.2.6.1. Configurare il proxy trasparente con Linux kernel 2.0.x
16.2.6.3. Configurare il proxy trasparente con Linux kernel 2.4.x e 2.6.x
16.2.7. Abilitare inline cache con Squid
16.2.8. L'ipmasquerade con LINUX kernel 2.2.x/2.4.x

16.3. Gli switch di livello quattro

16.4. WCCP (Web Cache Coordination Protocol)
16.4.1. Configurare WCCP con Cisco IOS
16.4.2. Configurare WCCP con Squid
16.4.3. Abilitare l'interfaccia GRE con FreeBSD
16.4.4. Abilitare l'interfaccia GRE con Linux
16.5. Policy di routing con i router Cisco
17. Reverse proxy
17.1. Server HTTPD e content caching
17.2. Reverse Proxy
17.3. SSL Reverse Proxy
17.4. Esempi e situazioni reali
17.4.1. Reverse Proxy di Server web o cluster HA installati su una macchina differente
17.4.2. Reverse Proxy di server web installato sulla stessa macchina che esegue Squid
17.4.3. Reverse Proxy per domini multipli
17.4.4. SSL Reverse Proxy di un server web o di un cluster HA installato su una macchina differente
18. Proxy load balancer
18.1. Preambolo
18.2. WPAD protocol
18.3. DHCP e configurazione automatica del browser
18.4. Fail over e load balancer
19. Limitazione della banda per classi
19.1. Preambolo
19.2. Squid ed i Delay pools
19.2.1. Limitare la banda per singole connessioni a 128 kbps
19.2.2. Limitare la banda totale a 512 kbps
19.2.3. Limitare la banda con una linea a 2 Mbps
19.3. Limitare il download di alcuni files
20. Security ed utilizzi estremi
20.1. Preambolo
20.2. Squid come ultima risorsa
20.3. Squid e la sicurezza
20.3.1. Sicurezza in quanto Servizio
20.4. Squid ed Antivirus
20.4.1. InterScan Web Security Suite
20.5. Sicurezza come interazione con il sistema operativo ospitante
20.5.1. Sistemi UNIX®, cloni e BSD
20.5.2. La modalità chroot() nei sistemi UNIX® cloni o BSD
20.6. Squid e Daemontools
20.8. Sistemi OS/2
21. La analisi dei log di Squid
21.1. Preambolo
21.2. I log nativi
21.3. Log in altri formati
21.4. Troubleshooting con il file cache.log
21.4.1. Utilizzare tail(8) ed xterm(8)

21.4.2. Livelli di debug

21.5. I codici di stato di Squid
21.6. Codici di Stato HTTP
21.7. Metodi di richiesta supportati
21.8. Codici gerarchici per il peering con altre webcache
21.9. Strumenti di analisi dei Log
21.9.1. Calamaris
21.9.2. Webalizer
21.9.3. Sarg
21.9.4. Squeezer2
21.9.5. Yaala
21.9.6. SquidAlyser
21.9.7. Logrep
21.9.8. LIRE
21.9.9. Squidefender
22. Una configurazione operativa
23. Colophon
24. GNU Free Documentation License
25. Elenco dei mirror autorizzati
Capitolo 1. Informazioni
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
Capitolo 2. La storia di Squid e dello Squid-Book

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
● [email protected] - discussioni generali sull'utilizzo di squid
● [email protected] - lista per il rilascio delle nuove release
● [email protected] - lista per l'annuncio dei nuovi bugs e problemi
● [email protected] - lista per il feedback e nuove idee
● [email protected] - lista per il feedback, gli aggiornamenti e contributi addizionali per le Squid FAQ
mailing lists non strettamente legate al progetto Squid
● [email protected] - lista sulle implementazioni del protocollo SNMP in ambito webcaching
● [email protected] - 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).
Capitolo 3. Cosa è Squid

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.1.1. L'architettura Web

Prima di iniziare a parlare di Squid dovremmo comprendere alcune nozioni ed alcuni termini che ci consentiranno di intendere
il concetto di proxy ed il concetto di webcaching
3.1.2. Clients e Servers
Il web e molti altri sistemi distributi si basano sull'architettura client/server, i clients sono anche conosciuti come user agent e
iniziano la transazione inviando una richiesta al server. Un web server gestisce e fornisce l'accesso ad un insieme di risorse; il
server, dopo aver processato la richiesta effettuata dal client, invia la risposta. I più comuni dei web client prendono il nome di
browser web, lo scopo di un browser web è quello di visualizzare (eseguire il rendering) il contenuto delle pagine che sono
state servite dal web server. Possono essere diversi i server maggiormente utilizzati, tra questi Apache HTTP Server è uno dei
server più popolari (http://httpd.apache.org/).
3.1.3. Proxies
Il proxy è un mediatore di una transazione web, in effetti si tratta di una applicazione che viene posizionata tra il web client ed
il server di origine, i proxy autorizzano e registrano le richieste provenienti dalla rete interna (inside) dirette verso la rete
esterna (outside).
3.1.4. Oggetti web
Il termine object viene utilizzato per definire il traffico scambiato tra il client ed il server, object è un termine generico che
descrive nella maniera migliore quelli che possono essere i differenti tipi di contenuti che vengono rilasciati dal server. Gli
oggetti web (object) hanno un numero di caratteristiche molto importanti inclusa la grandezza (size), il tipo di documento
(type), la data e l'ora di creazione nonchè la data e l'ora dell'ultima modifica.
3.1.5. URL
Uniform Resource Locator (URLs) è la forma più comune con la quale viene identificata una Universal Resource Identifier
(URI). Gli URI o identificativi di risorse, sono una parte fondamentale dell'architettura Web in quanto si tratta dei nomi e gli
indirizzi degli oggetti web. La sintassi delle URL viene descritta nella RFC 1738 (http://www.ietf.org/rfc/rfc1738.txt?
number=1738)
3.1.6. Un sistema di webcache
Un sistema di webcache viene generalmente implementato con un apparato di rete dedicato che è stato progettato per
memorizzare e trattenere nella memoria locale, la cache, tutti gli oggetti web che sono stati richiesti dagli utenti con maggiore
frequenza. Tale sistema fa in modo che gli oggetti, memorizzati nella cache locale, non debbano più essere richiesti
direttamente dalla rete internet e quindi riduce la necessità di utilizzo della banda dedicata. Grazie all'utilizzo di queste device
di webcache, gli utenti delle reti aziendali o dei vari ISP (Internet Service Provider) rimarranno soddisfatti per la velocità con la

quale accederanno alle risorse web e le contestuali necessità di banda dedicata verranno decisamente ridotte.
Come sappiamo, internet è una rete immensa ed il world wide web è principalmente composto da ipertesti, immagini ed altri
files che vengono offerti dai rispettivi server di origine; tali apparati sono dislocati nei posti più disparati del pianeta e la
richiesta degli oggetti www necessita di banda ed alta velocità. Gli amministratori delle reti studiano e progettano i sistemi di
accesso alle risorse web e cercano di garantire un livello di servizio molto elevato, uno degli obiettivi principali che viene
perseguito è quello di ridurre i costi mantenendo le performance molto elevate senza dover incrementare le risorse di banda
internet dedicate.
Una device di webcaching è l'unico sistema che consente di mantenere alto il livello del servizio e di ridurre i costi:
l'inserimento di queste device all'interno di un network determina una possibile riduzione dell'utilizzo della banda disponibile,
nel caso di pagine statiche i valori percentuali relativi alla riduzione varieranno dal 30% al 40%, molto dipende anche dal
numero e dal tipo di utenti della rete.
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.2.1. Tempo di latenza (latency)
Il tempo di latenza è quel tempo che intercorre nella trasmissione di un dato tra un punto e l'altro della rete. La trasmissione dei
dati attraverso un circuito elettrico o un circuito ottico viene limitata dalla velocità della luce. Una connessione tra Roma e
Milano introduce teoricamente un ritardo di circa 10ms. Il tempo di latenza può essere ulteriormente incrementato quando
sussistono delle congestioni sulla rete.
3.2.2. Capacità di banda (bandwidth)
Se la connessione internet è congestionata la nostra capacità di banda si riduce, tutte le applicazioni di rete concorrono a
limitare la banda disponibile
3.2.3. Utilizzo delle risorse del server (server load)
Il tempo di risposta di un server cresce in misura equivalente con il numero di richieste che vengono effettuate dai client, un
server molto occupato riduce notevolemente i tempi di risposta. Molti Internet Service Provider (ISP) installano degli apparati
di webcache per ridurre le esigenze di banda nella distribuzione dei contenuti.
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.5.1. contenuti pagina web
Negli ultimi anni si é assistito ad un proliferare di siti web bastati su pagine che vengono create dinamicamente al momento
della navigazione (.asp, .mspx, .aspx, .jsp, .php ecc...). É evidente che con l'utilizzo di tali applicazioni la funzionalità di
caching ne risente negativamente e quindi, al crescere dell'utilizzo di tali tecnologie, ci si deve attendere un'aumento
dell'occupazione della banda dedicata al traffico Internet.
3.5.2. numero degli utenti
In linea di massima, maggiore sarà il numero degli utenti che accedono all'apparato di webcache, superiore sarà il risparmio di
banda internet. Un corretto dimensionamento di Squid dipende anche da altri fattori come la disponibilità di una quantità
ottimale di memoria RAM, la possibilità di disporre di un cache storage di grandi dimensioni, l'utilizzo di un filesystem

appropriato e un corretto sistema operativo di classe UNIX® possono fare la differenza.
3.5.3. tipologia degli utenti
Se vi sono gruppi di utenti dagli interessi diversi si visiteranno un numero sempre più alto di siti web con la contestuale
memorizzazione della pagine nella cache dell'apparato. In questo caso, il risparmio di banda sara minore, perchè la probabilità
che le stesse pagine web visitate vengano richieste nuovamente si riducono. Se vi sono molti grandi utenti, meglio conosciuti
come "power users", che visitano sempre gli stessi siti internet e che quindi hanno abitudini di browsing simili, è decisamente
possibile aumentare il risparmio di banda. Se una squadra di tecnici addetta alla manutenzione dei sistemi decide di aggiornare
il browser web utilizzato dagli utenti, provvederà ad effettuare il download del programma. Il file rimarrà memorizzato nella
memoria cache della device eliminando totalmente le successive richieste di banda.
3.5.4. tipo di webcache utilizzata
Il tipo di dimensionamento dello spazio dedicato al cache storage può avere un impatto consistente sull'ammontare della banda
che è possibile risparmiare. Maggiore sarà la dimensione della cache e superiore sarà il numero degli oggetti che verranno
salvati nella memoria tampone. Sarà determinante anche la velocità di accesso dell'apparato di memorizzazione: un sistema di
disk storage efficente ed un disco rigido di dimensioni contenute dalle prestazioni molto elevate consentiranno di ottenere un
incremento delle performance.
3.5.5. tipologia della rete
All'interno di una rete corporate composta unicamente di "power users" la webcache può essere un sistema eccezionale per la
riduzione della banda. In altri casi, come ad esempio un Internet Service Provider (ISP) o un Application Service Provider
(ASP) il taglio di banda sarà decisamente inferiore.
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.12.1. Internet Cache Protocol (ICP)
L'Internet Cache Protocol (ICP) è il primo dei protocolli di intercache ed è stato sviluppato come parte fondamentale del
progetto Harvest. Il suo scopo è quello di trovare gli oggetti richiesti all'interno della rete delle cache adiacenti, la cache
adiacente può rispondere con un HIT ovvero che l'oggetto è stato trovato, oppure con un MISS, quindi che l'oggetto non è
presente nella cache adiacente. Il protocollo ICP fornisce un metodo efficiente e veloce di comunicazione intercache e si tratta
di un meccanismo che instaura una complessa gerarchia di cache, la cache che esegue l'interrogazione colleziona una serie di
risposte ICP e decide cosa fare, possiamo anche dire che l'Internet Cache Protocol (ICP) può essere utilizzato all'interno di
gerarchie di cache (peer) per localizzare uno specifico oggetto nelle cache di livello superiore.
● OBJECT (oggetto)
questo temine definisce un valore generico con il quale si identifica qualsiasi documento o altro tipo di dato disponibile
via web, le Uniform Resource Locator (URL) solitamente identificano gli oggetti
● HIT
il temine cache HIT definisce una copia valida di un oggetto
● MISS
il termine cache miss identifica un oggetto che non esiste più in una cache o che ha perso validità
Se una cache non dovesse contenere l'oggetto richiesto invia una richiesta ICP alle cache partner, le quali inviano una risposta
contenente un un HIT oppure un MISS; il nostro proxy analizza le risposte ricevute per scegliere la cache adiacente migliore
per risolvere il proprio MISS. I termini neighbours e peer sono sinonimi e si riferiscono a dei sistemi di cache adiacenti ed in
relazione tra loro.
ICP supporta inoltre la trasmissione di tipo multiplexed di stream di oggetti multipli su una singola connessione TCP,
attualmente ICP é implementato su trasporto di tipo UDP e le versioni correnti di Squid supportano anche ICP via multicast. Il
tempo di ritardo di una transazione ICP può dipendere dallo stato della rete o dallo stato delle cache adiacenti. Qualora non si
dovesse ricevere alcun messaggio ICP possiamo dedurre che la cache remota è in errore oppure che la rete è congestionata, per
questo motivo l'Internet Cache Protocol (ICP) utilizza User Datagram Protocol (UDP) come protocollo di trasporto
● RFC 2186 (http://www.ietf.org/rfc/rfc2186.txt) specifiche del protocollo ICPv2
● RFC 2187 (http://www.ietf.org/rfc/rfc2187.txt) specifiche applicative del protocollo ICPv2

● ICP (http://www.ircache.net/~wessels/Papers/icp-squid.ps.gz) con Squid web cache
le implementazioni applicative o i sistemi di webcache che utilizzano Internet Cache Protocol (ICP) oltre a Squid attualmente
sono
● Network Appliance (http://www.netapp.com/products/netcache/)
● Cisco Cache Engine (http://www.cisco.com/go/cache/)
● Volera (http://www.volera.com/)
● BlueCoat (http://www.bluecoat.com/)
● iMimic DataReactor (http://www.imimic.com/)
3.12.2. Cache Array Routing Protocol (CARP)
Il Cache Array Routing Protocol (CARP) è un algoritmo e non è un protocollo, è stato sviluppato da Microsoft come parte
fondamentale dei propri prodotti Proxy Server ed è stato disegnato per risolvere un problema in particolare: trovare un sistema
scalabile ed efficente per migliorare gli HIT ratios e ridurre il tempo di latenza. L'algoritmo per una data richiesta CARP
calcola un punteggio per ogni cache adiacente, la richiesta verrà girata al proxy server che ha ottenuto il punteggio più alto, se
questo dovesse fallire la richiesta verrà girata al secondo sistema di webcache con punteggio più alto. Il punteggio viene
calcolato sull'HASH della URL. Le regole di questo algoritmo forniscono dunque un metodo veloce ed efficiente per creare
un'insieme di webcache (array), gestirne la relativa comunicazione e stabilire un meccanismo complesso di gerarchie di tipo
fault tolerant e load balanced. CARP è documentato da un Internet Draft che è oramai scaduto
● CARP 1.0 Internet-Draft (http://icp.ircache.net/carp.txt)
● Carp white paper (http://www.microsoft.com/TechNet/Proxy/technote/prxcarp.asp)
Cache Array Routing Protocol (CARP) funziona unicamente quando le relazioni tra webcache sono del tipo parent in quanto
non è in grado di predire i cache HIT. Squid utilizza il protocollo CARP solamente come client per selezionare uno dei membri
dell'array di livello gerarchico superiore, non é in grado di partecipare attivamente a tale array, le implementazioni applicative o
i sistemi di webcache che utilizzano CARP attualmente sono
● Microsoft Proxy & ISA Server (http://www.microsoft.com/isaserver/)
3.12.3. Hyper Text Caching Protocol (HTCP)
Hyper Text Caching Protocol (HTCP) è un protocollo che è stato disegnato per migliorare il protocollo ICP. Anche HTCP è un
protocollo del tipo domanda/risposta che utilizza User Datagram Protocol (UDP) per il trasporto delle informazioni sulla rete.
Un falso HIT può essere un problema per ICP sopratutto in una relazione di cache del tipo sibling ed HTCP risolve questo tipo
di problema in quanto invia una intestazione HTTP completa sia per quanto concerne la richiesta che la risposta. HTCP include
moltissime funzionalità sperimentali di ICP, tra queste la possibilità che viene offerta ad una cache di richiedere al sistema
adiacente di cancellare o aggiornare un dato oggetto. Una cache è in grado di informare le corrispondenti se un oggetto è stato

aggiunto, aggiornato, rimpiazzato o cancellato. HTCP supporta anche l'autenticazione forte utilizzando le shared key (SKA[2])
con algoritmo MD5[3]. Trattandosi di un protocollo piuttosto complesso la struttura del messaggio HTCP richiede maggiori
risorse di sistema. Possiamo concludere dicendo che HTCP è un protocollo che consente di eseguire la ricerca delle cache e
degli oggetti in esse contenute, inoltre è in grado di eseguire il controllo ed il monitoraggio della attività delle webcache. HTCP
è regolamentato dalla RFC 2756 (http://www.ietf.org/rfc/rfc2756.txt).
3.12.4. Cache Digest
Cache Digest è un nuovo protocollo che tratta una tecnica di ottimizzazione del caching cooperativo. Lo scopo primario di
questo nuovo protocollo è quello di effettuare la trasmissione delle informazioni salvando gli oggetti in sistemi di directory che
a loro volta vengono scambiate tra cache adiacenti. Cache Digest autorizza i proxies componenti una gerarchia collegata a
generare delle informazioni relativamente al contenuto della propria cache, una web cache componente lo stesso peer è così in
grado di identificare al meglio quale delle webcache gemelle può fornirgli più velocemente i documenti richiesti.
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.
Capitolo 4. I sistemi operativi che supportano Squid

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-
[email protected]
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.3.1. GNU Linux
Le distribuzioni Linux che vengono trattate all'interno di questo documento, in relazione alle configurazioni implementate con
Squid, sono Debian GNU/Linux, Slackware, RedHat, Mandrake e Fedora Core.
4.3.2. FreeBSD
Thomas-Martin Seck <tmseck(at)netcologne.de> è l'attuale maintainer del ports per FreeBSD (http://www.freshports.org/www/
squid/) e molte delle configurazioni trattate in questo documento vengono testate su questi sistemi. Nelle ultime versioni del
ports è stato anche inserito un semplice ed utile menù interattivo che consente di selezionare, in maniera visuale, alcune delle
opzioni di configurazione del software come il supporto SNMP (Simple Network Managemet Protocol) o le ACL ARP based
ACL ARP based.


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.
Capitolo 5. Differenze tra Squid 2.4 e Squid 2.5

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.
Capitolo 6. Casi di studio

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]
❍ 300 utenti
❍diskd disk store (filesystem UFS), autenticazione ntlm in AD

● Server Compaq Proliant - PII 450 MHz - 128 MB RAM - disco SCSI
❍ 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
❍ 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
❍ 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
❍ 10 utenti
❍ aufs disk store (file system ext3), autenticazione BASIC
Capitolo 7. Configurare ed installare Squid

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.3.1. Utilizzo della memoria RAM
Squid utilizza la memoria RAM per tenere una traccia della tabella degli oggetti[9], un'accesso rapido a questa tabella è
fondamentale, il ricorso alla memoria di swap penalizza le prestazioni di Squid sino a renderlo inservibile.

Qualsiasi oggetto memorizzato su disco utilizza circa 75 bytes di memoria RAM, la grandezza media di un oggetto è di circa
13 Kb. Utilizzando questi valori è possibile definire uno standard di calcolo in merito al fabbisogno di memoria RAM da parte
di Squid.
1GB cache_dir 1.000.000/13 = 76.923,07692 oggetti su disco

75*76.923,07692 = 5.769.230,769 pari a circa 6 MB di RAM
per 1 GB di disk storage Squid richiederà circa 6 MB di RAM per funzionare correttamente
8GB cache_dir 8.000.000/13 = 615.384,6154 oggetti su disco

75*615.384,6154 = 46.153.846,16 pari a circa 48 MB di RAM
per 8 GB di disk storage Squid richiederà circa 48 MB di RAM per funzionare correttamente
7.3.2. Tipo di CPU
Squid non utilizza in maniera intensiva la CPU, solo al momento dell'avviamento la CPU lavora a pieno regime perchè Squid
deve verificare la validità gli oggetti contenuti nella cache. Ne consegue che una CPU di vecchia generazione può penalizzare
l'accesso agli oggetti presenti nella cache unicamente nei minuti successivi all'avviamento di Squid. Un sistema Pentium 300
Mhz può già essere sufficente per eseguire Squid in piccole realtà aziendali (massimo 50 utenti).
7.3.3. Simmetric Multi Processor (SMP)
L'utilizzo di un sistema multiprocessore non aumenta in modo significativo le performance di Squid in quanto l'applicazione è
basata su un processo singolo che non ricorre alla tecnologia SMP[10]. Lievi benefici possono essere ottenuti nel caso si
disponga di sistemi di webcache con elevato carico di I/O che utilizzando configurazioni di Disk Storage asincrono (Cfr. la
sezione relativa al Disk Storage).
Nel caso volessimo ottenere dei grandi benefici dall'utilizzo di SMP dovremo eseguire istanze multiple di Squid e trovare il
sistema di distribuire gli utenti sulle diverse istanze.
7.3.4. Sottosistema dischi e tecnologie
Per quanto concerne il sottositema dischi lo standard su bus SCSI è la soluzione consigliata, a tale riguardo si rammenta che
oggi è possibile utilizzare dei sistemi su bus EIDE[11], ATA[12] o SATA[13] che prevedono il collegamento con delle unità a
disco molto veloci, queste unità devono essere in grado di supportare il trasfermento dei dati tramite DMA[14] e devono
disporre di una capacità di rotazione pari almeno 7.200 rpm. Per bilanciare al meglio le performance di Squid è necessario
valutare anche altri fattori a riguardo della scelta delle unità a disco
● il numero delle unità a disco
● il tipo di file system
● lo spazio libero su disco

● il numero di files presenti sul file system
7.3.5. Sistemi in RAID
A livello progettuale, la soluzione migliore che possiamo proporre al lettore è quella di utilizzare i dischi in RAID[15] Livello
1 per il sistema Operativo e utilizzare uno o più dischi per lo spazio dedicato al disk storage (cache)
● RAID Livello 1 è una ottima soluzione, lo stesso vale per unità a disco separate
● RAID Livello 0 (striping) non determina nessun vantaggio a livello di performance
● RAID Livello 5 è la soluzione meno indicata
la soluzione RAID Livello 5 degrada le prestazioni in quanto lo spazio dedicato al disk storage viene scritto diverse volte in
modalità randomica. Questa modalità di scrittura dei dati su disco riduce la velocità e quindi le performance se paragonata con
un sistema a disco singolo. Dobbiamo però anche dire che i sistemi RAID garantiscono un livello di stabilità e di affidabilità
superiore in quanto sono stati progettati per ridondare delle componenti che sono molto sensibili ai guasti come le unità a disco.
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
7.5.1. Accesso al CVS
Il Cuncurrent Version System (CVS) è un sistema del tipo client/server che consente agli sviluppatori, seppur divisi da distanze
geografiche rilevanti, di lavorare in un'unico team di sviluppo. Non è necessario che il progetto sia necessariamento legato allo
sviluppo del software, anche un saggio come questo può essere elaborato nell'ambito di un progetto comune che prevede
l'utilizzo di un repository CVS centrale. La storia delle versioni che vengono inserite dagli sviluppatori verrà memorizzata su
un unico server centrale, le macchine client mantengono una copia di tutti i files sui quali, di fatto, tutti gli sviluppatori
lavorano. La rete internet divide il client ed il server e consente di effettuare operazioni in CVS come i controlli sul codice
sorgente e gli aggiornamenti del codice stesso

7.5.1.1. Squid current
per eseguire un checkout per l'intero l'albero dei sorgenti di Squid che sono correntemente utilizzati da un server CVS
% touch .cvspass
% cvs -d :pserver:[email protected]:/squid login
CVS password:
a questo punto digitare anoncvs, subito dopo
% cvs -z3 -d :pserver:[email protected]:/squid co -P squid
per aggiornare i sorgenti digitare il comando cvs -z3 all'interno della directory squid
% cd squid
% cvs -z3 update -dP
questo tipo di ambiente è stato testato utilizzando bash come shell di sistema
7.5.1.2. Squid vecchie versioni
per accedere alle vecchie versioni di Squid dovremmo utilizzare la stessa procedura di accesso al server CVS cvs.squid-cache.
org ma dovremmo specificare le versioni specifiche per le quali si intendono sincronizzare i sorgenti
% cvs -d :pserver:[email protected]:/squid login

CVS password:
● per Squid-2.5 dovremmo utilizzare il comando
% cvs -z3 -d :pserver:[email protected]:/squid co -r SQUID_2_5 squid
per aggiornare i sorgenti digitare il comando cvs -dP all'interno della directory squid

% cd squid
● per Squid-2.4 dovremmo utilizzare il comando
% cvs -z3 -d :pserver:[email protected]:/squid co -r SQUID_2_4 squid
per aggiornare i sorgenti digitare il comando cvs -dP all'interno della directory squid
% cd squid
7.5.1.3. verificare il CVS appena prelevato
utilizzando il comando more(8) possiamo eseguire una pipe di interrogazione sul file di ./configure per verificare la versione di
Squid appena prelevata da cvs.squid-cache.org
% cd squid
% more configure | grep VERSION
VERSION=2.5.STABLE7-RC3-CVS
non è possibile manipolare le versioni correnti e quelle passate dei files, i clients possono effettuare le stesse operazioni che
sono anche disponibili localmente, maggiori informazioni per prelevare un sistema CVS possono essere reperite alla URLs
https://www.cvshome.org/
7.5.2. Prelevare Squid
Oltre che sul sito web il file contenente il codice sorgente di Squid è anche disponibile sul sito ftp del progetto Squid (ftp://ftp.
squid-cache.org/pub/squid-2/STABLE/), per prelevare il file utilizziamo il comando fetch(8), l'implementazione originale di
questo comando è di Jean-Marc Zucconi e viene incluso in tutti i sistemi FreeBSD, in alternativa potremmo utilizzare l'utility
wget(8), per maggiori informazioni a riguardo consultare la URLs http://www.gnu.org/software/wget/wget.html
% 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)

presso la home page del progetto Squid sono anche disponibili tutte le patch che consentono di aggiungere funzionalità o di
aggiornare la versione di Squid (http://www.squid-cache.org/Versions/v2/).
7.5.3. Compilare Squid
Per compilare Squid è necessario disporre di un compilatore ANSI C[18], tutti i moderni sistemi UNIX® includono un
compilatore con queste caratteristiche preinstallato. I vecchi Sistemi SunOS non dispongono di compilatori compatibili con lo
standard ANSI C ed il compilatore per i Sistemi Sun Solaris deve essere acquistato a parte.
Il compilatore GNU C è disponibile presso il sito ftp del progetto GNU (ftp://ftp.gnu.org/), inoltre per compilare ed installare
correttamente Squid sono anche necessarie le librerie gcc (ftp://ftp.gnu.org/gnu/gcc/), il package binutils (ftp://ftp.gnu.org/gnu/
binutils/) ed i linguaggi Awk e Perl (http://www.perl.org/).A seconda delle opzioni di compilazione e dei moduli di Squid
selezionati, possono inoltre essere necessarie le librerie OpenLDAP ed OpenSSL, nonché i Sorgenti di Samba 2.2.x o 3.0.x.
7.5.4. eseguire lo script di configurazione
Dopo aver prelevato la distribuzione è necessario scompattarla, utilizzeremo in comando bunzip2(8) ed il comando tar(8), sono
necessari almeno 20 MB liberi sul disco. In ogni caso, per compilare ed installare tutte le versioni di Squid, è necessario
eseguire lo script di ./configure prima di lanciare il comando make
% 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
tutte le caratteristiche di Squid vengono attivate utilizzando lo script di configurazione (./configure), alcune di queste
caratteristiche, per essere attivate, devono essere dichiarate specificatamente al momento della compilazione dei codici
sorgenti, per ottenere una configurazione ottimale può anche rendersi necessario ricompilare ulteriormente e vedremo in
seguito come procedere.
Una delle ragioni per le quali una specifica caratteristica di Squid possa non essere disponibile è determinata dal livello di
compatibilità del sistema operativo con i codici sorgenti. Anche se Squid viene rilasciato con un codice sorgente valido per
un'utilizzo generico e multipiattaforma, è comunque possibile che determinate funzioni, come async-IO o le ACL ARP-based,
non siano disponibili per quel tipo di sistema operativo. Lo script di configurazione (./configure) può contenere alcune
caratteristiche che informano gli utenti sullo stato delle opzioni di configurazione disponibili.
Alcuni Amministratori di Sistema disabilitano volutamente determinate caratteristiche di Squid per rendere sempre più
performante e sicuro il funzionamento delle loro piattaforme, come abbiamo accennato prima, è possibile includere in Squid le
funzionalità che oggi non sono richieste senza problemi o effetti collaterali ricompilando i sorgenti in un secondo momento.

Il programma di configurazione (./configure) ha inoltre una seconda funzione, infatti inserisce una sorta di intestazione che
informa il compilatore C relativamente alle chiamate o alle funzioni di Sistema. Questo fatto, molto spesso, rende la
compilazione del codice sorgente piuttosto difficile. Il compilatore GNU configura i controlli dello script per programmare le
librerie e le chiamate di Sistema realmente disponibili sul sistema operativo che state utilizzando. Questa funzionalità del
compilatore GNU facilita la messa a punto del codice.
Il file di configurazione (./configure) è generico, in particolare si tratta di uno script realizzato per la Bourne Shell[19] (/bin/sh),
se avete sostituito il comando /bin/sh con una Shell non compatibile o con una Shell che effettua delle chiamate non conformi
allo standard Posix, non potrete compilare ed installare Squid sul Vostro Sistema Operativo.
Tutte le opzioni di configurazione vengono regolate dunque dall'opzione ./configure. Nell'esempio che tratteremo in seguito,
compileremo Squid con diverse caratteristiche tra le quali, il modello di autenticazione, lo schema di autenticazione con i
relativi helpers, diskd come modello di Disk Storage utilizzato ed il supporto Simple Network Management Protocol (SNMP)
% ./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
molte di queste opzioni sono tra quelle che vengono più comunemente utilizzate.
7.5.5. eseguire nuovamente lo script di ./configure
Come abbiamo accennato in precedenza, molto spesso accade di avere la necessità di eseguire nuovamente lo script di ./
configure, questo può accadere nel caso in cui si decida di modificare alcune caratteristiche. Per eseguire nuovamente lo script
di configurazione con le stesse opzioni utilizzate in precedenza possiamo utilizzare lo script config.status

% ./config.status --recheck
il file ./config.status viene generato automaticamente al momento della prima eseguzione dello script di ./configure. Per
aggiungere o rimuovere le opzioni di ./configure è necessario eseguire nuovamente il comando, prima di mandarlo in
esecuzione eseguiremo un make clean
% make clean
% ./configure --enable-snmp
7.5.6. Applicare le patch
Per eseguire questa operazione è richiesta la presenza del programma patch, questo programma è disponibile sul sito ftp del
progetto GNU (ftp://ftp.gnu.org/gnu/patch/) e generalmente viene incluso in qualsiasi sistema operativo di classe UNIX®.
E' sempre una buona norma duplicare l'intera struttura della directory che contiene i codici sorgenti di Squid prima di applicare
qualsiasi patch
% patch < /tmp/nome_file.patch
dopo aver applicato la patch potremo finalmente eseguire il rebuild di Squid preparando i codici sorgenti alla piattaforma
specifica
% make distclean
% ./configure
% make
% make install
se il programma patch(8) si dovesse rifiutare di funzionare è possibile che si stia utilizzando una versione troppo vecchia,
possiamo prelevare una versione più recente dal repository ftp del progetto GNU (ftp://ftp.gnu.org/gnu/patch/).
7.5.7. Versione giornaliera autogenerata
Il daily snapshot dei codici sorgenti di Squid è il rilascio del codice sorgente più aggiornato per il branch corrente (attualmente
squid-2.5). Dalla data di rilascio dell'ultima versione STABLE vengono rilasciate diverse patch che correggono gli errori
rilevati dagli utenti e dagli sviluppatori. Questi aggiornamenti oltre ad altre correzioni minori, vengono incluse in una versione
STABLE corrente di Squid, questa release prende il nome di "current Squid-2.5 snapshots" e viene rilasciata giornalmente. La

versione current può essere considerata alla stregua della successiva release di Squid-STABLE. La procedura per installare e
compilare la versione current è la medesima e la URLs dalla quale prelevare il codice sorgente è http://www.squid-cache.org/
Versions/v2/2.5/, la sezione da consultare per procedere con il download è la "Daily auto-generated release"
% 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)
ora scompattiamo l'archivio contenente i sorgenti e configuriamo il codice per la nostra piattaforma
% 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
naturalmente, come detto in precedenza, dovremo scegliere delle opzioni di configurazione (./configure) mirate che ci
consentiranno di definire la nostra migliore configurazione, ora compiliamo il codice ed installiamo i file binari
% make
% make install
% make clean
7.5.8. Opzioni di configurazione
Come abbiamo visto, lo script di ./configure può essere avviato con numerose opzioni, una di quelle più utilizzate è

% ./configure --prefix
con questa opzione si definisce il percorso (path) nel quale verranno installati i file eseguibili di Squid, la directory che viene
utilizzata come base di installazione nel file di configurazione incluso con la distribuzione è /usr/local/squid/.
Se si vuole installare Squid in un percorso diverso è quindi possibile modificare il valore standard eseguendo lo script di ./
configure utilizzando le seguenti opzioni
% ./configure -exec-prefix=/usr/local/sbin
questa opzione consente di modificare il percorso di installazione dei file binari dipendenti dalla architettura
% ./configure --prefix=/usr/local/squid
questa opzione se utilizzata singolarmente imposterà la directory di default per gli eseguibili, i logs ed i files di configurazione,
si tratta del valore standard
% ./configure --localstatedir=/var/log
questa opzione consente di modificare il percorso della directory di var
% ./configure --sysconfdir=/usr/local/etc/squid
questa opzione consente di modificare il percorso della directory etc
% ./configure --help
questa opzione consente di visualizzare tutte le opzioni di ./configure attualmente disponibili, per abilitare o disabilitare alcune
delle features di Squid, dovremo specificare diverse opzioni di configurazione. Mostriamo ora tutte le opzioni di ./configure, la
lista è aggiornata a squid-2.5.STABLE10

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.

7.6.1. Determinare il numero corretto di file descriptor
Quando Squid è fermo in attesa di richieste utilizza in media 24 descrittori di files (file di log e comunicazioni tra processi),
ogni singola richiesta HTTP determina l'apertura di una media di 8 file descriptor (singola richiesta e connessioni persistenti).
file descriptor medi utenti concorrenti connessioni persistenti totale file descriptor
24 20 20*8 160+24=184
24 50 50*8 400+24=424
24 100 100*8 800+24=824
24 200 200*8 1600+24=1624
24 400 400*8 3200+24=2324
24 500 500*8 4000+24=4024
Nell'ipotesi più pessimistica con la quale si prevede l'apertura di 10 o più file descriptors per connessione persistente, con 400
client concorrenti saranno necessari almeno 4096 file descriptor. Una buona configurazione può prevedere 1024 file descriptor,
tale impostazione può andare bene se si prevede un traffico medio. La tabella riportata in calce può essere utilizzata per
dimensionare al meglio il nostro sistema di webcache, se desideriamo verificare il numero di file descriptor configurati per una
versione pacchettizzata e preinstallata di Squid, possiamo determinare questo valore ricavandolo dal file cache.log
2004/04/03 13:08:29| With 1024 file descriptors available
Squid può presentare dei problemi con i file descriptor nel momento in cui viene eseguito, anche in questo caso l'avviso potrà
essere rilevato dal file cache.log
2004/04/12 21:33:22| WARNING! Your cache is running out of file descriptors
nel caso si dovesse presentare questo avviso di warning è necessario accrescere il limite dei file descriptor, la modalità con cui
è possibile variare il numero di file descriptor, come abbiamo visto precedentemente, é specifica per ogni Sistema Operativo.
Il Cache Manager è un ottimo strumento per verificare l'allocazione dei processi attivi per file descriptor
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
7.6.2. File descriptor con Linux
Il valore dei files descriptors impostato come default per ogni distribuzione Linux è generalmente pari a 1024, gestire questo
tipo di impostazione non è affatto semplice. Infatti prima di configurare Squid è necessario verificare il numero di file
descriptors attualmente configurati utilizzando il comando ulimit(8), si tratta di un comando che fa parte della shell. Il primo
passo da compiere è quello di verificare il numero di file descriptor disponibili sulla nostra piattaforma
% ulimit -n
1024
a questo punto dovremmo editare uno dei file di system include del kernel, in particolare si tratta del file /usr/include/bits/tipes.
h oppure del file /usr/include/bits/typesizes.h modificando il valore __FD_SETSIZE
% vi /usr/include/bits/typesizes.h
#define __FD_SETSIZE 4096
il valore __FD_SETSIZE viene controllato durante l'esecuzione dello script di ./configure. Squid è particolarmente vorace di
file descriptors che sono una risorsa finita ma regolabile del sistema operativo, oltre che molto preziosa, visto che sono i canali
di comunicazione che vengono utilizzati dai vari processi per parlare con il mondo esterno e fra di loro. Per verificare quanti
file descriptors il sistema metta a disposizione con la configurazione standard si può digitare il seguente comando
% cat /proc/sys/fs/file-max
104857
è opportuno che questo numero sia piuttosto alto, in linea di massima può andare bene se maggiore di 65000. Qualora il
numero dovesse essere più basso, si consiglia di editare (come root) il file /etc/sysctl.conf aggiungendo la riga
fs.file-max = 102400
e poi lanciare (sempre come root) il comando

% sysctl -p
che legge le impostazioni dal file /etc/sysctl.conf (viene di norma eseguito automaticamente al reboot, quindi le impostazioni
non andranno perse). Se per caso la nostra distribuzione linux non utilizzasse il sistema sysctl, si può in alternativa aggiungere
la riga
echo 102400 > /proc/sys/fs/file-max
al file rc.local, e lanciarla anche dalla riga di comando (come root) per attivarla anche immediatamente. queste impostazioni
vanno aggiunte su tutti i sistemi su cui Squid verrà installato, non solo su quelli dove viene compilato. A questo punto
incrementiamo il limite massimo dei processi di file descriptors. Dovremmo utilizzare la stessa shell (bash, sh, tsh...) con la
quale successivamente configureremo e compileremo Squid
% ulimit -Hn 4096

% ulimit -n 4096
dove 4096 è il valore di file descriptors che si intendono utilizzare con Squid, eseguiamo un make clean prima di avviare lo
script ./config.status che ci consentirà di configurare nuovamente l'ambiente tenendo conto delle nuove impostazioni del kernel
% 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
...
ora compiliamo ed installiamo nuovamente Squid

% make
% make install
non abbiamo ancora finito, impostare il valore corretto di file descriptors con linux non riguarda solo la compilazione e
l'installazione di Squid ma anche il suo avviamento
ulimit -HSn 4096
possiamo inserire questo ultimo comando nello script di avviamento di Squid, in qualsiasi distribuzione Red Hat o Fedora core
il file da modificare è /etc/rc.d/init.d/squid
7.6.3. File descriptor con Solaris
Il valore di default è 1024, per impostare il numero di File Descriptor dovremo editare il file /etc/system
set rlim_fd_max = 4096
7.6.4. File descriptors con FreeBSD
L'approccio al problema dei file descriptors nei sistemi BSD è totalmente diverso e naturalmente più funzionale se paragonato
con i sistemi linux, la voce di configurazione che nel kernel controlla questa impostazione prende il nome di MAXFILES.
Ultimamente questo tipo di approccio è stato leggermente modificato, infatti i nuovi kernel dei sistemi FreeBSD controllano
dinamicamente il numero delle tabelle interne che vengono utilizzate dal sistema operativo, tale impostazione viene
determinata prendendo come riferimento la quantità di memoria che è stata fisicamente installata sul server di produzione. Il
file di configurazione del Kernel di FreeBSD (e di molti alti sistemi BSD) si trova in /usr/src/sys/i386/conf/GENERIC,
l'impostazione che determina questa modalità di funzionamento è
maxusers 0
7.6.4.1. MAXFILES
se vogliamo impostare manualmente il valore dei descrittori di files dovremmo editare il file di configurazione del kernel,
questa modifica vale anche per i sistemi NetBSD ed OpenBSD

options MAXFILES=8192
possiamo verificare il valore dei file descriptors attivi in un dato momento utilizzando il comando sysctl(8), le variabili del
kernel di un sistema FreeBSD possono essere visualizzate ed eventualmente modificate utilizzando il comando sysctl
% sysctl -a | grep kern.maxfiles

kern.maxfiles: 4040
kern.maxfilesperproc: 3636
come per i sistemi linux per visualizzare il numero di files descriptors attivi possiamo anche utilizzare l'opzione di shell ulimit
% ulimit -n
4040
non è dunque necessario ricompilare il kernel per impostare il valore corretto dei file descriptors, sarà sufficente editare il file /
etc/sysctl.conf
kern.maxfiles=4040
kern.maxfilesperproc=3636
per concludere possiamo dire che modificare manualmente il numero di file descriptors in un sistema BSD ha senso solo se si
vuole ottimizzare le prestazioni di un server di rete ad alto traffico.
7.6.4.2. MBUF
Un'altro collo di bottiglia per il kernel di un sistema FreeBSD è rappresentato dalla corretta impostazione del valore di MBUF.
MBUF sono dei pezzi di memoria che vengono utilizzati dal kernel per consentire tutte le connessioni di rete. Il numero di
MBUF scala in relazione alla impostazione dell'opzione MAXUSERS all'interno del file di configurazione del kernel, anche in
questo caso con i nuovi kernel di FreeBSD, questo valore viene impostato in maniera automatica così come avviene per i
descrittori di files, anche in questo caso potrebbe rendersi necessario aumentare il valore degli MBUF. L'opzione
NMBCLUSTERS controlla il numero di MBUFS creati dal kernel di sistema

% 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
questo sistema FreeBSD dispone di 16384 MBUF, se volessimo aumentare questo valore dovremmo modificare il file di
configurazione del Kernel così come segue
options NMBCLUSTERS=32768
questa impostazione vale anche per NetBSD e OpenBSD
7.6.5. File descriptors con Windows
il numero massimo di file descriptor è 2048, questo valore é preimpostato nella libreria dinamica MSVCRT.DLL e non può
essere modificato se non ricompilando la DLL stessa.
7.6.6. File handles con OS/2
Se si utilizza il runtime EMX (The UN*X to OS/2-EMX Porting) è possibile definire il numero massimo di file handles
modificando il file config.sys
SET EMXOPT=-h#
questa impostazione fissa il limite massimo di file handles a #, il valore di # deve essere un numero compreso tra 10 e 65536,
l'ultima versione disponibile compilata con il runtime EMX supporta solo 256 file handles.
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.
7.8.1. Perchè installare Squid dai sorgenti
Tra i principali vantaggi che possiamo ottenere installando Squid utilizzando la procedura di compilazione dei codici sorgenti
citiamo
● ottimizzare il codice binario di Squid per il processore specifico in uso nel nostro sistema
● modificare il limite massimo di file descriptors utilizzabili
● ottimizzare le performance anche relativamente al tipo di Disk Storage utilizzato
● scegliere le opzioni di configurazione realmente necessarie alla nostre esigenze
WCCP, i delay pools, il tipo di autenticazione, HTCP, il supporto ICMP ed il tipo di Disk Storage sono le opzioni di
configurazione maggiormente utilizzate
● non tutti i package precompilati di Squid offrono le opzioni potenzialmente disponibili nella versione che viene
compilata utilizzando i codici sorgenti
possiamo quindi affermare che è possibile realizzare delle appliance vere e proprie compilando prima il Kernel del Sistema
Operativo e successivamente la nostra webcache Squid. Solo in questo modo potremo ottenere un sistema di webcache
performante e leggero.
7.8.2. I comandi più importanti
Dopo aver configurato nella maniera più opportuna Squid con il comando configure potremmo finalmente compilare
utilizzando il comando make(8)
% make
procediamo con l'installazione utilizzando il comando make install

% make install
7.8.3. L'albero delle directory di Squid
supponendo di aver utilizzato come opzione di configurazione
% ./configure --prefix=/usr/local/squid
mostriamo ora al lettore l'albero delle directory di /usr/local/squid che contiene gli eseguibili ed i files di configurazione di
Squid che vengono generati utilizzando il comando make && make install
% 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
● le applicazioni che possono essere utilizzate da tutti gli utenti di sistema si trovano in /usr/local/squid/bin
% ls -l /usr/local/squid/bin/
totale 28
-rwxr-xr-x 1 root root 741 13 set 17:24 RunAccel
-rwxr-xr-x 1 root root 732 13 set 17:24 RunCache
-rwxr-xr-x 1 root root 18580 13 set 17:28 squidclient
il file RunCache è uno script che può essere utilizzato per avviare Squid, anche lo script RunAccel è simile al precedente
ma accetta anche un'argomento a linea di comando che indica a Squid la porta da utilizzare per rimanere in ascolto di
richieste HTTP
● le applicazioni che normalmente possono essere avviate dall'utente root si trovano in /usr/local/squid/sbin
% ls -l /usr/local/squid/sbin/
totale 668
-rwxr-xr-x 1 root root 676024 13 set 17:28 squid

questo è il file eseguibile del processo Squid
● il percorso dove vengono installati normalmente i vari helpers utilizzati da Squid si trovano in /usr/local/squid/libexec
# ls -l /usr/local/squid/libexec/
totale 220
-rwxr-xr-x 1 root root 19000 13 set 17:28 cachemgr.cgi
-rwxr-xr-x 1 root root 11028 13 set 17:28 digest_pw_auth
-rwxr-xr-x 1 root root 11808 13 set 17:28 diskd
-rwxr-xr-x 1 root root 5384 13 set 17:28 ip_user_check
-rwxr-xr-x 1 root root 32568 13 set 17:28 msnt_auth
-rwxr-xr-x 1 root root 10356 13 set 17:28 ncsa_auth
-rwxr-xr-x 1 root root 43180 13 set 17:28 ntlm_auth
-rwxr-xr-x 1 root root 10272 13 set 17:28 pam_auth
-rwxr-xr-x 1 root root 5904 13 set 17:28 squid_unix_group
-rwxr-xr-x 1 root root 3468 13 set 17:28 unlinkd
-rwxr-xr-x 1 root root 11860 13 set 17:28 wb_auth
-rwxr-xr-x 1 root root 10148 13 set 17:28 wb_group
-rwxr-xr-x 1 root root 1333 13 set 17:27 wbinfo_group.pl
-rwxr-xr-x 1 root root 16516 13 set 17:28 wb_ntlmauth
-rwxr-xr-x 1 root root 8052 13 set 17:28 yp_auth
il suo contenuto dipende dal numero di opzioni di configurazione abilitate
● la directory dove vengono memorizzati i files di configurazione di Squid si trova in /usr/local/squid/etc
% ls -l /usr/local/squid/etc/
totale 268
-rw-r--r-- 1 root root 11651 2 apr 23:03 mime.conf
-rw-r--r-- 1 root root 11651 13 set 17:27 mime.conf.default
-rw-r--r-- 1 root root 421 10 apr 10:04 msntauth.conf
-rw-r--r-- 1 root root 421 13 set 17:27 msntauth.conf.default
-rw-r--r-- 1 root root 113932 17 apr 01:01 squid.conf
-rw-r--r-- 1 root root 114832 13 set 17:27 squid.conf.default
il contenuto di questa directory ed il contenuto dei file di configurazione di base squid.conf dipendono dal numero di
opzioni di configurazione abilitate. Nella directory viene incluso anche il file mime.conf che indica a Squid i MIME
types da utilizzare quando i dati vengono richiesti utilizzando ftp e gopher
● la directory che normalmente contiene i files di sola lettura che vengono utilizzati da Squid si trova in /usr/local/squid/
share

# ls -l /usr/local/squid/share/
totale 36
drwxr-xr-x 30 root root 4096 2 apr 23:03 errors
drwxr-xr-x 2 root root 4096 13 set 17:27 icons
-rw-r--r-- 1 root root 26104 13 set 17:27 mib.txt
la directory share/icons contiene i file di icone utilizzati da Squid per l'ftp ed il gopher, la directory share/errors
contiene i template per i messaggi di errore che vengono visualizzati da Squid, il file mib.txt è il Management
Information Base (MIB) per Squid
7.8.4. Pulire gli eseguibili dalle informazioni di debug
Il comando make install genera degli eseguibili mostruosamente grandi, se invece si desidera installare degli eseguibili puliti,
senza alcuna informazione di debug, é possibile utilizzare il comando make install-strip. Ricordiamo agli utenti che questo
comando può essere eseguito soltanto dall'interno della directory contenete i sorgenti di Squid
% make && make install

% cd src/
% make install-strip
per rimuovere le informazioni di debug dagli eseguibili potremmo anche utilizzare il comando strip(8). Questo comando
elimina le informazioni di debug dagli object files scartando automaticamente gli oggetti non riconosciuti come eseguibili
% 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
7.8.5. Altre informazioni per installare correttamente Squid dai sorgenti
nel caso in cui con le opzioni di configurazione sia stato attivato il supporto ICMP, è necessario installare anche l'helper pinger
con il comando
% make install-pinger
consigliamo sempre di generare una directory dedicata al file che identifica il numero di processo (squid.pid) e assegnare subito
dopo i permessi per consentire l'esecuzione dei processi disk I/O. Nell'esempio seguente la UID nobody eseguirà il processo
Squid

% mkdir /usr/local/squid/var/run
% chown -R nobody:nobody /usr/local/squid/var/*
è ora possibile editare e customizzare il file squid.conf che nell'installazione di default viene memorizzato in
/usr/local/squid/etc/squid.conf
una guida di avviamento rapido viene sempre inclusa con la distribuzione dei sorgenti di Squid
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.
7.9.1. Package per i vari ambienti UNIX®
Vediamo ora alcune delle URLs dalle quali è possibile prelevare i package per le piattaforme SGI IRIX, FreeBSD, NetBSD,
Sun Solaris e Linux
● Il sito Freeware della SGI fornisce delle versioni precompilate di Squid per la piattaforma SGI IRIX
● I package di Squid sono disponibili per il Sistema Operativo FreeBSD per le piattaforme Alpha, AMD64 ed IA32
consigliamo comunque di compilare Squid sulla piattaforma specifica utilizzando l'albero dei ports di FreeBSD, tale
procedura implica la compilazione del codice sorgente incluse le eventuali patch relative alla piattaforma
● Sono disponibili i binari di Squid per qualsiasi piattaforma supportata dal sistema Operativo NetBSD
● Gurkan Sengun rende disponibili le versioni binarie di Squid per il Sistema Operativo Sun Solaris su piattaforma Sparc
● tutte le più importanti distribuzioni di GNU Linux forniscono le versioni precompilate di Squid
i package per le distribuzioni RedHat Linux a partire dalla versione 6.2 sino alla versione 7.3 (attualmente non più
supportate dalla RedHat) sono disponibili alla URLs: http://www.swelltech.com/support/squidpackages.html
In merito ai pacchetti precompilati per le altre distribuzioni GNU Linux, è necessario fare riferimento alla home page della
distribuzione che state utilizzando.

7.9.2. Package per Win32 ed OS/2
Di seguito si forniscono le URLs dalle quali è possibile prelevare i package per le piattaforme Windows ed OS/2
● per la piattaforma Win32 riferirsi alla URLs: http://www.acmeconsulting.it/SquidNT/
● per la piattaforma OS/2 riferirsi alla URLs: ftp://hobbes.nmsu.edu/pub/os2/apps/internet/www/server
● per la piattaforma OS/2 e la versione nativa VACPP riferirsi alla URLs: http://www.laser.ru/evgen/soft/Squid2/index_l.
html
Capitolo 8. Postinstallazione
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.
8.6.1. Files di log principali
vediamo ora come sia possibile gestire i files di log di Squid, i TAG più importanti relativi all'attivazione dei files di log
all'interno del file squid.conf sono
il TAG cache_access_log
cache_access_log /usr/local/squid/var/logs/access.log

nel file access.log vengono registrate tutte le transazioni effettuate dai client, vedremo in seguito ulteriori informazioni
il TAG cache_log
cache_log /usr/local/squid/var/logs/cache.log
nel file cache.log vengono registrate tutte le informazioni sullo stato della cache, vedremo in seguito ulteriori informazioni
il TAG cache_store_log
cache_store_log /usr/local/squid/var/logs/store.log
nel file store.log vengono registrate tutte le attività eseguite dallo storage manager di Squid, vedremo in seguito ulteriori
informazioni
il TAG cache_swap_log
cache_swap_log /usr/local/squid/var/cache/swap.state
nel file swap.state viene memorizzato il file di log dello swap, si tratta di un file binario che include un checksum MD5 e che
contiene i campi dello store entry. Non è necessario indicarlo in squid.conf in quanto verrà scritto automaticamente nella top
level directory della cache_dir
8.6.2. Files di log accessori
vi sono anche alcune opzioni relative ad alcuni files di log che devono essere esplicitamente compilate per essere supportate
attivamente da Squid proxy server
il TAG useragent_log
useragent_log /usr/local/squid/var/logs/useragent.log
nel file useragent.log viene registrato il campo user-agent per ogni richiesta HTTP. Questa opzione è disponibile solo se Squid
viene compilato con l'opzione di ./configure

%./configure --enable-useragent-log
questa opzione è utile per generare dei report sulle tipologie dei browser utilizzati dagli utenti e viene disabilitata di default
il TAG referer_log
referer_log /usr/local/squid/var/logs/referer.log
nel file referer.log viene registrato il campo referer per ogni richiesta HTTP. Questa opzione è disponibile solo se Squid viene
compilato con l'opzione di ./configure
%./configure --enable-referer-log
questa opzione è utile per generare dei report sui link esterni ed i vari motori di ricerca, viene disabiliata di default.
8.6.3. Formati dei files di log
In fase di configurazione possiamo anche definire il formato dei files di logs, tale formato può essere suddiviso in file di log
nativi ed in file di log che emulano lo schema transazionale di un server web, il TAG da utilizzare è emulate_httpd_log [on|off]
il cui valore di default è off
emulate_httpd_log on
in questo esempio emuliamo il file di log di un server web, questa funzionalità può essere utile nel caso in cui si decida di
utilizzare il proxy server con funzionalità di Reverse Proxy.
8.6.4. Ruotare i files di log
con il TAG logfile_rotate è possibile specificare il numero massimo di rotazione per un file di log
logfile_rotate 10
la rotazione dei file di log può essere effettuata con il comando

% squid -k rotate
i comando squid -k rotate invia un segnale USR1 al processo Squid, viene utilizzato per ruotare dei file di log di dimensioni
notevoli (Linux con ext2 non supporta files che superano 2 GB). Il processo di rotazione chiude un file, lo rinomina ed apre un
nuovo file di log. E' prassi inserire questo comando nella tabella di crontab(8)[20] del sistema (file /etc/crontab) per ruotare
automaticamente i log di Squid, nell'esempio seguente prevediamo una rotazione ogni mese alle ore 01:01
01 1 * 1 * /usr/local/squid/sbin/squid -k rotate
il valore di default per il TAG logfile_rotate è 10, impostando questo valore i file di log verranno ruotati e gli verrà assegnata
una estensione che va da 0 a 9. Il file cache.log diverrà cache.log.0, ed ancora cache.log.0 diverrà cache.log.1, successivamente
cache.log.1 diverrà cache.log.2 e così via. La rotazione dei files di log riguarderà anche il file swap.state
logfile_rotate 0
Impostando il TAG logfile_rotate 0 verrà disabilitata la rotazione dei file di log.
8.6.5. Disabilitare i files di log
se si persegue l'obiettivo delle prestazioni è possibile disabilitare totalmente o parzialmente il sistema di logging ricorrendo ad
alcuni TAG nel file squid.conf
ecco un esempio valido per squid-2.4
cache_access_log /dev/null
cache_store_log none
cache_log /dev/null
se invece utilizzate squid-2.5
cache_access_log none
cache_log /dev/null
useragent_log none
referer_log none

è decisamente una cattiva idea disabilitare il file cache.log, questo file contiene diversi messaggi sullo stato di funzionamento
di Squid ed altri messaggi per il debugging. Se viene specificato il percorso /dev/null per disabilitare il logging di Squid, è
necessario impostare il TAG logfile_rotate 0. Disabilitando il logging è anche possibile migliorare le performance del disk I/O,
in seguito vedremo come sia possibile creare un proxy server anonimizzante.
8.6.6. Mime tipe e file di processo
è anche previsto un TAG che consente di definire un file che identifichi la tabella dei mime type[21]
il TAG mime_table
mime_table /usr/local/squid/etc/mime.conf
questa tabella contiene gli esempi standard di mime type nella loro formattazione più comune
il TAG pid_filename
pid_filename /usr/local/squid/var/run/squid.pid
questo TAG identifica il nome del file che contiene il numero di processo che viene attivato da Squid con il suo avviamento.
8.6.7. Memoria e cache_dir
il TAG cache_mem consente di impostare la quantità di memoria RAM massima che potrà essere utilizzata dal processo Squid
cache_mem 64 MB
questo TAG non dovrebbe mai superare 1/4 della memoria fisica installata sul sistema, vedremo i dettagli in seguito. Non
dimentichiamo che è possibile utilizzare anche il TAG high_memory_warning per tenere sotto controllo l'utilizzo della memoria
high_memory_warning 80 MB
se l'utilizzo della memoria supera i valori da noi impostati, Squid registra un WARNING nel file cache.log anche se il TAG
debug level è impostato a 0.
ufs è il tipo di Disk Storage che viene utilizzato storicamente da Squid, come vedremo successivamente è proprio questo il

sistema che si occupa di gestire il processo di disk-I/O. Il TAG cache_dir definisce il percorso su disco dove verrà ubicata la
cache di Squid
cache_dir ufs /squid/cache 100 16 256
la sintassi di questo TAG verrà approfondita nel capitolo dedicato al Disk Storage
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 [email protected]
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 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
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 locallan src 192.168.0.0/255.255.255.0
cache_mgr [email protected]
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.
Capitolo 9. Il Cache Store di 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
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.
9.6.1. ufs storage
È il Disk Storage system originario e nativo di Squid, si basa su una struttura di directory a 2 livelli dove i valori di default
prevedono ben 16 directory per il primo livello (L1) e 256 per il secondo (L2). Tutti gli oggetti presenti nella cache di Squid
sono immagazzinati come file all'interno del secondo livello, tutte le operazioni di I/O sono gestite in modalità sincrona
direttamente dal Sistema Operativo e possono bloccare il funzionamento del processo principale di Squid sino al loro
completamento. La sintassi del TAG cache_dir per il Disk Storage ufs é
cache_dir ufs Directory-Name MBytes L1 L2 [options]

dove Directory-Name identifica la top-level directory nella quale i files saranno immagazzinati, L1 è il numero di directory di
primo livello, L2 è il numero di directory di secondo livello ed il numero massimo di oggetti per directory, infine MBytes indica
la dimensione massima in MBytes di questo Disk Storage, ecco un esempio
9.6.2. aufs storage
Utilizza il medesimo formato di storage su disco di ufs, tutte le operazioni di I/O sono gestite in modalità asincrona utilizzando
il modello POSIX-threads, aufs utilizza quindi dei processi di tipo thread che gli consentono di eseguire le operazioni di disk I/
O. Questo modello di storage consente di evitare il blocco del processo principale di Squid durante tutte le operazioni di disk I/
O in quanto le stesse vengono inoltrate ad un processo thread differente. Questo tipo di Disk Storage viene spesso indicato
anche come async-io e non può essere utilizzato efficacemente sui Sistemi che implementano il modello dello user-threads, il
codice aufs richiede la presenza della libreria pthreads. Questo tipo di Disk Storage non é disponibile sulle piattaforme
Windows e funziona unicamente sulle piattaforme Linux, FreeBSD e Solaris. La sintassi del TAG cache_dir per il Disk Storage
aufs é
cache_dir aufs Directory-Name MBytes L1 L2 [options]
Dove Directory-Name identifica la top-level directory ove i files verranno immagazzinati, L1 è il numero di directory di primo
livello, L2 è il numero di directory di secondo livello ed il numero massimo di oggetti per directory ed infine MBytes è la
dimensione massima espressa in MBytes per questo Disk Storage. Ecco un esempio
cache_dir aufs /usr/local/squid/var/cache 8192 16 256
Il numero di thread in uso viene calcolato dinamicamente in funzione del numero delle cache_dir definite, la seguente tabella
mostra il numero di thread predefiniti sino a 6 cache_dir
cache_dir threads
1 16
2 26
3 32
4 36
5 40
6 44
in alternativa è possibile forzare il numero di thread al momento della compilazione di Squid ricorrendo all'opzione --with-aio-
threads=N di ./configure

% ./configure --with-aio-threads=32
utilizzando il cache manager è possibile visualizzare le statistiche relative a aufs
% 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
9.6.3. awin32 storage
Si tratta del port nativo di aufs per la piattaforma Windows. Anche in questo caso, tutte le operazioni di I/O sono gestite in
modalità asincrona utilizzando i Win32 native threads, questo tipo di approccio serve per evitare il blocco del processo
principale di Squid durante le operazioni di disk I/O. La sintassi del TAG cache_dir per il Disk Storage awin32 é
cache_dir awin32 Directory-Name MBytes L1 L2 [options]
dove Directory-Name identifica la top-level directory dove i files saranno salvati, L1 è il numero di directory di primo livello,
L2 è il numero di directory di secondo livello ed il numero massimo di oggetti per directory, infine MBytes indica la
dimensione massima espressa in MBytes di questo Disk Storage. Di seguito ecco un esempio
cache_dir awin32 c:/squid/var/cache 4096 16 256

9.6.4. diskd storage
Diskd è l'acronimo di disk daemons ed utilizza il medesimo formato di storage di ufs, concettualmente è molto simile ad aufs,
l'unica differenza che distingue diskd da aufs risiede nel fatto che tutte le operazioni di I/O vengono gestite in modalità
asincrona ricorrendo ad un programma esterno per ogni cache_dir. Questo sistema consente di evitare il blocco del processo
principale di Squid durante le operazioni di disk I/O, diskd dunque non utilizza i threads e le funzioni IPC[24] vengono
implementate ricorrendo alla memoria condivisa (shared memory) e alla coda dei messaggi (message queue) del Sistema
Operativo. La coda dei messaggi è implementata per la prima volta dalla AT&T con il rilascio dello UNIX® System V,
Release 1. Diskd viene particolarmente indicato sui sistemi che implementano il modello dello user-threads come FreeBSD ed
OpenBSD; funziona anche con Linux, Solaris e Digital Unix® mentre non è disponibile sulle piattaforme Windows. La sintassi
del TAG cache_dir per il Disk Storage diskd é
cache_dir diskd Directory-Name MBytes L1 L2 [options] [Q1=n] [Q2=n]
dove Directory-Name identifica la top-level directory in cui i file verranno immagazzinati, L1 è il numero di directory di primo
livello, L2 è il numero di directory di secondo livello nonchè il numero massimo di oggetti per directory, infine MBytes
rappresenta la dimensione massima espressa in MBytes per questo Disk Storage. I Parametri Q1 e Q2 indicano rispettivamente
la lunghezza massima della coda di I/O per il blocco dell'apertura di nuovi files e la lunghezza massima della coda di I/O per
l'inizio del funzionamento in modalità blocking. I valori predefiniti sono 72 e 64. È inoltre necessario specificare il percorso
dell'eseguibile del programma diskd. Questa funzionalità viene attivata solo se abbiamo compilato Squid con il supporto a
diskd, il TAG da indicare nel file squid.conf è
diskd_program diskd-path
di seguito un esempio
cache_dir diskd /usr/local/squid/var/cache 8192 16 256 Q1=72 Q2=64

diskd_program /usr/local/squid/libexec/diskd
utilizzando il Cache Manager è possibile visualizzare le prestazioni del 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
9.6.4.1. Tuning dei parametri Q1 e Q2
Abbiamo già parlato in precedenza dei valori Q1 e Q2, nel codice sorgente di Squid vengono chiamati magic1 e magic2 e si
riferiscono al numero di richieste di I/O che vengono contenute nella coda dei messaggi che rimangono in attesa di un
acknowledge da parte di diskd. Questi valori vengono specificati nel TAG cache_dir, dopo aver impostato le directory di livello
L1 e L2, il formato del TAG è
cache_dir diskd Directory-Name MBytes L1 L2 [options] [Q1=n] [Q2=n]
quando la lunghezza della coda dei messaggi raggiunge il valore Q1, Squid intenzionalmente fallisce l'apertura dei files sul
disco per quello che concerne le operazioni di lettura e scrittura. Si tratta di un efficente meccanismo di load-shedding,
letteralmente tradotto come spargimento delle richieste. Se la cache è veramente occupata e non è possibile accedere al disco,
Squid sorpassa il disco stesso prima che il numero delle richieste vada nuovamente giù. Se la lunghezza della coda raggiunge il
valore Q2, allora il processo principale di Squid si pone in I/O blocking mode per piccole frazioni di tempo, sino a quando il
processo di diskd riprende a fornire dei risultati. Se vogliamo che Squid si ponga in I/O blocking mode prima di iniziare la fase
di rifiuto dell'apertura dei files, il valore di Q1 deve essere decisamente più grande del valore Q2. Nel nostro esempio, nel file
di configurazione di Squid abbiamo impostato dei valori che possono essere considerati come ragionevoli per Q1 e Q2, tali
valori saranno appunto rispettivamente come già consigliato 72 e 64
cache_dir diskd /usr/local/squid/cache 7500 16 256 Q1=72 Q2=64
9.6.4.2. Configurare la coda dei messaggi (message queues)
Molti sistemi operativi UNIX® hanno il supporto per la gestione della coda dei messaggi abilitato come default. Una metodo
per verificare questa impostazione è controllare se si dispone del comando ipcs(1), ipcs è una facility del sistema operativo che
esegue dei report sullo stato delle comunicazioni intraprocesso. È comunque necessario aumentare la grandezza della coda dei
messaggi per far lavorare correttamente Squid, le implementazioni della coda dei messaggi rispondono ai seguenti parametri
● MSGMNB - numero massimo di byte per message queue

● MSGMNI - numero massimo di identificativi message queue (system wide)
● MSGSEG - numero massimo di segmenti dei messaggi per la coda (queue)
● MSGSSZ - grandezza del segmento dei messaggi
● MSGTQL - numero massimo dei messaggi (system wide)
● MSGMAX - grandezza massima di un whole message. In molti sistemi è necessario aumentare questo limite, in altri
sistemi non è possibile modificare questo valore
i messaggi tra Squid e diskd sono di 32 bytes per le CPUs a 32-bit mentre sono di 40 bytes per le architetture che prevedono
CPUs a 64-bit. Sulla base di queste informazioni, MSGSSZ deve avere un valore di 32 oppure essere più grande, è indicato
settare un valore più grande per avere maggiore sicurezza. Ci sono due code per ogni cache_dir, una per ogni direzione, così il
valore richiesto per MSGMNI deve essere almeno due volte il numero delle cache_dir. Sono stati rilevati in media 75 messaggi
per coda ed è proprio questo il limite che consente di ottenere delle performance decenti con diskd. Se ogni messaggio diskd
consiste di un segmento (questo dipende dal valore che abbiamo assegnato a MSGSSZ), allora MSGSEG dovrà essere più
grande di 75. MSGMNB e MSGTQL dipendono da quanti messaggi possono essere contenuti dalla coda nello stesso momento. I
messaggi diskd non devono essere più grandi di 40 bytes e si utilizzano 64 bytes per essere più sicuri. MSGMNB dovrà essere
almeno 64*75, si raccomanda di impostare un numero non lontano dal doppio di questo valore oppure un valore di 8192.
MSGTQL deve essere almeno 75 volte il numero dei TAG cache_dir che abbiamo configurato.
9.6.4.3. Coda dei messaggi con BSD
Il Kernel deve prevedere le seguenti impostazioni
options SYSVMSG
altri parametri da impostare prima di ricompilare il Kernel vengono riportati da questo esempio, assicuriamoci di impostare i
valori appropriati per il nostro sistema
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
9.6.4.4. Coda dei messaggi con Linux
Per configurare la coda dei messaggi con Linux è necessario editare il file /etc/sysctl.conf

kernel.msgmnb=8192
kernel.msgmni=40
kernel.msgmax=8192
9.6.4.5. Coda dei messaggi con Solaris
Aggiungere le seguenti linee nel file /etc/system
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
naturalmente è necessario eseguire un riavvio del Sistema dopo aver modificato il file /etc/system
9.6.4.6. Configurare la memoria condivisa (shared memory)
La Shared Memory utilizza un insieme di parametri simili a quelli utilizzati per la gestione della coda dei messaggi (message
queues). L'implementazione del diskd di Squid utilizza un'area di memoria condivisa per ogni cache_dir. Qualsiasi area di
Shared Memory è almeno di 800 kilobytes per tipo, per un corretto funzionamento di Squid con diskd è quindi richiesto
modificare i seguenti parametri della Shared Memory
● SHMSEG - numero massimo di segmenti di shared memory per processo
● SHMMNI - numero massimo di segmenti di shared memory per il segments per l'intero sistema
● SHMMAX - segmento più grande di shared memory segment autorizzato
● SHMALL - ammontare totale della shared memory che può essere utilizzata
per Squid e diskd, SHMMNI e SHMMNI devono essere più grandi o uguali al numero di cache_dir configurate sul sistema di
webcache. SHMMAX deve essere almeno di 800 kilobytes, SHMALL deve essere almeno il valore di SHMMAX 800 kilobytes
moltiplicato per il numero delle cache_dir.
9.6.4.7. Memoria condivisa con BSD
Il Kernel deve prevedere le seguenti impostazioni

options SYSVSHM
altri parametri da impostare prima di ricompilare il Kernel vengono riportati da questo esempio, assicuriamoci di impostare i
valori appropriati per il nostro sistema
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)
9.6.4.8. Memoria condivisa con Linux
Per configurare la memoria condivisa con Linux è necessario editare il file /etc/sysctl.conf
kernel.shmall=2097152
kernel.shmmni=32
kernel.shmmax=16777216
9.6.4.9. Memoria condivisa con Solaris
Aggiungere le seguenti linee nel file /etc/system
set shmsys:shminfo_shmmax=2097152
set shmsys:shminfo_shmmni=32
set shmsys:shminfo_shmseg=16
naturalmente è necessario eseguire un riavvio del Sistema dopo aver modificato il file /etc/system
9.6.5. null storage
Null è uno schema di Disk Storage fittizio, viene utilizzato nei casi in cui si desidera che Squid effettui il caching nella sola
memoria, in questo caso non verrà salvata alcuna copia degli oggetti su disco. Viene anche utilizzato per eseguire dei test
prestazionali, utilizzare uno schema di Disk Storage come null consente di aumentare le prestazioni in maniera drastica. La
sintassi del TAG cache_dir per il Disk Storage null é

cache_dir null Directory-Name [options]
Dove Directory-Name identifica una top-level directory fittizia, ecco un esempio
cache_dir null /tmp
9.6.6. coss storage
Coss è l'acronimo di Cyclic Object Storage System Scheme, questo modello di Storage utilizza un singolo file per memorizzare
tutti gli oggetti e quando il file raggiunge le sue dimensioni massime, Squid si occupa di ripartire dall'inizio del file stesso
riscivendo tutti i dati presenti nel file. Il file potrebbe anche essere rappresentato con un raw disk device. Sfortunatamente si
tratta di uno schema di storage system ancora a livello sperimentale ed il suo sviluppo procede piuttosto lentamente. Tutte le
operazioni di disk I/O vengono gestite in modalità asincrona ricorrendo al modello POSIX AIO, in particolare utilizza le
chiamate di sistema aio_read() e aio_write(). La gestione asincrona, come abbiamo visto, consente di evitare il blocco del
processo principale di Squid durante le operazioni di disk I/O, coss è al momento disponibile per FreeBSD, Solaris e Linux e
non é invece disponibile sulle piattaforme Windows. La sintassi del TAG cache_dir per il Disk Storage coss é
cache_dir coss File-Name MBytes max-size=n [options] [block-size=b]
dove File-Name identifica il file contenente il Disk Storage, l'opzione comune max-size deve essere sempre specificata, block-
size é la dimensione del blocco di allocazione utilizzato da coss, ed infine MBytes è la dimensione massima espressa in MBytes
di questo Disk Storage. Ecco alcuni esempi
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
coss per il momento è in grado di supportare il solo algoritmo LRU a riguardo del Memory e Cache Replacement Policy
9.6.7. Scelta del Disk storage più adatto
Quale schema di Storage scegliere? il mio sistema supporta aufs? con il sistema Operativo che utilizzo aufs è più veloce di
diskd o viceversa? Gli interrogativi sono molti così come sono molti i fattori che concorrono a pieno titolo alla scelta del
modello di Disk Storage più adatto per il nostro Sistema, tra i vari fattori citiamo
● Il tipo di Sistema Operativo

● il tipo di utilizzo che si intende fare di Squid
● il numero di transazioni previste
La seguente tabella riassume alcune linee guida da seguire per effettuare tale scelta
I/O sincrono I/O asincrono I/O fittizio

ufs - - ● singola cache
● poche transazioni/sec
- aufs - ● cache multiple
● molte transazioni/sec
● sistema operativo con supporto POSIX-threads
- awin32 - ● cache multiple
● sistema operativo Windows
- diskd - ● cache multiple
● sistema operativo con supporto USER-threads
- - null ● modalità solo proxy
● reverse proxy
Un altro fattore che può influire significativamente sul buon funzionamento del sistema di Disk Storage é il tipo di File System
fisico sul quale viene ad appoggiarsi Squid. Uno spunto molto interessante a riguardo può essere fornito da uno studio di Duane
Wessels che è liberamente disponibile in internet alla URLs http://conferences.oreillynet.com/presentations/os2002/
wessels_duane.ppt.
9.6.8. Esempi di configurazione
Vista la complessità e l'importanza dell'argomento trattato, in questo paragrafo ci occuperemo di mostrare al lettore alcuni
esempi di configurazione di un sistema di Disk Storage efficente con Squid, tratteremo anche le eventuali ottimizzazioni che
sono relative al Sistema Operativo ospitante.

9.6.8.1. Configurare diskd con FreeBSD
In questo caso di studio aumenteremo le performance della disk I/O configurando un sistema di webcache con 3*7500 MB di
cache_dir (L1=16, L2=256) utilizzando il diskd come sistema di Disk Storage, questa configurazione per consentire di ottenere
le performance sperate, richiede la compilazione del Kernel di FreeBSD, il file da editare che contiene tutte le direttive per
compilare il Kernel è
/usr/src/sys/i386/conf/MIOKERNEL
dove MIOKERNEL è il file che include tutte le impostazioni del Kernel, per compilare correttamente il Kernel di FreeBSD
consultare sempre il FreeBSD Handbook oppure, le istruzioni in lingua italiana contenute nel mio libro Note su FreeBSD.
Nel file di configurazione del Kernel, relativamente alla corretta configurazione della Shared Memory (SYSVSHM), devono
essere contenute le seguenti linee (Squid FAQ alla URLs http://www.squid-cache.org/Doc/FAQ/FAQ-22.html#ss22.7)
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)
definiamo il numero massimo di file descriptors ed il numero massimo di cluster mbuf per le connessioni di rete
options MAXFILES=8192
options NMBCLUSTERS=32768
utilizzando l'implementazione reale della system calls aio_* possiamo ottenere una maggiore stabilità e sicurezza del sistema
da possibili attacchi che possono essere portati da utenti locali
options VFS_AIO
nel file di configurazione del Kernel, relativamente alla configurazione della Message Queues (SYSVMSG), devono essere
contenute le seguenti linee (Cfr. Squid FAQ alla URLs http://www.squid-cache.org/Doc/FAQ/FAQ-22.html#ss22.6)

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
Dopo aver inserito queste entry nel file di configurazione del Kernel di FreeBSD, si procederà con la compilazione vera e
propria del nuovo Kernel a questo punto ottimizzato per eseguire Squid
% cd /usr/src
% make buildkernel KERNCONF=MIOKERNEL
% make installkernel KERNCONF=MIOKERNEL
% reboot
al successivo avviamento la nostra macchina FreeBSD sarà finalmente pronta per la compilazione e l'installazione di Squid
Proxy Server. Ritornando nuovamente alla configurazione di Squid, per utilizzare diskd come sistema di Disk Storage è
necessario compilare Squid utilizzando le seguenti opzioni di ./configure
% ./configure --enable-storeio=diskd,ufs
il port di FreeBSD prevede l'abilitazione di questo tipo di opzione come default e comunque, se si vuole selezionare alcune
delle opzioni esotiche di ./configure, è necessario digitare i seguenti comandi
% cd /usr/ports/www/squid
% make config
% make
% make install clean
9.6.8.2. Configurare ufs (multipiattaforma)
A riguardo la configurazione è piuttosto semplice in quanto si limita alla sola modifica del file squid.conf
si tratta dello schema di storage di default di Squid e può essere utilizzato per qualsiasi tipo di configurazione

9.6.8.3. Configurare aufs con Linux
cache_dir aufs /usr/local/squid/var/cache 6744 16 256
trattandosi dello stesso schema di storage di ufs sarà sufficente rileggere la configurazione di Squid (squid -k reconfigure)
9.6.8.4. Configurare awin32 con Windows
cache_dir awin32 c:/squid/var/cache 6744 16 256
trattandosi dello stesso schema di storage di ufs sarà sufficente rileggere la configurazione di Squid (squid -k reconfigure)
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.
La configurazione del Memory Storage é controllabile tramite alcuni parametri di configurazione inclusi nel file squid.conf

cache_mem bytes
high_memory_warning bytes
maximum_object_size bytes
minimum_object_size bytes
maximum_object_size_in_memory bytes
il TAG cache_mem
specifica la quantità massima di memoria utilizzabile da Squid per contenere gli oggetti di tipo In-Transit, Hot e Negative-
Cached, l'allocazione di memoria avviene a blocchi di 4 KByte. In caso di necessità, il limite specificato può essere
momentaneamente superato, il valore predefinito é 8 MByte, ad esempio
cache_mem 64 MB
il TAG cache_mem non determina l'occupazione massima di memoria che viene effettuata da Squid. Squid infatti utilizza altra
memoria per eseguire le altre operazioni e diversi I/O buffer (scrittura dei file su disco o una richiesta HTTP), per eventuali ed
ulteriori dettagli riferisi alla relativa sezione nelle FAQ di Squid.
il TAG high_memory_warning
viene utilizzato per tenere sotto controllo l'utilizzo della memoria
high_memory_warning 80 MB
se l'utilizzo della memoria supera i valori da noi impostati, Squid registra un WARNING nel file cache.log anche se il debug
level è impostato a 0.
il TAG maximum_object_size
specifica la dimensione massima degli oggetti memorizzabili nel Disk Storage, un valore elevato per questo parametro fornisce
un alto rapporto di BYTE hits, i valori bassi forniscono una maggiore responsivitá della webcache a discapito di un maggiore
consumo di banda Internet. Il valore predefinito é 4096 KByte, ad esempio
maximum_object_size 8192 Kb
il TAG mimum_object_size
specifica la dimensione minima degli oggetti memorizzabili nel Disk Storage, il valore predefinito é 0 KByte, ad esempio

mimum_object_size 1 Kb
il TAG maximum_object_size_in_memory
specifica la dimensione massima degli oggetti conservabili nel Memory Storage. È raccomandabile impostare questo parametro
con un valore che consenta la memorizzazione degli oggetti con un elevato hit rate, senza però sovraccaricare il Memory
Storage con oggetti di dimensioni elevate. Il valore predefinito é 8 KByte, ad esempio
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
La configurazione delle Replacement policy in Squid avviene tramite i seguenti parametri
cache_replacement_policy policy
memory_replacement_policy policy
cache_swap_low low-water-mark
cache_swap_high high-water-mark
il TAG cache_replacement_policy
specifica la replacement policy da utilizzare per determinare quali oggetti devono essere eliminati e/o sostituiti quando è
necessario del nuovo spazio nel Disk Storage. Il valore predefinito é lru, i valori possibili sono
lru
heap GDSF
heap LFUDA
heap LRU
ad esempio
cache_replacement_policy heap LFUDA
il TAG memory_replacement_policy
specifica la replacement policy da utilizzare per determinare quali oggetti devono essere eliminati e/o sostituiti quando è
necessario del nuovo spazio nel Memory Storage. Il valore predefinito é lru, i valori possibili sono

lru
heap GDSF
heap LFUDA
heap LRU
ad esempio
memory_replacement_policy heap GDSF
il TAG cache_swap_low
specifica il valore ottimale di percentuale di utilizzo del Disk Storage desiderato, quando tale soglia viene superata, le Policy di
Replacement vengono attivate. Il valore predefinito é 90%, ad esempio
cache_swap_low 85
il TAG cache_swap_high
specifica il valore massimo di percentuale di utilizzo del Disk Storage desiderato, quando tale soglia viene avvicinata, le Policy
di Replacement vengono applicate in modo maggiormente aggressivo. Il valore predefinito é 95%, ad esempio
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.
Le appliance di periferia sono collegate tramite linee dedicate e ridondano la relazione di parent tra le due cache principali, tra
loro collegate in modalità sibling (Cfr. capitolo sulle gerarchie di cache). Lo script di bilanciamento del carico è installato
presso due server WPAD che sono configurati in modalità round robin (Cfr. capitolo sul fail-over).
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.
Capitolo 10. Controlli di accesso

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

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

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
entriamo nello specifico visualizzando alcune delle impostazioni standard di Squid
acl all src 0.0.0.0/0.0.0.0

acl locallans src 192.168.0.0/255.255.255.0
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


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 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
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.
10.5.1. wb_group
Questo helper permette la verifica di appartenza di un utente ad un gruppo globale di un Dominio Windows NT 4 o Active
Directory. Deve essere utilizzato in concomitanza con gli helper di autenticazione Basic Winbindd e NTLM.
Per il suo corretto funzionamento necessita che Samba 2.2.4 (http://www.samba.org/) o seguenti siano installati sul nostro
sistema. Per i dettagli relativi alla configurazione di Samba, riferirisi alle susseguenti sezioni relative all'Autenticazione con
Samba 2.2.x e alla configurazione di Winbindd.
L'utilizzo di questo helper può semplificare in maniera notevole la gestione della configurazione di Squid e migliorarne le
prestazioni globali. Per spiegarci meglio, definiremo un caso di studio: supponiamo di aver 500 utenti censiti in un dominio NT
e che li si voglia suddividere in gruppi di restrizione relativamente all'accesso alla webcache. Utilizzando gli helper di
autenticazione è possibile agire in due modi:

● creare una ACL per ogni utente
● creare una ACL basata su un regex[25] che legge la lista degli utenti da un file
In entrambi i casi appare chiaro che incontreremmo un notevole impatto sulle prestazioni della nostra cache, in quanto ad ogni
auth-challenge, Squid dovrà verificare l'elenco delle access list, oppure confrontare tutta la lista degli utenti. Proprio per far
fronte a questa problematica ci viene in contro l'external helper wb_group che deve essere usato congiuntamente a
wb_ntlmauth. Ora creeremo dei gruppi d'utilizzo all'interno del dominio NT, per capirci meglio
● InternetFull, nessuna limitazione
● InternetNormal, Gli utenti possono solo navigare su determinati siti e non scaricare
● InternetToDow, i membri possono navigare in maniera filtrata e scaricaricare liberamente.
● InternetToNav, Gli utenti possono navigare senza limitazione ma non scaricare
A questo punto, sempre all'interno del dominio Windows NT, assegneremo gli utenti ai rispettivi gruppi. L'utilizzo del dominio
NT è ora piuttosto trasparente a Squid, infatti nel file di configurazione squid.conf è possibile utilizzare un autenticatore
qualsiasi, la scelta dello stesso non è più importante.
Definire il TAG external_acl
external_acl_type wb_group concurrency=5 ttl=900 %LOGIN \

/usr/squid/libexec/wb_group
Creeremo all'interno della directory $PREFIX/etc/ dei file, ciascuno di questi file deve contenere i nomi dei gruppi da
agganciare all'ACL. Per consentire una maggiore comprensione, si specifica anche che i files appena creati dovranno contenere
al loro interno il solo nome del gruppo. Esempio: Gruppo InternetFull - nel file /usr/squid/etc/internetfull ci deve essere scritto
unicamente "InternetFull"
Inseriremo ora, le ACL come segue:

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

Appare chiara la facilità con la quale si può ora amministrare grandi numeri di utenti compiendo pochi passi per eseguire la
configurazione. Per la configurazione di Samba e wb_ntlmauth, consultare il paragrafo relativo.
A partire dalla versione 1.20 dell'helper wb_group, sono disponibili le seguenti opzioni:
-c use case insensitive compare

-d enable debugging
-h this message
La modalità predefinita prevede che la comparazione sia case sensitive sui nomi dei gruppi, e quindi questi devono essere
specificati esattamente come nel dominio NT/2000. L'opzione -c attiva la modalità di comparazione case insensitive, ma,
utilizzando impostazioni locali di lingua differenti dall'inglese, il risultato potrebbe essere diverso dal previsto. Per dettagli
vedere le man pages di toupper, sezione BUGS.
L'opzione -d consente una diagnostica abbastanza chiara e precisa dei problemi. Al fine di controllare il corretto funzionamento
dell'helper wb_group, si consideri un utente di prova ed un gruppo di prova avviando l'helper wb_group come segue:
% /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
311576647-512
/wb_group[14984](wb_check_group.c:154): Windows group: Domain Admins, Squid group:
Gruppo
311576647-1510
/wb_group[14984](wb_check_group.c:154): Windows group: Gruppo, Squid group: Gruppo OK
10.5.2. Utilizzo di wbinfo_group con Samba 3
L'helper wbinfo_group, cosí come wb_group, consente il controllo delle autorizzazioni di accesso in base all'appartenzenza a
gruppi di dominio Windows NT/2000, ma é basato su di uno script perl che interagisce con l'utility Samba wbinfo, ció fa sí che
esso sia "neutro" rispetto alla versione di Samba installata sul sistema.
wbinfo_group necessita di Samba e di una versione recente di perl che includa il modulo di libreria shellwords.pl. In mancanza

di quest'ultimo, é possibile tentare di copiarlo da un altro sistema. Il suo utilizzo e le procedure di verifica di funzionamento
sono strettamete equivalenti a quelle di wb_group.
Quindi l'external_acl definita in precedenza per wb_group diventerà
external_acl_type wb_group concurrency=5 ttl=900 %LOGIN /usr/squid/libexec/

wbinfo_group
10.5.3. win32_check_group
L'helper win32_check_group, cosí come wb_group, consente il controllo delle autorizzazioni di accesso in base
all'appartenzenza a gruppi di dominio Windows NT/2000, ma riguarda esclusivamente la piattaforma Win32. Non necessita di
alcuna componente esterna in quanto si appoggia sulle API native del sistema operativo. win32_check_group può operare su
gruppi globali di dominio o gruppi locali di macchina. Il suo utilizzo e le procedure di verifica di funzionamento sono
strettamete equivalenti a quelle di wb_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
http_access allow password GProxyUsers
http_access allow password LProxyUsers
Nell'esempio precedente, tutti gli utenti NT validati appartenenti al gruppo globale di dominio GProxyUsers o al gruppo locale
di macchina LProxyUsers sono autorizzati ad utilizzare la cache. L'helper win32_check_group é utilizzabile solamente in
ambiente Windows nativo o Cygwin ed é disponibile nei relativi package Squid. Per questo helper sono disponibili le seguenti
opzioni:
-G start helper in Global Group mode

-c use case insensitive compare
-d enable debugging
-h this message
La modalità predefinita prevede che la comparazione sia case sensitive sui nomi dei gruppi, e quindi questi devono essere
specificati esattamente come nel dominio NT/2000. L'opzione -c attiva la modalità di comparazione case insensitive, ma,
utilizzando impostazioni locali di lingua differenti dall'inglese, il risultato potrebbe essere diverso dal previsto. Per dettagli
vedere le man pages di toupper, sezione BUGS.
L'opzione -d consente una diagnostica abbastanza chiara e precisa di eventuali problemi.

10.5.4. squid_ldap_group
Questo helper permette la verifica di appartenza di un utente ad un gruppo di una directory LDAP. Il programma opera
eseguendo delle ricerche tramite un search filter basato sul username dell'utente ed il gruppo richiesto, se viene trovato un
match, l'utente appartiene al gruppo cercato.
Nel seguito di questo paragrafo verranno trattati alcuni argomenti la cui comprensione é strettamente dipendente da una buona
conoscenza del protocollo LDAP, per maggiori dettagli al riguardo, riferirsi al sito del Progetto OpenLDAP.
Questo autenticatore consente l'interfacciamento con tutti i maggiori Directory Service attualmente disponibili
● Microsoft Active Directory
● Novell NDS
● Lotus Notes Directory
● Sun Java System Directory
esempio di configurazione
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
http_access allow password Gruppo1
in questo caso squid_ldap_group si trova in /usr/local/squid/libexec, e sono definite due acl relative ai gruppi LDAP Gruppo1 e
Gruppo2. L'helper squid_ldap_group é utilizzabile solamente sulle piattaforme supportate da Squid sui cui sono disponibili le
librerie OpenLDAP od un un altra C-API LDAP compatibile.
Sono disponibili le seguenti opzioni:
squid_ldap_group -b "base DN" -f "LDAP search filter"

[options] [ldap_server_name[:port]...|URI]
Le opzioni -b e -f devono essere sempre specificate. Per dettagli sulle opzioni si raccomanda di visionare la man page relativa a
squid_ldap_group fornita con Squid.
Attenzione: sono supportate al massimo 16 occorrenze di %s negli argomenti dell'opzione -u

10.5.5. squid_unix_group
Questo helper permette la verifica di appartenza di un utente ad un gruppo standard UNIX®/Linux. Il programma opera
eseguendo delle ricerche nel file /etc/group basate sullo username dell'utente ed il gruppo richiesto, un esempio di
configurazione
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
in questo caso squid_unix_group si trova in /usr/local/squid/libexec, e sono definite due ACL relative ai gruppi Linux Gruppo1
e Gruppo2. L'helper squid_unix_group é utilizzabile solamente sulle piattaforme supportate da Squid sui cui l'appartenza a
gruppi degli utenti é gestita tramite il file /etc/group. Sono disponibili le seguenti opzioni:
squid_unix_group [-g group1 -g group2 -g group3 ...] [-p]
L'opzione -g permette di indicare i gruppi da verificare sulla command line dell'helper, ma il suo utilizzo é sconsigliabile, in
quanto la definizione del gruppo da verificare direttamente tramite External ACL come in esempio é maggiormente flessibile.
L'opzione -p attiva il lookup anche nei riguardi del gruppo primario indicato in /etc/passwd. Per maggiori dettagli si
raccomanda di visionare la man page relativa a squid_unix_group fornita con Squid.
Attenzione: sono supportati al massimo 10 gruppi. Per aumentare tale valore é necessario modificare il define MAX_GROUP
nel codice sorgente e ricompilare l'helper.
10.5.6. ip_group_check
Questo helper permette di verificare la corrispondenza tra l'indirizzo IP del client su cui viene eseguito il Browser Internet e
l'utente utilizzato per l'autenticazione. Il programma può operare su singoli indirizzi IP o su intere subnet, é inoltre possibile
utilizzare come riferimento per la verifica dell'utente, gruppi standard UNIX®/Linux, in questo caso il programma esegue delle
ricerche nel file /etc/group basate sullo username dell'utente. Le impostazioni dell'helper devono essere inserite all'interno di un
apposito file di configurazione, vediamo un esempio di utilizzo:

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
http_access allow password restricted
in questo caso ip_user_check si trova in /usr/local/squid/libexec, il suo file di configurazione é /usr/local/squid/etc/

ip_user_check.conf ed é definita una ACL per eseguire la verifica di corrispondenza. L'helper ip_user_check é utilizzabile
solamente sulle piattaforme supportate da Squid sui cui l'appartenza a gruppi degli utenti é gestita tramite il file /etc/group.
Sono disponibili le seguenti opzioni:
ip_user_check -f <configuration_file>
L'opzione -f é obbligatoria e specifica il percorso del file di configurazione.
Il formato del file di configurazione é il seguente:
● Le linee che iniziano con il carattere # sono ignorate (commenti)
● Singolo utente:
ip[/mask] utente
● Utenti appartenenti ad un gruppo definito in /etc/group
ip[/mask] @gruppo
● Range IP vietato (nessun utente può usare la cache)
ip[/mask] NONE
● Range IP libero (qualunque utente può usare la cache)
ip[/mask] ALL

● Indirizzo IP e maschera devono essere specificati nel formato X.Y.Z.W
Il risultato della verifica si basa sulla logica di first match, é quindi necessario fare molta attenzione all'oridine in cui vengono
inserite le direttive. Esempio:
# 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.
10.6.1. Controlli di accesso e URL filtering
Con le ACL del tipo url_regex è possibile inserire un percorso per i files che contengono la lista delle parole chiave selezionate
che consentono di individuare il sito Web vietato che è stato richiesto dal client HTTP (netscape, mozilla, internet explorer....).
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"
ecco il TAG http_access, facciamo attenzione all'ordine dei dinieghi di accesso via http


http_access deny badlang
http_access deny entertain
http_access deny games
http_access deny pirate
Inseriti i blocchi ora è possibile definire le ACL relative agli host autorizzati. Per scaricare una lista aggiornata degli host è
necessario raggiungere la seguente URLs: http://www.squidblock.com/. Di seguito esaminiamo anche il formato dei files che
possono contenere la lista delle parole chiave che consentono di individuare i siti web
.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
altre liste di siti precompilate possono anche essere reperite
● Squid and web utilities alla URL http://web.onda.com.br/orso/ di Pedro Lineu Orso
● Squid Blocking Files alla URL http://members.lycos.co.uk/njadmin/ di Jasons Staudenmayer
10.6.2. Definire una lista di siti visitabili
In questo paragrafo tratteremo un modello di configurazione molto interessante ed anche molto semplice, è un dato di fatto più
dell'80% delle consultazioni sui siti web effettuate da parte degli utenti aziendali non riguardano assolutamente nessuno degli
argomenti connessi con gli scopi che si è prefissa l'organizzazione per la quale lavorano. Nell'esempio riportato con questo tipo
di configurazione restringeremo al massimo il campo di consultazione ai soli web-site che sono stati definiti come

"interessanti" ed "utili", gli esempi riportati possono essere validi in un'ambiente dove i bambini hanno libero accesso alle
risorse web
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
abbiamo definito delle ACL che in prima istanza frazionano la rete in due subnet distinte e poi definiscono delle liste in
formato regexp, il file regexp è un file di testo nel quale vengono dichiarate un'insieme di espressioni regolari. Di seguito
vengono applicate le ACL per definire questa specifica configurazione di Squid

http_access allow allowed_hosts
http_access allow consentiti
http_access deny nonconsentiti
http_access allow allowed_hosts1
http_access deny manager all
si evince che alla subnet dichiarata dalla ACL "allowed_hosts" (192.168.0.0/255.255.255.128) è consentito l'accesso a tutti i
siti web, mentre la subnet dichiarata dalla ACL "allowed_hosts1" (192.168.0.128/255.255.255.128) è consentito accedere alle
URL contenute nella lista di regexp che viene dichiarata dalla ACL "consentiti". Successivamente verranno bloccate tutte le
URL contenute nella lista di regexp definita con la ACL "nonconsentiti". Di seguito la lista /etc/squid/block/consentiti.txt
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
ancora di seguito la lista /etc/squid/block/nonconsentiti.txt
% more nonconsentiti.txt
.
la lista di regexp "nonconsentiti.txt" con l'esperessione "." blocca tutto il resto.
10.6.3. Raggiungere direttamente domini o siti predefiniti
E' possibile utilizzare le ACL per consentire agli utenti di raggiungere direttamente alcuni siti internet. Ad esempio, se
vogliamo che Squid consenta la connessione diretta con servers appartenenti al dominio cisco.com possiamo definire il
seguente TAG all'interno del file squid.conf
acl cisco dstdomain .cisco.com

always_direct allow cisco
10.6.4. Bloccare gli spyware
Controllando lo user-agent log potremmo incorrere in questo tipo di codice
Gator/5.0 Script FD6B41F906B248C3B5711814B3F375B8 2 0.00 Gator/5.0 Precision Time \
se vogliamo evitare che le macchine infettate degli utenti interroghino la nostra rete passando per squid potremmo aggiongere il
seguente TAG
acl gator browser Gator/5.0

Http_access deny gator
10.6.5. Bloccare web radio e TV
Controllando lo user-agent log potremmo incorrere in questo tipo di codice

Windows-Media-Player/9.00.00.3128
se vogliamo evitare che gli utenti utilizzino squid per vedere la TV o ascoltare la radio
acl WMP browser Windows-Media-Player/*

http_access deny WMP
10.6.6. Bloccare msn-messanger (Yahoo Messanger)
Tra gli elementi che compongono le ACL possiamo identificare un header del tipo content-type, inoltre possiamo identificare il
pattern inviato quale risposta ad una intestazione del tipo content-type. Gli elementi che compongono le ACL da utilizzare sono
il req_mime_type ed il rep_mime_type. Se vogliamo evitare l'utilizzo del msn-messanger dovremmo impostare le seguenti ACL
acl reqmsn req_mime_type -i âpplication/x-msn-messenger

acl repmsn rep_mime_type -i âpplication/x-msn-messenger
Il messanger msn viene identificato quindi dal tag application/x-msn-messenger, a questo punto dobbiamo solo applicare le
regole appena definite
http_access deny reqmsn

http_reply_access deny repmsn
10.6.7. No cache
E' possibile utilizzare Squid senza memorizzare le pagine visitate nella cache, il TAG no_cache infatti consentirà di eliminare il
caching degli oggetti
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 `ÀRP 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
Capitolo 11. Autenticazione degli utenti

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.2.1. Basic authentication
È lo schema di autenticazione standard supportato da tutti i Browser web come Netscape, Mozilla, Opera, Internet Explorer,
Konqueror, etc. Viene spesso indicato come "Clear Text Authentication" perchè prevede lo scambio di username e password
tra Browser e server, con una semplice codifica a base64, ovvero in chiaro, naturalmente questo tipo di autenticazione risulta
essere estremamente insicuro perchè le password vengono trasmesse attraverso la rete continuamente e un maleintenzionato
potrebbe osservare il traffico dei dati per ottenere la password che successivamente potrebbe utilizzare per vestire i panni
dell'utente leggittimo. Con questo tipo di autenticazione, l'utente deve esplicitamente inserire i dati di autenticazione all'inizio
di ogni nuova sessione.
11.2.2. NTLM authentication
È uno schema di autenticazione proprietario tipico dei prodotti Microsoft, nella cui terminologia è comunemente indicato come
"integrated authentication". lo schema NTLM è supportato dai browser web Microsoft Internet Explorer (a partire dalla
versione 3.02) e da Mozilla (a partire dalla versione 1.4) nonchè dai prodotti server Microsoft IIS (Internet Information Server),

Proxy Server 2.0 ed ISA Server. Per funzionare correttamente NTLM necessita di un Dominio Windows NT oppure delle
Active Directory di Windows 2000/2003. In ambienti Windows 2000/2003 opera indifferentemente in modalità mixed o nativa,
purchè in fase di installazione dell'Active Directory sia stata selezionata la compatibilità con i sistemi pre Windows 2000. Per
verificare se un Dominio Active Directory sia stato stato installato in modalità compatibile pre Windows 2000 é sufficiente
eseguire Active Directory Users and Computers e controllare se nel gruppo "Pre-Windows 2000 Compatible Access" situato
nel container built-in sia presente l'utente Everyone. Se non fosse presente, riferirsi all'articolo Q303973 (http://support.
microsoft.com/) della Knowledge Base Microsoft.
Lo schema di autenticazione NTLM è stato implementato anche con licenza GPL, queste versioni sono basate sul reverse
engineering del protocolo, le più note sono Squid 2.5 e mod_ntlm per Apache Web Server. Peculiarità di NTLM è l'esecuzione
della procedura di autenticazione in maniera assolutamente trasparente all'utente senza alcuna richiesta di username/password,
sfruttando le credenziali fornite durante l'autenticazione in un Dominio Windows NT o con le Active Directory di Windows
2000/3.
Grosso svantaggio di NTLM è quello di essere "Connection Oriented", ovvero peer to peer, ciò fa si che un server HTTP
operante con l'autenticazione NTLM non possa essere connesso tramite un Proxy Server, ma solamente in modalità "direct".
11.2.3. Digest authentication
È lo schema di autenticazione standard proposto come successore dello schema Basic, Digest authentication si propone di
superare i problemi legati allo scambio in chiaro dello username e della password tra browser web e server HTTP. Digest
utilizza un protocollo di tipo challenge/handshake per evitare la rivelazione della password quando la stessa viene immessa in
rete. Attualmente lo schema di autenticazione Digest è largamente inutilizzato, benchè sia supportato dalle ultime versioni di
Internet Explorer, Mozilla, Netscape ed Opera. Per maggiori dettagli sulla Digest authentication riferirsi alla RFC 2617 (http://
www.ietf.org/rfc/rfc2617.txt).
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
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.
Lo schema di autenticazione basic utilizza i seguenti parametri
auth_param basic program cmdline

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

Specifica il comando che avvia il programma utenticatore esterno. Tale programma legge una riga da stdin contenente
"username password" e risponde con "OK" o "ERR" in un loop senza fine. Come default, lo schema di autenticazione basic
non viene attivato, a meno che non venga specificato un programma che si occupa di eseguire l'autenticazione, ad esempio
auth_param basic program /usr/local/squid/libexec/ncsa_auth \

/usr/local/squid/etc/passwd
il TAG children numberofchildren
Indica quante istanze del programma di autenticazione devono essere eseguite contemporaneamente. Se viene configurato un
numero di autenticatori troppo basso, Squid potrebbe essere costretto ad attendere un autenticatore libero, rallentando la
navigazione. Il valore predefinito è 5
auth_param basic children 5
il TAG realm realmstring
Specifica il nome realm che viene fornito ai client per lo schema di autenticazione Basic, ovvero il testo che l'utente vedrà nella
dialog box di autenticazione proposta dal browser web. Il valore predefinito è "Squid proxy-caching web server"
auth_param basic realm Squid proxy-caching web server
il TAG credentialsttl timetolive
Specifica il tempo di vita (Time To Live o TTL) di una coppia username:password che viene validata esternamente. In altre
parole, quanto spesso un programma helper debba validare nuovamente le credenziali per un dato utente. Il valore predefinito é
due ore
auth_param basic credentialsttl 2 hours
è sempre possibile testare il corretto funzionamento di un helper per la Basic authentication semplicemente eseguendolo con la
stessa riga comandi specificata in squid.conf e verificando che, immettendo delle coppie username:password, si ottengano le
risposte "OK" o "ERR" previste.
Squid 2.4 supporta esclusivamente lo schema di autenticazione Basic ed utilizza i seguenti parametri

authenticate_program cmdline
authenticate_children numberofchildren
Il significato e la sintassi di queste direttive é analogo a quelle di Squid 2.5 che abbiamo trattato in precedenza
il TAG authenticate_program cmdline
Specifica il comando che avvia il programma utenticatore esterno. Questo programma legge una riga da stdin contenente
"username:password" e risponde con "OK" o "ERR" in un loop senza fine. Come default, lo schema di autenticazione basic
non viene attivato a meno che non sia specificato un programma che esegue l'autenticazione. Questo TAG equivale alla
direttiva di Squid 2.5 auth_param basic program cmdline, ad esempio
authenticate_program /usr/local/squid/libexec/ncsa_auth /usr/local/squid/etc/passwd
il TAG authenticate_children numberofchildren
navigazione. Questo TAG equivale alla direttiva di Squid 2.5 "auth_param basic children numberofchildren", il valore
predefinito è 5.
authenticate_children 5
Nel seguito di questo documento saranno trattati in dettaglio gli autenticatori relativi a Squid 2.5, si tenga presente che le
configurazioni indicate possono essere valide anche per Squid 2.4 sempre che si utilizzi la differente sintassi nelle direttive di
configurazione in squid.conf.
11.4.3. helper NCSA
É storicamente il primo authentication helper utilizzato in Squid. Utilizza un file di password sullo stile di NCSA httpd (o piú
recentemente Apache) per eseguire l'autenticazione con alcune varianti rispetto al formato originale
● Le linee che iniziano con '#' sono considerate un commento
● É possibile lasciare delle linee vuote
● Tutti i campi extra del file di password sono ignorati, ciò permette l'utilizzo diretto di un file di password Unix
ecco un esempio di configurazione

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

/usr/local/squid/etc/passwd
auth_param basic credentialsttl 30 minutes
In questo caso ncsa_auth si trova in /usr/local/squid/libexec, il file contenente le password é /usr/local/squid/etc/passwd, il

numero di helper in esecuzione é 10 ed il TTL dell'autenticazione é pari a 30 minuti. L'helper ncsa_auth é utilizzabile su tutte
le piattaforme supportate da Squid.
11.4.3.1. Generare il DB degli utenti
Il file contenente le userid e le password che verranno interpretate da ncsa_auth può essere generato utilizzando l'applicazione
htpasswd fornita come corredo standard del server web apache. Di seguito la corretta sintassi per la creazione del file /usr/local/
squid/etc/passwd
% htpasswd -c /usr/local/squid/etc/passwd stefano

New password:
Re-type new password:
Adding password for user stefano
Pedro Lineu Orso ha realizzato due ottimi strumenti per la gestione tramite interfaccia WEB del file di password: admuser e
chpasswd disponibili su http://web.onda.com.br/orso/.
11.4.4. helper PAM
Questo authentication helper consente a Squid l'utilizzo pratico di qualsiasi modulo PAM (Pluggable Authentication Module)
per validare un utente. I moduli PAM piú utilizzati sono Unix, Radius, Kerberos e SMB. Sono comunque disponibili molti altri
moduli meno noti presso varie fonti, ecco un esempio di configurazione
auth_param basic program /usr/local/squid/libexec/pam_auth

in questo caso pam_auth si trova in /usr/local/squid/libexec, il numero di helper in esecuzione é 5 ed il TTL dell'autenticazione
é pari a 45 minuti. L'helper pam_auth é utilizzabile solamente sulle piattaforme supportate da Squid che forniscono i servizi
PAM a livello di sistema. Il nome di default del servizio PAM utilizzato é squid. La configurazione del supporto PAM può
variare in funzione della piattaforma utilizzata, sono disponibili le seguenti opzioni

-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
Per maggiori dettagli riferirsi a pam(8), "PAM Systems Administrator Guide".
11.4.4.1. Red Hat Linux
Creare il file /etc/pam.d/squid utilizzando il comando
% touch /etc/pam.d/squid
Il file deve contenere le seguenti entry:
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
11.4.4.2. Unix Standard
Per utilizzare /etc/passwd standard modificare il file /etc/pam.conf
squid auth required /lib/security/pam_unix.so.1

squid account required /lib/security/pam_unix.so.1
si noti che alcuni moduli PAM, per esempio l'autenticazione tramite shadow password, necessitano che il programma sia
installato con privilegio di root suid per poter avere accesso al database delle password utente.
11.4.5. helper LDAP

L'helper squid_ldap_auth consente a Squid di connettersi ad un Directory Service LDAP per validare username e password.
Nel seguito di questo paragrafo verranno trattati alcuni argomenti la cui comprensione é strettamente dipendente da una buona
conoscenza del protocollo LDAP, per maggiori dettagli al riguardo, riferirsi al sito del progetto OpenLDAP (http://www.
openldap.org).
Il programma ha due modalità di funzionamento: nella modalità di funzionamento predefinita il DN (Distinguished Name)
dell'utente da validare é costruito utilizzando un DN base e l'attributo user. Nell'altra modalità di funzionamento, viene
utilizzato un filtro di ricerca per localizzare nella Directory un user DN valido rispetto al DN base. Questo autenticatore
consente l'interfacciamento con tutti i maggiori Directory Service attualmente disponibili
● Microsoft Active Directory
● Novell NDS
● Lotus Notes Directory
● Sun Java System Directory
ecco un esempio di configurazione
auth_param basic program /usr/local/squid/libexec/squid_ldap_auth -b \

dc=your,dc=domain
in questo caso squid_ldap_auth si trova in /usr/local/squid/libexec, il numero di helper in esecuzione é 5 ed il TTL

dell'autenticazione é pari a 30 minuti e il server LDAP si trova sulla macchina proxy. L'helper squid_ldap_auth é utilizzabile
solamente sulle piattaforme supportate da Squid sui cui sono disponibili le librerie OpenLDAP od un un altra C-API LDAP
compatibile. A riguardo dell'helper sono disponibili le seguenti opzioni
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]] ...
L'opzione -b deve essere sempre specificata. Per dettagli sulle opzioni si raccomanda di visionare la man page relativa a
squid_ldap_auth fornita con Squid.
11.4.5.1. Esempi di configurazione
Di seguito vengono proposti alcuni esempi di utilizzo di squid_ldap_auth.
Nel caso in cui la Directory utilizzi il layout definito dalla RFC 2307 (http://www.faqs.org/rfcs/rfc2307.html) con un singolo

dominio, é sufficiente specificare il nome del DN base sotto il quale si trovano gli utenti ed i server
squid_ldap_auth -b ou=people,dc=your,dc=domain ldapserver
se invece si utilizzano dei sottodomini, si rende necessario ricorrere ad un filtro per localizzare il DN dell'utente in quanto
questo non può essere ricostruito a partire dal DN base e dal login name
squid_ldap_auth -b dc=your,dc=domain -f uid=%s ldapserver
In modo simile, se si intende concedere l'accesso solo agli utenti che hanno un attributo specifico
squid_ldap_auth -b dc=your,dc=domain -f (&(uid=%s)(specialattribute=value))

ldapserver
nel caso in cui l'attributo user del DN dell'utente sia "cn" invece di "uid" e non si vogliano fare ricerche per identificare l'utente,
o nel caso di Active Directory, é possibile utilizzare qualcosa di simile
squid_ldap_auth -u cn -b cn=Users,dc=your,dc=domain ldapserver
nel caso in cui, volendo eseguire delle ricerche, la Directory non consenta ricerche di tipo anonimo, é possibile utilizzare le
opzioni -D e -w per specificare un DN utente e relativa password per connettersi alla Directory ed eseguire la ricerca, come nel
seguente esempio per Active Directory
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
11.4.6. helper Winbindd
L'helper wb_auth consente la validazione degli utenti su di un dominio Windows NT 4 o Windows 2000 Active Directory. Per
il suo corretto funzionamento necessita che Samba 2.2.4 (http://www.samba.org/) o seguenti siano installati sul sistema. Per i
dettagli relativi alla configurazione di Samba, riferirisi alle sezioni relative all'Autenticazione con Samba 2.2.x e alla
configurazione di Winbindd. Ecco un esempio di configurazione

auth_param basic program /usr/local/squid/libexec/wb_auth

In questo caso wb_auth si trova in /usr/local/squid/libexec, il numero di helper in esecuzione é 5 ed il TTL dell'autenticazione é
pari a 30 minuti. L'helper wb_auth é utilizzabile solamente sulle piattaforme supportate da Squid per cui é disponibile Samba
versione 2.2.4 o seguenti. Sono disponibili le seguenti opzioni:
-d enable debugging
-h this message
L'opzione -d consente una diagnostica abbastanza chiara e precisa dei problemi. Per controllare il funzionamento di winbindd,
é possibile utilizzare il tool wbinfo fornito con Samba.
Attenzione: wb_auth non funziona con Samba 3.x, è necessario riferirsi alla sezione dedicata a Samba 3 per ottenere maggiori
dettagli.
11.4.7. helper MSNT
Questo helper consente di verificare l'autenticazione degli utenti appartenenti a un dominio Windows NT 4 o Active Directory
Windows 2000/2003. Tale funzionalità é attualmente resa disponibile con prestazioni migliori dall'helper Winbind. Ecco un
auth_param basic program /usr/local/squid/libexec/msntauth

In questo caso msntauth si trova in /usr/local/squid/libexec, il numero di helper in esecuzione é 8 ed il TTL dell'autenticazione
é pari a 15 minuti. L'helper msntauth é utilizzabile solamente sulle piattaforme supportate da Squid su cui é possibile compilare
le librerie Samba su cui é basato (Samba non é comunque richiesto).
A partire dalla versione 2, msntauth utilizza un file di configurazione denominato msntauth.conf, la directory di default del file
msntauth.conf è /usr/local/squid/etc/msntauth.conf, il suo formato è il seguente:

#
# PDC BDC DOMAIN
# --------- ----------- -----------
server paperino pippo mio_dominio
#
denyusers /usr/local/squid/etc/denyusers
allowusers /usr/local/squid/etc/allowusers
nell'esempio di cui sopra paperino e pippo sono i nomi dei server che svolgono le funzioni di domain controller, mio_dominio è
il nome del dominio windows. Gli utenti non abilitati ad accedere alla rete internet possono essere indicati nel file identificato
dalla direttiva denyusers. Questo file contiene una lista di nomi utente per i quali non è richiesta una struttura particolare. Se il
file non esiste o è vuoto a nessun utente verrà applicata la negazione di accesso, il file deve essere leggibile dall'utente con cui
gira Squid, specificato dalla direttiva cache_effective_user in squid.conf. Gli utenti abilitati per accedere alla rete internet
vengono dichiarati nel file identificato dalla direttiva allowusers, questo file contiene una lista di utenti autorizzati la cui
compilazione non richiede una particolare struttura, se il file non esiste o è vuoto verrà comunque ignorato.
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.
Vediamo in questo paragrafo quali sono le necessità immediate alle quali risponde lo schema di autenticazione NTLM di Squid
● Implementare una gestione centralizzata degli utenti di tipo single-sign-on evitando particolari oneri gestionali per
l'amministratore della cache e semplificando le procedure di accesso ad internet degli utenti.
● Incrementare il livello di sicurezza evitando che transitino sulla rete password in chiaro
l'Autenticazione NTLM funziona esclusivamente con la versione 2.5 di Squid. Sino alla versione 2.5.STABLE4 viene
supportata soltanto la versione 1 del protocollo NTLM, a partire dalla versione 2.5.STABLE5 viene anche supportata la
versione 2 del protocollo NTLM grazie al nuovo supporto dei pacchetti del tipo NTLM NEGOTIATE. Si rammenta al lettore
che, se si intende utilizzare delle password o degli oggetti di lunghezza superiore a 14 caratteri, è necessario ricorrere ad un
helper che sia in grado di interpretare correttamente i pacchetti NTLM NEGOTIATE (NTLMv2) con la relativa funzionalità
abilitata in squid.conf. Lo schema di autenticazione NTLM utilizza i seguenti parametri

auth_param ntlm program cmdline

auth_param ntlm children numberofchildren
auth_param ntlm max_challenge_reuses number
auth_param ntlm max_challenge_lifetime timespan
auth_param ntlm use_ntlm_negotiate on|off
Specifica il comando che avvia il programma utenticatore esterno. Tale programma legge una riga da stdin contenente pacchetti
NTLM di tipo NEGOTIATE in formato uuencoded e risponde su stdout con pacchetti NTLM di tipo challenge/response in
formato uuencoded in un loop senza fine. Di default, lo schema di autenticazione NTLM non viene attivato, a meno che non sia
specificato un programma autenticatore. Ad esempio:
auth_param ntlm program /usr/local/squid/libexec/wb_ntlmauth
navigazione. Il valore predefinito è 5.
auth_param ntlm children 5
il TAG max_challenge_reuses number
Specifica il massimo numero di volte che un challenge fornito da un helper può essere riutilzzato. Il valore 0 implica che il
challenge può essere utilizzato una volta sola (caching disabilitato).
auth_param ntlm max_challenge_reuses 0
il TAG max_challenge_lifetime timespan
Specifica il massimo periodo di tempo per cui un challenge fornito da un helper può essere riutilzzato. L'effetivo periodo di
validità del challenge é dato dal minimo tra il numero di riutilizzi consentiti ed il tempo qui specificato.
auth_param ntlm max_challenge_lifetime 2 minutes
il TAG use_ntlm_negotiate

Abilita il supporto per lo scambio dei pacchetti NTLM NEGOTIATE con l'helper. L'helper NTLM configurato deve essere in
grado di gestire i pacchetti NTLM NEGOTIATE. In caso di dubbi riferirsi alla documentazione dell'helper. ntlm_auth fornito
con Samba 3.0.2 o seguenti supporta l'utilizzo di questa opzione. Per compatibilità con i vecchi helper e configurazioni
esistenti, il valore predefinito é off. Questa opzione é disponibile a partire dalla versione 2.5.STABLE5 di Squid.
auth_param ntlm use_ntlm_negotiate on
a differenza dello schema di autenticazione Basic, non é possibile testare il corretto funzionamento di un helper per la NTLM
authentication, in quanto le transazioni di autenticazione non sono di tipo unitario, ma prevedono delle sequenze di challenge/
response non simulabili tra il browser client e l'autenticatore.
11.5.2. Autenticazione NTLM nativa
Anche se non è corretto utilizzare il temine "autenticazione NTLM nativa", in quanto si tratta di un sistema di autenticazione
proprietario prodotto da Microsoft, in questo paragrafo tratteremo l'utilizzo degli helper NTLM che sono stati inclusi
nativamente nella distribuzione di Squid.2.5, questi helper non devono ricorrere al supporto di altre applicazioni esterne come
Samba.
11.5.2.1. helper SMB (ntlm_auth)
Questo helper permette di autenticare gli utenti tramite il protocollo NTLMv1 nell'ambito di uno o più Domain Controller per
uno o più domini Windows NT o in Active Directory, la configurazione è quanto mai semplice
auth_param ntlm program /usr/local/squid/libexec/ntlm_auth DOMINIO/SERVER DOMINIO/

SERVER
auth_param ntlm use_ntlm_negotiate off
in questo caso ntlm_auth si trova in /usr/local/squid/libexec, il numero di helper in esecuzione é 5, i challenge possono essere
riutilizzati due volte ed il loro TTL é pari a 15 minuti.
L'helper ntlm_auth può essere utilizzato unicamente sulle piattaforme supportate da Squid su cui é possibile compilare le
librerie Samba su cui é basato (Samba non é comunque richiesto), ntlm_auth non supporta i pacchetti NTLM NEGOTIATE e
quindi non è in grado di funzionare con il protocollo NTLMv2. La lunghezza massima delle password utilizzate dagli utenti non
può superare un numero massimo di 14 caratteri.
Riferendoci all'esempio di cui sopra, la macchina SERVER deve essere un Domain Controller e deve essere sicuramente
raggiungibile. In caso di incertezze si consiglia sempre di mettere una voce nel file /etc/hosts per identificare il corretto
percorso di rete dei sistemi Domain Controller. E' possibile specificare più di una macchina Domain Controller per ogni

Dominio, i Domain Controller possono anche appartenere a domini differenti ed è quindi possibile utilizzare Squid per eseguire
l'autenticazione in modalità trasparente per più di un dominio Windows NT/2000/2003.
Vediamo ora un esempio di autenticazione trasparente su più domini
auth_param ntlm program /usr/local/squid/libexec/ntlm_auth SEDE_01/SERVER1 SEDE_02/

SERVER2
in questo caso Squid autenticherà in maniera trasparente gli utenti del Dominio SEDE_01 e gli utenti del Dominio SEDE_02, i
due Domain Controller sono installati rispettivamente sulle macchine SERVER1 e SERVER2, per queste macchine avremo
inserito una voce che consenta di identificare il loro indirizzo internet nel file /etc/hosts
% more /etc/hosts
127.0.0.1 localhost.localdomain localhost
192.168.0.3 athlon.sede_00.net server0
192.168.0.5 dc.sede_01.net server1
192.168.0.7 dc.sede_02.net server2
l'helper ntlm_auth prevede le seguenti opzioni
-b enables load-balancing among controllers.

-f enables failover among controllers (DEPRECATED and always active).
-l changes behavior on domain controller failures to last-ditch.
-d enables debugging statements if DEBUG was defined at build-time.
L'opzione -d consente una diagnostica abbastanza chiara e precisa dei problemi
Questo helper presentava alcuni problemi che venivano erroneamente imputati alla non perfetta implementazione del protocolo
SMB e che provocavano delle saltuarie richieste di autenticazione da parte del Browser. A partire da Squid 2.5.STABLE5,
questo tipo di anomalia è stato finalmente eliminato, pertanto ntlm_auth può essere tranquillamente utilizzato nel caso in cui si
decidesse di utilizzare il protocollo NTLMv1 per autenticarsi in un dominio Windows NT o in un sistema Active Directory.
11.5.2.2. helper fakeauth & no_check
Questi helper non compiono alcuna validazione, ma si limitano ad eseguire una transazione NTLM di tipo challenge/response
senza eseguire alcuna validazione. Il loro utilizzo può rivelarsi particolarmente utile a scopo di debugging relativamente alla
componente NTLM di Squid o per casi particolari, casi nei quali si voglia eseguire solamente il logging degli utenti. I
riferimenti di configurazione per squid.conf sono i seguenti

auth_param ntlm program /usr/squid/libexec/fake_auth

In questo caso fake_auth si trova in /usr/local/squid/libexec, il numero di helper in esecuzione é 5, i challenge possono essere
riutilizzati 20 volte ed il loro TTL é pari a 15 minuti. Gli helper fake_auth e no_check sono utilizzabili su tutte le piattaforme
supportate da Squid, e NON supportano i pacchetti NTLM NEGOTIATE (NTLMv2).
11.5.2.3. helper Windows win32_ntlm_auth
L'helper win32_ntlm_auth riguarda esclusivamente Squid per la piattaforma Win32 e consente la validazione trasparente degli
utenti su di un dominio Windows NT 4 o Windows 2000 Active Directory. Inoltre é supportato in modo totalmente automatico
l'utilizzo dei pacchetti NTLM NEGOTIATE (NTLMv2). Non necessita di alcuna componente esterna in quanto si appoggia
sulle API native del sistema operativo
auth_param ntlm program c:/squid/libexec/win32_ntlm_auth.exe

In questo caso win32_ntlm_auth.exe si trova in c:/squid/libexec, il numero di helper in esecuzione é 5, i challenge non possono
essere riutilizzati, il supporto per i pacchetti NTLM NEGOTIATE é abilitato. L'helper win32_ntlm_auth é utilizzabile
solamente in ambiente Windows nativo o Cygwin ed é disponibile nei relativi package Squid. Per questo helper sono
disponibili le seguenti opzioni
-d enable debugging
-v enable verbose NTLM packet debugging.
-A specify a Windows Local Group name allowed to authenticate
-D specify a Windows Local Group name not allowed to authenticate
-h this message
Le opzioni -d e -v consentono una diagnostica abbastanza chiara e precisa di eventuali problemi. Le opzioni -A e -D consentono
di specificare un gruppo Windows LOCALE autorizzato o non autorizzato alla navigazione, si raccomanda l'utilizzo di ACL
esterne per ottenere una maggiore flessibilità.
11.5.3. Autenticazione NTLM con Samba 2.2.x

Vedremo di seguito come utilizzare il servizio Winbindd di Samba versione 2.2.x come supporto per l'autenticazione NTLM di
Squid 2.5.
11.5.3.1. Compilazione helpers
Per utilizzare gli helpers basati su Winbindd è necessario avere installato e correttamente configurato Samba 2.2.4 o seguenti,
Squid-2.5 utilizza un'interfaccia interna di Samba per la comunicazione con Winbindd, per questo motivo il suo funzionamento
può essere influenzato da modifiche a tale interfaccia da parte del team di sviluppo di Samba. Squid-2.5.STABLE2 supporta
Samba 2.2.6 e Samba 2.2.7a e forse anche le versioni seguenti. Per utilizzare le versioni precedenti di Samba è necessario
utilizzare la nuova opzione di compilazione
% ./configure --with-samba-sources=path
questa opzione è necessaria per indicare il percorso contenente i sorgenti di Samba, ad esempio
% ./configure --with-samba-sources=/usr/src/samba-2.2.8
l'utilizzo di tale opzione potrebbe anche rendersi necessario per le future versioni di Samba o in caso di applicazione di patch ai
suoi sorgenti. Squid-2.5.STABLE1 supporta Samba 2.2.4 e Samba 2.2.5, per le versioni di Samba a partire dalla 2.2.6 e
seguenti è necessario sostituire, prima della compilazione di Squid, gli include winbind_nss.h e winbindd_nss_config.h presenti
nel source tree di Squid con quelli del source tree di Samba.
11.5.3.2. Configurazione di Samba2
Come detto precedentemente, per utilizzare l'autenticazione Winbindd è necessario installare Samba, versione 2.2.4 o seguenti,
e configuralo in modo opportuno. Alcune linee guida per una corretta installazione possono essere le seguenti. In fase di
compilazione, eseguendo il ./configure di Samba, inserire le seguenti opzioni:
% ./configure --with-winbind --with-winbind-auth-challenge
nella grande maggioranza delle distribuzioni GNU Linux, la versione binaria di Samba che viene fornita é compilata senza
l'opzione --with-winbind-auth-challenge, si raccomanda quindi la ricompilazione ad hoc per la propria installazione e si
consiglia anche di non utilizzare la versione fornita a corredo della propria distribuzione.
Dopo avere compilato il demone, dovremo integrare il file smb.conf le seguenti direttive (si prega di confrontare la
documentazione di samba per maggiori informazioni)

;******************* section global *****************

[global]
password server = *
wins server = 192.168.5.1 192.168.0.1
security = domain
encrypt passwords = Yes
workgroup = DOMINIO
;******************* winbindd ***********************
winbind separator = \ template
homedir = /home/%D/%U template
shell = /bin/bash
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
sarà quindi necessario inserire il server Samba nel dominio come "member" con il comando smbpasswd(8)
% smbpasswd -j DOM -r DOMPDC -UAdministrator%password
l'opzione -j viene utilizzata per aggiungere il server samba nel dominio NT quale membro del dominio, il valore DOM è il
nome del dominio al quale si vuole aggiugere la macchina samba. Grazie a questa opzione, il nostro server samba sarà in grado
di eseguire l'autenticazione degli utenti verso uno qualsiasi dei domain controller così come potrebbe operare uno qualsiasi dei
server Windows NT, 2000 e 2003. L'opzione -r invece, indica il nome della macchina remota ovvero il nome netbios del server
SMB/CIFS da contattare per inserire il nostro server samba nel dominio. Il valore DOMPDC equivale quindi al nome netbios
del domain controller. Assicurarsi che i demoni Samba (http://www.samba.org/) smbd, nmbd e winbindd siano stati avviati
automaticamente con il boot del sistema, prima dell'avvio di Squid. Maggiori dettagli sul comando smbpasswd(8) possono
essere reperiti alla URLs http://us1.samba.org/samba/ftp/docs/htmldocs/smbpasswd.8.html.
Se Samba viene utilizzato sulla macchina solamente per il supporto winbindd, a partire dalla versione 2.2.6 di Samba é anche
possibile non eseguire il demone smbd. É però INDISPENSABILE eseguire un rinnovo periodico della relazione di trust tra la
macchina Samba ed il dominio Windows. Per fare ciò, nel caso in cui non si esegua smbd, é sufficiente schedulare il seguente
comando una volta al giorno
% smbpasswd -t DOM -r DOMPDC
ecco una entry da inserire nella tabella di crontab(8)
02 4 * * * root /usr/bin/smbpasswd -t DOM -r DOMPDC
questa linea inserita nella tabella di crontab ci consentira di eseguire il comando smbpasswd(8) una volta al giorno e rinnovare

la relazione di trust tra la macchina UNIX® e il server Windows NT/2000, dove DOM è il nome di dominio e DOMPDC è il
nome netbios del Domain Controller.
11.5.3.3. helper wb_ntlmauth
L'helper wb_ntlmauth consente la validazione trasparente degli utenti su di un dominio Windows NT 4 o Windows 2000 Active
Directory. Per il suo corretto funzionamento necessita che Samba 2.2.4 o seguenti siano installati sul sistema. Di seguito
vediamo un esempio di configurazione:
auth_param ntlm program /usr/squid/libexec/wb_ntlmauth [domain]

In questo caso wb_ntlmauth si trova in /usr/local/squid/libexec, il numero di helper in esecuzione é 5, i challenge non possono
essere riutilizzati ed il loro TTL é pari a 15 minuti. È possibile specificare il dominio predefinito per l'autenticazione sulla riga
comandi dell'helper.
Naturalmente almeno un domain controller del dominio deve essere raggiungibile, si consiglia di verificare il corretto
funzionamento della risoluzione dei nomi di rete Microsoft (WINS, LMHOSTS o hosts).
L'helper wb_ntlmauth é utilizzabile solamente sulle piattaforme supportate da Squid per cui é disponibile anche Samba 2.2.4 o
seguenti, e NON supporta i pacchetti NTLM NEGOTIATE. In merito all'utilizzo di Samba si rammenta al lettore che devono
essere in esecuzione almeno i demoni winbindd e nmbd. Per questo helper sono disponibili le seguenti opzioni
-d enable debugging
-h this message
L'opzione -d consente una diagnostica abbastanza chiara e precisa dei problemi. Per controllare il funzionamento di winbindd, é
possibile utilizzare il tool wbinfo fornito con Samba. wb_ntlmauth non funziona con Samba 3.x, riferirsi alla sezione su Samba
3 per maggiori dettagli.
11.5.4. Autenticazione NTLM con Samba3
Gli helpers basati su winbindd 2.2.x soffrono di un problema di compatibilità tra le varie versioni di samba, in quanto
l'interfaccia software di winbindd non é mai stata standardizzata dal gruppo di sviluppo di Samba. Per ovviare a questo
problema, si é instaurata una collaborazione tra i gruppi di sviluppo di samba e di Squid, che ha portato alla realizzazione di un
autenticatore NTLM per Squid, ntlm_auth, basato sulle caratteristiche di winbindd 3 che viene incluso direttamente nel
package Samba3. Gli autenticatori wb_ntlmauth, wb_auth e wb_group basati su winbindd 2.2 inclusi in Squid non funzionano
con Samba 3

11.5.4.1. helper esterno Samba 3.x ntlm_auth
Questo autenticatore é in grado di operare in modalitá basic e ntlm. Inoltre a partire da Samba 3.0.2 é supportato in modo
totalmente automatico l'utilizzo dei pacchetti NTLM NEGOTIATE (NTLMv2). Assumendo che Samba sia installato in /usr/
local/samba, i parametri da utilizzare in squid.conf diventano
auth_param ntlm program /usr/local/samba/bin/ntlm_auth --helper-protocol=squid-2.5-

ntlmssp
auth_param basic program /usr/local/samba/bin/ntlm_auth --helper-protocol=squid-2.5-
basic
auth_param basic credentialsttl 2 hours
la precedente configurazione consente di sostituire gli autenticatori wb_auth e wb_ntlmauth abilitando il supporto per i
pacchetti NTLM NEGOTIATE. Come accadeva già per Samba 2, anche Samba 3 deve essere compilato con questa opzione
di ./configure
% ./configure --with-winbind
11.5.4.2. Inserire nel dominio la macchina Samba 3.0
Dopo l'installazione di Samba 3, é necessario inserire la macchina in un dominio Windows NT 4 o Active Directory, la
procedura da utilizzare varia a seconda del tipo di dominio.
● Dominio Windows NT 4
La configurazione da utilizzare in smb.conf é identica a quella utilizzata con Samba 2, con la differenza che le
funzionalità del comando smbpasswd sono state incluse nel comando net(8) di Samba 3 (http://www.samba.org/samba/
docs/man/net.8.html). L'utility net inclusa con Samba 3 lavora in maniera simile al comando net del DOS[26] e di
Windows. Il comando per inserire la macchina samba in dominio Windows NT diventa quindi
% net join -S DOMPDC -UAdministrator%password
con l'opzione -S si indica il nome netbios del server di destinazione o il relativo indirizzo IP, nell'esempio DOMPDC è il
nome netbios del domain controller

● Dominio Active Directory (Samba 3 deve essere compilato con support Kerberos)
Inserire nel file smb.conf le seguenti direttive:
realm = your.kerberos.REALM
security = ADS
encrypt passwords = yes
nel caso in cui Samba non riesca ad identificare il server ADS tramite il REALM
password server = your.kerberos.server
inserire la macchina Samba 3 in dominio con il comando net(8)
% net ads join -U Administrator%password
l'opzione ads viene utilizzata per identificare le ActiveDirectory, l'opzione rap viene invece utilizzata per le macchine
NT3 oppure Windows9x, per finire l'opzione rpc può essere utilizzata per le macchine NT4 o Windows 2000, se
l'argomento viene omesso il comando net(8) tenterà di determinare automaticamente il tipo di sistema.
Si raccomanda di riferirsi alla documentazione della versione di Samba 3 utilizzata per verificare la corretta procedura da
seguire in funzione dell'implementazione Kerberos utilizzata sul sistema. Infine, per consentire agli helper Samba 3 di lavorare
correttamente con Squid è necessario fare in modo che il gruppo specificato nella direttiva cache_effective_group di squid.conf
abbia i permessi di lettura sulla directory winbindd_privileged in cui si trova la pipe di winbindd, quindi nel caso in cui il
gruppo utilizzato da squid sia ad esempio nogroup:
% chgrp nogroup /dove/sta/samba/winbindd_privileged

% chmod 750 /dove/sta/samba/winbindd_privileged
Il risultato di un ls -la /dove/sta/samba/winbindd_pipe/pipe dovrebbe essere:
srwxrwxrwx 1 root root 0 Aug 14 22:50 pipe
anche con Samba 3, se viene utilizzato sulla macchina solamente il supporto winbindd é possibile non eseguire il demone
smbd. Anche in questo caso é però INDISPENSABILE eseguire un rinnovo periodico della relazione di trust tra la macchina
Samba ed il dominio Windows. Per fare ciò, nel caso in cui non si esegua smbd, é sufficiente schedulare il seguente comando
una volta al giorno

% net rpc changetrustpw
le possibilità sono [rpc|ads] CHANGETRUSTPW per forzare il rinnovo della relazione di trust, ecco una entry da inserire nella
tabella di crontab(8)
02 4 * * * root /usr/bin/net rpc changetrustpw
questa linea inserita nella tabella di crontab ci consentira di eseguire il comando net(8) una volta al giorno e rinnovare la
relazione di trust tra la macchina UNIX® e il server Windows NT4/2000.
11.5.5. Problemi comuni con NTLM
La modalità di funzionamento connection oriented propria di NTLM, il fatto che non tutti gli user agent supportino il sistema di
autenticazione NTLM, nonchè particolari configurazioni relative al dominio Windows di appartenenza, possono provocare dei
problemi di utilizzo anche piuttosto fastidiosi in presenza del sistema di autenticazione NTLM. Vediamo ora alcuni dei
problemi più comuni che possono presentarsi con NTLM.
11.5.5.1. Java runtime
Navigando su siti che utilizzano applet Java, il JRE richiede di continuo l'autenticazione all'utente. Ciò accade perché il
browser non é in grado di condividere l'autenticazione della connessione con la Java Virtual Machine
● soluzione: consentire nelle ACL il traffico Java non autenticato
acl java_jvm browser Java/1.4

http_access allow java_jvm
11.5.5.2. ftp
Navigando su siti ftp con URL del tipo ftp://ftp.miosito.com, a volte può succedere che il browser richieda l'autenticazione per
accedere agli oggetti icona FTP di Squid. Questo é dovuto ad un problema nel riconoscimento dei siti Internet/Intranet da parte
di alcune versioni recenti di Internet Explorer
● soluzione: consentire nelle ACL l'accesso non autenticato agli oggetti interni di Squid

acl internal_icons urlpath_regex -i /squid-internal-static/icons/

http_access allow internal_icons
11.5.5.3. Windows Update V5 (Windows XP-SP2)
Che cosa simpatica: il Windows Update V5 che è stato incluso con il SP2 di Windows XP sembra bloccarsi sempre con il
sistema di autenticazione NTLM sia nativa che quella con Samba. Ancora non siamo in grado di spiegare le cause di questo
fastidioso problema
● soluzione: consentire nelle ACL l'accesso non autenticato alle URLs di Windows Update
acl wu dstdomain .windowsupdate.com .microsoft.com .windows.com .public-trust.com

http_access allow wu
se vogliamo proprio essere pignoli possiamo analizzare il file di log dello user-agent per verificare i seguenti client utilizzati da
Windows Update V5
172.31.128.128 [19/Sep/2004:21:12:06 +0200] "Windows Update Control"

172.31.128.128 [19/Sep/2004:21:12:52 +0200] "Microsoft WU Client/2.0"
172.31.128.128 [19/Sep/2004:21:15:28 +0200] "Microsoft BITS/6.6"
● soluzione affinata: consentire nelle ACL l'accesso non autenticato per determinati user-agent la cui destinazione non
può essere diversa da quella che viene definita dalla ACL wu
acl wuagent browser "Windows Update Control"

acl wuagent browser "Microsoft WU Client/2.0"
acl wuagent browser "Microsoft BITS/6.6"
acl wuagent browser "Industry Update Control"
acl wu dstdomain .microsoft.com .windowsupdate.com .windows.com .public-trust.com
http_access allow wuagent wu
l'ultimo TAG deve essere posizionato prima della direttiva http_access relativa alla autenticazione
11.5.5.4. Windows 2003
É impossibile navigare utilizzando una macchina Windows 2003. Ciò accade in quanto in Windows 2003 l'utilizzo del
protocollo LM/NTLM é disabilitato per default e le versione di Squid precedenti la 2.5.STABLE5 non supportano la funzione
di NTLM NEGOTIATE

● soluzione: utilizzare squid 2.5.STABLE5 con ntlm_auth di Samba 3.0.2 o seguenti abilitando il supporto NTLM
NEGOTIATE
● soluzione: attivare il supporto LM/NTLM in Windows 2003
per abilitare il supporto LM/NTLM in Windows 2003 server è necessario aprire il tool "Machine Local Security Policy", nelle
opzioni di sicurezza, modificare la voce "Network Security: LAN Manager Authentication Level" da "Send NTLM response
only" a "Send LM & NTLM responses".
11.5.5.5. Utenti non autenticati
Utilizzando NTLM può accadere che alcuni utenti non vengano autenticati in modo sistematico, e Samba restituisce l'errore
NT_STATUS_INVALID_WORKSTATION. Questo avviene perché l'utente é autorizzato a fare la logon su un numero
ristretto di workstation, ma non sul Proxy Server.
● soluzione: aggiungere il Proxy Server all'elenco delle macchine autorizzate nelle proprietà dell'utente Windows
● soluzione: utilizzare squid.2.5-STABLE5 con ntlm_auth di Samba 3.0.2 abilitando il supporto NTLM NEGOTIATE
11.6. Digest Authentication

l'Autenticazione Digest funziona esclusivamente con la versione 2.5 di Squid
Lo schema di autenticazione Digest utilizza i seguenti parametri
auth_param digest program cmdline

auth_param digest children numberofchildren
auth_param digest realm realmstring
auth_param digest nonce_garbage_interval timeinterval
auth_param digest nonce_max_duration timeinterval
auth_param digest nonce_max_count number
auth_param digest nonce_strictness on|off
auth_param digest post_workaround on|off
Specifica il comando che avvia il programma utenticatore esterno. Tale programma legge una riga da stdin contenente
"username":"realm" e risponde su stdout con un appropriato valore H(A1) codificato base64 in un loop senza fine. Riferirsi alla

RFC 2616 (http://www.faqs.org/rfcs/rfc2616.html) per la definizione di H(A1).
Di default, lo schema di autenticazione Digest non viene attivato a meno che non sia specificato un programma autenticatore.
Ad esempio:
auth_param digest program /usr/local/squid/libexec/digest_pw_auth /usr/local/squid/

etc/digpass
navigazione. Il valore predefinito è 5, quando l'elaborazione di H(A1) avviene tramite rete, può essere raccomandabile
aumentare questo valore.
auth_param digest children 5
il TAG realm realmstring
Specifica il nome realm che viene fornito ai client per lo schema di autenticazione Digest (Il testo che l'utente vedrà nella
dialog box di autenticazione del browser). Il valore predefinito è "Squid proxy-caching web server".
auth_param digest realm Squid proxy-caching web server
il TAG nonce_garbage_interval timeinterval
specifica ogni quanto tempo viene verificata la validità dei nonce assegnati ai client Il valore predefinito é 5 minuti.
auth_param digest nonce_garbage_interval 5 minutes
il TAG nonce_max_duration timeinterval
specifica la durata massima della validità di un dato nonce. Il valore predefinito é 30 minuti.
auth_param digest nonce_max_duration 30 minutes
il TAG nonce_max_count number

specifica il massimo numero di volte che un dato nonce può essere riutilizzato. Il valore predefinito é 50.
auth_param digest nonce_max_count 50
il TAG nonce_strictness on|off
determina se Squid richiede incrementi del nonce count esattamente di uno o se invece accetta incrementi generici (off), per
quei useragent che generano dei nonce count che incrementano casualmente di un valore superiore all'unità (Per esempio
1,2,4,6). Il valore predefinito é off.
auth_param digest nonce_strictness off
il TAG check_nonce_count on|off
disabilita totalmente il nonce count check come workaround ad alcune implementazioni anomale di digest qop in alcuni
browser. Il valore predefinito é on, ovvero verificare il nonce count per evitare attacchi di tipo authentication replay.
auth_param digest check_nonce_count on
il TAG post_workaround on|off
questo é un workaround per un bug presente in alcuni browser che inviano una richiesta incorretta di digest durante
un'operazione di POST basata su un nonce di una precedente operazione di GET. Questa funzione é normalmente disattiva.
auth_param digest post_workaround off
11.6.1.1. helper digest_pw_auth
É attualmente l'unico autenticatore disponibile per lo schema di autenticazione Digest, viene tendenzialmente fornito come
riferimento per nuove implementazioni. Come back-end viene utilizzato un file il cui formato prevede linee del tipo "username:
password".
● Le linee che iniziano con '#' sono considerate un commento
● É possibile lasciare delle linee vuote

auth_param digest program /usr/local/squid/libexec/digest_pw_auth /usr/local/squid/

etc/digpass
auth_param digest children 10
auth_param digest realm Squid proxy-caching web server
auth_param digest nonce_garbage_interval 5 minutes
auth_param digest nonce_max_duration 30 minutes
auth_param digest nonce_max_count 25
auth_param digest check_nonce_count on
In questo caso digest_pw_auth si trova in /usr/local/squid/libexec, il file contenente le password é /usr/local/squid/etc/digpass,

il numero di helper in esecuzione é 10, il garbage dei nonce avviene ogni 5 minuti, la loro durata é di 30 minuti con 25 riutilizzi
massimi ed il TTL dell'autenticazione é pari a 30 minuti.
L'helper digest_pw_auth é utilizzabile su tutte le piattaforme supportate da Squid.
Capitolo 12. Avviare Squid

12.1. Preambolo
In questo capitolo analizziamo nel dettaglio come avviare il Proxy Server Squid utilizzando la shell, inoltre terremo anche
conto del diverso funzionamento dei vari Sistemi Operativi che supportano Squid.
Nei sistemi UNIX® è fondamentale l'utente che esegue il processo, nel capitolo configurare ed installare Squid abbiamo già
visto che è possibile eseguire Squid utilizzando un utente ed un gruppo specifico. Quando il proxy server viene avviato, grazie
ai TAG cache_effective_user e cache_effective_group che sono contenuti nel file squid.conf, è possibile modificare
l'identificativo UID e GID che esegue il processo Squid. Il cambiamento della userid e del gruppo riduce la possibilità che il
sistema possa essere modificato a causa di un exploit dovuto ad un improbabile bug di Squid. Questo cambiamento di UID e di
GID è molto importante perchè l'utente utilizzato per eseguire il processo Squid non è comunque abilitato ad ottenere i
permessi amministrativi riservati all'utente root.
Le modalità di avvio del demone Squid possono variare sensibilmente a secondo dell'utilizzo di una versione di Squid
compilata dai sorgenti ufficiali o di una versione di Squid fornita con una qualsiasi distribuzione UNIX®.
12.2. Istruzioni multipiattaforma

Al termine della compilazione e dell'installazione di Squid siamo obbligati a seguire alcune indicazioni di massima
12.2.1. Controllare il file di configurazione
Si rende necessario verificare la sintassi del file di configurazione squid.conf avviando Squid con il comando squid -k parse

% squid -k parse
se non riceviamo alcun messaggio di errore, il file di configurazione è valido e potremmo procedere con il passo successivo. Se
il file di configurazione dovesse contenere un errore riceveremo un messaggio di avviso di questo genere
% squid -k parse
2004/09/21 22:31:31| squid.conf line 1832: http_access allow paperino
2004/09/21 22:31:31| aclParseAccessLine: ACL name 'paperino' not found.
2004/09/21 22:31:31| squid.conf line 1832: http_access allow paperino
2004/09/21 22:31:31| aclParseAccessLine: Access line contains no ACL's, skipping
la direttiva http_access contenuta nella linea 1832 di squid.conf si riferisce ad una ACL che non esiste, dovremmo intervenire
sul file di configurazione per correggere l'errore. Posto rimedio eseguiremo nuovamente il comando squid -k parse per
verificare se il problema è stato veramente risolto, il comando deve essere eseguito ogni volta che modificheremo il file di
configurazione.
12.2.2. Prepariamo lo spazio dedicato alla cache
Il passo successivo sarà quello di creare gli oggetti che comporranno la cache utilizzando il comando squid -z
% squid -z
2004/01/25 15:58:06| Creating Swap Directories
con questo comando genereremo il Disk Storage, ovvero lo spazio dedicato alla cache. Il comando deve essere utilizzato in
ogni caso prima di avviare il Proxy Server. Se eseguendo questo comando si dovesse ricevere un messaggio di errore
% squid -z
2004/01/25 15:58:06| Creating Swap Directories
FATAL: Failed to make swap directory /usr/local/squid/var/cache/00:
(13) Permission denied
dovremmo controllare che all'interno del file squid.conf siano stati correttamente abilitati i TAG cache_effective_user e
cache_effective_group. Inoltre verificheremo i permessi assegnati alla directory di cache definita con il TAG cache_dir, i
permessi dovranno essere Group ID (GID) e User ID (UID) così come definito nella direttiva cache_effective_user e
cache_effective_group.

% ls -l /usr/local/squid/var/
totale 8
drwxr-xr-x 18 nobody nobody 4096 21 set 19:48 cache
drwxr-xr-x 2 nobody nobody 4096 21 set 19:48 logs
ovviamente nel file squid.conf troveremo
% more /usr/local/squid/etc/squid.conf | grep nobody

# change to UID to nobody. If you define cache_effective_user,
12.2.3. Avviare Squid manualmente
solo dopo aver creato le directory dedicate al Disk Storage consigliamo di eseguire Squid in modalità debugging per capire se il
processo funziona correttamente. Avviamo Squid utilizzando l'istruzione squid -N -d 1 -D, questo comando inizializza Squid
senza farlo divenire un demone di background
% squid -N -d1
2004/03/06 12:02:35| Starting Squid Cache version 2.5.STABLE4 for i386-portbld-
freebsd4.9...
2004/03/06 12:02:35| Process ID 68005
2004/03/06 12:02:35| With 3584 file descriptors available
2004/03/06 12:02:35| DNS Socket created at 0.0.0.0, port 1718, FD 4
l'opzione -N avvia Squid come precesso di foreground mentre l'opzione -d1 consente di visualizzare il codice di debug al
livello 1. Digitando la sequenza di tasti [Ctrl+Z] potremo bloccare il processo Squid.
12.2.4. Avviamo Squid come processo
Dopo aver risolto tutti i possibili problemi potremmo finalmente avviare ed utilizzare il proxy server in modalità daemon, il
sistema più veloce per eseguire Squid
% squid -s
l'opzione -s consente a Squid di registrare i messaggi di errore e di stato verso il demone syslogd(8). Squid utilizza come
priorità la facility LOCAL4. Questo è il comando che consentirà di avviare il proxy server in condizioni di lavoro generiche.

12.3. Avviare Squid automaticamente con il boot del sistema

Il processo di avviamento di un computer, qualunque sia il tipo di architettura adottato, prende il nome di processo di boot (cfr.
Jargon file), durante questo processo viene caricato ed eseguito nella memoria del computer il Kernel del Sistema Operativo
che consente di configurare e inizializzare i vari dispositivi hardware creando tutti processi di Sistema. Prima che il Sistema
Operativo stesso venga avviato completamente, si devono anche verificare una serie di eventi molto importanti, tra questi
possiamo senzadubbio citare il processo di mount dei file system ed il contestuale avviamento dei demoni o servizi di sistema.
Tutti questi eventi vengono eseguiti da una serie di script che prendono il nome di script di init del Sistema Operativo e
compongono il processo di init di Sistema. I sistemi UNIX® prevedono diversi sistemi di script di avvio
● script di avvio in stile System V
il sistema di init di System V prevede ben sette livelli di esecuzione o run level, ogni run level rappresenta un particolare
insieme di servizi
❍ livello 0 è il sistema in shutdown
❍ livello 1 è la modalità monoutente
❍ i livelli dal 2 al 5 invece definiscono i diversi strati di multiutenza
❍ livello 6 è il livello di riavvio (reboot) del sistema
il file /etc/inittab comunica al processo di init quale run level si debba inizializzare all'avviamento del Sistema
Operativo, le copie originali degli script di init risiedono in una directory speciale chiamata init.d, questa directory è
solitamente situata in /etc, ogni script è responsabile di un servizio specifico ed ogni script riconosce gli argomenti start
e stop. Nel momento in cui init cerca di avviare un run level, inizia a ricercare gli script di avviamento nelle directory rc
[0-6].d dove 0-6 è lo specifico livello run level. Le directory rc[0-6].d contengono dei link simbolici che puntano agli
script di init veri e propri, il nome di questi link simbolici inizia sempre con le lettere S o K che sono sempre seguite da
un numero o dal nome dello script che controlla il tipo di servizio.
● script di init in stile BSD
FreeBSD come molti altri sistemi BSD, esegue un solo script all'avviamento del sistema, in particolare legge il file /etc/
rc che a sua volta richiama altri tre scripts. Si tratta dei files /etc/defaults/rc.conf, /etc/rc.conf e /etc/rc.conf.local
/etc/defaults/rc.conf
è il file che elenca tutti i parametri di configurazione di FreeBSD, notoriamente e per ragioni di sicurezza non avvia
alcun servizio
/etc/rc.conf

questo file sovrascrive i parametri di configurazione del file /etc/defaults/rc.conf, effettivamente è questo il file che
definisce se avviare o meno i servizi di sistema
/etc/rc.conf.local
questo file riguarda principalmente le configurazioni locali, anche questo script si occupa di sovrascrivere i parametri di
configurazione del file /etc/defaults/rc.conf
Tutti i sistemi UNIX® prevedono almeno due tipi di avviamento
● l'avviamento automatico (multiutenza)
che prevede l'avviamento ed il caricamento del Kernel di sistema, individua e configura l'hardware, crea i processi di
sistema, esegue gli script di avviamento (init) e procede con l'avviamento in multiutenza
● l'avviamento manuale (single user mode)
che prevede l'avviamento ed il caricamento del Kernel di sistema, individia e configura l'hardware, crea i processi di
sistema e cede il controllo del Sistema all'utente
Nei sistemi UNIX® è quindi possibile avviare Squid automaticamente con la partenza del Sistema Operativo utilizzando uno
script generico del tipo init.d. Il file che abbiamo inserito nello spazio contrib dovrebbe essere compatibile con la maggior parte
dei sistemi UNIX® che utilizzano lo schema di avviamento init.d.
12.3.1. Avviare Squid utilizzando la tabella di inittab
Molti sistemi UNIX® come Digital Unix, Solaris, IRIX, HP-UX ed alcune distribuzioni GNU Linux, prevedono la presenza
del file /etc/inittab. Il file inittab descrive quali processi vengono avviati con l'avvio del sistema e durante le normali
operazioni. Init distingue tra diversi runlevel, ognuno dei quali può avere il suo insieme di processi da avviare. I runlevel validi
sono 0-6 e A, B e C per le voci ondemand. Una voce nel file inittab ha il seguente formato
id:runlevel:azione:processo
In questo file possiamo quindi inserire alcune linee per consentire l'avvio automatico con di Squid con il Sistema Operativo
sq:2550:once:/usr/local/squid/sbin/squid -D
in questo modo il processo di init avvia Squid una sola volta quando si entra nel runlevel specificato

sq:2550:respawn:/usr/local/squid/sbin/squid -D
utilizzando l'opzione respawn il processo di init riavvia Squid se il processo dovesse terminare. Dopo aver editato il file di
inittab rileggiamo la configurazione ed avviamo Squid
% init q
questa soluzione è stata testata con Fedora Core 1
12.3.2. Avviare Squid utilizzando il file rc.local
Uno degli schemi più semplici per avviare Squid è utilizzare lo script /etc/rc.local oppure lo script /etc/rc.d/rc.local (RedHat
Linux, Fedora e Mandrake). Si tratta di un semplice script di shell che viene eseguito come root all'avvio del sistema
/usr/local/squid/sbin/squid -D
il prefisso di installazione del file binario può essere differente e possiamo utilizzare diverse opzioni per avviare Squid ad
esclusione di squid -N. Per verificare se Squid è in ascolto utilizziamo l'utility squidclient
% /usr/local/squid/bin/squidclient http://www.cisco.com/ > test
successivamente verificheremo se il contenuto del file test è congruo
12.3.3. Avviare Squid con i sistemi *BSD (init.d e rc.d)
Lo schema init.d e rc.d ricorre ad uno script di shell che è in grado di avviare i diversi servizi. Questo script può trovarsi nelle
seguenti directory: /sbin/init.d, /etc/init.d e /usr/local/etc/rc.d. Di seguito mostriamo uno script di startup realizzato per un
sistema BSD

#!/bin/sh
# nome del file: squid.sh
echo -n ' Squid '
case "$1" in
start)
/usr/local/squid/bin/squid -D
;;
stop)
/usr/local/squid/bin/squid -k shutdown
;;
restart)
/usr/local/squid/bin/squid -k reconfigure
;;
*)
echo "Usage: `basename $0` {start|stop|restart}"
;;
esac
questo tipo di script ricorre agli argomenti start, stop e restart
% /usr/local/etc/rc.d/squid.sh start
lo script è stato testato con FreeBSD 4.11-STABLE
12.3.4. Fermare Squid
Il sistema più veloce per arrestare Squid è quello di utilizzare il comando squid -k shutdown
% squid -k shutdown
questo comando avvia un segnare TERM al processo Squid, verranno così chiusi tutti i socket di rete e nessuna nuova richiesta
verrà accettata. Il tempo di chiusura di Squid è pari a circa 30 secondi ma può essere modificato utilizzando la direttiva
shutdown_lifetime. Possiamo anche utilizzare il comando squid -k interrupt
% squid -k interrupt
con questo comando Squid verrà chiuso immediatamente

12.4. Avviare una versione compilata su Red Hat Linux

Come noto tutte le versioni di RedHat Linux, a partire dalla release 7.2, sino ad arrivare alla versione 9 non vengono più
supportate da Red Hat. E' stato anche istituito un webservice di supporto non ufficiale da parte di FedoraLegacy (URLs http://
www.fedoralegacy.org/) che è diverso tempo che non rilascia patch per le applicazioni più importanti e non supporta più le
versioni 7.2 ed 8.0. In molti casi Squid può rappresentare una applicazione mission critical per il core business ed inoltre,
secondo il parere di chi scrive, non è mai una buona idea aggiornare un Sistema Operativo che funziona bene e che offre servizi
importati per la nostra community. Una nuova release di un Sistema Operativo può offrire delle nuove funzionalità ma
potrebbe anche compromettere la stabilità e l'affidabilità del sistema precedente qualora si decidesse di eseguire
l'aggiornamento.
Abbiamo realizzato dei test funzionali utilizzando una distribuzione Red Hat Linux 7.3, gli stessi sono stati ripetuti con
successo utilizzando Fedora Core 1 e possiamo supporre che la configurazione che andremo a descrivere in seguito possa
funzionare anche con Mandrake Linux e le altre distribuzioni Red Hat, il cui sistema di init è praticamente uguale identico.
Il Sistema di init di una distribuzione Red Hat Linux è ispirato al modello System V, dunque legge il contenuto del file /etc/
inittab
id:x:initdefault:
questa linea identifica il run level che verrà attivato come default. In questo esempio la x identifica il numero di run level e tutti
i link simbolici contenuti nella directory /etc/rcx.d/ verranno mandati in esecuzione.
La prima attività da svolgere è quella di rimuovere la versione che viene distribuita ed installata con il Sistema Operativo. Nel
caso di studio che stiamo documentando, in prima istanza verificheremo la versione di Squid installata sul Sistema e poi
procederemo alla rimozione del pacchetto rpm utilizzando appunto il comando rpm(8), rpm è l'acronimo di RPM Package
Manager o Red Hat Package Manager
% rpm -qa | grep 'squid'

squid-2.4.STABLE6-6.7.3
rimuoviamo il package
% rpm -e squid-2.4.STABLE6-6.7.3
warning: /etc/squid/squid.conf saved as /etc/squid/squid.conf.rpmsave
l'operazione appena effettuata non cancellerà il vostro file di configurazione squid.conf ma lo rinominerà eseguendo una copia
di sicurezza. Il messaggio di warning contenuto nell'esempio sopracitato è piuttosto chiaro. La procedura di disinstallazione del
package rpm ha rimosso anche altri files come /etc/sysconfig/squid. Questo file dovrà essere prontamente ricreato

% touch /etc/sysconfig/squid
editiamo il file /etc/sysconfig/squid utilizzando il nostro editor preferito
# default squid options

# -D disables initial dns checks. If you most likely will not to have an
# internet connection when you start squid, uncomment this
SQUID_OPTS="-D"
# Time to wait for Squid to shut down when asked. Should not be necessary
# most of the time.
SQUID_SHUTDOWN_TIMEOUT=100
ora possiamo finalmente procedere con l'installazione di Squid utilizzando il codice sorgente, per seguire la procedura di
configurazione ed installazione è necessario riferirsi al paragrafo che abbiamo appunto dedicato a questo argomento.
Terminato il processo di compilazione e di installazione, con il comando ln(8) imposteremo un link simbolico per rendere
l'eseguibile compatibile con il formato Red Hat. Il nuovo eseguibile /usr/local/squid/sbin/squid dovrà essere linkato
simbolicamente in /usr/sbin/squid. I sistemi UNIX® definiscono due concetti a riguardo dei collegamenti. Possiamo avere dei
collegamenti fisici o dei collegamenti simbolici. Un collegamento fisico viene rappresentato da un nome di un file mentre il
collegamento simbolico è un file speciale che contiene un percorso fisico diretto verso il file originale. Quindi un collegamento
simbolico può puntare verso un file che può essere fisicamente ubicato su un'altro file system
# ln -s /usr/local/squid/sbin/squid /usr/sbin/squid
# ls /usr/sbin/squid
lrwxrwxrwx 1 root 27 apr 8 23:06 /usr/sbin/squid -> /usr/local/squid/sbin/squid*
a questo punto procediamo con la generazione dell'ambiente di init ricreando il file di init per il demone Squid, questo ci
consentirà di avviare il proxy server con il boot del Sistema Operativo. Il nome del file di init è /etc/rc.d/init.d/squid
% touch /etc/rc.d/init.d/squid
% chmod u+x,g+x,o+x /etc/rc.d/init.d/squid
● convenzioni utilizzate dal file
1. viene modificata la directory dove verrà installato il file di configurazione di Squid
/usr/local/squid/etc/squid.conf
2. viene ridefinita la directory dove verrà creato lo spazio dedicato al disk storage di Squid

/usr/local/squid/var/cache
3. viene ridefinita l'ubicazione del PID (Process ID) file
/usr/local/squid/var/run/squid.pid
nell'esempio che riportiamo in calce, Vi proponiamo un file di init per i sistemi Red Hat, modificato in alcuni punti. Le
modifiche devono essere riferite al tipo di albero delle directory che sono state definite come standard per una versione di
Squid compilata. Per altre informazioni sull'albero delle directory fare riferimento al paragrafo che abbiamo dedicato
all'argomento. Questo file consentirà a Red Hat Linux di eseguire una versione compilata sulla macchina locale
#!/bin/bash
# filename : /etc/rc.d/init.d/squid
# modifiche: il file è stato modificato per eseguire una versione di Squid \
# compilata, il file è stato testato su Red Hat Linux 7.3
#
# squid This shell script takes care of starting and stopping
# Squid Internet Object Cache
#
# chkconfig: - 90 25
# description: Squid - Internet Object Cache. Internet object caching is \
# a way to store requested Internet objects (i.e., data available \
# via the HTTP, FTP, and gopher protocols) on a system closer to the \
# requesting site than to the source. Web browsers can then use the \
# local Squid cache as a proxy HTTP server, reducing access time as \
# well as bandwidth consumption.
# pidfile: /usr/local/squid/var/run/squid.pid
# config : /usr/local/squid/etc/squid.conf
# cache : /usr/local/squid/var/cache
# logs : /usr/local/squid/var/logs
PATH=/usr/bin:/sbin:/bin:/usr/sbin
export PATH
#
# file descriptors (avvia squid con un limite max di 4096 FD)
# echo 102400 > /proc/sys/fs/file-max
ulimit -HSn 4096
#
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0
# check if the squid conf file is present
#
# è stata modificata la directory dove è ubicato il file \
# di configurazione di Squid
[ -f /usr/local/squid/etc/squid.conf ] || exit 0

if [ -f /etc/sysconfig/squid ]; then
. /etc/sysconfig/squid
else
SQUID_OPTS="-D"
SQUID_SHUTDOWN_TIMEOUT=100
fi
# determine the name of the squid binary
#
# ci si riferisce al percorso del vecchio eseguibile \
# ed avremo provveduto a creare un eventuale link simbolico \
# che punta al nuovo file eseguibile
[ -f /usr/sbin/squid ] && SQUID=squid
[ -z "$SQUID" ] && exit 0
prog="$SQUID"
# determine which one is the cache_swap directory
# nel caso in cui la directory di swap sia vuota squid ne \
# crea una, attenzione al percorso di squid.conf
CACHE_SWAP=`sed -e 's/#.*//g' /usr/local/squid/etc/squid.conf | \
grep cache_dir | awk '{ print $3 }'`
[ -z "$CACHE_SWAP" ] && CACHE_SWAP=/usr/local/squid/var/cache
RETVAL=0
start() {
for adir in $CACHE_SWAP; do
if [ ! -d $adir/00 ]; then
echo -n "init_cache_dir $adir... "
$SQUID -z -F 2>/dev/null
fi
done
echo -n $"Starting $prog: "
$SQUID $SQUID_OPTS 2> /dev/null &
RETVAL=$?
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/$SQUID
[ $RETVAL -eq 0 ] && echo_success
[ $RETVAL -ne 0 ] && echo_failure
echo
return $RETVAL
}
stop() {
echo -n $"Stopping $prog: "
$SQUID -k check >/dev/null 2>&1
RETVAL=$?
if [ $RETVAL -eq 0 ] ; then
$SQUID -k shutdown &
rm -f /var/lock/subsys/$SQUID
timeout=0
while : ; do
[ -f /usr/local/squid/var/run/squid.pid ] || break
if [ $timeout -ge $SQUID_SHUTDOWN_TIMEOUT ]; then
echo
return 1
fi
sleep 2 && echo -n "."
timeout=$((timeout+2))

done
echo_success
echo
else
echo_failure
echo
fi
return $RETVAL
}
reload() {
$SQUID $SQUID_OPTS -k reconfigure
}
restart() {
stop
start
}
condrestart() {
[ -e /var/lock/subsys/squid ] && restart || :
}
rhstatus() {
status $SQUID
$SQUID -k check
}
probe() {
return 0
}
case "$1" in
start)
start
;;
stop)
stop
;;
reload)
reload
;;
restart)
restart
;;
condrestart)
condrestart
;;
status)
rhstatus
;;
probe)
exit 0
;;
*)
echo $"Usage: $0 {start|stop|status|reload|restart|condrestart}"
exit 1
esac

exit $?
ora verifichiamo l'esistenza di un'utente appropriato per eseguire Squid. In particolare per le distribuzioni Red Hat Linux,
dovrebbe essere già presente l'utente squid. In effetti l'utente dovrebbe essere presente in quanto creato precedentemente dalla
procedura di installazione della distribuzione originale in formato RPM
% more /etc/passwd | grep squid

squid:x:23:23::/var/spool/squid:/dev/null
in merito al Disk Storage di Squid, accertiamoci di configurare anche nel nuovo file di configurazione lo stesso percorso che
abbiamo utilizzato nella versione precedente di Squid (TAG cache_dir)
% more /etc/squid/squid.conf.rpmsave | grep cache_dir

cache_dir ufs /home/var/spool/squid 2024 16 256
ora procederemo con l'assegnazione dei permessi sulle directory, questo processo è fondamentale per consentire ai processi di
disk I/O di Squid di essere eseguiti. Inoltre editeremo il file squid.conf per impostare al meglio la nuova configurazione. In
questo caso non dimentichiamo che stiamo effettuando una migrazione da una versione 2.4 pacchettizata da Red Hat ad una
versione 2.5 direttamente compilata utilizzando i sorgenti prelevati dal sito del progetto Squid. Ricordiamo al lettore che vi
sono delle differenze piuttosto importanti tra la versione 2.4 e la versione 2.5 (cfr. capitolo differenze tra Squid 2.4 a Squid
2.5), pertanto non sarà possibile riutilizzare in alcun modo lo stesso file di configurazione
% cd /usr/local/squid/var/
% chown -R squid:squid *
% ls
totale 20
drwxr-xr-x 5 root 4096 apr 7 22:17 ./
drwxr-xr-x 9 root 4096 apr 7 21:30 ../
d-wx--x--x 2 squid 4096 apr 7 22:17 cache/
d-wx--x--x 2 squid 4096 apr 7 21:30 logs/
d-wx--x--x 2 squid 4096 apr 7 22:17 run/
per riprodurre il file squid.conf in maniera fedele possiamo aiutarci con il comando grep(8), grep ricerca nei file specificati le
righe che contengono una corrispondenza, possiamo così ricercare nel nuovo file di configurazione i TAG più significativi.
Nell'esempio vediamo la parte relativa alla configurazione SNMP

% more /etc/squid/squid.conf.rpmsave | grep snmp

# TAG: snmp_port
# NOTE: SNMP support requires use the --enable-snmp configure
snmp_port 3401
# TAG: snmp_access
snmp_access allow snmpManager
snmp_access allow snmppublic localhost
snmp_access allow allowed_hosts
snmp_access deny all
al termine della preparazione del file squid.conf possiamo provare ad avviare nuovamente Squid
% squid -k parse
% /etc/rc.d/init.d/squid start
Avvio di squid: [ OK ]
% netstat --l | grep webcache
tcp 0 0 *:webcache *:* LISTEN
% netstat --l | grep 3401
udp 0 0 *:3401 *:*
% nmap localhost
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-04-08 23:57 CEST
Interesting ports on localhost (127.0.0.1):
(The 1645 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
3128/tcp open squid-http
grandioso, Squid è in funzione e la migrazione è stata totalmente completata. A questo punto dovremo fare in modo di avviare
il processo squid con il relativo livello di init del Sistema Operativo (3 o 5 senza dimenticale lo 0 per l'esecuzione di una
corretta chiusura di Squid) utilizzando il comando chkconfig(8), chkconfig fornisce una facility a linea di comando per
mantenere le directory /etc/rc[0-6].d in maniera gerarchica e consentire agli Amministratori di Sistema di manipolare i link
simbolici contenuti all'interno di queste directory
% chkconfig --level 3 squid on

% chkconfig --level 0 squid off
% chkconfig --level 6 squid off
% ls -l /etc/rc.d/rc6.d/K25squid
lrwxrwxrwx 1 root root 15 27 dic 11:34 /etc/rc.d/rc6.d/K25squid -> ../init.d/squid
% ls -l /etc/rc.d/rc0.d/K25squid
lrwxrwxrwx 1 root root 15 2 ott 12:43 /etc/rc.d/rc0.d/K25squid -> ../init.d/squid
potremo continuare ad utilizzare tranquillamente tutte le facility di gestione di un Sistema Red Hat come ad esempio il
comando service, questa utility consente di manipolare i servizi di sistema

% service squid stop

Interruzione di squid: [ OK ]
% service squid start
Avvio di squid: [ OK ]
Maggiori dettagli a riguardo degli scrip di avviamento sono reperibili nelle FAQ in lingua inglese presso la URLs http://www.
squid-cache.org/Doc/FAQ/FAQ-3.html#ss3.6.
12.5. RedHat, Fedora Core e Mandrake Linux

In fase di installazione, sarà direttamente il package in formato rpm che viene fornito con il Sistema Operativo, che si occuperà
di creare l'utente necessario all'esecuzione del demone e che definirà i permessi per l'accesso al filesystem da parte del processo
Squid. Qualora in fase di installazione non si sia provveduto all'installazione del proxy, il comando per installare l'applicazione
è
% rpm -ihv squid25-arch.rpm
dopo aver editato il file di configurazione principale di Squid e dopo averne verificato la correttezza, potremo creare la struttura
delle directory degli oggetti di cache con il comando
% squid -z
con Red Hat Linux, Fedora Core e Mandrake Linux il comando per avviare Squid è
% service squid start
consentiamo a Squid di avviarsi automaticamente con l'avviamento del sistema operativo

da annotare che in molte di queste distribuzioni Linux, il semplice avvio del servizio è sufficente per la generazione della cache
su disco

12.6. Debian GNU/Linux

In fase di installazione sarà la distribuzione del pacchetto in formato deb fornita con il Sistema Operativo, che si occuperà di
creare l'utente necessario all'esecuzione del demone e che definirà i permessi per l'accesso al filesystem da parte del processo
Squid. Qualora in fase di installazione non si sia provveduto all'installazione del proxy, il comando per installare l'applicazione
è
% apt-get install squid
dopo avere editato il file di configurazione principale di Squid e dopo averne verificato la sua correttezza, potremo creare la
struttura delle directory degli oggetti di cache con il comando
% squid -z
Se utilizziamo Debian Woody il comando per avviare Squid è
% /etc/init.d/squid start
12.7. FreeBSD
Definiremo le opzioni di configurazione, compileremo ed installeremo Squid direttamente dall'albero dei ports di FreeBSD
ricorrendo ai seguenti comandi
% cd /usr/ports/www/squid/
% make config

Il comando make config consente di impostare in maniera interattiva alcune opzioni di configurazione che permettono di
abilitare una serie di features piuttosto esotiche di Squid Proxy Server, il comando che utilizzeremo per installare Squid è
eseguita l'installazione verificheremo la correttezza dei permessi sul filesystem, come abbiamo visto i permessi sono necessari
per consentire la corretta generazione dello storage nonchè per la scrittura dei file di logs. I processi avviati da Squid verranno
gestiti dall'utente squid (squid-2.5.4_6 e successivi) che verrà generato automaticamente al momento dell'installazione del
ports. Dopo aver editato il file di configurazione principale squid.conf ed averne verificato la sua correttezza procediamo con la
generazione degli oggetti che compongono la cache
% squid -z
dopo aver generato lo spazio dedicato al diskstorage procediamo all'avviamento di Squid ricorrendo allo script di avviamento
che è stato installato direttamente dal ports

non dimentichiamo di modificare lo script di override del sistema di init /etc/rc.conf di FreeBSD, nel quale dovremo includere
la seguente entry (squid-2.5.4_6 e successivi)
squid_enable="YES"
lo script di avvio è stato posizionato tra gli script di avviamento delle applicazioni lato user, pertanto Squid verrà avviato al
momento del processo di boot del sistema operativo.
12.8. OS/2 o EComStation

Nella distribuzione di Squid per OS/2 ed EComStation viene incluso il file squid.cmd che dovrà essere preventivamente editato
per definire il percorso (path) dell'eseguibile di Squid.
@setlocal
@set SQUID_DIRECTORY=e:\squid
@%SQUID_DIRECTORY%\bin\squid %1 %2 %3 %4 %5 %6 %7 %8 %9
@endlocal
prima di avviare il Proxy Server sarà necessario editare il file di configurazione adeguandolo alle nostre esigenze, verificarne la
sintassi e successivamente dovremo generare gli oggetti che compongono la cache
$ squid -z
solo ora sarà possibile eseguire il file squid.cmd per avviare Squid
12.9. Windows NT/2000/XP/2003

● estrarre l'archivio binario nella directory desiderata (il default è c:\squid)
● copiare il file squid.conf.default come squid.conf e mime.conf.default come mime.conf
● editare il file squid.conf e modificare, se necessario, i riferimenti al percorso c:/squid, utilizzando nei percorsi del tipo
"path" il carattere "/" e non il carattere "\"
● creare manualmente tutte le directory specificate in squid.conf, tranne quelle relative alla cache directory
● installare il servizio specificando il nome del file di configurazione nel caso lo stesso sia diverso da c:/squid/etc/squid.
conf ed il nome del servizio se lo stesso diverso da SquidNT

squid -i [-f configfile] [-n servicename]
● creare la struttura di cache directory
squid -z [-f configfile]
● configurare nel registro di Windows le opzioni di avvio di Squid
squid -O servicecommandline [-n servicename]
● avviare ed arrestare il servizio dal pannello di controllo dei servizi o ricorrendo al comando net stop o net start
Capitolo 13. Monitorare il funzionamento di Squid

13.1. Controlliamo la nostra cache
Il monitoraggio in tempo reale degli apparati di rete é una delle componenti essenziali che consentono di garantire una corretta
erogazione dei servizi di rete. É importante avere a disposizione informazioni di riferimento relative a periodi piuttosto lunghi
(baseline) sullo stato degli apparati di rete in quanto in caso di necessità sarà possibile individuare con maggiore facilità
eventuali problemi. Inoltre una baseline di riferimento può migliorare la nostra capacità di pianificare degli aggiornamenti. A
tale riguardo, per tenere sotto controllo un'apparato di webcache, sono necessarie delle misurazioni standard come il request
rate ed il response time. Dobbiamo dire che anche se non si dispone di budget molto elevati è possibile creare dei sistemi di
monitoraggio molto performanti ed efficenti utilizzando alcune applicazioni a codice libero come net-snmp (http://net-snmp.
sourceforge.net/), MRTG (http://people.ee.ethz.ch/~oetiker/webtools/mrtg/) ed RRDTool (http://people.ee.ethz.ch/~oetiker/
webtools/rrdtool/).
13.2. Analizziamo le informazioni

Elenchiamo ora un insieme di informazioni che devono essere collezionate per effettuare un corretto monitoraggio di Squid
13.2.1. Request rate
il Request rate è il numero delle richieste che vengono effettuare dai client a Squid, all'interno di una organizzazione
commerciale possiamo verificare dei picchi di richiesta delle pagine durante la mattina e la sera, all'interno di una università

l'andamento delle richieste è decisamente più uniforme nell'arco della giornata
13.2.2. Response time
il tempo di risposta è un tipo di misurazione server-side e client-side. La misurazione server-side consiste nella valutazione dei
tempi di risposta che intercorrono tra i servers di origine (compresi i proxy server in relazione di parentela) ed il proxy server.
La misurazione client-side invece consiste nella valutazione dei tempi di risposta che vengono ottenuti dall'utente finale. Tempi
di risposta molto brevi danno una sensazione di efficenza del sistema, cattivi tempi di risposta ne forniranno agli utenti una
sensazione di cattivo funzionamento
13.2.3. bandwidth
abbiamo già detto che c'è una relazione molto forte tra la banda disponibile e le richieste di accesso al proxy server, in presenza
di un alto numero di richieste potrebbe saturarsi la banda internet disponibile, queste considerazioni possono essere utilizzate
per valutare un'aggiornamento della connettività internet
13.2.4. stato delle connessioni
un sistema operativo di rete è in grado di aprire un certo numero massimo di connessioni TCP, questo fattore dipende molto
dalle impostazioni del Kernel e dalla memoria fisica disponibile, ed esempio le versioni più recenti di FreeBSD sono in grado
di regolare automaticamente questo tipo di risorsa. Nei sistemi UNIX® il comando netstat(8) può aiutarci a verificare il
numero massimo delle connessioni attive. Controllare lo stato delle connessioni è importante per capire se il sistema sta
esaurendo il numero massimo consentito di connessioni di rete oppure se siamo di fronte ad un attacco del tipo SYN flood
13.2.5. Altri fattori
la risoluzione dei nomi internet può essere un fattore critico, tenere traccia delle risposte Domain Name System (DNS) lookup
consente registrare lo stato dei sistemi DNS esterni, l'utilizzo della memoria del sistema operativo sul quale viene eseguito
Squid e l'utilizzo dello spazio su disco, come abbiamo visto, sono informazioni che possono cambiare significativamente le
prestazioni di Squid. L'utilizzo intensivo della CPU può divenire un collo di bottiglia, se per qualche motivo si dovesse
bloccare il processo di disk I/O inizierà a crescere l'utilizzo del processore, l'utilizzo di una unità a disco particolarmente lenta
può provocare un utilizzo massivo dalla CPU. Il numero di descrittori di file in uso in un dato momento sono generalmente
uguali al numero di request rate moltiplicati per il response time, se la connessione con la rete internet va giù il tempo di
risposta può divenire infinito e Squid può raggiungere il limite massimo di descrittori di file. É normale verificare un piccolo
numero di errori relativi ad accessi non consentiti o rinunciati ma è quanto mai singolare verificare un'incremento significativo
di questo tipo di errori.
13.2.6. Gli strumenti di controllo offerti da Squid
Squid mette a disposizione due tipi differenti di interfaccie per eseguire l'attività di monitoraggio delle risorse

● Supporto SNMP (Simple Network Management Protocol)
● Il Cache Manager
oltre a fornire una serie di informazioni sul protocollo del Simple Network Management Protocol (SNMP) e su alcuni prodotti
a codice libero, nelle pagine seguenti approfondiremo al meglio delle nostre possibilità queste due componenti di Squid.
13.3. Due parole su SNMP

Il troubleshooting è necessario per risolvere molti problemi che si possono verificare all'interno di una rete, una delle
aspirazioni di un buon amministratore di rete è quella di non avere problemi. Il software che consente di effettuare il network
management delle reti TCP/IP è principalmente basato sul protocollo Simple Network Management Protocol (SNMP). SNMP è
un protocollo del tipo client/server che è descritto come protocollo di management e viene utilizzato per consentire la gestione
di intere reti geografiche e di tenere sotto controllo qualsiasi tipo di apparato. Il Draft che descrive il protocollo SNMP è la
RFC 1157 (http://www.ietf.org/rfc/rfc1157.txt).
Gli agent SNMP (un server, un apparato di rete, una risorsa in genere) si occupano di monitorare lo stato degli apparati di rete e
trasmettono i dati o consentono l'analisi delle informazioni relative al loro stato di funzionamento. Il manager (il client SNMP)
viene eseguito sulla Network Management Station (NMS), questa postazione è in effetti il collettore di tutte le informazioni
provenienti dai vari apparati di rete, le informazioni vengono immagazzinate sulla base di dati che possono essere visualizzati
in tempo reale. Esistono diversi applicativi che consentono di manipolare le informazioni fornite dalla stazione di NMS.
La maggioranza degli apparati TCP/IP vengono forniti con un agent SNMP, Squid è un software che, se opportunamente
configurato, può tranquillamente funzionare come agent per fornire informazioni dettagliate sullo stato della webcache nonchè
sul traffico che sta gestendo in un dato momento.
SNMP è un protocollo del tipo richiesta/risposta che utilizza lo User Datagram Protocol (UDP) per il trasporto dei pacchetti,
l'agent rimane in ascolto sulla porta UDP 161 mentre la network managemente station (NMS) rimane in ascolto anche sulla
porta UDP 162 per ricevere le trap che possono essere inviate dai vari agent. Secondo le specifiche di SNMPv1 e SNMPv2 il
transito delle informazione utilizza un sistema di autenticazione che prende il nome di communities, le communities sono delle
password in formato testo, ne consegue che il transito dai dati tra l'agent e l'nms è il punto debole del protocollo in quanto non
viene utilizzato alcun sistema di crittografia. Le communities sono read-only, read-write e trap, ognuna di queste svolge un
compito ben definito. La read-only consente di prelevare le informazioni dall'agent in sola lettura, la read-write è stata studiata
per consentire agli utenti di eseguire la gestione remota dell'apparato (quindi consente di modificare le informazioni) e la trap
invece autentica gli avvisi che vengono inviati dall'agent verso l'nms. Con il protocollo SNMPv3 è stato introdotto uno schema
di autenticazione forte che consente di trasmettere le informazioni all'inteno di un canale sicuro (crittografato). Vista la
debolezza del protocollo SNMPv1 ed SNMPv2 si consiglia sempre di utilizzare un firewall od un filtro IP che consenta la
comunicazione tra i soli agent e la network management station (NMS) visto che il traffico potrebbe essere facilmente
intercettato (sniffato). La richiesta e la risposta ai messaggi che SNMP invia nei datagrammi UDP viene chiamata Protocol
Data Units (PDU).
13.3.1. Configurare l'agent SNMP di Squid
Abbiamo già detto che con la compilazione di Squid può essere incluso un agente Simple Network Managment Protocol
(SNMP), unitamente all'agent Squid viene fornito anche di un MIB file che consentirà di gestire le variabili e gli oggetti più
importanti. Per configurare il supporto SNMP è necessario compilare Squid con le seguenti opzioni di ./configure

% ./configure --enable-snmp
inoltre sarà necessario editare il file squid.conf per specificare una lista di communities, abbiamo visto in precedenza il
significato di questo termine ed è possibile effettuare questa operazione utilizzando il TAG ACL riportato nell'esempio
sottostante dove l'indirizzo IP 10.0.0.2 è quello della proxy appliance
acl locallan src 10.0.0.0/255.255.255.0

acl localla1 src 10.0.1.0/255.255.255.0
acl snmpjoebloggs snmp_community joebloggs
nel nostro caso, oltre alle access list che definiscono le subnet della rete locale verranno create ulteriori 3 nuove ACL
● una per il Server snmpManager
● due per le communities che prendono il nome di "public" e "joebloggs"
i nomi delle communities vengono determinati a piacere dall'amministratore del network. É necessario specificare una porta
sulla quale deve rimanere in ascolto l'agente SNMP, per fare questo si utilizza il TAG snmp_port, la porta utilizzata come
default da Squid è la 3401
snmp_port 3401
è anche possibile effettuare il forward delle richieste SNMP su un'altro agent SNMP che in questo caso potrebbe già essere in
ascolto sulla stessa macchina sulla quale è in funzione il nostro proxy, è possibile eseguire questa operazione utilizzando il
seguente TAG
forward_snmp_port
per autorizzare l'accesso all'agent SNMP di Squid devono essere definite le autorizzazioni per i TAG ACL che abbiamo creato
in precedenza, ad esempio

snmp_access allow snmppublic locallan

nel nostro esempio l'agent SNMP potrà sempre essere avviato da snmpManager, ovvero la macchina che esegue il proxy potrà
essere consultata da localhost (127.0.0.1) e la locallan (10.0.0.0/24), tutte le altre macchine della WAN non potranno accedere
al servizio. Se non viene definita alcuna ACL, l'accesso SNMP è sempre vietato come standard predefinito. É anche possibile
definire indirizzi IP determinati che legano l'agente SNMP di Squid per quello che concerne il traffico in entrata e quello in
uscita, è possibile effettuare il bind facendo ricorso al seguente TAG
snmp_incoming_address 0.0.0.0
snmp_outgoing_address 0.0.0.0
dopo aver configurato correttamente l'agente SNMP è importante verificare che l'appliance Squid sia in ascolto sulla porta 3401
(predefinita), per effettuare questa verifica è necessario utilizzare il comando netstat(8) (sistemi Linux e FreeBSD)
% netstat -na |grep udp|grep 3401

udp 0 0 0.0.0.0:3401 0.0.0.0:*
verificato il funzionamento dell'agente SNMP possiamo finalmente testare il funzionamento del proxy server Squid.
13.3.2. Net-snmp
Possiamo finalmente provare le funzionalità dell'agent SNMP di Squid utilizzando i tools che vengono inclusi nel pacchetto net-
snmp (http://net-snmp.sourceforge.net/). Installiamo net-snmp su un sistema FreeBSD
% cd /usr/ports/net-mgmt/net-snmp
se utilizziamo una qualsiasi distribuzione Linux o un'altro sistema UNIX® potremmo anche procedere con la compilazione e
l'installazione manuale di net-snmp, come potete vedere il processo è molto semplice
% tar zxvf net-snmp-5.1.2.tar.gz

% cd net-snmp-5.1.2
% ./configure
% make
% su
% make install
copiamo il MIB file di Squid nella directory che contiene tutti i MIB files utilizzati da net-snmp, il percorso di destinazione del
MIB file può variare e questo fatto può dipendere dal sistema operativo utilizzato

% cp /usr/local/etc/squid/mib.txt /usr/local/share/snmp/mibs/SQUID-MIB.txt
% chmod 444 /usr/local/share/snmp/mibs/SQUID-MIB.txt
su una macchina Red Hat Linux 7.3 che utilizza ucd-snmp ovvero la versione precedente di net-snmp i file MIB sono ubicati in
una directory diversa
% cp /usr/local/squid/share/mib.txt /usr/share/snmp/mibs/SQUID-MIB.txt
% chmod 444 /usr/share/snmp/mibs/SQUID-MIB.txt
il MIB file è stato copiato nella directory come file di sola lettura, a questo punto utilizziamo l'utility snmpget(8) che consente
di comunicare con una entità di rete utilizzando una richiesta SNMP di tipo GET
% snmpget -m SQUID-MIB -c public klingon.merlinobbs.net:3401 \

squid.cacheConfig.cacheAdmin
enterprises.nlanr.squid.cacheConfig.cacheAdmin = [email protected]
se dovessimo ottenere una risposta contenente un errore, questo significa che snmpget(8) non riesce a trovare il MIB file di
Squid, se invece non dovessimo ottenere risposta, oppure ottenessimo un errore di timeout potemmo anche supporre che Squid
non sia stato configurato per utilizzare SNMP oppure le ACL impostate sono troppo restrittive e non consentono di interrogare
l'agent.
% snmpget -m SQUID-MIB -c public klingon.merlinobbs.net:3401 \

squid.cacheConfig.cacheAdmin
snmpget: Timeout
l'opzione -m indica all'utility snmpget(8) di utilizzare il MIB file SQUID-MIB, l'opzione -c indica il nome della community, per
finire klingon.merlinobbs.net:3401 è il nome dell'host e la porta dove l'agent SNMP è in ascolto. Potremmo utilizzare anche
l'utility snmpwalk(8) che comunica con una entità di rete utilizzando una richiesta SNMP del tio GETNEXT.
% snmpwalk localhost:3401 public .1.3.6.1.4.1.3495.1.1

enterprises.3495.1.1.1.0 = 84
enterprises.3495.1.1.2.0 = 12916
enterprises.3495.1.1.3.0 = Timeticks: (1326) 0:00:13.26
% snmpwalk localhost:3401 public .1.3.6.1.4.1.3495.1.1
enterprises.3495.1.1.1.0 = 84
enterprises.3495.1.1.2.0 = 171000
enterprises.3495.1.1.3.0 = Timeticks: (8406) 0:01:24.06
in questo esempio non vengono utilizzate opzioni, localhost:3401 è il nome della macchina locale (127.0.0.1) e la porta dove

rimane in ascolto l'agent SNMP, public è il nome della community SNMP. Gli esempi mostrano chiaramente come
interagiscono gli oggetti di una Network Management Station (NMS) con gli agent SNMP.
13.3.3. Controllare i processi utilizzando Net-snmp
In precedenza abbiamo citato il tipo di processi che dovremmo sempre tenere sotto controllo per verificare costantemente il
nostro sistema di webcache, ora analizziamo nel dettaglio i processi e come utilizzare il Simple Network Management Protocol
(SNMP) per ottenere questo tipo di informazioni
13.3.3.1. process size
la grandezza dei processi può avere un grande impatto sulle prestazioni di Squid, se il processo diviene troppo grande il sistema
operativo utilizzerà una parte del disco per salvare le operazioni nella partizione di swap, lo OID[27] incluso nel MIB[28] file
di Squid è enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheMaxResSize

enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheMaxResSize
enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheMaxResSize = 0
13.3.3.2. page fault rate
le prestazioni di Squid possono soffrire quando la grandezza del processo supera la memoria fisica del sistema, analizzare il
processo page fault rate è un ottimo sistema per tenere sotto controllo questo tipo di problema. Un page fault si verifica quando
un programma richiede di accedere in un area di memoria che è stata swappata sul disco, lo OID incluso nel MIB file di Squid è
enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheSysPageFaults

enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheSysPageFaults
enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheSysPageFaults = Counter32: 768
13.3.3.3. HTTP request rate
l'HTTP request rate è l'insieme delle richieste che vengono effettuare dai client verso Squid, se abbiamo avuto notizia che
Squid sia divenuto lento alle richieste degli utenti possiamo determinare l'effettivo aumento delle HTTP request rate, lo OID
incluso nel MIB file di Squid è enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheProtoAggregateStats.
cacheProtoClientHttpRequests


enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheProtoAggregateStats.
cacheProtoClientHttpRequests
cacheProtoClientHttpRequests = Counter32: 399
13.3.3.4. ICP request rate
Se utilizziamo dei proxy server in relazione tra loro (parent o sibling) dovremmo controllare le richieste ICP in quanto vi sono
dei problemi piuttosto importanti che possono essere relazionati con le query ICP. lo OID incluso nel file MIB di Squid è
enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheProtoAggregateStats.cacheIcpPktsRecv

cacheIcpPktsRecv
cacheIcpPktsRecv = Counter32: 0
13.3.3.5. Denied requests
Abbiamo detto in precedenza che dovremmo sempre ricevere un numero molto limitato di messaggi di errore (deny access,
miss etc.), un'alta percentuale di errori può indicare un problema che è occorso nella realizzazione delle ACL o una cattiva
configurazione dei client, oppure che qualcuno sta cercando di attaccare in nostro server. Questo tipo di errori possono essere
analizzati direttamente dal file di log access.log
13.3.3.6. HTTP service time
Con il termine HTTP service time si identifica la lunghezza di una transazione HTTP competa, ovvero il tempo che intercorre
tra la richiesta effettuata dal client e la risposta trasmessa al client. HTTP median service time è il tempo medio di risposta,
questo tipo di misurazione può andare da un minimo di 100 ms ad un massimo di 500 ms, questa informazione può variare
sulla base di alcuni fattori come il tipo di connettività internet. Lo OID incluso nel file MIB di Squid è enterprises.nlanr.squid.
cachePerf.cacheProtoStats.cacheMedianSvcTable.cacheMedianSvcEntry.cacheHttpAllSvcTime.5

enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheMedianSvcTable.
cacheMedianSvcEntry.cacheHttpAllSvcTime.5
cacheMedianSvcEntry.cacheHttpAllSvcTime.5 = 0

13.3.3.7. DNS service time
Con il termine DNS service time viene indicato il tempo necessario a risolvere un nome internet da parte di un sistema Domain
Name System (DNS), abbiamo detto in precedenza che un tempo di risposta molto elevato nella risoluzione di un nome può
indicare un problema con il nostro DNS primario. Lo OID incluso nel file MIB di Squid è enterprises.nlanr.squid.cachePerf.
cacheProtoStats.cacheMedianSvcTable.cacheMedianSvcEntry.cacheDnsSvcTime.5

cacheMedianSvcEntry.cacheDnsSvcTime.5
cacheMedianSvcEntry.cacheDnsSvcTime.5 = 0
13.3.3.8. File descriptor aperti
Come abbiamo già spiegato dettagliatamente, i descrittori di file rappresentano il totale dei file e dei socket di rete aperti in un
dato momento. Questo tipo di controllo può essere effettuato unitamente agli HTTP connection rate e gli HTTP service time.
Lo OID incluso nel file MIB di Squid è enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheCurrentUnusedFDescrCnt

enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheCurrentUnusedFDescrCnt
enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheCurrentUnusedFDescrCnt =
Gauge32: 1011
13.3.3.9. Utilizzo della CPU
Abbiamo già detto che l'utilizzo della CPU dipende da vari fattori, tra questi possiamo elencare le opzioni di configurazione
che abbiamo abilitato durante la compilazione di Squid e la grandezza della cache. Una unità a disco particolarmente lenta può
divenire un collo di bottiglia che può far crescere esponenzialmente il tempo di utilizzo della CPU. Altre opzioni che utilizzano
pesantemente la CPU sono il cache-digest, il CARP e le liste di URLs basate sulle regular expression. Lo OID incluso nel file
MIB di Squid è enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheCpuUsage

enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheCpuUsage
enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheCpuUsage = 0
13.3.3.10. Spazio su disco
Lo spazio su disco è una delle risorse che viene maggiormente utilizzata da Squid, il messaggio di errore notificato agli utenti
quando si verifica una condizione di spazio esaurito è "no space left on device". Quando si riceve questo tipo di messaggio, il
processo (PID) Squid va in errore e l'applicazione va in crash, questo tipo di informazione è disponibile unicamente utilizzando

l'interfaccia del cache manager di Squid di cui parleremo in seguito
13.3.3.11. Hit ratio
Cache Hit ratio è un'altro tipo di misurazione che può variare molto frequentemente nell'arco temporale, queste continue
variazioni non sono un buon indicatore per la rilevazione di un problema. Lo OID incluso nel file MIB di Squid è enterprises.
nlanr.squid.cachePerf.cacheProtoStats.cacheMedianSvcTable.cacheMedianSvcEntry.cacheRequestHitRatio.5

cacheMedianSvcEntry.cacheRequestHitRatio.5
cacheMedianSvcEntry.cacheRequestHitRatio.5 = 0
13.4. MRTG e Squid

Dopo aver configurato il proxy server come agent SNMP, è anche possibile controllare al meglio le performance di Squid
utilizzando Multi Router Traffic Grapher (MRTG), si tratta di un prodotto piuttosto noto negli ambienti del networking, questo
tool viene generalmente utilizzato per controllare i collegamenti di rete. MRTG è in grado di generare delle pagine HTML che
mostrano delle immagini, queste visualizzano graficamente una rappresentazione del traffico di rete o di altri valori. Installiamo
ora MRTG sul nostro sistema FreeBSD
% cd /usr/ports/net-mgmt/mrtg/
se utilizziamo una qualsiasi distribuzione Linux o un'altro sistema UNIX® potremmo anche procedere con la compilazione e
l'installazione manuale di net-snmp, come potete vedere il processo è molto semplice
% tar zxvf mrtg-2.10.15.tar.gz

% cd mrtg-2.10.15
% ./configure
% make
% su
% make install
per ottenere maggiori informazioni su questo pacchetto è possibile consulare la URLs http://people.ee.ethz.ch/~oetiker/
webtools/mrtg/ .
Ad ogni buon conto, MRTG è un programma che utilizza il linguaggio perl che molte distribuzioni Linux installano
automaticamente come "default" nella loro configurazione per i servers. MRTG viene utilizzato dai network manager per la sua

duttilità e per la facilità di utilizzo nel controllo degli apparati di rete come, ad esempio, i Router della CISCO Systems (http://
www.cisco.com/), MRTG funziona con i sistemi UNIX® e Windows.
Attivato l'agent SNMP di Squid è possibile utilizzare Multi Router Traffic Grapher per verificare il traffico e l'uptime del
nostro proxy server, di seguito mostriamo il codice da aggiungere nel file di configurazione /usr/local/etc/mrtg/squid.cgf
WorkDir: /usr/local/www/data-dist/mrtg
LoadMIBs: /usr/local/etc/squid/mib.txt
Target[proxy-srvkbinout]: cacheServerInKb&cacheServerOutKb:[email protected]:3401
MaxBytes[proxy-srvkbinout]: 1250000
Title[proxy-srvkbinout]: Cache Server Traffic In / Out
PageTop[proxy-srvkbinout]: <H1>Cache Statistics: traffic (In/Out)</H1>
Suppress[proxy-srvkbinout]: y
LegendI[proxy-srvkbinout]: Traffic In
LegendO[proxy-srvkbinout]: Traffic Out
Legend1[proxy-srvkbinout]: Traffic In
Legend2[proxy-srvkbinout]: Traffic Out
YLegend[proxy-srvkbinout]: per minute
ShortLegend[proxy-srvkbinout]: b/min
kMG[proxy-srvkbinout]: k,M,G,T
kilo[proxy-srvkbinout]: 1024
Options[proxy-srvkbinout]: nopercent, perminute
le pagine HTML con i grafici ed i dati verranno salvati nella WorkDir, a questo punto utilizziamo la tabella di crontab(8) per
consentire ad MRTG di scrivere le statistiche di accesso e realizzare i suoi grafici
0-59/5 * * * * root /usr/local/bin/mrtg /usr/local/etc/mrtg/hardware.cfg
MRTG verrà eseguito ogni 5 minuti, per realizzare i grafici e salvare i dati MRTG dovrà leggere il file /usr/local/etc/mrtg/squid.
cfg. Se vogliamo visualizzare le statistiche di accesso con i relativi grafici dovremmo utilizzare l'utility indexmaker(8) che crea
i file di indice per i siti web basati su MRTG
% indexmaker /usr/local/etc/mrtg/squid.cfg > /usr/local/www/data-dist/mrtg/index.html
Per quanto concerne l'integrazione di MRTG con Squid, va segnalata la home page di Chris. L'autore pubblica una serie di
interessanti configurazioni, la URL's di riferimento è http://www.psychofx.com/chris/unix/mrtg/ .

Nell'area /contrib potrete trovare alcuni file di configurazione MRTG, tali file Vi saranno utili ad una corretta utilizzazione con
Squid proxy server.
13.5. Risorse in rete per utilizzare Squid con MRTG

Segue una lista di URLs che serviranno come riferimento per utilizzare MRTG con Squid, tutte le informazioni sono reperibili
anche nelle Squid FAQ alla URLs http://www.squid-cache.org/Doc/FAQ/FAQ-18.html#ss18.9
1. Monitoraggio della Cache - How to setup and monitoring by DFN-Cache
2. Utilizzare MRTG per monitorare Squid by Guido Serassio
3. Manuale di configurazione di Squid - Monitoring Squid by Visolve
4. Utilizzare MRTG con Squid - workshop session by Matija Grabnar
5. How do I monitor my Squid 2 cache using MRTG? by The National Janet Web Cache Service
Altri esempi di configurazione di Squid con MRTG
1. Collezione di MRTG HOWTO
2. Utilizzare MRTG per monitorareMRTG per monitorare Squid - dal sito di MRTG
3. MRTG & Squid by Glenn Chisholm
4. Braindump by Joakim Recht
13.6. Il Cache Manager

Il Cache Manager è una componente interna di Squid per la gestione remota tramite protocollo HTTP. É possibile utilizzare
una applicazione web del tipo Common Gateway Interface (CGI), cachemgr.cgi(8), che consente di visualizzare le diverse
informazioni e statistiche relative al processo Squid esposte dal Cache Manager. Per utilizzare correttamente cachemgr.cgi(8) è
necessario installare un server web, che può anche non risiedere sulla macchina dove è in esecuzione Squid.
A partire dalla versione 2.5 STABLE10, cachemgr.cgi(8) utilizza il file cachemgr.conf per determinare a quali server si è
autorizzati ad accedere. Ogni linea specifica una coppia server:port seguita da una descrizione opzionale:

# This file controls which servers may be managed by cachemgr.cgi

#
# The file consists of one server per line on the format
# hostname:port description
#
# Specifying :port is optional. If not specified then
# the default proxy port is assumed.
#
# hostname is matched using shell filename matching, allowing
# * and other shell wildcards.
localhost
cache.example.com:8080
Esistono anche applicazioni commerciali di terze parti che accedono direttamente allínterfaccia di Cache Manager senza
utilizzare un server web.
13.6.1. Configurare cachemgr.cgi con Apache
In prima istanza assicurarsi che sia stato installato Apache e che la directory che contiene gli script cgi-bin utilizzi la direttiva
ScriptAlias, è necessario modificare il file httpd.conf definendo la direttiva ScriptAlias per il singolo VirtualHost
<VirtualHost 192.168.0.4>
ScriptAlias /squid/cgi-bin/ /usr/local/squid/libexec/
</VirtualHost>
ora assicuriamoci che solo alcune workstation possano accedere al cachemanager, sempre all'interno della direttiva VirtualHost
inseriremo le seguenti informazioni
<Location /usr/local/libexec/squid/cachemgr.cgi>
order allow,deny
allow from workstation.domain.com
</Location>
</VirtualHost>
possiamo inserire più linee per ogni direttiva allow, possiamo autorizzare interi domini o intere subnet. In alternativa è anche
possibile proteggere il Cache Manager impostando una password di accesso sul server web utilizzando la direttiva Location.
Per proteggere l'accesso al Cache Manager con una password inseriremo le seguenti direttive nel file httpd.conf

<Location /usr/local/libexec/squid/cachemgr.cgi>
AuthUserFile /etc/htpasswd
AuthGroupFile /dev/null
AuthName User/Password Required
AuthType Basic
require user cachemanager
</Location>
</VirtualHost>
il file /etc/htpasswd contiene gli userID le password in formato MD5, non dimentichiamo mai che il protocollo HTTP non è un
protocollo sicuro in quanto i dati transitano sempre in chiaro, maggiori informazioni sul web server Apache sono disponibili
alla URLs http://httpd.apache.org/.
13.6.2. Configurare cachemgr.cgi con IIS 6
É possibile utilizzare una macchina Windows per connettersi al Cache Manager di Squid, anche su sistemi non Windows.
Innanzitutto é necessario procurarsi un package binario per Windows ed estrarne il file cachemgr.cgi.
Quindi si deve definire una directory virtuale IIS cgi-bin e modificarne i permessi di accesso in questo modo:
Utente Permessi
Administrators Full Control
NETWORK SERVICE Read & Execute
SYSTEM Full Control
Definire una Allowed Web Server Extension "Squid cachemgr.cgi" ed aggiungere il file cachemgr.cgi nei Required Files.
Modificare la directory virtuale cgi-bin definendone l'Application Name come "cgi-bin" e assegnando "Scripts and
Executables" come Execute Permissions
Disattivare infine l'accesso anonimo sulla directory virtuale e attivare uno schema di autenticazione, tipicamente Integrated
Windows
Se si sta utilizzando IIS 5.0 (Windows 2000) o IIS 5.1 (Windows XP), si deve procedere in modo analogo, ma senza cambiare i
permessi e non é necessario definire la Web Server Extension.
13.6.3. Impostare la password di accesso al Cache Manager
Tramite il Cache Manager è possibile visualizzare diverse informazioni sullo stato della cache ed è anche possibile bloccare il
processo di Squid, è dunque una buona idea definirne dei livelli di accesso. Solitamente si impostano diversi livelli di sicurezza

del Cache Manager ricorrendo all'utilizzo di più password utilizzando il TAG cachemgr_passwd. Rammentiamo ancora al
lettore che il traffico http non è sicuro perchè i dati attraversano la rete in chiaro. Per proteggere questi dati da occhi indiscreti è
possibile ricorrere agli standard SSL[29] o TLS[30] che sono alla base protocollo HTTPS (RFC 2818 - http://www.faqs.org/
rfcs/rfc2818.html). L'utilizzo del TAG all'interno del file squid.conf è il seguente
cachemgr_passwd [password] [azione] [azione]
dove password è appunto la parola chiave che intendiamo utilizzare, il TAG azione corrisponde ad un comando del Cache
Manager
cachemgr_passwd pippo shutdown

cachemgr_passwd paperino info stats/objects
con questo esempio viene impostata come password la parola pippo per consentire l'arresto di Squid tramite Cache Manager.
Utilizzando la parola chiave paperino potremo visualizzare le informazioni relative al processo Squid.
13.6.4. Definire una ACL per consentire l'accesso al Cache Manager
L'accesso al Cache Manager avviene utilizzando il protocollo identificato in Squid come cache_object, il TAG che definisce
l'utilizzo di questo protocollo è proto cache_obiect

acl all src 0.0.0.0/0.0.0.0
nell'esempio precedente, la macchina 127.0.0.1 è localhost, il webserver Apache è in funzione sulla stessa macchina che esegue
Squid (localhost). A questo punto dobbiamo definire delle regole che consentono l'accesso al Cache Manager da parte di
localhost
http_access deny manager !localhost

nel caso in cui il server web é installato su una macchina diversa da localhost


acl mywebserver src 192.168.0.4/255.255.255.255
acl all src 0.0.0.0/0.0.0.0
http_access deny manager !localhost !mywebserver
dopo aver installato e configurato Apache, definite le parole chiave per l'accesso alle varie funzionalità del Cache Manager ed
infine aver definito le ACL, siamo finalmente in grado di utilizzare il cachemgr.cgi.
13.6.5. Interrogare il Cache Manager utilizzando la linea di comando
Anche se l'interfaccia web di cachemgr.cgi consente di visualizzare le informazioni sullo stato della cache in maniera chiara e
dettagliata possiamo anche interrogare il Cache Manager direttamente, senza dover configurare alcun user-agent ed utilizzando
dal prompt dei comandi l'utility squidclient(8). I prerequisiti per questo tipo di configurazione sono gli stessi che per l'accesso
tramite cachemgr.cgi.
Nel caso in cui squidclient(8) non sia in path, potrebbe essere comodo definire un link simbolico all'interno del path di sistema
che consenta di avviare il comando in maniera agevole:
% ln -s /usr/local/squid/bin/squidclient /usr/sbin/squidclient
ora possiamo finalmente interrogare il Cache Manager di Squid, nel caso in cui sia stata definita una password, basterà usare le
opzioni -U e -W:
% squidclient -U manager -W pippo mgr:info | less

...
...
Squid Object Cache: Version 2.5.STABLE6
Start Time: Sat, 25 Sep 2004 07:07:20 GMT
Current Time: Sat, 25 Sep 2004 07:48:13 GMT
Connection information for squid:
ecco un'altro esempio di query via squidclient(8) che ci consentirà di determinare il numero di richieste HTTP in corso

% squidclient mgr:info | grep 'HTTP'

HTTP/1.0 200 OK
Number of HTTP requests received: 11
Average HTTP requests per minute since start: 0.2
HTTP Requests (All): 0.00000 0.00000
elenchiamo ora una serie di interrograzioni al Cache Manager di Squid, il significato di queste query è stato già trattato
dettagliatamente in precedenza nella sezione Utilizziamo Net-SNMP
13.6.5.1. Process size
% squidclient mgr:info | less

...
...
Process Data Segment Size via sbrk(): 2244 KB
Maximum Resident Size: 0 KB
13.6.5.2. Page Fault Rate
% squidclient mgr:info | grep 'Page faults'

Page faults with physical i/o: 464
13.6.5.3. HTTP Request Rate
% squidclient mgr:info | grep 'Number of HTTP requests'

Number of HTTP requests received: 16
% squidclient mgr:info | grep 'Average HTTP requests'
Average HTTP requests per minute since start: 0.2
% squidclient mgr:60min | grep 'client_http.requests'
client_http.requests = 0.004419/sec
13.6.5.4. ICP Request Rate

% squidclient mgr:counters | grep icp.queries_recv

icp.queries_recv = 0
13.6.5.5. DNS Service Time
% squidclient mgr:5min | grep dns.median_svc_time

dns.median_svc_time = 0.000000 seconds
13.6.5.6. File Descriptors
% squidclient mgr:info | grep 'Number of file desc currently in use'

Number of file desc currently in use: 12
13.6.5.7. CPU Usage
% squidclient mgr:5min | grep cpu_usage

cpu_usage = 0.000000%
Capitolo 14. Privacy

14.1. Preambolo
L'avvento della new-economy, oltre a generare delle nuove forme di schiavitù , ha determinato il deprecabile fenomeno della
catalogazione dei profili utente: i managers rampanti, per fidelizzare gli utenti e controllare le loro attitudini, hanno la necessità
di conoscere sempre maggiori dettagli sulla privacy degli utenti della rete: questo fenomeno viene principalmente utilizzato per
rivendere al miglior offerente abitudini, gusti e scelte degli utenti e per creare nuove opportunità di business.
14.2. Note operative

E' possibile proteggere da occhi indiscreti la nostra rete utilizzando Squid. Per motivi legati alla sicurezza è fondamentale
anonimizzare l'indirizzamento IP della LAN/WAN ed eventualmente proteggere altre informazioni come quelle relative al
client web utilizzato dagli utenti.
Con il TAG forwarded_for Squid può includere il Vostro indirizzo IP o il nome dell'host che inoltra con le sue richieste HTTP,

il valori sono [on|off]. La situazione generica è molto simile a questa
X-Forwarded-For: 192.168.2.3
è comunque possibile disabilitare questa funzione per far apparire un messaggio generico unitamente all'inoltro della richiesta
http verso il server web del tipo
X-Forwarded-For: unknown
per disabilitare l'inoltro dell'indirizzo IP da cui parte la richiesta diretta verso il server web Il TAG da abilitare è
forwarded_for off
se correttamente configurato Squid può anonimizzare le intestazioni inoltrate tramite la richiesta HTTP, per eseguire questa
misura di sicurezza deve essere utilizzando il TAG anonymize_headers. Nel caso che analizzeremo in seguito, verrà modificato
l'header relativo allo User-Agent ovvero il browser web utilizzato dagli utenti della rete che sono a valle del proxy. Utilizzo
anonymize_headers allow|deny header_name
l'opzione anonymizer_headers consente di eseguire configurazioni molto accurate: è infatti possibile specificare esattamente
quali intestazioni autorizzare. Ci sono due metodi per utilizzare questa features
1. specificare le intestazioni autorizzate
2. dettagliare gli header permessi.
Per riprodurre le opzioni di base, già previste nelle vecchie versioni di Squid con il l'opzione http_anonymizer standard dovrà
essere utilizzato il seguente TAG
anonymize_headers deny From Referer Server

anonymize_headers deny User-Agent WWW-Authenticate Link
per riprodurre la vecchia funzione http_anonymizer paranoid è invece necessario utilizzare il seguente TAG

anonymize_headers allow Allow Authorization Cache-Control

anonymize_headers allow Content-Encoding Content-Length
anonymize_headers allow Content-Type Date Expires Host
anonymize_headers allow If-Modified-Since Last-Modified
anonymize_headers allow Location Pragma Accept
anonymize_headers allow Accept-Encoding Accept-Language
anonymize_headers allow Content-Language Mime-Version
anonymize_headers allow Retry-After Title Connection
anonymize_headers allow Proxy-Connection
Nota: non è possibile utilizzare ambedue le regole allow e deny. Tutte le linee anonymize_headers devono avere sempre lo
stesso secondo argomento. La regola base è che tutte le intestazioni sono autorizzate, quindi nessuna funzionalità di
anonymizing viene eseguita, con questo TAG è anche possibile anonimizzare lo user-agent ovvero il browser web
anonymize_headers deny User-Agent
vediamo ora il TAG fake_user_agent. Se viene resa anonima l'intestazione dello User-Agent utilizzando TAG
anonymize_headers molti server web potrebbero rifiutare la richiesta HTTP inoltrata da Squid. Per evitare questo disdicevole
inconveniente è possibile utilizzare degli artifizi, ecco un esempio concreto
fake_user_agent Nutscrape/1.0 (Commodore Vic20; 8-bit)

# ( da un'idea di Paul Southworth - [email protected] )
vediamo, dopo aver effettuato la cura intensiva, come si presenta il nostro browser sul web
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*

Accept-Encoding: gzip
Accept-Language: it,en
Accept-Charset: iso-8859-1,*,utf-8
User-Agent: Nutscrape/1.0 (Commodore Vic20; 8-bit)
Via: 1.0 proxy.merlino.bbs:3128 (Squid/2.3.STABLE1)
X-Forwarded-For: unknown
Host: www.delegate.org
Cache-Control: max-age=259200
Connection: keep-alive
14.3. Internet Junkbuster

Abbiamo già analizzato il fatto che un proxy server come Squid possa ricorrere all'utilizzo di diversi programmi esterni
(helpers).

Un ottimo sistema per proteggere la nostra privacy o la privacy aziendale è quello di affiancare a Squid un proxy server esterno
che è stato disegnato per filtrare in modo intelligente e costruttivo i cookies ed i banners pubblicitari. Internet Junkbuster è un
proxy server che può anche cooperare con Squid, le sue eccellenti potenzialità sono descritte molto dettagliatamente nella
documentazione on-line presso la URLs http://www.junkbuster.com/.
Anche sulla scorta di quanto abbiamo già scritto dobbiamo anche dire che la degenerazione del business sulla rete internet è
sopratutto identificabile nella pornografia, senza certo esprimere pareri in merito, purtroppo, sempre più spesso capita di
doversi trovare di fronte a banner pubblicitari a sfondo pornografico che, molto spesso, vengono anche visualizzati se si accede
a portali di carattere generalista.
Cerchiamo ora di analizzare alcune delle motivazioni che spingono gli amministratori di rete a bloccare i sistemi AD, AD è
l'acronimo di Advertising:
● Velocità: bloccando gli Advertising software la velocità di connessione al WWW aumenta, il browser web non deve
attendere inutilmente il caricamento dei banner pubblicitari
● Tranquillità: i banner pubblicitari sono disegnati appositamente per distrarre la nostra attenzione quindi sono in grado di
distrarre l'utente che naviga sul web
● Riservatezza: il Cookies vengono utilizzati dalle AD Networks per tracciare e registrare il nostro movimento sulla rete
internet, dunque vengono chiaramente utilizzati per invadere il campo della nostra privacy.
14.3.1. Definizioni ed albero delle directory, file di configurazione
Junkbuster è un proxy server che consente di inibire la visualizzazione dei banners pubblicitari e dei cookies, permette di
anonimizzazione gli accessi provenienti dalla nostra LAN/WAN, l'albero delle directory che portiamo come esempio è relativo
ad un sistema FreeBSD 4.10-STABLE
● /usr/local/sbin/junkbuster
è l'eseguibile di internet Junkbuster
● /usr/local/etc/rc.d/junkbuster.sh
è lo script di shell che consente di avviare il proxy server con l'avviamento del sistema
● /usr/local/etc/junkbuster
è la directory che contiene i files di configurazione
Provvediamo ad eseguire una configurazione ottimizzata del software editando i file di configurazione del di Junkbuster, che
vengono generalmente forniti con la distribuzuine senza garanzia alcuna e sono:
● /usr/local/etc/junkbuster/configfile
è il file di configurazione principale che definisce i parametri di massima

● /usr/local/etc/junkbuster/blockfile
è il file che contiene tutte le URL AD da bloccare
● /usr/local/etc/junkbuster/cookiefile
è il file dove si inseriscono i siti fidati dai quali si accettano i cookies
● /usr/local/etc/junkbuster/forwardfile
è il file dove si definisce il forward verso un proxy server esterno come squid
Nell'area /contrib è possibile trovare alcuni esempi
14.3.2. Verificare il funzionamento di Junkbuster
Per avviare Junkbuster sarà sufficente eseguire il comando
% /usr/local/etc/rc.d/junkbuster.sh start
ora potremmo configurare il nostro browser web preferito. Di seguito immaginiamo una configurazine tipica di chi naviga sul
web utilizzando Mozilla.
Avviare Mozilla, scegliere edit, preference, advanced e per finire utilizzare la sezione proxies procedendo alla configurazione
manuale del proxy. Nei campi HTTP-Proxy e Securiry Proxy inserire il valore 127.0.0.1 porta 8000 (l'impostazione di default
di Junkbuster è quella di rimanere in ascolto di eventuali richieste sulla porta 8000).
Per verificare la corretta installazione di Junkbuster utilizzare il browser web puntando al seguente indirizzo web http://
indirizzo-IP-Junkbuster/show-proxy-args, se tutto è correttamente configurato potrete visualizzare le specifice di
configurazione del prodotto.
Per utilizzare il proxy Junkbuster con le funzionalità di forwarding verso un'altro proxy come Squid va solo editato il file /usr/
local/etc/junkbuster/forwardfile, è anche possibile registrare in un file di log tutte le operazioni compiute da Junkbuster.
14.4. Privoxy
Privoxy è un proxy server studiato per la navigazione sul web e fornisce delle funzionalità avanzate per tutto quello che
concerne il filtraggio dei contenuti e la gestione della privacy. Privoxy si occupa di verificare il contenuto delle pagine visitate,
gestisce in maniera funzionale e manageriale i cookies, controlla gli accessi e rimuove ADS, banners, popups, pone rimedio
anche ad altre tecniche utilizzate dai pubblicitari per fidelizzare utenti sulla rete internet.
Privoxy è stato anche studiato per fornire la possibilità di eseguire delle configurazioni molto flessibili, può essere utilizzato sia
dagli utenti che dalle organizzazioni, questo proxy server è basato sul codice di Internet Junkbuster, di seguito vediamo alcune

specifiche relative ad un sistema FreeBSD 4.11-STABLE
● /usr/local/sbin/privoxy
è file eseguibile e può essere avviato con le seguenti opzioni
1. privoxy --help che consente di richiamare l'help in linea
2. privoxy --version che consente di ottenere informazioni sulla versione in uso sul nostro sistema
Se all'avviamento del programma non viene specificato alcun file di configurazione, Privoxy tenta di avviare il file config che
si trova nello stesso percorso del file eseguibile (nel nostro caso nella directory /usr/local/sbin/), nel caso si voglia utilizzare un
percorso specifico per il file di configurazione, Privoxy dovrà essere avviato indicando il percorso specifico del file di
configurazione.
% /usr/local/sbin/privoxy /usr/local/etc/privoxy/config
May 12 09:50:45 Privoxy(134705152) Info: loading configuration file
'/usr/local/etc/privoxy/config'
Per utilizzare le features di Privoxy il browser web necessita di una configurazione individuale che prevede l'ascolto su
localhost, porta 8180, la configurazione di Privoxy può essere modificata editando alcuni dei files di configurazione.
14.4.1. files di configurazione di Privoxy
Privoxy può essere configurato utilizzando diversi file di configurazione, di seguito proponiamo l'elenco completo:
% ls -l /usr/local/etc/privoxy/
total 84
-r--r--r-- 1 root wheel 30422 May 9 08:59 config
-r--r--r-- 1 root wheel 28456 May 9 08:42 default.action
-r--r--r-- 1 root wheel 20005 May 9 08:42 default.filter
drwxr-xr-x 2 root wheel 1024 May 9 08:42 templates
-r--r--r-- 1 root wheel 2998 May 9 08:42 trust
config è il file di configurazione principale, default.filter e default.action vengono utilizzati per definire le eccezioni alle regole
principali che vengono utilizzate come regole base di Privoxy. Nel file config viene definita la directory che conterrà i files di
configurazione, la directory che conterrà il file dei logs, vengono anche definiti gli action.file, il filter.file, il jarfile (per la
gestione dei cookies).
Oltre all'indirizzo IP e alla porta sulla quale rimane in ascolto il proxy server, può anche essere definito il riferimento
dell'amministratore di sistema, il manuale utente e le informazioni a riguardo delle URL's che vengono filtrate. nel file config
file viene anche definita la direttiva di forward, direttiva con la quale si redirigono le richieste, dopo averne filtrato il contenuto,
verso il proxy server principale che di solito viene installato sulla stessa macchina.

Nel file default.action viene inclusa una sezione denominata "sites suffer from a bug in PHP", in questa sezione dovremo
inserire i portali internet realizzati in phpNuke o con altri CMS che utilizzano il PHP come linguaggio di scripting.
14.5. Ad Zapping con Squid

Ad Zapping è un redirector che intercetta e ridireziona gli advertising, i page counters e molti altri bugs propri del web. Questo
redirector comporta anche dei benefici a riguardo del risparmio della banda ed inoltre è un programma piuttosto semplice da
installare.
Ad Zapper è fondamentalmente uno script che può essere integrato facilmente con il Squid, il suo funzionamento si basa su un
algoritmo che contiene alcune espressioni regolari (regex), queste espressioni sono incluse all'interno dello script stesso.
14.5.1. Differenze con Junkbuster e Privoxy
Come abbiamo visto in precedenza, Junkbuster e Privoxy sono dei proxy servers specializzati nel mediare il filtraggio, per
funzionare questi proxy devono essere utilizzati nell'ambito di una cache gerarchica, in questo ambito possono essere definiti
come parent o sibling.
Tutte le richieste effettuate da parte dei client vengono dirette a Junkbuster o a Privoxy, questo fatto comporta un discreto
livello di complessità della configurazione e un certo rallentamento sulla rete, in quanto la richiesta, dopo essere stata purgata
dal proxy filtro, dovrà essere inoltrata dal sistema parent a Squid.
Se Junkbuster e Privoxy sono in grado di filtrare anche i cookies e le pagine web che contengono gli advertising, Ad Zapper è
solo in grado di eliminare gli advertising (ads).
14.5.2. Vantaggi della ridirezione
Abbiamo già accennato al fatto che una delle features più interessanti offerte da Squid è il ricorso al sistema di ridirezione. I
programmi esterni che eseguono materialmente la ridirezione, leggono le informazioni che vengono richieste dagli utenti e le
riscrivono inviandole a un percorso diverso. Se viene attivata l'opzione redirect_program, Squid consulterà il redirector che si
farà carico di intercettare gli ads ridirezionando e sostituendo il codice vietato. Il TAG redirect_program è facilmente attivabile
modificando il file di configurazione squid.conf
redirect_program /usr/local/libexec/squid_redirect
Il path dovrà essere rimpiazzato con il percorso dell'applicazione che utilizzeremo per la ridirezione delle richieste
14.5.3. Prerequisiti di Ad Zapping

I prerequisiti di sistema richiesti da Ad Zapping sono
● Linguaggio Perl (http://www.cpan.org/)
L'installazione di Ad Zapping è piuttosto semplice in quanto si provvede all'installazione dello script e si aggiunge nel file di
configurazione di Squid il TAG redirect_program. Successivamente sarà necessario riavviare il proxy per attivare l'Ad
Zapping. Esistono diverse versioni già customizzate dello script Ad Zapping per diversi Sistemi Operativi
● FreeBSD - è possibile installare il ports dell'applicazione
maggiori informazioni relative al ports alla URLs http://www.freebsd.org/cgi/url.cgi?ports/www/adzap/pkg-descr
● NetBSD - è possibile installare il package dello zapper
maggiori informazioni relative al package alla URLs ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/www/adzap/

README.html
● GNU Linux/Debian - è possibile installare il package deb dello zapper
Lo script originale può essere prelevato dalla URLs del progetto http://adzapper.sourceforge.net/#download
14.5.4. installare Ad Zapping
In questo caso di studio proponiamo l'installazione dello script Ad Zapping sul Sistema Operativo FreeBSD, la procedura è
piuttosto semplice. Digitiamo i seguenti comandi nella directory contenente il ports di adzap
% cd /usr/ports/www/adzap
Ad Zapping è ora installato, per attivare la ridirezione è necessario editare il file di configurazione squid.conf ed inserire lo
script adzap utilizzando il TAG redirect_program. Di seguito vediamo gli script che ha provveduto ad installare la procedura di
configurazione
% cd /usr/local/libexec
% ls
total -------
drwxr-xr-x 9 root wheel 512 Feb 11 11:29 ./
drwxr-xr-x 7 root wheel 512 Feb 5 06:27 ../
-r-xr-xr-x 1 root wheel 2551 Feb 11 11:29 adzap*
drwxr-xr-x 2 root wheel 512 Feb 3 06:14 squid/
-r-xr-xr-x 1 root wheel 113798 Feb 11 11:29 squid_redirect*
Il programma di installazione e configurazione ha generato 2 files, adzap e squid_redirect. Per avviare correttamente la

procedura di ridirezione modificheremo il file di configurazione squid.conf
redirect_program /usr/local/libexec/squid_redirect
redirect_children 5
per rendere operativa la modifica ed iniziare ad utilizzare il redirector
% squid -k reconfigure
da notare che il file
/usr/local/libexec/adzap
contiene tutte le impostazioni necessarie al corretto funzionamento di Ad Zapper, tra le variabili citiamo
ZAP_BASE=http://adzapper.sourceforge.net/zaps
con questa variabile è possibile definire un percorso di un server web, questo consente di visualizzare dei messaggi o delle
immagini in sostituzione degli advertising. Se si esegue un web server sulla stessa macchina dove è in funzione Squid
(consigliato), si procederà a copiare i files *.{html,js,gif} dal percorso ${PREFIX}/share/examples/adzap direttamente nella
DirectoryRoot del webserver. Successivamente modificheremo la variabile ZAP_BASE contenuta nel file di configurazione /
usr/local/libexec/adzap
% cd /usr/local/www/data-dist/
% mkdir zaps
% cd /usr/local/share/examples/adzap/
% cp * /usr/local/www/data-dist/zaps/
Ecco la variabile modificatata
ZAP_BASE=http://127.0.0.1/zaps/
14.6. Fornire agli utenti un servizio di Web Caching anonimo

Sulla rete internet è anche possibile trovare dei sistemi di webcache che consentono agli utenti di rendere anonima la loro

navigazione, molti di questi sistemi naturalmente utilizzano Squid. Possiamo configurare Squid come un sistema proxy
anonimizzante impostando alcune direttive all'interno del file configurazione squid.conf
● la direttiva cache_store_log
tutte le attività effettuate da Squid vengono memorizzate sempre nello storage manager. Possiamo visualizzare quali
oggetti sono stati memorizzati all'interno del cache storage, per disabilitare questa opzione possiamo utilizzare il valore
none
● la direttiva client_netmask
client_netmask 0.0.0.0
il netmask degli indirizzi ip dei client viene sempre memorizzato all'interno nei files di log di Squid nonchè nei
messaggi di output del cachemgr o dello squidclient. Per proteggere la privacy degli utenti è possibile modificare questo
valore di default, il valore netmask pari a 255.255.255.255 eseguirà il log degli indirizzi ip completi dei client che si
connettono a Squid, qualora non volessimo loggare alcun indirizzo ip dei client il valore del client_netmask deve essere
impostato a 0.0.0.0
● la direttiva http_access
acl all src 0/0

abbiamo già trattato questo tipo di direttiva nel capitolo relativo alle regole di accesso al proxy server. Normalmente
questa direttiva viene impostata a deny ma un proxy anonimizzante consente il libero accesso a tutti gli utenti
● la direttiva forwarded_for
forwarded_for off
se questa direttiva viene impostata ad on Squid includerà l'indirizzo IP del sistema client negli headers delle richieste
HTTP per i quali esegue il forward, come default l'headers della richiesta HTTP inviata da Squid contiene questa
informazione: X-Forwarded-For: 192.1.2.3. Impostando il valore di questa direttiva ad off fa in modo che l'headers
della richiesta HTTP venga modificato per fornire questo tipo di informazione: X-Forwarded-For: unknown
● la direttiva client_db

client_db off
impostando il valore di questa direttiva ad off verrà disabilitato il database che registra i tutti i dati relativi alle
connessioni che vengono effettuate dai client, il valore di default è client_db on.
Queste direttive consentono a Squid di nascondere sia l'indirizzo IP del sistema da cui parte la connessione HTTP, che
disabilitare il relativo logging delle connessioni che vengono dirette al proxy server (tutti gli indirizzi IP dei client che
utilizzano Squid sono pari a 0.0.0.0).
Capitolo 15. Comunicare con altri proxy server

15.1. Preambolo
Abbiamo già visto in precedenza che Squid fa suo il concetto di cache gerarchiche grazie al supporto per il protocollo ICP
(Internet Cache Protocol). Concettualmente sappiamo che l'apparato di webcache, che non dispone delle pagine richieste, si
collega direttamente con il server web di origine ove risiedono le pagine.
Neighbours e Peer sono dei sinonimi che identificano diversi sistemi di webcache in relazione tra loro, i termini parent e sibling
definiscono il livello di parentela tra le cache. In una cache gerarchica, il proxy può comunicare con altri proxy server, questa
situazione può rendere più veloce l'accesso alle pagine web richieste dagli utenti, riducendo sia il traffico HTTP che il relativo
tempo d'attesa per l'accesso alla rete da parte degli utenti.
15.2. Esempi e relazioni tra webcache

Dei sistemi in relazione di sibling[31] richiedono solamente gli oggetti presenti nella cache e non eseguono il forward delle
cache MISS[32]. In questo esempio configureremo alcuni sistemi proxy in modalità sibling, modalità attraverso la quale uno
dei proxy può essere configurato come fratello germano di un altro sistema di webcache. Organizzazioni che sono in stretto
rapporto commerciale possono configurare i loro sistemi di webcache con questa modalità. Il TAG cache_peer consente di
specificare i proxy server con i quali ci si vuole mettere in relazione
cache_peer proxy.dominio1.com parent 3128 3130
il TAG cache_peer indica che la nostra webcache interrogherà il server padre proxy.dominio1.com utilizzando il sistema di
relazione parent (padre). Squid comunica con il proxy parent utilizzando la porta 3128 per il protocollo HTTP e le
informazioni trasmesse con il protocollo ICP vengono scambiate tramite la porta 3130

cache_peer proxy.dominio2.com sibling 8080 3130
In questo caso il TAG cache_peer si riferisce ad un tipo di configurazione che definisce l'host proxy.dominio2.com come proxy
in relazione sibling (fratello germano) che rimane in ascolto sulla porta 8080 per quello che concerne il protocollo HTTP e
scambia le informazioni relative al protocollo ICP utilizzando la porta 3130.
Il Proxy Server Squid può essere configurato per effettuare richieste contemporanee a diversi sistemi di webcache, siano esse in
modalità parent che sibling, nel caso non si desideri utilizzare alcuna cache in rapporto di peering con la nostra sarà necessario
eliminare TAG cache_peer.
Nella maggior parte dei casi la configurazione di una cache gerarchica è piuttosto difficoltosa e può anche divenire un punto
critico, sopratutto se trattiamo gerarchie di livello nazionale o internazionale. In una WAN l'utilizzo delle cache gerarchie e del
protocollo ICP può divenire uno strumento potente e flessibile per la gestione delle ridondanze e della sicurezza. Nell'esempio
in calce, al fine di ottimizzare al massimo i tempi di risposta, Squid prima accede alla cache parent ed esegue una semplice
query con la quale verifica l'esistenza dell'oggetto[33] richiesto. Nel caso ottenga una HIT[34] preleva l'oggetto dalla parent
cache, se ottiene un MISS scarta la richiesta, il TAG default no-query consente di scartare una MISS lasciando al proxy il
compito di recuperare l'oggetto dal server web di origine.
cache_peer proxy.domain.com parent 3128 3130 default no-query

prefer_direct off
nel caso si disponga di una cache installata presso il proprio ISP (Internet Service Provider) è anche possibile configurare Squid
in modalità parent per ridurre i tempi di consultazione. Nel caso si disponga di una linea dedicata con tariffazione a consumo
sarà quindi possibile occupare una minore quantità di banda e ridurre i costi.
Per qualsiasi altra informazione sulle cache gerarchiche si faccia riferimento al documento Configuring Hierarchical Squid
Caches di Duane Wessels disponibile alla URLs: http://www.squid-cache.org/Doc/Hierarchy-Tutorial/.
15.3. Alcune informazioni su IRCACHE

IRCACHE è un progetto di NLANR WebCaching, il progetto è stato originalmente costituito con un fondo dal National
Science Foundation (http://www.nsf.gov/), la direzione del progetto è stata affidata a Computer and Information Sciences and
Engineering (http://www.cise.nsf.gov/). A partire dal 1996 e sino al 2000, il progetto IRCache è stato amministrato
dall'Università di California di San Diego (http://www.ucsd.edu/) in collaborazione con la San Diego Supercomputer Center
(http://www.sdsc.edu/) ed il National Laboratory for Applied Network Research (http://www.nlanr.net/). Le FAQ relative a
questo progetto possono essere reperite alla URLs http://www.ircache.net/FAQ/.
Una gerarchia di web cache come quella di NLANR può fornire una fonte iniziale per relazionare il nostro Sistema di
webcache con un'altro proxy sia utilizzando la modalità sibling che la modalità parent. Unire il nostro Sistema di web cache
con un Sistema globale di NLANR migliorerà le prestazioni generali del nostro proxy server Squid. Abilitando alcune opzioni
nel file squid.conf potremo registrare la nostra cache all'interno del servizio NLANR

cache_announce 24
announce_to sd.cache.nlanr.net:3131
annunciare la propria cache non è come unirsi ad una gerarchia NLANR, possiamo unirci ad una gerarchia senza registrarsi
come servizio di cache NLANR. Per trovare le cache adiacenti alle nostre appartenenti ed appartenenti NLANR è stato istituito
il database NLANR (http://www.ircache.net/Tracker/), il motore di ricerca può essere interrogato alla URLs http://www.
ircache.net/Tracker/search.html.
15.4. Alcune informazioni sul Servizio di Cache Nazionale GARR

La Rete GARR, il cui acronimo significa Gestione Amplimento Rete Ricerca è composta da tutte le entità che rappresentano la
comunità accademica e della ricerca scientifica in Italia, le attività della Rete GARR sono gestite dal Consortium GARR e in
modo operativo dalla Direzione del Consortium GARR, maggiori informazioni sui compiti istituzionali del Consortium GARR
possono essere reperiti presso la URL http://www.garr.it/checosa/garr-b-checosa.shtml.
Il GARR offre il servizio di Cache Nazionale GARR, questo tipo di servizio è rivolto unicamente ai gestori delle cache
Dipartimentali o d'Ente. L'obiettivo è quello di aiutare gli amministratori dei sistemi di web cache, o anche di coloro che hanno
intenzione di creare questo tipo di servizio, a partecipare alla gerarchia nazionale GARR configurando le proprie cache per
l'utilizzo dei server centrali messi a disposizione dal GARR presso i 4 punti del backbone nazionale. I server si trovano nella
stessa sede del POP GARRB, e dunque di questi sono particolarmente vicini ai link nazionali ed internazionali. Sono
disponibili al peering verso le cache Dipartimentali o d'Ente 4 server centrali, si tratta di sistemi NetCache C720 (http://www.
netapp.com/products/netcache/), con circa 72G utili per il caching. Per utilizzare i server del servizio nazionale è sufficiente
aggiungere le seguenti righe nel file di configurazione squid.conf
cache_peer XX.cache.garr.it parent 3128 3130

cache_peer_domain XX.cache.garr.it !.garr.it !.akamai.net !.akamaitech.net
dove XX sta ad indicare una delle seguenti sigle
mi - Milano (dedicata agli enti afferenti al POP di Milano)

bo - Bologna (dedicata agli enti afferenti al POP di Bologna)
na - Napoli (dedicata agli enti afferenti al POP di Napoli)
rm - Roma (dedicata agli enti afferenti al POP di Roma)
il TAG cache_peer_domain prevede l'esclusione (!) del ricorso alla gerarchia per il dominio garr.it a cui appartengono i server
FTP dei mirror GARR, e per il dominio akamai.net (rete del gestore di CDN che ha dislocato i propri server in sede POP
GARRB). Maggiori informazioni a riguardo alla URLs http://www.cache.garr.it/guida.html.

Capitolo 16. Proxy trasparente

16.1. Preambolo
Prima di iniziare la trattazione di questo argomento, è nostra intenzione schematizzare il funzionamento del protocollo TCP/IP,
lo schema che riportiamo di seguito aiuterà il lettore a comprendere gli stati di rete nei quali opera il proxy trasparente.
L'interception caching è un acronimo di proxy trasparente. L'interception caching inizia a lavorare sul livello di trasporto di
rete ove qualsiasi pacchetto IP viene routato fra i vari nodi. Un router o uno switch di livello quattro può riconoscere i pacchetti
HTTP e deviarli verso Squid. Attualmente esistono quattro tipi di intercettamento
1. inline cache o switch di livello sette
2. switch di livello quattro
3. WCCP (Web Cache Coordination Protocol)
4. politiche di routing
uno dei problemi più importanti che oggi deve risolvere un amministratore di rete è quello di trovare un sistema automatico per
la configurazione del proxy server sulle macchine degli utenti. L'interception caching è una delle tecniche che viene
maggiormente utilizzata unitamente con il protocollo WPAD (Web Proxy Autodiscovery Protocol) che tratteremo
dettagliatamente nel seguito di questo libro. Intercettare le richieste dirette alla porta 80, solitamente utilizzata dai server HTTP,
per redirigerle verso Squid, può aiutare l'amministratore a tenere sotto controllo l'utilizzo della risorse web prevendo eventuali
abusi nel rispetto della policy e degli standard adottati all'interno dell'organizzazione. La tecnica del proxy trasparente
comporta diversi benefici come il funzionamento automatico con qualsiasi tipo di browser web, ma introduce anche diversi
livelli di complessità ed alcuni single point of failure. Di seguito analizzeremo molto dettagliatamente le inline cache, il
protocollo WCCP concludendo con le politiche di routing utilizzando i router della Cisco System, sarà compito del lettore
valutare la soluzione migliore per risolvere le proprie esigenze.
16.2. Concetto di inline cache

Una cache di questo tipo combina in un unico apparato sia il webcaching che le tecniche di routing e/o di bridging, questo
apparato può essere configurato con due o più interfaccie di rete, il classico esempio di inline cache è una macchina UNIX®
sulla quale viene eseguito Squid, questo tipo di device viene posizionato sul percorso di rete per consentirgli di catturare il

traffico HTTP e ridirezionarlo verso Squid. Non sono molti gli apparati dedicati disegnati per svolgere questo compito perchè
una inline cache può rappresentare un single point of failure. Molti produttori infatti raccomandano di utilizzare sistemi
sviluppati da terze parti come gli switch di livello quattro che garantiscono un maggior livello di disponibilità del servizio.
Possiamo progettare una inline cache a basso costo utilizzando dei semplici PC che vengono equipaggiati con GNU Linux o
FreeBSD e Squid proxy server. Qualsiasi sistema UNIX® è in grado di eseguire il routing tra diverse interfaccie di rete così
come la ridizione del traffico, ma se Squid va in errore ne risentirà tutto il traffico web che attraversa quel percorso della rete.
In dettaglio possiamo affermare che il transparent proxying è un termine piuttosto comune che descrive una metodologia con la
quale si posiziona un gateway tra la zona militarizzata (MZ) e la rete degli utenti o zona militarizzata di secondo livello (MZ-
L2) per controllare, filtrare e redirezionare il traffico HTTP.
La rete IP pubblica è la rete di proprietà dell'ISP (Internet Service Provider), il router è la porta di accesso che delimita la rete
pubblica dal nostro segmento di rete pubblico. Nella DMZ vengono mappati gli indirizzi pubblici, nella MZ gli indirizzi IP sono
quelli riservati alle reti private. Con questo sistema tutti gli accessi di tipo www verranno convogliati al gateway, il Transparent
Proxy funziona unicamente per le richieste di tipo HTTP. E' possibile paragonare la tecnica del transparent proxy ad uno switch
di livello sette. Si tratta in effetti di una apparecchiatura molto sofisticata che opera al livello sette del modello OSI, quindi
lavora sullo strato delle applicazioni. Per operare correttamente questo tipo di apparati hanno la necessità di tradurre gli
indirizzi internet e di interpretare il traffico IP. Il protocollo di trasporto TCP opera però sul quarto livello del modello OSI.
Uno switch di livello sette fornisce le stesse opzioni che uno switch di livello quattro offre solo addizionalmente. Nel caso della
tecnica del transparent proxy, Squid si istalla su una macchina che opera da gateway, questo tipo di configurazione viene
utilizzata nelle grandi LAN/WAN dove il numero dei PC client è molto elevato. I pacchetti inviati dai PC client che fanno
richiesta del protocollo HTTP vengono ridirezionati dal gateway o dallo switch di livello quattro, che nel caso specifico è
appunto incluso nella nostra macchina Linux o nel nostro sistema BSD dove viene eseguito Squid. Il processo di ridirezione dei
pacchetti non viene effettuato direttamente dal proxy server ma viene processato da una applicazione che si occupa di gestire le
regole del traffico IP, questo tipo di applicativo consente di filtrare e manipolare i pacchetti. Quando il Kernel del sistema
operativo riceve i pacchetti diretti verso la porta 80 verifica le regole di ridirezione ed aggiusta il pacchetto ricevuto
cambiandone la porta di destinazione. Se Squid è in ascolto sulla porta 3128 il traffico IP verrà intercettato e rediretto verso la
porta 3128 dove normalmente rimane in ascolto Squid. Per effettuare il setup del proxy trasparente è necessario effettuare due
attività
1. configurare l'applicazione che esegue il filtro dei pacchetti

2. configurare Squid
mostriamo ora uno schema esplicativo con il quale illustreremo il funzionamento switch di livello sette
tutte le richieste provenienti dalla rete mz-l2 e dirette verso la porta 80 dei sistemi che sono oltre il segmento di rete mz,
verranno manipolate dalla applicazione che esegue il filtro dei pacchetti e che lavora sia a livello tre che a livello quattro della
pila OSI, questi pacchetti vengono ridirezionati ed inviati alla porta 3128 dove normalmente rimane in ascolto Squid che lavora
invece al livello sette, ovvero al livello delle applicazioni della pila OSI.
16.2.1. L'applicazione che esegue il filtro dei pacchetti
E' necessario configurare l'applicazione che esegue il filtro dei pacchetti IP per accettare il traffico proveniente da qualsiasi
indirizzo e diretto verso la porta 80 e redigerlo verso la porta dove è in ascolto l'applicazione di cache (nel nostro caso la 3128).
Per effettuare questa attività sono necessarie delle applicazioni che consentono di gestire funzionalità avanzate come ipfiltering
e ipforwarding. In genere, questo tipo di applicazioni vengono fornite con il Kernel del sistema operativo. Facciamo ora una
piccola panoramica dei sistemi GNU Linux o dei sistemi BSD e UNIX® che consentono di gestire la tecnica del proxy
trasparente in maniera efficiente.
16.2.2. Alcune annotazioni
Prima di analizzare le varie applicazioni che eseguono il filtraggio dei pacchetti e di mostrare una serie di esempi pratici, si
rammenta al lettore che alcune delle soluzioni proposte in questo capitolo sono state testate con
● FreeBSD 4.9-STABLE, squid-2.5STABLE5 ed ipfw(8) per eseguire il filtraggio dei pacchetti
● Linux Red Hat 7.1, Kernel 2.4.20, Squid 2.3.STABLE4 ed ipchains(8) per eseguire il filtraggio dei pacchetti.
16.2.3. Filtraggio con GNU Linux
Come sappiamo GNU Linux è un Kernel che utilizza diverse applicazioni per il filtraggio dei pacchetti che sono in stretta

relazione con il tipo di Kernel utilizzato, le applicazioni più importanti sono
● iptables (netfilter) con il Kernel 2.4.x e 2.6.x
● ipchains con il Kernel 2.2.x e 2.4.x
● ipfwadm con il Kernel 2.0.x
16.2.4. Filtraggio con FreeBSD
I sistemi BSD ed i sistemi UNIX® utilizzano approcci differenti per eseguire il filtraggio dei pacchetti
● FreeBSD utilizza ipfw(8) e natd(8)
● gli altri sistemi BSD e UNIX® utilizzano ipf(8) congiuntamente con ipnat(8)
per abilitare la funzionalità di proxy trasparente è necessario compilare (o ricompilare) il Kernel o aggiungere dei moduli che
possono essere caricati dinamicamente. Ora vediamo come procedere per configurare un gateway FreeBSD con le funzionalità
di proxy trasparente, la FAQ è di Stefano Tagliaferri.
16.2.4.1. utilizziamo ipfw
La prima operazione da eseguire sarà quella di ricompilare il Kernel di FreeBSD utilizzando le opzioni IPFIREWALL,
IPFIREWALL_FORWARD ed IPDIVERT
# kernel firewalling support

options IPFIREWALL # firewall
options IPFIREWALL_VERBOSE # abilita il logging
options IPFIREWALL_FORWARD # enable t. proxy support
options IPDIVERT # divert sockets
ora utilizzeremo l'ipfw(8) per eseguire il forward dei pacchetti diretti verso la porta 80 direttamente sulla porta 3128 della
macchina FreeBSD dove Squid è in ascolto. La regola che dovremo applicare utilizzando il comando ipfw(8) è la seguente
% ipfw add fwd 192.168.0.254,3128 tcp from 192.168.0.0/24 to any www
per attivare le funzionalità di proxy trasparente dovremmo abilitare le funzionalità di firewalling ed il demone natd(8) di
FreeBSD aggiungendo le seguenti linee al file di init /etc/rc.conf

firewall_enable="YES"
firewall_type="/usr/local/etc/ipfw.rules"
natd_enable="YES"
natd_interface="xl0"
natd_flags="-f /etc/natd.conf"
procederemo con la creazione del file /etc/natd.conf con il quale definiremo la configurazione del demone natd(8), nel nostro
esempio trattiamo un sistema con una duplice interfaccia di rete (dual-homed host), dove l'interfaccia xl0 fa parte della rete
pubblica internet (outside) mentre l'interfaccia rl0 fa parte di una rete privata (inside). L'interfaccia pubblica (outside) è quella
che traduce gli indirizzi e le porte eseguendo il NAT (Network Address Translation) o il PAT (Port Address Translation). Per
definire le regole che verranno utilizzate dal demone natd(8) e per dare corso alla traduzione degli indirizzi e delle porte,
dovremo necessariamente creare un file di configurazione del natd(8) /etc/natd.conf
interface xl0
use_sockets yes
same_ports yes
in questo file viene definita l'interfaccia di rete che eseguirà il NAT (outside), le istruzioni use_socket yes e same_ports yes
sono fondamentali per il corretto funzionamento di alcuni protocolli applicativi (livello sette) come l'FTP (File Transfer
Protocol) e l'IRC (Internet relay chat). Ora dovremmo anche creare il file /usr/local/etc/ipfw.rules il cui contenuto dovrà essere
adattato ad una macchina che opera da gateway tra la LAN (local area network) e la WAN (rete pubblica) abilitando il demone
natd(8)
## ipfw - regole natd e transparent proxy

# xl0 - interfaccia sulla rete WAN (esegue il NAT)
# rl0 - interfaccia sulla rete LAN
#
add fwd 192.168.0.254,3128 tcp from 192.168.0.0/24 to any www
add divert natd all from any to any via xl0
add pass all from any to any via rl0
add pass all from any to any via xl0
192.168.0.254 è l'indirizzo IP della macchina che esegue Squid, rammentiamo al lettore che questo esempio non garantisce
alcuna misura di sicurezza per la rete interna, per configurare correttamente il firewall è necessario consultare la man page di
ipfw(8)
16.2.5. Filtraggio con altri sistemi UNIX®
L'autore di IPFilter è Darren Reed. IPFilter è una applicazione open source che è stata portata su diversi sistemi operativi
UNIX®, tra i più importanti possiamo citare FreeBSD, NetBSD, OpenBSD, BSD/OS, GNU Linux, Irix, SunOS, Solaris e
Solaris-x86. In questo caso di studio abbiamo utilizzato una macchina FreeBSD

16.2.5.1. utilizziamo ipf
Per utilizzare ipf(8) (http://coombs.anu.edu.au/ipfilter/) dovremmo compilare (o ricompilare) il Kernel abilitando le opzioni
IPFILTER e IPFILTER_LOG
# abilita il supporto ipfilter nel Kernel

options IPFILTER
options IPFILTER_LOG
per utilizzare le funzionalità di proxy trasparente con ipfilter è necessario compilare Squid con la seguente opzione di
configurazione
% ./configure --enable-ipf-transparent
dopo aver compilato (o ricompilato) Squid, dovremmo creare un file denominato /etc/ipf.rules, questo deve contenere le
seguenti linee
% pass in all
a questo punto creeremo un nuovo file dal nome /etc/ipnat.rules, questo deve contenere le seguenti linee
# rl0 è in nome dell'interfaccia di rete

rdr rl0 0.0.0.0/0 port 80 -> 192.168.0.254 port 3128 tcp
192.168.0.254 è l'indirizzo IP della macchina che esegue Squid, ora posizioniamoci nella directory /usr/local/etc/rc.d per creare
uno script che sia in grado di inizializzare le regole di firewalling che abbiamo appena definito
% ee ipfilter.sh
#!/bin/sh
ipf -Fa -E -f /etc/ipf.rules
ipnat -CF -f /etc/ipnat.rules
% chmod 755 ipfilter.sh
dopo aver impostato il modo del file a 755 (esecuzione) potremmo finalmente riavviare la macchina che al successivo reboot
sarà pronta per funzionare come proxy trasparente. Rammentiamo al lettore che questo esempio non garantisce alcuna misura
di sicurezza per la rete interna, per configurare correttamente il firewall è necessario consultare la man page di ipf(8).

16.2.6. Esempi di inline cache con Linux
In questa sezione possiamo analizzare alcuni esempi di configurazioni con GNU Linux , in particolare la tecnica del proxy
trasparente utilizza un software che esegue il filtraggio dei pacchetti ed in alcuni casi la tecnica del Network Address
Translation.
Questa FAQ è stata realizzata da Rodney van den Oever.
E' necessario compilare il Kernel con il supporto per il firewalling e la ridirezione dei pacchetti, è necessario impostare dei
parametri importanti in /usr/src/linux/.config
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Networking options
#
CONFIG_FIREWALL=y
# CONFIG_NET_ALIAS is not set
CONFIG_INET=y
CONFIG_IP_FORWARD=y
# CONFIG_IP_MULTICAST is not set
CONFIG_IP_FIREWALL=y
# CONFIG_IP_FIREWALL_VERBOSE is not set
CONFIG_IP_MASQUERADE=y
CONFIG_IP_TRANSPARENT_PROXY=y
CONFIG_IP_ALWAYS_DEFRAG=y
# CONFIG_IP_ACCT is not set
CONFIG_IP_ROUTER=y
è anche necessario abilitare l'opzione di IP Forwarding, un sistema per attivare questa funzionalità è quello di inserire una linea
simile alla seguente negli script di init del sistema
% echo 1 > /proc/sys/net/ipv4/ip_forward
a questo punto procuriamoci il software ipfwadm(8), per garantire il corretto funzionamento del sistema di filtraggio dei
pacchetti è necessaria la versione 2.3.0. Con ipfwadm(8) è possibile ridirezionare il traffico verso Squid utilizzando il seguente
comando

% ipfwadm -I -a acc -P tcp -D default/0 80 -r 3128
rammentiamo al lettore che questo esempio non garantisce alcuna misura di sicurezza per la rete interna, per configurare
correttamente il firewall è necessario consultare la man page di ipfwadm(8).
FAQ scritta da Martin Lyons.
E' necessario configurare il Kernel per utilizzare ipchains(8), la prima cosa da fare è quella di posizionarsi nella directory
contenente i sorgenti di GNU Linux
% cd /usr/src/linux
% make menuconfig
queste sono le opzioni più importanti da includere nella configurazione del Kernel
[*] Network firewalls

[ ] Socket Filtering
[*] Unix domain sockets
[*] TCP/IP networking
[ ] IP: multicasting
[ ] IP: advanced router
[ ] IP: kernel level autoconfiguration
[*] IP: firewalling
[ ] IP: firewall packet netlink device
[*] IP: always defragment (required for masquerading)
[*] IP: transparent proxy support
Il Kernel deve essere compilato con il supporto per il firewalling e devono essere inoltre abilitate le funzionalità di always
defragment che sono necessarie alla politica di masquerading, compileremo inoltre il supporto per il transparent proxy. E'
necessario abilitare la funzionalità di ipforwarding ed installare il pacchetto software ipchains(8). Il comando da utilizzare per
ridirezionare il traffico verso Squid è il seguente
% ipchains -A input -p tcp -s 0/0 -d 0/0 80 -j REDIRECT 3128
la regola -A input appende delle regole di entrata, l'opzione -p tcp esprime una corrispondenza con il protocollo TCP, le opzioni
-s e -d specificano l'indirizzo sorgente e quello di destinazione, utilizzando l'opzione 0/0 si esprime la corrispondenza con
qualsiasi indirizzo IP. Rammentiamo al lettore che questo esempio non garantisce alcuna misura di sicurezza per la rete interna,

per configurare correttamente il firewall è necessario consultare la man page di ipchains(8).
16.2.6.3. Configurare il proxy trasparente con Linux kernel 2.4.x e 2.6.x
FAQ di Daniel Kiracofe, Il documento di riferimento è: Transparent Proxy with Linux and Squid mini-HOWTO disponibile
alla URLs http://www.linuxdoc.org/HOWTO/mini/TransparentProxy.html.
Il Kernel deve essere compilato con i seguenti prerequisiti
● Networking support
● Sysctl support
● Network packet filtering
● TCP/IP networking
● Connection tracking (Under `ÌP: Netfilter Configuration'' in menuconfig)
● IP tables support
● Full NAT
● REDIRECT target support
● /proc filesystem support
l'opzione "Fast switching" deve essere disabilitata ed inoltre dovremmo abilitare la funzionalità del packet forwarding negli
script di init
% echo 1 > /proc/sys/net/ipv4/ip_forward
per un corretto funzionamento del proxy trasparente è necessario il pacchetto software iptables(8), il comando da utilizzare per
configurare l'applicazione che filtra i pacchetti e ridirezionare il traffico www verso Squid è il seguente
% iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
correttamente il firewall è necessario consultare la man page di iptables(8), maggiori dettagli sono reperibili alla URL http://
www.squid-cache.org/Doc/FAQ/FAQ-17.html#ss17.4.

16.2.7. Abilitare inline cache con Squid
Dopo aver configurato l'applicazione che esegue il filtraggio dei pacchetti vediamo come definire correttamente la
configurazione di Squid per eseguire in maniera efficente la tecnica del proxy trasparente. Di seguito mostriamo il TAG da
inserire nel file /etc/squid/squid.conf
http_port 3128
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
naturalmente le regole impostate sino ad ora consentiranno solo l'inoltro del traffico dei pacchetti IP diretti verso la sola porta
80. Nel caso ci si trovi in una LAN/WAN di medie o di grandi dimensioni è ipotizzabile supporre la necessità di lasciar passare
anche altri pacchetti IP. Per rendere possibile questo inoltro si utilizzano le funzionalità offerte dal NAT (Network Address
Translation), queste funzioni in ambiente Linux vengono supportate in parte dall'ipmasquerade mentre con i sistemi BSD si
utilizza natd(8) e ipnat(8).
16.2.8. L'ipmasquerade con LINUX kernel 2.2.x/2.4.x
Dopo aver mostrato come configurare i diversi Kernel di Linux siamo finalmente in grado di mostrare un esempio di tecnica di
mascheramento che consentirà il passaggio dei pacchetti di qualsiasi tipo verso la subnet 192.168.1.0/24, rete sulla quale
abbiamo attestato la rete dei server (MZ)
% ipchains -P forward DENY ipchains -A forward -p all -s 192.168.1.0/24 -d 0/0 -j

MASQ
gli indirizzi sorgenti che vengono identificati dall'opzione -s, vengono mascherati ricorrendo alla tecnica del Network Address
Translation. Nell'esempio successivo mostriamo come eseguire la tecnica del mascheramento consentendo il passaggio di
alcuni pacchetti TCP relativi ad alcune applicazioni di livello sette come ssh, telnet, ftp, smtp, pop3 ed https verso la subnet
192.168.2.0/24, rete sulla quale abbiamo attestato gli utenti finale(MZ-L2), la regola finale eseguirà il forward dei pacchetti
dalla porta 80 alla 3128.
% ipchains -A forward -p tcp -s 192.168.2.0/24 -d 0/0 --dport ssh -j MASQ

% ipchains -A forward -p tcp -s 192.168.2.0/24 -d 0/0 --dport telnet -j MASQ
% ipchains -A forward -p tcp -s 192.168.2.0/24 -d 0/0 --dport ftp -j MASQ
% ipchains -A forward -p tcp -s 192.168.2.0/24 -d 0/0 --dport smtp -j MASQ
% ipchains -A forward -p tcp -s 192.168.2.0/24 -d 0/0 --dport 110 -j MASQ
% ipchains -A forward -p tcp -s 192.168.2.0/24 -d 0/0 --dport 443 -j MASQ
% ipchains -A input -p tcp -s 0/0 -d 0/0 80 -j REDIRECT 3128

gli indirizzi sorgente che vengono identificati dall'opzione -s, vengono mascherati ricorrendo alla tecnica del Network Address
Translation, i pacchetti tcp provenienti da qualsiasi indirizzo sorgente e diretti verso qualsiasi indirizzo di destinazione (0/0)
vengono ridirezionati dalla porta 80 alla porta 3128. Ora rendiamo operativo Squid modificando il file /etc/squid/squid.conf
http_port 3128
httpd_accel_port 80
httpd_accel_uses_host_header on
correttamente il firewall è necessario consultare la man page di ipchains(8)
16.3. Gli switch di livello quattro

Gli switch normalmente lavorano a livello due (livello di datalink), uno switch di livello quattro invece esegue il forwarding dei
pacchetti basandosi sugli indirizzi IP o sulle porte TCP. uno switch di livello quattro può essere utilizzato per eseguire il
bilanciamento tra server (load balancing) e nel caso in cui Squid dovesse andare in errore lo switch si occuperà di ridirezionare
il traffico HTTP lasciandolo transitare per il suo naturale percorso. Gli switch di livello quattro possono essere tenuti sotto
controllo utilizzando diversi sistemi e diversi protocolli, tra i più importanti citiamo ARP, ICMP, TCP, HTTP, SNMP ed altri.
Tra le soluzioni commerciali citiamo i Cisco Local Director (http://www.cisco.com/en/US/products/hw/contnetw/ps1894/index.
html), F5 Networks BIG-IP (http://www.f5.com/f5products/bigip/), ServerIron 450-850 (http://www.foundrynet.com/products/
webswitches/serveriron/index.html) e RadWare Cache Server Director (http://www.radware.com/content/products/csd/default.
asp). Tra le applicazioni a codice libero citiamo LVS[35] eseguito su una macchina GNU Linux (http://www.linuxvirtualserver.
org/).
16.4. WCCP (Web Cache Coordination Protocol)

Si tratta di un protocollo di incapsulamento che è stato sviluppato dalla Cisco Systems e che viene implementato nei routers e
negli switch di livello quattro. WCCPv1 viene supportato da diversi vendors e viene incluso come componente di serie in tutti i
sistemi di webcache come Squid. Esistono due versioni del protocollo WCCP che è un protocollo aperto e viene documentato
dalla RFC 3040 (http://www.faqs.org/rfcs/rfc3040.html). Per utilizzare questo protocollo è comunque richiesta la licenza di
utilizzo dalla Cisco Systems. Il protocollo WCCP si compone di due parti, il protocollo di controllo e la ridirezione del traffico,
il protocollo di controllo utilizza tre tipi di messaggi
HERE_I_AM
I_SEE_YOU
ASSIGN_BUCKETS
l'applicazione di cache avvisa della sua presenza lanciando un messaggio I_SEE_YOU, il router e Squid continuano a
scambiare messaggi periodicamente per verificare il loro livello di interconnessione, grazie a questo sistema il router riconosce

lo stato operativo di Squid e può quindi eseguire la deviazione del traffico HTTP verso la device di webcache. WCCP non
necessita che il proxy server sia connesso direttamente con il router perchè i pacchetti deviati vengono incapsulati con il
protocollo GRE che è l'acronimo di Generic Routing Incapsulation - RFC 2784 (http://www.faqs.org/rfcs/rfc2784.html) ed il
sistema operativo che esegue Squid deve essere in grado di interpretare i pacchetti GRE che riceverà dal router. Il protocollo
WCCP è stato codificato per deviare solo i pacchetti TCP che vengono identificati con la porta di destinazione 80 (ovvero
quella solitamente utilizzata dai server HTTP). I pacchetti incapsulati vengono inviati a Squid che esegue la decodifica del
protocollo GRE per interpretare correttamente i pacchetti TCP. Il protocollo WCCP supporta inoltre il clustering degli apparati
di webcache e le tecniche di load balancing: un router sul quale viene abilitato il protocollo WCCP è in grado di deviare il
traffico verso diversi sistemi Squid. Grazie al messaggio I_SEE_YOU il router notifica alle webcache la presenza di altri
apparati, la macchina Squid configurata con l'indirizzo IP più basso viene automaticamente designata come cache master. Il
protocollo WCCP supporta la rilevazione dei guasti, Squid invia un messaggio del tipo HERE_I_AM ogni 10 secondi, se il
router non riceve questo messaggio per una durata massima di 30 secondi marca come indisponibile (bad) la cache designata
come master, la richiesta non verra dunque deviata verso la macchina Squid al momento indisponibile.
16.4.1. Configurare WCCP con Cisco IOS
WCCPv1 è supportato dal sistema operativo Cisco IOS nelle sue versioni a partire dalla 11.1(19) e successive, il protocollo
WCCPv2 viene pienamente supportato dal sistema operativo Cisco IOS a partire dalla versione 12.0(4).
In questo esempio possiamo vedere la configurazione del protocollo WCCPv1 per il sistema operativo Cisco IOS 11.x
ip wccp enable
!
interface fastethernet0/0
ip wccp web-cache redirect
In questo esempio invece vediamo la configurazione più comune del protocollo WCCPv1 per il sistema operativo Cisco IOS 12.
x
ip wccp version 1
ip wccp web-cache
!
interface fastethernet0/0
ip wccp web-cache redirect out
il sistema operativo Cisco IOS Release 12.2 consente di abilitare le funzionalità WCCPv1 o WCCPv2 utilizzando il comando ip
wccp version. La configurazione automatica del protocollo WCCPv1 è stata sostituita, l'interfaccia del router utilizzata in
questo esempio (fastethernet 0/0) può non essere adeguata alla Vostra installazione.
16.4.2. Configurare WCCP con Squid
Dopo aver configurato il router analizziamo i TAG che consentono di attivare il protocollo WCCPv1 con Squid, si rammenta

che il protocollo WCCPv2 verrà implementato nelle future versioni di Squid (http://devel.squid-cache.org/projects.
html#visolve_wccpv2)
wccp_router 192.168.1.254
wccp_version 4
il TAG wccp_router indica l'indirizzo IP del router sul quale è stato abilitato il protocollo WCCP, il TAG wccp_version
identifica il tipo di versione. Il sistema operativo Cisco IOS 11.2 supporta unicamente la versione 3, Squid viene normalmente
compilato con il supporto al protocollo WCCP abilitato, non dimentichiamo che, se si decide di utilizzare il protocollo WCCP,
non sarà possibile abilitare alcun modello di autenticazione.
16.4.3. Abilitare l'interfaccia GRE con FreeBSD
Se si intende utilizzare il protocollo WCCP con FreeBSD sarà necessario compilare il Kernel del sistema operativo abilitando il
supporto GRE. A partire dalla versione 4.7 di FreeBSD, l'istruzione che consentirà di abilitare il protocollo GRE nel file che
definisce le impostazioni del Kernel (/usr/src/sys/i386/conf/GENERIC) sarà
pseudo-device gre #IP over IP tunneling
a questo punto dovremmo configurare FreeBSD per stabilire un tunnel GRE tra il router e la macchina che esegue Squid
% ifconfig gre0 create

% ifconfig gre0 <Host-IP> <Router-IP> netmask 255.255.255.255 up
% ifconfig gre0 tunnel <Host-IP> <Router-IP>
% route delete <Router-IP>
dove <Host-IP> è l'indirizzo IP della macchina che esegue Squid e <Router-IP> è l'indirizzo IP del router che intercetta i
pacchetti HTTP.
16.4.4. Abilitare l'interfaccia GRE con Linux
Il Kernel di Linux 2.2 supporta l'incapsulamento GRE soltanto se il modulo relativo verrà compilato nel Kernel. Per assicurarsi
che il codice GRE sia stato compilato staticamente oppure come modulo dinamico del Kernel è possibile utilizzare il seguente
comando
% modprobe ip_gre

le versioni 2.4 del kernel di linux vengono fornite con una pseudo interfaccia GRE ma questa non è comunque in grado di
operare per eseguire la decodifica dei pacchetti GRE che vengono inviati durante una sessione WCCP. Il progetto Squid
fornisce un modulo WCCP specifico per il kernel di Linux (http://www.squid-cache.org/WCCP-support/Linux/). Sarà
necessario compilare questo file http://www.squid-cache.org/WCCP-support/Linux/ip_wccp.c come modulo del kernel di
Linux posizionandolo nella directory dei sorgenti del kernel per poi eseguire il comando make modules. Il passo successivo è
quello di caricare il modulo nella memoria del kernel utilizzando il comando insmod(8).
% insmod ip_wccp.o
il modulo ip_wccp accetta i pacchetti GRE/WCCP da qualsiasi indirizzo sorgente pertanto qualsiasi utente è in grado di inviare
del traffico WCCP al nostro proxy, per proteggerci utilizzeremo il comando iptables(8)
% iptables -A INPUT -p gre -s 192.168.1.254 -j ACCEPT

% iptables -A INPUT -p gre -j DROP
dove l'indirizzo IP 192.168.1.254 è l'indirizzo del nostro router, potremmo salvare la nostra regola utilizzando il comando
service
% service iptables save
a questo punto dovremmo configurare Linux per stabilire un tunnel GRE tra il router e la macchina che esegue Squid
% iptunnel add gre1 mode gre remote <Router-IP> local <Host-IP> dev <interface>
% ifconfig gre1 127.0.0.2 up
dove <Router-IP> è l'indirizzo IP del router che intercetta i pacchetti HTTP, <Host-IP> è l'indirizzo IP della cache e
<interface> è il nome dell'interfaccia di rete che riceve questi pacchetti (molto probabilmente eth0).
16.5. Policy di routing con i router Cisco

Un router è in grado di eseguire delle operazioni di forwarding dei pacchetti basandosi su informazioni differenti dal semplice
indirizzo IP di origine o di destinazione, una politica di routing può consentire di impostare dei percorsi differenti per alcuni
pacchetti che rispondono a determinati requisiti, un router è dunque in grado di dirottare i pacchetti ragionando anche sulla
porta di destinazione del pacchetto stesso. Questa funzionalità può essere abilitata utilizzando le regole del sistema operativo
Cisco IOS, è bene ricordare che alcune versioni di questo sistema operativo possono risultare incompatibili con questa opzione
perché troppo vecchie.
La FAQ che stiamo per illustrare è stata realizzata da John Saunders, la configurazione proposta lavora correttamente con il

sistema operativo Cisco System IOS 11.1 e successivi. La prima attività da svolgere è procedere con la creazione di una access-
list che consentirà al router di selezionare il traffico da deviare verso la macchina che esegue Squid
access-list 110 deny tcp host 192.168.102.3 any eq www

access-list 110 permit tcp any any eq www
192.168.102.3 è l'indirizzo IP della macchina che esegue Squid, la prima linea della ACL esclude i pacchetti con indirizzo
sorgente 192.168.102.3 destinati alla porta 80 (www), la seconda linea confronta con tutti gli altri pacchetti destinati alla porta
80. Dopo aver impostato una access-list possiamo definire una route-map
route-map proxy-squid permit 10

match ip address 110
set ip next-hop 192.168.102.3
per rendere operativa la configurazione è necessario applicare la route-map sull'interfaccia connessa con la LAN dove è stato
installato Squid
interface Ethernet0
ip policy route-map proxy-squid
di seguito sottoponiamo al lettore un'altro esempio completo, dove viene definita una route-map denominata proxy-redirect,
quest'ultima specifica come salto successivo la macchina dove è in esecuzione il proxy server Squid
!
access-list 110 deny tcp any any neq www
access-list 110 deny tcp host 192.168.1.13 any
access-list 110 permit tcp any any
!
route-map proxy-redirect permit 10
match ip address 110
set ip next-hop 192.168.1.13
!
interface Ethernet0
ip policy route-map proxy-redirect
!
in questo caso di studio la macchina che esegue Squid ha l'indirizzo IP 192.168.1.13. Il router redirige il traffico destinato alla
porta 80 (www) verso la porta dove rimane in ascolto Squid. Questo tipo di policy di routing degrada le prestazioni del router
ed in molte versioni di Cisco IOS questo tipo di regola utilizza un tempo CPU piuttosto elevato.

Capitolo 17. Reverse proxy

17.1. Server HTTPD e content caching
La funzionalità di acceleratore o di Reverse Proxy consente agli amministratori di Sistema di utilizzare Squid come servizio
HTTP o HTTPS dedicato, tale opzione di configurazione lascia inalterate le funzionalità di proxy tradizionale di Squid. Nella
fattispecie l'acceleratore può essere fondamentale nelle piattaforme di security ispirate al modello TIER (2-TIER/3-TIER),
inoltre un Reverse Proxy riduce l'utilizzo e l'overload di uno o più server web di backend.
Il modello TIER prevede il frazionamento dei servizi da offrire sul Web e viene implementato in quelle WAN interconnesse
con la rete internet che prevedono una zona demilitarizzata (DMZ) posizionata a valle del firewall che la controlla e ne
garantisce il livello di sicurezza.
Ecco un esempio per un modello TIER-3. l'acceleratore si trova zona demilitarizzata (DMZ) e viene contattato dagli utenti che
accedono dalla rete IP pubblica, il Reverse Proxy si occupa di contattare direttamente il web server che si trova all'interno di
una rete a maggior livello di protezione (MZ). Il Reverse Proxy installato nella DMZ ed il Proxy configurato nella MZ possono
essere in peering tra loro grazie al protocollo ICP e alla modalità parent o sibling. Nella DMZ sono posizionati gli host che
offrono i servizi internet come HTTPD, DNS, SMTP e pop3. L'acceleratore sostituisce il server web reale ed è l'unico host
autorizzato ad attraversare il firewall per contattare il server web situato all'interno della rete a maggior livello di protezione
(MZ). Il server web presente nella rete MZ viene consultato indirettamente dagli utenti internet tramite le funzionalità del
Reverse Proxy Squid.
17.2. Reverse Proxy

Per configurare ed attivare le funzionalità di reverse Proxy è necessario istruire Squid affinchè rimanga in ascolto di richieste
sulla porta 80, per fare questo utilizzeremo il TAG http_port [port]
http_port 80
nel caso in cui Squid sia stato installato su un server che è stato configurato con diverse interfacce di rete è possibile
configurare il proxy per rimanere in ascolto su uno specifico indirizzo IP, questa funzionalità può essere attivata utilizzando il
TAG http_port [IP]:[port]

http_port 192.168.1.1:80
sullo stesso server è possibile configurare Squid come reverse Proxy ma è necessario installare anche un server web. Affinché
la soluzione di Reverse Proxy funzioni è necessario avviare il web server ma lo stesso deve rimanere in ascolto su una porta
non standard, a tale scopo utilizzeremo la porta 81. Per configurare il web server si faccia riferimento alle istruzioni del
prodotto specifico. Con il TAG httpd_accel_host ed il TAG httpd_accel_port indichiamo a Squid il server web da accelerare
httpd_accel_host 127.0.0.1
httpd_accel_port 81
possiamo anche utilizzare questa sintassi
httpd_accel_host localhost
httpd_accel_port 81
in genere il server web o i servers web, come impone una architettura ridondata, vengono installati su una o più macchine
diverse da quella sulla quale è in ascolto Squid. Se vogliamo accelerare una macchina diversa, Squid può essere configurato
come Reverse Proxy e rimanere in ascolto sulla porta 80. Il contenuto visualizzato dai client http che contatteranno la porta 80
di Squid è quello presente sul server Web che fisicamente risiede su un'altra macchina
httpd_accel_host nomemacchina.nomedominio.it
httpd_accel_port 80
Se si vuole utilizzare Squid sia come server web che come Proxy Server è necessario abilitare il TAG httpd_accel_whit_proxy
on
httpd_accel_whit_proxy on
riavviamo Squid e verifichiamo se la nuova configurazione stia funzionando correttamente
% netstat -t -l | grep http
tcp 0 0 *:http *:* LISTEN
l'output del comando netstat(8) dimostra che la configurazione di acceleratore http sta funzionando correttamente, a questo

punto potremmo collegarci al Reverse Proxy.
17.3. SSL Reverse Proxy

A partire da squid-2.5.STABLE1 è stato abilitato il supporto SSL[36], utilizzando il TAG https_port è possibile configurare
Squid come acceleratore per un server HTTP di backend, questa opzione sarà disponibile solo se Squid verrà compilato con la
seguente opzione di configurazione
% ./configure --enable-ssl
in alcuni casi può essere necessario specificare il percorso delle librerie openssl
% ./configure --enable-ssl --with-openssl=/usr
abbiamo già detto che questo tipo di opzione funziona solo quando Squid viene avviato nella modalità di acceleratore, nel file
di configurazione squid.conf possono essere definiti indirizzi di socket multipli inclusi i percorsi dei certificati digitali. Tali
certificati devono necessariamente essere in formato PEM[37]. Il TAG da utilizzare è https_port [port] cert=path key=path
https_port 443 cert=/usr/local/squid/etc/key.crt \

key=/usr/local/squid/etc/key.key
prima di attivare Squid come acceleratore sulla porta 443 dobbiamo necessariamente generare i certificati digitali in formato
PEM
% openssl req -x509 -newkey rsa:2048 -keyout key.key -out key.crt -days 365 -nodes
Using configuration from /usr/share/ssl/openssl.cnf
Generating a 2048 bit RSA private key
................................................................................+++
......+++
writing new private key to 'key.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:IT
State or Province Name (full name) [Berkshire]:Italy
Locality Name (eg, city) [Newbury]:Mia_Città

Organization Name (eg, company) [My Company Ltd]:Organizzazione

Organizational Unit Name (eg, section) []:Networking
Common Name (eg, your name or your server's hostname) []:host.dominio.net
Email Address []:[email protected]
spostiamo i certificati digitali appena generati nella directory dove vengono memorizzati i file di configurazione di Squid
% mv key.* /usr/local/squid/etc/
con il TAG httpd_accel_host impostiamo il server web che intendiamo accelerare, con il TAG httpd_accel_port definiamo la
porta sulla quale rimane in ascolto httpd_accel_host
httpd_accel_port 80
se eseguiamo Squid come acceleratore e disponiamo di un singolo server di backend, impostiamo il TAG
httpd_accel_single_host sul valore on. Questa impostazione determina che le richieste vengano ruotate direttamente all'unico
server di backend disponibile. Se invece abbiamo diversi server di backend, il valore del TAG httpd_accel_single_host deve
essere impostato ad off, in questo caso dovremo utilizzare un sistema redirector per ruotare le richieste verso il server di
backend appropriato
httpd_accel_single_host off
nel caso volessimo utilizzare Squid sia come httpd accelerator che come proxy server, dovremmo utilizzare il TAG
httpd_accel_whit_proxy on
le richieste HTTP/1.1 includono un header denominato host, in realtà si tratta del nome dell'host che viene estrapolato dalla
URL. l'header host viene utilizzato per definire i virtualhost basati sul nome di dominio, se il nostro acceleratore fornisce un
servizio di domain based virtual hosts utilizzando lo stesso indirizzo IP, allora dovremo utilizzare il TAG
httpd_accel_uses_host_header on. E' necessario utilizzare questa opzione se si vuole utilizzare Squid come transparent Proxy
httpd_accel_uses_host_header off
eseguiamo il reload di Squid e verifichiamo se la nuova configurazione funziona correttamente

% netstat -t -l | grep https
tcp 0 0 *:https *:* LISTEN
come possiamo vedere dall'output del comando netstat(8) ora disponiamo di un server web che rimane in ascolto sulla porta
443 (SSL).
17.4. Esempi e situazioni reali

Ora proponiamo una interessante panoramica di esempi che possono essere implementati in situazioni reali, altri esempi sono
reperibili presso la URL http://www.visolve.com/ è particolare l'attenzione che deve essere prestata nella implementazione
delle ACL visto che in genere si può utilizzare l'acceleratore anche come proxy server.
17.4.1. Reverse Proxy di Server web o cluster HA installati su una macchina differente
il reverse proxy Squid funziona come acceleratore per un server web che rimane in ascolto su una macchina differente da
quella sulla quale opera Squid
http_port 80
httpd_accel_port 80
httpd_accel_single_host on
17.4.2. Reverse Proxy di server web installato sulla stessa macchina che esegue Squid
il reverse proxy Squid funziona come acceleratore per un server web installato sulla stessa macchina sulla quale viene eseguito
Squid

http_port 80
httpd_accel_port 81
httpd_accel_single_host on
17.4.3. Reverse Proxy per domini multipli
il reverse proxy Squid funziona come acceleratore per domini multipli puntando a diversi server web che si trovano a valle
dell'acceleratore e che possono essere più di uno, per far funzionare questo tipo di configurazione è necessario compilare Squid
con il supporto per il DNS interno
% ./configure --disable-internal-dns
questa è l'opzione di configurazione che installa l'eseguibile dell'external dnsserver, vediamo ora un'esempio per questo tipo di
configurazione
http_port 80
httpd_accel_port 80
ora grazie al sistema del domain name system (DNS) si seleziona e si definisce il reverse proxy per i rispettivi domini, ad un
indirizzo IP sulla rete pubblica internet possono corrispondere diversi nomi di dominio
www.merlinobbs.net 12.12.12.1
www.marsicalug.it 12.12.12.1
www.plutonet.org 12.12.12.1
definiamo delle entry nel domain name system a cui fa riferimento diretto il reverse proxy server. Sarà necessario configurare
un sistema DNS falso (fake DNS) che risolve i nomi per la rete interna nella quale sono installati i server web reali, è anche
possibile inserire delle entry nel file /etc/hosts.

www.merlinobbs.net 192.168.1.21
www.marsicalug.it 192.168.1.30
www.plutonet.org 192.168.1.7
Attenzione: utilizzando la funzione httpd_accel_host verrà disabilitato il proxy-caching e il protocollo ICP. Se volete abilitare
anche queste funzionalità si renderà necessario abilitare l'opzione httpd_accel_with_proxy.
17.4.4. SSL Reverse Proxy di un server web o di un cluster HA installato su una macchina
differente
il reverse proxy Squid funziona come acceleratore SSL per un server web che rimane in ascolto su una macchina differente da
quella sulla quale opera Squid
https_port 443 cert=/usr/local/squid/etc/key.crt \

key=/usr/local/squid/etc/key.key
httpd_accel_port 80
Capitolo 18. Proxy load balancer

18.1. Preambolo
Ipotizziamo ora di configurare una cache gerarchica nel contesto di una WAN di dimensioni ragguardevoli. Prima di fare
questo analizziamo le fondamenta della configurazione automatica dei browser web più comuni come Netscape ed Internet
Explorer.
18.2. WPAD protocol

Il Web Proxy Autodiscovery Protocol è un protocollo di livello 7 che è stato elaborato da un gruppo di produttori software
(Microsoft, RealNetworks, Sun Microsystem ed InkTomi.....) che consente all'utente finale di configurare il proprio browser
web in maniera trasparente, ovvero senza fare ricorso ad alcuna configurazione manuale. In particolare, tramite la modalità di
autoconfigurazione, è possibile definire automaticamente l'accesso al proxy server principale all'interno di un dominio (FQDN).
Il principio è molto semplice: il browser web, che implementa il protocollo WPAD, inizia la sua indagine interrogando il
sistema di risoluzione dei nomi, il Domain Name System (ISC Bind), alla ricerca del nome host wpad.

ecco un esempio di record A - ADDRESS (indirizzo IP)
wpad IN A 192.168.1.200
ecco un esempio di record CNAME (canonical name)
proxy IN A 192.168.1.100
wpad IN CNAME proxy
se esiste un record A (address) o un record CNAME (canonical name) corrispondente a tale nome host nell'ambito di un
dominio qualificato, il browser web cercherà di caricare il file di configurazione automatica direttamente dalla URLs
http://wpad/wpad.dat
Il server Web corrispondente al nome host wpad ha memorizzato nella sua Document root il file wpad.dat, Il browser web
cercherà di leggere quella URLs per auto configurarsi. Il browser web esegue le direttive scritte in Java script che sono
contenute in quel file. Naturalmente un browser web che non supporta Java o Java script non sarà in grado di autoconfigurarsi.
In tutti i casi un file wpad.dat o il file proxy.pac, per poter essere utilizzato, deve essere messo in linea su un server web
opportunamente configurato. Per far si che il browser web sia in grado di autoconfigurarsi è necessario aggiungere un
particolare tipo di mime-type che consente il caricamento e l'esecuzione del file wpad.dat come Javascript autoconfigurante.
Nel caso si utilizzi come server Web il comunissimo e potentissimo Apache è sufficiente editare il file /etc/mime.types
aggiungendo la seguente riga
application/x-ns-proxy-autoconfig pac dat
vediamo di seguito un esempio concreto di file proxy.pac o wpad.dat
function FindProxyForURL( url, host )

{
if( isPlainHostName( host ) || // no domain specification
dnsDomainIs( host, "mynet.com" ) || // MyNet local domain
shExpMatch( url, "https*" ) || // secure protocols
shExpMatch( url, "snews*" ) )
return "DIRECT";
else
return "PROXY calimero.mynet.com:3128; " +
"PROXY rocco.mynet.com:3128; " +
"DIRECT";
}

il file di autoconfigurazione punta su 2 proxy server diversi, vediamo ancora un esempio per la configurazione del DNS (ISC
Bind)
www IN A 192.168.10.25
;
wpad IN CNAME www
l'host www corrisponde all'indirizzo IP 192.168.10.25 ed il suo nome canonico (o alias) è wpad.
Attualmente, solo il browser Microsoft Internet Explorer supporta le funzionalità WPAD e l'Internet Draft che ne descrive le
carratteristiche é scaduto. Per maggiori dettagli sulla scrittura degli scripts riferirsi a Navigator Proxy Auto-Config File Format
(http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html).
Questi script di autoconfigurazione sono comunque supportati correttamente in modalità manuale dalla maggior parte dei
Browser Internet (Mozilla, Opera, Konqueror, etc.).
18.3. DHCP e configurazione automatica del browser

E' possibile utilizzare ISC DHCP (http://www.isc.org/products/DHCP/) per configurare automaticamente i browser web al
protocollo WPAD. Questa tecnica consente di configurare qualsiasi URL come PAC URL
option wpad code 252 = text;

option wpad "http://www.example.com/proxy.pac";
la modalità DHCP non lavora correttamente con diverse versioni di internet Explorer, la modalità DNS rimane quella
consigliata
18.4. Fail over e load balancer

In una WAN di dimensioni ragguardevoli, per garantire continuità del servizio ed affidabilità, è sempre consigliato installare un
sistema di Cluster in HA[38]. Data la complessità di questo tipo di configurazione o qualora non fosse possibile realizzare un
sistema così complesso, può essere una buona idea configurare un ambiente di fail over con relativo load balancer. Questo tipo
di configurazione garantirà agli utenti un corretto e costante utilizzo delle risorse della rete internet. Nel caso in cui il proxy 1
dovesse avere dei problemi i client andrebbero a recuperare le informazioni presenti nella cache di un'altro proxy sulla base
dello schema rappresentato nella seguente immagine

Sfruttando le specifiche del protocollo WPAD, le richieste HTTP, HTTPS ed FTP effettuate dai browser web e provenienti dalla
rete degli utenti (nuovola di rete celeste) verranno automaticamente instradate verso il server Web che è stato appunto
predisposto alle specifiche del protocollo WPAD, questo web server detiene nella Document root il Java script di Super
LoadBalancing che, come abbiamo visto in precedenza, consentirà ai browser web di utilizzare le funzionalità di URL hashing
ed eseguire il forward delle richieste http.
I due host che eseguono l'appliance Squid effettuano il forward della richiesta verso la rete internet attraversando il firewall.
Nel caso in cui uno dei due server proxy venisse a mancare (mancato funzionamento, manutenzione, upgrade software, upgrade
hardware....) subentrerebbe l'host 2.
In genere i due proxy server eseguono la cache in modalità gemella e comunicano tra loro tramite il protocollo ICP, le due o
più macchine che sono state adibite a fornire lo script di super Load Balancer dovranno eseguire delle configurazioni speculari.
E' fondamentale la configurazione del DNS ISC Bind (http://www.isc.org/products/BIND/) che esegue la risoluzione dei nomi
host
proxy1 IN A 192.168.10.4
proxy2 IN A 192.168.10.14
;
wpad IN CNAME proxy1
IN CNAME proxy2
il nome wpad è un nome canonico o alias per gli host proxy1 e proxy2 che, assieme al servizio Squid, eseguono anche una
copia del server web Apache. Di seguito ecco le specifiche logiche del super proxy cache a due vie da realizzato in una rete
geografica che può tranquillamente essere definita come WAN di medie dimensioni.

Ecco un dettaglio delle specifiche hardware e software adottate
Pentium III 500 Mhz 256 Mb RAM Pentium III 500 Mhz 384 Mb RAM
OS Linux (Kernel 2.4.x) OS Linux (Kernel 2.4.x)
Squid appliance 2.4 St. 6 patched Squid appliance 2.4 St. 6 patched
Supporto SNMP abilitato Supporto SNMP abilitato
n. 1 Disco EIDE da 10 Gb 5000 RPM n. 2 Dischi EIDE da 20 Gb 7200 RPM
64 Mb di cache_mem 96 Mb di cache_mem
2524 Mb di cache su FS EXT3 2500 Mb di cache su FS EXT3
Server httpd on board Server httpd on board
Di seguito un esempio di file proxy.pac realizzato dalla Sharp Corporation, ottimizzato per la configurazione Super proxy
server in modalità load Balancer.
/*
* Super Proxy Script
*
* by SHARP Corp.
*
* Take a look at http://naragw.sharp.co.jp/sps/
* for theory and operation.
*
*/
function FindProxyForURL(url, host)
{
/* your original script here */
if( dnsDomainIs( host, "dominio.com" ) ||
dnsDomainIs( host, "love.dominio.com" ) ||

dnsDomainIs( host, "localhost" ) ||

isPlainHostName( host ) ||
isInNet( host, "127.0.0.1", "255.255.255.255" ) ||
isInNet( host, "192.168.0.0", "255.255.0.0" ) )
return "DIRECT";
else
/* end of your original script */
var n = URLhash2(url) % 2;
if (n < 1)
return "PROXY proxy2.dominio.com:3128;PROXY proxy.dominio.com:3128;DIRECT";
if (n < 2)
return "PROXY proxy.merlino.bbs:3128;PROXY proxy2.merlino.bbs:3128;DIRECT";
}
/* make check sum of URL string */
/* v1.0 by SHARP Corp Copyright 1996-1997 */
function URLhash(name)
{
var cnt=0;
var str=name.toLowerCase(name);
if ( str.length ==0) {
return cnt;
}
for(var i=0;i < str.length ; i++) {
var ch= atoi(str.substring(i,i + 1));
cnt = cnt + ch; } return cnt ;
}
/*
URLhash2( ) for directory name hash computing version.
written by SHARP Corp in Feb 1997
Objects in a same directory will be accessed via the same proxy.

Use URLhash2( ) instead of URLhash( ) if you prefer to use persistent
connection in HTTP 1.1
http://www.sharp.co.jp/sample/test/img/mebius.gif
http://www.sharp.co.jp/sample/test/img/zaurus.gif
http://www.sharp.co.jp/sample/test/img/wiz.gif
<------------------------------------->
directory name hashing here
*/
function URLhash2(name) {
var cnt=0;
var dirptr=0;
var str=name.toLowerCase(name);
if ( str.length ==0) {
return cnt;
}
/* skip filename in directory */
for(var i=str.length - 1;i >=0 ; i--) {
if ( str.substring(i,i +1) == '/' ) {
dirptr = i+1 ; break;
}
}
for(var i=0;i < dirptr; i++) {

var ch= atoi(str.substring(i,i + 1));

cnt = cnt + ch;
} return cnt ;
}
function atoi(charstring) {
if ( charstring == "a" ) return 0x61; if ( charstring == "b" ) return 0x62;
if ( charstring == "c" ) return 0x63; if ( charstring == "d" ) return 0x64;
if ( charstring == "e" ) return 0x65; if ( charstring == "f" ) return 0x66;
if ( charstring == "g" ) return 0x67; if ( charstring == "h" ) return 0x68;
if ( charstring == "i" ) return 0x69; if ( charstring == "j" ) return 0x6a;
if ( charstring == "k" ) return 0x6b; if ( charstring == "l" ) return 0x6c;
if ( charstring == "m" ) return 0x6d; if ( charstring == "n" ) return 0x6e;
if ( charstring == "o" ) return 0x6f; if ( charstring == "p" ) return 0x70;
if ( charstring == "q" ) return 0x71; if ( charstring == "r" ) return 0x72;
if ( charstring == "s" ) return 0x73; if ( charstring == "t" ) return 0x74;
if ( charstring == "u" ) return 0x75; if ( charstring == "v" ) return 0x76;
if ( charstring == "w" ) return 0x77; if ( charstring == "x" ) return 0x78;
if ( charstring == "y" ) return 0x79; if ( charstring == "z" ) return 0x7a;
if ( charstring == "0" ) return 0x30; if ( charstring == "1" ) return 0x31;
if ( charstring == "." ) return 0x2e; return 0x20;
}
E' necessario sottolineare che questo tipo di configurazione non garantisce comunque alcuna ridondanza e non determina
nessun fattore di alta disponibilità del servizio.
Capitolo 19. Limitazione della banda per classi

19.1. Preambolo
E' possibile limitare i costi utilizzando al meglio le risorse di rete, una corretta gestione dell'ampiezza della banda disponibile
può essere la soluzione di molti problemi. Squid è anche in grado rispondere a questo tipo di esigenza in quanto può gestire la
banda disponibile. Per controllare l'ampiezza della banda Squid ricorre al TAG delay pools.
19.2. Squid ed i Delay pools

L'idea di realizzare questa interessante features è partita dalla Western Australian University che intendeva limitare i costi
riducendo il traffico. Il codice sorgente di questo hack fu introdotto nella versione 1 Squid e prendeva il nome di
DELAY_HACK. Nella versione 2 di Squid questa funzione ha preso il nome di delay pools. Nella versione 2.2 di Squid, il
codice del delay pools è stato totalmente riscritto per offrire maggiori performance ed affidabilità.

Per utilizzare questa funzionalità è necessario specificare la seguente opzione di ./configure
% ./configure --enable-delay-pools
e ricompilare Squid.
Attenzione: molto spesso i package binari forniti con le distribuzioni non sono compilati con il supporto per Delay pools.
Non è possibile limitare la velocità di una singola connessione HTTP ma è invece possibile limitare la banda per singole
workstation o di intere subnet. È inoltre possibile limitare la banda per singoli utenti o gruppi di utenti. Per ridurre l'utilizzo di
bandwidth su una specifica subnet viene definita una ACL che identifica la subnet stessa. Per limitare il traffico di una
specifica workstation si definisce una ACL che identifica quella macchina. Per limitare un gruppo di macchine è possibile
utilizzare un delay_pools di classe 2 o 3. Infine, per limitare il traffico di singoli utenti o gruppi di utenti, é possibile definire
delle ACL basate sull'autenticazione degli utenti e su ACL esterne.
19.2.1. Limitare la banda per singole connessioni a 128 kbps
Un esempio che limita la banda a 128 Kbps per singole connessioni provenienti da 64 subnet (partendo dall'indirizzo
192.168.0.0 per finire all'indirizzo 192.168.63.255), impostiamo le ACL che identificano il traffico da limitare
acl only128kusers src 192.168.1.0/255.255.192.0

acl all src 0.0.0.0/0.0.0.0
impostiamo il TAG delay_pools
delay_pools 1
delay_class 1 3
delay_access 1 allow only128kusers
delay_access 1 deny all
delay_parameters 1 64000/64000 -1/-1 16000/64000
19.2.2. Limitare la banda totale a 512 kbps
Vediamo ora un esempio con il quale limitiamo la banda totale di Squid a 512 Kbps, anche in questo caso impostiamo la ACL
che identifica il traffico da limitare
acl all src 0.0.0.0/0.0.0.0

delay_pools 1
delay_class 1 1
delay_access 1 allow all
delay_parameters 1 64000/64000 # 512 kbits = 64 kbytes per second
19.2.3. Limitare la banda con una linea a 2 Mbps
Ipotiziamo di avere a disposizione una connessione dedicata con una banda massima di 2 Mbps, definiamo ora alcune ACL che
ci consentono di identificare il traffico da limitare
acl outgoing src 192.168.100.2/255.255.255.255

acl student src 192.168.200.0/255.255.255.0
acl admin src 192.168.300.0/255.255.255.0
acl magic_words1 url_regex -i 192.168
acl magic_words2 url_regex -i ftp .exe .mp3 .vqf .tar.gz .gz .rpm \
.zip .rar .avi .mpeg .mpe .mpg .qt .ram .rm .iso .raw .wav .mov
delay_pools 2
abbiamo detto che la linea dedicata è un link HDSL a 2Mbits, il valore di 2 Mbits è pari a 256 Kbytes per secondo e 256 KB/s
sono pari a 5 KB/s. Nell'esempio seguente impostiamo 256 KB/s di bandwith per l'intero network, ma solo 5 KB/s verranno
riservati ad ogni nodo
delay_class 1 2
delay_parameters 1 256000/256000 5000/256000
delay_access 1 allow magic_words2
delay_access 1 allow student
delay_access 1 allow admin
con il valore -1/-1 indichiamo che non vi sono limiti di sorta per il traffico locale

delay_class 2 2
delay_parameters 2 -1/-1 -1/-1
delay_access 2 allow magic_words1
eliminiamo il download nel caso in cui il file sia più grande di 1MB
reply_body_max_size 1024 KB
19.3. Limitare il download di alcuni files

E' anche possibile limitare il download di alcuni files impostando delle ACL che identifichino il tipo di files da limitare
acl ftpblock url_regex -i \.mp3$ \.asx$ \.avi$ \.mpeg$ \.mpg$ \

\.qt$ \.ram$ \.rm$ \.iso$ \.wav$
applichiamo la ACL
Capitolo 20. Security ed utilizzi estremi

20.1. Preambolo
In questi ultimi anni si parla molto, ed anche a sproposito di sicurezza. La continuità del servizio definisce la stabilità e la alta
disponibilità nell'erograzione del servizio stesso e fa parte a pieno titolo del ramo informatico dedicato alla sicurezza dei
sistemi. Questo capitolo nasce per ricordare la data dell'11 Settembre 2001, giorno in cui un'attacco terroristico ha causato più
di tremila vittime civili distruggendo le Twin Towers di New York.
20.2. Squid come ultima risorsa

Nella vicenda dell'attacco alle Twin Towers alcune delle più importanti backbone della rete internet vanno giù e parte della rete
GARR, Rete dell'Università e della Ricerca Scientifica Italiana (http://www.garr.it) rimane isolata dagli USA. Per un breve
periodo di tempo la connettività è stata ripristinata attraverso alcuni link di emergenza e grazie anche alla collaborazione di
DANTE (http://www.dante.net/) con il quale venne configurato un circuito provvisorio che attraversava la rete europea per
raggiungere appunto le reti USA.

Le funzionalità del link con DANTE si sono interrotte con l'esaurimento del generatore autonomo ed il traffico HTTP ed FTP
diretto verso gli Stati Uniti è stato dirottato attraverso un Link secondario non GARR a 34 Mbps, tutto questo è stato possibile
grazie al supporto di CASPUR, Consorzio interuniversitario per le Applicazioni di Supercalcolo per Università e Ricerca
(http://www.caspur.it/) e dal servizio nazionale GARR-CACHE, Servizio Web Cache Nazionale del GARR (http://www.cache.
garr.it/).
20.3. Squid e la sicurezza

L'obiettivo di questo capitolo è quello di dare una panoramica delle possibili soluzioni relative alla sicurezza da implementare
utilizzando Squid, divideremo quindi questo paragrafo in tre sezioni principali analizzando diverse aree di interesse:
● sicurezza in quanto servizio
● sicurezza come interazione con il sistema operativo ospitante
Storicamente non si ricordano importanti problematiche di sicurezza inerenti l'attività di sviluppo di Squid.
Per i pignoli ricordiamo che tutti gli advisor possono essere controllati nell'url http://www.squid-cache.org/Advisories/.
Utilizzare l'ultima versione di Squid da sempre la certezza di avere il codice allo stato dell'arte, il codice dell'ultima release
stabile risolve tutti i problemi riscontrarti durante l'utilizzo del proxy server, le ultime versioni considerate sicure alla data del 6
Aprile del 2004' sono
● Squid-2.4.STABLE7 (sconsigliata e non più supportata tranne che da qualche specifico vendor)
● Squid-2.5.STABLE5
in questo paragrafo non è nostra intenzione dilungarci per disquisire sul controllo degli accessi, la questione è stata infatti
approfonditamente affrontata in questo libro nei capitoli relativi alle ACL, all'autenticazione, all'autenticazione con Linux,
all'autenticazione con Windows e relativamente al controllo accesso. Considereremo come "dato di fatto" che l'utente sia già a
conoscenza del comportamento di Squid o di come Squid si configuri.
Lo scopo ultimo di questa sezione è sensibilizzare l'admin sui motivi per i quali le politiche di sicurezza proposte diventino un
dovere e molto spesso una necessità. Accade troppo spesso infatti che, per quanto cerchiamo di "blindare" i nostri servizi, non
riusciamo mai a proteggerci dagli attacchi e dagli abusi d'utilizzo.
20.3.1. Sicurezza in quanto Servizio
Più passa il tempo, più si può felicimente notare un aumento dell'utilizzo di Squid nelle realtà aziendali. Con la dilatazione del
numero di utenze non può mancare un corretto rapporto tra l'utilizzo del servizio stesso e le politiche di profilazione che si
adottano per la sicurezza aziendale e non.
La stesura di questa parte del documento nasce dalla presa di coscienza che, una volta creato un servizio e reso disponibile alla
comunità d'utenza aziendale, automaticamente il fruitore (utente o chi per esso) si sentirà in diritto di utilizzare il servizio a
proprio piacimento. Questo comportamento "improprio" in genere, si verifica genericamente in assenza di una
regolamentazione scritta.

Troppe volte infatti accade che i "gestori/manutentori" devono saper sopperire a questioni e problematiche che vengono causate
dall'utilizzo improprio di un servizio, questa problematica naturalmente si manifesta con molteplici sfaccettature che toccano
sicuramente ed in maniera tangibile i seguenti argomenti:
● efficacia
● efficienza
● sicurezza
Lasciando per ora da parte le implicazioni giuridiche legate alla sicurezza informatica, in questo contesto infatti indichiamo
(per lo più) la possibile corruzione del dato da parte di terzi o l'accesso non autorizzato. Squid, oltre che avere un efficente
sistema di web-cache può risolvere il problema di migliorare la sicurezza di un sistema informativo, ovvero quella di lasciare
ad un unico punto logico l'accesso diretto a internet.
Questo fa si che il singolo pc dell'utente finale debba demandare qualsiasi richiesta di accesso ad internet al nostro cache
server. Non solo, Squid fa in modo che l'utente possa essere profilato in modo da permettere la generazione demandata di
alcune determinate connessioni (cfr. capitoli sul controllo accesso, sulla privacy e sulle indicazioni sulle dimensioni della
cache) alle quali può sopperire (FTP, HTTP ed HTTPS). Il fine primo di questa azione è quello di risolvere le seguenti
problematiche:
● evitare abuso d'utilizzo
● evitare l'introduzione di materiale illegale e non direttamente legato all'uso lavorativo all'interno della rete interna.
● evitare l'introduzione di Virus e Trojans all'interno della rete aziendale
● evitare problematiche inerenti alla sicurezza informatica in generale.
Un esempio pratico per l'attuazione di queste politiche di sicurezza si fonda sui seguenti divieti e sui controlli che possono
essere definiti sul livello di accesso al sistema di web-cache:
● discriminazione in base all'utenza
● download e determinati mimetypes
● contenuto delle pagine
● access Lists temporizzate
● direct Connect
Il primo passo è la discriminazione d'accesso sulla base alle credenziali dell'utente, naturalmente ci saranno diverse profilazioni
per l'utilizzo della cache. Dopo aver impostato questo tipo di controllo è possibile lavorare sul tipo di download nonchè sui
mimetypes: un esempio di desinenze per i file "vietati", poichè potenzialmente pericolosi (veicolo per l'introduzione dei virus)
può essere la negazione per alcune estensioni di files come i file .exe, .com, .bat .vbs etc. etc. (cfr. capitolo sulle limitazioni
della banda per classi, voce "acl ftp_block")
Possono essere inoltre vietate le pagine e le URLs che possiedono alcuni tipi di contenuti:

● offensivi, discriminatori per razza, sesso e religione, pornografici
● non legati ad un'utilizzo strettamente lavorativo
I criteri di "scelta" degli URLs e del loro contenuto viene affidato ad un algoritmo che effettua un controllo su parole chiave
predefinite (cfr. capitoli sulla configurazione, sull'autenticazione in generale e sul controllo degli accessie sulle limitazioni di
banda), altre possibili soluzioni per la gestione del content filtering possono essere reperite con l'utilizzo dei seguenti
applicativi:
● Dansguardian http://www.dansguardian.org
● Squidguard http://www.squidguard.org
Nota: per quello che concerne la profilazione degli utenti ed il content filering bisogna fare attenzione alla regolamentazione
giuridica italiana in materia di data-privacy nonchè da quanto previsto dallo statuto dei lavoratori.
Vediamo ora una caso particolare per quanto riguarda il DIRECT CONNECT. Alcuni servizi di rete (come ad esempio l'https)
necessitano del metodo CONNECT per funzionare. Utilizzando questa modalità Squid non fa altro che creare un vero e proprio
TUNNEL tra il client richiedente ed il server. Una sbagliata configurazione potrebbe permette ad un utente malintenzionato di
servirsi di questo metodo per creare delle vere e proprie connessioni da usare a proprio piacimento per qualsiasi servizio.
E' buona prassi quindi negare il metodo CONNECT su tutte le porte ad eccezione di quelle SSL. (cfr. capitolo sulle limitazioni
di banda voce: "http_access deny CONNECT !SSL_ports")
20.4. Squid ed Antivirus

Vale anche la pena citare, a proposito della sicurezza informatica, la possibile integrazione di Squid con i sistemi AntiVirus o
viruswalling. E' di grande importanza per tutti gli utenti avere la possibilità di effettuare una navigazione internet "protetta" da
possibili virus, trojans e worms. L'inserimento di questa feature all'interno di Squid, naturalmente, deve essere fatta attraverso
l'utilizzo di software di terze parti. Passiamo in rassegna alcune possibili configurazioni
● Viralator è un wrapper in perl che si propone di controllare tutti i file che passano attraverso la web-cache, ulteriori
informazioni possono essere reperite alla URL http://viralator.loddington.com/
● Squid-VScan unica soluzione Free/GPL integra OpenAntivirus (scritto in Java) con squid http://sourceforge.net/projects/
openantivirus/
● DGVirus è un'integrazione di DansGuardian con con l'utilizzo dell'antivirus http://www.pcxperience.org/dgvirus/
● TrendMicro InterScan Web VirusWall (ora Interscan Web Security Suite) che fa parte della suite per il viruswalling di
TrendMicro, questo sistema può essere integrato con Squid URL: http://www.trendmicro.com/en/products/gateway/iwss/
evaluate/overview.htm
l'unica soluzione documentabile è quella di Trend Micro, in merito alle altre soluzioni antivirus citate in alto, questo tomo per il
momento non si propone di trattare queste configurazioni perchè gli autori non hanno ancora trovato una documentazione
esaustiva a riguardo.

20.4.1. InterScan Web Security Suite
In questo paragrafo analizzeremo come utilizzare questo prodotto della TrenMicro assieme a Squid Proxy Server per consentire
una efficace scansione del traffico HTTP salvaguardando l'introduzione di virus sulle macchine client, gli esempi fanno
riferimento al prodotto ISVW (Inter Scan Web VirusWall) e Squid. Per la sua natura tutto il traffico HTTPS non viene
naturalmente trattato, pertanto ISVW esegue il "forward" delle richieste HTTPS in maniera totalmente trasparente. il proxy
server a monte della catena dei sistemi che concateneremo in questo esempio non loggherà nessuna attività a rigurdo del
traffico HTTPS.
Configureremo ISVW per rispondere sulla porta 8080 di una qualsiasi macchina, sia Windows che UNIX®, non è un fattore
determinante. ISVW per funzionare deve concatenarsi con un proxy Server che si trova a valle quindi che è direttamente
collegato con la rete internet
---------------------------------------------------
| | |
------------ ------------ -------------
|proxy:3128|<------| ISVW:8080|<-----|proxy1:3128|
------------ ------------ -------------
content antivirus proxy_users
Nello schema sopracitato vediamo 3 sistemi Proxy concatenati tra loro, dove la macchina con ISVW, in ascolto sulla porta
8080 contatta il proxy server Squid a valle che è in ascolto sulla porta 3128 ottenendo le pagine web. Il proxy1, sempre in
ascolto sulla porta 3128, contatta il proxy server ISVW, in ascolto sulla porta 8080, per ottenere tutte le pagine web filtrate e
pulite da possibili virus. Gli utenti della nostra rete accedono ad internet senza rischio contattando il sistema proxy1, che
rimane in ascolto sulla porta 3128.
Ora vediamo come configurare la macchina proxy1 per consentirgli di legarsi con il server ISVW. Modificheremo il file squid.
conf inserendo queste 2 righe nei punti opportuni
cache_peer localhost parent 8080 0 no-query no-digest

never_direct allow all
La configurazione appena trattata è stata testata sia con Squid 2.4 che con Squid 2.5, per rendere operativo il concatenamento
dei due proxy server sarà necessario riavviare Squid Proxy Server
% /usr/local/etc/rc.d/squid.sh stop
oppure

Il riavvio del server renderà immediatamente funzionante ed operativa la nuova configurazione
20.5. Sicurezza come interazione con il sistema operativo ospitante

Squid è un server di tipo "demone" che viene eseguito in ambito LAN o WAN e, in quanto tale, naturalmente può essere
potenzialmente soggetto a connessioni anche da parte di utenti malintenzionati. E' quindi buona prassi fare una corretta
configurazione del sistema ospitante al fine di evitare eventuali problematiche di sicurezza.
20.5.1. Sistemi UNIX®, cloni e BSD
Nei sistemi UNIX® la prima semplice ed immediata procedura per proteggere il sistema è una corretta gestione dei permessi; a
riguardo la user guide di Squid è alquanto chiara (cfr. http://squid-docs.sourceforge.net/latest/html/c911.html#AEN913), noi ci
limiteremo a riportare solo le voci principali. Prima di tutto puntualizziamo sul fatto che Squid accede alla cache utilizzando un
utente che fa parte un gruppo ben definito, vale la pena quindi creare un utente e un gruppo che abbiano le credenziali
necessarie che garantiscano la sicurezza del corretto funzionamento, i TAG da indicare nel file di configurazione squid.conf
sono i seguenti
cache_effective_user squid
cache_effective_group squidadm
Impostato l'utente ed il gruppo, sarà necessario propagare le credenziali a tutta la struttura di directory in cui squid "vive", tale
pratica è necessaria per il corretto funzionamento del sistema. Nell'esempio che vi sottoponiamo abbiamo creato un gruppo
"squidadm", l'utente che fa parte di questo gruppo è "squid", il proxy server Squid è stato installato nel prefix /usr/squid/,
quindi dovremo necessariamente impostare i seguenti permessi
% chown squid:squidadm /usr/squid

% chmod 755 /usr/squid
% chown squid:squidadm /usr/squid/bin/.
% chown squid:squidadm /usr/squid/bin/*
% chmod 755 /usr/squid/bin/.
% chmod 755 /usr/squid/bin/*
% chmod 2775 /usr/squid/etc/.
% chown squid:squidadm /usr/squid/etc/*
% chown squid:squidadm /usr/squid/etc/.
% chown squid:squidadm /usr/squid/var/logs/
% chmod 770 /usr/squid/var/logs/
% chown squid:squidadm /usr/squid/var/cache
% chmod 770 /usr/squid/var/cache

Una volta impostati i permessi, facciamo partire squid ricordandosi di generare le sottodirectory di gestione della cache
(comando squid -z per il dettaglio cfr. capitolo sull'avvio di Squid) utilizzando un utente non privilegiato (non utilizziamo
l'utente root per capirci) eseguendo il comando
% /usr/local/bin/setuidgid squid /usr/squid/sbin/squid -D -N -d 10
Nota: setuidgid è una applicazione inclusa nel pacchetto daemontools realizzato da d.j. Bernstein.
Nell'esempio abbiamo deciso di far partire Squid con utente non privilegiato poichè ogni demone di rete che gira come root
rappresenta comunque una problematica per la sicurezza, l'operazione è stata eseguita nonostante il server Squid abbia una
struttura per la quale il processo child, che usa comunque un utente non privilegiato (squid), si occuperà di servire le richieste.
20.5.2. La modalità chroot() nei sistemi UNIX® cloni o BSD
Analizziamo ora un'altra possibilità che ci viene offerta dai sistemi UNIX® per corazzare il servizio Squid. Tale possibilità
viene offerta dalla funzione chroot()[39]. Questa funzione consente a un comando (nel nostro caso proprio Squid) di essere
confinato in un environment (o gabbia) per l'occasione da noi predisposto all'interno del sistema stesso.
Nel malaugurato caso in cui un malintenzionato riesca ad ottenere una "shell" sul sistema, sfruttando un improbabile bug di
Squid, grazie alla funzione chroot(), lo stesso rimarrà chiuso nella gabbia da noi preparata, grazie alla gabbia il
malintenzionato non potrà effettuare danni.
E' necessario rammentare che esistono alcuni metodi per irrompere fuori dalla gabbia di chroot() (cfr. http://www.bpfh.net/
simes/computing/chroot-break.html) ma se stiamo un pò attenti, possiamo rendere anche questo raggiro molto difficile.
Sinceramente l'autore di questo paragrafo, pensa che non sia strettamente necessario porre Squid in un ambiente chrootato, ma
visto che la sicurezza non è mai troppa e la paranoia regna sovrana porremo il nostro Squid in una gabbia blindata.
Nota: la sicurezza paranoica è un temine che è stato coniato dall'autore del libro nel momento in cui si teorizzava
sull'inserimento di questo paragrafo.
Passando alla parte operativa prima di tutto dobbiamo creare il nostro sistema "gabbia" dove andremo a chiudere il processo
Squid, quindi avremo bisogno di creare una directory per metterci dentro tutto quello che serve a Squid per funzionare
% mkdir /chroot
% cd /chroot
creazione delle directory di sistema

% mkdir -p usr/bin usr/lib lib squidhome etc

% ln -s usr/bin/ bin
copiamo le librerie necessarie nell'environment (la questione è variabile a secondo dei Sistemi utilizzati)
% cp -pi /lib/lib/libtermcap* /lib/ld-linux.so.2 /lib/libc.so.6 lib/

% cp -pi /lib/libnss* lib/
mettiamoci dentro un pò di binaries necessari
% cp -pi /bin/cat /bin/sh bin/
proviamo la nostra chroot()
% chroot /chroot /bin/cat --help
Creiamo adesso un utente ed un gruppo che esisteranno solo all'interno del nostro ambiente
% cd /chroot
% touch etc/passwd etc/shadow etc/group
% chmod 400 etc/shadow
% echo 'squidadm:x:888:' > etc/group
% echo 'squid:*:10882:-1:99999:-1:-1:-1:134537804' > etc/shadow
% echo 'squid:x:888:888:Web Account:/squidhome:/usr/bin/False' > etc/passwd
creiamo una shell fittizia
% echo 'int main(int argc, char *argv[]) {return(1);}' \

> /tmp/False.c && gcc -O3 /tmp/False.c -o /chroot/usr/bin/False
Facciamo in modo che i binaries siano SOLO eseguibili
% chmod 111 usr/bin/*

Creiamo i file per le risoluzioni (N.B. se usiamo l'auth winbindd conviene inserire anche nss_winbind)
----/chroot/etc/nsswitch.conf ----------------
passwd: files
shadow: files
group: files
hosts: files dns
----------------------------------------------
----/chroot/etc/resolv.conf ------------------
domain mydomain.com
nameserver dnsaddress
----------------------------------------------
----/chroot/etc/hosts ------------------------
127.0.0.1 localhost loopback my.add.re.ss nomemio hostname.mydomain.com
----------------------------------------------
Compiliamo ed installiamo Squid
% mkdir /chroot/squid
% ln -s /chroot/squid /squid
% ./configure --prefix=/squid --enable-storeio="diskd ufs" \
--enable-snmp --enable-underscores
% gmake all && gmake install && ldconfig && sync
Una volta fatto questo dovremo essere quasi pronti per far funzionare squid, ci dobbiamo soltanto armare delle utility strace ed
ldd per vedere COSA serve a squid per funzionare correttamente, quindi
% ldd /squid/bin/squid
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00136000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00163000)
libm.so.6 => /lib/libm.so.6 (0x00179000)
libresolv.so.2 => /lib/libresolv.so.2 (0x0019b000)
libnsl.so.1 => /lib/libnsl.so.1 (0x001ac000)
libc.so.6 => /lib/libc.so.6 (0x001c1000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00110000)
% ldd /squid/bin/client
libresolv.so.2 => /lib/libresolv.so.2 (0x00158000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00169000)
libc.so.6 => /lib/libc.so.6 (0x0017e000)
% ldd /squid/libexec/squid/diskd
libc.so.6 => /lib/libc.so.6 (0x00158000)
% ldd /squid/libexec/squid/unlinkd

libc.so.6 => /lib/libc.so.6 (0x00136000)

questo output ci mostra dove Squid (ed altri programmi vitali) cercheranno le librerie (shared objects) necessarie. A questo
punto noi dobbiamo ricreare lo stesso path nel nostro ambiente e copiarvi la libreria. Un esempio semplice
libpthread.so.0 => /lib/libpthread.so.0
questo vuol dire che Squid proverà a linkare libpthread.so.0 cercandola dentro /lib. Quindi, noi abbiamo chrootato dentro /
chroot, non dovremo far altro che copiare la libreria dove Squid la cercherà
/chroot/lib/libpthread.so.0
% cp -pi /lib/libpthread.so.0 /chroot/lib/
continuamo così per tutto il resto dell'output degli ldd. Ora, se abbiamo configurato tutto correttamente permessi directory etc.
(cfr. l'inizio del paragrafo) tutto dovrebbe funzionare, possiamo far partire Squid con il comando
% /usr/local/bin/setuidgid squid '/usr/sbin/chroot/chroot /squid/bin/squid -D -d 1'
se dovessero venir fuori problemi o errori provare prima a far partire Squid normalmente senza chroot(). Poi ricontrollare tutto
con ldd, al massimo utilizzare l'utility "strace" per un miglior debugging.
20.6. Squid e Daemontools

Squid è un software decisamente stabile, a memoria non si ricordano problematiche gravi relative a crash in produzione
direttamente dipendenti il demone. Storicamente lo si è visto "morire" esclusivamente per problematiche legate all'hardware o
a configurazioni sbagliate. Naturalmente la prudenza non è mai troppa, specialmente se utilizziamo Squid in scenari mission-
critical.
Per migliorare l'affidabilità e la raggiungibilità del servizio di Squid ci viene incontro il pacchetto di software scritto
dall'integerrimo DJ Bernstein, ovvero Daemontools, che possiamo facilmente reperire su: http://cr.yp.to/daemontools/
daemontools-0.76.tar.gz
Il funzionamento di questo supporto è semplice, con la sua struttura daemontools fa partire in modalità "respawn" direttamente
dall'inittab l'applicativo svscanboot il quale lancia e controlla continuamente il programma svscan sulla directory /service
dopodichè supervise avrà il compito di controllare il processo che abbiamo deciso di monitorare e lo rilancerà nel caso in cui
questo dovesse interrompersi per un qualsiasi motivo.

Passiamo ora alla configurazione: dopo aver installato Squid con un determinato prefix (Es. /usr/squid) ed aver correttamente
reso funzionante daemontools, andiamo a creare lo script run necessario per il corretto funzionamento della struttura di
controllo
#!/bin/sh
exec ./bin/squid -d 1 -N -D \
-f ./etc/squid.conf \
2>&1 | /usr/local/bin/multilog t s10000000000 n20 ./log
idealmente, ovvero come dice lo stesso DjB, questa tipologia di file non dovrebbe contenere dei "|" (pipe) al loro interno, ma
dato che non abbiamo bisogno diretto del log, questo può anche andare. C'è da puntualizzare anche che all'interno del file,
possono essere messe e tolte tutte le opzioni ad eccezione di "-N", per un corretto funzionamento infatti, Squid non deve
entrare in daemon mode. Una volta terminato questo step, basterà dare i seguenti comandi
% chmod 755 /usr/squid/run

% ln -s /usr/squid /service
aspettiamo qualche secondo e, come per magia, Squid partirà da solo, correttamente funzionante, e sarà virtualmente
invulnerabile! naturalmente possiamo controllare se Squid funziona con il comando
% svstat /service/squid
altra cosa importante, non servirà inserire nessuno script di boot nell'init.d in quanto penserà svscanboot stesso a farlo partire.
Se proprio lo volessimo, eccone uno fatto ad hoc su schema RedHat
#!/bin/sh
# Start/stop/restart squid-daemontools.
# Start acpid:
squid_start() {
if [ -x /usr/squid/bin/squid ]; then
echo "Starting Squid daemon: /usr/squid/bin/squid"
/usr/local/bin/svc -u /service/squid
fi
}
#
# Stop squid:
squid_stop() {
echo "Shutting down Squid daemon: /usr/squid/bin/squid"
/usr/local/bin/svc -dk /service/squid
/bin/killall squid # non necessario di solito, server per uccidere anche i child
}
#
# Restart acpid:
squid_restart() {

/usr/local/bin/svc -dk /service/squid

/bin/killall squid
/usr/local/bin/svc -u /service/squid
}
case "$1" in
'start') squid_start
if [ -x /usr/squid/bin/squid ]; then
echo "Starting Squid daemon: /usr/squid/bin/squid"
/usr/local/bin/svc -u /service/squid24
fi
}
#
# Stop Squid:
squid_stop() {
echo "Shutting down Squid daemon: /usr/squid/bin/squid"
/usr/local/bin/svc -dk /service/squid24
/bin/killall squid
}
#
# Restart Squid:
squid_restart() {
squid_stop
sleep 1
squid_start
}
#
case "$1" in
'start')
squid_start
;;
'stop')
squid_stop
;;
'restart')
squid_restart
;;
*)
echo "usage $0 start|stop|restart"
esac

Squid, come ben sappiamo è stato "portato" per funzionare anche sotto archiettura Microsoft Windows (utilizzando Cygwin o
MinGW). Le politiche di sicurezza possono essere le stesse utilizzate sotto UNIX® (ad eccezione della chroot()) ovvero la
corretta configurazione dei permessi del directory tree e il far partire il processo da utente non privilegiato.

20.8. Sistemi OS/2

Anche in questo caso si tratta di un porting realizzato grazie all'EMX runtime. OS/2 non prevede l'esecuzione di un processo ad
un livello inferiore o con privilegi minimi di conseguenza, il demone verrà eseguito sempre con i privilegi di amministratore
del sistema.
Capitolo 21. La analisi dei log di Squid

21.1. Preambolo
Anche se può apparire strano, la funzione più importante nell'amministrazione dei servizi di rete è proprio l'analisi dei file di
log, controllando l'andamento e la tipologia degli accessi è possibile prevenire per evitare possibili abusi e migliorare anche la
qualità del servizio offerto.
Non è nostro obiettivo trattare eventuali problematiche inerenti l'aspetto legale che l'analisi di un file di log può determinare,
sopratutto per quello che concerne la relativa legge sulla privacy nonchè lo statuto dei lavoratori in vigore nello stato
d'utilizzazione.
Questo capitolo ha l'obiettivo di proporre delle metodologie di analisi dei log di accesso generati da Squid, ricordiamo a tale
proposito che una lista ben fornita di applicazioni per l'analisi dei log è disponibile presso la URL's: http://www.squid-cache.
org/Scripts/
21.2. I log nativi

Abbiamo già visto che Squid utilizza diversi files di logs di cui quattro sono i file di log principali, questi vengono definiti dai
seguenti TAG
il TAG cache_access_log
nel file access.log vengono registrate tutte le transazioni effettuate dai client
il TAG cache_log
nel file cache.log vengono registrate tutte le informazioni sullo stato della cache, ne analizzeremo i dettagli in seguito

il TAG cache_store_log
nel file store.log vengono registrate tutte le attività eseguite dallo storage manager di Squid
il TAG cache_swap_log
cache_swap_log /usr/local/squid/var/cache/swap.state
nel file swap.state viene memorizzato il file di log dello swap, si tratta di un file binario che include un checksum MD5 e che
contiene i campi dello store entry. Non è necessario indicarlo in squid.conf in quanto verrà scritto automaticamente nella top
level directory della cache_dir.
Possiamo anche definire il formato dei files di logs che può essere suddiviso in file di log nativi ed in file di log che emulano lo
schema transazionale di un server web. Naturalmente le informazioni più importanti sullo stato di servizio della cache vengono
memorizzate nel file cache.log, mentre il file dal quale riusciremo ad estrapolare il maggior numero di informazioni sul
funzionamento del servizio di web cache è senza dubbio il file access.log. Ora analizziamo nel dettaglio il formato del file
access.log
(1)1049790275.517(2)880(3)192.168.5.12(4)TCP_MISS \
(5)20012689(6)GET (7)ftp://it.samba.org/pub/samba \
(8)Federico DIRECT/(9)217.56.103.6 (10) text/html
come possiamo notare vi sono ben 10 campi, questi campi vengono identificati utilizzando dei valori numerici, nello specifico
di seguito ne forniamo il dettaglio
1. TimeStamp
è il momento in cui la richiesta diretta verso il sistema di cache è stata processata, da notare che il formato è "UNIX®
Time" con la risoluzione in millisecondi
2. Elapsed Time
il tempo necessario per processare la richiesta, il tempo viene espresso in millisecondi
3. Client Address
determina l'indirizzo IP sorgente della richiesta
4. Log Tag/HTTP Code
si tratta dell'azione intrapresa da Squid in base alla richiesta (hit, miss, denied)

5. Size
la quantità di byte inviati al Client
6. Request Method
determina il metodo HTTP che viene utilizzato per soddisfare la richiesta (GET, POST)
7. URL
l'indirizzo internet del sito web richiesto dal client
8. Ident
determina l'utente o l'identificativo del client che ha richiesto il servizio
9. Hierarchy Data / Hostname
identifica come e dove la richiesta è stata processata
10. Content Type
come da RFC viene riportato il campo Content-Type dell'header HTTP
Naturalmente appare chiaro che con un pò di comandi shell UNIX® o perl scripting si può tirar fuori molto più di quello di cui
abbiamo bisogno da questo file di log.
21.3. Log in altri formati

Un'interessante features offerta da Squid è quella di cambiare il formato di output del log, vale la pena citare due metodologie
molto interessanti ai fini dell'amministrazione di sistema
1. la prima opzione a nostra disposizione è la compatibilità con il log di un server httpd
2. la seconda opzione a nostra disposizione è la possibilità di disporre di un file di log il cui output è nel formato custom
log format
la prima opzione è facilmente realizzabile introducendo il seguente TAG nel file di configurazione squid.conf
per quanto concerne la seconda opzione, è necessario applicare una patch al codice sorgente di Squid e compilarlo nuovamente,
ulteriori informazioni possono essere reperite sull'URLs http://devel.squid-cache.org/customlog/, la patch in questione è invece
scaricabile dalla URLs http://devel.squid-cache.org/cgi-bin/diff2/customlog.patch. E' anche possibile processare il file access.

log con uno script perl appositamente realizzato e reperibile presso la URL's http://cord.de/tools/squid/Welcome.html.en. E'
previsto l'inserimento del custom log Format nella futura versione Squid-3.
21.4. Troubleshooting con il file cache.log

Quando si implementa un nuovo sistema Squid è buona norma tenere sempre sotto controllo il file di log cache.log, verificare il
contenuto di questo file di log è un ottimo sistema per eseguire il debug e il troubleshooting ed ottenere una configurazione
ottimale per una nuova installazione di Squid.
21.4.1. Utilizzare tail(8) ed xterm(8)
Per verificare il funzionamento di Squid in tempo reale utilizzeremo il comando tail(8) che, se utilizzato con l'opzione -f
continuerà a leggere tutti i caratteri prodotti dal file di log assumendo che il file stesso sia in continua crescita. Per lavorare
correttamente utilizzeremo più finestre xterm(8). Questo programma, che fornisce l'emulazione terminale per un sistema X
Window, ci consentirà di utilizzare diverse sessioni terminale per impartire comandi e tenere sotto controllo il file di log.
Nell'esempio seguente eseguiremo il reload della configurazione di Squid con il comando squid -k reconfigure
2004/04/13 12:34:39| Cache dir '/usr/local/squid/var/cache' size changed to 102400 KB
2004/04/13 12:34:39| Initialising SSL.
2004/04/13 12:34:39| Error error setting CA certificate locations: error:00000000:lib
(0):func(0):reason(0)
2004/04/13 12:34:39| continuing anyway...
contemporaneamente utilizziamo il comando tail(8)
% tail -f /usr/local/squid/var/logs/cache.log
2004/04/13 12:21:14| Reconfiguring Squid Cache (version 3.0-PRE3)...
2004/04/13 12:21:14| FD 11 Closing HTTP connection
2004/04/13 12:21:14| FD 12 Closing ICP connection
2004/04/13 12:21:14| FD 13 Closing HTCP socket
2004/04/13 12:21:14| FD 14 Closing SNMP socket
2004/04/13 12:21:14| Cache dir '/usr/local/squid/var/cache' size remains unchanged
at 102400 KB
2004/04/13 12:21:14| User-Agent logging is disabled.
2004/04/13 12:21:14| Adding nameserver 192.168.10.4 from /etc/resolv.conf
2004/04/13 12:21:14| Accepting HTTP connections at 0.0.0.0, port 3128, FD 8.
2004/04/13 12:21:14| Accepting ICP messages at 0.0.0.0, port 3130, FD 10.

2004/04/13 12:21:14| Accepting HTCP messages on port 4827, FD 11.

2004/04/13 12:21:14| Accepting SNMP messages on port 3401, FD 12.
2004/04/13 12:21:14| WCCP Disabled.
2004/04/13 12:21:15| Loaded Icons.
2004/04/13 12:21:15| Ready to serve requests.
nel caso specifico viene segnalato un errore relativo alla impostazione del percorso della CA[40], vengono riconosciuti due
name server e Squid rimarrà in ascolto delle connessioni HTTP sulla porta 3128, dei messaggi ICP sulla porta 3130, dei
messaggi HTCP[41] sulla porta 4827. Per finire Squid accetta le connessioni SNMP sulla porta 3401. Nonostante l'errore
segnalato, Squid si è avviato correttamente, il messaggio Ready to serve requests è fondamentale per definire lo stato attuale di
Squid.
Il File cache.log dunque continene le informazioni relative alla configurazione di avviamento di Squid, fornisce dunque un
insieme di informazioni relative agli errori che possono verificarsi durante le operazioni che vengono svolte da Squid e non
solo in fase di avviamento. Per proseguire con il nostro esempio, abilitiamo l'acceleratore HTTP e confrontiamo nuovamente
l'output del file cache.log
2004/04/13 12:34:39| Using certificate in /usr/local/squid/etc/key.crt
2004/04/13 12:34:39| Using private key in /usr/local/squid/etc/key.key
2004/04/13 12:34:39| Cache dir '/usr/local/squid/var/cache' size changed to 102400 KB
contemporaneamente utilizziamo il comando tail(8)
% tail -f /usr/local/squid/var/logs/cache.log
2004/04/13 12:34:39| Reconfiguring Squid Cache (version 3.0-PRE3)...
2004/04/13 12:34:39| FD 8 Closing HTTP connection
2004/04/13 12:34:39| FD 10 Closing ICP connection
2004/04/13 12:34:39| FD 11 Closing HTCP socket
2004/04/13 12:34:39| FD 12 Closing SNMP socket
2004/04/13 12:34:39| Using certificate in /usr/local/squid/etc/key.crt
2004/04/13 12:34:39| Using private key in /usr/local/squid/etc/key.key
2004/04/13 12:34:39| Cache dir '/usr/local/squid/var/cache' size remains unchanged
at 102400 KB


2004/04/13 12:34:39| User-Agent logging is disabled.
2004/04/13 12:34:39| Accepting HTTP connections at 0.0.0.0, port 3128, FD 8.
2004/04/13 12:34:39| Accepting HTTPS connections at 0.0.0.0, port 443, FD 10.
2004/04/13 12:34:39| Accepting ICP messages at 0.0.0.0, port 3130, FD 11.
2004/04/13 12:34:39| Accepting HTCP messages on port 4827, FD 12.
2004/04/13 12:34:39| Accepting SNMP messages on port 3401, FD 13.
2004/04/13 12:34:39| WCCP Disabled.
2004/04/13 12:34:39| Loaded Icons.
2004/04/13 12:34:39| Ready to serve requests.
2004/04/13 12:34:39| Configuring Parent www1.dominio.com/80/0
come potete ben vedere, è stata inizializzata la porta 443 che rimane in ascolto delle connessioni HTTPS. Possiamo concludere
dicendo che il controllo del file cache.log è fondamentale per risolvere diversi problemi di configurazione e per tenere sotto
costante controllo lo stato di funzionamento di Squid.
21.4.2. Livelli di debug
E' possibile aumentare il numero delle informazioni di debug che vengono registrate nel file di cache logging cache.log
utilizzando il TAG debug_options. Normalmente l'output di questo file di log è impostato con un valore di debug molto basso,
come default Squid imposta il TAG debug_options con il valore
debug_options ALL,1
se abbiamo la necessità di effettuare un tuning molto accurato della nostra web cache, possiamo impostare un valore di debug
più alto
debug_options ALL,5
il full debugging viene rappresentato dal livello 9, questa impostazione determina la scrittura di file di log molto grandi.
L'impostazione ALL determina il livello di debugging per tutte le sezioni, è raccomandabile eseguire il debug con
l'impostazione ALL,1.
21.5. I codici di stato di Squid

Per comprendere al meglio i log di Squid dobbiamo saper interpretare i codici di stato, i codici TCP_ si riferiscono alle
richieste dirette verso la porta HTTP (generalmente la 3128), i codici UDP_ invece si riferiscono alle richieste dirette verso la
porta ICP (generalmente la 3130). Ecco una serie di statistiche relative ai codici di stato di Squid in una condizione di lavoro
lavoro normale
n. hits valore % codice di stato

---------------------------------------------------
1 14630 39.58% TCP_MISS:DIRECT
2 5528 14.96% TCP_REFRESH_HIT:DIRECT
3 4576 12.38% TCP_HIT:NONE
4 4566 12.35% TCP_CLIENT_REFRESH_MISS:DIRECT
5 4159 11.25% TCP_IMS_HIT:NONE
una statistica come questa basata appunto sui codici di stato, consente di tenere sotto controllo lo stato delle richieste dirette
verso Squid e consente anche di redigere delle statistiche relativamente al risparmio di banda internet all'interno della nostra
LAN. Ricordiamo al lettore che è possibile disabilitare la registazione del log per le richieste del tipo ICP, utilizzando il TAG
log_icp_queries non verrà registrato nessun codice di stato ICP.
Squid supporta i seguenti codici di stato
● TCP_HIT
è stata trovata una copia valida dell'oggetto nella cache di Squid
● TCP_MISS
l'oggetto richiesto non è presente nella cache di Squid
● TCP_REFRESH_HIT
l'oggetto è presente nella cache di Squid ma si tratta di un'oggetto vecchio (STALE). La query IMS relativa all'oggetto è
"304 not modified".
● TCP_REF_FAIL_HIT
l'oggetto è presente nella cache ma si tratta di una copia vecchia. La query If-Modified-Since (IMS)[42] fallisce se
l'oggetto viene trasportato
● TCP_REFRESH_MISS
l'oggetto è presente nella cache ma si tratta di una copia vecchia. la query IMS ritorna un nuovo oggetto
● TCP_CLIENT_REFRESH_MISS
Il client annuncia un messaggio "no-cache" pragma, la richiesta dell'oggetto visualizza dei messaggi di controllo della
cache, la cache deve aggiornare l'oggetto
● TCP_IMS_HIT

Il client annuncia una richiesta IMS per un oggetto che è presente nella cache e non è scaduto
● TCP_SWAPFAIL_MISS
L'oggetto era nella cache ma non è più accessibile
● TCP_NEGATIVE_HIT
si tratta di una richiesta per un oggetto non presente nella cache, il messaggio è "404 not found", la cache pensa che
questo oggetto sia inaccessibile. Riferirsi alle spiegazioni relative al TAG negative_ttl che sono contenute nel file squid.
conf
● TCP_MEM_HIT
una copia valida dell'oggetto richiesto è sia nella cache che nella memoria, con questo messaggio Squid indica che
l'accesso al disco è stato evitato
● TCP_DENIED
l'accesso viene bloccato per questo ripo di richiesta
● TCP_OFFLINE_HIT
l'oggetto richiesto è stato reperito direttamente dalla cache durante la modalità off-line di Squid. Questo tipo di modalità
non valida nessun oggetto, riferirsi al TAG offline_mode contenuto nel file squid.conf
● UDP_HIT
esiste una copia valida dell'oggetto nella cache di Squid
● UDP_MISS
l'oggetto richiesto non è nella cache
● UDP_DENIED
per questo tipo di richiesta l'accesso è stato negato
● UDP_INVALID
è stata ricevuta una richiesta non valida
● UDP_MISS_NOFETCH
se l'avviamento di Squid viene richiamato con il comando squid -Y (se la vostra cache è di tipo child ed usa il protocollo
ICP, questa opzione consente una rigenerazione veloce della cache), nel caso si dovessero verificare degli errori
frequenti, la cache ritornerà questo codice o dei codici UDP_HIT.
● NONE

Si verifica con gli errori sulle richieste effettuate dal cache manager
21.6. Codici di Stato HTTP

Squid utilizza quasi tutti i codici di stato HTTP di cui alla RFC 2616 (http://www.w3.org/Protocols/rfc2616/rfc2616.html) -
Hypertext Transfer Protocol -- HTTP/1.1. Squid-2 utilizza molti dei codici descritti in questa RFC ad eccezione dei codici 307
(Temporary Redirect), 416 (Request Range Not Satisfiable) e 417 (Expectation Failed). Squid utilizza anche dei codici
aggiuntivi come lo 0 (result code being unavailable) e 600 (segnalare un header non valido o un errore del proxy). Molte
definizioni sono state aggiunte nella RFC 2518 (http://www.ietf.org/rfc/rfc2518.txt) - HTTP Extensions for Distributed
Authoring -- WEBDAV.
"000" ; Used mostly with UDP traffic (Squid)

"100" ; Section 10.1.1: Continue
"101" ; Section 10.1.2: Switching Protocols
"200" ; Section 10.2.1: OK
"201" ; Section 10.2.2: Created
"202" ; Section 10.2.3: Accepted
"203" ; Section 10.2.4: Non-Authoritative Information
"204" ; Section 10.2.5: No Content
"205" ; Section 10.2.6: Reset Content
"206" ; Section 10.2.7: Partial Content
"300" ; Section 10.3.1: Multiple Choices
"301" ; Section 10.3.2: Moved Permanently
"302" ; Section 10.3.3: Found
"303" ; Section 10.3.4: See Other
"304" ; Section 10.3.5: Not Modified
"305" ; Section 10.3.6: Use Proxy
"307" ; Squid unsupported
"400" ; Section 10.4.1: Bad Request
"401" ; Section 10.4.2: Unauthorized
"402" ; Section 10.4.3: Payment Required
"403" ; Section 10.4.4: Forbidden
"404" ; Section 10.4.5: Not Found
"405" ; Section 10.4.6: Method Not Allowed
"406" ; Section 10.4.7: Not Acceptable
"407" ; Section 10.4.8: Proxy Authentication Required
"408" ; Section 10.4.9: Request Time-out
"409" ; Section 10.4.10: Conflict
"410" ; Section 10.4.11: Gone
"411" ; Section 10.4.12: Length Required
"412" ; Section 10.4.13: Precondition Failed
"413" ; Section 10.4.14: Request Entity Too Large
"414" ; Section 10.4.15: Request-URI Too Large
"415" ; Section 10.4.16: Unsupported Media Type
"500" ; Section 10.5.1: Internal Server Error
"501" ; Section 10.5.2: Not Implemented

"502" ; Section 10.5.3: Bad Gateway

"503" ; Section 10.5.4: Service Unavailable
"504" ; Section 10.5.5: Gateway Time-out
"505" ; Section 10.5.6: HTTP Version not supported
"600" ; Squid header parsing error (Squid)
21.7. Metodi di richiesta supportati

Squid riconosce diversi metodi di richiesta HTTP che vengono definiti nella RFC 2616 (http://www.w3.org/Protocols/rfc2616/
rfc2616.html) - Hypertext Transfer Protocol -- HTTP/1.1. Le nuove versioni di Squid, in particolare a partire da squid-2.2.
STABLE5 e versioni successive, riconoscono anche i metodi di richiesta che sono descritti nella RFC 2518 (http://www.faqs.
org/rfcs/rfc2518.html) - HTTP Extensions for Distributed Authoring -- WEBDAV. La lista che alleghiamo di seguito è
disponibile alla URLs http://www.squid-cache.org/Doc/FAQ/FAQ-6.html#ss6.9
method defined cachabil meaning

--------- ---------- ---------- ----------------------------------
GET HTTP/0.9 possibly object retrieval and simple searches
HEAD HTTP/1.0 possibly metadata retrieval
POST HTTP/1.0 CC or Exp. submit data (to a program)
PUT HTTP/1.1 never upload data (e.g. to a file)
DELETE HTTP/1.1 never remove resource (e.g. file)
TRACE HTTP/1.1 never appl. layer trace of request route
OPTIONS HTTP/1.1 never request available comm. options
CONNECT HTTP/1.1r3 never tunnel SSL connection
ICP_QUERY Squid never used for ICP based exchanges
PURGE Squid never remove object from cache
PROPFIND rfc2518 ? retrieve properties of an object
PROPATCH rfc2518 ? change properties of an object
MKCOL rfc2518 never create a new collection
COPY rfc2518 never create a duplicate of src in dst
MOVE rfc2518 never atomically move src to dst
LOCK rfc2518 never lock an object against modifications
UNLOCK rfc2518 never unlock an object
21.8. Codici gerarchici per il peering con altre webcache

Nel caso si utilizzi Squid all'interno di una cache gerarchica, nei files di log potremmo trovare i seguenti codici gerarchici
● NONE
per un TCP HIT o una richiesta TCP fallita o una richiesta effettuata dal cachemgr e per tutte le richieste UDP nelle
quali non sono presenti informazioni sulla gerarchia

● DIRECT
l'oggetto viene prelevato direttamente dal server di origine
● SIBLING_HIT
l'oggetto viene prelevato da una cache sibling che risponde con un messaggio UDP_HIT
● PARENT_HIT
l'oggetto viene prelevato da una cache parent che risponde con un messaggio UDP_HIT.
● DEFAULT_PARENT
nessuna query ICP è stata trasmessa, la cache parent viene scelta da Squid perchè è marcata come default nel file squid.
conf
● SINGLE_PARENT
l'oggetto è stato richiesto all'unico sistema cache parent adatto per soddisfare la URL richiesta
● FIRST_UP_PARENT
l'oggetto è stato prelevato dal primo sistema cache parent inserito nella lista dei sistemi che sono in relazione parent
● NO_PARENT_DIRECT
l'oggetto è stato prelevato dal server di origine, non esiste alcun sistema parent per la URL richiesta
● FIRST_PARENT_MISS
l'oggetto è stato prelevato dal sistema cache parent che si presenta con il miglior RTT[43]
● CLOSEST_PARENT_MISS
Questo cache parent è stato scelto perchè è incluso nel più basso RTT se paragonato con quello del server di origine
● CLOSEST_PARENT
la selezione della cache parent è basata sulla nostra misurazione del RTT
● CLOSEST_DIRECT
la nostra misurazione RTT ritorna un tempo più corto rispetto a qualsiasi cache parent
● NO_DIRECT_FAIL
l'oggetto non può essere richiesto, controllare il TAG never_direct oppure non ci sono sistemi cache parent disponibili

● SOURCE_FASTEST
il sito di origine è stato scelto perchè il ping sorgente è arrivato velocemente
● ROUNDROBIN_PARENT
dai sistemi cache parent sono arrivate le risposte. Il sistema cache parent è stato scelto perchè è stato marcato come
sistema in modalità di round robin nel file di configurazione squid.conf
● CACHE_DIGEST_HIT
Il sistema peer è stato selezionato perchè il cache digest ha predetto un hit
● CD_PARENT_HIT
Il sistema parent è stato scelto perchè il cache digest ha predetto un hit
● CD_SIBLING_HIT
il sistema di cache sibling è stato scelto perchè il cache digest ha predetto un hit
● CARP
Il peer è stato selezionato dal protocollo CARP
molti di questi codici sono preceduti dal valore TIMEOUT_, questo accade se intercorre un timeout maggiore a due secondi nel
momento in cui tutte le risposte ICP arrivano dalle neighbors, per maggiori informazioni controllare il TAG icp_query_timeout
nel file squid.conf
code meaning
-------------------- -------------------------------------------------
PARENT_UDP_HIT_OBJ hit objects are not longer available
SIBLING_UDP_HIT_OBJ hit objects are not longer available
SSL_PARENT_MISS SSL can now be handled by squid
FIREWALL_IP_DIRECT No special logging for hosts inside the firewall
LOCAL_IP_DIRECT No special logging for local networks
21.9. Strumenti di analisi dei Log

Passiamo ora alla discussione inerente gli strumenti e delle metodologie che utilizzeremo per effettuare l'analisi dei file di log.
Appare chiaro, anche sulla base di quanto scritto in precedenza, che la registrazione delle attività più importanti viene
memorizzata nel file access.log. In questo file troviamo sia le informazioni inerenti gli accessi, sia le informazioni relative alle
prestazioni della nostra cache.
Introduciamo il discorso dell'analisi dei log dicendo che, i file di log stessi devono essere necessariamente gestiti in base alla
loro grandezza. In uno scenario dove più di 500 utenti accedono ad internet attraverso la delega di Squid, il file access.log può
anche raggiungere dimensioni vicine al gigabyte per una sola settimana d'utilizzo. Per questo motivo la prima cosa da fare è

utilizzare il nostro sistema di schedulazione dei processi (crond) in maniera appropriata, nella fattispecie ci serviremo del
comando apposito offerto da Squid per ruotare i file di log, ovvero:
% squid -k rotate
Il comando di cui sopra genererà un file access.log.N dove "N" indica un numero incrementale a partire da 0 sino a 9 che indica
il numero di rotazione del file di log, tale procedura consente:
● di evitare che il log diventi un file di grandezza incontrollata
● di dividere i report di analisi per periodi di tempo ben determinati
● di avere uno storico dei log in formato file.
Nei paragrafi successivi prenderemo in considerazione il file access.log.0, che differisce dal file di log "normale" in quanto si
tratta del file di log direttamente successivo all'originale routato, questa scelta permette di agire su un file di log senza dover
fermare il processo di squid e/o di utilizzare il file di log in un lasso di tempo ben definito.
Ricordiamo al lettore che, nell'area /contrib è possibile trovare una tabella crontab correttamente configurata nella quale sono
censiti tutti i comandi di rotating e log parsing.
Non è nostro scopo consigliare un programma per la gestione dei log di Squid, per noi è fondamentale descrivere quelle
applicazioni di largo utilizzo che consentiranno al lettore di scegliere il sistema di analisi che più si addice alle sue esigenze.
Ora passiamo in rassegna diverse soluzioni per le quali forniremo anche un breve commento.
21.9.1. Calamaris
Calamaris è in grado di analizzare diversi files di log, tra questi possiamo citare i files di log protoddi da Squid (http://www.
squid-cache.org/), NetCache (http://www.netapp.com/products/netcache/), Inktomi Traffic Server (http://www.inktomi.com/) e
Oops! proxy server (http://zipper.paco.net/~igor/oops.eng/).
calamaris è sicuramente il più famoso tra i log analyzer realizzati per Squid e si tratta di tool scritto in perl, si tratta di una delle
poche applicazioni in grado di creare una statistica di utilizzo completa che non riguarda solamente gli accessi al sistema ed il
livello di utilizzo ma gestisce anche le cache vicine (protocollo ICMP / parent e sibling) e la dislocazione degli oggetti nelle
cache stesse, calamaris supporta la creazione di report sia in formato testo che in formato html che contengono le seguenti
informazioni:
● Status-report per richieste UDP e TCP
● Request-Method (GET, HEAD etc. etc.)
● Estensione dei file
● Performance della cache in un tempo determinato

Calamaris è anche utile per capire il livello di utilizzo della cache rispetto alle richieste ricevute, infatti viene anche gestita la
percentuale di HIT rispetto ai MISS, l'utilizzo di calamaris può anche essere utile per creare dei report relativi alle performance
del sistema. Ora vediamo un comando di esempio per la generazione di un report:
% cat /usr/local/squid/var/logs/access.log.0 | calamaris -F html -u \

>/web_server_root/calamaris/index.html
possiamo programmare l'esecuzione di calamaris utilizzando la tabella di crontab(8), questo prodotto è reperibile presso la
URL's http://cord.de/tools/squid/calamaris/Welcome.html.en.
21.9.2. Webalizer
Questo software nato per la preparazione di reports per i log dei server web, può funzionare egregiamente anche per la gestione
dei log di Squid. Webalizer è particolarmente indicato per i file di grosse dimensioni poichè, essendo scritto in C, è molto
veloce nell'elaborazione del file di log. Ricordiamo che la visione dei report prodotti da Webalizer necessita di un web server, il
software consente anche la configurazione per la generazione di un'archivio storico che terrà conto delle analisi effettuate in
precedenza, in questo modo potremmo ottenere della reportistica incrementale.
Per quello che riguarda le informazioni reperibili dall'analisi del file di log, webalizer gestisce le seguenti statistiche mensili:
● Istogramma accessi giornalieri
● Istogramma accessi per ora
● Statistiche mensili, giornaliere ed orarie per: Pagina, File, Kbytes,Contatti
● Statistiche delle Top per quello che riguarda: Utenza, URL e Kbytes
Webalizer è sicuramente uno dei migliori log parser disponibili oggi in circolazione, l'unica pecca è quella di non consentire
una analisi approfondita dei file di log visto che la sua prerogativa è quella di fornire dei risultati statistici. La configurazione di
webalizer è piuttosto semplice, basta configurare correttamente le principali variabili all'interno del suo file di configurazione,
tra queste possiamo citare le più importanti
LogFile /usr/local/squid/logs/access.log
LogType squid
OutputDir /usr/local/www/data-dist/webalizer
ulteriori informazioni circa gli altri parametri di configurazione possono essere reperite all'interno del file di configurazione che
è comunque commentato, una volta impostate le variabili all'interno del file di configurazione sarà necessario lanciare il
comando

% /usr/local/bin/webalizer -c /usr/local/etc/webalizer.squid.conf
se vogliamo impostare l'esecuzione programmata possiamo utilizzare la tabella di crontab(8), per tutte le altre informazioni su
webalizer consigliamo di consultare la documentazione dell'applicazione direttamente alla URLs http://www.mrunix.net/
webalizer/.
21.9.3. Sarg
Squid Analysis Report Generator (SARG) è un altro ottimo analizzatore di log per Squid, la sua peculiarità è quella di essere
orientato alla creazione di reportistica in base all'utenza, può essere molto utile in ambienti dove i sistemi di autenticazione
concedono o negano l'accesso alla cache. SARG è stato scritto nel linguaggio di programmazione C ed è particolarmente
indicato per file di log dimensioni ragguardevoli.
Lo storico di utilizzo è dato dal periodo di tempo a cui il log fa riferimento, molto importante al fine di ottenere una reportistica
coerente è il susseguirsi dei log tramite la loro rotazione, a tale proposito consigliamo all'utente di lanciare il comando sarg con
l'obbligo di analizzare un file access.log.N appena ruotato. Anche questo analizzatore di log necessita di un web server per la
pubblicazione dei dati analizzati.
Le informazioni reperibili sono le seguenti
● Reportistica in base all'utenza con informazioni correlate in base a data, dati movimentati e siti richiesti
● Statistica dei siti più accessi
● Informazioni circa i tentativi negati
● Reportistica per integrazione con SquidGuard
la configurazione è alquanto semplice, il file di configurazione sarg.conf viene posizionato nella directory /usr/local/etc/sarg e
come per webalizer sarà necessario editare questo file per definire alcune variabili come
language Italian
access_log /usr/local/squid/access.log.0
resolve_ip yes
output_dir /usr/local/www/data-dist/sarg
a punto possiamo iniziare il processo di generazione dei report avviando l'eseguibile del programma
% sarg
se vogliamo programmare l'esecuzione di sarg possiamo utilizzare anche in questo caso la tabella di crontab(8), ulteriori

informazioni ed eventuale documentazione può essere reperita presso la URLs http://sarg.sourceforge.net/.
21.9.4. Squeezer2
Squeezer2 è il diretto successore del famoso script Squeezer. Si tratta di una applicazione scritta in perl che permette di avere
ottima visione sullo stato della cache in termini di prestazioni, accessi e metodi HTTP utilizzati. Anche questo analizzatore di
log fornisce la reportistica in formato HTML, possiamo generare tre tipologie di report
● Minima, fornisce una visione dello stato attuale della cache e delle sue prestazioni
● Media, fornisce una visione più completa ampliando la visione minima con i report gli "status" ed i "result" sullo stato
della cache che contengono anche i riferimenti temporali
● Massima, verrà generato un report totale (per tutte le opzioni consigliamo il lettore di confrontare la documentazione del
sito) del file di log elaborato, questo tipo di report non è consigliabile dato che può creare pagine html di dimensioni
considerevoli.
L'utilizzo di Squeezer2 è alquanto semplice anche per un profano del linguaggio perl, basterà editare il file squeezer2.pl e
configurare correttamente le seguenti variabili:
my $base_dir = '/usr/squid';
my $conf_name = '/usr/squid/etc/squid.conf';
my $log_dir = $base_dir . '/var/logs';
my $log_name = 'access.log.0';
A questo punto lanceremo i seguenti comandi al fine di creare i report:
% /usr/local/bin/squeezer2.pl /var/squid/logs/access.log.0 \
>/www/squeezer/SQ`date +%Y%m%d`.html
% /usr/local/bin/squeezer2.pl > /www/squeezer/all.html
Il sito di riferimento è presso la URL's http://www.rraz.net/squeezer2/.
21.9.5. Yaala
Anche questa applicazione rappresenta un ottimo sistema per la gestione e l'analisi del log di Squid in particolare per quello che
concerne i siti internet acceduti dai nostri utenti. La particolarità di Yaala sta nel fatto che la creazione dei report in HTML è
completamente configurabile, Yaala utilizza un linguaggio molto simile all'SQL, l'estrazione dei dati dal file di log analizzato
può risultare molto simile ad una vera e propria select. E' possibile quindi concatenare i dati stabilendo un criterio di
aggregazione ed estrarre le informazioni desiderate dal file di log preso in considerazione.

Esistono tre tipi di aggregazione possibili:
● richieste
● bytes
● tempo intercorso
Dati questi tre tipi di aggregazione si possono estrarre i dati per campi, i campi disponibili sono:
● client
● date
● hierarchycode
● hour
● httpstatus
● method
● mime
● peer
● protocol
● resultcode
● server
Per spiegare meglio passiamo direttamente ad un esempio di configurazione, editando il file "config" si devono definire quindi
le variabili necessarie ed i criteri di estrazione dei dati:
directory: 'reports';
report: 'Classic';
logtype: 'Squid';
select: "requests BY client, date, httpstatus, method, mime";
Analizzando l'ultima riga aggregheremo i dati concatenando le richieste in base al client, la data, il codice http, il metodo http e
il mimetype. Ora per creare i nostri report basterà lanciare il seguente comando:
% yaala /path/verso/squid/logs/access.log.0

Ulteriori delucidazioni e riferimenti sono reperibili sulla URL's http://verplant.org/yaala/.
21.9.6. SquidAlyser
SquidAlyser è un programma di analisi dei log molto potente. E' scritto in perl e si appoggia ad un database (MySQL o
PostgreSQL) per lo storage dei dati. L'autore dell'applicazione sconsiglia questo programma in scenari ad alta densità d'utenza
in quanto esiste un grande impatto sia in termini di prestazioni (utilizzo del perl e di un database) che gestionali (mantenimento
e manutenzione di una macchina DB).
I dati che si possono estrarre sono tutti inerenti l'utenza e si possono anche analizzare gli accessi in base a file chiamati o byte.
L'installazione comprende quindi la creazione di un database, l'utilizzo di uno script che nel caso specifico si occupa di estrarre
le informazioni e metterle nel DB e la configurazione corretta del web server per il CGI che creerà i report.
Dato che la struttura di SquidAlyser è alquanto variegata non discuteremo della configurazione di questo sistema, ulteriori
informazioni a riguardo sono reperibili sulla URL's http://ababa.org/index.html.
21.9.7. Logrep
Logrep è un software molto potente per la gestione dei log. Questa applicazione viene citata non tanto per la qualità dei report
che è in grado di generare quanto per la possibilità che offre nel riunire in una unica applicazione la completa gestione dei molti
file di log che oggi vengono prodotti.
Nello specifico, Logrep può essere molto utile nel caso si volesse implementare una macchina preposta allo storage dei file di
log ed alla creazione della reportistica. Tra i formati supportati da Logrep vale la pena citare oltre a Squid anche IIS, Apache,
Exchange, Snort, Postfix, Iptables, NT Event ed altri. Ricordiamo che naturalmente nel caso si volesse implementare uno
scenario simile a quello sopra descritto, si deve necessariamente procedere a copiare l'access.log.0 sul log-server.
il sito di riferimento è alla URL's http://logrep.sourceforge.net/ .
21.9.8. LIRE
Anche LIRE, come Logrep, è un software che consente la gestione e la creazione di report centralizzata, supporta una grande
varietà di formati di files di log. LIRE viene inoltre citato perchè offre la possibilità di installare sulla macchina log-server, che
abbiamo brevemente descritto nel paragrafo precedente, un demone che rimane in ascolto delle informazioni che vengono
trasmesse dal suo client che potrà essere installato sulla macchina Squid. In questo modo il client LIRE si occuperà di inviare il
file di log direttamente al log-server sulla base dei dei criteri da noi impostati.
Ulteriori informazioni possono essere reperite sulla URLs: http://logreport.org/lire/.
21.9.9. Squidefender

Squid Defender è un semplice script scritto in linguaggio perl che si occupa di analizzare il file access.log al fine di trovare
possibili entry riguardanti possibili attacchi:
● di tipo Worm.
● basati sul metodo HTTP_CONNECT (mail relaying, Aol MSG Etc. etc.)
Tra le altre funzionalità importanti riportiamo:
● è in grado di creare report in formato html e di inviare una e-mail di avviso ogni attacco riconosciuto
● consente, attraverso il suo file di configurazione, di creare dei propri criteri e delle proprie regole di altering
● è inoltre integrabile con iptables o ipchains per l'inserimento di regole di firewalling ad hoc in base all'alert.
Il suo funzionamento è alquanto semplice, basta editare il file squidefender.conf, inserendo correttamente alcune variabili
importanti, tra le quali citiamo:
squidlog=/squid/var/logs/access.log.0
mailhost=IP.DEL.SMTP
logfile=squidresults.log
htmlout=/path/www/index.html
Una volta preparato il file di configurazione basterà lanciare l'eseguibile e puntare il nostro browser verso il report, ulteriori
informazioni possono essere reperite sulla URL's http://www.jeroen.se/squidefender.php.
Capitolo 22. Una configurazione operativa

Con la versione 2.0 dello Squid-Book si apre anche una sezione aperta ai contributi degli utenti che intendono partecipare alla
diffusione delle informazioni pubblicando le loro configurazioni. Le configurazioni possono essere inoltrare nella mail-box
dell'autore del Book Stefano Tagliaferri.
● La configurazione inviata da Giovanni - file di testo 3,25 Kb
Di seguito si riporta una configurazione funzionante che consente di effettuare sia blocchi di rete che autorizzazione,
autenticazione ed accounting, i commenti alla configurazione sono a cura di Federico Lombardo.

http_port 3128 # porta di utilizzo della cache

icp_port 3130 # porta di utilizzo per le connessioni ICP
#
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY # Questa ACL fa in modo che gli oggetti
# in questione non vengano registrati nella cache
cache_mem 96 MB
# memoria max utilizzata dal processo che amministra la cache
maximum_object_size 8192 KB
# Grandezza massima di un oggetto registrato nella cache
cache_dir ufs /squidcache0 7500 16 256
# storage e filesystem system dedicato alla cache
cache_dir ufs /squidcache1 7500 16 256
# storage e filesystem dedicato alla cache
cache_access_log /var/log/squid/access.log
cache_log /var/log/squid/cache.log
cache_store_log /var/log/squid/store.log
# file di log e percorsi
# formato dei log compatibile con la struttura "httpd"
mime_table /etc/squid/mime.conf
# ubicazione del file di configurazione che specifica i mimetypes
pid_filename /var/run/squid.pid
# ubicazione del file pid
ftp_user [email protected]
# nome utente utilizzato per le connessioni ftp anonime
dns_nameservers 192.168.1.8 192.168.1.7
# DNS da utilizzare per la risoluzione dei nomi
authenticate_program /usr/lib/squid/msntauth
# programma utilizzato per autenticare gli utenti
authenticate_children 15
# numero massimo di autenticatori lanciati alla partenza di squid
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320
# direttive che specificano ogni quando un pattern va riverificato
reference_age 6 months
# acl per la richiesta un'autenticazione valida
acl all src 0.0.0.0/0.0.0.0
acl locallan src 192.168.1.0/255.255.255.0
acl localla1 src 192.168.2.1
acl localla2 src 192.168.4.0/255.255.255.0
acl porn url_regex "/etc/squid/block/porn.block.txt"
acl notporn url_regex "/etc/squid/block/porn.unblock.txt"
acl Safe_ports port 80 21 443 563 70 210 1025-65535


# discrimina il metodo CONNECT secondo le specifiche HTTP/1.1
acl ftpblock url_regex -i \.mp3$ \.asx$ \.avi$ \.mpeg$ \.mpg$ \.qt$ \
\.ram$ \.rm$ \.iso$ \.wav$
# fa in modo che non vengano fatti scaricare i file di quelle desinenze
http_access allow notporn
icp_access allow all
miss_access allow all
proxy_auth_realm Enterprise Nome_Azienda web Gateway
cache_mgr netmaster@nome_azienda.com
visible_hostname proxy.nome_azienda.com
unique_hostname proxy.nome_azienda.com
forwarded_for off
snmp_port 3401
snmp_access allow snmppublic locallan
Capitolo 23. Colophon

Questo libro è stato scritto utilizzando il WYSIWYM Document Processor Lyx (http://www.lyx.org/).
LyX è Copyright (C) 1995 di Matthias Ettrich. Lyx è una applicazione che funziona su diverse piattaforme Unix, OS/2 e
Windows/Cygwin ed è inoltre disponibile una versione nativa per Mac OS X.
LyX consente di produrre un output di altissima qualità grazie allo standard LaTeX, LaTex è un motore di typesetting di livello
industriale, in questo caso, LyX è molto di più di un frontend per LaTeX, Lyx riconosce anche i DocBook files.
Il libro viene successivamente convertito nel formato DocBook v 4.2, il DocBook è uno dei più popolari DTD (Document Type
Definition), il supporto allo standard DocBook viene incluso in molte distribuzioni Linux, DocBook dispone di un set di tags
(più di 300) che vengono utilizzati per descrivere il contenuto di un documento. DocBook include i formati XML e SGML,
grazie a questo tipo di supporto è possibile utilizzare le regole grammaticali dei formati XML ed SGML.
I formati HTML, PDF, PS e TXT sono stati prodotti utilizzando un foglio di stile personalizzato del tipo DSSSL con uno script

del tipo wrapper Jade.
Questo documento viene formattato con Lyx e successivamente viene esportato nel formato LinuxDoc, per realizzare una
corretta formattazione del documento vengono utilizzati i fogli di stile, in particolare viene utilizzato il il foglio di stile DSL
fornito da Linux Documentation Project (LPD - http://www.merlinobbs.net/LDP/LDP/LDP-Author-Guide/html/templates.
html). Questo foglio di stile viene fornito da Tille e viene utilizzato per utilizzare la trasformazione DSSSL.
Per l'eliminazione degli errori dalle pagine HTML è stata utilizzata l'utility tidy (http://tidy.sourceforge.net/), alla realizzazione
di questo saggio hanno contribuito
● 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
Capitolo 24. GNU Free Documentation License

GNU Free Documentation License - Version 1.1, March 2000 - Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple
Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license
document, but changing it is not allowed.
PREAMBLE
The purpose of this License is to make a manual, textbook, or other written document "free" in the sense of freedom: to assure
everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or
noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not
being considered responsible for modifications made by others.
This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same
sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have
designed this License in order to use it for manuals for free software, because free software needs free documentation: a free
program should come with manuals providing the same freedoms that the software does. But this License is not limited to
software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book.
We recommend this License principally for works whose purpose is instruction or reference.
APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be
distributed under the terms of this License. The "Document", below, refers to any such manual or work. Any member of the
public is a licensee, and is addressed as "you". A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the
relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains
nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics,
a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the
subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The
"Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the
notice that says that the Document is released under this License.
The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice
that says that the Document is released under this License.
A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is
available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text
editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and
that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text
formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage
subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input
format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human
modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary
word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-
generated HTML produced by some word processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the
material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title
Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.
VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this
License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies,
and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or
control the reading or further copying of the copies you make or distribute. However, you may accept compensation in
exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You
may also lend copies, under the same conditions stated above, and you may publicly display copies.
COPYING IN QUANTITY
If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover
Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the
front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of
these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add
other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the
Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either
cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and
continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-
readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-
network location containing a complete Transparent copy of the Document, free of added material, which the general network-

using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter
option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this
Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an
Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you
contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide
you with an updated version of the Document.
MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided
that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document,
thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must
do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous
versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a
previous version if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the
Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less
than five).
C. State on the Title page the name of the publisher of the Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version
under the terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license
notice.
H. Include an unaltered copy of this License.
I. Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and
publisher of the Modified Version as given on the Title Page. If there is no section entitled "History" in the Document, create
one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the
Modified. Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and
likewise the network locations given in the Document for previous versions it was based on. These may be placed in the
"History" section. You may omit a network location for a work that was published at least four years before the Document
itself, or if the original publisher of the version it refers to gives permission.
K. In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the
substance and tone of each of the contributor acknowledgements and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the
equivalent are not considered part of the section titles.

M. Delete any section entitled "Endorsements". Such a section may not be included in the Modified Version.
N. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section. If the Modified
Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied
from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to
the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.
You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by
various parties--for example, statements of peer review or that the text has been approved by an organization as the
authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to
25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover
Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already
includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on
behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that
added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names
for publicity for or to assert or imply endorsement of any Modified Version.
COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms defined in section 4 above
for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original
documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice. The combined work
need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If
there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by
adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique
number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined
work. In the combination, you must combine any sections entitled "History" in the various original documents, forming one
section entitled "History"; likewise combine any sections entitled "Acknowledgements", and any sections entitled
"Dedications". You must delete all sections entitled "Endorsements."
COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this License, and replace the
individual copies of this License in the various documents with a single copy that is included in the collection, provided that
you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a
single document from such a collection, and distribute it individually under this License, provided you insert a copy of this
License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume
of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no
compilation copyright is claimed for the compilation. Such a compilation is called an "aggregate", and this License does not
apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are
not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of
the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed
on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole
aggregate.
TRANSLATION

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section
4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include
translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a
translation of this License provided that you also include the original English version of this License. In case of a disagreement
between the translation and the original English version of this License, the original English version will prevail.
TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any
other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under
this License. However, parties who have received copies, or rights, from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.
FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time.
Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
See http://www.gnu.org/copyleft/. Each version of the License is given a distinguishing version number. If the Document
specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following
the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the
Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version
ever published (not as a draft) by the Free Software Foundation.
ADDENDUM: note dell'autore
Questo libro viene rilasciato sotto la GNU Free Documentation License, 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 ([email protected] - http://www.merlinobbs.net), alla stesura di alcune parti del
documento ha partecipato Leo Pedone ([email protected]). Questo libro è rilasciato sottoGNU 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 ([email protected]),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.
Questa pubblicazione si è perfezionata senza eventuali protezioni di brevetti d'invenzione, inoltre, i nomi coperti da eventuale
marchio registrato vengono utilizzati senza tenerne conto.
Capitolo 25. Elenco dei mirror autorizzati

● MerlinoBBS - http://merlino.merlinobbs.net/Squid-Book/ - Roma (RM)
● MajaGLUG - http://www.majaglug.net/doc/Squid-Book/index.html - Roma (RM)

● Latina LUG - http://www.llg.it/Squid-Book/ - Latina (LT)
● Acme Consulting S.r.l. - http://www.acmeconsulting.it/Squid-Book/ - Torino (TO)
● GARR Network's ROMA Ftp-Archive - http://rm.mirror.garr.it/mirrors/Squid-Book/ - Roma (RM)
● Progetto Italiano Documentazione eCS ed OS/2 (Pido2) - http://www.ecomstation.it/pido2/home/djspider8/squidbook/ -

La Spezia (SP)
Note
[1] The Internet Engineering Task Force (http://www.ietf.org/)

[2] SKA è l'acronimo di Shared Key Authentication, si tratta di un metodo pdi autenticazione che prevede l'uso di una
chiave condivisa nel processo di autenticazione (da qui il termine shared key)
[3] MD5 è un algoritmo che genera un'impronta, chiamata anche fingerprint o message digest, della lunghezza di 128 bits
per un messaggio di lunghezza arbitraria.
[4] IA32 - architettura intel per i sistemi a 32 bit
[5] UFS è l'acronimo di Unix File System
[6] AD è l'acronimo di Active Directory
[7] RAID 5 - questa configurazione in realtà si compone di due macchine e si tratta di un Cluster HA (High Availability),
una configurata come master (il server) e la seconda come slave (si tratta da un PC Pentium III 500Mhz, disco IDE
5000RPM, FreeBSD 4.11-STABLE ed ufs disk store su filesystem UFS con alimentatore ridondato). Tale
configurazione consente di mantenere un'altissimo livello di affidabilità ed una rapida e veloce manutenzione in caso di
fault. Per altre informazioni riferirsi al capitolo relativo al Proxy Load Balancer (WPAD protocol)
[8] Disk Store aufs: in presenza di carico significativo e di una cache store di dimensioni consistenti (superiore a 2 GB) un
diskstore multi threaded asincrono come aufs, awin32 o diskd garantisce prestazioni decisamente migliori
[9] con il temine oggetto si definisce un valore generico con il quale si identifica qualsiasi documento o altro tipo di dato
disponibile via web, le URL (Uniform Resource Locator) solitamente identificano gli oggetti
[10] SMP è acronimo di Simmetric Multi Processor
[11] EIDE è acronimo di enhanced IDE
[12] l'interfaccia ATA viene utilizzata per connettere device di storage come hard disks, DVDs e CD-R/W
[13] SATA - Serial ATA
[14] DMA è acronimo di Direct Memory Access
[15] RAID è l'acronimo di Redundant Array of Inexpensive Disks, si tratta di un metodo che permette l'immagazzinamento
delle informazioni su più dischi, usando tecniche come lo striping dei dischi (RAID Livello 0) e il mirroring di dischi
(RAID Livello 1) per ottenere ridondanza, bassa latenza e/o banda più elevata in lettura e/o scrittura, e la possibilità di
recupero delle informazioni dopo la rottura di un disco, sono stati definiti 6 diversi tipi di configurazioni RAID.
[16] il sistema di diskstorage aufs attiva le funzionalità di async-io, il disk I/O viene eseguito in modalità threaded per
evitare attese e blocchi durante i tentativi di accesso al disco
[17] è noto che i dischi in tecnologia SCSI utilizzano un minor tempo di CPU rispetto al classico disco UDMA su bus IDE/
EIDE
[18] ANSI C è un linguaggio di programmazione
[19] Bourne Shell (sh) è la più vecchia delle shell di sistema e prende il nome dal suo creatore, Stephen Bourne. Si tratta di
una shell molto primitiva se paragonata con quelle più moderne e funzionali

[20] l'utility crontab è l'applicazione che viene utilizzata per installare o disinstallare una serie di procedure automatiche
attivabili tramite la tabella di cron(8) nel Vixie Cron
[21] MIME è l'acronimo di Multimedia Internet Mail Extension e consente a Squid di determinare il tipo di file in base alla
sua estensione, la lista dei mime type viene generalmente inclusa in un file dal nome mime.conf, una lista aggiornata di
mime type può essere prelevata alla URLs http://www.isi.edu/in-notes/iana/assignments/media-types/media-types
[22] Unix File System, si tratta del file system utilizzato dai sistemi *BSD
[23] ext2 è il file system originario dei Sistemi Linux
[24] Interprocess Communication Resources
[25] regex è acronimo di regular expression. Le espressioni regolari (ER, «regular expression») sono definite dallo standard
POSIX 1003.2, la loro sintassi può essere utilizzata per definire dei modelli che possono essere utilizzati per eseguire
delle liste di confronto
[26] DOS è l'acronimo di Disk Operating System
[27] OID - Object ID o identificativo dell'oggetto
[28] MIB - SNMP Management Information Base
[29] SSL è l'acronimo di Secure Socket Layer
[30] TSL è l'acronimo di Transport Layer Security
[31] fratelli con i quali si condivide un solo genitore
[32] un messaggio di cache MISS definisce un oggetto che non esiste più nella cache o che ha perso validità
[33] Object: termine generico con il quale viene definito un qualsiasi tipo di dato disponibile via web, le URL identificano
gli oggetti
[34] una cache HIT definisce una copia valida di un'oggetto
[35] LVS è l'acronimo di Linux Virtual Server
[36] SSL è l'acronimo di Secure Socket Layer
[37] PEM e PGP sono dei programmi che grazie alla crittografia consentono di comunicare in maniera riservata
[38] HA è l'acronimo di High Availability che tradotto in lingua italiana significa Alta Disponibilità
[39] Il termine chrooting definisce un processo con il quale viene confinata una applicazione in una parte speciale del
filesystem che prende il nome di jail (gabbia). Quando viene eseguita una chiamata chroot() l'applicazione non può più
accedere ai files che si trovano al difuori della gabbia. Solo l'utente root può scappare dalla gabbia, infatti una parte
vitale del processo di chroot() è proprio quella di non concedere i permessi dell'utente root
[40] CA è l'acronimo di Certification Authority
[41] HTCP è l'acronimo di Hyper Text Caching Protocol
[42] IMS è una tecnica che viene utilizzata dalla webcache quando un oggetto perde la sua consistenza. Se un oggetto non
viene più ritenuto consistente verrà verificato con una richiesta di If-Modified-Since (IMS), tale richiesta serve per
determinarne la reale consistenza dell'oggetto e se lo stesso risultasse realmente modificato la cache si occuperà di
richiedere al server di origine una copia aggiornata.
[43] RTT è l'acronimo di Round Trip Time

Squid-Book Oltre Le FAQ

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Squid-Book Oltre Le FAQ

Caricato da

Copyright:

Formati disponibili

Squid-Book oltre le FAQ

Squid-Book oltre le FAQ

Diario delle Revisioni

http://www.merlinobbs.net/Squid-Book/HTM/ (1 of 263)14/02/2006 11.31.52

http://www.merlinobbs.net/Squid-Book/HTM/ (2 of 263)14/02/2006 11.31.52

Split HTML - Single HTML

http://www.merlinobbs.net/Squid-Book/HTM/ (3 of 263)14/02/2006 11.31.52

3.5.1. contenuti pagina web

http://www.merlinobbs.net/Squid-Book/HTM/ (4 of 263)14/02/2006 11.31.52

7.5.1.1. Squid current

http://www.merlinobbs.net/Squid-Book/HTM/ (5 of 263)14/02/2006 11.31.52

8.11. La configurazione di startup (squid.conf)

http://www.merlinobbs.net/Squid-Book/HTM/ (6 of 263)14/02/2006 11.31.52

10.6.1. Controlli di accesso e URL filtering

http://www.merlinobbs.net/Squid-Book/HTM/ (7 of 263)14/02/2006 11.31.52

http://www.merlinobbs.net/Squid-Book/HTM/ (8 of 263)14/02/2006 11.31.52

13.6.1. Configurare cachemgr.cgi con Apache

http://www.merlinobbs.net/Squid-Book/HTM/ (9 of 263)14/02/2006 11.31.52

16.3. Gli switch di livello quattro

http://www.merlinobbs.net/Squid-Book/HTM/ (10 of 263)14/02/2006 11.31.52

21.4.2. Livelli di debug

1.2. Note sul libro

1.3. Note sull'autore

http://www.merlinobbs.net/Squid-Book/HTM/ (11 of 263)14/02/2006 11.31.52

1.4. Altre annotazioni

1.5. Licenza d'utilizzo

● 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/

http://www.merlinobbs.net/Squid-Book/HTM/ (12 of 263)14/02/2006 11.31.52

● 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/

1.7. Convenzioni utilizzate

questo è un esempio di codice

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

indica il frazionamento per una linea di comando UNIX®

http://www.merlinobbs.net/Squid-Book/HTM/ (13 of 263)14/02/2006 11.31.52

# commento al codice sorgente o al TAG

Capitolo 2. La storia di Squid e dello Squid-Book

2.2. Il Core Development Team

● Francesco "Kinkie" Chemolli

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

http://www.merlinobbs.net/Squid-Book/HTM/ (14 of 263)14/02/2006 11.31.52

2.3. Un programma libero

2.4. Mailing lists

● [email protected] - discussioni generali sull'utilizzo di squid

● [email protected] - lista per il rilascio delle nuove release

● [email protected] - lista per l'annuncio dei nuovi bugs e problemi

● [email protected] - lista per il feedback e nuove idee

mailing lists non strettamente legate al progetto Squid

● [email protected] - lista sulle implementazioni del protocollo SNMP in ambito webcaching

2.5. Le origini dello Squid-Book

http://www.merlinobbs.net/Squid-Book/HTM/ (15 of 263)14/02/2006 11.31.52

2.6. Chi sviluppa oggi lo Squid-Book

● responsabile del progetto: Stefano Tagliaferri

http://www.merlinobbs.net/Squid-Book/HTM/ (16 of 263)14/02/2006 11.31.52

2.7. Squid, il software libero e la situazione Italiana

Capitolo 3. Cosa è Squid

3.1.1. L'architettura Web

http://www.merlinobbs.net/Squid-Book/HTM/ (17 of 263)14/02/2006 11.31.52