Squid-Book oltre le FAQ - digilander.libero.itdigilander.libero.it/novavoice/reti/Squid-Book oltre le FAQ.pdf · documento, Squid Proxy Server, Configurare SNMP e le FAQ per il controllo

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


mailto:[email protected]




http://www.mrshark.it/






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


http://www.merlinobbs.net/Squid-Book/HTML/index.html

http://www.merlinobbs.net/Squid-Book/HTM/index.html


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.8.1. Parametri di configurazione

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.2. Configurazione in Squid 2.4 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. Configurazione 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.2. Configurare il proxy trasparente con Linux kernel 2.2.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.7. Sistemi Windows 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/


http://www.gnu.org/licenses/licenses.html


http://www.merlinobbs.net/




http://www.squid-cache.org/Doc/#non-english

http://www.squid-cache.org/

http://www1.it.squid-cache.org/

http://www.securityfocus.com/

http://www.squid-cache.org/Doc/FAQ/

http://www.squid-cache.org/Doc/Hierarchy-Tutorial/

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 #


http://squid-docs.sourceforge.net/

http://www.ircache.net/


http://www.swelltech.com/support/benefits/


http://www.swelltech.com/support/sizecache/index.html

http://www.swelltech.com/support/sizecache/index.html


# 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/.


http://www.gnu.org/copyleft/gpl.html

http://www.gnu.org/copyleft/gpl.html

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.


http://www.squid-cache.org/Doc/FAQ/squid-copyright.txt


http://www.gnu.org/licenses/gpl.html

http://www.squid-cache.org/mail-archive/squid-users/200404/0954.html

http://www.squid-cache.org/mail-archive/squid-users/200404/0954.html








http://www.ietf.org/

news: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


http://merlino.ghostbbs.tk/




http://www.redhat.com/

http://www.redhat.com/

http://www.llg.it/







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


http://www.apogeonline.com/openpress/doc/cathedral.html

http://www.apogeonline.com/openpress/doc/cathedral.html


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


http://httpd.apache.org/

http://www.ietf.org/rfc/rfc1738.txt?number=1738



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


http://www.ietf.org/rfc/rfc2616.txt







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


http://www.ircache.net/~wessels/Papers/icp-squid.ps.gz

http://www.netapp.com/products/netcache/

http://www.cisco.com/go/cache/

http://www.volera.com/

http://www.bluecoat.com/

http://www.imimic.com/

http://icp.ircache.net/carp.txt

http://www.microsoft.com/TechNet/Proxy/technote/prxcarp.asp

http://www.microsoft.com/isaserver/


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





http://www.freshports.org/www/squid/

http://www.freshports.org/www/squid/


4.4. Sistemi Windows

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

1. modalità nativa

2. modalità emulata

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

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

4.5. Sistemi OS/2

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

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


http://www.mingw.org/

http://www.cygwin.com/


http://www.acmeconsulting.it/

http://www.acmeconsulting.it/SquidNT/

http://homepages.tu-darmstadt.de/~st002279/os2/html/porting.html

http://homepages.tu-darmstadt.de/~st002279/os2/html/porting.html


http://www.laser.ru/evgen/soft/Squid2/index_l.html



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



http://www.squid-cache.org/Versions/v2/2.5/RELEASENOTES.html


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


http://www.squid-cache.org/Versions/v2/2.5/RELEASENOTES.html

http://www.samba.org/


● 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


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

http://www.squid-cache.org/Versions/v2/

http://www.digistar.com/bzip2/index.html

http://www.digistar.com/bzip2/index.html




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 loginCVS 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 loginCVS 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




● 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


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 VERSIONVERSION=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.gzReceiving squid-2.5.STABLE6.tar.gz (1355951 bytes): 100%1355951 bytes transferred in 18.9 seconds (69.94 kBps)


https://www.cvshome.org/

ftp://ftp.squid-cache.org/pub/squid-2/STABLE/

ftp://ftp.squid-cache.org/pub/squid-2/STABLE/

http://www.gnu.org/software/wget/wget.html


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


http://www.squid-cache.org/Versions/v2/

ftp://ftp.gnu.org/

ftp://ftp.gnu.org/gnu/gcc/

ftp://ftp.gnu.org/gnu/binutils/

ftp://ftp.gnu.org/gnu/binutils/

http://www.perl.org/


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



% cd squid-2.5.STABLE6% ./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

% cd squid-2.5.STABLE5% 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


ftp://ftp.gnu.org/gnu/patch/

ftp://ftp.gnu.org/gnu/patch/


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.gzReceiving 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 è


http://www.squid-cache.org/Versions/v2/2.5/

http://www.squid-cache.org/Versions/v2/2.5/


% ./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 configureDirectory 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 namesHost 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 -n1024

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-max104857

è 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... 4096checking Maximum number of filedescriptors we can open... 4096checking Default UDP send buffer size... 65535checking Default UDP receive buffer size... 65535checking Default TCP send buffer size... 16384checking Default TCP receive buffer size... 87380Limiting receive buffer size to 64Kchecking if sys_errlist is already defined... (cached) nochecking for libresolv _dns_ttl_ hack... nochecking if inet_ntoa() actually works... yeschecking for working statvfs() interface... yeschecking for _res.nsaddr_list... (cached) yescreating ./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.maxfileskern.maxfiles: 4040kern.maxfilesperproc: 3636

come per i sistemi linux per visualizzare il numero di files descriptors attivi possiamo anche utilizzare l'opzione di shell ulimit

% ulimit -n4040

non è dunque necessario ricompilare il kernel per impostare il valore corretto dei file descriptors, sarà sufficente editare il file /etc/sysctl.conf

kern.maxfiles=4040kern.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 -m129/320/65536 mbufs in use (current/peak/max): 129 mbufs allocated to data128/260/16384 mbuf clusters in use (current/peak/max)600 Kbytes allocated to network (1% of mb_map in use)0 requests for memory denied0 requests for memory delayed0 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 28drwxr-xr-x 2 root root 4096 apr 10 12:26 bindrwxr-xr-x 2 root root 4096 apr 10 12:16 etcdrwxr-xr-x 2 root root 4096 apr 10 12:26 libexecdrwxr-xr-x 3 root root 4096 apr 3 12:40 mandrwxr-xr-x 2 root root 4096 apr 10 12:26 sbindrwxr-xr-x 4 root root 4096 apr 10 12:16 sharedrwxr-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 36drwxr-xr-x 30 root root 4096 2 apr 23:03 errorsdrwxr-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 recognizedstrip: /usr/local/squid/bin/RunCache: File format not recognizedstrip: /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.


