Linux tips and tricks/Transparent proxy

Con l'espressione transparent proxy si intende il filtraggio e l'eventuale blocco o redirezione dei pacchetti TCP/IP finalizzato a particolari obiettivi, fra cui:

• proteggere i minori dal rischio di imbattersi in siti dedicati alla pornografia, alla violenza, al gioco d'azzardo e altro (il cosiddetto parental control)
• impedire al personale di un'azienda o di un ente di perdere tempo frequentando siti non connessi con l'attività lavorativa
• migliorare l'utilizzo della banda disponibile, bloccando l'accesso a siti non connessi con l'attività lavorativa

Per realizzare obiettivi simili è necessario dirottare tutte le richieste HTTP in uscita verso un software che, in base a determinati criteri, stabilisce se il sito destinazione può essere raggiunto o se la richiesta debba essere bloccata. Naturalmente questo dirottamento ha senso solo se è coercitivo: se l'utente di cui si vuole limitare l'attività di navigazione in questo modo dispone di credenziali amministrative, potrebbe disattivare senza problemi il sistema di filtraggio sulla sua postazione.

In questo wikibook sono illustrate le nozioni teoriche di base e due diverse soluzioni concrete per realizzare facilmente simili obiettivi.

Nozioni preliminari

Gli ingredienti che permettono di realizzare gli obiettivi sopra elencati sono, in definitiva:

• un insieme di blacklist che elenchino i siti e le URL da bloccare o meno, ma anche frasi che, trovate in una pagina, facciano sì che essa sia bloccata
• un software di filtraggio, o url rewriter, che, servendosi delle blacklist, possa dirottare una richiesta verso una pagina prestabilita oppure lasciarla passare
• un software proxy, che si occupa essenzialmente di passare le URL al software di filtraggio oppure, quando è lo stesso software di filtraggio a ricevere le richieste direttamente, a inoltrarle verso l'esterno
• la utility iptables, utilizzata per definire le regole che, in maniera trasparente, dirottano tutto il traffico web attraverso il proxy o il software di filtraggio, indipendentemente dalla volontà degli utenti
• il supporto Netfilter nel kernel, necessario alla utility iptables, almeno per quanto riguarda una serie di funzionalità

Nelle sezioni seguenti vengono illustrati più dettagliatamente tutti questi elementi.

Le blacklist

Il sito del software di filtraggio squidGuard, illustrato più avanti, elenca alcune fonti di blacklist, sia gratuite che commerciali. Per cominciare la cosa migliore è fare riferimento alla prima fonte (MESD), liberamente scaricabili e distribuibili.

Le blacklist elencano di solito anche centinaia di migliaia di URL e domini, raggruppate per temi. Ovviamente i file sono compressi, ma vanno decompressi per poterli usare con il programma di filtraggio. La directory in cui vanno decompressi dipende dal programma che si userà, ma esso di solito può essere configurato in modo da cercare le blacklist in una specifica directory, per cui in teoria possono essere collocate dove più si preferisce, ma non avrebbe molto senso metterle dove gli utenti potrebbero manipolarle per sbloccare i siti che vogliono raggiungere...

Le blacklist sono quasi sempre di due tipi per ciascun raggruppamento: domains e urls. Vediamo più da vicino perché questa suddivisione.

Se un dominio, diciamo pippo.com, è bloccato perché elencato fra i domains di una certa blacklist, sono bloccate implicitamente anche URL come pippo.com/paperino o pippo.com/paperone, e qualunque altra URL del dominio pippo.com. Ma ci sono domini che non è opportuno bloccare, come aruba.com, che offrono però agli utenti iscritti la possibilità di creare delle pagine che invece andrebbero bloccate. A questo scopo servono le liste di tipo urls, che permettono di bloccare URL del tipo aruba.com/~pippo/adults/ senza bloccare aruba.com, che di per sé non è un sito da bloccare a priori.

Ad esempio, ecco alcune righe del file porn/domains delle blacklist MESD già citate.

64.90.37.162
65.110.38.162
66.197.38.162
64.237.38.162
...
asianpornofilm.be
asianpost.be
asianseksfilms.be
asiansex.be
...

Come si vede, possono essere sia indirizzi numerici che alfabetici. Per inciso, questo solo file definisce quasi un milione di domini da bloccare.

Dalle stesse blacklist, ecco invece alcune URL ricavate dal file porn/urls:

