SQUID : DAI SORGENTI AL CONTENT-FILTERING

Analisi delle funzioni base e add-on per la gestione

Andrea Gozzi Daniele Benincasa Francesco Picciati Valerio Romeo asgozzi@gbhtech.com dany.metal@gmail.com piccio85@gmail.com rom121@gmail.com

CdL Informatica, Universit di Modena e Reggio Emilia

"If the Internet turns out not to be the future of computing, we're toast. But if it is, we're golden." Larry Ellison (CEO Oracle), 1999

1.1 Obiettivo:
Con il lavoro si cercato di definire una configurazione del server proxy Squid Cache ottimizzata per un possibile utilizzo in ambienti di produzione, nel rispetto di una serie di requisiti (in ordine di importanza):

1. 2. 3. 4. 5.

Garantire la stabilit del sistema anche sotto carichi di lavoro medio-alti. Ottenere il massimo numero di HIT e quindi migliorare i tempi di risposta. Bloccare gli accessi di utenti non autorizzati. Impedire la visualizzazione di determinate risorse Web. Distribuire equamente la connettivit di rete tra gli utenti e contemporaneamente bloccare certi tipi di download.

1.2 Modalit:
Data la natura di Squid stato indispensabile utilizzare calcolatori con sistema operativo UNIX-like. Ogni applicazione fondamentale per lo svolgimento del progetto stata compilata manualmente, spesso con direttive particolari, in modo da ottenere la migliore configurazione possibile. Versione del software utilizzata: Squid 2.5-STABLE12 Principali caratteristiche hardware delle macchine utilizzate: CPU: AMD Turion64 [1800Mhz 1024KByte Cache] RAM: 1024 MB HD: IDE 5400 RPM OS: Debian GNU/Linux Etch GCC: 4.1 CPU: Sun Microsistems UltraSPARC IIi 333Mhz (2048 Kbyte Cache) RAM: 256 MB HD: SCSI HP ST34573W 4.2 GB OS: FreeBSD 6.1-BETA4 GCC: 3.4.4 [FreeBSD] 20050518 CPU: Intel Pentium II 400Mhz (512KByte Cache) RAM: 192 MB HD: SCSI SAMSUNG WN34324U 4.3 GB OS: Debian GNU/Linux Sarge 2.6.15 i686 GCC: 3.3.5 (Debian 1:3.3.5-13)

NB: Le funzionalit di Squid sono state testate all'interno della LAN dell'Universit di Modena e Reggio Emilia oltre che su una linea FastWeb. Data la tipologia delle due reti (NAT) alcuni risultati potrebbero presentare un certo margine di inattendibilit .

2.1 Squid: concetti fondamentali

Squid un proxy server per sistemi Unix e Unix-like utile per migliorare la gestione delle connessioni di reti locali ad Internet. La funzione principale di Squid quella di ottimizzare i collegamenti ad Internet di una rete: il proxy infatti si far carico di memorizzare tutte le richieste web effettuate dai computer ad esso connessi in modo da restituire le stesse pagine in maniera pi efficiente e veloce. Il proxy (lett. "procura") dunque una sorta di grande contenitore dei dati pi utilizzati dalla rete cui connesso. Ma le funzioni non si fermano qui: un proxy pu essere utile anche a selezionare i contenuti vietati e quelli permessi alla visione, pu essere utile per controllare lattivit della rete interna e per vietare lutilizzo di alcuni programmi. Attualmente Squid in grado di gestire i seguenti protocolli: HTTP, SSL, FTP, GOPHER. Squid uno dei principali software utilizzati per queste funzioni. La complessit del prodotto e la sua estrema configurabilit ne fanno un ottimo software adatto anche a utilizzi in ambiente professionale. Attraverso lutilizzo di Squid sar possibile una riduzione della banda consumata e il controllo pressoch totale delle connessioni. Squid rilasciato sotto licenza GPL ma proprietaria del copyright la UCSD (University of California, San Diego) dove il progetto ha visto la luce. Alcuni dati riguardanti Squid: Dimensione dei sorgenti (compressi con gzip): 1'394'653 bytes. Numero di righe nel file squid.conf: 4434.

Sviluppatori 5. Processi creati quando in esecuzione: 1.

3.1 Fase 1 -Compilazione

Alcune funzionalit di Squid, che ne modificano radicalmente il comportamento in specifiche situazioni, devono essere attivate utilizzando lo script di configurazione (./configure) al momento della compilazione dei codici sorgenti. Qui di seguito si riportano i parametri utilizzati al momento dell'esecuzione di tale script, scelti in modo da ottimizzare le prestazioni della cache e la velocit della risposta:

--prefix=/home/squid/squid/ Per ragioni di sicurezza preferibile specificare una destinazione alternativa (che verr in seguito chrootata) nella quale trover posto l'albero delle cartelle. --enable-dlmalloc Considerando che alcuni test hanno dimostrato la lentezza delle funzioni C quali malloc(),free() e realloc(), si preferito compilare Squid con il supporto per le dlmalloc in modo da incrementarne le prestazioni. --enable-xmallocs-statistics Mostra le statistiche delle funzioni malloc() e free() all'interno dell'interfaccia Web. --enable-delay-pools Mentre possibile limitare la velocit di una singola connessione HTTP ma invece possibile limitare la banda per singole workstation o per intere subnet utilizzando i delay pools . Questa opzione permette inoltre una limitazione della banda per singoli utenti o gruppi di utenti. --enable-async-io --with-pthreads Volendo preparare una configurazione Squid da utilizzare in situazioni di alto carico stato abilitato il supporto per libreria di thread POSIX affinch che le operazioni di I/O vengano gestite in modalit asincrona. --enable-useragent-log Questa opzione permette di registrare in un logfile separato il tag identificativo del software utilizzato dagli utenti. --enable-referer-log Questo parametro, analogamente al precedente, consente a Squid di memorizzare il percorso fatto dall'utente nel Web attraverso i referer. --enable-snmp SNMP (Simple Network Management Protocol): e il protocollo utilizzato per comunicare informazioni di carattere amministrativo allinterno della rete. In questo caso stato abilitato per permettere la creazione delle statistiche con il supporto del software MRTG.

