Squid-Book oltre le FAQ

Transcript

1 Squid-Book oltre le FAQ Stefano Tagliaferri <squid(at)merlinobbs.net> Diario delle Revisioni Revisione Dicembre 2005 utilizzare le ACL per bloccare msn-messanger Revisione Novembre 2005 Core developers, nuove opzioni di configurazione relative a Squid 2.5-STABLE12 Revisione Aprile 2005 backport proxy anonimizzante Revisione 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 Luglio 2004 Aggiornamento della versione di Squid, alcuni aggiornamenti sull'helper ntlm_auth Revisione 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 Revisione Aprile 2004 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 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 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 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 Revisione Gennaio (1 of 263)14/02/

2 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 Revisione Novembre 2003 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 Settembre 2003 Alcune annotazioni sull'utilizzo delle acl e dei controlli di accesso Revisione 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 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 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. Revisione Aprile 2003 GARR Network's FTP Archive diviene mirror ufficiale dello Squid-Book. Revisione Aprile 2003 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) Revisione Gennaio 2003 Differenze tra rel. 2.4 e 2.5 (Federico Lombardo), schemi di autenticazione (Guido Serassio) Revisione Novembre 2002 Modificato il capitolo con il quale si spiega cosa è Squid (aggiornato con il link relativo al porting per la piattaforma Win32) Revisione Novembre 2002 Modificato il capitolo dedicato alle funzionalità di reverse proxy (aggiunta di esempi reali sul funzionamento dei reverse proxy) Revisione 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 Stefano Tagliaferri (2 of 263)14/02/

3 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 L'architettura Web Clients e Servers Proxies Oggetti web URL Un sistema di webcache 3.2. Fattori basilari che intervengono nella trasmissione dei dati Tempo di latenza (latency) Capacità di banda (bandwidth) Utilizzo delle risorse del server (server load) 3.3. Come lavora un apparato di webcache 3.4. Riduzione delle esigenze di banda 3.5. Fattori che determinano il risparmio di banda (3 of 263)14/02/

4 contenuti pagina web numero degli utenti tipologia degli utenti tipo di webcache utilizzata 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 Una piccola panoramica su Gopher Una piccola panoramica su WWWCACHE Cosa sono le cache gerarchiche Internet Cache Protocol (ICP) Cache Array Routing Protocol (CARP) Hyper Text Caching Protocol (HTCP) Cache Digest Concludendo 4. I sistemi operativi che supportano Squid 4.1. Preambolo 4.2. Piattaforme specifiche 4.3. Sistemi UNIX GNU Linux FreeBSD 4.4. Sistemi Windows 4.5. Sistemi OS/2 5. Differenze tra Squid 2.4 e Squid 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 Utilizzo della memoria RAM Tipo di CPU Simmetric Multi Processor (SMP) Sottosistema dischi e tecnologie Sistemi in RAID 7.4. Il sistema ottimale 7.5. I file sorgenti di Squid Accesso al CVS (4 of 263)14/02/

5 Squid current Squid vecchie versioni verificare il CVS appena prelevato Prelevare Squid Compilare Squid eseguire lo script di configurazione eseguire nuovamente lo script di./configure Applicare le patch Versione giornaliera autogenerata Opzioni di configurazione 7.6. Il problema dei file descriptor Determinare il numero corretto di file descriptor File descriptor con Linux File descriptor con Solaris File descriptors con FreeBSD MAXFILES MBUF File descriptors con Windows File handles con OS/ Il problema dell'insieme delle porte 7.8. Installare Squid dai sorgenti Perchè installare Squid dai sorgenti I comandi più importanti L'albero delle directory di Squid Pulire gli eseguibili dalle informazioni di debug Altre informazioni per installare correttamente Squid dai sorgenti 7.9. Disponibilità di pacchetti precompilati Package per i vari ambienti UNIX 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 Files di log principali Files di log accessori Formati dei files di log Ruotare i files di log Disabilitare i files di log Mime tipe e file di processo Memoria e cache_dir 8.7. Parametri amministrativi 8.8. Utente e Gruppo (UID e GID) 8.9. Controlli di accesso Redirect (5 of 263)14/02/

6 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 ufs storage aufs storage awin32 storage diskd storage Tuning dei parametri Q1 e Q Configurare la coda dei messaggi (message queues) Coda dei messaggi con BSD Coda dei messaggi con Linux Coda dei messaggi con Solaris Configurare la memoria condivisa (shared memory) Memoria condivisa con BSD Memoria condivisa con Linux Memoria condivisa con Solaris null storage coss storage Scelta del Disk storage più adatto Esempi di configurazione Configurare diskd con FreeBSD Configurare ufs (multipiattaforma) Configurare aufs con Linux Configurare awin32 con Windows 9.7. Memory storage Parametri di configurazione 9.8. Memory e Cache Replacement Policy Parametri di configurazione 9.9. Indicazione dimensionamento del cache store 10. Controlli di accesso Preambolo Elementi che compongono le ACL Capire il funzionamento delle ACL Utilizzare le ACL per autenticare degli utenti External ACL wb_group Utilizzo di wbinfo_group con Samba win32_check_group squid_ldap_group squid_unix_group ip_group_check Controllo d'accesso sui siti web (6 of 263)14/02/

7 Controlli di accesso e URL filtering Definire una lista di siti visitabili Raggiungere direttamente domini o siti predefiniti Bloccare gli spyware Bloccare web radio e TV Bloccare msn-messanger (Yahoo Messanger) No cache ACL basate sul MAC address 11. Autenticazione degli utenti Preambolo Schemi di autenticazione Basic authentication NTLM authentication Digest authentication Parametri di Configurazione Basic Authentication Configurazione in Squid Configurazione in Squid helper NCSA Generare il DB degli utenti helper PAM Red Hat Linux Unix Standard helper LDAP Esempi di configurazione helper Winbindd helper MSNT NTLM Authentication Configurazione Autenticazione NTLM nativa helper SMB (ntlm_auth) helper fakeauth & no_check helper Windows win32_ntlm_auth Autenticazione NTLM con Samba 2.2.x Compilazione helpers Configurazione di Samba helper wb_ntlmauth Autenticazione NTLM con Samba helper esterno Samba 3.x ntlm_auth Inserire nel dominio la macchina Samba Problemi comuni con NTLM Java runtime ftp Windows Update V5 (Windows XP-SP2) Windows Utenti non autenticati Digest Authentication (7 of 263)14/02/

8 Configurazione helper digest_pw_auth 12. Avviare Squid Preambolo Istruzioni multipiattaforma Controllare il file di configurazione Prepariamo lo spazio dedicato alla cache Avviare Squid manualmente Avviamo Squid come processo Avviare Squid automaticamente con il boot del sistema Avviare Squid utilizzando la tabella di inittab Avviare Squid utilizzando il file rc.local Avviare Squid con i sistemi *BSD (init.d e rc.d) Fermare Squid Avviare una versione compilata su Red Hat Linux RedHat, Fedora Core e Mandrake Linux Debian GNU/Linux FreeBSD OS/2 o EComStation Windows NT/2000/XP/ Monitorare il funzionamento di Squid Controlliamo la nostra cache Analizziamo le informazioni Request rate Response time bandwidth stato delle connessioni Altri fattori Gli strumenti di controllo offerti da Squid Due parole su SNMP Configurare l'agent SNMP di Squid Net-snmp Controllare i processi utilizzando Net-snmp process size page fault rate HTTP request rate ICP request rate Denied requests HTTP service time DNS service time File descriptor aperti Utilizzo della CPU Spazio su disco Hit ratio MRTG e Squid Risorse in rete per utilizzare Squid con MRTG Il Cache Manager (8 of 263)14/02/

9 Configurare cachemgr.cgi con Apache Configurare cachemgr.cgi con IIS Impostare la password di accesso al Cache Manager Definire una ACL per consentire l'accesso al Cache Manager Interrogare il Cache Manager utilizzando la linea di comando Process size Page Fault Rate HTTP Request Rate ICP Request Rate DNS Service Time File Descriptors CPU Usage 14. Privacy Preambolo Note operative Internet Junkbuster Definizioni ed albero delle directory, file di configurazione Verificare il funzionamento di Junkbuster Privoxy files di configurazione di Privoxy Ad Zapping con Squid Differenze con Junkbuster e Privoxy Vantaggi della ridirezione Prerequisiti di Ad Zapping installare Ad Zapping Fornire agli utenti un servizio di Web Caching anonimo 15. Comunicare con altri proxy server Preambolo Esempi e relazioni tra webcache Alcune informazioni su IRCACHE Alcune informazioni sul Servizio di Cache Nazionale GARR 16. Proxy trasparente Preambolo Concetto di inline cache L'applicazione che esegue il filtro dei pacchetti Alcune annotazioni Filtraggio con GNU Linux Filtraggio con FreeBSD utilizziamo ipfw Filtraggio con altri sistemi UNIX utilizziamo ipf Esempi di inline cache con Linux Configurare il proxy trasparente con Linux kernel 2.0.x Configurare il proxy trasparente con Linux kernel 2.2.x Configurare il proxy trasparente con Linux kernel 2.4.x e 2.6.x Abilitare inline cache con Squid L'ipmasquerade con LINUX kernel 2.2.x/2.4.x (9 of 263)14/02/

10 16.3. Gli switch di livello quattro WCCP (Web Cache Coordination Protocol) Configurare WCCP con Cisco IOS Configurare WCCP con Squid Abilitare l'interfaccia GRE con FreeBSD Abilitare l'interfaccia GRE con Linux Policy di routing con i router Cisco 17. Reverse proxy Server HTTPD e content caching Reverse Proxy SSL Reverse Proxy Esempi e situazioni reali Reverse Proxy di Server web o cluster HA installati su una macchina differente Reverse Proxy di server web installato sulla stessa macchina che esegue Squid Reverse Proxy per domini multipli SSL Reverse Proxy di un server web o di un cluster HA installato su una macchina differente 18. Proxy load balancer Preambolo WPAD protocol DHCP e configurazione automatica del browser Fail over e load balancer 19. Limitazione della banda per classi Preambolo Squid ed i Delay pools Limitare la banda per singole connessioni a 128 kbps Limitare la banda totale a 512 kbps Limitare la banda con una linea a 2 Mbps Limitare il download di alcuni files 20. Security ed utilizzi estremi Preambolo Squid come ultima risorsa Squid e la sicurezza Sicurezza in quanto Servizio Squid ed Antivirus InterScan Web Security Suite Sicurezza come interazione con il sistema operativo ospitante Sistemi UNIX, cloni e BSD La modalità chroot() nei sistemi UNIX cloni o BSD Squid e Daemontools Sistemi Windows Sistemi OS/2 21. La analisi dei log di Squid Preambolo I log nativi Log in altri formati Troubleshooting con il file cache.log Utilizzare tail(8) ed xterm(8) (10 of 263)14/02/