amazon.com/5-Star-Nudity-on-DVD/lm/R2152H68D2NTKY
amazon.com/Afterburn-Novel-Zane/dp/product-description/0743470974
amazon.com/Cybersex-Anna-Malle/dp/B00004CUMK
amazon.com/Great-Upskirt-moments-on-DVD/lm/R2ULICG4T7UDCI

Bloccare il dominio amazon.com sarebbe assurdo, vista la sua importanza. Ma siccome Amazon consente ai suoi utenti iscritti di pubblicare materiale pornografico, con un elenco di URL è possibile bloccare l'accesso a questo materiale senza bloccare l'accesso ad Amazon.

Le dimensioni notevoli delle liste obbligano i software di rewriting a gestirle in forma indicizzata. I due software discussi nel seguito utilizzano il formato DB (cioè il Berkeley Database).

Naturalmente, se le blacklist vengono modificate per sbloccare dei siti o per bloccarne di nuovi, il comando va eseguito nuovamente. Ma questo di solito si fa solo quando si installa una versione aggiornata delle blacklist.

Un tipo di blacklist alquanto diverso comprende liste di frasi che, se presenti in una pagina, possono determinare il blocco della stessa. Questo tipo di liste può essere di carattere dinamico, nel senso che l'url rewriter può essere istruito a servirsi di fonti esterne per dare un punteggio ad una pagina in base alle frasi che contiene. Ovviamente servizi di questo genere possono rallentare la navigazione.

Un ulteriore tipo di liste sono le greylist, che permettono di bloccare solo alcune parti di un sito o di una URL, anche se in maniera piuttosto complicata.

Infine, si possono definire liste di URL o domini in base a delle espressioni regolari, offrendo così uno strumento molto fine per il blocco dinamico di certe pagine.

Naturalmente non tutti i software di url rewriting offrono l'intero ventaglio di potenzialità, ma a seconda di quello che si vuole fare ci si può limitare a funzioni molto elementari, o ricorrere a soluzioni più complesse.

L'url rewriter

Questo software si occupa di riscrivere una URL, sostituendola con un'altra opportuna. Il risultato è in pratica il dirottamento di certe richieste verso una o più pagine predefinite. Tipicamente, l'utente viene deviato su una pagina recante un messaggio del tipo spiacente, il sito che volevi raggiungere non sembra collegato agli interessi dell'Azienda, o qualcosa del genere.

La riscrittura delle richieste HTTP può avvenire in due modi:

• l'url rewriter è invocato come sottoprocesso dal proxy stesso allo scopo di riscrivere la URL: il proxy si limiterà a puntare a questa nuova URL, senza curarsi di altro
• l'url rewriter riceve direttamente la richiesta dallo stack TCP/IP, la riscrive se lo ritiene necessario, e in ogni caso passa la URL originale o quella riscritta al proxy perché sia inoltrata all'esterno

In ogni caso il proxy prende per buona la URL ricevuta dall'url rewriter, sia che il proxy stesso abbia invocato l'url rewriter come sottoprocesso, sia che il proxy riceva direttamente via rete dall'url rewriter la URL riscritta.

Un esempio relativo al primo caso è squidGuard: esso non è un servizio di rete, bensì un eseguibile che, tipicamente, viene invocato dal proxy squid col quale si integra molto bene.

Un esempio relativo al secondo caso è invece DansGuardian: esso è un servizio di rete che si frappone in sostanza fra il browser e il proxy.

Il proxy

I proxy sono una categoria di software molto ampia, per cui in questo contesto saranno necessarie alcune grossolane semplificazioni per non divagare troppo. Basterà pensare al proxy come a uno strato software che si interpone, in modo appunto trasparente, fra il browser e la rete. Ma non è un semplice passa-carte, perché prima di inoltrare nella rete le richieste che ha ricevuto dal browser, può decidere di fare diverse cose con queste richieste. Potrebbe essere egli stesso a riscrivere le URL, ma si tratta di un compito estremamente particolare che richiede un software specifico, e quindi i proxy sono di solito una parte di un'architettura in cui un'altra componente si occupa del rewriting.

Due proxy molto diffusi sono squid e tinyproxy. Il primo offre una notevole varietà di funzioni, per lo più inutili per gli obiettivi di questo testo, ma è anche molto stabile e supportato. Tinyproxy è molto veloce, richiede risorse limitate, ma è anche limitato nelle funzioni e non brilla per documentazione. A voi la scelta.

Netfilter e il kernel

