Laboratorio

Modulo 6 - Hardware di rete

Copyright Creative Commons License 2003-2006 Sandro Doro

Esperienza su firewall LEAF/Bering uClibc ("a due interfacce")

 left up right

Per la realizzazione di questo modulo useremo Netkit4TIC con la connettività con la rete reale (leggere il file README).

Di seguito forniamo la mappa (pdf) della rete dell'esercizio proposto con il relativo schema di numerazione.

Lo scopo di questa esercitazione è quello di testare le funzionalità di una piccola rete locale connessa ad Internet tramite un firewall:

Per quanto riguarda la configurazione del firewall come macchina virtuale rimandiamo alla lettura di Virtual uBering.

Modificando la lista dei pacchetti da caricare al boot e memorizzata nella variabile LRP possiamo ottenere un'installazione personalizzata. Alla classica lista dei pacchetti aggiungiamo:

Le due interfacce di rete eth0 ed eth1 sono configurate attraverso l'impostazione del file /etc/network/interfaces. Inoltre Shorewall è settato in modalità "two interface" con attivazione del mascheramento. Per un esempio dei file di configurazione vai sul progetto Bering uClibc reale.

Dopo aver settato correttamente l'ambiente Netkit scarica il tarball e lancia lo script che costruisce il firewall, i tre nodi (e relativi hub):

realHost$ lstart net fw proxy loc01

che attiva un server apache sui nodi net, loc01 e proxy. Inoltre attiva i server squid e Dansguardian sul nodo proxy (screenshot).

Il documento si divide nelle seguenti sezioni:

Navigazione in Internet dalla rete LAN

 up

Dal nodo loc01 ricerchiamo la home page su net: 

loc01# lynx -dump http://217.57.5.218/ | strings
   Benvenuto 217.57.5.217 su 217.57.5.218

Verifichiamo il mascheramento controllando il file di log di apache: 

net# tail -f /var/log/apache/access.log
217.57.5.217 - - [25/Aug/2005:18:24:37 +0200] "GET / HTTP/1.0" 200 196 "-" \
  "Lynx/2.8.5rel.1 libwww-FM/2.14 SSL-MM/1.4.1 GNUTLS/1.0.16"

Network exploration tool and security scanner

 up

Utilizzando nmap costruiamo delle richieste di rete che facciano scattare le regole di DROP o REJECT del firewall, per esempio con: 

net# nmap 217.57.5.217 -p 21-22
[...]
PORT   STATE    SERVICE
21/tcp filtered ftp
22/tcp open     ssh
[...]

loc01# nmap 10.10.10.78  -p 21-22
[...]
PORT   STATE  SERVICE
21/tcp closed ftp
22/tcp open   ssh
[...]

e verifichiamo il risultato nel log del firewall con: 

fw# tail -f /var/log/messages
Sep  9 07:23:13 localhost kernel: Shorewall:net2all:DROP:IN=eth0 OUT= \
  MAC=fe:fd:d9:39:05:d9:fe:fd:d9:39:05:da:08:00 \
  SRC=217.57.5.218 DST=217.57.5.217 LEN=40 TOS=0x10 PREC=0x00 TTL=44 \
  ID=5239 PROTO=TCP SPT=60808 DPT=21 WINDOW=1024 RES=0x00 SYN URGP=0 

Sep  9 07:23:14 localhost kernel: Shorewall:net2all:DROP:IN=eth0 OUT= \
  MAC=fe:fd:d9:39:05:d9:fe:fd:d9:39:05:da:08:00 \
  SRC=217.57.5.218 DST=217.57.5.217 LEN=40 TOS=0x10 PREC=0x00 TTL=39 \
  ID=924 PROTO=TCP SPT=60809 DPT=21 WINDOW=4096 RES=0x00 SYN URGP=0

Sep  9 08:32:42 localhost kernel: Shorewall:all2all:REJECT:IN=eth1 OUT= \
  MAC=fe:fd:0a:0a:0a:4e:fe:fd:0a:0a:0a:41:08:00 \
  SRC=10.10.10.65 DST=10.10.10.78 LEN=40 TOS=0x10 PREC=0x00 TTL=56 \
  ID=54416 PROTO=TCP SPT=45151 DPT=21 WINDOW=1024 RES=0x00 SYN URGP=0

Facciamo notare che il traffico non ammesso proveniente da Internet subisce DROP e quello da rete locale subisce REJECT.

Navigazione da Internet tramite NAT

 up

Ci connettiamo da net (Internet) al web server (NAT su 10.10.10.65) sul nodo loc01: 

net# lynx -dump http://217.57.5.217/ | strings
   Benvenuto 217.57.5.218 su 217.57.5.217

Controlliamo il log del server web della rete privata: 