--enable-arp-acl Abilitando questo parametro possibile impostare le ACL in modo che il controllo venga fatto sulla base dell'indirizzo fisico (MAC) della scheda di rete. --enable-htcp Attiva il supporto per protcollo HTCP che andr ad affiancare il ICP per i collegamenti con le altre cache. --enable-linux-netfilter Netfilter, anche detto iptables, un componente del sistema Linux che permette l'intercettazione e la manipolazione dei dati trasferiti in rete. Ci rende possibile la realizzazione di funzionalit di rete avanzate (ad esempio la gestione di firewall basata sul filtraggio delle comunicazioni). Nota la stabilit e la robustezza di iptables sempre consigliabile abilitare questo parametro . --enable-auth=basic Con questa opzione stata attivata la gestione degli accessi in Squid . Nel nostro caso la procedura di autenticazione viene effettuata da mysql_auth che scambia le informazioni con il proxy server in modalit trasparente (basic). --enable-storeio=diskd Parametro fondamentale di Squid, definisce in che modo verranno salvati gli oggetti nella cache. Le motivazioni di questa scelta rispetto al metodo default verranno discusse brevemente nella sezione relativa al file squid.conf (pagina 9) . --enable-removal-policies=lru heap Il secondo fattore da cui dipendono le prestazioni di una cache l'algoritmo con cui vengono scelti gli oggetti da rimuovere. Analogamente alla storage engine (diskd), la scelta dell'algoritmo verr discussa successivamente (pagina 8).

3.2 Fase 2 -Il nocciolo del proxy: squid.conf

Una volta completata la fase di compilazione dei sorgenti bisogne apportare le modifiche necessarie al file contenente tutte le direttive di funzionamento . Il file squid.conf si trova nella sottocartella etc/ all'interno della directory principale di Squid . Date le notevoli dimensioni del file ed il grande numero di possibili parametri, si esaminano qui soltanto quelli pi importanti.

http_port 3128 Socket su cui Squid si mette in ascolto per ricevere le richieste dei client . Poich richiesta l'autenticazione degli utenti stato mantenuto il valore di default, bloccando gli accessi esterni alla LAN. https_port none Per evitare possibili utilizzi impropri da parte degli utenti le risorse HTTP cifrate tramite protocollo SSL non vengono gestite da Squid.

icp_port 3130 htcp_port 4827 Specifica la coppia di porte che verranno utilizzate per l'invio e la ricezione delle query ICP e HTCP.

icp_query_timeout 5 Intervallo di tempo (in secondi) oltre il quale una richiesta alle peer cache viene considerata invalida. Trovandoci all'interno di LAN durante i test, si preferito incrementare questo valore per evitare timeout prematuri.

cache_peer pa.us.ircache.net parent 3128 3130 login=username:password cache_peer pb.us.ircache.net parent 3128 3130 login=username:password cache_peer bo.us.ircache.net sibling 3128 4827 htcp login=username:password cache_peer uc.us.ircache.net sibling 3128 4827 htcp login=username:password Queste direttive definiscono i collegamenti alle cache del consorzio IRCache. Si optato per una scelta intermedia tra le possibili configurazioni, ovvero parent e sibling, utilizzando entrambi i protocolli HTCP e ICP per migliorare le prestazioni.Dopo aver effettuato alcune sessioni di test per calcolare il RTT delle richieste, le cache pa (Palo Alto, CA) e pb (Pittsburgh, PA) sono risultate quelle con il valore minore e quindi configurate con lo status di parent. hierarchy_stoplist cgi-bin ? Parametro che indica i termini che, se individuati all'interno di un URL, non verranno richiesti alle peer cache. La directory cgi-bin nei webserver contiene degli script (C/C++, VB, PERL, ...) che generano pagine web in modo dinamico, rendendo inutile il caching.

cache_mem 16 MB Indica il quantitativo massimo di memoria centrale della macchina che Squid autorizzato a utilizzare per alcuni tipi di oggetti (quelli in transito, quelli con alto tasso di richeste e quelli non salvabili nella cache). Su sistemi con grandi quantit di RAM ad accesso veloce, incrementando questo valore si ottengono notevoli miglioramenti.

cache_swap_low 80 cache_swap_high 95 Limite superiore ed inferiore di riempimento della cache. Il low specifica la percentuale alla quale Squid inizier la sostituzione degli oggetti sul disco al fine di mantenersi prossimo a questo livello . Nell'ambito del test i valori di default sono stati modificati in modo che, ogni qualvolta fosse stato raggiunto il low-mark, rimanesse comunque disponibile spazio per un oggetto potenzialmente grande. Arrivare ad un valore del 95% significherebbe avere una cache che si riempie pi velocemente di quanto si svuoti, e sarebbe quindi necessario avviare una sostituzione pi aggressiva.

maximum_object_size 5120 KB minimum_object_size 0 KB maximum_object_size_in_memory 128 KB Queste tre direttive gestiscono gli oggetti che potranno essere memorizzati in cache. Il proxy potr tenere in cache gli oggetti di dimensioni comprese tra 0 e 5MByte. L'ultimo parametro si riferisce alla memoria centrale ed stato impostato a 128 Kbyte in modo che gli unici oggetti salvati in RAM possano essere pagine web o immagini di dimensioni contenute.