http://freeware.sgi.com/

http://www.freebsd.org/cgi/ports.cgi?query=squid-2&stype=all

ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/www/squid/README.html

http://www.linuks.mine.nu/solaris/

http://www.swelltech.com/support/squidpackages.html


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


http://www.acmeconsulting.it/SquidNT/

ftp://hobbes.nmsu.edu/pub/os2/apps/internet/www/server




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:3128http_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/nullcache_store_log nonecache_log /dev/null

se invece utilizzate squid-2.5

cache_access_log nonecache_store_log nonecache_log /dev/nulluseragent_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.0http_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.0acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl to_localhost dst 127.0.0.0/8acl SSL_ports port 443 563acl Safe_ports port 80 # httpacl Safe_ports port 21 # ftpacl Safe_ports port 443 563 # https, snewsacl Safe_ports port 70 # gopheracl Safe_ports port 210 # waisacl Safe_ports port 1025-65535 # unregistered portsacl Safe_ports port 280 # http-mgmtacl Safe_ports port 488 # gss-httpacl Safe_ports port 591 # filemakeracl Safe_ports port 777 # multiling httpacl locallan src 192.168.0.0/255.255.255.0acl CONNECT method CONNECThttp_access allow manager localhosthttp_access deny managerhttp_access deny !Safe_portshttp_access deny CONNECT !SSL_portshttp_access allow localhosthttp_access allow locallanhttp_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 3128icp_port 3130cache_mem 8 MBcache_dir ufs /usr/local/squid/var/cache 100 16 256cache_access_log /usr/local/squid/var/logs/access.logcache_log /usr/local/squid/var/logs/cache.logcache_store_log /usr/local/squid/var/logs/store.logemulate_httpd_log offmime_table /usr/local/squid/etc/mime.confpid_filename /usr/local/squid/var/run/squid.pidacl all src 0.0.0.0/0.0.0.0acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl to_localhost dst 127.0.0.0/8acl SSL_ports port 443 563acl Safe_ports port 80 # httpacl Safe_ports port 21 # ftpacl Safe_ports port 443 563 # https, snewsacl Safe_ports port 70 # gopheracl Safe_ports port 210 # waisacl Safe_ports port 1025-65535 # unregistered portsacl Safe_ports port 280 # http-mgmtacl Safe_ports port 488 # gss-httpacl Safe_ports port 591 # filemaker


http://www.squidguard.org/

http://squirm.foote.com.au/


acl Safe_ports port 777 # multiling httpacl locallan src 192.168.0.0/255.255.255.0acl CONNECT method CONNECThttp_access allow manager localhosthttp_access deny managerhttp_access deny !Safe_portshttp_access deny CONNECT !SSL_portshttp_access allow localhosthttp_access allow locallanhttp_access deny allcache_mgr [email protected]_effective_user nobodycache_effective_group nobodyvisible_hostname proxy.nomedominio.netappend_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


http://conferences.oreillynet.com/presentations/os2002/wessels_duane.ppt



● 1GB RAM

● 3 x 18GB dischi SCSI di cui uno esterno

● scheda di rete Integrata Intel 10/100)

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

● FreeBSD 4.5-STABLE

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

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

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

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

9.2. Alcune problematiche legate al tipo di filesystem

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

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

9.3. Eseguire l'ottimizzazione del file system

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



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

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

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

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

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

9.4. Riservare correttamente lo spazio al Cache Storage

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

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

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



cache_dir ufs /cache1 7000 16 256

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

9.5. Le componenti del Cache Store

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

● Disk Storage

● Memory Storage

● Memory e Cache Replacement Policy

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

9.6. Disk Storage

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

● ufs

● aufs (awin32 in Windows)

● diskd

● null

● coss

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

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



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

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

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

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

I valori di default sono

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

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

read-onlymax-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_countsHTTP/1.0 200 OKServer: squid/2.5.STABLE5Mime-Version: 1.0Date: Tue, 06 Apr 2004 19:08:27 GMTContent-Type: text/plainExpires: Tue, 06 Apr 2004 19:08:27 GMTLast-Modified: Tue, 06 Apr 2004 19:08:27 GMTX-Cache: MISS from portatilo.miodominio.netProxy-Connection: closeASYNC IO Counters:Operation # Requestsopen 93close 93cancel 93write 0read 108stat 0unlink 5check_callback 9312queue 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=64diskd_program /usr/local/squid/libexec/diskd

utilizzando il Cache Manager è possibile visualizzare le prestazioni del diskd

% squidclient mgr:diskdHTTP/1.0 200 OKServer: squid/2.5.STABLE5Mime-Version: 1.0Date: Tue, 06 Apr 2004 19:56:57 GMTContent-Type: text/plainExpires: Tue, 06 Apr 2004 19:56:57 GMTLast-Modified: Tue, 06 Apr 2004 19:56:57 GMTX-Cache: MISS from proxy.miodominio.netProxy-Connection: closesent_count: 132233recv_count: 132233



max_away: 26max_shmuse: 25open_fail_queue_len: 0block_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 queueoptions MSGMNI=41 # number of message queue identifiersoptions MSGSEG=2049 # number of message segments per queueoptions MSGSSZ=64 # size of a message segmentoptions 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=2048set msgsys:msginfo_msgmnb=8192set msgsys:msginfo_msgmni=40set msgsys:msginfo_msgssz=64set 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 processoptions SHMMNI=32 # max shared mem id's per systemoptions 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=2097152kernel.shmmni=32kernel.shmmax=16777216

9.6.4.9. Memoria condivisa con Solaris

Aggiungere le seguenti linee nel file /etc/system

set shmsys:shminfo_shmmax=2097152set shmsys:shminfo_shmmni=32set 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=2048cache_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 Tuningoptions SHMSEG=16 # max shared mem id's per processoptions SHMMNI=32 # max shared mem id's per systemoptions 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=8192options 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)


http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html

http://www.merlinobbs.net/FreeBSD/HTML/lavorare-con-il-kernel.html




options SYSVMSG # SYSV-style message queues # Squid Message Queues DiskD Tuningoptions MSGMNB=16384 # max of bytes in a queueoptions MSGMNI=41 # number of message queue identifiersoptions MSGSEG=2049 # number of message segments per queueoptions MSGSSZ=64 # size of a message segmentoptions 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.

9.7.1. Parametri di configurazione

La configurazione del Memory Storage é controllabile tramite alcuni parametri di configurazione inclusi nel file squid.conf



cache_mem bytes high_memory_warning bytesmaximum_object_size bytesminimum_object_size bytesmaximum_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


