Non sono un esperto di sicurezza, ma sono abbastanza 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.
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 base sulla sicurezza. E ricordate, le cose che dico qui sono solo l'inizio. Un sito sicuro ha bisogno di un amministratore diligente che sappia dove trovare informazioni e tutti i problemi relativi alla sicurezza.
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.
Dovreste leggere gli avvisi del CERT su NFS, molto di ciò che è qui scritto deriva dai messaggi scritti dal CERT. Vedere ftp.cert.org/01-README per un elenco aggiornato degli avvisi del CERT. Ecco qui alcuni avvisi relativi a NFS.
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.
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
nosuid. 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 noexec, ma è sicuramente
meno pratico di nosuid, poiché è naturale pensare che una partizione
debba avere dei file eseguibili o degli script. Potete inserire queste opzioni
nella colonna opzioni con rsize e wsize separati da
virgole.
Sul server possiamo decidere che non vogliamo dare fiducia all'account root dei client. Possiamo farlo usando l'opzione root_squash nel file exports:
/mn/eris/local apollon(rw,root_squash)
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
root_squash 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 root e non di bin
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.
root_squash è realtà un'opzione di default con Linux NFSd,
per garantire accesso come root ai filesystem, utilizza l'opzione
no_root_squash.
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.
Un'altra cosa: mai esportare un filesystem a 'localhost' o 127.0.0.1. Credetemi.
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.
Non tutte le distribuzioni di Linux sono uguali. Alcune distribuzioni
apparentemente aggiornate non 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 non è 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 /etc/hosts.deny e /etc/hosts.allow,
importanti per gestire la sicurezza. Posto che
il portmapper è /usr/sbin/portmap si può controllarlo con il
seguente comando: strings /usr/sbin/portmap | grep hosts.
Sulla mia macchina il risultato è:
/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
Per prima cosa modifichiamo il file /etc/hosts.deny. Dovrebbe
contenere la riga:
portmap: ALL
che nega l'accesso a chiunque. Poiché l'accesso è chiuso,
provate il comando rpcinfo -p 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.
Chiudere il portmapper a chiunque è un po' troppo drastico, quindi
riapriamolo modificando il file /etc/hosts.allow, 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:
portmap: 129.240.223.0/255.255.255.0
in hosts.allow. Questo è quanto viene scritto anche come subnet mask in
ifconfig. Per il dispositivo eth0 di questa macchina, ifconfig
dovrebbe essere:
...
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
...
e netstat -rn dovrebbe mostrare:
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 ...
(l'indirizzo di rete è nella prima colonna).
I file hosts.deny e hosts.allow sono descritti nelle pagine
man con lo stesso nome.
IMPORTANTE: non inserite nient'altro che NUMERI IP 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...
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.
È 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 rpcinfo -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.
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 abbastanza sicuri.
Comunque ci sono altri problemi: se qualcuno ha accesso alla rete
può far apparire strani comandi nel vostro .forward o leggere
la vostra posta se le directory /home o /var/spool/mail
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.
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 comp.os.linux.announce e comp.security.announce.