J'ai rencontré de nombreux serveurs NFS largement ouverts, qui pourraient être rendus un peu plus sûrs et plus sûrs avec quelques changements rapides. Il s'agit d'un guide rapide qui rend les choses un peu plus sûres. Ce n'est en aucun cas un guide complet pour sécuriser NFS, mais il peut rendre les choses un peu plus sûres sans trop d'efforts. Pour passer à un autre niveau, vous souhaitez envisager d'implémenter NFSv4 et Kerberos.
Les options de base pour les exportations peuvent inclure :
- no_all_squash :Cette option désactive tous les écrasements.
- rw :Cette option permet au serveur NFS d'utiliser à la fois les requêtes de lecture et d'écriture sur un volume NFS.
- ro :Cette option permet au serveur NFS d'utiliser des requêtes en lecture seule sur un volume NFS.
- synchroniser :Cette option permet au serveur NFS de répondre aux requêtes uniquement après que les modifications ont été validées dans un stockage stable.
- asynchrone :Cette option permet au serveur NFS de violer le protocole NFS et de répondre aux requêtes avant que les modifications n'aient été validées dans un stockage stable.
- sécurisé :Cette option nécessite que les requêtes proviennent d'un port Internet.
- non sécurisé :Cette option accepte tout ou partie des ports.
- wdélai :Cette option permet au serveur NFS de retarder la validation d'une demande d'écriture sur un disque s'il soupçonne qu'une autre demande d'écriture associée est en cours ou peut arriver bientôt.
- no_wdelay :Cette option permet au serveur NFS d'autoriser la validation de plusieurs demandes d'écriture sur le disque en une seule opération. Cette fonctionnalité peut améliorer les performances, mais si un serveur NFS reçoit de nombreuses petites requêtes, ce comportement peut dégrader les performances. Vous devez savoir que cette option n'a aucun effet si async est également défini.
- subtree_check :Cette option active la vérification des sous-arborescences.
- no_subtree_check :Cette option désactive la vérification des sous-arborescences, ce qui implique des problèmes de sécurité, mais elle peut améliorer la fiabilité.
- anonuid=UID :Ces options définissent explicitement l'uid et le gid du compte anonyme; cela peut être utile lorsque vous souhaitez que toutes les demandes apparaissent comme si elles provenaient d'un seul utilisateur.
- anongid=GID :Cette option désactivera anonuid=UID.
Qu'est-ce que root_squash ?
root_squash permettra à l'utilisateur root sur le client d'accéder et de créer des fichiers sur le serveur NFS en tant que root. Techniquement parlant, cette option forcera NFS à changer la racine du client en un ID anonyme et, en effet, cela augmentera la sécurité en empêchant la propriété du compte root sur un système de migrer vers l'autre système. Cela est nécessaire si vous hébergez des systèmes de fichiers racine sur le serveur NFS (en particulier pour les clients sans disque); dans cet esprit, il peut être utilisé (avec parcimonie) pour les hôtes sélectionnés, mais vous ne devez pas utiliser no_root_squash à moins que vous ne soyez conscient des conséquences.
SUID et NFS
suid est une méthode d'un utilisateur assumant les droits du propriétaire d'un fichier lorsqu'il est exécuté par l'utilisateur. Pourquoi est-ce que je m'en soucie ? Imaginez si un utilisateur était capable de copier un fichier sur le volume NFS, d'activer le suid bit sur le fichier, puis de l'exécuter sur le serveur ou le client NFS en s'élevant efficacement à la racine dans le processus ?
Voici un exemple démontrant les risques.
Le nom d'hôte du serveur NFS est le serveur, le nom d'hôte du client NFS est le client. Le sous-réseau de l'exemple de réseau est 192.168.1.0/24. Cet exemple suppose également que les deux systèmes exécutent les mêmes versions de système d'exploitation (c'est-à-dire que les deux sont RHEL 7, ou les deux sont SLES 12), tant que les versions principales du système d'exploitation correspondent.
1. Sur un serveur NFS, créez un répertoire temporaire (/export/test) et exportez avec les options suivantes (remplacez 192.168.1.0/255.255.255.0 par votre propre réseau/masque de réseau) :
server# vi /etc/exports /export/test 192.168.1.0/255.255.255.0(no_root_squash,insecure,rw)
2. Redémarrez le serveur nfs. Cela varie en fonction de la saveur de Linux..
RHEL :
server# systemctl restart nfs
SUSE :
server# systemctl restart nfsserver
3. Sur la machine cliente, montez l'export :
client# mkdir /mnt/nfstest client# mount -t nfs server:/export/test /mnt/nfstest
4. Sur le client, en tant qu'utilisateur root, copiez le binaire vi sur le montage NFS.
client# which vi —— output ——— /usr/bin/vi
client# cp /usr/bin/vi /mnt/nfstest
5. Définissez le bit suid sur le binaire copié.
client# chmod u+s /mnt/nfstest/vi
6. SSH sur le serveur nfs en tant qu'utilisateur non privilégié. En tant qu'utilisateur non privilégié, exécutez le vi situé dans le montage exporté sur le serveur :
server$ /export/test/vi /etc/passwd
7. Recherchez le compte non privilégié dans le fichier de mots de passe et changez l'UID en 0, enregistrez, déconnectez-vous puis reconnectez-vous en tant qu'utilisateur non privilégié. L'utilisateur est maintenant root.
La même chose fonctionnera sur le client, si vous exécutez le vi à partir du montage NFS en tant qu'utilisateur régulier, vous pouvez le pointer vers n'importe quel fichier sur l'hôte et pourrez le modifier en tant que root. Cela fonctionnera avec n'importe quel binaire auquel vous pouvez penser.
Comment éviter cela ?
1. Tout d'abord, supprimez le fichier vi du répertoire d'exportation :), puis activez root_squash sur l'exportation nfs. Sur le serveur éditez à nouveau le /etc/exports modifiez le no_root_squash en root_squash :
server# vi /etc/exports /export/test 192.168.1.0/255.255.255.0(root_squash,insecure,rw)
2. Redémarrez le serveur nfs, remontez le système de fichiers sur le client :
server# systemctl restart nfs
client# umount /mnt/test client# mount -t nfs server:/export/test /mnt/nfstest
3. Depuis le client, en tant que root, créez des fichiers sur le montage NFS, vérifiez les autorisations :
client# touch /mnt/nfstest/{test1,test2,test3} En fonction des autorisations définies sur /export/test, vous obtiendrez soit une autorisation refusée, soit si le répertoire est accessible en écriture par tout le monde, les autorisations sur les fichiers ressembleront à :
-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
Le root_squash remappe l'UID racine pour qu'il soit l'UID d'un utilisateur anonyme. Cet uid est configurable dans le fichier exports, man /etc/exports pour plus d'informations. Copiez à nouveau la commande vi (si cela est autorisé) en tant que root sur le client vers le volume nfs et répétez les étapes ci-dessus (ssh vers le serveur, exécutez vi sur /etc/passwd). Cette fois, vous n'aurez pas la permission d'enregistrer le fichier, les permissions sont élevées à un compte non privilégié.
C'est un peu plus sûr, mais nous n'avons pas encore fini. Une autre étape consiste à monter le système de fichiers exporté sur le serveur NFS avec l'option nosuid.
server# vi /etc/fstab
4. Trouvez le point de montage pour /export/, modifiez les valeurs par défaut de la colonne d'options.
/dev/mapper/sys_vg-export_lv /export ext3 defaults 0 0 /dev/mapper/sys_vg-export_lv /export ext3 nosuid 0 0
5. Remontez le support :
server# mount -o remount /export
6. Videz le fichier vi sur le montage, définissez le bit suid, passez à un compte non privilégié et réessayez :
server# cp /usr/bin/vi /export/test; chmod u+s /export/test/vi
server# su - someuser server$ /export/test/vi /etc/passwd
Après avoir apporté une modification au fichier transmis, vous ne serez pas autorisé à enregistrer la modification.
7. Sautez sur le client en tant qu'utilisateur non privilégié et essayez la même chose :
client$ /export/test/vi /etc/passwd
Cela fonctionne toujours, le client doit également être remonté avec l'option nosuid :
client# mount -t nfs -o nosuid server:/export/test /mnt/nfstest
Testez-le à nouveau avec le compte non privilégié, cela devrait échouer.
Il existe quelques autres options qui peuvent être spécifiées sur le point de montage pour restreindre davantage ce qui peut être exécuté à partir d'eux, consultez le noexec (pas de fichiers exécutables), nodev (pas de fichiers de périphérique). Si une sécurité supplémentaire est requise, examinez Kerberos et NFSv4.