http://www1.it.squid-cache.org/Doc/FAQ/FAQ-8.html#ss8.4


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"


http://www.hpl.hp.com/techreports/1999/HPL-1999-69.html

http://fog.hpl.external.hp.com/techreports/98/HPL-98-173.html

http://fog.hpl.external.hp.com/techreports/98/HPL-98-173.html


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

9.8.1. Parametri di configurazione

La configurazione delle Replacement policy in Squid avviene tramite i seguenti parametri

cache_replacement_policy policymemory_replacement_policy policycache_swap_low low-water-markcache_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

lruheap GDSFheap LFUDAheap 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



lruheap GDSFheap LFUDAheap 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/32acl pippo dstdomain www.sun.comacl 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/32acl legolas dstdomain www.sun.com www.linux.com www.cisco.comacl aragorn method PUT POST

l'espressione multipla esegue una comparazione con una richiesta per ogni valore inserito nell'espressione stessa. La ACL gandalf esegue una comparazione tra una richiesta proveniente dagli indirizzi IP 10.10.10.4, 10.10.10.24 e 10.10.10.84. La ACL legolas verifica la rispondenza con i siti di sun, linux e cisco, mentre la ACL aragorn esegue una comparazione sul tipo di richiesta HTTP ed in particolare che la stessa sia conforme ai metodi PUT o POST.

Ora che abbiamo mostrato al lettore alcuni tipi di ACL, assicuriamoci di applicare queste ACL in maniera graduale e corretta. Abbiamo detto che una richiesta può essere permessa o negata, nell'esempio seguente mostreremo una lista di regole che si riferiscono ad elementi di tipo ACL, facendo riferimento al nome assegnato alle ACL, concederemo o negheremo l'accesso, in



questo contesto è bene sottolineare che il nome della ACL diviene una parola chiave

acl paperino src 10.10.10.1/32acl pippo dstdomain www.sun.comacl topolino method GEThttp_access allow paperinohttp_access deny pippohttp_access allow topolino

le regole della ACL vengono rigorosamente applicate nell'ordine nel quale sono state scritte, la decisione viene presa sempre quando la relativa ACL viene confrontata, ritornando sull'esempio precedente analizzeremo alcune situazioni che possono venire a delinearsi.

● Cosa accade quando un utente proveniente dall'indirizzo IP 10.10.10.1 esegue il confronto con la ACL che specifica l'indirizzo di destinazione www.sun.com?

Squid incontra la ACL paperino e ne autorizza l'accesso. La nostra richiesta viene confrontata con la ACL paperino che ne verifica l'indirizzo IP di provenienza (10.10.10.1), in questo caso le regole successive non verranno verificate.

● Cosa accade invece se arriva una richiesta per il sito www.sun.com proveniente dall'indirizzo IP 10.10.10.5?

la richiesta non confronta con la prima regola ACL ma collima con la seconda ACL pippo, la richiesta verrà dunque negata. In questo caso l'utente riceverà un messaggio di richiesta negata da parte di Squid.

● Cosa accade se arriva una richiesta per il sito www.linux.com proveniente dall'indirizzo IP 10.10.10.5?

La richiesta non confronta la prima ACL paperino, non si abbina nemmeno con la seconda ACL pippo perchè www.linux.com è differente da www.sun.com però si confronta con la terza regola ACL topolino perchè il metodo di richiesta HTTP utilizzato è GET.

Le regole che abbiamo visto sino a questo momento sono state impostate con delle ACL semplici, non dimentichiamo però che Squid è in grado di combinare in maniera molto interessante anche elementi multipli per singole ACL, possiamo ora mostrare un semplice esempio

acl paperino src 10.10.10.1/32acl pippo dstdomain www.sun.comacl topolino method GEThttp_access allow paperino pippohttp_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/0acl servers 192.168.1.4/32 192.168.1.10/32 192.168.1.14/32icp_access allow serversicp_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/32acl legolas dstdomain www.sun.com www.linux.com www.cisco.comacl aragorn method PUT POSThttp_access deny gandalf legolas aragornhttp_access allow gandalf legolashttp_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/0http_access deny vietatohttp_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 vietatohttp_access deny vietatohttp_access allow all

entriamo nello specifico visualizzando alcune delle impostazioni standard di Squid

acl all src 0.0.0.0/0.0.0.0acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl locallans src 192.168.0.0/255.255.255.0acl to_localhost dst 127.0.0.0/8acl SSL_ports port 443 563acl Safe_ports port 80 # httpacl Safe_ports port 21 # ftpacl Safe_ports port 443 563 # https, snewsacl Safe_ports port 70 # gopheracl Safe_ports port 210 # waisacl Safe_ports port 1025-65535 # unregistered portsacl Safe_ports port 280 # http-mgmtacl Safe_ports port 488 # gss-httpacl Safe_ports port 591 # filemakeracl Safe_ports port 777 # multiling httpacl CONNECT method CONNECThttp_access allow manager localhosthttp_access deny managerhttp_access deny !Safe_portshttp_access deny CONNECT !SSL_portshttp_access allow locallanhttp_access deny all

con il TAG acl src vengono definite diverse liste di accesso basate sull'indirizzo IP, incluse quelle per gli host autorizzati dall'amministratore del sistema ad accedere al proxy server. Il TAG http_access allow consente a tutta la subnet 192.168.0.0 incluso l'host locale (127.0.0.1) di accedere al proxy, il TAG http_access deny impone una negazione di accesso.

I protocolli SMTP e HTTP sono delle implementazioni piuttosto simili, questo fatto può autorizzare qualche male intenzionato ad utilizzare il nostro proxy server come relay SMTP per inviare dei messaggi di posta non autorizzati. Per prevenire questo tipo di inconveniente dovremmo accertarci che Squid blocchi le richieste dirette verso la porta 25 che viene appunto utilizzata dal protocollo SMTP. Squid viene configurato in questo modo come default, nel file squid.conf vengono elencate una lista di porte fidate, a tale riguardo controllare la acl Safe_ports. Nel vostro file di configurazione dovreste avere un TAG http_access impostato in questo modo



acl Safe_ports port 80 # httpacl Safe_ports port 21 # ftphttp_access deny !Safe_ports

con questo TAG http_access deny bloccheremo tutto il traffico diverso (!) da quello dichiarato nella acl Safe_ports. Naturalmente per impedire il relay non autorizzato di posta elettronica, la porta 25 non deve elencata nella acl Safe_ports. Possiamo utilizzare una ACL per impostare gli orari di accesso a Squid

acl work_time time MTWHF 08:00-17:30 http_access allow work_time

