NFS HOWTO Nicolai Langfeldt janl@math.uio.no Version 1.02, 19 March 1998 COME installare NFS su client e server. Traduzione di kevin@arena.sci.univr.it Versione traduzione 0.1, 26 Maggio 1998. 1. Introduzione 1.1. Note legali (C)opyright 1997 Nicolai Langfeldt. Do not modify without amending copyright, distribute freely but retain this paragraph. The FAQ section is based on a NFS FAQ compiled by Alan Cox. The Checklist section is based on a mount problem checklist compiled by the IBM Corporation. L'unica licenza valida è quella originale in lingua inglese. Di seguito ne trovate una traduzione abbastanza fedele che però non ha alcun valore. I diritti appartengono a Nicolai Langfeldt. Non modificare nulla senza allegare il copyright, distribuisci liberamente ma mantieni questo paragrafo. La sezione sulle FAQ è basata sulle NFS FAQ di Alan Cox. La sezione Checklist è basata su un problema di mount compilato da IBM Corporation. 1.2. Altre questioni Questo non sarà mai un documento finito, mandami una mail se avrai problemi e successi, potrebbe rendere questo documento migliore. Manda denaro, commenti e/o domande a janl@math.uio.no. Se mandi una E-mail accertati che l'indirizzo di risposta sia corretto e funzionante. Ricevo molte mail e accertarmi di ogni indirizzo sarebbe troppo oneroso. Se vuoi tradurre questo HOWTO fammelo sapere così terrò traccia in quante lingue hanno pubblicato il documento :) Ringrazio Olaf Kirch che mi ha dato spunto e suggerimento per scrivere. Questo HOWTO riguarda il supporto di NFS nel kernel versioni 2.0.X. Ci sono rilevanti migliorie e cambiamenti nella versione 2.1 del kernel. 1.3. Dediche Questo HOWTO è dedicato ad Anne Line Norheim Langfeldt. Probabilmente non lo leggerà mai perché non è quel tipo di ragazza. 2. LEGGIMI NFS, il sistema di condivisione dei dischi via rete, ha tre caratteristiche: · Rende possibile la condivisione dei file in rete. · Funziona abbastanza bene. · Apre dei buchi di sicurezza che sono conosciuti dai cracker, e facilmente utilizzabili per ottenere facilmente accesso (lettura, scrittura e cancellazione) su tutti i tuoi file. Parlerò di questi argomenti in questo HOWTO. Accertati di leggere la sezione relativa alla sicurezza e sarai in grado di limitare al minimo la vulnerabilità ed i rischi. La sezione sulla sicurezza contiene dei passi piuttosto tecnici e richiede alcune conoscenze di reti IP ed i termini ad esse relativi. Se non capisci la terminologia utilizzata fai un passo indietro e leggi il Networking HOWTO oppure acquista un libro relativo all'amministrazione di reti TCP/IP per familiarizzare con TCP/IP. È comunque una buona idea se amministri macchine UNIX/Linux. Un ottimo libro al riguardo è TCP/IP Network Administration di Craig Hunt, pubblicato da O'Reilly & Associates, Inc. Dopo averlo letto e capito, avrai un maggior valore sul mercato del lavoro :) Ci sono due sezioni per aiutarti nella soluzione dei problemi di NFS, chiamate Mount Checklist e FAQs. Fai riferimento ad esse se qualcosa non dovesse funzionare come aspettato. Oh, il sito primario per nfsd per Linux 2.0 è ftp.mathematik.th- darmstadt.de:/pub/linux/okir, nel caso tu volessi o avessi bisogno di scaricarlo e compilartelo. 3. Configurare un server NFS 3.1. Prerequisiti Prima di continuare a leggere questo HOWTO devi poter fare telnet tra due macchine che hai intenzione di configurare come client e server. Se non sei in grado di farlo, leggi il networking/NET-2 HOWTO per installare e configurare correttamente la rete. 3.2. Il primo passo Prima di fare qualsiasi altra cosa, abbiamo bisogno di configurare un server NFS. Se fai parte di un dipartimento o università probabilmente ce ne saranno molti altri già configurati. Se puoi accedervi o stai leggendo questo HOWTO per utilizzarli, non hai bisogno di leggere questa sezione e puoi saltare direttamente alla sezione ``Configurazione di un client NFS'' Se hai bisogno di installare NFS su una macchina che non abbia Linux, allora devi leggere il manuale di sistema per scoprire come abilitare il servizio di NFS ed esportare i file tramite NFS. C'è una sezione apposita in questo HOWTO su come farlo su molti sistemi diversi. Dopo aver configurato tutto, puoi passare alla sezione successiva. Oppure leggi altre parti di questa sezione poiché alcune cose che saranno dette potrebbero essere interessanti anche per altri sistemi, indipendentemente dal tipo di macchina che vuoi usare come server. Quelli di voi che continueranno a leggere, avranno bisogno di configurare alcuni programmi. 3.3. Il portmapper Il portmapper su linux può chiamarsi sia portmap o rpc.portmap. La pagina man sul mio sistema dice che è un "DARPA port to RPC program number mapper". Questo è il primo buco di sicurezza che apri. La descrizione per chiudere alcuni di questi buchi è nella sezione ``Sicurezza ed NFS'', che ti consiglio di leggere con urgenza. Avvio del portmapper. Lo si può fare in due modi: portmap oppure rpc.portmap e li dovresti trovare nella directory /usr/sbin (su alcune macchine si chiama rpcbind). Per ora lo puoi lanciare a mano, ma è necessario che venga lanciato ogni volta che riavvii la macchina, per questo dovrai creare/aggiornare i tuoi scripts rc. Gli script rc sono descritti in maggior dettaglio nella pagina man di init, di solito si trovano in /etc/rc.d, /etc/init.d oppure /etc/rc.d/init.d. Se c'è uno script che ha il nome simile a inet probabilmente è lo script giusto da modificare. Ciò che devi scriverci va oltre lo scopo di questo HOWTO. Avvia portmap e controlla che esso sia correttamente partito con il comando ps aux. È partito ? Bene. 3.4. Mountd e nfsd I prossimi programmi che devono essere lanciati sono mountd e nfsd. Ma prima dobbiamo modificare un altro file. Questa volta /etc/exports. Diciamo che io voglia che il file system /mn/eris/local che risiede su eris possa essere disponibile anche sulla macchina chiamata apollon. Dobbiamo quindi mettere queste righe nel file /etc/exports di eris: ______________________________________________________________________ /mn/eris/local apollon(rw) ______________________________________________________________________ Le righe sopra indicate, consentono l'accesso in lettura e scrittura a /mn/eris/local. Invece di rw potremmo mettere ro che vorrebbe dire accesso in sola lettura (se non metti nulla, è di default a sola lettura). Ci sono altre opzioni che puoi mettere e ne discuteremo alcune relative alla sicurezza più avanti. Le opzioni sono tutte elencate nella pagina man di exports che dovresti leggere almeno una volta nella tua vita. Ci sono modi migliori che elencare gli host nel file exports. Puoi per esempio usare net groups se stai usando le NIS (o NYS), e puoi sempre specificare domini interi oppure sottoreti IP come host autorizzati a montare qualcosa. Ma dovresti considerare che qualcuno non autorizzato potrebbe accedere al server se usi questo tipo di autorizzazioni. Nota: La sintassi del file exports non è la stessa di altri Unix. C'è una sezione separata in questo HOWTO che riguarda il file exports di altri Unix. Ora siamo pronti per lanciare il comando mountd (oppure può chiamarsi rpc.mountd) e quindi nfsd (che potrebbe chiamarsi rpc.nfsd). Entrambi leggono il file exports. Se modifichi il file /etc/exports accertati che nfsd e mountd sappiano che il file è stato cambiato. Il modo tradizionale è lanciare exportfs. Molte distribuzioni non hanno il programma exportfs, allora puoi installare questo script sulla tua macchina: ______________________________________________________________________ #!/bin/sh killall -HUP /usr/sbin/rpc.mountd killall -HUP /usr/sbin/rpc.nfsd echo re-exported file systems ______________________________________________________________________ Salvalo chiamandolo /usr/sbin/exportfs, e non dimenticare di cambiargli i permessi con il comando chmod a+rx. Ora, ogni volta che modifichi il file exports, lancia exportfs come root. Ora dovresti controllare che mountd e nfsd stiano girando correttamente. Prima con rpcinfo -p. Dovrebbe mostrarti qualcosa simile a questo: ______________________________________________________________________ program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100005 1 udp 745 mountd 100005 1 tcp 747 mountd 100003 2 udp 2049 nfs 100003 2 tcp 2049 nfs ______________________________________________________________________ Come vedi il portmapper ha avviato i propri servizi e così pure mountd e nfsd. Se invece ottieni l'errore: rpcinfo: can't contact portmapper: RPC: Remote system error - Connection refused, RPC_PROG_NOT_REGISTERED o qualcosa di simile, allora il portmapper non sta girando. Oppure hai qualcosa nel file /etc/hosts.{allow,deny} che impedisce le a portmapper di rispondere. Avvia il portmapper, oppure rimuovi o rinomina /etc/hosts.{allow,deny}. Se ottieni il messaggio No remote programs registered. allora o il portmapper non vuole risponderti oppure qualcosa non funziona. Killa nfsd, mountd ed il portmapper e riprova la sequenza di avvio dall'inizio. Dopo avere controllato che il portmapper riporti i servizi, puoi controllare anche con ps. Il portmapper continuerà a riportare i servizi anche dopo che il programma che li ha utilizzati termina in maniera non corretta, per cui controllare con il ps può essere utile che sembra che qualcosa non funzioni. Naturalmente, avrai bisogno di modificare i tuoi file rc per avviare mountd e nfsd ed il portmapper quando avvii la macchina. È probabile che gli scripts esistano già sulla tua macchina, devi solo togliere il commento dalle parti che interessano oppure modificare il livello di init affinché queste vengano attivate. Le pagine man che dovrebbero esserti familiari adesso, sono quelle di portmap, mountd, nfsd ed exports. Bene, se hai fatto tutto esattamente come ho detto probabilmente è tutto a posto per iniziare a lavorare sul client NFS. 4. Configurazione di un client NFS Prima di tutto hai bisogno di un kernel che abbia il supporto per NFS compilato staticamente oppure come modulo. Questo lo configuri prima di iniziare la compilazione. Se non hai mai compilato un kernel prima, devi leggere il Kernel HOWTO. Se stai usando una distribuzione fatta bene (come Red Hat [meglio Debian N.d.T]) e non hai mai messo mano al kernel o ai moduli, (rovinandolo ;)), allora nfs dovrebbe essere già disponibile. Ora, dal prompt di root, puoi lanciare il comando appropriato e vedere il file system apparire. Continuando l'esempio della sezione precedente, vogliamo montare la partizione in /mn/eris/local da eris. Ciò è fatto con il comando: ______________________________________________________________________ mount -o rsize=1024,wsize=1024 eris:/mn/eris/local /mnt ______________________________________________________________________ (Torneremo successivamente sulle opzioni rsize e wsize). Il file system è ora disponibile sotto /mnt e puoi fare cd in esso, e con un ls vedere tutti i file che vi sono presenti. Noterai che non è così veloce come su un file system locale, ma molto più conveniente che usare ftp. Se invece di montare il file system, il comando mound produce un errore come mount: eris:/mn/eris/local failed, reason given by server: Permission denied, allora il file exports è errato, oppure hai dimenticato di lanciare il comando exportfs dopo averlo modificato. Se invece dice mount clntudp_create: RPC: Program not registered significa che nfsd oppure mountd non stanno girando sul server. Oppure hai il problema nel file hosts.{allow,deny} di cui abbiamo parlato precedentemente. Per togliere il filesystem, devi usare il comando: ______________________________________________________________________ umount /mnt ______________________________________________________________________ Per fare in modo che il sistema monti file system al boot, devi modificare il file /etc/fstab. Per il nostro esempio devi aggiungere la seguente riga: ______________________________________________________________________ # device mountpoint fs-type options dump fsckorder ... eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024 0 0 ... ______________________________________________________________________ Questo è tutto, più o meno. 4.1. Opzioni del comando mount Ci sono alcune opzioni che dovresti guardare almeno una volta. Governano il modo in cui i client NFS gestiscono i crash della rete o del server. Una delle cose belle di NFS è che questi problemi vengono gestiti molto bene...se configuri i client in modo corretto. Ci sono due tipi di problemi: software Il client NFS sono responsabili di riportare l'errore al processo che sta accedendo ad un file su un file system montato. Alcuni programmi gestiscono la segnalazione, altri no. Non raccomando l'uso di questo parametro. hardware Il programma che tenti di accedere ad un file su un file system NFS si bloccherà quando il server ha un crash. Il processo non potrà essere interrotto o killato a meno che tu non specifichi il parametro intr. Quando il server NFS torna in linea, il programma riprenderà a funzionare correttamente. Questo è probabilmente il funzionamento che vorresti. Raccomando di usare hard,intr su tutti i file system montati via NFS. Riprendendo l'esempio precedente, modifichiamo la linea dell'fstab: ______________________________________________________________________ # device mountpoint fs-type options dump fsckorder ... eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024,hard,intr 0 0 ... ______________________________________________________________________ 4.2. Ottimizzare NFS Normalmente, se non vengono usate le opzioni rsize e wsize, NFS leggerà e scriverà blocchi di 496 o 8192 bytes. Alcune combinazioni di kernel di linux e schede di rete possono non essere in grado di gestire blocchi così grandi o potrebbero non esserlo comunque maniera ottimale. Quindi dobbiamo provare a sperimentare varie dimensioni per determinare quali siano i parametri che funzionino e garantiscano le migliori prestazioni. Puoi provare l'influenza delle opzioni sulla velocità con alcuni semplici comandi. Se hai montato la partizione come sopra ed hai i diritti di scrittura, puoi provare con il seguente test di scrittura sequenziale: ______________________________________________________________________ time dd if=/dev/zero of=/mnt/testfile bs=16k count=4096 ______________________________________________________________________ Questo crea un file di 64MB di zeri (grande abbastanza per fare in modo che l'uso delle cache non sia significativo sulle prestazioni, usa una dimensione maggiore se hai molta memoria disponibile). Lancialo alcune volte (5-10?) e prendi il tempo medio. Il tempo da tenere maggiormente in considerazione è quello indicato con 'elapsed' oppure 'wall clock'. Quindi puoi testare le prestazioni in lettura: ______________________________________________________________________ time dd if=/mnt/testfile of=/dev/null bs=16k ______________________________________________________________________ Fallo alcune volte e fai la media dei tempi. Quindi smonta e rimonta la partizione nuovamente ma con rsize e wsize maggiori. Dovrebbero essere sempre multipli di 1024 e non essere più grandi di 16384, che è la dimensione massima ammessa da NFS versione 2. Dopo averla montata nuovamente, fai un cd nel file system montato e prova qualche semplice comando tipo ls, esplora il file system, eccetera per vedere se il tutto funziona correttamente. I sintomi di rsize/wsize troppo grandi, sono molto strani e per nulla ovvi. Un sintomo tipico è una lista incompleta di file quando viene fatto un 'ls', senza alcun messaggio di errore. Oppure la lettura dei file fallisce miseramente senza messaggi di errore. Dopo avere stabilito che le dimensioni di rsize e wsize funzionano, allora puoi provare i test nuovamente. Server diversi hanno dimensioni ottimali diverse. SunOS e solaris hanno la reputazione di andare molto più veloci con blocchi di 4096 byte. I kernel di linux più recenti (dal 1.3), eseguono un read-ahead per rsize di dimensioni maggiori o uguali alla dimensione della pagina della macchina. Sui processori Intel, la dimensione della pagina è di 4096 byte. Poiché l'uso del read-ahead aumenta significativamente le prestazioni in lettura di NFS, raccomando di settare a 4096 le dimensioni di rsize. Ricorda di modificare /etc/fstab per riflettere le dimensioni di rsize/wsize che hai trovato essere le migliori. Un trucco per accelerare le prestazioni in scrittura di NFS, è quello di disabilitare la scrittura in sincronia sul server. Le specifiche di NFS controllano che le richieste di scrittura sul server non siano considerate terminate finché i dati non siano memorizzati su un supporto non volatile (il disco). Questo limita le prestazioni in scrittura, per cui disabilitando questa caratteristica si otterrà un incremento delle prestazioni. Il nfsd di linux non ha più fatto scritture sincrone da quando non lo fa nemmeno il file system stesso. Su macchine non linux, puoi aumentare le prestazioni modificando in questo modo il file /etc/exports: ______________________________________________________________________ /dir -async,access=linuxbox ______________________________________________________________________ o qualcosa di simile. Fai riferimento alla pagina man relativa al file exports della macchina in questione. Da notare che ciò aumenta la possibilità di perdita di dati. 5. NFS su linee lente Le linee lente includono Modem, ISDN e tutte le le altre connessioni su lunga distanza. Questa sezione si basa sulla conoscenza dei protocolli usati, ma non su prove reali poiché non ho modo di provarli. Fammi sapere le tue esperienze se hai la possibilità di provare ;-) La prima cosa da ricordare è che NFS è un protocollo lento. Ha un grosso overhead di sistema. Usare NFS è come usare il kermit per i trasferire file. È veramente slow. Quasi tutto è più veloce di NFS. FTP è più veloce. HTTP è più veloce. rcp è più veloce. ssh è più veloce. Sei ancora convinto di volerlo provare ? Ok. I parametri di default di NFS sono per linee veloci e con bassa latenza. Se usi questi parametri su linee ad alta latenza si potrebbero verificare errori, operazioni non portate a termine, file che risultano essere più corti di quanto siano in realtà ed altri fatti misteriosi. La prima cosa da fare è di non usare l'opzione per il mount soft. Questo causerebbe dei timeout per ritornare degli errori alle applicazioni, che potrebbero non gestirli correttamente. Questa potrebbe essere la causa di misteriosi fallimenti. Usa invece l'opzione hard. Quando l'opzione hard è attiva, i timeout generano infiniti tentativi invece di terminare l'operazione che il software voleva fare. Ed è ciò di cui hai bisogno. La prossima cosa da fare è ingannare le opzioni timeo e retrans. Sono descritte nella pagina man nfs(5), che è qui riportata [tradotta NdT]: ______________________________________________________________________ timeo=n Il valore, in decimi di secondo prima di tentare una ritrasmissione dopo un RPC timeout. Il valore di default è di 7 decimi di secondo. Dopo il primo timeout, il timeout viene raddoppiato dopo ogni successivo timeout fino ad un massino di 60 secondi oppure non si verifichi un timeout maggiore. Inoltre, se il filesystem è montato in modo hard, ogni nuovo timeout avrà come valore di partenza, il doppio del valore di partenza della sequenza di timeout precedente, che si raddoppia ad ogni ritrasmissione. Il massimo timeout rimane di 60 secondi. Le migliori presta- zioni si raggiungono incrementando il valo- re di timeout quando si monta un disco su una rete lenta, su un server lento oppure attraverso routers e gateway. retrans=n Il numero di timeouts minori e ritrasmis- sioni che si devono verificare prima che si verifichi un timeout maggiore. Il valo- re di default è di 3 timeouts. Quando si verifica un timeout maggiore, viene bloc- cata l'operazione sul file ed un messaggio "server not responding" è stampato sulla console. ______________________________________________________________________ In altre parole: se non viene ricevuta una risposta entro il timeout di 0.7 secondi (700ms) il client NFS ripeterà la richiesta raddoppiando il timeout a 1.4 secondi. Se non si riceve risposta entro 1.4 secondi la richiesta viene ripetuta ancora ed il timeout viene raddoppiato ancora a 2.8 secondi. La velocità di una linea può essere misurata con un ping con le dimensioni del pacchetto e del rsize/wsize uguali. ______________________________________________________________________ $ ping -s 8192 lugulbanda PING lugulbanda.uio.no (129.240.222.99): 8192 data bytes 8200 bytes from 129.240.222.99: icmp_seq=0 ttl=64 time=15.2 ms 8200 bytes from 129.240.222.99: icmp_seq=1 ttl=64 time=15.9 ms 8200 bytes from 129.240.222.99: icmp_seq=2 ttl=64 time=14.9 ms 8200 bytes from 129.240.222.99: icmp_seq=3 ttl=64 time=14.9 ms 8200 bytes from 129.240.222.99: icmp_seq=4 ttl=64 time=15.0 ms --- lugulbanda.uio.no ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 14.9/15.1/15.9 ms ______________________________________________________________________ Il tempo qui è quanto impiega il pacchetto del ping ad andare avanti ed indietro da lugulbanda. 15 ms è abbastanza veloce. Su una linea a 28.800 bps puoi aspettarti qualcosa come 4000-5000ms, e se la linea è molto carica questo tempo sarà ancora più alto, anche doppio. Quando il tempo è elevato, si dice che la linea ha elevata latenza. Generalmente per pacchetti più grandi e per linee cariche, il tempo tende ad aumentare. Aumenta il parametro timeo per adattarlo alla velocità della tua linea ed al carico. E poiché la latenza aumenta se usi la linea per altre cose: se vuoi provare FTP e NFS allo stesso momento, prova a misurare i tempi del ping mentre usi NFS e FTP per trasferire i file. 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. 7. Lista di problemi: Mount Questa sezione è basata sulla lista di problemi di NFS mount di IBM Corp. I miei ringraziamenti a loro per averla resa disponibile per questo HowTo. Se rilevi alcuni problemi montando un file system via NFS, guarda questa lista prima di postare il tuo problema. Ognuno descrive un problema e come risolverlo. 1. Il File system non viene esportato: Fix: Esportalo. 2. La risoluzione del nome non corrisponde con la lista di exports Esempio: la lista di export dice di esportare a johnmad ma il nome di johnmad è risolto in johnmad.austin.ibm.com e quindi il mount viene negato. Fix: Metti nell'export entrambi i nomi. Può anche accadere se il client ha due interfacce con nomi diversi e l'exports ne specifica una sola Fix: metti nell'exports entrambi i nomi. Può anche accadere se il server non riesce ad eseguire le funzioni lookuphostbyname o lookuphostbyaddr sul client. Accertati che il client possa fare host ; host ; e che entrambe mostrino la stessa macchina. Fix: metti a posto la risoluzione dei nomi. 3. Il file system è stato montato dopo che l'NFS è partito (sul server). In questo caso il server sta esportando la directory sottostante NFS e non il filesystem esportato. Fix: Riavvia NFSd. Nota: I client che abbiano già montato il filesystem avranno problemi dopo il riavvio del server. 4. La data è sbagliata su una o entrambe le macchine (ciò può dare problemi usando il comando make) Fix: Correggi la data. L'autore dell'HOWTO raccomanda di usare NTP per sincronizzare gli orologi. Poiché ci sono delle restrizioni su NTP negli USA, devi prelevare le versioni per debian, redhat o slackware da ftp://ftp.hacktic.nl/pub/replay/pub/linux o qualche mirror. 5. Il server non accetta il mount da un utente che è in più di 8 gruppi. Fix: Diminuisci il numero di gruppi cui appartiene o usa un altro utente. 6. Il portmapper del server non è disposto a parlare con te. Fix: Sposta, rimuovi o rinomina /etc/hosts.{allow,deny}. Almeno su Linux questo funziona. Su altri Unix potrebbe trattarsi di altri file. 8. FAQs Questa è la sezione delle FAQ. È basta su una vecchia FAQ di NFS di Alan Cox. 1. Ho un gran numero di errori 'stale nfs handlè quando uso Linux come server NFS Ciò è causato da un bug in alcune vecchie versioni di nfsd. È stato corretto a partire da nfs-server2.2beta16 2. Quando provo a montare un filesystem ottengo can't register with portmap: system error on send Probabilmente stai usando un sistema basato sulla distribuzione Caldera. C'è un bug negli script rc. Contatta Caldera per ottenere la versione corretta. 3. Perché non posso eseguire un file dopo averlo copiato sul server NFS ? Il fatto è che nfsd tiene una cache dei file aperti per motivi di prestazioni (ricorda, gira in un'ambiente utente). Mentre nfsd ha un file aperto (come nel caso di una scrittura), il kernel non ne consente l'esecuzione. Le versioni di nfsd più recenti di spring 95 rilasciano i file aperti dopo qualche secondo, versioni più vecchie possono impiegare anni... 4. I miei file su NFS sono a sola lettura Il default per il server NFS di Linux è di montare i filesystem a sola lettura. RTFM del file exports e nfsd. Avrai bisogno di modificare /etc/exports. 5. Monto una partizione da un server linux, e mentre il comando ls funziona, non riesco a leggere o scrivere i file. Su versioni più vecchie di Linux devi lanciare il server NFS con rsize=1024,wsize=1024. 6. Monto in server NFS Linux con la dimensione dei blocchi tra 3500-4000 regolarmente smette di rispondere. Allora semplicemente non farlo 7. Può Linux gestire NFS via TCP ? Al momento no. 8. Ottengo numerosi strani errori se provo a montare una macchina usando Linux. Accertati che l'utente sia in 8 gruppi o meno. Server più vecchi lo richiedono. 9. Quando riavvio la mia macchina a volte smette di rispondere provando a smontare un NFS server che non risponde. Non smontare un server NFS quando riavvii, ignorali, non causano problemi se non li smonti. Il comando è umount -avt nonfs. 10. I client NFS Linux sono molto lenti quando scrivono su NFS server Sun o BSD. Normalmente NFS scrive i dati in modo sincrono (puoi disabilitare questa modalità se vuoi, ma rischi di perdere dei dati). Peggio lavorano i kernel derivati da BSD, che tendono ad non essere in grado di lavorare in piccoli blocchi, quindi quando tu scrivi 4K di dati da una macchina linux in pacchetti da 1K, BSD fa questo: lettura di una pagina da 4K modifica di 1K scrittura di 4K sul disco fisico lettura di una pagina da 4K modifica di 1K scrittura di 4K sul disco fisico ecc.. 9. Esportare i filesystem Il modo di esportare i filesystem attraverso NFS non è completamente coerente tra le varie piattaforme. In questo caso Linux e Solaris 2 sono le eccezioni. Questa sezione propone una breve lista di modi di farlo sui vari sistemi. Se il tuo sistema non è riportato devi controllare sulle pagine del manuale. Prova a cercare parole come: nfsd, system administration tool, rc scripts, boot scripts, boot sequence, /etc/exports, exportfs. Userò un esempio durante questa sezione: come esportare /mn/eris/local ad apollon in lettura e scrittura. 9.1. IRIX, HP-UX, Digital-UNIX, Ultrix, SunOS 4 (Solaris 1), AIX Questi Sistemi Operativi usano il tradizionale formato di Sun per il file export. In /etc/exports scrivi: ______________________________________________________________________ /mn/eris/local -rw=apollon ______________________________________________________________________ La documentazione completa la trovi nella pagina del manuale di exports. Dopo avere modificato il file, lancia exportfs -av per esportare i filesystem. Quanto sono legate le varie versioni di exportfs circa le variazioni di sintassi ? Su alcuni sistemi troverai che le righe precedenti vengano lette come: ______________________________________________________________________ /mn/eris/local apollon ______________________________________________________________________ oppure possano degenerare in: ______________________________________________________________________ /mn/eris/local rw=apollon ______________________________________________________________________ Raccomando di essere formali, altrimenti rischi che la versione successiva di exportfs sia più sensibile e che quindi non funzioni più nulla. 9.2. Solaris 2 Sun ha completamente reinventato la ruota quando fecero Solaris 2. Quindi la loro sintassi è completamente diversa da quella di tutti gli altri. Ciò che devi fare è modificare il file /etc/dfs/dfstab. Questo file deve contenere i comandi share, come descritto nella pagina del manuale share(1M). Ad esempio: ______________________________________________________________________ share -o rw=apollon -d "Eris Local" /mn/eris/local ______________________________________________________________________ Dopo avere modificato il file, lancia il programma shareall per esportare il filesystem. 10. PC-NFS Non dovresti usare PC-NFS, ma samba. Mi spiace, non conosco nulla di PC_NFS. Se qualcuno vuole scriverci qualcosa lo faccia, ed io lo includerò qui.