<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>NFS HOWTO: Sicurezza e NFS</TITLE>
<LINK HREF="NFS-HOWTO-7.html" REL=next>
<LINK HREF="NFS-HOWTO-5.html" REL=previous>
<LINK HREF="NFS-HOWTO.html#toc6" REL=contents>
</HEAD>
<BODY>
<A HREF="NFS-HOWTO-7.html">Avanti</A>
<A HREF="NFS-HOWTO-5.html">Indietro</A>
<A HREF="NFS-HOWTO.html#toc6">Indice</A>
<HR>
<H2><A NAME="nfs-security"></A> <A NAME="s6">6. Sicurezza e NFS</A></H2>
<P>Non sono un esperto di sicurezza, ma sono <EM>abbastanza</EM> coscio dei
problemi di sicurezza. Ma attenzione: questo non è certo un elenco completo
dei problemi legati a NFS e se pensate di essere sicuri una volta che avrete letto
e implementato ciò che è scritto qui, avrei giusto giusto un ponte da vendervi.
<P>
<P>Questa sezione non è probabilmente di utilità se vi trovate in un una rete
chiusa, dove conoscete gli utenti e nessuno che non conoscete può accedere
alle macchine della rete. Ovvero, non ci dovrebbero essere modi per
entrare nella rete in dialin (via modem) e non dovrebbe essere collegata ad
altre reti di cui non conoscete gli utenti. Pensate che io sia paranoico?
Non lo sono per nulla. Questo è solo un aiuto di <EM>base</EM> sulla sicurezza.
E ricordate, le cose che dico qui sono solo l'inizio. Un sito <EM>sicuro</EM>
ha bisogno di un amministratore diligente che sappia dove trovare informazioni
e tutti i problemi relativi alla sicurezza.
<P>
<P>NFS ha un problema di sicurezza di base per cui il client, se non
specificato altrimenti, si fida del server NFS e viceversa. Questo può
essere negativo. Significa che se l'account di root viene compromesso
sul server, viene compromesso anche quello di tutti i client e viceversa.
Ci sono alcune strategie di copia per questo, sulle quali torneremo poi.
<P>
<P>Dovreste leggere gli avvisi del CERT su NFS, molto
di ciò che è qui scritto deriva dai messaggi scritti dal CERT.
Vedere
<A HREF="ftp://ftp.cert.org/01-README">ftp.cert.org/01-README</A>
per un elenco aggiornato degli avvisi del CERT. Ecco qui alcuni avvisi
relativi a NFS.
<P>
<HR>
<PRE>
CA-91:21.SunOS.NFS.Jumbo.and.fsirand 12/06/91
Vulnerabilities concerning Sun Microsystems, Inc. (Sun) Network
File System (NFS) and the fsirand program. These vulnerabilities
affect SunOS versions 4.1.1, 4.1, and 4.0.3 on all architectures.
Patches are available for SunOS 4.1.1. An initial patch for SunOS
4.1 NFS is also available. Sun will be providing complete patches
for SunOS 4.1 and SunOS 4.0.3 at a later date.
CA-94:15.NFS.Vulnerabilities 12/19/94
This advisory describes security measures to guard against several
vulnerabilities in the Network File System (NFS). The advisory was
prompted by an increase in root compromises by intruders using tools
to exploit the vulnerabilities.
CA-96.08.pcnfsd 04/18/96
This advisory describes a vulnerability in the pcnfsd program (also
known as rpc.pcnfsd). A patch is included.
</PRE>
<HR>
<P>
<H2><A NAME="ss6.1">6.1 Sicurezza del client</A>
</H2>
<P>Sul client possiamo decidere di non volere dare troppa fiducia al
server in un paio di modi con delle opzioni del mount. Per esempio
possiamo vietare l'uso di programmi SUID su partizioni NFS con l'opzione
<CODE>nosuid</CODE>. Questa è una buona idea e dovreste considerarne l'uso
con tutti i dischi che montate via NFS. Significa che gli utenti root del
server non possono fare programmi SUID-root sul file system, entrare come
utenti normali sui client e usare i programmi SUID per diventare
root anche sui client. Possiamo anche vietare l'esecuzione di file
sulla partizione montata usando l'opzione <CODE>noexec</CODE>, ma è sicuramente
meno pratico di <CODE>nosuid</CODE>, poiché è naturale pensare che una partizione
debba avere dei file eseguibili o degli script. Potete inserire queste opzioni
nella colonna opzioni con <CODE>rsize</CODE> e <CODE>wsize</CODE> separati da
virgole.
<P>
<H2><A NAME="ss6.2">6.2 Sicurezza del server: nfsd</A>
</H2>
<P>Sul server possiamo decidere che non vogliamo dare fiducia
all'account root dei client. Possiamo farlo usando l'opzione
root_squash nel file exports:
<P>
<HR>
<PRE>
/mn/eris/local apollon(rw,root_squash)
</PRE>
<HR>
<P>Ora, se l'utente con UID 0 sul client cerca di accedere (lettura,
scrittura, cancellazione) al file system, il server sostituisce l'UID con quello
dell'utente 'nobody' del server. Ciò significa che il root dei client
non può accedere o modificare i file del server che solo root può
accedere o modificare. Ciò rappresenta un fatto positivo e probabilmente dovreste usare
<CODE>root_squash</CODE> su tutti i file system che esporte. Potrebbe sorgere il dubbio
che l'utente root dei client può usare il comando 'su' per diventare
un altro utente e accedere e cambiare i file di quell'utente!. La
risposta è affermativa. Questo è ciò che avviene e quello che deve
avvenire su Unix e NFS e ha un'importante conseguenza: i file
importanti devono essere di proprietà di <CODE>root</CODE> e non di <CODE>bin</CODE>
o altri utenti non root, poiché il solo utente a cui l'utente root dei
client non può accedere è l'account root del server. Nella pagina
man di NFSd ci sono molte altre opzioni squash e potete decidere
di non dare fiducia a qualsiasi utente dei client. È possibile anche applicare
lo squash a gruppi di UID o GID. Tutto ciò è descritto nella pagina
man di NFSd.
<P>
<P>root_squash è realtà un'opzione di default con Linux NFSd,
per garantire accesso come root ai filesystem, utilizza l'opzione
<CODE>no_root_squash</CODE>.
<P>
<P>Un'altra cosa importante è assicurarsi che nfsd controlli che
tutte le richieste provengano da una porta privilegiata. Se accetta
richieste da qualsiasi porta, un utente senza privilegi particolari
potrebbe lanciare un programma facilmente ottenibile su Internet che
comunica con il server nfs e gli fa credere di essere un utente qualsiasi.
L'nfsd di Linux fa questo controllo per default, ma su altri sistemi
operativi dovrete effettuare questo controllo per contro vostro,
che dovrebbe essere descritto nella pagina man di nfsd del sistema operativo usato.
<P>
<P>Un'altra cosa: mai esportare un filesystem a 'localhost' o
127.0.0.1. Credetemi.
<P>
<H2><A NAME="ss6.3">6.3 Sicurezza del server: il portmapper</A>
</H2>
<P>Il portmapper di base ha problemi se usato con nfsd che rendono possibile
ottenere file dal server NFS senza alcun privilegio. Fortunatamente il
portmapper che viene distribuito con Linux è relativamente sicuro contro
questo attacco e può essere reso maggiormente sicuro configurando l'elenco
degli accessi in due file.
<P>
<P>Non tutte le distribuzioni di Linux sono uguali. Alcune distribuzioni
apparentemente aggiornate <EM>non</EM> includono un portmapper sicuro nemmeno
oggi, a distanza di molti anni da quando il problema è stato reso noto. Almeno
una distribuzione contiene la pagina man per un portmapper sicuro, ma
il portmapper reale <EM>non</EM> è sicuro. Un modo
facile per controllare se il vostro portmapper è valido oppure no, è quello
di lanciare il comando strings(1) per verificare se il portmapper
legge i file <CODE>/etc/hosts.deny</CODE> e <CODE>/etc/hosts.allow</CODE>,
importanti per gestire la sicurezza. Posto che
il portmapper è <CODE>/usr/sbin/portmap</CODE> si può controllarlo con il
seguente comando: <CODE>strings /usr/sbin/portmap | grep hosts</CODE>.
Sulla mia macchina il risultato è:
<P>
<HR>
<PRE>
/etc/hosts.allow
/etc/hosts.deny
@(#) hosts_ctl.c 1.4 94/12/28 17:42:27
@(#) hosts_access.c 1.20 96/02/11 17:01:27
</PRE>
<HR>
<P>
<P>Per prima cosa modifichiamo il file <CODE>/etc/hosts.deny</CODE>. Dovrebbe
contenere la riga:
<P>
<HR>
<PRE>
portmap: ALL
</PRE>
<HR>
<P>che nega l'accesso a <EM>chiunque</EM>. Poiché l'accesso è chiuso,
provate il comando <CODE>rpcinfo -p</CODE> per verificare se il vostro portmapper
legge e obbedisce realmente a questo file. rpcinfo non dovrebbe dare
alcun risultato oppure un messaggio di errore. Non dovrebbe essere
necessario riavviare il portmapper.
<P>
<P>Chiudere il portmapper a chiunque è un po' troppo drastico, quindi
riapriamolo modificando il file <CODE>/etc/hosts.allow</CODE>, ma prima
cerchiamo di capire che cosa inserirci. Il file dovrebbe semplicemente
avere un elenco di tutte le macchine a cui si vuole garantire accesso al
portmapper. Ci sono comunque pochissimi casi di macchine che hanno bisogno di
un accesso totale per qualsiasi ragione. Il portmapper amministra nfsd,
mountd, ypbind/ypserv, pcnfsd e i servizi 'r', come ruptime e rusers.
Di questi, solo nfsd, mountd, ypbind/ypserv e forse pcnfsd possono avere qualche
conseguenza. Tutte le macchine che richiedono accessi ai servizi della vostra macchina
dovrebbero essere autorizzate a farlo. Supponiamo che l'indirizzo della vostra
macchina sia 129.240.223.254 e che si trovi in una sottorete 129.240.223.0 che
deve poter accedere ai servizi della macchina (questa è la terminologia
introdotta da Networking HOWTO: se non vi ricordate rileggetelo). Scriviamo
quindi:
<P>
<HR>
<PRE>
portmap: 129.240.223.0/255.255.255.0
</PRE>
<HR>
<P>in <CODE>hosts.allow</CODE>. Questo è quanto viene scritto anche come subnet mask in
ifconfig. Per il dispositivo <CODE>eth0</CODE> di questa macchina, <CODE>ifconfig</CODE>
dovrebbe essere:
<P>
<HR>
<PRE>
...
eth0 Link encap:10Mbps Ethernet HWaddr 00:60:8C:96:D5:56
inet addr:129.240.223.254 Bcast:129.240.223.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:360315 errors:0 dropped:0 overruns:0
TX packets:179274 errors:0 dropped:0 overruns:0
Interrupt:10 Base address:0x320
...
</PRE>
<HR>
<P>e <CODE>netstat -rn</CODE> dovrebbe mostrare:
<P>
<HR>
<PRE>
Kernel routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
...
129.240.223.0 0.0.0.0 255.255.255.0 U 0 0 174412 eth0
...
</PRE>
<HR>
<P>(l'indirizzo di rete è nella prima colonna).
<P>I file <CODE>hosts.deny</CODE> e <CODE>hosts.allow</CODE> sono descritti nelle pagine
man con lo stesso nome.
<P>
<P><B>IMPORTANTE:</B> <EM>non</EM> inserite <EM>nient'altro</EM> che <EM>NUMERI IP</EM>
nelle linee del portmapper di questi file. La risoluzione dei nomi
può indirettamente causare attività del portmapper che può causare
attività del portmapper che può indirettamente causare attività del
portmapper...
<P>
<P>Ciò che abbiamo visto rende il server più chiuso. Il solo problema
che ora rimane (eh già :)) è che qualcuno riesca a corrompere la
shell di root (o che riesca a far partire la macchina con un floppy MS-DOS)
su una macchina affidabile e, usando questo privilegio, spedisca da una porta sicura
richieste come utente qualsiasi.
<P>
<H2><A NAME="security-firewalls"></A> <A NAME="ss6.4">6.4 NFS e firewall</A>
</H2>
<P>È una buona cosa proteggere con un firewall le porte di nfs e del
portmapper sul vostro router o firewall. L'nfsd funziona sulla porta 2049, con i protocolli
udp e tcp. Il portmapper lavora in genere sulla porta 111, sia tcp sia udp e mountd sulle porte 745 e 747, sia tcp sia udp.
Controllate le porte usate con il comando <CODE>rpcinfo -p</CODE>.
<P>
<P>Se invece NFS deve attraversare un firewall, ci sono delle opzioni
su nfsd e mountd più recenti per usare porte non standard
che possono essere tenute aperte attraverso il firewall.
<P>
<H2><A NAME="security-summary"></A> <A NAME="ss6.5">6.5 Riassunto</A>
</H2>
<P>Se usate hosts.allow/deny, root_squash, nosuid e l'opzione per le
porte privilegiate nei programmi portmapper/nfs, evitate la maggior
parte dei bug conosciuti di nfs e potete essere <EM>abbastanza</EM> sicuri.
Comunque ci sono altri problemi: se qualcuno ha accesso alla rete
può far apparire strani comandi nel vostro <CODE>.forward</CODE> o leggere
la vostra posta se le directory <CODE>/home</CODE> o <CODE>/var/spool/mail</CODE>
sono esportate via NFS. Per la stessa ragione, non dovreste mai lasciare
le vostre chiavi private di PGP su un disco esportato via NFS. O
almeno ora sapete i rischi che correte.
<P>
<P>NFS e il portmapper formano un sottosistema complesso e
non è improbabile che nuovi bug vengano scoperti, sia nella
progettazione sia nell'implementazione. Ci possono sempre essere
buchi di cui qualcuno sta abusando. Ma questa è la vita. Per tenervi
aggiornati su questo genere di problemi dovreste leggere alcuni
newsgroup come
<A HREF="news:comp.os.linux.announce">comp.os.linux.announce</A> e
<A HREF="news:comp.security.announce">comp.security.announce</A>.
<P>
<HR>
<A HREF="NFS-HOWTO-7.html">Avanti</A>
<A HREF="NFS-HOWTO-5.html">Indietro</A>
<A HREF="NFS-HOWTO.html#toc6">Indice</A>
</BODY>
</HTML>