loc01# tail -f /var/log/apache/access.log
217.57.5.218 - - [25/Aug/2005:18:28:15 +0200] "GET /index.php HTTP/1.0" 200 196 "-" \
  "Lynx/2.8.5rel.1 libwww-FM/2.14 SSL-MM/1.4.1 GNUTLS/1.0.16"

Alcune catture di traffico

 up

Ecco di seguito le catture di traffico (analizzabili con ethereal):

Lasciamo al lettore la verifica della connettività al firewall attraverso ssh sia dalla rete interna che da quella esterna.

Configurazione agent SNMP e navigazione MIB tramite snmpwalk

 up

È stato configurato un agent ucd-snmp sul firewall e il tool mrtg sul nodo proxy della rete locale. Per consultare le informazioni dell'agent possiamo usare il comando snmpwalk. Ad esempio se vogliamo conoscere la lista delle interfacce del nodo 10.10.10.78 (lo filtriamo con un grep per rendere minimo l'output): 

loc01# snmpwalk -Os -c public -v 1 10.10.10.78 \
  .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifDescr \
  | grep -e "eth0\|eth1"
ifDescr.4 = STRING: eth0
ifDescr.5 = STRING: eth1

loc01# snmpwalk -n -Os -c public -v 1 10.10.10.78 \
  .1.3.6.1.2.1.2.2.1.2 \
  | grep -e "eth0\|eth1"
IF-MIB::ifDescr.4 = STRING: eth0
IF-MIB::ifDescr.5 = STRING: eth1

Per consultare le statistiche costruite da mrtg interrogando l'agent snmp basta puntare un browser nel seguente URL: 

realHost$ mozilla-firefox http://192.168.77.2/mrtg/firewall.eth[0-1].html

Configurazione e uso di ssh

 up

Per attivare una sessione SSH sul firewall: 

loc01# ssh 10.10.10.78
The authenticity of host '10.10.10.78 (10.10.10.78)' can't be established.
RSA key fingerprint is 1c:14:d4:b1:16:40:de:d2:42:ea:d4:1c:4a:50:f3:66.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.10.10.78' (RSA) to the list of known hosts.
root@10.10.10.78's password: root
LEAF Bering-uClibc fw 2.4.26-bs1 #2 Fri Dec 31 11:32:18 CET 2004

Type in help if you are really lost

Proxy server: Squid

 up

La navigazione può essere resa più sicura, veloce e priva di banner mediante l'uso di un server proxy. Nel caso di software Open Source quello più usato è sicuramente squid.

Nel nostro caso per evitare che una dimenticanza di configurazione del browser permetta al browser di navigare senza l'uso del proxy permettiamo al solo server proxy di generare traffico uscente verso Internet che utilizza le porte 80 e 443.

Per prima cosa restringiamo la policy in modo da negare qualsiasi accesso a Internet da parte della rete interna. Nel file policy occorre commentare la precedente regola di abilitazione alla navigazione e sostituirla con il divieto per tutti: 

# /etc/shorewall/policy
#SOURCE         DEST            POLICY      LOG LEVEL
loc             net             ACCEPT
loc             net             REJECT      info

Quindi ora occorre abilitare il traffico per la navigazione della sola macchina proxy. Cambiamo quindi la riga del file rules della configurazione di shorewall: 

# /etc/shorewall/rules
#ACTION       SOURCE            DEST     PROTO   DEST
Web/ACCEPT    loc               net
Web/ACCEPT    loc:10.10.10.77   net

Rifacciamo partire shorewall: 

fw# /etc/init.d/shorewall restart
Possiamo verificare che la regola impedisca la navigazione attraverso un semplice tentativo di accedere al server net. In seguito per impostare il proxy per il wget occorre impostare la variabile d'ambiente http_proxy e riprovare: 

loc01# export http_proxy="http://10.10.10.77:3128/"
loc01# lynx -dump http://217.57.5.218/ | strings
   Benvenuto 217.57.5.217 su 217.57.5.218

Catturando il traffico in Internet generato dal comando lynx eseguito dal nodo proxy e quello generato dallo stesso comando eseguito dal nodo loc01 non vediamo alcuna differenza mentre se controlliamo il traffico nella rete locale scopriamo che il comando HTTP di richiesta home page "GET / HTTP/1.0" diventa "GET http://217.57.5.218/ HTTP".

Volendo utilizzare il comando nc (netcat) proviamo a richiere la home page direttamente: 

loc01# echo -e "GET / HTTP/1.0\r\n\r\n" | \
              nc 217.57.5.218 80

e attraverso il proxy: 

loc01# echo -e "GET http://217.57.5.218/ HTTP/1.0\r\n\r\n" | \
              nc 10.10.10.77 3128

