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