Se la macchina che utilizzeremo come firewall avrà compiti specifici, come ad esempio quello di Web o FTP server, potremo configurare il sistema per i soli servizi essenziali eliminando tutti quelli che potrebbero essere superflui: questo lo renderà più performante e meno vulnerabile a possibili attacchi esterni.
Andiamo dunque a vedere come configurare porte e servizi in Linux.
Al compito di ascoltare sulle porte e rendere, successivamente, attivo il servizio richiesto è adibito il demone inetd chiamato anche ?super server?. Questo è un processo servente che, ricevuta l?opportuna richiesta sulla specifica porta (socket), richiama il servizio predefinito attraverso la generazione di un processo figlio che esegue, con gli opportuni parametri, l?attivazione del servizio.
In parole più semplici il demone inetd è una sorta di centralinista, interposto tra il chiamante e il chiamato, che smista le telefonate ricevute. Potete, quindi, immaginare che con inetd è possibile scegliere quale sarà il programma che risponderà a un prestabilito servizio. Ecco uno scorcio del file inetd.conf, presente nella directory /etc/ di un tipico sistema Linux:
echo stream tcp nowait root internal
echo dgram udp wait root internal
discard stream tcp nowait root internal
discard dgram udp wait root internal
daytime stream tcp nowait root internal
daytime dgram udp wait root internal
chargen stream tcp nowait root internal
chargen dgram udp wait root internal
time stream tcp nowait root internal
time dgram udp wait root internal
ftp stream tcp nowait root /usr/sbin/tcpd wu.ftpd -a
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
#nntp stream tcp nowait news /usr/sbin/tcpd /usr/sbin/leafnode
smtp stream tcp nowait root /usr/sbin/sendmail sendmail -bs
printer stream tcp nowait root /usr/sbin/tcpd /usr/bin/lpd ?i
All?interno del file di configurazione in ogni riga sono presenti sette campi: il nome del servizio, il tipo di socket, il protocollo (tcp o udp), i flag (wait o nowait), lo user con cui si vuole lanciare il processo, il programma da eseguire (con il relativo path) e eventuali parametri da passare. I flag wait e nowait specificano al super server se deve operare in modalità single-threaded o multi-threaded. I nowait server utilizzano come protocollo di trasporto il tcp.
Se vogliamo disattivare un servizio, per esempio l’FTP anonimo, basta commentare la relativa riga con un #: ricordiamoci però di riavviare il demone inetd per rendere effettive le modifiche con il comando : kill ?HUP pid_di_inetd (il PID di un processo è ricavabile con il comando PS). Nel caso in cui non conosciate il pid del super server potete digitare: kill -HUP `ps aux | grep inetd | grep -v -e grep | awk ‘{print $2}’`
Nella configurazione del nostro firewall risulta importante disattivare tutti i servizi che non utilizzeremo, soprattutto i seguenti:
– echo
– discard
– chargen
– daytime
– time
– shell
– login
– exec
– comsat
– talk
– ntalk
– dtalk
– pop2
– uucp
– tftp
– bootps
– cfingerd
– systat
– netstat
– auth
– linuxconf
– swat
Quando non utilizzati, è sempre meglio disattivare anche i server non necessari come…
– ftp
– telnet
– pop3
– imap
– finger
Molto spesso abbiamo l?esigenza di restringere l?accesso di un servizio a una determinata sottorete o a una specifica lista di host, in modo che il servizio non sia disponibile a tutta la comunità di Internet. Per far ciò ci vengono in aiuto il TCP wrapper, sviluppati da Wietse Vanema dell? Università di Eindhoven in Olanda. Il TCP wrapper, conosciuto anche con il nome di tcpd, viene interposto tra il demone inetd e i services daemons e permette di filtrare i collegamenti che sono stati richiesti al super server: nel momento in cui arriva una nuova connessione, il demone inetd la delega al TCP wrapper, il quale, dopo aver effettuato gli opportuni test di controllo di accesso, invoca, nel caso di connessione lecita, l?idoneo programma server.
Il comportamento del TCP wrapper viene definito da regole ben precise presenti nei file /etc/hosts.allow e /etc/hosts.deny. Per ogni nuova connessione che arriva al sistema il demone tcpd esamina l?indirizzo di rete dell? host remoto e consulta il file hosts.allow per cercare una regola che possa garantire esplicitamente l?accesso per tale indirizzo. Nel caso in cui nessuna regola possa soddisfare tale richiesta, il tcpd controlla il contenuto del file hosts.deny per accertare l?esistenza o non di regole che non permettano l?accesso al sistema. Nel caso in cui nessuna delle regole presente all?interno dei due file soddisfino alla richiesta di connessione, quest?ultima viene, comunque, autorizzata.
L?utility tcpdmatch permette di simulare connessioni esterne in modo da verificare la bontà delle regole presenti nei due file di configurazione.
Un esempio di configurazione tcpd è la seguente:
/etc/hosts.deny
ALL:ALL
/etc/hosts.allow
ALL: 192.168.0.2 #client interno alla rete
ALL: 213.1.2.3 #sistema sicuro
ALL: 213.1.1 #è permesso il traffico proveniente dalla sottorete 213.1.1.x
Inoltre possiamo includere tra le regole la possibilità di permettere solo a un host sicuro l?accesso a un servizio di rete:
in.ftpd: 192.168.0.2 #è premesso l?accesso FTP solo alla macchina con indirizzo 192.168.0.2
in.pop3d: 213.1.2.3 #servizio permesso solo alla macchina 213.1.2.3
La Berkeley introdusse nella sua versione di Unix il concetto di trusted host, cioè di host sicuro. Un host che si fida di un altro host garantisce l?accesso agli utenti del secondo sistema senza chiedergli di autentificarsi tramite la password. Le applicazioni che normalmente utilizzano questa caratteristica sono le seguenti: rlogin, rsh e rcp. La proprietà offerta dal sistema di trusted host è sicuramente conveniente per molti scopi, ma genera una grossa falla di sicurezza per il sistema.
Attraverso questo meccanismo una persone che guadagna l?accesso ad un account su un sistema ha immediatamente accesso a tutti gli altri sistemi che si fidano di quest?ultima. Per avere una prova concreta di quanto detto, basta risalire al 1989, quando l? ?Internet Worm?, anche attraverso il sistema di trusting, si espanse a macchia d?olio su Internet.
La configurazione dei trusted host può avvenire in due modi. Il primo è basato su un rapporto host-to-host come specificato nel file di configurazione /etc/host.equiv. Il secondo è basato su un rapporto host-to-user secondo il file di configurazione .rhosts. Entrambe le modalità sono del tutto non fondamentali e la loro assenza indica la mancanza di ?fiducia? di qualsiasi sistema remoto.
Tale assenza rappresenta una buona scelta per garantire la sicurezza dell?intero sistema, per conoscere la presenza di regole di trusting digitate il comando:
find / | grep -e “.rhosts” -e “hosts.equiv” > /etc/info/risultati_trust
troverete nel file /etc/info/risultati_trust i trusted host conosciuti dal sistema.
Anche per questa settimana è tutto: non mi resta che darvi appuntamento alla prossima.
Ti potrebbe interessare
11 giu 2000