Mi sono imbattuto in molti server NFS aperti, che potrebbero essere resi un po' più sicuri e più sicuri con un paio di rapide modifiche. Questa è una guida rapida, per rendere le cose un po' più sicure. Questa non è affatto una guida completa per la protezione di NFS, ma può rendere le cose un po' più sicure senza troppi sforzi. Per passare a un altro livello, dovresti esaminare l'implementazione di NFSv4 e Kerberos.
Le opzioni di base per le esportazioni possono includere:
- no_all_squash :questa opzione disabilita tutti gli schiacciamenti.
- rw :questa opzione consente al server NFS di utilizzare sia richieste di lettura che di scrittura su un volume NFS.
- ro :questa opzione consente al server NFS di utilizzare richieste di sola lettura su un volume NFS.
- sincronizzazione :questa opzione consente al server NFS di rispondere alle richieste solo dopo che le modifiche sono state salvate in una memoria stabile.
- asincrono :questa opzione consente al server NFS di violare il protocollo NFS e di rispondere alle richieste prima che le modifiche siano state salvate in una memoria stabile.
- protetto :Questa opzione richiede che le richieste provengano da una porta Internet.
- insicuro :questa opzione accetta una o tutte le porte.
- ritardo :questa opzione consente al server NFS di ritardare il commit di una richiesta di scrittura su un disco se sospetta che un'altra richiesta di scrittura correlata possa essere in corso o possa arrivare presto.
- no_wdelay :questa opzione consente al server NFS di consentire il commit di più richieste di scrittura su disco all'interno di una singola operazione. Questa funzionalità può migliorare le prestazioni, ma se un server NFS riceve molte piccole richieste, questo comportamento può peggiorare le prestazioni. Tieni presente che questa opzione non ha alcun effetto se è impostata anche async.
- controllo_sottostruttura :questa opzione abilita il controllo del sottoalbero.
- no_subtree_check :questa opzione disabilita il controllo del sottoalbero, che presenta alcuni problemi di sicurezza impliciti, ma può migliorare l'affidabilità.
- anonuid=UID :queste opzioni impostano in modo esplicito l'uid e il gid dell'account anonimo; questo può essere utile quando vuoi che tutte le richieste appaiano come se provenissero da un singolo utente.
- anongid=GID :questa opzione disabiliterà anonid=UID.
Cos'è root_squash?
root_squash consentirà all'utente root sul client di accedere e creare file sul server NFS come root. Tecnicamente parlando, questa opzione forzerà NFS a cambiare la root del client in un ID anonimo e, in effetti, ciò aumenterà la sicurezza impedendo la proprietà dell'account root su un sistema che migra all'altro sistema. Questo è necessario se stai ospitando filesystem di root sul server NFS (specialmente per client senza disco); con questo in mente, può essere utilizzato (con parsimonia) per host selezionati, ma non dovresti usare no_root_squash a meno che tu non sia consapevole delle conseguenze.
SUID e NFS
suid è un metodo con cui un utente assume i diritti del proprietario di un file quando viene eseguito dall'utente. Perché mi interessa questo? Immagina se un utente fosse in grado di copiare un file sul volume NFS, abilitare il suid bit sul file, quindi eseguirlo sul server o client NFS elevandosi efficacemente a root nel processo?
Ecco un esempio che dimostra i rischi.
Il nome host del server NFS è il server, il nome host del client NFS è il client. La sottorete nella rete di esempio è 192.168.1.0/24. Questo esempio presuppone inoltre che entrambi i sistemi eseguano le stesse versioni del sistema operativo (cioè entrambi sono RHEL 7 o entrambi sono SLES 12), purché le versioni principali del sistema operativo corrispondano.
1. Su un server NFS creare una directory temporanea (/export/test) ed esportare con le seguenti opzioni (sostituire 192.168.1.0/255.255.255.0 con la propria rete/netmask):
server# vi /etc/exports /export/test 192.168.1.0/255.255.255.0(no_root_squash,insecure,rw)
2. Riavviare il server nfs. Questo varia a seconda del gusto di Linux..
RHEL:
server# systemctl restart nfs
SUSE:
server# systemctl restart nfsserver
3. Sul computer client, montare l'esportazione:
client# mkdir /mnt/nfstest client# mount -t nfs server:/export/test /mnt/nfstest
4. Sul client, come utente root, copia il binario vi sul mount NFS.
client# which vi —— output ——— /usr/bin/vi
client# cp /usr/bin/vi /mnt/nfstest
5. Impostare il bit suid sul binario copiato.
client# chmod u+s /mnt/nfstest/vi
6. SSH sul server nfs come utente non privilegiato. Poiché l'utente senza privilegi esegue vi che si trova nel mount esportato sul server:
server$ /export/test/vi /etc/passwd
7. Trova l'account non privilegiato nel file della password e cambia l'UID su 0, salva, disconnetti, quindi accedi nuovamente come utente non privilegiato. L'utente è ora root.
Lo stesso funzionerà sul client, se esegui vi dal mount NFS come utente normale, puoi puntarlo su qualsiasi file sull'host e sarai in grado di modificarlo come root. Funzionerà con qualsiasi binario che ti viene in mente.
Come evitarlo?
1. Prima di tutto elimina il file vi dalla directory di esportazione :), quindi abilita root_squash sull'esportazione nfs. Sul server, modifica di nuovo /etc/exports modifica no_root_squash in root_squash:
server# vi /etc/exports /export/test 192.168.1.0/255.255.255.0(root_squash,insecure,rw)
2. Riavvia il server nfs, rimonta il filesystem sul client:
server# systemctl restart nfs
client# umount /mnt/test client# mount -t nfs server:/export/test /mnt/nfstest
3. Dal client, come root crea alcuni file sul mount NFS, controlla i permessi:
client# touch /mnt/nfstest/{test1,test2,test3} A seconda dei permessi impostati su /export/test, otterrai il permesso negato o se la directory è scrivibile da tutto il mondo, i permessi sui file saranno simili a:
-rw-r--r-- 1 65534 65534 0 Nov 6 2015 test1 -rw-r--r-- 1 65534 65534 0 Nov 6 2015 test2 -rw-r--r-- 1 65534 65534 0 Nov 6 2015 test3
root_squash sta rimappando l'UID root in modo che sia l'uid di un utente anonimo. Questo uid è configurabile nel file exports, man /etc/exports per maggiori informazioni. Copiare di nuovo il comando vi (se consentito) come root sul client sul volume nfs e ripetere i passaggi precedenti (ssh sul server esegui vi su /etc/passwd). Questa volta non avrai l'autorizzazione per salvare il file, le autorizzazioni sono elevate a un account non privilegiato.
Questo è un po' più sicuro, tuttavia non abbiamo ancora finito. Un altro passaggio che puoi fare è montare il filesystem esportato sul server NFS con l'opzione nosuid.
server# vi /etc/fstab
4. Trova il punto di montaggio per /export/, modifica le impostazioni predefinite della colonna delle opzioni in.
/dev/mapper/sys_vg-export_lv /export ext3 defaults 0 0 /dev/mapper/sys_vg-export_lv /export ext3 nosuid 0 0
5. Rimontare il supporto:
server# mount -o remount /export
6. Scarica il file vi sul supporto, imposta il bit suid, passa a un account non privilegiato e riprova:
server# cp /usr/bin/vi /export/test; chmod u+s /export/test/vi
server# su - someuser server$ /export/test/vi /etc/passwd
Dopo aver apportato una modifica al file passato, non ti sarà consentito salvare la modifica.
7. Salta sul client come utente non privilegiato e prova lo stesso:
client$ /export/test/vi /etc/passwd
Funziona ancora, il client deve anche essere rimontato con l'opzione nosuid:
client# mount -t nfs -o nosuid server:/export/test /mnt/nfstest
Testalo di nuovo con l'account non privilegiato, dovrebbe fallire.
Ci sono un paio di altre opzioni che possono essere specificate sul punto di montaggio per limitare ulteriormente ciò che può essere eseguito da esse, controlla noexec (nessun file eseguibile), nodev (nessun file di dispositivo). Se è necessaria ulteriore sicurezza, esamina Kerberos e NFSv4.