11 Livelli di debug I codici di stato di Squid Codici di Stato HTTP Metodi di richiesta supportati Codici gerarchici per il peering con altre webcache Strumenti di analisi dei Log Calamaris Webalizer Sarg Squeezer Yaala SquidAlyser Logrep LIRE 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" 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. (11 of 263)14/02/

12 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 Licenza d'utilizzo 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 (squid(at)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 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 Riferimenti La presente documentazione fa parte del progetto Squid ( 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: Mirror italiano del progetto Squid: URLs Security Focus per la security: Squid Frequently Asked Questions (FAQ) 2001 Duane Wessels: Squid Configuring Hierarchical Squid Caches di Duane Wessels: Squid Programmers Guide di Duane Wessels: (12 of 263)14/02/

13 Squid User's Guide di Oskar Pearson: IRCache Project: Benefits of Web Caching di Joe Cooper alla URLs: Designing a Web Caching Infrastructure for Your Network di Joe Cooper alla URLs: 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 # (13 of 263)14/02/

14 # 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 ( 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 (14 of 263)14/02/

15 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" ( e può essere ridistribuito e modificato secondo quanto previsto dall'accordo della Licenza Pubblica GNU ( e viene distribuito all'utente finale senza nessuna garanzia. Nella GNU Pubblice License ( 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" ( Mailing lists Per migliorare l'utilizzo di Squid, le sue funzionalità, le performance e per contribuire al lavoro di miglioramento nonchè alla continua correzione dei problemi, è possibile aderire a cinque mailing lists squid-users@squid-cache.org - discussioni generali sull'utilizzo di squid squid-announce@squid-cache.org - lista per il rilascio delle nuove release squid-bugs@squid-cache.org - lista per l'annuncio dei nuovi bugs e problemi squid@squid-cache.org - lista per il feedback e nuove idee squid-faq@squid-cache.org - lista per il feedback, gli aggiornamenti e contributi addizionali per le Squid FAQ mailing lists non strettamente legate al progetto Squid cache-snmp@ircache.net - lista sulle implementazioni del protocollo SNMP in ambito webcaching icp-wg@ircache.net - lista dell'icp Working Group e di Internet Engineering Task Force (IETF 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. (15 of 263)14/02/

16 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 in seguito, le nuove versioni, complete di nuove informazioni, sono state pubblicate alla URLs 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 ( 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 ( 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 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 (16 of 263)14/02/

17 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 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 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 L'architettura Web (17 of 263)14/02/

18 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 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 ( 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) 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 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 ( number=1738) 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 (18 of 263)14/02/

19 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 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 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 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 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 Come lavora un apparato di webcache (19 of 263)14/02/

20 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 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 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 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 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 (20 of 263)14/02/

21 appropriato e un corretto sistema operativo di classe UNIX possono fare la differenza 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 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 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 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. (21 of 263)14/02/

22 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 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 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 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 ( che è molto differente dalla specifiche originarie che furono definite nella RFC 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) 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 ( 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 ( rfc2246.txt?number=2818). (22 of 263)14/02/

23 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 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% 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 (23 of 263)14/02/

24 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 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 ( specifiche del protocollo ICPv2 RFC 2187 ( specifiche applicative del protocollo ICPv2 (24 of 263)14/02/

25 ICP ( 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 ( Cisco Cache Engine ( Volera ( BlueCoat ( imimic DataReactor ( 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 ( Carp white paper ( 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 ( 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 (25 of 263)14/02/

26 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 ( 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 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 (26 of 263)14/02/

27 come SCO e Solaris nonchè i vari sistemi Windows come NT, 2000 e 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 (27 of 263)14/02/

28 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 squidbugs@squid-cache.org 4.2. Piattaforme specifiche In questo capitolo è nostra intenzione trattare alcune delle piattaforme e dei sistemi operativi sui quali viene oggi sviluppato Squid. OS/2 è la piattaforma sulla quale si è sviluppato inizialmente questo documento, GNU Linux e FreeBSD sono le piattaforme UNIX per eccellenza mentre la piattaforma Windows rappresenta un nuovo ramo nello sviluppo di Squid. Su questi sistemi operativi sono stati eseguiti i test e sono anche state provate moltissime delle configurazioni che verranno trattate in seguito 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 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 FreeBSD Thomas-Martin Seck <tmseck(at)netcologne.de> è l'attuale maintainer del ports per FreeBSD ( 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. (28 of 263)14/02/

29 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 ( 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 ( 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 Sistemi OS/2 Il porting di Squid per OS/2 viene effettuato tramite alcune librerie di runtime denominate EMX ( 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 index_l.html. Capitolo 5. Differenze tra Squid 2.4 e Squid 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 (29 of 263)14/02/

30 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 ( 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 (30 of 263)14/02/

31 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 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) 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 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 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 ( (31 of 263)14/02/

32 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 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 ( 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 ) 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 (32 of 263)14/02/

33 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.STABLE utenti diskd disk store (filesystem UFS [5]), autenticazione ntlm in AD[6] Server Fujitsu-Siemens Primergy L200 - PIII 1,3GHz - 1GB RAM - dischi SCSI RAID 5 [7] FreeBSD 4.11-STABLE Squid-2.5.STABLE utenti diskd disk store (filesystem UFS), autenticazione ntlm in AD Server Compaq Proliant - PII 450 MHz MB RAM - disco SCSI FreeBSD 4.11-STABLE Squid-2.5.STABLE10 50 utenti (33 of 263)14/02/

34 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 MB RAM - 2 x IDE 40 GB RAID 1 HW Promise FastTrack TX100 Debian GNU/Linux 3.0r1 kernel Squid-2.5STABLE3 80 utenti aufs disk store [8] (filesystem Ext3), autenticazione basic NCSA PC PII 266 MHz MB RAM - 2 x IDE 30 GB mirror SW Windows 2000 Server SP4 Squid-2.5STABLE4 15 utenti awin32 disk store (filesystem NTFS), autenticazione basic e NTLM in AD PC AMD Athlon XP 1,4 GZ MB RAM - 1 x IDE 20 GB (SO) con 2 x IDE 120 GB Red Hat Linux 7.3 kernel legacy Squid-2.5.STABLE6 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 (34 of 263)14/02/

35 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 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 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 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. (35 of 263)14/02/

36 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 /13 = ,07692 oggetti su disco 75*76.923,07692 = ,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 /13 = ,6154 oggetti su disco 75* ,6154 = ,16 pari a circa 48 MB di RAM per 8 GB di disk storage Squid richiederà circa 48 MB di RAM per funzionare correttamente 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) 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 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 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 (36 of 263)14/02/

37 il numero di files presenti sul file system 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 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 (37 of 263)14/02/

38 Ulteriori dettagli alla URLs: 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 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 ( 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 ( - 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 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 (38 of 263)14/02/

39 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:anoncvs@cvs.squid-cache.org:/squid login CVS password: a questo punto digitare anoncvs, subito dopo % cvs -z3 -d :pserver:anoncvs@cvs.squid-cache.org:/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 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:anoncvs@cvs.squid-cache.org:/squid login CVS password: per Squid-2.5 dovremmo utilizzare il comando % cvs -z3 -d :pserver:anoncvs@cvs.squid-cache.org:/squid co -r SQUID_2_5 squid per aggiornare i sorgenti digitare il comando cvs -dp all'interno della directory squid (39 of 263)14/02/

40 % cd squid % cvs -z3 update -dp per Squid-2.4 dovremmo utilizzare il comando % cvs -z3 -d :pserver:anoncvs@cvs.squid-cache.org:/squid co -r SQUID_2_4 squid per aggiornare i sorgenti digitare il comando cvs -dp all'interno della directory squid % cd squid % cvs -z3 update -dp verificare il CVS appena prelevato utilizzando il comando more(8) possiamo eseguire una pipe di interrogazione sul file di./configure per verificare la versione di Squid appena prelevata da cvs.squid-cache.org % cd squid % more configure grep VERSION VERSION=2.5.STABLE7-RC3-CVS non è possibile manipolare le versioni correnti e quelle passate dei files, i clients possono effettuare le stesse operazioni che sono anche disponibili localmente, maggiori informazioni per prelevare un sistema CVS possono essere reperite alla URLs 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 % fetch ftp://ftp.squid-cache.org/pub/squid-2/stable/squid-2.5.stable6.tar.gz Receiving squid-2.5.stable6.tar.gz ( bytes): 100% bytes transferred in 18.9 seconds (69.94 kbps) (40 of 263)14/02/

41 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 ( 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 ( 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 eseguire lo script di configurazione Dopo aver prelevato la distribuzione è necessario scompattarla, utilizzeremo in comando bunzip2(8) ed il comando tar(8), sono necessari almeno 20 MB liberi sul disco. In ogni caso, per compilare ed installare tutte le versioni di Squid, è necessario eseguire lo script di./configure prima di lanciare il comando make % bunzip2 squid-2.5.stable5.tar.bz2 % tar xvf squid-2.5.stable5.tar squid-2.5.stable5/ squid-2.5.stable5/contributors... % cd squid-2.5.stable5 %./configure tutte le caratteristiche di Squid vengono attivate utilizzando lo script di configurazione (./configure), alcune di queste caratteristiche, per essere attivate, devono essere dichiarate specificatamente al momento della compilazione dei codici sorgenti, per ottenere una configurazione ottimale può anche rendersi necessario ricompilare ulteriormente e vedremo in seguito come procedere. Una delle ragioni per le quali una specifica caratteristica di Squid possa non essere disponibile è determinata dal livello di compatibilità del sistema operativo con i codici sorgenti. Anche se Squid viene rilasciato con un codice sorgente valido per un'utilizzo generico e multipiattaforma, è comunque possibile che determinate funzioni, come async-io o le ACL ARP-based, non siano disponibili per quel tipo di sistema operativo. Lo script di configurazione (./configure) può contenere alcune caratteristiche che informano gli utenti sullo stato delle opzioni di configurazione disponibili. Alcuni Amministratori di Sistema disabilitano volutamente determinate caratteristiche di Squid per rendere sempre più performante e sicuro il funzionamento delle loro piattaforme, come abbiamo accennato prima, è possibile includere in Squid le funzionalità che oggi non sono richieste senza problemi o effetti collaterali ricompilando i sorgenti in un secondo momento. (41 of 263)14/02/

42 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 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 (42 of 263)14/02/

43 % 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 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/) 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 (43 of 263)14/02/

44 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 è Versions/v2/2.5/, la sezione da consultare per procedere con il download è la "Daily auto-generated release" % fetch Receiving squid-2.5.stable tar.gz ( bytes): 100% 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.stable tar.gz % cd squid-2.5.stable %./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 Opzioni di configurazione Come abbiamo visto, lo script di./configure può essere avviato con numerose opzioni, una di quelle più utilizzate è (44 of 263)14/02/

45 %./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 (45 of 263)14/02/

46 Usage: configure [options] [host] Options: [defaults in brackets after descriptions] Configuration: --cache-file=file cache test results in FILE --help print this message --no-create do not create output files --quiet, --silent do not print `checking...' messages --site-file=file use FILE as the site file --version print the version of autoconf that created configure Directory and file names: --prefix=prefix install architecture-independent files in PREFIX [/usr/local/squid] --exec-prefix=eprefix install architecture-dependent files in EPREFIX [same as prefix] --bindir=dir user executables in DIR [EPREFIX/bin] --sbindir=dir system admin executables in DIR [EPREFIX/sbin] --libexecdir=dir program executables in DIR [EPREFIX/libexec] --datadir=dir read-only architecture-independent data in DIR [PREFIX/share] --sysconfdir=dir read-only single-machine data in DIR [PREFIX/etc] --sharedstatedir=dir modifiable architecture-independent data in DIR [PREFIX/com] --localstatedir=dir modifiable single-machine data in DIR [PREFIX/var] --libdir=dir object code libraries in DIR [EPREFIX/lib] --includedir=dir C header files in DIR [PREFIX/include] --oldincludedir=dir C header files for non-gcc in DIR [/usr/include] --infodir=dir info documentation in DIR [PREFIX/info] --mandir=dir man documentation in DIR [PREFIX/man] --srcdir=dir find the sources in DIR [configure dir or..] --program-prefix=prefix prepend PREFIX to installed program names --program-suffix=suffix append SUFFIX to installed program names --program-transform-name=program run sed PROGRAM on installed program names Host type: --build=build configure for building on BUILD [BUILD=HOST] --host=host configure for HOST [guessed] --target=target configure for TARGET [TARGET=HOST] Features and packages: --disable-feature do not include FEATURE (same as --enable-feature=no) --enable-feature[=arg] include FEATURE [ARG=yes] --with-package[=arg] use PACKAGE [ARG=yes] --without-package do not use PACKAGE (same as --with-package=no) --x-includes=dir X include files are in DIR --x-libraries=dir X library files are in DIR --enable and --with options recognized: --disable-dependency-tracking Speeds up one-time builds --enable-dependency-tracking Do not reject slow dependency extractors --enable-maintainer-mode enable make rules and dependencies not useful (and sometimes confusing) to the casual installer --enable-dlmalloc[=lib] Compile & use the malloc package by Doug Lea --enable-gnuregex Compile GNUregex --enable-xmalloc-statistics (46 of 263)14/02/

47 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 --enable-default-err-language=lang Select default language for Error pages (see errors directory) --enable-err-languages="lang1 lang2.." (47 of 263)14/02/

48 Select languages to be installed. (All will be installed by default) --with-coss-membuf-size COSS membuf size (default 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 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.. (48 of 263)14/02/

49 --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 --enable-stacktraces Do not use unlinkd Enable automatic call backtrace on fatal errors (49 of 263)14/02/

50 --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. (50 of 263)14/02/

51 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 * = * = * = * = * = * =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 Log /usr/local/squid/var/logs/cache. log 4 Socket DNS Socket 5 File /usr/local/squid/var/logs/access. log 6 Pipe unlinkd -> squid 7 File /usr/local/squid/var/logs/store. log 8 File /home/var/spool/squid/swap.state (51 of 263)14/02/

52 9 Pipe squid -> unlinkd 10 Socket * cache_object:// / 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 File descriptor con Linux Il valore dei files descriptors impostato come default per ogni distribuzione Linux è generalmente pari a 1024, gestire questo tipo di impostazione non è affatto semplice. Infatti prima di configurare Squid è necessario verificare il numero di file descriptors attualmente configurati utilizzando il comando ulimit(8), si tratta di un comando che fa parte della shell. Il primo passo da compiere è quello di verificare il numero di file descriptor disponibili sulla nostra piattaforma % ulimit -n 1024 a questo punto dovremmo editare uno dei file di system include del kernel, in particolare si tratta del file /usr/include/bits/tipes. h oppure del file /usr/include/bits/typesizes.h modificando il valore FD_SETSIZE % vi /usr/include/bits/typesizes.h #define FD_SETSIZE 4096 il valore FD_SETSIZE viene controllato durante l'esecuzione dello script di./configure. Squid è particolarmente vorace di file descriptors che sono una risorsa finita ma regolabile del sistema operativo, oltre che molto preziosa, visto che sono i canali di comunicazione che vengono utilizzati dai vari processi per parlare con il mondo esterno e fra di loro. Per verificare quanti file descriptors il sistema metta a disposizione con la configurazione standard si può digitare il seguente comando % cat /proc/sys/fs/file-max è opportuno che questo numero sia piuttosto alto, in linea di massima può andare bene se maggiore di Qualora il numero dovesse essere più basso, si consiglia di editare (come root) il file /etc/sysctl.conf aggiungendo la riga fs.file-max = e poi lanciare (sempre come root) il comando (52 of 263)14/02/

53 % 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 > /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 checking Maximum number of filedescriptors we can open checking Default UDP send buffer size checking Default UDP receive buffer size checking Default TCP send buffer size checking Default TCP receive buffer size Limiting receive buffer size to 64K checking if sys_errlist is already defined... (cached) no checking for libresolv _dns_ttl_ hack... no checking if inet_ntoa() actually works... yes checking for working statvfs() interface... yes checking for _res.nsaddr_list... (cached) yes creating./config.status... ora compiliamo ed installiamo nuovamente Squid (53 of 263)14/02/

54 % 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 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 = 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 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 (54 of 263)14/02/

55 options MAXFILES=8192 possiamo verificare il valore dei file descriptors attivi in un dato momento utilizzando il comando sysctl(8), le variabili del kernel di un sistema FreeBSD possono essere visualizzate ed eventualmente modificate utilizzando il comando sysctl % sysctl -a grep kern.maxfiles kern.maxfiles: 4040 kern.maxfilesperproc: 3636 come per i sistemi linux per visualizzare il numero di files descriptors attivi possiamo anche utilizzare l'opzione di shell ulimit % ulimit -n 4040 non è dunque necessario ricompilare il kernel per impostare il valore corretto dei file descriptors, sarà sufficente editare il file / etc/sysctl.conf kern.maxfiles=4040 kern.maxfilesperproc=3636 per concludere possiamo dire che modificare manualmente il numero di file descriptors in un sistema BSD ha senso solo se si vuole ottimizzare le prestazioni di un server di rete ad alto traffico 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 (55 of 263)14/02/

56 % netstat -m 129/320/65536 mbufs in use (current/peak/max): 129 mbufs allocated to data 128/260/16384 mbuf clusters in use (current/peak/max) 600 Kbytes allocated to network (1% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines questo sistema FreeBSD dispone di 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 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 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 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 (56 of 263)14/02/

57 nell'intervallo 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 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 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 (57 of 263)14/02/

58 % make install L'albero delle directory di Squid supponendo di aver utilizzato come opzione di configurazione %./configure --prefix=/usr/local/squid mostriamo ora al lettore l'albero delle directory di /usr/local/squid che contiene gli eseguibili ed i files di configurazione di Squid che vengono generati utilizzando il comando make && make install % ls /usr/local/squid/ totale 28 drwxr-xr-x 2 root root 4096 apr 10 12:26 bin drwxr-xr-x 2 root root 4096 apr 10 12:16 etc drwxr-xr-x 2 root root 4096 apr 10 12:26 libexec drwxr-xr-x 3 root root 4096 apr 3 12:40 man drwxr-xr-x 2 root root 4096 apr 10 12:26 sbin drwxr-xr-x 4 root root 4096 apr 10 12:16 share drwxr-xr-x 5 root root 4096 apr 3 13:01 var le applicazioni che possono essere utilizzate da tutti gli utenti di sistema si trovano in /usr/local/squid/bin % ls -l /usr/local/squid/bin/ totale 28 -rwxr-xr-x 1 root root set 17:24 RunAccel -rwxr-xr-x 1 root root set 17:24 RunCache -rwxr-xr-x 1 root root 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 set 17:28 squid (58 of 263)14/02/

59 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 set 17:28 cachemgr.cgi -rwxr-xr-x 1 root root set 17:28 digest_pw_auth -rwxr-xr-x 1 root root set 17:28 diskd -rwxr-xr-x 1 root root set 17:28 ip_user_check -rwxr-xr-x 1 root root set 17:28 msnt_auth -rwxr-xr-x 1 root root set 17:28 ncsa_auth -rwxr-xr-x 1 root root set 17:28 ntlm_auth -rwxr-xr-x 1 root root set 17:28 pam_auth -rwxr-xr-x 1 root root set 17:28 squid_unix_group -rwxr-xr-x 1 root root set 17:28 unlinkd -rwxr-xr-x 1 root root set 17:28 wb_auth -rwxr-xr-x 1 root root set 17:28 wb_group -rwxr-xr-x 1 root root set 17:27 wbinfo_group.pl -rwxr-xr-x 1 root root set 17:28 wb_ntlmauth -rwxr-xr-x 1 root root 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 apr 23:03 mime.conf -rw-r--r-- 1 root root set 17:27 mime.conf.default -rw-r--r-- 1 root root apr 10:04 msntauth.conf -rw-r--r-- 1 root root set 17:27 msntauth.conf.default -rw-r--r-- 1 root root apr 01:01 squid.conf -rw-r--r-- 1 root root 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 (59 of 263)14/02/

60 # ls -l /usr/local/squid/share/ totale 36 drwxr-xr-x 30 root root apr 23:03 errors drwxr-xr-x 2 root root set 17:27 icons -rw-r--r-- 1 root root 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 Pulire gli eseguibili dalle informazioni di debug Il comando make install genera degli eseguibili mostruosamente grandi, se invece si desidera installare degli eseguibili puliti, senza alcuna informazione di debug, é possibile utilizzare il comando make install-strip. Ricordiamo agli utenti che questo comando può essere eseguito soltanto dall'interno della directory contenete i sorgenti di Squid % make && make install % cd src/ % make install-strip per rimuovere le informazioni di debug dagli eseguibili potremmo anche utilizzare il comando strip(8). Questo comando elimina le informazioni di debug dagli object files scartando automaticamente gli oggetti non riconosciuti come eseguibili % strip -s /usr/local/squid/bin/* /usr/local/squid/sbin/* /usr/local/squid/libexec/* strip: /usr/local/squid/bin/runaccel: File format not recognized strip: /usr/local/squid/bin/runcache: File format not recognized strip: /usr/local/squid/libexec/wbinfo_group.pl: File format not recognized 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 (60 of 263)14/02/

61 % 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 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: In merito ai pacchetti precompilati per le altre distribuzioni GNU Linux, è necessario fare riferimento alla home page della distribuzione che state utilizzando. (61 of 263)14/02/

62 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: 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: 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 (62 of 263)14/02/

63 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 (63 of 263)14/02/

64 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 -s 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 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 (64 of 263)14/02/

65 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 -R l'opzione -N indica a Squid di non diviene automaticamente un processo di background 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 (65 of 263)14/02/

66 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 :3128 http_port :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. (66 of 263)14/02/

67 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 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 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 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 (67 of 263)14/02/

68 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 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 (68 of 263)14/02/

69 %./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 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 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 (69 of 263)14/02/

70 % 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: * 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 Disabilitare i files di log se si persegue l'obiettivo delle prestazioni è possibile disabilitare totalmente o parzialmente il sistema di logging ricorrendo ad alcuni TAG nel file squid.conf ecco un esempio valido per squid-2.4 cache_access_log /dev/null cache_store_log none cache_log /dev/null se invece utilizzate squid-2.5 cache_access_log none cache_store_log none cache_log /dev/null useragent_log none referer_log none (70 of 263)14/02/

71 è 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 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 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 (71 of 263)14/02/

72 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 la sintassi di questo TAG verrà approfondita nel capitolo dedicato al Disk Storage 8.7. Parametri amministrativi E' possibile impostare l'indirizzo dello Squidmanager (amministratore della cache) nonchè il nome dell'host utilizzeremo il TAG cache_mgr cache_mgr 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 (72 of 263)14/02/

73 append_domain.nomedominio.com è stato incluso nelle versioni più recenti di Squid, questo TAG aggiunge automaticamente il nome di dominio locale 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 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 /24 acl locallan src / http_access allow locallan nel file squid.conf sono contenute delle regole basilari, vengono inoltre indicati i punti nei quali possiamo inserire i nostri controlli di accesso (73 of 263)14/02/

74 # 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 / acl manager proto cache_object acl localhost src / acl to_localhost dst /8 acl SSL_ports port acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port # https, snews acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl locallan src / acl CONNECT method CONNECT http_access allow manager localhost http_access deny manager http_access deny!safe_ports http_access deny CONNECT!SSL_ports http_access allow localhost http_access allow locallan http_access deny all abbiamo così mostrato al lettore una piccola serie di Access Control List (ACL), questa piccola configurazione ci consentirà di avviare Squid concedendo accesso ai nostri utenti 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 (74 of 263)14/02/

75 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@ print; } La configurazione di startup (squid.conf) Come abbiamo detto nel file squid.conf è contenuta la configurazione di Squid, in questo capitolo abbiamo affrontato quelli che possiamo definire come gli aspetti essenziali relativi alla preparazione, alla configurazione e alla installazione minimale di Squid. Abbiamo trattato di alcune impostazioni basilari e, alla luce di quanto sinora scritto, siamo finalmente in grado di mostrare un file di configurazione minimale e di avviare Squid http_port 3128 icp_port 3130 cache_mem 8 MB cache_dir ufs /usr/local/squid/var/cache cache_access_log /usr/local/squid/var/logs/access.log cache_log /usr/local/squid/var/logs/cache.log cache_store_log /usr/local/squid/var/logs/store.log emulate_httpd_log off mime_table /usr/local/squid/etc/mime.conf pid_filename /usr/local/squid/var/run/squid.pid acl all src / acl manager proto cache_object acl localhost src / acl to_localhost dst /8 acl SSL_ports port acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port # https, snews acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker (75 of 263)14/02/

76 acl Safe_ports port 777 # multiling http acl locallan src / acl CONNECT method CONNECT http_access allow manager localhost http_access deny manager http_access deny!safe_ports http_access deny CONNECT!SSL_ports http_access allow localhost http_access allow locallan http_access deny all cache_mgr squid@miodominio.net cache_effective_user nobody cache_effective_group nobody visible_hostname proxy.nomedominio.net append_domain.miodominio.net nei capitoli successivi approfondiremo i temi che abbiamo accennato, le nozioni che abbiamo descritto in questo capitolo ci hanno consentito solo di inquadrare in maniera superficiale le potenzialità offerte da Squid, questa configurazione solo minimale ancora non consente al lettore di utilizzare al meglio Squid. 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 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 (76 of 263)14/02/

77 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 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 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 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 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 (77 of 263)14/02/

78 # 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 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 megabyte (78 of 263)14/02/

79 cache_dir ufs /cache 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 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 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" (79 of 263)14/02/

80 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 le options sono comuni a tutti i tipi di Disk Storage e si suddividono in read-only max-size=n read-only indica che questa cache_dir é di sola lettura mentre max_size identifica la dimensione massima di oggetto che questa cache_dir può immagazzinare. É possibile specificare in squid.conf più di una definizione di cache_dir, anche se la stessa utilizza un differente tipo di Disk Storage, infatti a partire dalla versione 2 di Squid, è possibile aggiungere nuove cache_dir in qualsiasi momento e renderle attive senza ricavarne alcun effetto collaterale 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] (80 of 263)14/02/

81 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 cache_dir ufs /usr/local/squid/var/cache 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 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 in alternativa è possibile forzare il numero di thread al momento della compilazione di Squid ricorrendo all'opzione --with-aiothreads=n di./configure (81 of 263)14/02/

82 %./configure --with-aio-threads=32 utilizzando il cache manager è possibile visualizzare le statistiche relative a aufs % squidclient mgr:squidaio_counts HTTP/ OK Server: squid/2.5.stable5 Mime-Version: 1.0 Date: Tue, 06 Apr :08:27 GMT Content-Type: text/plain Expires: Tue, 06 Apr :08:27 GMT Last-Modified: Tue, 06 Apr :08:27 GMT X-Cache: MISS from portatilo.miodominio.net Proxy-Connection: close ASYNC IO Counters: Operation # Requests open 93 close 93 cancel 93 write 0 read 108 stat 0 unlink 5 check_callback 9312 queue 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 (82 of 263)14/02/

83 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 Q1=72 Q2=64 diskd_program /usr/local/squid/libexec/diskd utilizzando il Cache Manager è possibile visualizzare le prestazioni del diskd % squidclient mgr:diskd HTTP/ OK Server: squid/2.5.stable5 Mime-Version: 1.0 Date: Tue, 06 Apr :56:57 GMT Content-Type: text/plain Expires: Tue, 06 Apr :56:57 GMT Last-Modified: Tue, 06 Apr :56:57 GMT X-Cache: MISS from proxy.miodominio.net Proxy-Connection: close sent_count: recv_count: (83 of 263)14/02/

84 max_away: 26 max_shmuse: 25 open_fail_queue_len: 0 block_queue_len: 0 OPS SUCCESS FAIL open create close unlink read write 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 Q1=72 Q2= 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 (84 of 263)14/02/

85 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 MSGTQL deve essere almeno 75 volte il numero dei TAG cache_dir che abbiamo configurato Coda dei messaggi con BSD Il Kernel deve prevedere le seguenti impostazioni options SYSVMSG altri parametri da impostare prima di ricompilare il Kernel vengono riportati da questo esempio, assicuriamoci di impostare i valori appropriati per il nostro sistema options MSGMNB=16384 # max # of bytes in a queue options MSGMNI=41 # number of message queue identifiers options MSGSEG=2049 # number of message segments per queue options MSGSSZ=64 # size of a message segment options MSGTQL=512 # max messages in system Coda dei messaggi con Linux Per configurare la coda dei messaggi con Linux è necessario editare il file /etc/sysctl.conf (85 of 263)14/02/

86 kernel.msgmnb=8192 kernel.msgmni=40 kernel.msgmax= Coda dei messaggi con Solaris Aggiungere le seguenti linee nel file /etc/system set msgsys:msginfo_msgmax=2048 set msgsys:msginfo_msgmnb=8192 set msgsys:msginfo_msgmni=40 set msgsys:msginfo_msgssz=64 set msgsys:msginfo_msgtql=2048 naturalmente è necessario eseguire un riavvio del Sistema dopo aver modificato il file /etc/system 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 Memoria condivisa con BSD Il Kernel deve prevedere le seguenti impostazioni (86 of 263)14/02/

87 options SYSVSHM altri parametri da impostare prima di ricompilare il Kernel vengono riportati da questo esempio, assicuriamoci di impostare i valori appropriati per il nostro sistema options SHMSEG=16 # max shared mem id's per process options SHMMNI=32 # max shared mem id's per system options SHMMAX= # max shared memory segment size (bytes) options SHMALL=4096 # max amount of shared memory (pages) Memoria condivisa con Linux Per configurare la memoria condivisa con Linux è necessario editare il file /etc/sysctl.conf kernel.shmall= kernel.shmmni=32 kernel.shmmax= Memoria condivisa con Solaris Aggiungere le seguenti linee nel file /etc/system set shmsys:shminfo_shmmax= set shmsys:shminfo_shmmni=32 set shmsys:shminfo_shmseg=16 naturalmente è necessario eseguire un riavvio del Sistema dopo aver modificato il file /etc/system 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 é (87 of 263)14/02/

88 cache_dir null Directory-Name [options] Dove Directory-Name identifica una top-level directory fittizia, ecco un esempio cache_dir null /tmp 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, blocksize é 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/cossfile max-size=65536 blocksize=2048 cache_dir coss /usr/local/squid/var/cache/cossfile max-side= blocksize=2048 coss per il momento è in grado di supportare il solo algoritmo LRU a riguardo del Memory e Cache Replacement Policy 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 (88 of 263)14/02/

89 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 molte transazioni/sec sistema operativo Windows - diskd - cache multiple molte transazioni/sec 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 wessels_duane.ppt 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. (89 of 263)14/02/

90 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 options SYSVSHM options SHMSEG=16 options SHMMNI=32 options SHMMAX= options SHMALL=4096 # SYSV-style shared memory # Squid Shared Memory DiskD Tuning # max shared mem id's per process # max shared mem id's per system # max shared memory segment size (bytes) # max amount of shared memory (pages) definiamo il numero massimo di file descriptors ed il numero massimo di cluster mbuf per le connessioni di rete options MAXFILES=8192 options NMBCLUSTERS=32768 utilizzando l'implementazione reale della system calls aio_* possiamo ottenere una maggiore stabilità e sicurezza del sistema da possibili attacchi che possono essere portati da utenti locali options VFS_AIO nel file di configurazione del Kernel, relativamente alla configurazione della Message Queues (SYSVMSG), devono essere contenute le seguenti linee (Cfr. Squid FAQ alla URLs (90 of 263)14/02/

91 options SYSVMSG options MSGMNB=16384 options MSGMNI=41 options MSGSEG=2049 options MSGSSZ=64 options MSGTQL=512 # SYSV-style message queues # Squid Message Queues DiskD Tuning # max of bytes in a queue # number of message queue identifiers # number of message segments per queue # size of a message segment # 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 Configurare ufs (multipiattaforma) A riguardo la configurazione è piuttosto semplice in quanto si limita alla sola modifica del file squid.conf cache_dir ufs /usr/local/squid/var/cache si tratta dello schema di storage di default di Squid e può essere utilizzato per qualsiasi tipo di configurazione (91 of 263)14/02/

92 Configurare aufs con Linux A riguardo la configurazione è piuttosto semplice in quanto si limita alla sola modifica del file squid.conf cache_dir aufs /usr/local/squid/var/cache trattandosi dello stesso schema di storage di ufs sarà sufficente rileggere la configurazione di Squid (squid -k reconfigure) Configurare awin32 con Windows A riguardo la configurazione è piuttosto semplice in quanto si limita alla sola modifica del file squid.conf cache_dir awin32 c:/squid/var/cache 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 Parametri di configurazione La configurazione del Memory Storage é controllabile tramite alcuni parametri di configurazione inclusi nel file squid.conf (92 of 263)14/02/

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

94 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: e techreports/98/hpl 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" (94 of 263)14/02/

95 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 Parametri di configurazione La configurazione delle Replacement policy in Squid avviene tramite i seguenti parametri cache_replacement_policy policy memory_replacement_policy policy cache_swap_low low-water-mark cache_swap_high high-water-mark il TAG cache_replacement_policy specifica la replacement policy da utilizzare per determinare quali oggetti devono essere eliminati e/o sostituiti quando è necessario del nuovo spazio nel Disk Storage. Il valore predefinito é lru, i valori possibili sono lru heap GDSF heap LFUDA heap LRU ad esempio cache_replacement_policy heap LFUDA il TAG memory_replacement_policy specifica la replacement policy da utilizzare per determinare quali oggetti devono essere eliminati e/o sostituiti quando è necessario del nuovo spazio nel Memory Storage. Il valore predefinito é lru, i valori possibili sono (95 of 263)14/02/

96 lru heap GDSF heap LFUDA heap LRU ad esempio memory_replacement_policy heap GDSF il TAG cache_swap_low specifica il valore ottimale di percentuale di utilizzo del Disk Storage desiderato, quando tale soglia viene superata, le Policy di Replacement vengono attivate. Il valore predefinito é 90%, ad esempio cache_swap_low 85 il TAG cache_swap_high specifica il valore massimo di percentuale di utilizzo del Disk Storage desiderato, quando tale soglia viene avvicinata, le Policy di Replacement vengono applicate in modo maggiormente aggressivo. Il valore predefinito é 95%, ad esempio cache_swap_high 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 (96 of 263)14/02/

97 contemporanei dovrebbero rappresentare 400 MByte di cache_dir storage cache_dir ufs /usr/local/squid/cache 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 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) (97 of 263)14/02/

98 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 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à 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 (98 of 263)14/02/

99 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 (99 of 263)14/02/

100 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 Capire il funzionamento delle ACL (100 of 263)14/02/

101 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 /32 acl pippo dstdomain acl topolino method GET l'elemento ACL dal nome paperino confronta una richiesta che proviene dall'indirizzo IP , l'elemento ACL dal nome pippo contronta con la URL 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 / / /32 acl legolas dstdomain acl aragorn method PUT POST l'espressione multipla esegue una comparazione con una richiesta per ogni valore inserito nell'espressione stessa. La ACL gandalf esegue una comparazione tra una richiesta proveniente dagli indirizzi IP , e 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 (101 of 263)14/02/

102 questo contesto è bene sottolineare che il nome della ACL diviene una parola chiave acl paperino src /32 acl pippo dstdomain acl topolino method GET http_access allow paperino http_access deny pippo http_access allow topolino le regole della ACL vengono rigorosamente applicate nell'ordine nel quale sono state scritte, la decisione viene presa sempre quando la relativa ACL viene confrontata, ritornando sull'esempio precedente analizzeremo alcune situazioni che possono venire a delinearsi. Cosa accade quando un utente proveniente dall'indirizzo IP esegue il confronto con la ACL che specifica l'indirizzo di destinazione 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 ( ), in questo caso le regole successive non verranno verificate. Cosa accade invece se arriva una richiesta per il sito proveniente dall'indirizzo IP ? 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 proveniente dall'indirizzo IP ? La richiesta non confronta la prima ACL paperino, non si abbina nemmeno con la seconda ACL pippo perchè www. linux.com è differente da 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 /32 acl pippo dstdomain acl topolino method GET http_access allow paperino pippo http_access deny topolino tutte le richieste provenienti dall'indirizzo IP che contengono come URL di destinazione 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 (102 of 263)14/02/

103 acl all src 0/0 acl servers / / /32 icp_access allow servers icp_access deny all qui vediamo una relazione di parentela tra cache adiacenti che ricorrono al protocollo ICP, dove tutte le richieste provenienti dagli indirizzi IP , e verranno soddisfatte, mentre quelle provenienti da altri indizzi verranno negate. Ecco di seguito un esempio che contiene una regola più complessa acl gandalf src / / /32 acl legolas dstdomain acl aragorn method PUT POST http_access deny gandalf legolas aragorn http_access allow gandalf legolas http_access deny aragorn queste tre linee autorizzando i client della ACL gandalf ( , e ) ad accedere ai server specificati nella ACL legolas ( and 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 acl all src 0/0 http_access deny vietato http_access allow all in questo esempio a tutti gli utenti non è consentito accedere al sito 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 /32 e la nuova regola dovrà dunque essere (103 of 263)14/02/

104 http_access allow user_ok vietato nel contesto generale delle regole che stiamo applicando, la nuova ACL dovrà essere inserita seguendo questo schema http_access allow user_ok vietato http_access deny vietato http_access allow all entriamo nello specifico visualizzando alcune delle impostazioni standard di Squid acl all src / acl manager proto cache_object acl localhost src / acl locallans src / acl to_localhost dst /8 acl SSL_ports port acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port # https, snews acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT http_access allow manager localhost http_access deny manager http_access deny!safe_ports http_access deny CONNECT!SSL_ports http_access allow locallan http_access deny all con il TAG acl src vengono definite diverse liste di accesso basate sull'indirizzo IP, incluse quelle per gli host autorizzati dall'amministratore del sistema ad accedere al proxy server. Il TAG http_access allow consente a tutta la subnet incluso l'host locale ( ) 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 (104 of 263)14/02/

105 acl Safe_ports port 80 acl Safe_ports port 21 http_access deny!safe_ports # http # ftp 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 / acl locallans src / icp_access allow locallans icp_access deny all con il TAG icp_access vengono processate le ACL che autorizzano o negano accesso per le richieste ICP che vengono effettuate da altri proxy server. Così abbiamo visto che è possibile impostare diversi tipi di ACL, i nomi delle ACL di tipo src non devono assolutamente contenere il simbolo "-", questo carattere infatti potrebbe essere interpretatato da Squid come una indicazione di intervallo (range). Ecco un esempio di una serie di ACL del tipo src impostata correttamente acl locallan101 src / acl locallan102 src / acl locallan103 src / acl locallan104 src / acl locallan105 src / acl locallan106 src / acl locallan107 src / acl locallan108 src / acl locallan109 src / acl locallan110 src / di seguito riportiamo una ACL del tipo src impostata in maniera errata (105 of 263)14/02/

106 acl locallan-1-01 src / 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 Utilizzare le ACL per autenticare degli utenti Un'altra interessante opzione offerta da Squid è rappresentata dalla possibilità di limitare l'accesso al proxy tramite eventuale autorizzazione, autenticazione ed accounting. In una rete geografica di grandi dimensioni l'utilizzo di Squid può rilevarsi utile per il controllo degli accessi. Non dimentichiamo che un proxy è un gateway a livello applicativo (Layer 7 della pila OSI) e può essere utilizzato anche come firewall tra due reti, va sottolineato, per i puristi del TCP/IP, che il termine firewall in questo caso non è corretto in quanto Squid non esegue alcun filtraggio di pacchetti. Squid può essere utilizzato come applicazione per il controllo e la verifica, grazie alle sue funzionalità si rivelerà molto utile nell'implementazione di una politica di sicurezza. Per attivare il controllo di accesso a livello utente é necessario attivare almeno uno schema di autenticazione ed aggiungere nelle ACL i seguenti TAG acl password proxy_auth REQUIRED http_access allow password quando viene impostata un qualsiasi tipo di ACL del tipo proxy_auth tramite le regole http_access, tutte le ACL successive alla regola proxy_auth non verranno più considerate da Squid in quanto o l'accesso sarà stato consentito oppure verrà generato un errore di acceso negato alla cache. Se si deve configurare un proxy in maniera granulare è quindi necessario portare molta attenzione nell'applicazione delle regole http_access. In buona sostanza, una volta che ci si è autenticati su un sistema Squid è tutto permesso tranne quello che è stato esplicitamente negato nelle regole http_access precedenti alla regola http_access proxy_auth http_access allow localhost http_access deny manager http_access deny!safe_ports http_access deny CONNECT!SSL_ports http_access deny locallan102 http_access deny porn http_access deny badlang http_access deny entertain http_access deny games http_access deny mp3 http_access deny pirate http_access deny pron (106 of 263)14/02/

107 http_access deny ftpblock http_access allow sitiok http_access allow password come abbiamo visto sopra, è possibile l'accesso all'host locale, successivamente procediamo con la definizione di una serie di blocchi che riguardano le reti non autorizzate, i vari siti non consoni all'utilizzo del proxy, autorizziamo i siti censiti come visitabili e successivamente procediamo con la richiesta di autenticazione del tipo basic. L'utente, dopo aver proceduto ad autenticarsi, sarà autorizzato a fare tutto quello che non gli sia già stato esplicitamente negato 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 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 ( 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: (107 of 263)14/02/

108 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 REQUIRED acl internetfull external wb_group -i "/usr/squid/etc/internetfull" acl internetnormal external wb_group -i "/usr/squid/etc/internetnormal" acl internettodow external wb_group -i "/usr/squid/etc/internettodow" acl internettonav external wb_group -i "/usr/squid/etc/internettonav" acl time_acl time M T W H F 8:30-19:00 acl nointernet src "/usr/squid/etc/nointernet" acl goodurl url_regex -i "/usr/squid/etc/goodurl" acl badurl url_regex -i "/usr/squid/etc/badurl" acl badmime url_regex -i "/usr/squid/etc/badmime" http_access allow password internetfull http_access allow password internetnormal time_acl!badurl!badmime http_access allow password internettonav time_acl!badmime http_access allow password internettodow time_acl!badurl (108 of 263)14/02/

109 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 , 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 /wb_group[14984](wb_check_group.c:154): Windows group: Gruppo1, Squid group: Gruppo /wb_group[14984](wb_check_group.c:188): SID: S /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 /wb_group[14984](wb_check_group.c:154): Windows group: Gruppo, Squid group: Gruppo OK 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 (109 of 263)14/02/

110 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 win32_check_group L'helper win32_check_group, cosí come wb_group, consente il controllo delle autorizzazioni di accesso in base all'appartenzenza a gruppi di dominio Windows NT/2000, ma riguarda esclusivamente la piattaforma Win32. Non necessita di alcuna componente esterna in quanto si appoggia sulle API native del sistema operativo. win32_check_group può operare su gruppi globali di dominio o gruppi locali di macchina. Il suo utilizzo e le procedure di verifica di funzionamento sono strettamete equivalenti a quelle di wb_group: external_acl_type NT_global_group %LOGIN c:/squid/libexec/win32_check_group.exe -G external_acl_type NT_local_group %LOGIN c:/squid/libexec/win32_check_group.exe acl GProxyUsers external NT_global_group GProxyUsers acl LProxyUsers external NT_local_group LProxyUsers acl password proxy_auth REQUIRED http_access allow password GProxyUsers http_access allow password LProxyUsers http_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. (110 of 263)14/02/

111 squid_ldap_group Questo helper permette la verifica di appartenza di un utente ad un gruppo di una directory LDAP. Il programma opera eseguendo delle ricerche tramite un search filter basato sul username dell'utente ed il gruppo richiesto, se viene trovato un match, l'utente appartiene al gruppo cercato. Nel seguito di questo paragrafo verranno trattati alcuni argomenti la cui comprensione é strettamente dipendente da una buona conoscenza del protocollo LDAP, per maggiori dettagli al riguardo, riferirsi al sito del Progetto OpenLDAP. Questo autenticatore consente l'interfacciamento con tutti i maggiori Directory Service attualmente disponibili Microsoft Active Directory Novell NDS Lotus Notes Directory Sun Java System Directory esempio di configurazione external_acl_type ldap_group %LOGIN /usr/local/squid/libexec/squid_ldap_group... acl gruppo1 external ldap_group Gruppo1 acl gruppo2 external ldap_group Gruppo2 acl password proxy_auth REQUIRED http_access allow password Gruppo1 http_access allow password Gruppo2 http_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 (111 of 263)14/02/

112 squid_unix_group Questo helper permette la verifica di appartenza di un utente ad un gruppo standard UNIX /Linux. Il programma opera eseguendo delle ricerche nel file /etc/group basate sullo username dell'utente ed il gruppo richiesto, un esempio di configurazione external_acl_type Linux_group %LOGIN /usr/local/squid/libexec/squid_unix_group acl gruppo1 external Linux_group Gruppo1 acl gruppo2 external Linux_group Gruppo2 acl password proxy_auth REQUIRED http_access allow password Gruppo1 http_access allow password Gruppo2 http_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 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: (112 of 263)14/02/

113 external_acl_type IP_Check %SRC %LOGIN /usr/local/squid/libexec/ip_user_check -f / usr/local/squid/etc/ip_user_check.conf acl resticted external IP_Check acl password proxy_auth REQUIRED http_access allow password restricted http_access deny all 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 Range IP vietato (nessun utente può usare la cache) ip[/mask] NONE Range IP libero (qualunque utente può usare la cache) ip[/mask] ALL (113 of 263)14/02/

114 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 /24 sono autorizzati / ALL # # Gli utenti della rete /24 non sono autorizzati # tranne l'utente `boss che può autenticarsi ovunque / boss / NONE # # L'utente `gianni può autenticarsi solo dall'indirizzo IP delle propria stazione jayk # # Gli utenti appartenenti al gruppo `cad possono autenticarsi solo dalla propria VLAN 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 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 (114 of 263)14/02/

115 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: Di seguito esaminiamo anche il formato dei files che possono contenere la lista delle parole chiave che consentono di individuare i siti web.sex.de.playboy.com.br.clubhardcore.com www-cache.fh-bingen.de.monkeylove.com.amateur-pages.com.hitboss.com.peep.com.erotism.com.sinfulmail.com.nookie.com.snapshots.com.onlyteens.com heavyhangers.dailydirt.com hustler.brunclik.cz.desibaba.com.picturepost.com.haloo.fi.smut.com altre liste di siti precompilate possono anche essere reperite Squid and web utilities alla URL di Pedro Lineu Orso Squid Blocking Files alla URL di Jasons Staudenmayer 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 (115 of 263)14/02/

116 "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 / acl allowed_hosts1 src / acl allowed_hosts2 src / acl porn url_regex "/etc/squid/block/porn.block.txt" acl consentiti url_regex "/etc/squid/block/consentiti.txt" acl nonconsentiti url_regex "/etc/squid/block/nonconsentiti.txt" acl snmpmanager src / acl snmppublic snmp_community public abbiamo definito delle ACL che in prima istanza frazionano la rete in due subnet distinte e poi definiscono delle liste in formato regexp, il file regexp è un file di testo nel quale vengono dichiarate un'insieme di espressioni regolari. Di seguito vengono applicate le ACL per definire questa specifica configurazione di Squid http_access allow localhost http_access allow allowed_hosts http_access allow consentiti http_access deny nonconsentiti http_access allow allowed_hosts1 http_access deny manager all http_access deny all http_access deny!safe_ports http_access deny CONNECT!SSL_ports si evince che alla subnet dichiarata dalla ACL "allowed_hosts" ( / ) è consentito l'accesso a tutti i siti web, mentre la subnet dichiarata dalla ACL "allowed_hosts1" ( / ) è 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 go.to/streghe disney merlinobbs.net (116 of 263)14/02/

117 powerrangers ancora di seguito la lista /etc/squid/block/nonconsentiti.txt % more nonconsentiti.txt. la lista di regexp "nonconsentiti.txt" con l'esperessione "." blocca tutto il resto Raggiungere direttamente domini o siti predefiniti E' possibile utilizzare le ACL per consentire agli utenti di raggiungere direttamente alcuni siti internet. Ad esempio, se vogliamo che Squid consenta la connessione diretta con servers appartenenti al dominio cisco.com possiamo definire il seguente TAG all'interno del file squid.conf acl cisco dstdomain.cisco.com always_direct allow cisco Bloccare gli spyware Controllando lo user-agent log potremmo incorrere in questo tipo di codice Gator/5.0 Script FD6B41F906B248C3B B3F375B Gator/5.0 Precision Time \ se vogliamo evitare che le macchine infettate degli utenti interroghino la nostra rete passando per squid potremmo aggiongere il seguente TAG acl gator browser Gator/5.0 Http_access deny gator Bloccare web radio e TV Controllando lo user-agent log potremmo incorrere in questo tipo di codice (117 of 263)14/02/

118 Windows-Media-Player/ 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 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 ^application/x-msn-messenger acl repmsn rep_mime_type -i ^application/x-msn-messenger Il messanger msn viene identificato quindi dal tag application/x-msn-messenger, a questo punto dobbiamo solo applicare le regole appena definite http_access deny reqmsn http_reply_access deny repmsn No cache E' possibile utilizzare Squid senza memorizzare le pagine visitate nella cache, il TAG no_cache infatti consentirà di eliminare il caching degli oggetti acl all src 0/0 no_cache deny all 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 (118 of 263)14/02/

119 funziona con tutti i sistemi operativi supportati da Squid. Attualmente le ``ARP ACLs'' sono pienamente supportate sui seguenti sistemi operativi: Linux Solaris FreeBSD 4.11-STABLE con molta probabilità sono supportare anche da FreeBSD 5.3-STABLE nonchè le altre varianti dei sistemi BSD E' opportuno dire che Squid è in grado di determinare il MAC address dei client che si trovano all'interno della stessa subnet, ne consegue che se il client si trova su una subnet differente, Squid non sarà in grado di identificare l'indirizzo di MAC address. Per utilizzare i controlli ARP (MAC) access è necessario compilare il codice opzionalmente fornito con i sorgenti, per procedere con questa operazione è necessario compilare Squid con la direttiva --enable-arp-acl come opzione di configurazione %./configure --enable-arp-acl... se src/acl.c non compila o va in errore è ipotizzabile supporre che le ARP ACLs non sono supportate dal sistema operativo che state utilizzando, se contrariamente tutto compila correttamente è possibile inserire le linee relative alle ARP ACL direttamente nel file di configurazione di Squid squid.conf acl M1 arp 01:02:03:04:05:06 acl M2 arp 11:12:13:14:15:16 http_access allow M1 http_access allow M2 http_access deny all Capitolo 11. Autenticazione degli utenti 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 Schemi di autenticazione In precedenza abbiamo già fornito alcune nozioni di base per quello che concerne gli schemi di autenticazione. Per "schema di (119 of 263)14/02/

120 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 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 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), (120 of 263)14/02/

121 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 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 Q ( 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" 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 ( 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 ( 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 (121 of 263)14/02/

122 è legato ad uno schema di autenticazione attivo. Per utilizzare l'autenticazione è necessario definire un TAG con una acl nella quale venga specificata almeno la seguente direttiva acl password proxy_auth REQUIRED tale direttiva definisce l'elemento ACL password che potrà essere utilizzato in tutte le acl standard di Squid. La scelta degli helper da attivare viene effettuata al momento della configurazione dei parametri di compilazione di Squid %./configure --enable-schema-auth-helpers="elenco helper" dove schema può assumere i valori ntlm, basic e digest, il nome dell'helper da specificare è il nome (case sensitive) dalla cartella nel source tree di Squid che ne contiene i sorgenti %./configure --enable-auth="ntlm basic" \ --enable-ntlm-auth-helpers="fakeauth winbind SMB" \ --enable-basic-auth-helpers="ncsa winbind MSNT" nell'esempio precedente abbiamo selezionato gli schemi di autenticazione Basic e NTLM, contemporaneamente abbiamo anche definito gli helper NCSA, winbind e MSNT relativamente allo schema Basic. Abbiamo anche definito gli helpers Fakeauth, winbind ed SMB relativamente allo schema NTLM. Nota: In Squid 2.4, dove non esistono altri schemi di autenticazione oltre al Basic, la scelta degli helper da attivare può essere effettuata utilizzando la seguente opzione del comando./configure %./configure --enable-auth-modules="elenco helpers" Il funzionamento globale del motore di autenticazione di Squid é controllato dalle seguenti direttive authenticate_cache_garbage_interval timespan authenticate_ttl timetolive authenticate_ip_ttl timetolive il TAG authenticate_cache_garbage_interval timespan Definisce l'intervallo con cui vengono effettuati i cicli di garbage collection sul contenuto della username cache. Il valore predefinito é 1 ora, e rappresenta un compromesso tra l'utilizzo di memoria (intervalli lunghi, per esempio 2 giorni) e di CPU (intervalli brevi, per esempio 1 minuto). Si raccomanda di non variare questa impostaziona senza una valida motivazione (122 of 263)14/02/

123 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 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 Configurazione in Squid 2.5 Lo schema di autenticazione basic utilizza i seguenti parametri auth_param basic program cmdline auth_param basic children numberofchildren auth_param basic realm realmstring auth_param basic credentialsttl timetolive il TAG program cmdline (123 of 263)14/02/

124 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 Configurazione in Squid 2.4 Squid 2.4 supporta esclusivamente lo schema di autenticazione Basic ed utilizza i seguenti parametri (124 of 263)14/02/

125 authenticate_program cmdline authenticate_children numberofchildren Il significato e la sintassi di queste direttive é analogo a quelle di Squid 2.5 che abbiamo trattato in precedenza il TAG authenticate_program cmdline Specifica il comando che avvia il programma utenticatore esterno. Questo programma legge una riga da stdin contenente "username:password" e risponde con "OK" o "ERR" in un loop senza fine. Come default, lo schema di autenticazione basic non viene attivato a meno che non sia specificato un programma che esegue l'autenticazione. Questo TAG equivale alla direttiva di Squid 2.5 auth_param basic program cmdline, ad esempio authenticate_program /usr/local/squid/libexec/ncsa_auth /usr/local/squid/etc/passwd il TAG authenticate_children numberofchildren 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 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 (125 of 263)14/02/

126 auth_param basic program /usr/local/squid/libexec/ncsa_auth \ /usr/local/squid/etc/passwd auth_param basic children 10 auth_param basic realm Squid proxy-caching web server auth_param basic credentialsttl 30 minutes 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 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 helper PAM Questo authentication helper consente a Squid l'utilizzo pratico di qualsiasi modulo PAM (Pluggable Authentication Module) per validare un utente. I moduli PAM piú utilizzati sono Unix, Radius, Kerberos e SMB. Sono comunque disponibili molti altri moduli meno noti presso varie fonti, ecco un esempio di configurazione auth_param basic program /usr/local/squid/libexec/pam_auth auth_param basic children 5 auth_param basic realm Squid proxy-caching web server auth_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 (126 of 263)14/02/

127 -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" Red Hat Linux Creare il file /etc/pam.d/squid utilizzando il comando % touch /etc/pam.d/squid Il file deve contenere le seguenti entry: Auth required /lib/security/pam_stack.so service=system-auth Auth required /lib/security/pam_nologin.so account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth Unix Standard Per utilizzare /etc/passwd standard modificare il file /etc/pam.conf squid auth required /lib/security/pam_unix.so.1 squid account required /lib/security/pam_unix.so.1 si noti che alcuni moduli PAM, per esempio l'autenticazione tramite shadow password, necessitano che il programma sia installato con privilegio di root suid per poter avere accesso al database delle password utente helper LDAP (127 of 263)14/02/

128 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 ( 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 5 auth_param basic realm Squid proxy-caching web server auth_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 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 ( con un singolo (128 of 263)14/02/

129 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 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 ( 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 (129 of 263)14/02/

130 auth_param basic program /usr/local/squid/libexec/wb_auth auth_param basic children 5 auth_param basic realm Squid proxy-caching web server auth_param basic credentialsttl 30 minutes 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 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 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/msntauth auth_param basic children 8 auth_param basic realm Squid proxy-caching web server auth_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: (130 of 263)14/02/

131 # # 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 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 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 (131 of 263)14/02/

132 auth_param ntlm program cmdline auth_param ntlm children numberofchildren auth_param ntlm max_challenge_reuses number auth_param ntlm max_challenge_lifetime timespan auth_param ntlm use_ntlm_negotiate on off il TAG program cmdline 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 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 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 (132 of 263)14/02/

133 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 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 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 helper SMB (ntlm_auth) Questo helper permette di autenticare gli utenti tramite il protocollo NTLMv1 nell'ambito di uno o più Domain Controller per uno o più domini Windows NT o in Active Directory, la configurazione è quanto mai semplice auth_param ntlm program /usr/local/squid/libexec/ntlm_auth DOMINIO/SERVER DOMINIO/ SERVER auth_param ntlm 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 (133 of 263)14/02/

134 Dominio, i Domain Controller possono anche appartenere a domini differenti ed è quindi possibile utilizzare Squid per eseguire l'autenticazione in modalità trasparente per più di un dominio Windows NT/2000/2003. Vediamo ora un esempio di autenticazione trasparente su più domini auth_param ntlm program /usr/local/squid/libexec/ntlm_auth SEDE_01/SERVER1 SEDE_02/ SERVER2 in questo caso Squid autenticherà in maniera trasparente gli utenti del Dominio SEDE_01 e gli utenti del Dominio SEDE_02, i due Domain Controller sono installati rispettivamente sulle macchine SERVER1 e SERVER2, per queste macchine avremo inserito una voce che consenta di identificare il loro indirizzo internet nel file /etc/hosts % more /etc/hosts localhost.localdomain localhost athlon.sede_00.net server dc.sede_01.net server 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 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 (134 of 263)14/02/

135 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 minutes auth_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) helper Windows win32_ntlm_auth L'helper win32_ntlm_auth riguarda esclusivamente Squid per la piattaforma Win32 e consente la validazione trasparente degli utenti su di un dominio Windows NT 4 o Windows 2000 Active Directory. Inoltre é supportato in modo totalmente automatico l'utilizzo dei pacchetti NTLM NEGOTIATE (NTLMv2). Non necessita di alcuna componente esterna in quanto si appoggia sulle API native del sistema operativo auth_param ntlm program c:/squid/libexec/win32_ntlm_auth.exe auth_param ntlm children 5 auth_param ntlm max_challenge_reuses 0 auth_param ntlm max_challenge_lifetime 2 minutes auth_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à Autenticazione NTLM con Samba 2.2.x (135 of 263)14/02/

136 Vedremo di seguito come utilizzare il servizio Winbindd di Samba versione 2.2.x come supporto per l'autenticazione NTLM di Squid Compilazione helpers Per utilizzare gli helpers basati su Winbindd è necessario avere installato e correttamente configurato Samba 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 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 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 e Samba 2.2.5, per le versioni di Samba a partire dalla 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 Configurazione di Samba2 Come detto precedentemente, per utilizzare l'autenticazione Winbindd è necessario installare Samba, versione 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) (136 of 263)14/02/

137 ;******************* section global ***************** [global] password server = * wins server = security = domain encrypt passwords = Yes workgroup = DOMINIO ;******************* winbindd *********************** winbind separator = \ template homedir = /home/%d/%u template shell = /bin/bash winbind uid = winbind gid = 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 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 ( 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 Se Samba viene utilizzato sulla macchina solamente per il supporto winbindd, a partire dalla versione 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 (137 of 263)14/02/

138 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 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 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 minutes auth_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 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 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 (138 of 263)14/02/

139 helper esterno Samba 3.x ntlm_auth Questo autenticatore é in grado di operare in modalitá basic e ntlm. Inoltre a partire da Samba é supportato in modo totalmente automatico l'utilizzo dei pacchetti NTLM NEGOTIATE (NTLMv2). Assumendo che Samba sia installato in /usr/ local/samba, i parametri da utilizzare in squid.conf diventano auth_param ntlm program /usr/local/samba/bin/ntlm_auth --helper-protocol=squid-2.5- ntlmssp auth_param ntlm children 5 auth_param ntlm max_challenge_reuses 0 auth_param ntlm max_challenge_lifetime 15 minutes auth_param ntlm use_ntlm_negotiate on auth_param basic program /usr/local/samba/bin/ntlm_auth --helper-protocol=squid-2.5- basic auth_param basic children 5 auth_param basic realm Squid proxy-caching web server auth_param basic credentialsttl 2 hours la precedente configurazione consente di sostituire gli autenticatori wb_auth e wb_ntlmauth abilitando il supporto per i pacchetti NTLM NEGOTIATE. Come accadeva già per Samba 2, anche Samba 3 deve essere compilato con questa opzione di./configure %./configure --with-winbind 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 ( 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 (139 of 263)14/02/

140 Dominio Active Directory (Samba 3 deve essere compilato con support Kerberos) Inserire nel file smb.conf le seguenti direttive: realm = your.kerberos.realm security = ADS encrypt passwords = yes nel caso in cui Samba non riesca ad identificare il server ADS tramite il REALM password server = your.kerberos.server inserire la macchina Samba 3 in dominio con il comando net(8) % net ads join -U Administrator%password l'opzione ads viene utilizzata per identificare le ActiveDirectory, l'opzione rap viene invece utilizzata per le macchine NT3 oppure Windows9x, per finire l'opzione rpc può essere utilizzata per le macchine NT4 o Windows 2000, se l'argomento viene omesso il comando net(8) tenterà di determinare automaticamente il tipo di sistema. Si raccomanda di riferirsi alla documentazione della versione di Samba 3 utilizzata per verificare la corretta procedura da seguire in funzione dell'implementazione Kerberos utilizzata sul sistema. Infine, per consentire agli helper Samba 3 di lavorare correttamente con Squid è necessario fare in modo che il gruppo specificato nella direttiva cache_effective_group di squid.conf abbia i permessi di lettura sulla directory winbindd_privileged in cui si trova la pipe di winbindd, quindi nel caso in cui il gruppo utilizzato da squid sia ad esempio nogroup: % chgrp nogroup /dove/sta/samba/winbindd_privileged % chmod 750 /dove/sta/samba/winbindd_privileged Il risultato di un ls -la /dove/sta/samba/winbindd_pipe/pipe dovrebbe essere: srwxrwxrwx 1 root root 0 Aug 14 22:50 pipe anche con Samba 3, se viene utilizzato sulla macchina solamente il supporto winbindd é possibile non eseguire il demone smbd. Anche in questo caso é però INDISPENSABILE eseguire un rinnovo periodico della relazione di trust tra la macchina Samba ed il dominio Windows. Per fare ciò, nel caso in cui non si esegua smbd, é sufficiente schedulare il seguente comando una volta al giorno (140 of 263)14/02/

141 % 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/ 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 Java runtime Navigando su siti che utilizzano applet Java, il JRE richiede di continuo l'autenticazione all'utente. Ciò accade perché il browser non é in grado di condividere l'autenticazione della connessione con la Java Virtual Machine soluzione: consentire nelle ACL il traffico Java non autenticato acl java_jvm browser Java/1.4 http_access allow java_jvm 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 (141 of 263)14/02/

142 acl internal_icons urlpath_regex -i /squid-internal-static/icons/ http_access allow internal_icons Windows Update V5 (Windows XP-SP2) Che cosa simpatica: il Windows Update V5 che è stato incluso con il SP2 di Windows XP sembra bloccarsi sempre con il sistema di autenticazione NTLM sia nativa che quella con Samba. Ancora non siamo in grado di spiegare le cause di questo fastidioso problema soluzione: consentire nelle ACL l'accesso non autenticato alle URLs di Windows Update acl wu dstdomain.windowsupdate.com.microsoft.com.windows.com.public-trust.com http_access allow wu se vogliamo proprio essere pignoli possiamo analizzare il file di log dello user-agent per verificare i seguenti client utilizzati da Windows Update V [19/Sep/2004:21:12: ] "Windows Update Control" [19/Sep/2004:21:12: ] "Microsoft WU Client/2.0" [19/Sep/2004:21:15: ] "Microsoft BITS/6.6" soluzione affinata: consentire nelle ACL l'accesso non autenticato per determinati user-agent la cui destinazione non può essere diversa da quella che viene definita dalla ACL wu acl wuagent browser "Windows Update Control" acl wuagent browser "Microsoft WU Client/2.0" acl wuagent browser "Microsoft BITS/6.6" acl wuagent browser "Industry Update Control" acl wu dstdomain.microsoft.com.windowsupdate.com.windows.com.public-trust.com http_access allow wuagent wu l'ultimo TAG deve essere posizionato prima della direttiva http_access relativa alla autenticazione Windows 2003 É impossibile navigare utilizzando una macchina Windows 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 (142 of 263)14/02/

143 soluzione: utilizzare squid 2.5.STABLE5 con ntlm_auth di Samba 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" 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 abilitando il supporto NTLM NEGOTIATE Digest Authentication l'autenticazione Digest funziona esclusivamente con la versione 2.5 di Squid Configurazione Lo schema di autenticazione Digest utilizza i seguenti parametri auth_param digest program cmdline auth_param digest children numberofchildren auth_param digest realm realmstring auth_param digest nonce_garbage_interval timeinterval auth_param digest nonce_max_duration timeinterval auth_param digest nonce_max_count number auth_param digest nonce_strictness on off auth_param digest post_workaround on off il TAG program cmdline 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 (143 of 263)14/02/

144 RFC 2616 ( 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 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, 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 (144 of 263)14/02/

145 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 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 (145 of 263)14/02/

146 auth_param digest program /usr/local/squid/libexec/digest_pw_auth /usr/local/squid/ etc/digpass auth_param digest children 10 auth_param digest realm Squid proxy-caching web server auth_param digest nonce_garbage_interval 5 minutes auth_param digest nonce_max_duration 30 minutes auth_param digest nonce_max_count 25 auth_param digest check_nonce_count on In questo caso digest_pw_auth si trova in /usr/local/squid/libexec, il file contenente le password é /usr/local/squid/etc/digpass, il numero di helper in esecuzione é 10, il garbage dei nonce avviene ogni 5 minuti, la loro durata é di 30 minuti con 25 riutilizzi massimi ed il TTL dell'autenticazione é pari a 30 minuti. L'helper digest_pw_auth é utilizzabile su tutte le piattaforme supportate da Squid. Capitolo 12. Avviare Squid 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 Istruzioni multipiattaforma Al termine della compilazione e dell'installazione di Squid siamo obbligati a seguire alcune indicazioni di massima 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 (146 of 263)14/02/

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

148 % ls -l /usr/local/squid/var/ totale 8 drwxr-xr-x 18 nobody nobody set 19:48 cache drwxr-xr-x 2 nobody nobody 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 nobody cache_effective_group nobody Avviare Squid manualmente solo dopo aver creato le directory dedicate al Disk Storage consigliamo di eseguire Squid in modalità debugging per capire se il processo funziona correttamente. Avviamo Squid utilizzando l'istruzione squid -N -d 1 -D, questo comando inizializza Squid senza farlo divenire un demone di background % squid -N -d1 2004/03/06 12:02:35 Starting Squid Cache version 2.5.STABLE4 for i386-portbldfreebsd /03/06 12:02:35 Process ID /03/06 12:02:35 With 3584 file descriptors available 2004/03/06 12:02:35 DNS Socket created at , 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 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. (148 of 263)14/02/

149 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 (149 of 263)14/02/

150 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 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 (150 of 263)14/02/

151 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 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 > test successivamente verificheremo se il contenuto del file test è congruo 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 (151 of 263)14/02/

152 #!/bin/sh # nome del file: squid.sh echo -n ' Squid ' case "$1" in start) /usr/local/squid/bin/squid -D ;; stop) /usr/local/squid/bin/squid -k shutdown ;; restart) /usr/local/squid/bin/squid -k reconfigure ;; *) echo "Usage: `basename $0` {start stop restart}" ;; esac questo tipo di script ricorre agli argomenti start, stop e restart % /usr/local/etc/rc.d/squid.sh start lo script è stato testato con FreeBSD 4.11-STABLE 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 (152 of 263)14/02/

153 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 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.stable rimuoviamo il package % rpm -e squid-2.4.stable warning: /etc/squid/squid.conf saved as /etc/squid/squid.conf.rpmsave l'operazione appena effettuata non cancellerà il vostro file di configurazione squid.conf ma lo rinominerà eseguendo una copia di sicurezza. Il messaggio di warning contenuto nell'esempio sopracitato è piuttosto chiaro. La procedura di disinstallazione del package rpm ha rimosso anche altri files come /etc/sysconfig/squid. Questo file dovrà essere prontamente ricreato (153 of 263)14/02/

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

155 /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: # description: Squid - Internet Object Cache. Internet object caching is \ # a way to store requested Internet objects (i.e., data available \ # via the HTTP, FTP, and gopher protocols) on a system closer to the \ # requesting site than to the source. Web browsers can then use the \ # local Squid cache as a proxy HTTP server, reducing access time as \ # well as bandwidth consumption. # pidfile: /usr/local/squid/var/run/squid.pid # config : /usr/local/squid/etc/squid.conf # cache : /usr/local/squid/var/cache # logs : /usr/local/squid/var/logs PATH=/usr/bin:/sbin:/bin:/usr/sbin export PATH # # file descriptors (avvia squid con un limite max di 4096 FD) # echo > /proc/sys/fs/file-max ulimit -HSn 4096 # # Source function library.. /etc/rc.d/init.d/functions # Source networking configuration.. /etc/sysconfig/network # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 0 # check if the squid conf file is present # # è stata modificata la directory dove è ubicato il file \ # di configurazione di Squid [ -f /usr/local/squid/etc/squid.conf ] exit 0 (155 of 263)14/02/

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

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

158 exit $? ora verifichiamo l'esistenza di un'utente appropriato per eseguire Squid. In particolare per le distribuzioni Red Hat Linux, dovrebbe essere già presente l'utente squid. In effetti l'utente dovrebbe essere presente in quanto creato precedentemente dalla procedura di installazione della distribuzione originale in formato RPM % more /etc/passwd grep squid squid:x:23:23::/var/spool/squid:/dev/null in merito al Disk Storage di Squid, accertiamoci di configurare anche nel nuovo file di configurazione lo stesso percorso che abbiamo utilizzato nella versione precedente di Squid (TAG cache_dir) % more /etc/squid/squid.conf.rpmsave grep cache_dir cache_dir ufs /home/var/spool/squid ora procederemo con l'assegnazione dei permessi sulle directory, questo processo è fondamentale per consentire ai processi di disk I/O di Squid di essere eseguiti. Inoltre editeremo il file squid.conf per impostare al meglio la nuova configurazione. In questo caso non dimentichiamo che stiamo effettuando una migrazione da una versione 2.4 pacchettizata da Red Hat ad una versione 2.5 direttamente compilata utilizzando i sorgenti prelevati dal sito del progetto Squid. Ricordiamo al lettore che vi sono delle differenze piuttosto importanti tra la versione 2.4 e la versione 2.5 (cfr. capitolo differenze tra Squid 2.4 a Squid 2.5), pertanto non sarà possibile riutilizzare in alcun modo lo stesso file di configurazione % cd /usr/local/squid/var/ % chown -R squid:squid * % ls totale 20 drwxr-xr-x 5 root 4096 apr 7 22:17./ drwxr-xr-x 9 root 4096 apr 7 21:30../ d-wx--x--x 2 squid 4096 apr 7 22:17 cache/ d-wx--x--x 2 squid 4096 apr 7 21:30 logs/ d-wx--x--x 2 squid 4096 apr 7 22:17 run/ per riprodurre il file squid.conf in maniera fedele possiamo aiutarci con il comando grep(8), grep ricerca nei file specificati le righe che contengono una corrispondenza, possiamo così ricercare nel nuovo file di configurazione i TAG più significativi. Nell'esempio vediamo la parte relativa alla configurazione SNMP (158 of 263)14/02/

159 % more /etc/squid/squid.conf.rpmsave grep snmp acl snmpmanager src / acl snmppublic snmp_community public # TAG: snmp_port # NOTE: SNMP support requires use the --enable-snmp configure snmp_port 3401 # TAG: snmp_access snmp_access allow snmpmanager snmp_access allow snmppublic localhost snmp_access allow allowed_hosts snmp_access deny all al termine della preparazione del file squid.conf possiamo provare ad avviare nuovamente Squid % squid -k parse % /etc/rc.d/init.d/squid start Avvio di squid: [ OK ] % netstat --l grep webcache tcp 0 0 *:webcache *:* LISTEN % netstat --l grep 3401 udp 0 0 *:3401 *:* % nmap localhost Starting nmap 3.50 ( ) at :57 CEST Interesting ports on localhost ( ): (The 1645 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 3128/tcp open squid-http grandioso, Squid è in funzione e la migrazione è stata totalmente completata. A questo punto dovremo fare in modo di avviare il processo squid con il relativo livello di init del Sistema Operativo (3 o 5 senza dimenticale lo 0 per l'esecuzione di una corretta chiusura di Squid) utilizzando il comando chkconfig(8), chkconfig fornisce una facility a linea di comando per mantenere le directory /etc/rc[0-6].d in maniera gerarchica e consentire agli Amministratori di Sistema di manipolare i link simbolici contenuti all'interno di queste directory % chkconfig --level 3 squid on % chkconfig --level 0 squid off % chkconfig --level 6 squid off % ls -l /etc/rc.d/rc6.d/k25squid lrwxrwxrwx 1 root root dic 11:34 /etc/rc.d/rc6.d/k25squid ->../init.d/squid % ls -l /etc/rc.d/rc0.d/k25squid lrwxrwxrwx 1 root root 15 2 ott 12:43 /etc/rc.d/rc0.d/k25squid ->../init.d/squid potremo continuare ad utilizzare tranquillamente tutte le facility di gestione di un Sistema Red Hat come ad esempio il comando service, questa utility consente di manipolare i servizi di sistema (159 of 263)14/02/

160 % service squid stop Interruzione di squid: [ OK ] % service squid start Avvio di squid: [ OK ] Maggiori dettagli a riguardo degli scrip di avviamento sono reperibili nelle FAQ in lingua inglese presso la URLs squid-cache.org/doc/faq/faq-3.html#ss 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 (160 of 263)14/02/

161 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 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 (161 of 263)14/02/

162 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 (162 of 263)14/02/