Un ottimo generatore di report per squid è Sarg le cui iniziali stanno per Squid Analysis Report Generator. È un generatore di pagine Web e quindi ha bisogno di un server Web. Attraverso cron deve essere lanciato in esecuzione giornalmente in modo da elaborare i dati di log di Squid e riportare i report nella directory /var/www/squid-reports. Per visualizzarli forziamo una esecuzione di sarg e poi lanciamo il browser: 

proxy# sarg
realHost$ mozilla-firefox http://10.10.10.77/squid-reports/

I dati sono molto dettagliati sia per utente/IP address che per ora, traffico generato e siti visitati.

Per i vincoli dovuti alle norme sulla privacy occorre configurare il server proxy in modo che vengano mantenuti i file di log per almeno un anno e nel contempo attivare una procedura di backup e salvataggio degli stessi a livello trimestrale. Il programma da configurare per il salvataggio dei log si chiama logrotate che nel caso di squid sarà configurato come segue: 

# /etc/logrotate.d/squid
# Logrotate fragment for squid
/var/log/squid/*.log {
        daily
        compress
        delaycompress
        rotate 400
        missingok
        nocreate
        sharedscripts
        prerotate
                test ! -x /usr/sbin/sarg-maint || /usr/sbin/sarg-maint
        endscript
        postrotate
                test ! -e /var/run/squid.pid || /usr/sbin/squid -k rotate
        endscript
}

Per l'analisi delle prestazioni del proxy tramite il programma sarg è preferibile settare la raccolta differenziata per mese: 

# /etc/cron.monthly/squid
#Get current date
TODAY=$(date +%d/%m/%Y)
 
#Get current date
TD=$(date --date "1 month ago" +%Y-%m)
 
#Get one month ago today
YESTERDAY=$(date --date "1 month ago" +%d/%m/%Y)
 
#Get one month ago today (4touch)
YD=$(date --date "1 month ago" +%m/%d/%Y)

touch -d $YD /tmp/a
cat /var/log/squid/access.log.1 > /var/log/squid/monthly/squid-$TD
find /var/log/squid/ -newer /tmp/a -name access.log\*gz | \
  xargs zcat >> /var/log/squid/monthly/squid-$TD

ln -f -s /var/log/squid/monthly/squid-$TD /var/4sarg
sarg -o /var/www/squid-reports/monthly -d $YESTERDAY-$TODAY

Attenzione che i log contengono dati sensibili e quindi quelli relativi agli utenti non possono essere consultati senza infrangere la Legge Italiana.

Proxy server: DansGuadian

 up

Un altro proxy server, normalmente usato in cascata a Squid, utile come analizzatore di contenuti è DansGuardian. Questo programma si frappone tra il browser e Squid permettendo di filtrare le pagine visitate attraverso vari metodi: URL, IP address, frasi, estensioni di file e altre caratteristiche.

Esplicitiamo quindi ora il funzionamento dei due proxy server in una configurazione cooperativa. Dansguardian è in attesa di richieste dai vari browser sulla porta TCP 8080. Se la richiesta non è vietata in base all'IP, all'URL o a qualche altro filtro, Dansguardian passa la richiesta a Squid via loopback (quindi locale) sulla porta TCP 3128. Squid ricerca la pagina (inserendola nella cache per successive richieste) e la manda indietro a Dansguardian per l'ispezione del contenuto. Se il contenuto è accettabile, Dansguardian passa la pagina al browser che ne aveva fatto richiesta. Se il contenuto non è accettabile viene visualizzata una pagina web di negazione della richiesta.

Configurazione Transparent Proxy Server

 up

Un altro metodo per configurare l'uso del proxy consiste nel cambiare il funzionamento del sistema invece che cambiare il funzionamento delle applicazioni.
Le motivazioni che spingono verso l'utilizzo del Transparent Proxy sono:

Il meccanismo è schematizzato (pdf) come segue. Il browser manda la richiesta al server web e ha l'illusione di parlare con il server reale. La richiesta viene invece rediretta al server proxy che si incarica di mandare la richiesta al server reale. L'illusione della trasparenza si ferma al client poichè il server si rende conto che è in comunicazione con il proxy. In effetti il server web è illuso di comunicare con client e invece è in dialogo con il proxy.

Un ottimo documento sull'argomento si trova presso Transparent Proxy.

Per prima cosa occorre cambiare la configurazione di squid: 

# /etc/squid/squid.conf
[...]
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
[...]

e sempre sul nodo dove è installato squid associare all'attivazione della scheda di rete (eth1 nel nostro caso) il seguente comando di redirezione: 

proxy# iptables -t nat -A PREROUTING -i eth1 -d ! 10.10.10.77 \
              -p tcp --dport 80 -j REDIRECT --to-ports 3128

Le rimanenti operazioni sono tutte da fare sul router.
Aggiungiamo alla tabella delle tavole una entry www.out: 

fw# echo 202 www.out >> /etc/iproute2/rt_tables

Nel file di inizializzazione di shorewall aggiungiamo: 

# /etc/shorewall/init
if [ -z "`ip rule list | grep www.out`" ] ; then
        ip rule add fwmark 0xCA table www.out # Note 0xCA = 202
        ip route add default via 10.10.10.77 dev eth1 table www.out
        ip route flush cache
        echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects
fi

Modifichiamo il file: 

# /etc/shorewall/interfaces
[...]
#ZONE INTERFACE  BROADCAST    OPTIONS
loc   eth1       10.10.10.79  routeback

e infine aggiungiamo il file: 

# /etc/shorewall/start.d/transpro
iptables -t mangle -A PREROUTING -i eth1 -s ! 10.10.10.77 \
  -p tcp --dport 80 -j MARK --set-mark 202

Sperimentazione Transparent Proxy Server

 up

Per sperimentare la configurazione con il transparent proxy a partire dall'esperienza appena illustrata occorre "sostituire" i due nodi fw e proxy: 

realHost$ lcrash fw proxy; \
          lstart fwtp proxytp

Invece nel caso in cui si sia salta la sperimentazione precedente basta lanciare: 

realHost$ lstart net fwtp proxytp loc01

che costruisce i medesimi nodi con gli stessi servizi elencati precedentemente ma con le configurazioni specializzate.

Attiviamo una sessione di navigazione dal client della rete privata: 

loc01# lynx -dump http://217.57.5.218/ | strings
   Benvenuto 217.57.5.217 su 217.57.5.218

e controlliamo l'effetto sul proxy e sul web server: 

proxytp# tail -n 1 /var/log/squid/access.log
1130753977.005     25 10.10.10.65 TCP_MISS/200 509 \
  GET http://217.57.5.218/ - DIRECT/217.57.5.218 text/html
net # tail -n 1 /var/log/apache/access.log
217.57.5.217 - - [31/Oct/2005:11:19:36 +0100] \
  "GET / HTTP/1.0" 200 196 "-" \
  "Lynx/2.8.5rel.1 libwww-FM/2.14 SSL-MM/1.4.1 GNUTLS/1.0.16"

Il file di cattura traffico (File ACP) può essere poi elaborato con un filtro del tipo "http" in modo da evidenziare il "solo traffico http" (screenshot): 

No. Source       Destination   Prot  MAC address src    MAC address dst   Info
 5  10.10.10.65  217.57.5.218  HTTP  00:00:00:00:00:65  00:00:00:00:00:78 GET / HTTP/1.0

No. Source       Destination   Prot  MAC address src    MAC address dst   Info
 7  10.10.10.65  217.57.5.218  HTTP  00:00:00:00:00:78  00:00:00:00:00:77 GET / HTTP/1.0

No. Source       Destination   Prot  MAC address src    MAC address dst   Info
12  10.10.10.77  217.57.5.218  HTTP  00:00:00:00:00:77  00:00:00:00:00:78 GET / HTTP/1.0

No. Source       Destination   Prot  MAC address src    MAC address dst   Info
14  217.57.5.218 10.10.10.77   HTTP  00:00:00:00:00:78  00:00:00:00:00:77 HTTP/1.1 200 OK

No. Source       Destination   Prot  MAC address src    MAC address dst   Info
17  217.57.5.218 10.10.10.65   HTTP  00:00:00:00:00:77  00:00:00:00:00:65 HTTP/1.0 200 OK

dove, per facilitare la lettura, abbiamo assegnato i MAC address delle schede dei nodi della LAN al valore 00:00:00:00:00:NN dove NN è il quarto numero dell'indirizzo IP.

How Skype & Co. get round firewalls

 up

Read the Jurgen Schmidt's article The hole trick in "heise Security" and than experiment it in our labs. Please startup a subset of lab: 

realHost$ lstart net fw loc01

Firstly start a UDP listener on UDP port 14141 on the loc01 node behind the firewall: 

loc01# nc -u -l -p 14141 &

An external computer net then attempts to contact it (fw IP address: 217.57.5.217): 

net# echo "Hello" | nc -p 53 -u 217.57.5.217 14141

However, as expected nothing is received on loc01 and, thanks to the firewall, nothing is returned to net. Now on a node loc01, hping2, our universal tool for generating IP packets, punches a hole in the firewall (net IP address: 217.57.5.218): 

loc01# hping2 -c 1 -2 -s 14141 -p 53  217.57.5.218

As long as net is behaving itself, it will send back a "port unreachable" response via ICMP - however this is of no consequence. On the second attempt: 

net# echo "Hello" | nc -p 53 -u 217.57.5.217 14141

the netcat listener on node loc01 then coughs up a "Hello" - the UDP packet from outside has passed through the firewall and arrived at the computer behind it.

up
Creative Commons License FREE THE MOUSE Valid HTML! Sandro Doro (email me)
Ultima modifica: $Date: 2007-02-19 17:36:42 $