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.
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¶
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:
guardando /var/log/kern.log
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
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 2021-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
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... ;-)