Domande? Problemi?

Iscriviti al Google group:

Un proxy solo per SQUID

Scopo

Lo scopo di questa esperienza è configurare il server in modo che solo squid possa uscire sulla porta 80. Ogni altro utente deve venire bloccato in modo che si forzi l’uscita tramite proxy.

Setup

Questa esperienza usa

  • un server isi, facente anche funzione di firewall

Premessa

Ogni scuola è opportuno non solo che usi un firewall ma che implementi una politica che inibisca a chiunque di uscire in internet se non usando il firewall. La cosa non è difficile se il firewall è indipendente dal server. Quando però, normalmente per economizzare un pc, si usa il server come firewall ed è lecito agli utenti loggarsi sul server (ad esempio quando venga usato anche come server LTSP) si pone un problema: non si può inibire l’uscita sulla porta 80 pena il blocco di squid stesso, quindi ad un utente diventa possibile uscire senza proxy, semplicemente modificando a mano la configurazione del proprio broswer.

La soluzione che proponiamo qui è interamente basata su un modulo di iptables che può distinguere il proprietario del pacchetto.

Questa informazione non viene memorizzata nel pacchetto stesso, ma il kernel la conosce e può quindi prendere azioni di conseguenza.

E` sufficiente configurare pyrewall opportunamente:

iptables -A OUTPUT -p tcp --dport 80 -m owner --uid-owner proxy -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j DROP

e rilanciare pyrewall per ottenere questo risultato.

Le regole sopra indicate aggiugno due anelli alla cetena di OUTPUT, ovvero quella da cui passano tutti i pacchetti originari sulla macchina stessa e destinati all’esterno.

Il primo anello dichiara esplicitamente che se il pacchetto è di proxy (l’utente con cui gira squid) può passare, la successiva riga dice che nessun altro pacchetto tcp con destinazione la porta 80 può passare, lo fa mandando il pacchetto nella catena bad ovvero quella dove dove i pacchetti vengono prima loggati e poi droppati.

Esercizio

  1. Verificare che l’utente root non possa navigare in internet. E` possibile verificare questo in vari modi, ad esempio con un browser testuale, ma di gran lunga il metodo più semplice è usare wget:

    wget http://192.168.50.254

    questo comando “resta appeso” ovvero non dà alcun errore fino a quando va in “time out” che avviene dopo parecchio tempo.

    Come possiamo vedere se veramente stiamo tagliando?

    possiamo vedere i pacchetti tagliati in due modi:

    1. guardando /var/log/kern.log

    2. guardando le catene, ed in particolare i contatori dei pacchetti:

      srv-isi:~# ipt OUTPUT
      Chain OUTPUT (policy ACCEPT 126 packets, 16144 bytes)
       pkts bytes target     prot opt in     out     source               destination
          0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 owner UID match 13
          8   480 bad        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80
  2. Ora proviamo ad usare il proxy, per farlo basta impostare la variabile d’abiente http_proxy che punti al proxy su localhost:

    srv-isi:/hostlab# http_proxy=http://127.0.0.1:3128 wget  --proxy-user=administrator --proxy-password=isi 192.168.50.254
    --2010-04-19 21:53:57--  http://192.168.50.254/
    Connecting to 127.0.0.1:3128... connected.
    Proxy request sent, awaiting response... 200 OK
    Length: 45 [text/html]
    Saving to: `index.html'
    
    100%[====================================================>] 45          --.-K/s   in 0s
    
    2010-04-19 21:53:57 (676 KB/s) - `index.html' saved [45/45]

    Potreste avere un risultato differente ad esempio se non c’è un server in ascolto, ma in quel caso avreste un messaggio tipo:

    Proxy request sent, awaiting response...
Che ci conferma che il proxy ha inoltrato la domanda
  1. Verifichiamo che veramente siamo passati dal firewall utilizzando il riconoscimento del pacchetto come pacchetto di squid:

      srv-isi:/hostlab# ipt OUTPUT
      Chain OUTPUT (policy ACCEPT 1308 packets, 573K bytes)
       pkts bytes target     prot opt in     out     source               destination
          5   420 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 owner UID match 13
         20  1200 bad        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80
    
    La penultima riga ci dice che sono passati 5 pacchetti (il download era *molto* piccolo... ;-)