cache_replacement_policy heap LRU Algoritmo per la rimozione degli oggetti dalla cache: LRU rimuove gli oggetti che non sono stati pi richiesti da diverso tempo . L'algoritmo pu essere implementato tramite semplici liste LRU. LRU e heap LRU conservano gli oggetti referenziati pi recentemente. Heap GDSF ottimizza lo HIT rate conservando in cache gli oggetti piccoli e di pi frequente utilizzo 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 mantiene gli oggetti di pi frequente utilizzo in cache a prescindere dalle dimensioni, ottimizzando il byte hit rate a

scapito del HIT rate, impedendo a molti oggetti piccoli meno frequentemente utilizzati di essere cached. stato scelto lo heap LRU per le maggiori prestazioni delle strutture dati. cache_dir diskd /home/squid/squid/var/cache1 200 12 128 cache_dir diskd /home/squid/squid/var/cache2 200 12 128 Parametro che definisce le directory in cui saranno create le cache, la loro dimensione (200MByte) ed il numero massimo di sottocartelle (1 livello: 12; 2 livello: 128). La direttiva fondamentale il tipo di storage engine, ovvero la modalit con cui verranno scritti i dati sul disco: in questo caso stato scelto di utilizzare DISKD, che permette la creazione di un nuovo processo interamente dedicato alle funzioni di I/O in modo da non bloccare quello principale di Squid.

debug_options ALL,3 Opzione che specifica il livello (quindi la quantit) di informazioni che verranno salvate nei log generati da Squid. Il valore deve essere compreso in un intervallo tra 1 e 9, ad esempio la scelta di 3 con una media di 50'000 richieste in 24h genera un file di circa 8MByte.

redirect_program /usr/bin/squidGuard -c /home/squid/squidGuard/squidGuard.conf redirect_children 5 Definizione del software esterno a Squid (chiamato helper) che viene impiegato per funzioni di filtraggio dei contenuti e degli URL. In questo caso stato preferito l'utilizzo di squidGuard, indicandone il percorso ed il suo file di configurazione. La seconda direttiva imposta il numero massimo di processi helper creati da Squid: un numero troppo alto potrebbe risultare dannoso per la stabilit del sistema.

auth_param basic program /home/squid/squid/libexec/mysql_auth auth_param basic children 5 authenticate_ttl 1 hour Analogamente alle direttive precedenti questi parametri permettono di specificare un helper per l'autenticazione degli utenti che intendono avvalersi del server Squid . L'ultima riga definisce l'intervallo di inattivit nel quale un utente pu essere considerato ancora autenticato.

request_header_max_size 100 KB request_body_max_size 0 KB reply_header_max_size 20 KB reply_body_max_size 0 allow all Queste direttive, che limitano le dimensioni header e body delle richieste HTTP, vengono utilizzate primariamente per evitare possibili attacchi DoS (Denial of Service) che potrebbero mandare in stallo il processo principale del proxy. quick_abort_min 64 KB quick_abort_max 92 KB quick_abort_pct 85 Parametri che indicano a Squid come gestire i trasferimenti degli oggetti nel caso l'utente annulli la richiesta. Ad esempio se: quick_abort_min 10 quick_abort_max 100 quick_abory_pct 80 2/11kb -> Mancano meno di 10kb quindi finisci il download. 40/100kb -> stato trasferito meno dell'80% del file, quindi interrompi. 90/100kb -> stato scaricato pi dell'80% quindi finisci il download . 850/1000kb -> Mancano pi di 100Kb, quindi interrompi.

dns_testnames netsol.com internic.net nlanr.net europa.eu www.tv

Questa direttiva contiene la lista di domini che Squid utilizza per verificare il funzionamento dei server DNS a cui si rivolger durante l'esecuzione.

memory_pools_limit 25 MB qui definita la quantit di memoria centrale allocata preventivamente dal proxy server in modo da massimizzare le prestazioni evitando di eseguire funzioni malloc() superflue. Le dimensioni di questa porzione di memoria vanno decise tenendo conto del parameto maximum_object_size_in_memory.

snmp_port 3401 Socket del sistema su cui sar attivo il agent SNMP che, interrogato con appositi software in grado di fornire dettagliate informazioni sullo stato di Squid.

delay_pools 2 Con questo parametro sar attivato il supporto per la limitazione della banda consumata dagli utenti si avvalgono di Squid. I delay pool possono essere paragonati a secchi fessurati (leaking bucket) che perdono acqua (ovvero la banda consumata dai client) ma che contemporaneamente vengono riempiti a velocit costante (la velocit massima di trasferimento).Nel caso il secchio venga vuotato completamente tutti gli utenti si divideranno equamente la banda fino a che, nei periodi di inattivit, il secchio si riempia. Qualora vari utenti attingano contemporaneamente dal secchio la quantit di banda a disposizione di ciascuno di essi sar equamente divisa in modo che l'insieme dei download corrisponda alla disponibilit totale del secchio. Mano a mano che il numero di utenti si riduce la disponibilit individuale cresce tendenzialmente fino a corrispondere all'intera capacit del secchio (un solo download in funzione). delay_class 1 2 delay_class 2 1

Non essendo possibile limitare la velocit di una singola connessione HTTP sono stati implementati tre diversi tipi di delay pool: Tipo 1: la limitazione si applica a tutti i client. Tipo 2: si imposta una limitazione totale oltre che un valore individuale per ogni client (identificato dagli ultimi 8 bit dell'indirizzo IP). Tipo 3: analogo al 2, in pi introduce un parametro per la sottorete (identificata dai bit 17-24 dell'indirizzo IP). La configurazione migliore quella del terzo tipo, dividendo la banda prima per tutte le sottoreti e quindi per ogni client, rendendo cos la distribuzione effettivamente equa. Ad esempio, per la rete UNIMO, una configurazione del genere permetterebbe di limitare la banda prima a tutti i dipartimenti (sci.unimo.it, aule.unimo.it, ing.unimo.it, ecc.) e poi tra tutti gli utenti evitando consumi sproporzionati.