con il TAG acl work_time viene impostato un orario per l'accesso al proxy server e il TAG http_access allow consente solo quell'orario. In questo esempio autorizziamo l'accesso al proxy server nei soli giorni festivi e nelle sole ore lavorative.

Possiamo impostare delle ACL anche per il protocollo ICP ed determinare delle relazioni di trusted tra macchine diverse nell'ambito di un cache peering

acl all src 0.0.0.0/0.0.0.0acl locallans src 192.168.0.0/255.255.255.0icp_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 REQUIREDhttp_access allow password

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

http_access allow localhosthttp_access deny managerhttp_access deny !Safe_portshttp_access deny CONNECT !SSL_portshttp_access deny locallan102http_access deny pornhttp_access deny badlanghttp_access deny entertainhttp_access deny gameshttp_access deny mp3http_access deny piratehttp_access deny pron



http_access deny ftpblockhttp_access allow sitiokhttp_access allow password

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

10.5. External ACL

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

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

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

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

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

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 password proxy_auth REQUIREDacl 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:00acl nointernet src "/usr/squid/etc/nointernet"acl goodurl url_regex -i "/usr/squid/etc/goodurl" acl badurl url_regex -i "/usr/squid/etc/badurl" acl badmime url_regex -i "/usr/squid/etc/badmime"http_access allow password internetfull http_access allow password internetnormal time_acl !badurl !badmime http_access allow password internettonav time_acl !badmime http_access allow password internettodow time_acl !badurl



http_access deny all

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/wb_group[14984](wb_check_group.c:188): SID: S-1-5-21-1836190980-1428173729-311576647-512/wb_group[14984](wb_check_group.c:154): Windows group: Domain Admins, Squid group: Gruppo/wb_group[14984](wb_check_group.c:188): SID: S-1-5-21-1836190980-1428173729-311576647-1510/wb_group[14984](wb_check_group.c:154): Windows group: Gruppo, Squid group: Gruppo OK

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 -Gexternal_acl_type NT_local_group %LOGIN c:/squid/libexec/win32_check_group.exeacl GProxyUsers external NT_global_group GProxyUsersacl LProxyUsers external NT_local_group LProxyUsersacl password proxy_auth REQUIREDhttp_access allow password GProxyUsershttp_access allow password LProxyUsershttp_access deny all

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 Gruppo1acl gruppo2 external ldap_group Gruppo2acl password proxy_auth REQUIREDhttp_access allow password Gruppo1http_access allow password Gruppo2http_access deny all

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


http://www.openldap.org/


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_groupacl gruppo1 external Linux_group Gruppo1acl gruppo2 external Linux_group Gruppo2acl password proxy_auth REQUIREDhttp_access allow password Gruppo1http_access allow password Gruppo2http_access deny all

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.confacl resticted external IP_Checkacl password proxy_auth REQUIREDhttp_access allow password restrictedhttp_access deny all

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 autorizzati192.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 ovunque0.0.0.0/0.0.0.0 boss192.168.2.0/255.255.255.0 NONE## L'utente `gianni´ può autenticarsi solo dall'indirizzo IP delle propria stazione192.168.3.45 jayk## Gli utenti appartenenti al gruppo `cad´ possono autenticarsi solo dalla propria VLAN10.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 porn 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.comwww-cache.fh-bingen.de.monkeylove.com.amateur-pages.com.hitboss.com.peep.com.erotism.com.sinfulmail.com.nookie.com.snapshots.com.onlyteens.comheavyhangers.dailydirt.comhustler.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


http://www.squidblock.com/

http://web.onda.com.br/orso/

http://members.lycos.co.uk/njadmin/


"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.128acl allowed_hosts1 src 192.168.0.128/255.255.255.128acl allowed_hosts2 src 192.168.1.0/255.255.255.0acl 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.255acl 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 localhosthttp_access allow allowed_hostshttp_access allow consentitihttp_access deny nonconsentitihttp_access allow allowed_hosts1http_access deny manager allhttp_access deny allhttp_access deny !Safe_portshttp_access deny CONNECT !SSL_ports

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.comwww.it.barbie.comwww.myscene.comwww.witchmagazine.itwww.streghe.netgo.to/streghewww.antoniogenna.netdisneywww.diddl.comwww.pollypocket.comwww.cartoonnetwork.itwww.repubblica.itmerlinobbs.netwww.foxkidswww.melevisione.rai.itwww.xmen



www.batmanpowerrangers

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.comalways_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.0Http_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-messengeracl 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 reqmsnhttp_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/0no_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:06acl M2 arp 11:12:13:14:15:16http_access allow M1http_access allow M2http_access deny all

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


http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q303/9/73.ASP&NoWebContent=1

http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q303/9/73.ASP&NoWebContent=1



http://www.faqs.org/rfcs/rfc2617.html


è legato ad uno schema di autenticazione attivo. Per utilizzare l'autenticazione è necessario definire un TAG con una acl nella quale venga specificata almeno la seguente direttiva

acl password proxy_auth REQUIRED

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

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

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

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

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

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

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

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

authenticate_cache_garbage_interval timespanauthenticate_ttl timetoliveauthenticate_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.

11.4.1. Configurazione in Squid 2.5

Lo schema di autenticazione basic utilizza i seguenti parametri

auth_param basic program cmdlineauth_param basic children numberofchildrenauth_param basic realm realmstringauth_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.

11.4.2. Configurazione in Squid 2.4

Squid 2.4 supporta esclusivamente lo schema di autenticazione Basic ed utilizza i seguenti parametri



authenticate_program cmdlineauthenticate_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

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. 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/passwdauth_param basic children 10auth_param basic realm Squid proxy-caching web serverauth_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_authauth_param basic children 5auth_param basic realm Squid proxy-caching web serverauth_param basic credentialsttl 45 minutes

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


http://web.onda.com.br/orso/


-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-authAuth required /lib/security/pam_nologin.so account required /lib/security/pam_stack.so service=system-authpassword required /lib/security/pam_stack.so service=system-authsession 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.1squid 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 auth_param basic children 5auth_param basic realm Squid proxy-caching web serverauth_param basic credentialsttl 30 minutes

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_authauth_param basic children 5auth_param basic realm Squid proxy-caching web serverauth_param basic credentialsttl 30 minutes

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 esempio di configurazione

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

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.

