Linux tips and tricks/Transparent proxy: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
mNessun oggetto della modifica |
|||
Riga 77:
In entrambi i casi, il filtratore si comporta come ''url rewriter'' nel senso che, in base alla sua configurazione, sostituisce la URL che ha ricevuto dal proxy con un'altra, tipicamente la URL di una pagina recante un messaggio del tipo ''spiacente, il sito che volevi raggiungere non sembra collegato agli interessi dell'Azienda'', o qualcosa del genere. Il proxy prende per buona questa URL ricevuta dal filtratore, sia che sia il proxy stesso a invocare il filtratore come sottoprocesso, sia che riceva dal filtratore una URL riscritta direttamente via rete.
== Il software 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.▼
== 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
Line 120 ⟶ 146:
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.
===
Praticamente c'è solo una riga da aggiungere al file di configurazione /etc/squid/squid.conf:
Line 128 ⟶ 152:
url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf
Questa riga informa squid di passare
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.
Line 134 ⟶ 158:
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.
===
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
▲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.
== Regole iptables ==▼
▲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 (e quindi poi al sistema di 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
Line 168 ⟶ 180:
== Tinyproxy e DansGuardian ==
Viene ora illustrata una seconda soluzione, basata su due software alquanto diversi
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
=== Configurazione di DansGuardian ===
Line 200 ⟶ 212:
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
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 permette 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.
[[Categoria:Linux tips and tricks|Transparent proxy]]
| |||