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 all’interno 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 esterna
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.