Come si è già detto, la riscrittura o redirezione delle richieste HTTP, per gli scopi elencati nell'introduzione, ha senso solo se attuata in maniera coercitiva. GNU/Linux permette di riscrivere in maniera trasparente le richieste HTTP per qualsiasi utente tramite opportune regole impostate con il comando iptables che vedremo più avanti. Questo comando è però solo un'interfaccia per consentire a un amministratore di impostare delle regole che, per loro natura, valgono a livello del kernel, e modificano il modo in cui lo stack TCP/IP, gestito appunto dal kernel, reagisce a determinate situazioni.

È quindi necessario che il kernel stesso sia compilato includendo una serie di moduli che permettono poi di usare iptables per definire le regole indispensabili agli scopi oggetto di questa pagina. I moduli in questione sono tutti nell'albero di opzioni di configurazione del kernel che parte dal nodo Networking support / Networking options / Network packet filtering framework (Netfilter), almeno per quanto riguarda il kernel 2.6.30 contemporaneo a questa pagina. Netfilter è proprio il nome del progetto che sviluppa tutti gli strumenti a livello di kernel per la manipolazione avanzata dei pacchetti TCP/IP, la cui controparte a riga di comando è appunto iptables.

Le opzioni da impostare si trovano nel sottoramo Core Netfilter Configuration, ma alcune di esse sono disponibili solo se è stato anche impostata l'opzione Advanced netfilter configuration, allo stesso livello.

La prima delle opzioni necessarie è NETFILTER_XTABLES. Essa è spesso impostata automaticamente a seguito dell'attivazione di altre opzioni che non è qui opportuno elencare. Ma se nessuna di queste è impostata, NETFILTER_XTABLES può essere impostata espressamente, tramite la voce Netfilter Xtables support (required for ip_tables).

Quando questa opzione è selezionata, dovrebbero essere visibili anche tutte le ulteriori opzioni ad essa subordinate. Non è una cattiva idea selezionarle tutte, magari come moduli per caricare in memoria solo quelli necessari. Di certo va selezionato il modulo owner, indispensabile nelle situazioni in cui il proxy si trova sullo stesso host da cui provengono le richieste HTTP: in questo caso, infatti, lo stesso host deve sia intercettare richieste per la porta 80 (la caratteristica porta HTTP), sia creare egli stesso richieste HTTP da mandare all'esterno, ma che finirebbero a loro volta intercettate! L'unico modo per uscire da questo circolo vizioso è filtrare tutte le richieste HTTP, eccetto quelle prodotte dall'utente che esegue il software di proxy, e per questo è necessario il supporto degli utenti del sistema locale a livello di Netfilter, come apparirà più chiaro nella prossima sezione.

Prima soluzione: squid e squidGuard

Si illustra ora una prima soluzione basata su squid e squidGuard, rispettivamente come proxy e url rewriter. In questa soluzione, al di là delle caratteristiche e funzionalità dei due software, la cosa interessante è che squidGuard è invocato da squid come un qualunque comando, per cui squidGuard in effetti non partecipa della stack TCP/IP.

Configurazione di squidGuard

Cominciamo dal filtratore squidGuard che, come già ricordato più volte, è una utility a riga di comando, non un servizio di rete. Vedremo poi come configurare squid per invocarlo.

Un esempio essenziale di file di configurazione di squidGuard (/etc/squid/suidGuard) è il seguente:

dbhome /var/lib/squidGuard/db
logdir /var/log/squid/squidGuard.log

dest porn {
       domainlist porn/domains
       urllist porn/urls
       }

acl {
       default {
               pass !porn all
               redirect http://localhost/block.html
       }
}

La prima riga specifica la posizione delle blacklist decompresse, mentre la seconda riga specifica la posizione in cui saranno registrati i log di squidGuard.

Il blocco successivo definisce una destinazione, da intendere come un raggruppamento di URL e domini distinto dal altri per qualche caratteristica. Nel caso specifico, si volevano distinguere i siti porno, creando una dest di nome appunto porn. Nel blocco, la dichiarazione domainlist indica la blacklist per i domini da bloccare, mentre la dichiarazione urllist indica la blacklist per le URL. I valori usati sono percorsi relativi al percorso dbhome definito all'inizio del file.

Di volta in volta che, nella configurazione di squidGuard, si fa riferimento ad una nuova blackist, bisogna indicizzarla, convertendola nel formato db del Berkeley Database. A questo scopo si usa il comando:

# squidGuard -C all

