Chapter 26. Internet / 26.3. Server proxy: Squid | ||||
|---|---|---|---|---|
 | 26.2. Configurazione di una connessione DSL/ADSL | Chapter 27. Sicurezza nella rete |  | |
Chapter 26. Internet / 26.3. Server proxy: Squid | ||||
|---|---|---|---|---|
| 26.2. Configurazione di una connessione DSL/ADSL | Chapter 27. Sicurezza nella rete | | |
Squid è una cache-proxy molto diffusa per piattaforme Linux/UNIX. Descriveremo come configurarla, i requisiti di sistema necessari, come configurare il proprio sistema per poter eseguire un proxying trasparente ed infine come fare per ottenere statistiche sul carico della cache con l'aiuto di programmi come Calamaris e cachemgr o come filtrare contenuti web con squidGuard.
Squid funge da cache di proxy. Inoltra le richieste di oggetti da parte dei client (in questo caso browser web) al server competente. Quando arrivano gli oggetti richiesti dal server, passa gli oggetti ai client e ritiene una copia degli oggetti nella cache del disco rigido.
Il vantaggio è che quando più client richiedono lo stesso oggetto sarà la cache del disco rigido a replicare, quindi il processo è molto più veloce che nel caso di una richiesta inviata su Internet ed inoltre si risparmia molta banda del sistema.
Squid offre un vasto spettro di proprietà, oltre al caching, p.es. permette di definire gerarchie per il server proxy per il bilanciamento del carico di sistema, designar regole di accesso fisse per tutti i client che vogliono accedere al proxy, consentire o negare l'accesso a determinate pagine web con l'aiuto di altre applicazioni o per l'emissione di statistiche delle pagine web maggiormente e quindi sul comportamento di navigazione degli utenti su Internet.
Squid non è un proxy generico; normalmente fa solo da mediatore fra i collegamenti HTTP. Inoltre appoggia i protocolli FTP, Gopher, SSL e WAIS, ma non altri protocolli Internet come Real Audio, News o videoconferenze. Squid usa il protocollo UDP solo per supportare la comunicazione fra diverse cache, questo è il motivo per cui non vengono supportati diversi programmi multi-media.
Squid può essere usato insieme ad un firewall per proteggere reti interne da attacchi dall'esterno attraverso l'uso di un proxy cache. Il firewall, fatta eccezione per Squid, nega ai client di collegarsi a dei servizi esterni; tutte le connessioni al World Wide Web devono essere stabilite attraverso il proxy.
Nel caso di una configurazione firewall con una DMZ (zona demilitarizzata), imposteremo lì il nostro proxy: in un assetto configurativo del genere è essenziale che tutti i computer nella DMZ mandino i loro file di protocollo ai computer che si trovano all'interno della rete protetta.
Una possibilità di implementare un proxying cosiddetto “trasparente ” viene trattata nella sezione Section 26.3.6, “Configurazione del proxying trasparente”.
I proxy si lasciano configurare in modo che scambiano degli oggetti tra di loro per ridurre così il carico del sistema ed aumentare la possibilità di trovare un oggetto già esistente nella rete locale. Questo concetto permette anche la configurazione di gerarchie di cache, cosicché una cache è in grado di inoltrare richieste di oggetti a cache della stessa gerarchia, o indurre una cache superiore (nella gerarchia) a scaricare (download) gli oggetti da un'altra cache nella rete locale o direttamente dalla fonte.
La scelta della topologia giusta per la gerarchia della cache è molto importante allo scopo di impedire un aumento complessivo del traffico di rete. In una grande rete, è p.es. possibile configurare un server proxy per ogni sottorete e collegarlo poi con il proxy superiore, il quale a sua volta è collegato alla cache del proxy dell'ISP.
L'intera comunicazione viene controllata da ICP (ingl. Internet Cache Protocol), che è basato sul protocollo UDP. Lo scambio di dati fra le cache avviene tramite HTTP (ingl. Hyper Text Transmission Protocol) che si basa su TCP.
Per trovare il server più appropriato per gli oggetti desiderati, la cache invia una richiesta ICP a tutti i proxy della stessa gerarchia. Se l'oggetto è stato trovato, i proxy replicano tramite risposte ICP alle richieste con il codice “HIT”; se non è stato trovato nulla, rispondono con il codice “MISS”. Nel caso di più risposte HIT, il server proxy incaricherà un server ad eseguire il download: questa decisione viene determinata fra l'altro dalla cache che invia come prima la risposta o dalla prossimità della cache. Se non viene inviata alcuna risposta soddisfacente, la richiesta viene inviata alla cache superiore.
![[Tip]](admon/tip.png) | Tip |
|---|---|
Per evitare la memorizzazione molteplice di oggetti in diverse cache della nostra rete, vengono usati altri protocolli ICP come p.es. CARP (ingl. Cache Array Routing Protocol o HTCP (ingl. Hyper-Text Cache Protocol). Più oggetti si trovano nella nostra rete, più grande sarà la possibilità di trovare quello cercato. | |
Non tutti gli oggetti disponibili nella rete sono statici; vi sono molte pagine CGI generate dinamicamente, i contatori di accesso o i documenti SSL cifrati per una maggiore sicurezza. Per questo motivo, tali oggetti non vengono conservati nella cache, dato che l'oggetto ad ogni nuovo accesso si è già modificato.
Per tutti gli altri oggetti nella cache si pone comunque la domanda: per quanto tempo debbano rimanervi? Per facilitare questa decisione, gli oggetti vengono assegnati a tre stadi diversi:
Attraverso header o intestazioni come Last modified (“modificato recentemente”) o Expires (“scade”) e la data corrispondente, i server web e proxy si informano sullo stato di un oggetto. Vengono usati anche altri header che p.es. indicano oggetti da non memorizzare temporaneamente.
Gli oggetti nella cache di solito vengono sostituiti a causa della mancanza di spazio di memoria attraverso algoritmi del tipo LRU (ingl. Last Recently Used) che sono stati concepiti per sostituire oggetti della cache. Il principio è quello di sostituire come primo gli oggetti meno richiesti.
Innanzitutto dovrebbe venire stabilito il carico massimo del sistema: a questo scopo, è importante dare più peso alle punte di carico del sistema, poiché queste possono essere di quattro volte maggiori della media giornaliera. In caso di dubbio, è consigliabile sopravvalutare queste esigenze, dato che uno Squid al limite delle sue prestazioni potrebbe comportare un notevole abbassamento della qualità del servizio.
Vi elencheremo ora i diversi requisiti di sistema in ordine di importanza.
Per memorizzare temporaneamente, la velocità investe un ruolo molto importante; badate quindi in particolare modo a questo fattore. Nei dischi rigidi, questo parametro è indicato come “tempo di posizionamento” espresso in millesimi di secondo. Una regola approssimativa: più basso è questo valore e meglio è.
Dato che Squid il più delle volte memorizza su o legge dal disco rigido piccoli blocchi di dati la velocità del disco è più rilevante che la velocità della trasmissione dei dati (throughput). Proprio in casi come questi vale la pena avere dei dischi rigidi con un numero di giri elevato che consentono di posizionare velocemente la testina del disco. Dischi SCSI veloci hanno ad esempio un tempo di accesso al di sotto di 4 millesimi di secondo.
Un altro espediente per aumentare la velocità di trasmissione dei dati consiste nell'usare contemporaneamente più dischi rigidi o Raid Array stripeS
La probabilità di un HIT (l'oggetto desiderato si trova già nella cache) in una cache piccola è molto scarsa, perché si riempirà molto velocemente. In questo caso, gli oggetti poco richiesti, vengono sostituiti da nuovi. Se la cache ha però a disposizione 1 Gbyte e gli utenti necessitano di 10 Mbyte al giorno per navigare su Internet, per riempire la cache occorreranno più di 100 giorni.
La dimensione della cache può venire facilmente determinata tramite la velocità di trasmissione massima del collegamento. Con un collegamento di 1Mbit/s il tasso di trasmissione massimo è di 125 Kbyte/s. Se il traffico completo dei dati arriva nella cache, entro un'ora avremo un totale di 450 Mbyte. Partendo dal presupposto che il completo traffico dei dati si svolga entro 8 ore di lavoro, in un giorno avremo “ raccimolato” 3,6 Gbyte. Poiché di solito il collegamento non viene sfruttato fino in fondo, possiamo partire dal presupposto che la quantità di dati che passa attraverso la nostra cache, sia di ca. 2 Gbyte. Nel nostro esempio, abbiamo bisogno di 2 Gbyte di memoria per Squid , allo scopo di tenere nella cache i dati di tutte le pagine visitate durante un giorno.
La memoria (RAM) necessaria a Squid dipende dal numero degli oggetti che si trovano nella cache. Affinché i dati possano venire richiesti più velocemente, Squid salva anche nella memoria i cache object pointer ed i dati richiesti più spesso. La RAM è molto più veloce del disco rigido!
Squid tiene in memoria anche molti altri dati, come p.es. una tabella con tutti gli indirizzi IP assegnati, una ben determinata cache per nomi di domini, gli oggetti più richiesti, buffer, ACL, etc.
E' molto importante avere sufficiente memoria per un processo Squid: se dovesse venire trasferito sul disco rigido, il rendimento del sistema verrebbe drasticamente ridotto. Per l'amministrazione della memoria della cache, vi è il tool cachemgr.cgi che tratteremo nella sezione Section 26.3.7, “cachemgr.cgi”.
Il programma Squid non ha bisogno di molta CPU. I picchi di carico per il processore si hanno solo all'avvio e durante il controllo del contenuto della cache. L'impiego di un computer multi-processore non aumenta la prestazione del sistema. Per aumentare l'effettività si devono usare dischi rigidi più veloci o aggiungere memoria.
Lo Squid su è già preconfigurato e può essere subito utilizzato ad installazione avvenuta. Premessa per un avvio senza complicazioni: la rete deve essere configurata in modo che siano raggiungibili almeno un server dei nomi ed Internet. Potrebbe essere problematico, se si utilizza un collegamento con una configurazione DNS dinamica: in questo caso, almeno il server dei nomi dovrebbe essere registrato in maniera permanente, poichè Squid non parte se non trova alcun server DNS in /etc/resolv.conf.
Per avviare Squid inserite (come root) nella riga di comando: rcsquid start. Al primissimo avvio, viene prima creata la struttura di directory in /var/squid/cache; ciò viene realizzato automaticamente dallo script di avvio /etc/init.d/squid e può durare un paio di secondi. Se sulla destra, viene visualizzato un done color verde, vuol dire che Squid è stato avviato correttamente. Sul sistema locale è possibile collaudare subito il funzionamento di Squid, immettendo nel browser come proxy localhost e 3128 quale porta.
Per permettere a tutti l'accesso a Squid, e quindi anche ad Internet, basta modificare nel file di configurazione /etc/squid.conf la registrazione da http_access deny all a http_access allow all. Tenete però presente che, in questo modo, aprite Squid a tutti; è quindi necessario definire delle ACL che regolano l'accesso al proxy. Per maggiori approfondimenti, vd. il paragrafo Section 26.3.5.2, “Opzioni per le ACL”.
Se si sono eseguite delle modifiche nel file di configurazione /etc/squid.conf , Squid dovrà rileggerle. Questo avviene con il comando: rcsquid reload. Alternativamente, potete riavviare Squid con: rcsquid restart.
Importante è anche questo comando: rcsquid status. Con esso si può stabilire se il proxy è in esecuzione, e con rcsquid stop si può fermare Squid. Questo può durare un po', poiché Squid aspetta fino ad un mezzo minuto (opzione shutdown_lifetime in /etc/squid.conf), prima di interrompere i collegamenti con i client e di scrivere i suoi dati sul disco rigido.
![[Warning]](admon/warning.png) | Terminare Squid |
|---|---|
Se chiudete Squid con un kill o killall, ciò può danneggiare la cache. Per riavviare Squid bisogna cancellarla completamente. | |
Se dopo un pò Squid si chiude, nonostante l' avvio sia apparentemente riuscito, questo può essere dovuto ad una registrazione del server dei nomi errata o alla mancanza di un /etc/resolv.conf. Squid protocolla nel file /var/squid/logs/cache.log la causa di un avvio fallito. Se Squid deve venire avviato automaticamente al boot, nell'editor dei runlevel di bisogna attivare Squid per i runlevel in questione.
Se disinstallate Squid, la cache e i file di log rimangono; dunque, si dovrà cancellare manualmente la directory /var/cache/squid.
Vale la pena configurare un server DNS locale anche se non si amministra alcun dominio: funge solo da “DNS caching-only” ed è anche in grado di risolvere, tramite il server dei nomi root, richieste DNS senza aver bisogno di una configurazione speciale. Per maggiori dettagli si veda la sezione Section 22.7.1, “Inizializzare il server dei nomi BIND”. Se lo si registra nel /etc/resolv.conf con l'indirizzo IP 127.0.0.1 per localhost, all'avvio Squid trova sempre un server dei nomi valido. Il server dei nomi del provider si dovrebbe registrare nel file di configurazione /etc/named.conf sotto forwarders con relativo indirizzo IP. Se avete un firewall in funzione, si deve fare attenzione che vengano fatte passare le richieste DNS.
Tutte le impostazioni del server proxy Squid devono venire eseguite nel file /etc/squid/squid.conf; per poter inizializzare Squid per la primissima volta, non è necessario eseguirvi alcuna modifica, ma, in un primo momento, è disdetto l'accesso ai client esterni. Il proxy è abilitato per localhost e, come porta, viene usata di norma 3128. Le opzioni sono documentate dettagliatamente con molti esempi nel file preinstallato /etc/squid/squid.conf. Quasi tutte le righe hanno all'inizio il segno di commento #, mentre, alla fine della riga, troverete le relative specificazioni. I valori indicati corrispondono quasi sempre ai valori preimpostati, cosicché l' eliminazione del carattere di commento, senza la modifica del parametro dell'opzione, non ha alcun effetto – fatte poche eccezioni. Si consiglia lasciare invariato l'esempio ed inserire l'opzione con il parametro modificato in una riga inferiore. In questo modo, si vedono i valori preimpostati e le modifiche.
| Adattare il file di configurazione a seguito di un update |
|---|---|
Se si esegue un aggiornamento di Squid si consiglia assolutamente di utilizzare il nuovo /etc/squid/squid.conf e di assumere solo le modifiche del file originario. Se tentate di continuare a utilizzare il vecchio file squid.conf correte pericolo che la configurazione non funzioni più, visto che le opzioni si modificano e se ne aggiungono delle nuove continuamente. | |
La porta sulla quale Squid si mette “in ascolto” per richieste dei client. E' preimpostata su 3128, ma viene usata anche 8080. Qui è possibile indicare più numeri di porte, divisi da uno spazio.
Qui è possibile indicare un proxy superiore come “parent ” (genitore), p.es. se si vuole o si deve usare il proxy del provider. Come nome host si registra il nome o l'indirizzo IP del proxy da usare e come type parent. Per proxy-port si digita il numero della porta che l'utente del parent indica anche per l'uso nel browser; nella maggior parte dei casi 8080. icp-port si può impostare su 7 o su 0 se non è nota la porta ICP del parent e non ne è stato concordato l'uso con il provider. Inoltre, dopo il numero della porta si deve anche indicare default e no-query, per impedire completamente l'uso del protocollo ICP. Dopo di ciò, nei confronti del proxy del provider, Squid si comporterà come un normale browser.
Questa registrazione indica il massimo di RAM usata da Squid per il caching. La preimpostazione è di 8 Mbyte.
La registrazione cache_dir indica la directory dove gli oggetti vengono archiviati sul disco rigido. I numeri posposti indicano lo spazio massimo utilizzabile in “Mbyte” e il numero quantità di directory nel primo e secondo livello. Il parametro ufs dovrebbe rimanere invariato. Nella directory /var/squid/cache sono preimpostati “100 Mbyte ” di memoria del disco rigido da occupare e vi possono venire create 16 sottodirectory che a loro volta contengono 256 directory. All'indicazione della memoria da utilizzare, si devono lasciare riserve sufficienti; ragionevoli i valori fra il 50 e al massimo 80% dello spazio disponibile. É bene essere molto prudenti con l'aumento della quantità delle directory, poiché troppe directory possono causare problemi di prestazione. Se esistono più dischi rigidi sui quali distribuire la cache, è possibile registrare diverse righe cache_dir .
Percorso per i file di log.
Percorso per i file di log.
Percorso per i file di log. Queste registrazioni indicano il percorso al file di protocollo di Squid . Di solito si lasciano invariate. Se Squid è molto carico, può essere consigliabile distribuire la cache e i file di log su diversi dischi rigidi.
Se si cambia la registrazione in on, si ottengono file di log leggibili. Alcuni programmi non riescono ad elaborarli correttamente.
Con questa registrazione è possibile mascherare nei file di log gli indirizzi IP per celare l'identità del client. Se qui viene registrato 255.255.255.0, l'ultima cifra dell'indirizzo IP viene impostata su zero.
Specificare qui la password che Squid debba usare per i login FTP anonimi. Alternativamente, potete indicare anche un indirizzo e-mail valido del vostro dominio, dal momento che alcuni server FTP ne verificano la validità.
Si tratta di un indirizzo e-mail al quale Squid invia una messaggio nel caso di un crollo inaspettato. Di default si ha webmaster.
Se si invoca squid -k rotate, Squid è in grado di ruotare i file di log memorizzati: i file vengono numerati in relazione alla loro quantità e, dopo aver raggiunto il valore indicato, il file più vecchio viene sovrascritto. Di norma, questo valore è impostato su 0, perché in l' archiviazione e l'eliminazione dei file log vengono eseguite da un job di cron configurato nel file /etc/logrotate/squid.
Con append_domain si può indicare quale dominio venga automaticamente aggiunto, se non se ne è indicato alcuno. Nella maggior parte dei casi, qui viene indicato il proprio dominio, dopo di ciò, per raggiungere il proprio server web è sufficiente indicare www nel browser.
Se si imposta questa registrazione su off, Squid rimuove dalle richieste HTTP, l'indirizzo IP o il nome del sistema del client.
Normalmente non è necessario modificare questi valori. Se si ha però una linea commutata, può succedere Internet risulti per un pò non accessibile: Squid si ricorda delle richieste andate a vuoto e si rifiuta di ripeterle, benché il collegamento con Internet sia nuovamente attivo. In questi casi, si possono impostare i minutes su seconds cosicchè, pochi secondi dopo la connessione, anche un Reload nel browser porta all'effetto desiderato.
Se si vuole evitare che Squid invii direttamente le sue richieste ad Internet, con la registrazione sopra citata, si può forzare l'impiego di un altro proxy, che deve prima essere stato registrato sotto cache_peer . Se si seleziona acl_name all, tutte le richieste vengono inoltrate direttamente al parent. Ciò può essere necessario se p.es. si utilizza un provider che prescrive l'uso del suo proxy o se il firewall non consente alcun accesso diretto ad Internet.
Squid offre un raffinato sistema per controllare l'accesso al proxy, che con le ACL si lascia configurare in modo versatile. Si tratta di elenchi di regole che vengono elaborate l'una dopo l'altra. Prima di usarle, le ACL vanno definite. Alcune ACL standard come all e localhost esistono già. Di per sé, la definizione di una ACL non ha ancora nessuna conseguenza: solo quando viene usata effettivamente, p.es. assieme a http_access, vengono applicate le regole definite.
Per essere definita una ACL ha bisogno di almeno tre dati: il nome <acl_name> che può venire scelto liberamente. Per <type> è possibile scegliere fra un numero di possibilità diverse che trovate nella sezione ACCESS CONTROLS in /etc/squid/squid.conf. Cosa indicare per <data> dipende dal tipo di ACL e può provenire anche da un file, p.es. con nome di computer, indirizzo IP o URL. Eccovi qui di seguito alcuni semplici esempi:
acl i-miei-navigatori srcdomain .mio-dominio.com acl insegnante src 192.168.1.0/255.255.255.0 acl studenti src 192.168.7.0-192.168.9.0/255.255.255.0 acl mezzogiorno time MTWHF 12:00-15:00
Con http_access viene stabilito chi possa usare il proxy e a cosa ha il permesso di accedere su Internet: devono venire indicate le ACL, localhost e all sono già stati definiti sopra, che con deny o allow blocca o consentono l'accesso. Qui è possibile creare una lista con parecchie registrazioni http_access che vengono elaborate dalla prima all'ultima; a seconda della registrazione, viene dato via libera o bloccato l'accesso all'URL richiesta. La registrazione http_access deny all dovrebbe sempre essere all'ultimo posto. Nel seguente esempio, localhost, il computer locale, può accedere liberamente a tutto, mentre gli altri non possono accedervi.
http_access allow localhost http_access deny all
Ancora un esempio, nel quale vengono usate le ACL definite prima: il gruppo insegnanti ha sempre accesso ad Internet, mentre il gruppo studenti vi può navigare solo da lunedì a venerdì e solo a mezzogiorno.
http_access deny localhost http_access allow insegnante http_access allow studenti mezzogiorno http_access deny all
Per motivi di maggior chiarezza, la lista con registrazioni http_access proprie dovrebbe venire inserita solo nello spazio previsto in /etc/squid.conf . Cioé fra il testo
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR # CLIENTS
ed il conclusivo
http_access deny all
Con questa opzione, è possibile indicare un “redirector ”, come, p.es., SquidGuard, che sia in grado di bloccare URL indesiderate. Assieme all' autenticazione proxy e le relative ACL, è possibile regolare in modo molto mirato l'accesso ad Internet da parte dei diversi gruppi di utenti. SquidGuard è un pacchetto a sé stante che va installato e configurato a parte.
Se si vuole che gli utenti si autenticano al proxy, si può indicare qui un programma adeguato, p.es. pam_auth . Con pam_auth, al suo primo accesso, l'utente ha una finestra di login nella quale deve inserire l'user ID e la password: oltre a ciò è necessario anche una ACL affinché possano navigare solo i client con login valido:
acl password proxy_auth REQUIRED http_access allow password http_access deny all
Quel REQUIRED dopo proxy_auth può anche essere sostituito con una lista di nomi di utenti autorizzati o il percorso che conduce ad una lista del genere.
In questo modo, è possibile far eseguire una richiesta 'ident' su tutti i client definiti tramite l'ACL, allo scopo di accertare l'identità del rispettivo utente. Se per <acl_name> si inserisce all , questo accertamento viene eseguito per tutti i client. A questo scopo, sui client deve girare un cosiddetto 'ident daemon'; per Linux, si può installare a questo proposito il pacchetto pidentd, per Windows esiste del software libero che può venire scaricato da Internet. Affinchè vengano ammessi solo i client la cui identità è stata accertata, deve venire definita una apposita ACL:
acl identhosts ident REQUIRED http_access allow identhosts http_access deny all
Anche qui REQUIRED può venire sostituito da un elenco di user ID consentiti. L'uso di Ident può rallentare notevolmente l'accesso, poiché l' identità viene accertata ad ogni richiesta.
Normalmente il browser web invia richieste ad una determinata porta del server proxy ed il proxy mette a disposizione gli oggetti richiesti, sia che si trovino nella cache o meno. All'interno di una rete vera possono verificarsi diverse situazioni:
Per ragioni di sicurezza è bene che tutti i client usino un proxy per navigare su Internet.
E' necessario che tutti i client utilizzino - consapevolmente o meno - un proxy.
Il proxy è stato trasferito da un'altra parte all'interno della rete, ma i client esistenti devono mantenere la loro vecchia configurazione.
In ognuno di questi casi, può venire impiegato un proxy trasparente. Il principio è molto semplice: il proxy riceve le richieste del browser web e le elabora, cosicchè il browser web riceve le pagine richieste senza sapere da dove provengono. Tutto il processo viene eseguito in modo trasparente; da qui il nome del procedimento.
Prima assicuratevi che il kernel del server proxy supporti il proxing trasparente. Il kernel di è stato configurato in tal senso. Altrimenti dovete aggiungere questa opzione al kernel e ricompilarlo. Informazioni più precise a riguardo nel capitolo Chapter 8, Il kernel Linux.
Nel file /etc/squid/squid.conf devono essere abilitate le seguenti opzioni per avere un proxy trasparente:
httpd_accel_host virtual
httpd_accel_port 80 # Porta sulla quale si trova il vero server HTTP.
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
Tutte le richieste in arrivo che attraversano il firewall devono essere inoltrate, in base ad una regola di inoltro valida per le porte, alla porta Squid.A questo scopo, viene usato un tool fornito a corredo: SuSEfirewall2, il cui file di configurazione si trova in /etc/sysconfig/SuSEfirewall2. Il file di configurazione è composto da registrazioni ben documentate. Anche se intendete configurare solo un proxy trasparente, dovete configurare alcune opzioni inerenti al firewall, p.es.:
Dispositivo che punta su Internet: FW_DEV_EXT="eth1"
Dispositivo che punta sulla rete: FW_DEV_INT ="eth0"
Alle porte ed ai servizi (vd. /etc/services) dietro il firewall accedono delle reti inaffidabili come Internet. Nel seguente esempio, offriamo solo servizi web verso l'esterno:
FW_SERVICES_EXT_TCP="www"
Alle porte ed ai servizi (vd. /etc/services) sul firewall si accede da reti sicure, sia TCP che UDP.
FW_SERVICES_INT_TCP="domain www 3128"
FW_SERVICES_INT_UDP="domain"
Accediamo ai servizi web e a Squid (la cui porta standard è 3128). Il servizio sopra descritto “Domain” sta per DNS o Domain Name Server: è usuale utilizzarlo. Diversamente toglietelo dalla registrazione di cui sopra e impostate l'opzione su no:
FW_SERVICE_DNS="yes"
L'opzione più importante è la cifra 15:
Example 26.1. Opzione 15 della configurazione del firewall
# # 15.) # Quale accesso ai singoli servizi deve venire reindirizzato ad una # porta locale sul computer firewall? # # Con ciò, tutti gli utenti esterni possono venire costretti a # navigare tramite lo Squid Proxy oppure è possibile reindirizzare in # maniera trasparente il traffico web entrante ad un server web # sicuro. # # Scelta: non eseguire alcuna registrazione o usare la sintassi # delle regole di reindirizzo spiegata qui di seguito e divisa da # uno spazio vuoto. Una regola di reindirizzo consiste in 1) # IP/rete di origine, 2) IP/rete meta, 3) porta meta originaria e # 4) porta locale alla quale deve venire reindirizzato il traffico, # separato da virgole, p.es. "10.0.0.0/8,0/0,80,3128 # 0/0,172.20.1.1,80,8080" #
Nel commento sopra riportato, viene mostrata la sintassi da rispettare. Prima accedono gli indirizzi IP e la scheda di rete delle “reti interne” al firewall di proxy: quindi gli indirizzi IP e le maschere di rete ai quali i client inviano le richieste. Nel caso dei browser, stabiliamo le reti 0/0; si tratta di una wildcard e significa “dappertutto”. Segue la porta “originale”, alla quale sono state spedite queste richieste, e, infine, segue la porta a cui sono state reindirizzate le richieste.
Dal momento che Squid non supporta solo il protocollo HTTP, potete deviare al proxy anche le richieste da altre porte, come FTP (porta 21), HTTPS o SSL (porta 443).
Concretamente, i servizi web (Port 80) vengono reindirizzati alla porta del proxy (in questo caso: 3128). Qualora vogliate aggiungere altre reti o servizi, dovrete separarli con uno spazio nella riga corrispondente.
FW_REDIRECT_TCP="192.168.0.0/16,0 /0,80,3128 192.168.0.0/16,0/0,21,3128"
FW_REDIRECT_UDP="192.168.0.0/16,0 /0,80,3128 192.168.0.0/16,0/0,21,3128"
Per inizializzare il firewall e la nuova configurazione, dobbiamo editare una registrazione nel file /etc/sysconfig /SuSEfirewall2. La registrazione START_FW deve venire impostata su "yes":
Lanciate Squid come descritto nella sezione Section 26.3.4, “Avviare Squid”. Grazie ai file di log in /var/log/squid/access.log si può verificare se tutto funziona nel modo dovuto. Per controllare se tutte le porte sono state configurate correttamente, si può eseguire un port scan dell' host – da un qualsiasi computer al di fuori della nostra rete. Solo la porta di servizio web (80) dovrebbe essere aperta. Il port scan si effettua nmap -O indirizzo IP.
Il cache manager (cachemgr.cgi) è un programma di aiuto CGI per l'emissione di statistiche sulla memoria necessaria dal processo Squid in esecuzione. Al contrario del logging, la cosa facilita l'amministrazione della cache e la visualizzazione di statistiche.
Per prima cosa, è necessario sul sistema un server web funzionante. Per sapere se Apache è già in funzione, dobbiamo inserire come utente root: rcapache status.
Se appare una comunicazione come la seguente:
Checking for service httpd: OK Server uptime: 1 day 18 hours 29 minutes 39 seconds
vuol dire che Apache gira sul nostro computer; altrimenti immettete: rcapache start. Così Apache viene lanciato con le impostazioni di default di .
Infine, dobbiamo copiare il file cachemgr.cgi dalla directory/usr/share/doc/packages/squid/scripts/ nella directory srv/www/cgi-bin di Apache:
Le seguenti impostazioni standard sono necessarie per il cache manager:
acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255
Dovrebbero essere contenute le seguenti regole:
http_access allow manager localhost http_access deny manager
La prima ACL è la più importante, poiché il cache manager cerca di comunicare con Squid tramite il protocollo cach_object. Le seguenti regole partono dal presupposto che il server web e Squid girino sullo stesso computer. La comunicazione fra il cache manager e Squid origina nel server web e non nel browser. Se quindi il server web si trova su un altro computer, dobbiamo aggiungere appositamente una ACL come nel seguente file esempio Example 26.2, “Regole di accesso”.
Example 26.2. Regole di accesso
acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl webserver src 192.168.1.7/255.255.255.255 # IP server web
Inoltre servono le seguenti regole del file Example 26.3, “Regole di accesso”.
Example 26.3. Regole di accesso
http_access allow manager localhost http_access allow manager webserver http_access deny manager
Se vogliamo accedere a più opzioni (p.es. chiudere la cache da remoto o visualizzare altre informazioni sulla cache), possiamo anche configurare una password per il manager; allora servirà una password per configurare la registrazione cachemgr_passwd e la lista delle opzioni da visualizzare. Questa lista appare in /etc/squid/squid.conf come parte dei commenti delle registrazioni.
Ad ogni modifica del file di configurazione, bisogna riavviare Squid con il comando rcsquid reload
Andate alla relativa pagina web, p.es.:http://webserver.example.org/cgi-bin/cachemgr.cgi. Premete su e fatevi mostrare le diverse statistiche. Nelle FAQ di Squid, http://www.squid-cache.org/Doc/FAQ/FAQ-9.html troverete ulteriori informazioni sulle singole registrazioni che vengono emesse dal cache manager.
Questo capitolo vuole solo essere una introduzione alla configurazione di SquidGuard e darvi un paio di consigli sul suo impiego. Troverete informazioni più dettagliate sulle pagine web di SquidGuard: http://www.squidguard.org
SquidGuard è un filtro libero (GPL), flessibile e velocissimo, che si occupa di reindirizzare determinati contenuti ed è un “PlugIn” preposto ai controlli di accesso per Squid: permette, per una cache Squid, la definizione di una quantità di regole di accesso con diverse restrizioni per diversi gruppi di utenti. Per reindirizzare, SquidGuard utilizza l'interfaccia standard di Squid. squidGuard può anche venire utilizzato per:
limitare l'accesso via Internet a determinati server web e/o URL accettati/conoscuiti per alcuni utenti.
negare l'accesso ad alcuni utenti a determinati server web e/o URL.
negare l'accesso ad URL ad utenti che usano determinate espressioni regolari o termini.
reindirizzare URL bloccati a una pagina info “intelligente ” basata su CGI.
reindirizzare gli utenti non registrati ad un modulo di registrazione.
reindirizzare i banner in un GIF vuoto.
differenti regole di accesso, dipendenti dall'orario, giorno, data, etc.
differenti regole per i singoli gruppi di utenti.
Né con squidGuard, né con Squid è possibile:
filtrare/censurare/editare il testo dei documenti
filtrare/censurare/editare linguaggi di scripting HTML-embedded come JavaScript o VBscript.
Installate il squidGuard. Editate il file di configurazione /etc/squidguard.conf . Sotto http://www.squidguard.org/config/ troverete numerosi esempi di configurazione. Più avanti potrete sperimentare con configurazioni più complesse.
Il prossimo passo consiste nel creare una pagina dummy “accesso negato” o, se il client richiede una pagina web proibita, creare una pagina CGI più o meno complessa per reindirizzare Squid. Anche qui vi consigliamo di utilizzare Apache.
Ora dobbiamo comunicare con Squid di impiegare squidGuard. A questo scopo, usiamo nel file /etc/squid/squid.conf le seguenti registrazioni:
redirect_program /usr/bin/squidGuard
Un'altra opzione di nome redirect_children configura la quantità dei diversi “redirect”, quindi processi di reindirizzo in esecuzione sul sistema, in questo caso squidGuard. SquidGuard è abbastanza veloce da elaborare una quantitàconsiderevole di richieste, è veramente veloce: 100.000 richieste in 10 secondi su un Pentium di 500MHz con 5900 domini, 7880 URL, in totale 13780. Perciò consigliamo di non stabilire più di 4 processi, poiché l'attribuzione di questi processi consuma inutilmente tanta memoria.
redirect_children 4
Per concludere, fate caricare la nuova configurazione di Squid: rcsquid reload. Ora potete testare le vostre impostazioni su un browser.
Calamaris è uno script Perl che viene usato per creare rapporti sull' attività della cache in formato ASCII o HTML. Lavora con file di protocolli di accesso propri di Squid. La home page di Calamaris è http://Calamaris.Cord.de/. Il programma è semplice da usare, fate il login come root ed inserite quanto segue: cat access.log.files | calamaris options > reportfile.
Quando concatenate più file di protocollo, è importante osservare la sequenza cronologica, ovvero prima vengono i file più vecchi. Le diverse opzioni:
output di tutti i report disponibili
output come HTML report
messaggio o un logo nell'intestazione del report.
Nella pagina di manuale di calamaris, man calamaris, troverete altre informazioni sulle diverse opzioni.
Un altro strumento potente per la creazione di rapporti sulla cache è SARG (Squid Analysis Report Generator). Per maggiori informazioni a riguardo, consultate il sito Internet: http://web.onda.com.br/orso/
Visitate la home page di Squid: http://www.squid-cache.org/. Qui troverete la “Squid User Guide” e una vasta raccolta di FAQ su Squid. Il mini HOWTO per un proxying trasparente del pacchetto howtoen lo trovate dopo il processo di installazione sotto: /usr/share/doc/howto/en/mini/TransparentProxy.gz
Inoltre esistono mailing list per Squid sotto: squid-users@squid-cache.org. L'archivio relativo si trova sotto: http://www.squid-cache.org/mail-archive/squid-users/.
