In questo pagine non proponiamo l'acquisto e
lo studio di un particolare
firewall/router
ma anzi ci proponiamo di autocostruirlo
riutilizzando hardware dismesso.
Facciamo riferimento a pc con CPU
486
compatibile
e ad una distribuzione Linux specializzata
per sistemi embedded: la
Bering uClibc derivata dal progetto
LEAF/Bering derivata a sua volta dal progetto
Linux Router Project (ormai defunto nel 2003).
Consiste in un kernel Linux 2.4 e un
insieme di pachetti minimali per le funzionalità di base;
il tutto entro un floppy da 1.44M.
Le richieste hardware sono molto limitate, ma dipendono da cosa si
vuol fare. Comunque la configurazione minima è CPU i486 con 12MB di memoria,
unità floppy, due schede di rete e una tastiera (il monitor, dopo la fase di
test può essere tolto e ci si può eventualmente collegare al sistema
attraverso una seriale).
Un firewall di questo tipo è stato messo in opera negli Anni Scolastici 2002/03 e 2003/04 su hardware EPSON Endeavor 4DX2/66L con 12MB di RAM, due schede di rete 3COM 3c509 senza disco fisso risultando estremamente affidabile (7x24) con zero problemi di manutenzione.
Attualmente utilizziamo hardware ad hoc e in particolare PC-engines con processore 266 MHz AMD Geode SC1100 (fast 486 core), 128 MB SDRAM e 64/128 MB di CompactFlash, tre schede di rete National DP93916 e una porta seriale.
Per l'attività descritta occorrono un pc dismesso 486 e una stazione di lavoro da dove attiveremo il live-{CD,USB} Netkit4TIC. Il pc catorcio è la macchina target dove installeremo e proveremo il firewall mentre l'altro ci serve per scaricare i file da Internet e per costruire e personalizzare il floppy.
Per i problemi legati strettamente all'hardware e in particolare alle schede di rete ci viene in aiuto il sito http://pigtail.net/LRP/. Nel sito ci sono molte informazioni che vi potrebbero anche far perdere l'orientamento. Per semplicità in seguito ho riportato i quattro (4) link più importanti.
Installare 2 o più schede di rete può risultare un'operazione difficile specialmente quando le schede di rete, non autoconfiguranti, vanno in collisione (IRQ) tra di loro. In questo caso serve avere qualcosa di più del semplice driver: serve una utility fornita normalmente dal costruttore della scheda con la quale si può/deve cambiare il numero di interrupt (IRQ) e/o l'address base. Più la scheda è economica e più si fatica a trovare l'utility. Quindi non risparmiate sull'acquisto delle schede di rete!.
Il sito citato precedentemente mette a disposizione per il download una raccolta di queste utility per le schede di rete più conosciute. Il formato dei file da scaricare sono immagini boot compresse per floppy da 1.44M con dentro un DR-DOS freeware:
Attenzione che i file *.imz sono in realtà dei file compressi in formato ZIP. Ad esempio per le schede 3C509 ci serve l'immagine netcard.imz e per decomprimerla useremo:
# unzip netcard.imz
Archive: netcard.imz
inflating: NETCARD.IMA
Il file risultante è una immagine per floppy disk. Per trasferirlo sul supporto fisico prima lo formattiamo e poi lo copiamo con il comando dd (low level copy):
# superformat /dev/fd0 [...] # dd if=NETCARD.IMA of=/dev/fd0 bs=1474560 1+0 records in 1+0 records out 1474560 bytes transferred in 64.156201 seconds (22984 bytes/sec)
È ora il momento di accendere il nostro vecchio catorcio
con il floppy ancora caldo inserito nel drive. Alla comparsa del
prompt con il comando dir possiamo ottenere la
lista dei file. Dopo aver individuato l'eseguibile per la nostra/e
schede di rete lo lanciamo in esecuzione (nel nostro caso
3C509.exe. Normalmente l'utility
ci permette di cambiare
IRQ
o
l'IO address
in modo da evitare sovrapposizioni tra le due schede. Un
trucco che a volte funziona è quello di spostare
semplicemente di slot PCI la/e schede.
A questo punto il nostro sistema hardware è pronto.
Per formattare un floppy disk da 1440KB in modo da contenere 1680KB, con un primo step di formattazione "low-level" ed un secondo step di formattazione "MSDOS filesystem", utilizziamo il seguente comando:
# superformat /dev/fd0 1680/1440
(i possibili parametri si trovano su /etc/mediaprm).
Il bootloader utilizzato è syslinux e necessita un approfondimento a parte.
Dal momento che noi utilizzeremo una immagine del floppy non dobbiamo installare il bootloader nel floppy perchè è già presente nell'immagine. Nel caso ci costruissimo una immagine da zero occorrerebbe installarlo:
# syslinux -s /dev/fd0
Passiamo allo scaricamento del floppy base. Esiste nella
versione in formato *.exe autoscompattante in un floppy
e nella versione per sistemi Linux e utilizzabile dal
comando dd.
Seguite il prossimo riferimento di
download e scegliete la versione
stabile più recente. Poi con il comando dd
la trasferite su un floppy:
# dd if=Bering-uClibc_*_img_bering-uclibc-1680.bin \
of=/dev/fd0 bs=1720320
Se inseriamo il floppy nel pc catorcio e lo accendiamo
osserveremo il boot del firewall.
Al login specifichiamo come user root e
avremo a disposizione il menu di configurazione. Il
sistema non è però funzionante in quanto
sarà improbabile che i moduli caricati siano
proprio quelli giusti per l'hardware che abbiamo a disposizione.
Per una verifica del corretto funzionamento del floppy possiamo utilizzare QEMU dalla stessa stazione di lavoro:
$ qemu -boot a -fda /dev/fd0
ma non potremo testare il caricamento dei moduli delle schede.
Per far funzionare la nostra Bering box con le
particolari schede di rete in nostro possesso
occorre probabilmente modificare il package modules.lrp.
Editeremo il file /etc/modules per inserire
il nome del
modulo
per la nostra scheda di rete. Inoltre
nella directory /lib/modules
inseriremo il file contenente il modulo vero e proprio.
L'archivio contenente tutti i moduli precompilati si trova
nella stessa area di download e tipicamente ha
nome Bering-uClibc_modules_*.tar.gz.
Accendiamo questa volta il pc che fungerà da stazione di lavoro
con inserito nel drive CD-ROM il live-CD Netkit4TIC (oppure il
live-USB).
Nel caso di un pc
con hardware un po' lento possiamo specificare al boot la
stringa knoppix single che istruisce il sistema
a non attivare l'interfaccia grafica (in questo caso non la
utilizziamo).
Definiamo una variabile d'ambiente che rappresenta il numero della versione e una seconda variabile che rappresenta la corrispondente versione del kernel:
# export VER=3.0 ## Bering uClibc version ## # export KVER=2.4.33 ## Linux Kernel version ##
Definiamo un variabile d'ambiente di nome DownLoad
che viene valorizzata al path assoluto dove sono stati
scaricati i file (magari su supporto USB):
# export DownLoad=$RemovibleDevice/downloaded
Per trovare il modulo per la nostra particolare scheda di rete
occorre controllare la lista dei nomi nel file
Bering-uClibc_modules_$KVER.tar.gz. Per esempio
cerchiamo quello con nome "pcnet32" (case insensive):
# tar ztf $DownLoad/Bering-uClibc_modules_$KVER.tar.gz | \ grep -i pcnet32 $KVER/kernel/drivers/net/pcnet32.o
In seguito non opereremo direttamente sul floppy poichè
le continue riscritture ne possono compromettere il corretto funzionamento.
È molto meglio operare sul file immagine che montiamo
utilizzando il loop device (man mount).
(Suggerimento: prima di iniziare è saggio fare una copia del file
immagine originariamente scaricato da Internet e magari abbrevviare il nome
in uB3.0!).
# export L=/tmp/loop
# mkdir -p $L
# mount -o loop $DownLoad/Bering-uClibc_$VER_img_bering-uclibc-1680.bin $L
# rm -f $L/ppp* ## make room inside floppy ##
Estraiamo file modules.lrp dal floppy e facciamo
le modifiche necessarie (aggiunta del modulo e modifica alla
lista moduli). Attenzione che il modulo pcnet32 necessita
del modulo mii e del modulo crc32:
# export TMP=/tmp/workArea # mkdir -p $TMP # cd $TMP # tar zxf $L/modules.lrp ## extract gzipped modules.lrp ## # tar zxOf $DownLoad/Bering-uClibc_modules_$KVER.tar.gz \ $KVER/kernel/drivers/net/pcnet32.o > \ lib/modules/pcnet32.o ## extract and copy pcnet32.o ## # tar zxOf $DownLoad/Bering-uClibc_modules_$KVER.tar.gz \ $KVER/kernel/lib/crc32.o > \ lib/modules/crc32.o ## extract and copy crc32.o ## # tar zxOf $DownLoad/Bering-uClibc_modules_$KVER.tar.gz \ $KVER/kernel/drivers/net/mii.o > \ lib/modules/mii.o ## extract and copy mii.o ## # nano -w etc/modules ## add crc32, mii and pcnet32 ## to autoload list ## # tar czf $L/modules.lrp * ## re-create a new archive ##
Riportiamo le modifiche sul supporto fisico:
# umount $L
# dd if=$DownLoad/Bering-uClibc_$VER_img_bering-uclibc-1680.bin \
of=/dev/fd0 bs=1720320
Attenzione che
l'utilizzo dell'utenza root (segnalata dal promp "#")
garantisce che non
vengano modificate le permission dei file coinvolti nelle
precedenti operazioni.
Ora abbiamo un floppy allineato con l'hardware. Lo inseriamo su vetusto pc, diamo corrente e guardiamo con soddisfazione la sua attivazione.
Nota 1: l'esempio della scheda pcnet32 non è stato casuale: nel caso delle macchine virtuali realizzate dal VMware Player siamo esattamente in questo caso: la macchina virtuale (simile alla nostra macchina hardware) emula la scheda pcnet32 (AMD Am79C970A - PCnet LANCE PCI Ethernet Controller) e quindi noi dobbiamo caricare il relativo modulo con tutti i moduli dipendenti. Per completezza riportiamo che l'emulazione di VMware comprende anche la scheda Intel E1000 e la scheda VMXNET - VMware PCI Ethernet Adapter.
Nota 2: l'esempio precedente,
nel caso delle macchine virtuali realizzate da
QEMU,
deve essere modificato per la scheda "NE2000 PCI network adapters".
Nel floppy sono già presenti i moduli
crc32, 8390 e ne2k-pci
e quindi basta solo modificare la lista moduli: /etc/modules.
La configurazione può essere fatta seguendo la modalità
off-line esattamente come abbiamo fatto per la modifica del file
modules.lrp o in-line attraverso il menu di
configurazione. Nel secondo caso è bene ricordarsi che
tutte le modifiche vanno riportate nel floppy e questo viene
fatto attivando la funzione di backup.
Abbiamo scelto la modalità di lavoro off-line e quindi opereremo modificando l'immagine utilizzando un computer linux e al termine rigenerando completamente il floppy.
Passiamo ora alla vera e propria configurazione del firewall.
I file più importanti sono nel package etc.lrp:
/etc/network/interfaces: per la configurazione delle NIC;/etc/hosts: per alcune associazioni (IP, nome);/etc/hostname: per il nome dell'host;/etc/hosts.allow: host ACL (abilitazioni);/etc/hosts.deny: host ACL (negati).Gli ultimi due file sono legati a TCP_Wrappers che serve per filtrare l'accesso ai servizi del firewall.
L'
Ora legale italiana dal 1916
ci indica per ogni anno quali sono esattamente i giorni
in cui ci sono le variazioni dovute all'
ora legale. Riassumendo
per il 2006 nei giorni (25 Marzo, 29 Ottobre) e per il 2007 nei
giorni (30 Marzo, 28 Ottobre). Tali giorni
sono dei lunedi (primo [0] giorno della settimana [0-6]). In particolare
sono nella quarta e nella quinta settimana del mese.
Un documento dove viene spiegato quali valori assegnare
alla variabile TZ:
Environment Variables. Quindi per
noi:
# cat /etc/TZ
MET-1METDST-2,M3.4.0/02:00:00,M10.5.0/03:00:00
Per costruire il firewall viene usata una descrizione di regole di filtraggio ad alto
livello di nome
Shorewall
le quali sono successivamente tradotte a basso livello in
Netfilter
(iptables).
Esistono già pronti dei
template di pre-configurazioni
per varie versioni di shorewall adatte al caso in cui
si abbiano 2 o 3 NIC.
Copia i file in /etc/shorewall e personalizzali
secondo le tue necessità.
In particolare i file più importanti sono (package shorwall.lrp):
/etc/shorewall/zones:
descrive il partizionamento della rete in zone;/etc/shorewall/policy:
lista di regole di default per la gestione della sicurezza
a livello del firewall;/etc/shorewall/rules:
lista di regole che infrangono le regole espresse nella
policy;/etc/shorewall/interfaces:
elenco delle interfacce fisiche;/etc/shorewall/tunnels: per la configurazione di tunnel;/etc/shorewall/masq:
per configurare il mascheramento.
# /etc/shorewall/masq
#INTERFACE SUBNET
eth0 192.168.1.0/24
eth0 192.168.2.0/24
eth0 192.168.3.0/24
Il traffico, visto in termini di insieme di singoli pacchetti, può in generale essere definito dalle seguenti caratteristiche:
Possiamo ora stabilire una semplice politica di sicurezza d'esempio:
Rifiutare tutte le connessioni iniziate dalla rete pubblica verso il firewall e verso la LAN da lui protetta, tranne quelle dirette alla porta 22/tcp per l'amministrazione remota e quelle dirette verso la porta 80/tcp che verranno redirette su 10.10.10.65 stessa porta. Il traffico in uscita dal firewall e dalla LAN protetta è invece permesso, ma solo per i protocolli DNS, SSH, HTTP/HTTPS, SMTP.
Sandro Doro (email me)