11.5.1. Configurazione

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 cmdlineauth_param ntlm children numberofchildrenauth_param ntlm max_challenge_reuses numberauth_param ntlm max_challenge_lifetime timespanauth_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


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 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/SERVERauth_param ntlm children 10 auth_param ntlm max_challenge_reuses 2 auth_param ntlm max_challenge_lifetime 15 minutes 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/hosts127.0.0.1 localhost.localdomain localhost192.168.0.3 athlon.sede_00.net server0192.168.0.5 dc.sede_01.net server1192.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 auth_param ntlm children 5 auth_param ntlm max_challenge_reuses 20 auth_param ntlm max_challenge_lifetime 15 minutesauth_param ntlm use_ntlm_negotiate off

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.exeauth_param ntlm children 5auth_param ntlm max_challenge_reuses 0auth_param ntlm max_challenge_lifetime 2 minutesauth_param ntlm use_ntlm_negotiate on

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 = domainencrypt 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



http://us1.samba.org/samba/ftp/docs/htmldocs/smbpasswd.8.html


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]auth_param ntlm children 5 auth_param ntlm max_challenge_reuses 0 auth_param ntlm max_challenge_lifetime 15 minutesauth_param ntlm use_ntlm_negotiate off

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-ntlmsspauth_param ntlm children 5auth_param ntlm max_challenge_reuses 0auth_param ntlm max_challenge_lifetime 15 minutesauth_param ntlm use_ntlm_negotiate onauth_param basic program /usr/local/samba/bin/ntlm_auth --helper-protocol=squid-2.5-basicauth_param basic children 5auth_param basic realm Squid proxy-caching web serverauth_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


http://www.samba.org/samba/docs/man/net.8.html

http://www.samba.org/samba/docs/man/net.8.html


● Dominio Active Directory (Samba 3 deve essere compilato con support Kerberos)

Inserire nel file smb.conf le seguenti direttive:

realm = your.kerberos.REALMsecurity = ADSencrypt 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.4http_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.comhttp_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.comhttp_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

11.6.1. Configurazione

Lo schema di autenticazione Digest utilizza i seguenti parametri

auth_param digest program cmdlineauth_param digest children numberofchildrenauth_param digest realm realmstringauth_param digest nonce_garbage_interval timeintervalauth_param digest nonce_max_duration timeintervalauth_param digest nonce_max_count numberauth_param digest nonce_strictness on|offauth_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


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, 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

esempio di configurazione



auth_param digest program /usr/local/squid/libexec/digest_pw_auth /usr/local/squid/etc/digpassauth_param digest children 10auth_param digest realm Squid proxy-caching web serverauth_param digest nonce_garbage_interval 5 minutesauth_param digest nonce_max_duration 30 minutesauth_param digest nonce_max_count 25auth_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 parse2004/09/21 22:31:31| squid.conf line 1832: http_access allow paperino2004/09/21 22:31:31| aclParseAccessLine: ACL name 'paperino' not found.2004/09/21 22:31:31| squid.conf line 1832: http_access allow paperino2004/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 -z2004/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 -z2004/01/25 15:58:06| Creating Swap DirectoriesFATAL: 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 8drwxr-xr-x 18 nobody nobody 4096 21 set 19:48 cachedrwxr-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,cache_effective_user nobodycache_effective_group nobody

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 -d12004/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 680052004/03/06 12:02:35| With 3584 file descriptors available2004/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


http://info.astrian.net/jargon/terms/b.html#boot


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


http://www.merlinobbs.net/Squid-Book/HTM/contrib/squid


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.shecho -n ' Squid 'case "$1" instart)/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.3warning: /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


http://www.fedoralegacy.org/

http://www.fedoralegacy.org/


% 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 thisSQUID_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/squidlrwxrwxrwx 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/logsPATH=/usr/bin:/sbin:/bin:/usr/sbinexport PATH## file descriptors (avvia squid con un limite max di 4096 FD)# echo 102400 > /proc/sys/fs/file-maxulimit -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/squidelseSQUID_OPTS="-D"SQUID_SHUTDOWN_TIMEOUT=100fi# 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 0prog="$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.confCACHE_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/cacheRETVAL=0start() {for adir in $CACHE_SWAP; doif [ ! -d $adir/00 ]; then echo -n "init_cache_dir $adir... "$SQUID -z -F 2>/dev/nullfidoneecho -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_failureechoreturn $RETVAL}stop() {echo -n $"Stopping $prog: "$SQUID -k check >/dev/null 2>&1RETVAL=$?if [ $RETVAL -eq 0 ] ; then$SQUID -k shutdown &rm -f /var/lock/subsys/$SQUIDtimeout=0while : ; do[ -f /usr/local/squid/var/run/squid.pid ] || breakif [ $timeout -ge $SQUID_SHUTDOWN_TIMEOUT ]; thenechoreturn 1fisleep 2 && echo -n "." timeout=$((timeout+2))



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



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 squidsquid: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_dircache_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 *% lstotale 20drwxr-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 snmpacl snmpManager src 192.168.0.4/255.255.255.255acl snmppublic snmp_community public# TAG: snmp_port# NOTE: SNMP support requires use the --enable-snmp configuresnmp_port 3401# TAG: snmp_accesssnmp_access allow snmpManagersnmp_access allow snmppublic localhostsnmp_access allow allowed_hostssnmp_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 startAvvio di squid: [ OK ]% netstat --l | grep webcachetcp 0 0 *:webcache *:* LISTEN% netstat --l | grep 3401udp 0 0 *:3401 *:*% nmap localhostStarting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-04-08 23:57 CESTInteresting ports on localhost (127.0.0.1):(The 1645 ports scanned but not shown below are in state: closed)PORT STATE SERVICE3128/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/K25squidlrwxrwxrwx 1 root root 15 27 dic 11:34 /etc/rc.d/rc6.d/K25squid -> ../init.d/squid% ls -l /etc/rc.d/rc0.d/K25squidlrwxrwxrwx 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 stopInterruzione di squid: [ OK ]% service squid startAvvio 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

% chkconfig --level 3 squid on% chkconfig --level 5 squid on

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 è

% make install clean

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

% /usr/local/etc/rc.d/squid.sh start



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à


http://net-snmp.sourceforge.net/


http://people.ee.ethz.ch/~oetiker/webtools/mrtg/

http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/

http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/


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 snmpManager src 10.0.0.2/255.255.255.255 acl snmppublic snmp_community public 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 snmpManager snmp_access allow snmppublic localhost snmp_access allow snmppublic locallan snmp_access deny all



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% make install clean

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.cacheAdminenterprises.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.cacheAdminsnmpget: 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

% snmpget -m SQUID-MIB -c public localhost:3401 \enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheMaxResSizeenterprises.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

% snmpget -m SQUID-MIB -c public localhost:3401 \enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheSysPageFaultsenterprises.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