delay_parameters 1 -1/-1 20000/20000 Il primo delay pool creato, del secondo tipo, viene utilizzato per limitare le risorse Web comuni (HTML, immagini, animazioni) che generalmente sono il motivo primario della navigazione. I parametri quantificano la velocit di trasferimento massima globale e per singolo client. Il tasso globale stato impostato a -1 per indicare un valore illimitato mentre gli utenti potranno usufruire al massimo di 160Kbps (20Kbyte/sec).

delay_parameters 2 8000/8000 Il secondo delay pool, con limitazione globale, servir a gestire tutti i contenuti non strettamente legati alla consultazione di pagine Web. Solitamente queste tipologie rischiano di intasare la connessione ad Internet quindi il tasso di trasferimento viene limitato a 64Kbps (8Kbyte/sec), anche per scoraggiare questi download.

prefer_direct off Questa direttiva indica a Squid che, se possibile, tutte le richieste devono essere instradate alle parent cache.

redirector_bypass off Parametro relativo al comportamento del proxy: nel caso i processi di reindirizzamento creati non siano sufficienti a soddisfare tutte le richieste dei client, blocca l'accesso fino a quando la coda di attesa non si sia ridotta. Alcuni utenti maliziosi potrebbero sfruttare questa propriet per visitare siti inadatti, quindi stata disabilitata. chroot yes Questa opzione permette di usufruire del comando Unix chroot, aumentando la sicurezza del sistema. L'idea sottesa al programma chroot piuttosto semplice: quando si esegue Squid (o qualunque altro processo) in una gabbia chroot, il processo stesso diventa incapace di vedere la parte di filesystem estern a alla sua gabbia. Per esempio, configurando Squid affinch giri confinato nella directory /home/squid/squid il contenuto di questa cartella gli apparir come / (directory root) e non potr accedere a nient'altro al di fuori di essa.

high_response_time_warning 6000 Direttiva molto utile all'amministratore per scoprire eventuali congestioni della rete, che permette di impostare un limite temporale (in msec) entro il quale la richiesta del client deve esser stata soddisfatta. Se entro tale intervallo la risorsa non stata ancora recuperata, viene inviato un messaggio nel log.

3.3 ACL: obiettivo controllo totale

Le liste di controllo di accesso, ACL, acronimo di Access Control List, sono una delle colonne portanti del software Squid. infatti possibile implementare diverse politiche di utilizzo per definire le modalit con cui gli accessi alla rete esterna debbano effettivamente avvenire.Definendo delle liste di controllo di accesso con diverse regole associate, possibile impedire o consentire agli utenti di accedere a determinati siti o a determinaticontenuti. inoltre possibile limitare l'utilizzazione 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 una strategia completa di accesso che soddisfi entrambi i requisiti di stabilit e sicurezza. La configurazione preparata nell'ambito di questo progetto ha comportato l'utilizzo di diverse ACL, destinate a svolgere una molteplicit di funzioni; va comunque detto che non tutte le possibilit sono state sfruttate. Segue una breve descrizione della tipologia e dei compiti:

acl QUERY urlpath_regex cgi-bin acl QUERY urlpath_regex \? Queste due liste, lavorando insieme alla direttiva di configurazione no_cache che controlla quali risorse non verranno mai salvate nella cache del proxy, definiscono le espressioni regolari cgi-bin e \?. Quindi, se almeno una di queste due regex rilevata all'interno di un URL, Squid non memorizzer la pagina associata. acl IpAddressOnly url_regex ^http://[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/$ acl IpAddressOnly url_regex ^http://[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$ acl SSL proto ssl Avendo impostato un collegamento con la gerarchia di webcache del progetto IRCache, per poter instradare verso di loro le richieste, questo proxy dovr sottomettersi alla policy definita dal consorzio , che prevede due fondamentali regole: Le query possono essere espresse soltanto con un hostname e mai attraveso un indirizzo IP.

Le webcache IRCache non accettano alcun tipo di richiesta che sfrutti il protocollo TSL/SSL. Questa regola stata introdotta a seguito di abusi constatati in passato.Pertanto chi si collega a queste webcache deve agire in modo da evitare questo tipo di instradamento. Le due ACL iniziali sono relative alla prima regola, infatti si utilizza il principio delle espressioni regolari per filtrare le richieste in base all'indirizzo IP.Ad esempio, la richiesta per http://www.unimo.it/ verr inoltrata verso la gerarchia di cache mentre http://155.185.2.21/ sar gestita localmente. La terza ACL sfrutta il parametro proto che permette di definire un tipo di protocollo, in questo caso il TSL/SSL.Quindi, qualsiasi richiesta che faccia uso del protocollo specificato non sar inoltrata. Queste liste vengono utilizzate insieme alla direttiva cache_peer_access e devono essere dichiarate per ogni singola webcache.

acl Safe_ports port 80 acl Safe_ports port 21 acl Safe_ports port 70 acl Safe_ports port 194 Questa ulteriore serie di liste permette di specificare verso quali porte Squid autorizzato ad instradare il traffico proveniente dai client.Generalmente comprendono diversi protocolli, nel caso della ricerca sono stati abilitati soltanto HTTP(80), FTP(21), GOPHER(70) ed IRC(194).

acl UNIMO dstdomain .unimo.it Questa ACL globale, che sfrutta la direttiva http_access definisce come possibili client (autorizzati a sfruttare la cache di Squid) soltanto le macchine appartenenti al dominio unimo.it.