Dopo questa operazione è molto importante assicurarsi che il proprietario dei file, sia in formato testo che in formato db, sia l'utente che esegue squid. Se qualche file non ha il proprietario giusto, squid va in emergency mode, e il rewriting delle url non avviene, rendendo tutta l'operazione del tutto inutile. Per sicurezza, quindi, tanto vale eseguire il comando:

# chown -R proxy /var/lib/squidguard/db

ovviamente modificando l'utente e la directory in base alla propria installazione.

È possibile, nonché opportuno prima di procedere, verificare la validità della configurazione di squidGuard simulando l'accesso ad una delle URL o dei domini bloccati. Ad esempio, il comando seguente simula esattamente quello che avverrebbe se il proxy, di cui parleremo più avanti, segnalasse a squidGuard una particolare URL per sapere se bloccarla o meno:

echo "http://www.example.com 10.0.0.1/ - - GET" | squidGuard -c /etc/squid/squidGuard.conf -d 

Come si vede, tramite il comando echo si invia a squidGuard sullo standard input una semplice chiamata HTTP, che comprende la URL richiesta (www.example.com), l'indirizzo del richiedente (10.0.0.1), un paio di valori default (i due trattini) e il tipo di richiesta (in questo caso una GET, la più tipica). Dal canto suo, squidGuard userà il file di configurazione visto sopra (opzione -c) e dirotterà qualsiasi errore sullo standard error (opzione -d).

Nel caso dell'esempio, dal momento che www.example.com probabilmente non esiste, non dovrebbe essere bloccato da squidGuard, e il risultato del comando sopra dovrebbe essere una serie di righe di cui le ultime tre dovrebbero somigliare alle seguenti:

2009-11-01 11:43:35 [24325] squidGuard ready for requests (1257072215.651)

2009-11-01 11:43:35 [24325] squidGuard stopped (1257072215.687)

La riga vuota è significativa: rappresenta l'eventuale URL sostitutiva di quella inviata a squidGuard, e nel caso specifico sta a indicare che squidGuard non ha ritenuto di dover riscrivere la URL che ha ricevuto. Il seguente comando:

echo "http://www.playboy.com 10.0.0.1/ - - GET" | squidGuard -c /etc/squid/squidGuard.conf -d 

in tutto identico al precedente salvo per la URL, illustra il caso in cui la URL ricevuta viene riscritta da squidGuard secondo la regola definita nel file di configurazione sotto la stanza acl:

2009-11-01 11:43:50 [24337] squidGuard ready for requests (1257072230.781)
http://localhost/blocked.html 10.0.0.1/- - -
2009-11-01 11:43:50 [24337] squidGuard stopped (1257072230.810)

La richiesta HTTP ricevuta è stata sostituita, in questo caso, con quella indicata nella seconda riga.

Se squidGuard si comporta come appena visto, la configurazione si può ritenere corretta. Allo stesso modo, in caso siano definite altre dest e relative acl nel file di configurazione, è possibile effettuare test analoghi.

Configurazione di squid

Praticamente c'è solo una riga da aggiungere al file di configurazione /etc/squid/squid.conf:

 url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

Questa riga informa squid di passare a squidGuard tutte le URL che ha ricevuto, per permettergli di sostituire con altre tutte quelle che si ritiene di dover bloccare. Naturalmente, usando altre versioni o distribuzioni di squidGuard, i percorsi usati nella riga sopra possono essere diversi.

Se tutto è configurato correttamente, riavviando il servizio squid si dovrebbe poter testare facilmente la configurazione impostando il proxy a livello dell'account dell'utente. Con Gnome, questo si può fare col comando gnome-network-preferences, eseguibile anche dal menù Preferenze. Il proxy va impostato come localhost sulla porta 3128, quella su cui squid è in ascolto. In questo modo, usando un browser web qualunque, ogni richiesta del browser verrà dirottata automaticamente a squid, che poi invocherà squidGuard per decidere come comportarsi.

Gli esempi fatti per testare la configurazione di squidGuard si possono ripetere per quella di squid. Se sul localhost non è attivo un server web, la pagina http://localhost/blocked.html vista sopra ovviamente non esiste, e in questo si avrà una pagina di errore.

Regole iptables per squid

A questo punto è possibile illustrare la più elementare regola di redirezione che, in situazioni normali, permette di deviare tutte le richieste HTTP dirette all'esterno verso il proxy squid (che poi invoca squidGuard per l'url rewriting). La regola viene impostata col comando seguente:

