Sicurezza e NFS

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.

Sicurezza del client

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.

Sicurezza del server: nfsd

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.

Sicurezza del server: il portmapper

Il portmapper di base ha problemi se usato con nfsd che rendono possibile ottenere file dal server NFS senza alcun privilegio. Fortunatamente il portmapper 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

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.

NFS e firewall

È 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.

Riassunto

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.