acl auth proxy_auth REQUIRED Avendo deciso di utilizzare un helper esterno a Squid per permettere agli utenti di autenticarsi, questa ACL viene utilizzata nello stesso modo di UNIMO, ovvero insieme a http_access, impedendo l'accesso ad Internet a tutti i client che non abbiano inserito le credenziali.

acl snmpcom snmp_community public Per ottenere maggiori informazioni sullo stato di Squid stato abilitato il supporto per il protocollo SNMP attivando quindi l'agent interno al proxy. Nonostante nel caso di Squid questo protocollo sia utilizzabile semplicemente per elaborare delle statistiche, stato necessario creare un identificativo che dovr essere inviato dall'applicativo destinato ad analizzare i dati.

acl tipo_file_limitati url_regex .exe .mp3 .vqf .tar.gz .gz .rpm .zip .rar .avi .mpeg .mpe .mpg .qt .ram .rm .iso .raw .wav .mov L'utilizzo delle funzioni di limitazione della banda attraverso i delay pools sarebbe risultata incompleta senza la creazione di una lista una lista di file da considerare superflui per la normale navigazione Web. Questa lista, basata sulle espressioni regolari, permette di identificare i file con particolari estensioni e limitarne la velocit di trasferimento.Deve essere ovviamente sfruttata all'interno della dichiarazione di un delay pool.

3.4 Ancora qualcosa su squid.conf

Le direttive citate nelle sezioni precedenti rappresentano soltanto una piccola parte, sebbene probabilmente fondamentale, di tutte quelle presenti nel file di configurazione. Squid in realt offre all'amministratore molte altre funzioni, tra le quali: Interception Caching: detto anche proxy trasparente, una funzionalit attraverso la quale si fa in modo di ridirigere tutto il traffico

(TCP) verso un servizio proxy del nodo locale, quando altrimenti sarebbe diretto verso altri nodi, a porte determinate. Un proxy trasparente pu funzionare solo se il traffico della LAN deve attraversarlo per forza. Pertanto, si pu attivare questa funzionalit solo in un router, che eventualmente pu fungere sia da firewall che da proxy trasparente. Nonostante sia una caratteristica decisamente interessante, data la configurazione della rete UNIMO risultato impossibile eseguire dei test. Privacy: numerose opzioni di Squid consentono di mantenere la riservatezza sull'identit del navigante (fino ad un certo punto tuttavia, in quanto l'indirizzo IP del proxy verr pur sempre rilevato) sovrascrivendo oppure filtrando alcuni campi negli header delle richieste HTTP ed evitando di memorizzare informazioni confidenziali all'interno dei log. In questo contesto va segnalata la direttiva forwarded_for che, se impostata al valore OFF, impedisce l'invio dell'indirizzo IP del client (X-Forwarded-For: unknown). Altri campi dello header che potrebbero compromettere l'identit dell'utente e che quindi non dovrebbero essere inviati, sono: From, Referer, Server, User-Agent, WWW-Authenticate, Link. Reverse Proxy: una configurazione utile principalmente per reti di grandi dimensioni e con una notevole quantit di traffico proveniente dall'esterno. Il funzionamento teoricamente molto semplice: Squid viene impostato per ricevere connessioni da Internet sulla porta 80 (default per HTTP) e quando giunge la richiesta per una risorsa, il proxy si occupa di instradarla verso il webserver, diminuendo cos la pressione su quest'ultimo. Questo metodo particolarmente indicato per distribuire il carico di lavoro su diversi calcolatori mantenendo comunque un livello di astrazione per il navigante.

4.1 Gli add-on per Squid

Questo deployment dell'applicativo Squid ha richiesto l'utilizzo di programmi esterni, chiamati helper, che si occupino di determinati compiti. In questo caso si trattato di gestire l'autenticazione degli utenti che intendono sfruttare la cache e un redirector che blocchi l'accesso a determinate pagine web considerate inadatte o la cui visione stata vietata.

4.2 Autenticazione degli utenti mediante ricorso a database MySQL

Partendo dal concetto che Squid debba essere utilizzato in una rete, bisogna presupporre che sia gi stato definito un protocollo di autenticazione che permetta agli utenti l'accesso ai terminali.Si potrebbe quindi aver a che fare con una rete principalmente Windows (LDAP) o Unix (PAM). Per risovere questo problema sono stati implementati numerosi helper che permettono di interfacciare lo Squid con il protocollo utilizzato all'interno della LAN semplificando cos i compiti, sia per l'amministratore che per gli utenti. Data la nota affidabilit di questi software e l'intenzione di sfruttare applicazioni Open Source stato scelto un sistema di autenticazione alternativo, meno utilizzato ma non per questo meno funzionale: mysql_auth. Il progetto, il cui sviluppo attualmente attraversa una fase di stallo, stato portato avanti dall'ungherese Ervin Hegedus, arrivando fino alla versione 0.8 rilasciata nel dicembre 2004. Il concetto di mysql_auth decisamente semplice: all'interno di un database MySQL viene creata una tabella contenente i campi username e password relativi a tutti gli utenti che avranno accesso alla rete Internet sfruttando il proxy. Quando un client tenta l'accesso alla rete gli vengono richiesti i dati attraverso un prompt del browser, e se questi corrispondono ad una delle tuple contenute nel database, l'accesso accordato; in caso contrario il navigatore del client visualizzer un messaggio di errore e la consultazione del Web gli sar inibita. Lo scambio di dati con Squid ed il controllo della correttezza di tali informazioni gestito da uno dei processi helper creati all'avvio del proxy. Il metodo di installazione si rivelato leggermente anomalo rispetto alle consuetudini dei sistemi Linux: stato necessario andare a modificare manualmente alcuni sorgenti e header, nonch il Makefile, per specificare la configurazione del sistema operativo. src/mysql_auth.conf: necessario indicare i parametri per la connessione al DBMS MySQL: host, username, password, nome del database, identificativo della tabella, posizione del socket UNIX, lunghezza massima del nome utente e relativa password. Da notare la direttiva booleana encrypt_password_form che permette di scegliere il formato in cui saranno salvate le password nel database: plain text oppure cifrato. Per ovvie ragioni di sicurezza l'opzione consigliata quest'ultima.