# iptables -t nat -A OUTPUT --dport www -m owner ! --uid-owner proxy -j REDIRECT --to-ports 3128

L'opzione -t nat indica che si vuole aggiungere una regola alla tabella nat, quella dedicata al Network Address Translation. È proprio in questa tabella che si può stabilire quali servizi devono essere eventualmente deviati e su quali altri (oltre a moltissime altre cose).

L'opzione -A OUTPUT permette di specificare, all'interno della tabella nat, a quale catena si vuole aggiungere la regola. In questo caso interessa la catena di OUTPUT, che riguarda tutti i pacchetti in uscita.

L'opzione --dport www specifica che la regola si applica ai pacchetti HTTP. Pertanto, fino a questa opzione, si è stabilito semplicemente che la regola si applica a tutti i pacchetti HTTP in uscita dall'host su cui è stata impostata la regola (in sostanza localhost).

Prima di spiegare le altre due opzioni prima dell'opzione -j, vediamo proprio quest'ultima, che definisce il target della regola, cioè quello che deve accadere dei pacchetti che, finora, sono solo stati selezionati fra tanti altri. Come si può intuire, le opzioni -j REDIRECT --to-ports 3128 specificano che tutti i pacchetti corrispondenti alle condizioni definite nella prima parte della regola devono essere deviati verso la porta local 3128. Su questa porta, come visto nelle sezioni precedenti, è in ascolto il proxy squid che, servendosi di squidGuard, deciderà se e dove reindirizzare determinare richieste HTTP.

Come accennato a proposito di Netfilter, a questa regola non sfuggono i pacchetti HTTP prodotti dallo stesso squid, per cui si creerebbe un circolo vizioso dal quale non uscirebbe più alcun pacchetto HTTP: da localhost sarebbe impossibile navigare sul web.

Il rimedio è contenuto nelle due opzioni ancora lasciate da parte: -m owner ! --uid-owner proxy.

La prima segnala che è necessario caricare il modulo owner del kernel, in modo da permettere l'utilizzo di alcune ulteriori opzioni di iptables, fra cui proprio --uid-owner. Così come riportata nella regola sopra, questa opzione aggiunge una condizione particolare per selezionare i pacchetti HTTP in uscita: essi non devono essere stati prodotti dall'utente proxy. Se, come avviene nella configurazione di squid per Debian Lenny, proxy è proprio l'utente che esegue squid, in questo modo ai pacchetti prodotti da squid non sarà applicato il target della regola, e quindi, se non intervengono altre regole a bloccarli, usciranno regolarmente permettendo all'utente di navigare tranquillamente.

Seconda soluzione: tinyproxy e DansGuardian

Viene ora illustrata una seconda soluzione, basata su due software alquanto diversi da squid e squidGuard: tinyproxy e DansGuardian, a cui si è già accennato anche in un certo dettaglio nelle sezioni precedenti.

Fra le varie limitazioni di tinyproxy, volute per privilegiare le prestazioni, c'è anche l'impossibilità di invocare un url rewriter come fa invece squid. Quindi tinyproxy deve essere usato insieme ad un url rewriter che sia esso stesso un servizio di rete, non una utility a riga di comando. Qui interviene DansGuardian, che è un servizio di rete.

In breve, il traffico web va dirottato con una regola iptables verso DansGuardian, il quale analizza ogni richiesta HTTP e decide se riscriverla o meno, per poi passarla via rete a tinyproxy perché provveda a trasmettere la richiesta all'esterno.

Configurazione di DansGuardian

Per configurare DansGuardian occorre innanzitutto aggiungere le tre righe seguenti in fondo al file /etc/dansguardian/dansguardian.conf:

filterport = 8080
proxyport  = 3129
proxyip    = 127.0.0.1

La prima porta è quella su cui DansGuardian si mette in ascolto, e ovviamente sarà necessario dirottare il traffico web verso questa porta con un'opportuna regola NetFilter. La seconda porta è quella su cui è in ascolto tinyproxy, che provvede a inoltrare le richieste HTTP che DansGuardian ritenesse di non bloccare. L'ultima opzione potrebbe richiedere altri valori: il valore indicato significa che tinyproxy lavora sulla loopback device, il che non è certo corretto se l'host deve servire da proxy ad altre postazioni.