% snmpget -m SQUID-MIB -c public localhost:3401 \enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheProtoAggregateStats.cacheProtoClientHttpRequestsenterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheProtoAggregateStats.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

% snmpget -m SQUID-MIB -c public localhost:3401 \enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheProtoAggregateStats.cacheIcpPktsRecventerprises.nlanr.squid.cachePerf.cacheProtoStats.cacheProtoAggregateStats.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

% snmpget -m SQUID-MIB -c public localhost:3401 \enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheMedianSvcTable.cacheMedianSvcEntry.cacheHttpAllSvcTime.5enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheMedianSvcTable.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

% snmpget -m SQUID-MIB -c public localhost:3401 \enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheMedianSvcTable.cacheMedianSvcEntry.cacheDnsSvcTime.5enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheMedianSvcTable.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

% snmpget -m SQUID-MIB -c public localhost:3401 \enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheCurrentUnusedFDescrCntenterprises.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

% snmpget -m SQUID-MIB -c public localhost:3401 \enterprises.nlanr.squid.cachePerf.cacheSysPerf.cacheCpuUsageenterprises.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

% snmpget -m SQUID-MIB -c public localhost:3401 \enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheMedianSvcTable.cacheMedianSvcEntry.cacheRequestHitRatio.5enterprises.nlanr.squid.cachePerf.cacheProtoStats.cacheMedianSvcTable.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/% make install clean

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/mrtgLoadMIBs: /usr/local/etc/squid/mib.txt Target[proxy-srvkbinout]: cacheServerInKb&cacheServerOutKb:[email protected]:3401MaxBytes[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/ .


http://www.cisco.com/

http://www.cisco.com/

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:


http://www.merlinobbs.net/Squid-Book/HTM/contrib


http://www.cache.dfn.de/DFN-Cache/Development/Monitoring/

http://www.acmeconsulting.it/pagine/opensource/squid/mrtg.htm

http://squid.visolve.com/related/snmp/monitoringsquid.htm

http://www.arnes.si/~matija/utrecht/lecture.html

http://hermes.wwwcache.ja.net/FAQ/FAQ-2.html#mrtg

http://howto.aphroland.de/HOWTO/MRTG/SquidMonitoringWithMRTG

http://people.ee.ethz.ch/~oetiker/webtools/mrtg/squid.html

http://thproxy.jinr.ru/file-archive/doc/squid/cache-snmp/mrtg-demo/

http://www.braindump.dk/en/wiki/?catid=7&wikipage=ConfigFiles


# 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.localhostcache.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

<VirtualHost 192.168.0.4><Location /usr/local/libexec/squid/cachemgr.cgi>order allow,denyallow 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



<VirtualHost 192.168.0.4><Location /usr/local/libexec/squid/cachemgr.cgi>AuthUserFile /etc/htpasswdAuthGroupFile /dev/nullAuthName User/Password RequiredAuthType Basicrequire 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


http://httpd.apache.org/


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 shutdowncachemgr_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 manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl 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 !localhosthttp_access allow all

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





acl manager proto cache_objectacl localhost src 127.0.0.1/255.255.255.255acl mywebserver src 192.168.0.4/255.255.255.255acl all src 0.0.0.0/0.0.0.0http_access deny manager !localhost !mywebserverhttp_access allow all

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.STABLE6Start Time: Sat, 25 Sep 2004 07:07:20 GMTCurrent Time: Sat, 25 Sep 2004 07:48:13 GMTConnection 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_recvicp.queries_recv = 0

13.6.5.5. DNS Service Time

% squidclient mgr:5min | grep dns.median_svc_timedns.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_usagecpu_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


http://www.junkbuster.com/


● /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% make install clean

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% lstotal -------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


http://www.cpan.org/

http://www.freebsd.org/cgi/url.cgi?ports/www/adzap/pkg-descr

ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/www/adzap/README.html

ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/www/adzap/README.html

http://adzapper.sourceforge.net/#download


procedura di ridirezione modificheremo il file di configurazione squid.conf

redirect_program /usr/local/libexec/squid_redirectredirect_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

cache_store_log none

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/0http_access allow all

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-queryprefer_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


http://www.squid-cache.org/Doc/Hierarchy-Tutorial/

http://www.nsf.gov/

http://www.cise.nsf.gov/

http://www.ucsd.edu/

http://www.sdsc.edu/

http://www.nlanr.net/

http://www.ircache.net/FAQ/


cache_announce 24announce_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.


http://www.ircache.net/Tracker/

http://www.ircache.net/Tracker/search.html

http://www.ircache.net/Tracker/search.html

http://www.garr.it/checosa/garr-b-checosa.shtml



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 supportoptions IPFIREWALL # firewalloptions IPFIREWALL_VERBOSE # abilita il loggingoptions IPFIREWALL_FORWARD # enable t. proxy supportoptions 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 xl0use_sockets yessame_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 wwwadd divert natd all from any to any via xl0add pass all from any to any via rl0add 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 Kerneloptions IPFILTERoptions 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 reterdr 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/shipf -Fa -E -f /etc/ipf.rulesipnat -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).


http://coombs.anu.edu.au/ipfilter/


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.

16.2.6.1. Configurare il proxy trasparente con Linux kernel 2.0.x

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 setCONFIG_INET=yCONFIG_IP_FORWARD=y# CONFIG_IP_MULTICAST is not setCONFIG_IP_FIREWALL=y# CONFIG_IP_FIREWALL_VERBOSE is not setCONFIG_IP_MASQUERADE=yCONFIG_IP_TRANSPARENT_PROXY=yCONFIG_IP_ALWAYS_DEFRAG=y# CONFIG_IP_ACCT is not setCONFIG_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).

16.2.6.2. Configurare il proxy trasparente con Linux kernel 2.2.x

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

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 iptables(8), maggiori dettagli sono reperibili alla URL http://www.squid-cache.org/Doc/FAQ/FAQ-17.html#ss17.4.


http://www.linuxdoc.org/HOWTO/mini/TransparentProxy.html




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_host virtual httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_uses_host_header on

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


http://www.cisco.com/en/US/products/hw/contnetw/ps1894/index.html

http://www.cisco.com/en/US/products/hw/contnetw/ps1894/index.html

http://www.f5.com/f5products/bigip/

http://www.foundrynet.com/products/webswitches/serveriron/index.html

http://www.foundrynet.com/products/webswitches/serveriron/index.html

http://www.radware.com/content/products/csd/default.asp

http://www.radware.com/content/products/csd/default.asp

http://www.linuxvirtualserver.org/

http://www.linuxvirtualserver.org/



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/0ip 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 1ip wccp web-cache!interface fastethernet0/0ip 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.254wccp_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


http://devel.squid-cache.org/projects.html#visolve_wccpv2

http://devel.squid-cache.org/projects.html#visolve_wccpv2


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


http://www.squid-cache.org/WCCP-support/Linux/

http://www.squid-cache.org/WCCP-support/Linux/ip_wccp.c



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 wwwaccess-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 10match ip address 110set 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 Ethernet0ip 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 wwwaccess-list 110 deny tcp host 192.168.1.13 anyaccess-list 110 permit tcp any any!route-map proxy-redirect permit 10match ip address 110set ip next-hop 192.168.1.13!interface Ethernet0ip 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

% squid -k reconfigure% netstat -t -l | grep httptcp 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 -nodesUsing configuration from /usr/share/ssl/openssl.cnfGenerating 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 incorporatedinto 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 blankFor some fields there will be a default value,If you enter '.', the field will be left blank.-----Country Name (2 letter code) [GB]:ITState or Province Name (full name) [Berkshire]:ItalyLocality Name (eg, city) [Newbury]:Mia_Città



Organization Name (eg, company) [My Company Ltd]:OrganizzazioneOrganizational Unit Name (eg, section) []:NetworkingCommon Name (eg, your name or your server's hostname) []:host.dominio.netEmail 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_host 10.251.10.254httpd_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

httpd_accel_with_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



% squid -k reconfigure% netstat -t -l | grep httpstcp 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 acl allowed_hosts src 0.0.0.0/0.0.0.0 http_access allow allowed_hosts httpd_accel_host 192.168.0.3 httpd_accel_port 80 httpd_accel_single_host on httpd_accel_with_proxy onhttpd_accel_uses_host_header off

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://www.visolve.com/


http_port 80 acl allowed_hosts src 0.0.0.0/0.0.0.0 http_access allow allowed_hosts httpd_accel_host 127.0.0.1 httpd_accel_port 81 httpd_accel_single_host on httpd_accel_with_proxy on httpd_accel_uses_host_header off

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 acl allowed_hosts src 0.0.0.0/0.0.0.0 http_access allow allowed_hosts httpd_accel_host virtual httpd_accel_port 80 httpd_accel_single_host off httpd_accel_with_proxy on httpd_accel_uses_host_header off

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.1www.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.keyhttpd_accel_host 10.251.10.254httpd_accel_port 80httpd_accel_single_host offhttpd_accel_with_proxy onhttpd_accel_uses_host_header off

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.


http://www.isc.org/products/BIND/


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.100wpad 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


http://www.web-cache.com/Writings/Internet-Drafts/draft-ietf-wrec-wpad-01.txt

http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html

http://www.isc.org/products/DHCP/


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.4proxy2 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.


http://www.isc.org/products/BIND/


Ecco un dettaglio delle specifiche hardware e software adottate

Pentium III 500 Mhz 256 Mb RAM Pentium III 500 Mhz 384 Mb RAMOS Linux (Kernel 2.4.x) OS Linux (Kernel 2.4.x)Squid appliance 2.4 St. 6 patched Squid appliance 2.4 St. 6 patchedSupporto SNMP abilitato Supporto SNMP abilitaton. 1 Disco EIDE da 10 Gb 5000 RPM n. 2 Dischi EIDE da 20 Gb 7200 RPM64 Mb di cache_mem 96 Mb di cache_mem2524 Mb di cache su FS EXT3 2500 Mb di cache su FS EXT3Server 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 == "2" ) return 0x32; if ( charstring == "3" ) return 0x33; if ( charstring == "4" ) return 0x34; if ( charstring == "5" ) return 0x35; if ( charstring == "6" ) return 0x36; if ( charstring == "7" ) return 0x37; if ( charstring == "8" ) return 0x38; if ( charstring == "9" ) return 0x39; 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 1delay_class 1 1delay_access 1 allow alldelay_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.255acl student src 192.168.200.0/255.255.255.0acl admin src 192.168.300.0/255.255.255.0acl magic_words1 url_regex -i 192.168acl 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 2delay_parameters 1 256000/256000 5000/256000delay_access 1 allow magic_words2delay_access 1 allow studentdelay_access 1 allow admin

con il valore -1/-1 indichiamo che non vi sono limiti di sorta per il traffico locale



delay_class 2 2delay_parameters 2 -1/-1 -1/-1delay_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

http_access deny ftpblock

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.


http://www.garr.it/

http://www.dante.net/


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.


http://www.caspur.it/

http://www.cache.garr.it/

http://www.cache.garr.it/

http://www.squid-cache.org/Advisories/


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.


http://www.dansguardian.org/

http://www.squidguard.org/

http://viralator.loddington.com/

http://sourceforge.net/projects/openantivirus/

http://sourceforge.net/projects/openantivirus/

http://www.pcxperience.org/dgvirus/

http://www.trendmicro.com/en/products/gateway/iwss/evaluate/overview.htm

http://www.trendmicro.com/en/products/gateway/iwss/evaluate/overview.htm


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-digestnever_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% /usr/local/etc/rc.d/squid.sh start

oppure



% squid -k reconfigure

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


http://squid-docs.sourceforge.net/latest/html/c911.html#AEN913


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


http://www.bpfh.net/simes/computing/chroot-break.html

http://www.bpfh.net/simes/computing/chroot-break.html


% 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 libm.so.6 => /lib/libm.so.6 (0x00136000) libresolv.so.2 => /lib/libresolv.so.2 (0x00158000) libnsl.so.1 => /lib/libnsl.so.1 (0x00169000) libc.so.6 => /lib/libc.so.6 (0x0017e000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00110000) % ldd /squid/libexec/squid/diskd libm.so.6 => /lib/libm.so.6 (0x00136000) libc.so.6 => /lib/libc.so.6 (0x00158000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00110000) % ldd /squid/libexec/squid/unlinkd



libc.so.6 => /lib/libc.so.6 (0x00136000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00110000)

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.


http://cr.yp.to/daemontools/daemontools-0.76.tar.gz

http://cr.yp.to/daemontools/daemontools-0.76.tar.gz


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/shexec ./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

20.7. Sistemi Windows

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

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

nel file access.log vengono registrate tutte le transazioni effettuate dai client

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, ne analizzeremo i dettagli in seguito


http://www.squid-cache.org/Scripts/

http://www.squid-cache.org/Scripts/


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

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

emulate_httpd_log on

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.


http://devel.squid-cache.org/customlog/

http://devel.squid-cache.org/cgi-bin/diff2/customlog.patch


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

% squid -k reconfigure2004/04/13 12:34:39| Cache dir '/usr/local/squid/var/cache' size changed to 102400 KB2004/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.log2004/04/13 12:21:14| Reconfiguring Squid Cache (version 3.0-PRE3)...2004/04/13 12:21:14| FD 11 Closing HTTP connection2004/04/13 12:21:14| FD 12 Closing ICP connection2004/04/13 12:21:14| FD 13 Closing HTCP socket2004/04/13 12:21:14| FD 14 Closing SNMP socket2004/04/13 12:21:14| Cache dir '/usr/local/squid/var/cache' size remains unchanged at 102400 KB2004/04/13 12:21:14| Initialising SSL.2004/04/13 12:21:14| Error error setting CA certificate locations: error:00000000:lib(0):func(0):reason(0)2004/04/13 12:21:14| continuing anyway...2004/04/13 12:21:14| User-Agent logging is disabled.2004/04/13 12:21:14| DNS Socket created at 0.0.0.0, port 32793, FD 72004/04/13 12:21:14| Adding nameserver 192.168.10.4 from /etc/resolv.conf2004/04/13 12:21:14| Adding nameserver 192.168.10.254 from /etc/resolv.conf2004/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.


http://cord.de/tools/squid/Welcome.html.en


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

% squid -k reconfigure2004/04/13 12:34:39| Initialising SSL.2004/04/13 12:34:39| Using certificate in /usr/local/squid/etc/key.crt2004/04/13 12:34:39| Using private key in /usr/local/squid/etc/key.key2004/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...2004/04/13 12:34:39| Cache dir '/usr/local/squid/var/cache' size changed to 102400 KB2004/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.log2004/04/13 12:34:39| Reconfiguring Squid Cache (version 3.0-PRE3)...2004/04/13 12:34:39| FD 8 Closing HTTP connection2004/04/13 12:34:39| FD 10 Closing ICP connection2004/04/13 12:34:39| FD 11 Closing HTCP socket2004/04/13 12:34:39| FD 12 Closing SNMP socket2004/04/13 12:34:39| Initialising SSL.2004/04/13 12:34:39| Using certificate in /usr/local/squid/etc/key.crt2004/04/13 12:34:39| Using private key in /usr/local/squid/etc/key.key2004/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...2004/04/13 12:34:39| Cache dir '/usr/local/squid/var/cache' size remains unchanged at 102400 KB2004/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...2004/04/13 12:34:39| User-Agent logging is disabled.2004/04/13 12:34:39| DNS Socket created at 0.0.0.0, port 32796, FD 72004/04/13 12:34:39| Adding nameserver 192.168.10.4 from /etc/resolv.conf2004/04/13 12:34:39| Adding nameserver 192.168.10.254 from /etc/resolv.conf2004/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:DIRECT2 5528 14.96% TCP_REFRESH_HIT:DIRECT3 4576 12.38% TCP_HIT:NONE4 4566 12.35% TCP_CLIENT_REFRESH_MISS:DIRECT5 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"416" ; Squid unsupported"417" ; Squid unsupported"500" ; Section 10.5.1: Internal Server Error"501" ; Section 10.5.2: Not Implemented


http://www.w3.org/Protocols/rfc2616/rfc2616.html



"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 searchesHEAD HTTP/1.0 possibly metadata retrievalPOST 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 routeOPTIONS HTTP/1.1 never request available comm. optionsCONNECT HTTP/1.1r3 never tunnel SSL connectionICP_QUERY Squid never used for ICP based exchangesPURGE Squid never remove object from cachePROPFIND rfc2518 ? retrieve properties of an objectPROPATCH rfc2518 ? change properties of an objectMKCOL rfc2518 never create a new collectionCOPY rfc2518 never create a duplicate of src in dstMOVE rfc2518 never atomically move src to dstLOCK rfc2518 never lock an object against modificationsUNLOCK 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 availableSIBLING_UDP_HIT_OBJ hit objects are not longer availableSSL_PARENT_MISS SSL can now be handled by squidFIREWALL_IP_DIRECT No special logging for hosts inside the firewallLOCAL_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






http://www.inktomi.com/

http://zipper.paco.net/~igor/oops.eng/


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


http://cord.de/tools/squid/calamaris/Welcome.html.en


% /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 Italianaccess_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


http://www.mrunix.net/webalizer/

http://www.mrunix.net/webalizer/


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.


http://sarg.sourceforge.net/

http://www.rraz.net/squeezer2/


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


http://verplant.org/yaala/

http://ababa.org/index.html

http://logrep.sourceforge.net/

http://logreport.org/lire/


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://www.jeroen.se/squidefender.php



http://www.merlinobbs.net/Squid-Book/HTM/contrib/squid.giovanni.conf


http_port 3128 # porta di utilizzo della cacheicp_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 cachecache_mem 96 MB # memoria max utilizzata dal processo che amministra la cachemaximum_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 emulate_httpd_log on # 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 password proxy_auth REQUIRED # acl per la richiesta un'autenticazione valida 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 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 SSL_ports port 443 563 acl Safe_ports port 80 21 443 563 70 210 1025-65535 acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker



acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT # discrimina il metodo CONNECT secondo le specifiche HTTP/1.1 acl snmpManager src 192.168.1.14/255.255.255.255 acl snmppublic snmp_community public 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 password http_access allow manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost http_access allow notporn http_access deny porn http_access deny ftpblock http_access allow passwordhttp_access deny all 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 snmpManager snmp_access allow snmppublic localhost snmp_access allow snmppublic locallan snmp_access deny all

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


http://www.lyx.org/


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.


http://www.merlinobbs.net/LDP/LDP/LDP-Author-Guide/html/templates.html

http://www.merlinobbs.net/LDP/LDP/LDP-Author-Guide/html/templates.html

http://tille.soti.org/

http://tidy.sourceforge.net/







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)








http://merlino.merlinobbs.net/Squid-Book/

http://www.majaglug.net/doc/Squid-Book/index.html


● 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


http://www.llg.it/Squid-Book/

http://www.acmeconsulting.it/Squid-Book/

http://rm.mirror.garr.it/mirrors/Squid-Book/

http://www.ecomstation.it/pido2/home/djspider8/squidbook/

http://www.ietf.org/


[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


http://www.isi.edu/in-notes/iana/assignments/media-types/media-types

Documents

Squid-Book oltre le FAQ - digilander.libero.itdigilander.libero.it/novavoice/reti/Squid-Book oltre le FAQ.pdf · documento, Squid Proxy Server, Configurare SNMP e le FAQ per il controllo