src/define.h: l'unica opzione, #define CONFIG_FILE, da impostare riguarda la posizione definitiva (ovvero al termine dell'installazione) del file mysql_auth.conf. Makefile: supponendo una installazione da sorgenti del server MySQL sar necessario specificare in questo file la posizione di mysql.h e libmysqlclients.a, fondamentali per l'interazione con il DBMS. Inoltre sar compito dell'amministratore indicare la cartella contenente Squid in modo che il binario di mysql_auth venga copiato nella sottodirectory libexec/ . Dopo aver eseguito queste modifiche sar necessario digitare i comandi make e make install per completare l'installazione di mysql_auth. Per attivare il sistema di autenticazione baster aggiungere alcune direttive, illustrate nelle precedenti sezioni (3.2 e 3.3), all'interno del file squid.conf e successivamente riavviare o ricaricare Squid.

4.3 Blocco delle risorse Web non accettabili

La principale sfida degli ultimi anni per ogni amministratore di rete stata probabilmente il riuscire a bloccare efficacemente quei contenuti che, pur essendo reperibili sul Web, sono ritenuti inadatti al posto di lavoro, alla scuola o semplicemente contravvenenti alla legislazione nazionale. In queste categorie rientrano, oltre all'ovvia pornografia e pedopornografia, anche risorse quali chatroom, forum di discussione, file multimediali e software protetti da diritto d'autore, negozi virtuali o anche applicativ i potenzialmente pericolosi. Squid, operando insieme ad un helper, permette di risolvere questi problemi (se non tutti, almeno una buona parte di essi) senza evidenti cali di prestazioni, sia a livello hardware che software. L'estensione in questione nota come squidGuard ed stata sviluppata da due amministratori di rete danesi, Pl Baltzersen e Lars Erik Hland, con l'obiettivo di impedire comportamenti scorretti da parte dei loro utenti. Nonostante la pi recente versione disponbile sia datata dicembre 2001, squidGuard senza dubbio il miglior redirector / access controller disponibile per Squid in termini di prestazioni, qualit e percentuale d i errori. Questo software integra numerose funzioni, tra le quali quelle maggiormente degne di menzione sono : Limitazione dell'acceso ad URL contenenti speciali espressioni regolari. Blocco della navigazione su siti Web presenti in un database, o blacklist. Reindirizzamento degli utenti non autenticati ad una pagina di registrazione. Sostituzione dei banner ed altre pubblicit presenti all'interno delle pagine, in modo da velocizzare la navigazione. Blocco del download di file utilizzando come criterio l'estensione. inoltre possibile configurare squidGuard per applicare i criteri d'accesso selettivamente, ovvero in base ai permessi del client o all'ora della giornata o anche in base alla data. Il meccanismo di funzionamento decisamente semplice: nel momento in cui un client richiede una risorsa al proxy questa viene passata al redirector che la analizza e, se consentita, invier un segnale a Squid in modo che la fase di recupero si possa concludere regolarmente. L'analisi si articola su tre fasi principali:

i. Identificazione del richiedente e controllo delle eventuali restrizioni d'accesso. ii. Confronto della risorsa richiesta con le espressioni regolari bloccate e il database di URL vietati. iii. Reindirizzamento in caso di contenuto proibito, altrimenti soddisfacimento della richiesta.
Si pu senza dubbio definire la blacklist punto di forza del helper squidGuard in quanto essa viene utilizzata per filtrare ogni richiesta dei client. Le blacklist non sono altro che delle liste contenenti tutti gli URL, i domini e le regex che l'amministratore di rete ha deciso di rendere inaccessibili: generalmente vengono utilizzate le liste fornite sul sito di squidGuard oppure quelle create dal dipartimento IT dell'Universit di Tolosa, entrambe molto complete. Per ottimizzare i confronti tra le richieste e i termini presenti nelle blacklist, squidGuard permette che quest'ultime vengano strutturate secondo il metodo del Berkeley DB, database noto per essere stato incorporato in varie

applicazioni. L'installazione di squidGuard si rivela essere molto semplice, l'unica dipendenza da soddisfare proprio il Berkeley DB; una volta installato baster configurare i sorgenti e compilarli con il metodo make e make install. Il funzionamento completamente basato sul file di configurazione, squidGuard.conf, contenente tutte le direttive necessarie ad affrontare qualsiasi possibile situazione una sintassi errata porterebbe ad una interruzione improvvisa dei processi helper e conseguentemente all'arresto di Squid. Questi i parametri fondamentali:

dbhome /home/squid/squidGuard/blacklists
Indica la posizione delle blacklist contenenti gli URL, i domini e le espressioni regolari proibite. Nel caso siano presenti pi liste contenute in cartelle separate (ad esempio adult, forum, gambling , ecc..) va specificata la directory padre.

logdir /home/squid/logs/squidguard
Cartella che contiene i log generati da squidGuard . Da notare che la directory dovr avere i permessi in lettura e scrittura relativi all'utente responsabile dell'esecuzione di Squid; nel nostro caso si tratta di nobody.