Occorre poi istruire DanGuardian su quali richieste HTTP bloccare. Rispetto a squidGuard, DansGuardian ha qualche possibilità in più: oltre al tipico meccanismo basato su blacklist, si può bloccare una pagina analizzandone in tempo reale il contenuto, alla ricerca di parole particolari. Questa possibilità è impostata per default nel pacchetto Debian, grazie alla riga:

weightedphrasemode = 2

in cui il valore 2 fa in modo che una frase pesata sia conteggiata una sola volta per ciascuna pagina, anche se compare più volte. Un valore 1 aumenterebbe il peso di una frase in base al numero di occorrenze nella pagina, mentre un valore 0 disabilita completamente questo tipo di blocco.

Il resto delle configurazioni, in condizioni normali, può rimanere inalterato, ma è bene sapere che, a differenza di squidGuard che ha un unico file di configurazione, DansGuardian fa riferimento a diversi altri file, fra cui:

/etc/dansguardian/dansguardianfN.conf

Al variare di N, questi file contengono le impostazioni relative a diversi gruppi di filtri. Come squidGuard usa le stanze dest e acl nel suo file di configurazione per stabilire cosa, come e per chi bloccare, così DansGuardian usa distinti file di configurazione per ottenere lo stesso scopo. Il risultato è certamente un controllo molto fine, ma anche alquanto complicato. In situazioni normali basta un solo filtro, e quindi un solo file di questo tipo. All'interno di simili file, tramite parametri abbastanza autoesplicativi, si definiscono una serie di opzioni fra cui i file da cui ricavare le URL e i domini da bloccare. Rispetto a squidGuard, DansGuardian è più sofisticato anche perché permette di gestire whitelist e greylist, ma anche in questo caso il prezzo da pagare è una configurazione certamente più complessa.

/etc/dansguardian/lists/bannedurllist|bannedsitelist

Riferiti nei file del tipo dansguardianfN.conf tramite i parametri omonimi, questi file non sono affatto, come si potrebbe pensare, liste di URL e di domini da bloccare, bensì un ulteriore livello di configurazione per stabilire quali file usare, e come usarli, come blacklist vere e proprie. Tipicamente, i file di questo tipo contengono, a parte qualche parametro abbastanza ovvio, una serie di direttive .Include che servono appunto a includere o meno determinate blacklist vere e proprie. Questo stesso meccanismo a più livelli si applica a liste di altro tipo, comprese le liste di frasi cui si accennava prima. I file da includere sono dello stesso tipo di quelli usati da squidGuard, e anche DansGuardian, per utilizzarli, li indicizza con il Berkeley Database. Quando se ne seleziona uno nuovo per l'inclusione, basta riavviare DansGuardian perché avvenga l'indicizzazione.

In conclusione, DansGuardian offre certamente un controllo molto fine, andando al di là del pur valido sistema delle blacklist, ma al prezzo di una configurazione che può risultare alquanto complicata.

Configurazione di tinyproxy

Il file di configurazione di tinyproxy è /etc/tinyproxy/tinyproxy.conf, almeno in Debian. L'unica riga da considerare è la seguente:

Port 3129

Questa è la porta su cui tinyproxy è in ascolto, e deve essere ovviamente la stessa a cui DansGuardian inoltra le URL eventualmente riscritte. L'uso della porta 3129 invece di quella di default 3128 è intenzionale, e vuole evitare confusione con la soluzione squid-squidGuard: le due soluzioni potrebbero essere implementate entrambe, e l'utilizzo effettivo dell'una o dell'altra dipenderebbe unicamente dalle regole iptables, purché si usino due porte diverse. In una fase di sperimentazione la cosa è più che sensata.

Per quanto riguarda tinyproxy non c'è altro, riavvio del servizio a parte.

Regole iptables per DansGuardian

In questa seconda soluzione è DansGuardian il primo anello della catena, e quindi la regola iptables va definita in modo da dirottare tutto il traffico web verso la porta su cui ascolta DansGuardian, sempre con l'accortezza di non dirottare le richieste web prodotte da tinyproxy.

La regola viene impostata col comando seguente:

# iptables -t nat -A OUTPUT --dport www -m owner ! --uid-owner proxy -j REDIRECT --to-ports 8080

Come si vede, il traffico web, eccetto quello prodotto dall'utente proxy che, di norma, esegue il processo tinyproxy, viene dirottato sulla porta 8080 su cui è in ascolto appunto DansGuardian. Sappiamo poi come va a finire: DansGuardian riscrive o meno la URL, e in ogni caso la passa a tinyproxy sulla porta 3129 perché sia inoltrata all'esterno.