Avanti Indietro Indice

6. Sicurezza ed NFS

Non sono un esperto di sicurezza, ma sono abbastanza coscio dei problemi di sicurezza. Ma attento: questa non è certo una lista completa dei problemi legati ad NFS e se pensi di essere sicuro una volta che avrai letto ed implementato ciò che è scritto qui, avrei anche un ponte che vorrei venderti.

Questa sezione non è probabilmente di utilità se sei un una rete chiusa, dove conosci gli utenti e nessuno che tu non conosca 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 ne conosci gli utenti. Pensi che io sia paranoico ? Non lo sono per nulla. Questo è solo un aiuto di base sulla sicurezza. E ricorda, le cose che dico qui sono solo l'inizio. Un sito sicuro necessita di un amministratore diligente e che conosca 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 la shell di root viene compromessa sul server, viene compromessa anche quella di tutti i client. E viceversa. Ci sono alcune strategie di copia per questo, sulle quali torneremo poi.

Qualcosa che dovresti leggere sono gli avvisi del CERT sul NFS, molto di ciò che è qui scritto deriva con i messaggi scritti dal CERT. Vedi ftp.cert.org/01-README per una lista aggiornata degli avvisi del CERT. Ecco qui alcuni avvisi relativi ad 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.

6.1 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 programi SUID su partizioni NFS con l'opzione nosuid. Questa è una buona idea e dovresti considerarne l'uso con tutti i dischi che monti 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 quindi usare i programmi SUID per diventare root anche sui client. Possiamo anche vietare l'esecuzione di file sulla partizione montata usando anche l'opzione noexec, ma è sicuramente meno pratico di nosuid, poiché è naturale pensare che una partizione debba avere dei file eseguibili o degli script. Puoi inserire queste opzioni nella colonna opzioni, assieme a rsize e wsize, separati da virgole.

6.2 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) il file system 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ò è positivo, e probabilmente dovresti usare root_squash su tutti i file systems che esporti. Potresti dire: "Ma 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 è: Sì, questo è ciò che avviene e quello che che deve avvenire su Unix e NFS. Questo 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 che l'utente root dei client non può divenire è l'utente root del server. Nella pagina del man di NFSd ci sono molte altre opzioni squash, e quindi puoi decidere di non dare fiducia a qualsiasi utente dei client. Puoi 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 chiunque. L'nfsd di Linux fa questo controllo per default, ma su altri Sistemi Operativi devi fare questo controllo da solo e 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. Credimi.

6.3 Sicurezza del server: il portmapper

Il portmapper di base ha problemi se usato con nfsd che rendono possibile prendere dei 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 la lista 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 anno da quando il problema è stato reso noto. Almeno una distribuzione contiene ancora un portmapper non sicuro. Un modo facile per controllare se il tuo portmapper è buono oppure no, è quello di lanciare il comando strings(1) per vedere se il portmapper legge i file (importanti per gestire la sicurezza), /etc/hosts.deny e /etc/hosts.allow. Posto che il portmapper è /usr/sbin/portmap puoi 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 editiamo il file /etc/hosts.deny. Dovrebbe contenere la riga:


portmap: ALL

che nega l'accesso a chiunque. Poiché è l'accesso è chiuso, prova il comando rpcinfo -p per testare se il tuo portmapper legge ed 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 metterci dentro. Il file dovrebbe semplicemente avere una lista di tutte le macchine che dovrebbero avere accesso al tuo portmapper. Ci sono comunque pochissimi casi di macchine che necessitano di un accesso totale per qualsiasi ragione. Il portmapper amministra nfsd, mountd, ypbind/ypserv, pcnfsd ed i servizi 'r', come ruptime e rusers. Di questi, solo nfsd, mountd, ypbind/ypserv e forse pcnfsd possono avere qualche conseguenza. Tutte le macchine necessitano accessi ai servizi della tua macchina dovrebbero essere autorizzati a farlo. Diciamo che l'indirizzo della tua macchina è 129.240.223.254 e che è in una sottorete 129.240.223.0 che deve poter accedere ai servizi della macchina (questa è la terminologia introdotta da networking HOWTO, se non ti ricordi rileggilo). Scriviamo quindi:


portmap: 129.240.223.0/255.255.255.0

in hosts.allow. Questo è lo stesso che scrivi 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 mettere 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...

Le cose che abbiamo visto rendono 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 fidata e usando questo privilegio spedisca da una porta sicura come richieste come utente qualsiasi.

6.4 NFS e firewalls

È una buona cosa proteggere con un firewall le porte di nfs e del portmapper sul tuo router o firewall. L'nfsd lavora sulla porta 2049, sia udp che tcp. Il portmapper lavora sulla porta 111, sia tcp che udp. Di solito. Controlla le porte usate con il comando rpcinfo -p.

Se invece NFS deve attraversare un firewall, ci sono delle opzioni sui demoni nfsd e mountd più recenti per usare porte non standard che possono essere tenute aperte attraverso il firewall.

6.5 Riassunto

Se usi hosts.allow/deny, root_squash, nosuid e l'opzione per le porte privilegiate nei programmi portmapper/nfs, eviti la maggior parte dei bugs conosciuti di nfs e puoi stare abbastanza sicuro. Comunque ci sono altri problemi: se qualcuno ha accesso alla rete può far apparire strani comandi nel tuo .forward o leggere la tua posta se le directory /home o /var/spool/mail sono esportate via NFS. Per la stessa ragione, non dovresti mai lasciare le tue chiavi private di PGP su un disco esportato via NFS. O almeno ora sai i rischi che corri.

NFS ed il portmapper formano un sottosistema complesso e quindi non è improbabile che nuovi bugs vengano scoperti, sia nella progettazione che nell'implementazione. Ci possono sempre essere buchi di cui qualcuno sta abusando. Ma questa è a vita. Per tenerti aggiornato su questo genere di problemi dovresti leggere almeno alcuni newsgroup come comp.os.linux.announce e comp.security.announce.


Avanti Indietro Indice