src ADMIN {
ip 127.0.0.1

Definisce un indirizzo IP o gruppo di indirizzi che squidGuard gestir con il nome di ADMIN. Utile per poter effettuare controlli diversi a seconda della provenienza del client.

dest adult {
domainlist adult/domains urllist adult/urls expressionlist adult/expressions } Questi parametri permettono di definire una blacklist: basandosi sulla direttiva dbhome squidGuard in grado di ricostruire il percorso ai file domains, urls e expressions (in questo caso contenuti nella cartella /home/squid/squidGuard/blacklists/adult/).

acl {
ADMIN { pass all

default { pass !adult all redirect http://155.185.131.128/accedi.php

} Qui viene definito il comportamento di squidGuard nei confronti dei client: in questo caso il calcolatore che faccia parte del gruppo ADMIN non sar sottoposto a nessun tipo di controllo mentre qualsiasi altra richiesta non potr avere termini, domini o URL contenuti nella blacklist adult. L'ultimo parametro imposta la reindirizzamento, ovvero la pagina a cui l'utente sar trasferito nel caso la sua richiesta risulti non permessa.

5.1 ICP, HTCP e consorzio IRCache

Abbiamo affermato precedentemente che l'utilizzo di un proxy da considerarsi vantaggioso se la percentuale di HIT, ovvero il caso in cui

un oggetto richiesto sia presente nella cache, superiore al 10-15%. Questo valore pu essere ancora migliorato semplicemente aggiungendo un secondo livello di cache, a cui lo Squid locale si collegher per richiedere gli oggetti. Questo metodo, chiamato cache gerarchiche, permette ad un proxy di richiedere la risorsa ad un'altra cache prima di andare a recuperarlo direttamente alla fonte, riducendo cos il tempo di completamento della richiesta ed aumentando la probabilit di HIT. L'utilit di questo metodo dimostrata nel caso in cui l'oggetto richiesto sia presente su una macchina con collegamento ad Internet lento: andandolo a recuperare da una cache gerarchica (solitamente con grande disponibilit di banda) migliora notevolmente la velocit della navigazione. Le cache gerarchiche sono un'estensione logica del concetto di cache, e sono implementate utilizzando i protocolli di intercache CARP, DIGEST, ICP e l'evoluzione di quest'ultimo, il HTCP; Squid offre supporto nativo per tutti i protocolli elencati ma nell'ambito del progetto sono stati sfruttati unicamente il gli ultimi due.

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 gerarchiche a cui un proxy server collegato. La cache adiacente pu rispondere con un HIT, ovvero che l'oggetto stato trovato, oppure con un MISS, indicando che l'oggetto non presente nella cache adiacente. Essendo stato implementato in modo da non appesantire eccessivamente un proxy e con l'intenzione di minimizzare il RTT tra cache remote, il protocollo ICP definisce un time-out molto breve per la ricezione della risposta, dopo il quale l'oggetto verr recuperato localmente. Utilizza il protocollo di trasporto UDP e permette inoltre il multiplexing, ovvero l'invio sequenziale di pi oggetti all'interno di una stessa connessione.

HTCP
Hyper Text Caching Protocol (HTCP) un protocollo implementato per migliorare il precedente ICP. Anche il HTCP sfrutta un metodo del tipo domanda/risposta utilizzano lo User Datagram Protoco l (UDP) per il trasporto delle informazioni sulla rete. Un falso HIT pu essere un problema per ICP soprattutto in una relazione di cache del tipo sibling , ma il HTCP permette di risolvere questo inconveniente inviando uno header HTTP completo sia per quanto riguarda la richiesta che la risposta. Il protocollo HTCP include moltissime funzionalit sperimentali del ICP, tra queste citiamo la capacit di una cache di richiedere al sistema adiacente la cancellazione o l'aggiornamento di una determinata risorsa. Trattandosi di un protocollo complesso la struttura del messaggio HTCP richiede maggiori risorse di sistema ed una configurazione del proxy leggermente pi complessa, ma permette un miglioramento di prestazioni rispetto al suo predecessore. L'utilizzo di una gerarchia di cache comporta anche la definizione dei livelli di parentela, ovvero il tipo d i relazione che si creer tra i diversi proxy destinati ad interagire. Entrambi i protocolli ICP ed HTCP offrono due diverse possibilit:

Parent
Questa tipologia di relazione solitamente utilizzata nel caso la cache remota abbia un link verso Internet pi veloce o pi stabile rispetto al proxy locale. Il funzionamento prevede infatti che, nel caso la richiesta ritorni un valore MISS, l'oggetto venga recuperato dalla cache remota e successivamente inviato a quella locale. per importante ricordare come questa situazione rischi di creare un carico eccessivo su l collegamento ad Internet del proxy a monte.

Sibling
La definizione di una cache remota come sibling crea una relazione di pari grado, utile principalmente per distribuire il carico tra i proxy collegati: quando una richiesta viene inoltrata e la risposta un MISS, la cache che ha originato la query ICP proceder localmente al recupero della risorsa senza oberare di lavoro la sua gerarchia. Da notare che le relazioni sono attive in un'unica direzione: un figlio potr instradare le richieste verso il parent, ma non viceversa. Volendo sfruttare le funzionalit dei sistemi di cache gerarchiche nello svolgimento di questo progetto e non potendone provare l'effettiva utilit semplicemente configurando due proxy locali, Squid stato impostato per collegarsi alle webcache del consorzio IRCache con entrambe le relazioni di parent e sibling .

IRCache nasce nel 1995 con l'obiettivo di creare una rete mondiale di cache accessibili a tutti, individui ed organizzazioni, per aumentare il pi possibile le prestazioni dei proxy. Chiunque, previa registrazione e attenendosi al regolamento, pu infatti gestire una cache e collegarsi a quelle del progetto IRCache in modalit parent o sibling e quindi beneficiare dei servizi offerti.

5.3 Ottimizzazione a livello di sistema

Il buon funzionamento ed alte prestazioni della webcache non sono determinate semplicemente dalla configurazione del proxy ma in gran parte anche dal tipo di sistema su cui Squid si dovr appoggiare. Questo include sia il livello del sistema operativo che la base hardware sottostante; stato ampiamente dimostrato che, a differenza di altre applicazioni server, la potenza di calcolo del processore pu essere considerata marginale. Di grande importanza sono invece le caratteristiche delle periferiche di memorizzazione, RAM e memoria ausiliaria.

Sistema Operativo
Un'ottima scelta pu essere rappresentata dal sistema operativo FreeBSD, che senza dubbio una scelta di eccellenza in quanto fornisce la giusta miscela di funzionalit e standardizzazione. Non dimentichiamo che, se a livello di performance FreeBSD si posiziona in testa al gruppo dei sistemi operativi, a livello di compatibilit con il codice sorgente, quello che meglio si integra con Squid GNU Linux. possibile citare numerosi casi in cui Squid stato utilizzato su sistemi operativi proprietari, ad esempio Solaris oppure OS/2, ma questo progetto ha avuto come regola fondamentale l'utilizzo di software Open Source.

Memoria Centrale
Squid utilizza la memoria RAM per tenere una traccia della tabella degli oggetti, quindi un accesso rapido a questa tabella fondamentale, ed il ricorso alla memoria di swap penalizza le prestazioni del proxy sino a renderlo inservibile. Qualsiasi oggetto memorizzato su disco utilizza circa 75 Byte di memoria RAM, la grandezza media di un oggetto di circa 13 KByte. Utilizzando questi valori possibile definire uno standard di calcolo in merito al fabbisogno di memoria RAM da parte di Squid.

Storage
Per quanto concerne il sottositema dischi, lo standard su bus SCSI (possibilmente in RAID-1) senza dubbio la soluzione consigliata. A tale proposito si rammenta che ormai possibile utilizzare dei sistemi su bus EIDE, ATA o SATA che prevedono il collegamento con delle unit a disco a velocit elevata: queste unit devono essere in grado di supportare il trasferimento dei dati tramite DMA e devono disporre di una capacit di rotazione pari almeno 7'200 RPM.

6.1 Conclusioni
Confrontandoci con l'avvento della banda larga, ormai arrivata a coprire la quasi totalit del territorio (tra ADSL, fibra ottica e presto WI-MAX), si potrebbe pensare al caching come una tecnologia ormai superata. Questo progetto ha invece dimostrato come una buona configurazione di un proxy server, ad esempio Squid, possa ottimizzare la navigazione e l'utilizzo delle risorse presenti sul Web, indipendentemente dalla loro forma. Una cache pu inoltre semplificare la gestione della rete al personale amministrativo, permettend o modifiche, anche sostanziali, senza turbare eccessivamente gli utenti finali. Le funzionalit avanzate di Squid garantiscono inoltre un livello di sicurezza elevato riducendo quindi i possibili problemi indotti da comportamenti scorretti degli utenti interni o di hacker intenzionati a danneggiare il sistema informatico .

A titolo personale raccomanderei l'utilizzo di un proxy server, ed in particolare di Squid, in un ambiente PMI dove la rete aziendale sia composta da 50-100 macchine. In questo caso la spesa per l'acquisto della macchina destinata a svolgere le funzioni di cache sarebb e limitata e allo stesso tempo permetterebbe di evitare i costosi sistemi informatici che rischierebbero d i risultare superflui. Allo stesso modo, l'utilizzo di un sistema operativo e di software Open Source permetterebbe la riduzione, nel lungo termine, dei costi legati all'acquisto di licenze per gli applicativi proprietari.

Bibliografia
Risorse Web Squid-Docs (28/3/2006) http://squid-docs.sf.net/ IRCache (22/3/2006) http://www.ircache.org/ Squid: Oltre le FAQ (28/3/2006) http://www.merlinobbs.net/Squid-Book/ JANET Web Cache Service http://wwwcache.ja.net/ GARR Cache (17/3/2006) http://cache.garr.it/ Web Caching: Making the Most of Your Internet Connection (15/3/2006) http://www.web-cache.com/ The International Web Content Caching and Distribution Workshops (2/3/2006) http://www.iwcw.org/ ICP vs HTCP (13/3/2006) -http://www.squid-cache.org/mail-archive/squid-users/199807/0010.html Anonymous WWW (22/3/2006) -http://www.iks-jena.de/mitarb/lutz/anon/web.en.html Wikipedia http://en.wikipedia.org/

RFC 2126 Internet Cache Protocol (10/3/2006) http://www.ietf.org/rfc/rfc2186.txt 2756 Hyper Text Caching Protocol (10/3/2006) http://www.htcp.org/ 3143 -Known HTTP Proxy/Caching Problems (27/3/2006) ftp://ftp.rfc-editor.org/in-notes/rfc3143.txt 2246 TSL Protocol (14/3/2006) http://www.ietf.org/rfc/rfc2246.txt 1436 GOPHER Protocol -http://www.ietf.org/rfc/rfc1436.txt 2617 -HTTP Authentication: Basic and Digest Access Authentication (21/3/2006) http://www.ietf.org/rfc/rfc2617.txt

Software Squid-Cache http://www.squid-cache.org/ Wisconsin Proxy Benchmark http://www.cs.wisc.edu/~cao/wpb1.0.html Web Polygraph http://www.measurement-factory.com/ SquidGuard http://www.squidguard.org Berkeley DB http://www.sleepycat.com/ mysql_auth http://people.arxnet.hu/airween/mysql_auth/

Back