Systèmes de fichiers réseau sécurisés pour Linux: que font les gens?

26

NFSv3 est répandu, mais le modèle de sécurité par défaut est ... pittoresque . CIFS peut utiliser l'authentification Kerberos, mais sans la sémantique POSIX, ce n'est pas un démarreur. AFS n'a jamais chiffré le trafic sur le câble et est krb4 - et, fondamentalement, un projet mort. De nouveaux systèmes de fichiers expérimentaux fantaisistes ne se matérialisent jamais ou sont axés sur la vitesse (et si vous êtes chanceux, la fiabilité des données) - par exemple, Luster utilise le même modèle de confiance client que NFSv3. Pour un usage domestique, sshfs est astucieux, mais cela ne se redimensionne pas.

Et puis bien sûr, il y a NFSv4, avec sec = krb5p. Génial en théorie, mais après dix ans, il semble être troublant dans le monde réel. Le client Linux vient de retirer la balise expérimentale. Et si vous regardez EMC Celerra, Isilon, etc., tout est NFSv3. (Celerra prend en charge NFSv4, mais il est vraiment enterré dans la documentation. Isilon a apparemment travaillé à l'ajout de la prise en charge RPCGSS à FreeBSD, alors peut-être que ça arrive, mais il n'est pas là maintenant.) Je ne peux même pas marquer ce post comme "nfsv4" parce que je suis nouveau ici et ce serait une nouvelle balise .

Alors vraiment . Que faites vous tous?

mattdm
la source
Je voudrais dire "NFS3 sur IPSEC", mais je ne peux pas.
sysadmin1138
1
"NFS3 sur IPSEC" aide à résoudre le problème sur le fil, mais ne résout pas un autre problème NFS fondamental: si une boîte cliente est enracinée, ou si vous êtes dans un environnement où les utilisateurs se rootent sur leurs propres systèmes, ils peut usurper l'identité de n'importe quel utilisateur distant.
mattdm
Voilà, nouveau tag;)
Cry Havok
1
AFAIK, Kerberos a été défini pour NFS
Javier
2
Je ne suis pas sûr de la nécessité de chiffrer le trafic sur le câble dans un environnement LAN (l'authentification doit cependant être chiffrée). Vous devriez quand même surveiller l'empoisonnement ARP ...
Hubert Kario

Réponses:

8

Puisqu'il s'agit d'une question spécifique (que faites-vous tous), répondons-y: rien. La plupart des administrateurs et des utilisateurs ne se soucient pas de la sécurité NFS, donc tout le monde utilise NFSv3. Il s'agit généralement d'un environnement contrôlé (dans le sens où seules les machines bien connues peuvent se connecter au réseau en premier lieu). Si quelqu'un se fait prendre en train d'abuser de l'infrastructure, il est renvoyé ou emprisonné.

Pour les données que vous ne voulez vraiment pas que quiconque puisse lire, vous les chiffrez explicitement, par exemple les bases de données de mots de passe Firefox, les clés ssh ou les clés pgp. Vous faites cela parce que vous savez que l'administrateur peut les lire sur le serveur de fichiers, de sorte que la sécurité du système de fichiers réseau ne sera d'aucune aide.

Martin c. Löwis
la source
14

Vous semblez poser deux questions ici:

Qu'utilisons-nous réellement? et qu'est-ce que cela?

Ce que j'utilise en fait est CIFS, dans mes cas d'utilisation POSIX est moins important, donc je n'ai eu aucun problème. NFS3 est utilisé dans des zones où la sécurité n'est pas importante, comme mon serveur d'installation SLES. Et enfin, sshfs / gvfs pour un partage simple de l'espace utilisateur. Le chiffrement filaire n'est pas jugé nécessaire, ce n'est donc pas un facteur significatif pour nous.

Quant à l'autre question, il semble y avoir six exigences principales pour ce que vous recherchez:

  1. Chiffre le trafic sur le câble.
  2. Crypte l'authentification.
  3. Sémantique Posix.
  4. Forte application des ACL basées sur le serveur.
  5. N'est pas un espace utilisateur.
  6. Est réellement utilisé.

Je soupçonne que les points 5 et 6 seront les tueurs ici, mais c'est parti (aussi, c'est le point où une table serait vraiment pratique, mais markdown / StackExchange ne la prend pas en charge).

NFSv3 + IPSec

  1. Chiffré sur le fil, passez
  2. Aucune authentification chiffrée, échec
  3. Posix sémantique, passe
  4. Aucune application stricte des listes de contrôle d'accès basées sur serveur, échec
  5. N'est pas un espace utilisateur, passez
  6. Est réellement utilisé, passez

NFSv4 + Krb + IPSec

  1. Chiffré sur le fil, passez
  2. Authentification cryptée, réussite
  3. Posix sémantique, passe
  4. Forte application des ACL basées sur le serveur, réussite
  5. N'est pas un espace utilisateur, passez
  6. N'est pas réellement utilisé, échoue

CIFS

  1. Non chiffré sur le fil, échec
  2. Authentification cryptée
  3. Sémantique Posix, passe (Samba & Kernel maintenant, Windows a une couche Posix depuis les jours NT)
  4. Forte application des ACL basées sur le serveur, réussite
  5. N'est pas un espace utilisateur, passez
  6. Est réellement utilisé, passez

CIFS + IPSec

  1. Chiffré sur le fil, passez
  2. Authentification cryptée
  3. Posix sémantique, passe (Samba & Kernel maintenant)
  4. Forte application des ACL basées sur le serveur, réussite
  5. N'est pas un espace utilisateur, passez
  6. N'est pas réellement utilisé, échoue

SSHFS

  1. Chiffré sur le fil, passez
  2. Authentification cryptée, réussite
  3. Posix sémantique, passe
  4. Forte application des ACL basées sur le serveur, réussite
  5. Is userland, fail
  6. Est réellement utilisé, passez

AFP / NetATalk

  1. Chiffré sur le fil, échec
  2. Authentification cryptée, réussite
  3. Posix sémantique, passe
  4. Forte application des ACL basées sur le serveur, réussite
  5. N'est pas un espace utilisateur, passez
  6. Est réellement utilisé, échoue

Et je ne touche pas aux systèmes de fichiers distribués. Il n'y a tout simplement pas une seule chose qui fait tout. Certains se rapprochent (CIFS) et certains sont déjà là mais personne ne les utilise (NFS4 + IPSec, CIFS + IPSec). Pour une raison quelconque, un système de fichiers réseau sécurisé est quelque chose qui a été soumis à de nombreux compromis au fil des ans.

sysadmin1138
la source
Vous auriez pu mentionner "NFSv4 + Krb" et ajouter "7. Est-il raisonnablement rapide (c'est-à-dire par rapport à la même pile de protocoles sans chiffrement)?" comme une question. Ce qui serait probablement un échec pour NFSv4 + krb5p, mais passez aux questions 1-6.
al.
pourrait-il être temps pour un nouveau système de fichiers réseau sécurisé SNFS?
The Unix Janitor
@ user37899 Le problème, comme toujours, est de convaincre les fournisseurs d'appareils de le prendre en charge et les organisations de le déployer.
sysadmin1138
1
Nous avons eu beaucoup de mal à essayer d'utiliser CIFS en mode POSIX. Il est peut-être temps de revoir cela.
mattdm
FWIW J'utilise CIFS + IPsec, mais pas avec la sémantique POSIX. le serveur est emc celerra, les clients win7. tunnels ipsec effectués en mode lan à lan entre Cisco ASA (à côté de celerra) et l'ipsec intégré win7.
Dan Pritts
3

J'utilise openafs en production depuis des années, avec des clients Linux et Windows. Il fonctionne très bien, possède une communauté de développement active et est devenu beaucoup plus facile à installer et à administrer au cours des dernières années, car les différentes distributions Linux ont inclus un emballage pour cela. Il a ses verrues, mais j'ai trouvé qu'elles sont compensées par une plus grande flexibilité administrative, la possibilité de séparer les clients et les serveurs par des liaisons lentes, la facilité des sauvegardes hors site et d'autres AFSismes positifs.

Une chose que j'aime en particulier, c'est d'exécuter des serveurs Web de production sur Internet sur openafs, avec les ACL verrouillées. Sans ticket kerberos, il n'y a aucun processus sur la machine - même un qui s'exécute en tant que root - qui peut écrire dans le système de fichiers. Je ne peux pas compter combien de fois nous avons remarqué que les attaques échouaient complètement à cause de cette simple mesure.

Il y a de très gros utilisateurs d'Openafs - le plus grand utilisateur commercial que je connaisse est Morgan Stanley.

stevegt
la source
1

Qu'en est-il d'OpenAFS qui est toujours en vie et d'un VPN sous lui car son seul cryptage pour le moment est DES.

Rob Olmos
la source
2
J'ai utilisé OpenAFS en production. Les rumeurs de sa vivacité sont grandement exagérées.
mattdm
Il y a eu une nouvelle version ce mois-ci et avant cela, il y a eu des mises à jour assez régulières pour prendre en charge les nouvelles versions de Windows et les nouvelles versions du noyau Linux (la dernière version prend en charge 3.0).
Hubert Kario
1

Je vois que beaucoup de gens dans ce fil parlent de masquage de données, c'est-à-dire que les attaques ne peuvent pas espionner vos données. Il est également important de penser à l'intégrité et à l'authenticité des données. Ces paquets nfs proviennent-ils vraiment de votre serveur nfs? Un paquet nfs a-t-il été modifié en transit?

Le concierge Unix
la source
NFS sur IPsec s'en charge (sur les liaisons étendues) et la surveillance de l'empoisonnement ARP le fait sur LAN
Hubert Kario
est-ce que quelqu'un utilise réellement ipsec avec succès?
The Unix Janitor du
1

Eh bien, pour moi, il semble que l'un de ces systèmes de fichiers distribués serait pour vous. Je ne voudrais pas vraiment recommander OpenAFS, car il est ancien, ne prend pas encore en charge IPv6, ..

Je suis assez content de GlusterFS moi-même. Gluster est assez mature, fonctionne bien et possède un bon ensemble de fonctionnalités. Cependant, comme récemment discuté dans IRC, Gluster ne prend pas non plus en charge IPv6 de manière stable. Cette fonctionnalité sera programmée pour 3.6 ou 3.7.

Il existe également un projet appelé HekaFS, qui s'appuie sur Gluster, qui ajoute des fonctionnalités d'authentification plus avancées et SSL. Il est extrêmement bien documenté et très bien conçu.

Ce qui peut également vous intéresser est XtreemFS , qui est conçu pour le calcul de grille mondial, il est donc livré avec SSL et d'autres éléments par défaut. Mon choix d'utilisation est tombé sur Gluster, car la communauté semble plus active et bien mieux documentée.

Les deux sont bien sûr compatibles avec Posix.

juwi
la source
0

J'utilise NFS. Mais le serveur à serveur NFS se fait sur une dorsale réseau dédiée, donc le chiffrement n'est pas nécessaire et l'authentification est en quelque sorte inutile. Définissez simplement chaque exportation pour partager uniquement un répertoire sélectionné avec un serveur basé sur IP.

Porche
la source
réseau dédié, jusqu'à ce que quelqu'un se connecte au commutateur de rack avec wirehark.
The Unix Janitor
C'est alors un problème de sécurité physique. Une fois qu'ils sont dans la même pièce que les serveurs, le jeu se termine quand même.
Porche
-2

Avec tout le respect que je vous dois, vous regardez complètement ce problème dans le mauvais sens et vous devriez vous éloigner de la console pendant quelques heures.

Presque tout le stockage io n'est pas chiffré car cela n'a pas d'importance au niveau de cette couche de la pile d'abstraction. J'en doute? Mettez un robinet sur votre commutateur fibre brocart et vous verrez que le canal fibre, tout comme iscsi et nfs, est tout un désordre non chiffré - par conception. Résoudre ce problème est moyen, pas un problème de protocole de stockage. Par exemple, vous voulez des nfs sécurisés et chiffrés? Création d'un lan chiffré point à point entre le client nfs et le serveur à l'aide d'ipsec / ssl / tls ou d'une solution matérielle pure.

Rafael Ferreira
la source
Je pense que vous manquez un point clé. Comme le dit la question, le problème vient du modèle de sécurité NFS. Bien que le chiffrement soit agréable, c'est, comme vous le dites, un problème résoluble. Le gros problème avec NFS est qu'une fois qu'un système de fichiers est monté sur un système, toute personne ayant un accès root sur ce système peut accéder à n'importe quel fichier sur ce système de fichiers, indépendamment de la propriété ou des autorisations. Un système comme AFS ou, en théorie, NFSv4 avec sec = krbp5, nécessite des informations d'identification solides pour accéder aux fichiers, et représente donc une augmentation substantielle de la sécurité. Un client NFS enraciné n'équivaut pas à une exposition massive de données.
larsks
1
Sauf si vous demandez à l'utilisateur d'entrer des informations d'identification pour chaque accès, les informations d'identification seront stockées. Un client root compromis est susceptible d'abandonner facilement la clé stockée. Tout système de fichiers en réseau augmentera l'exposition du système de fichiers aux compromis.
BillThor
@BillThor C'est ce que je pensais .. Est-il toujours ouvert aux attaques si les informations d'identification sont dans la mémoire du noyau? Je pense qu'un module du noyau pourrait être chargé pour lire n'importe quel morceau de mémoire du noyau.
Rob Olmos
Tant que la demande est utilisée dans le contexte d'un utilisateur ayant accès au stockage partagé, peu importe où se trouvent les informations d'identification. Les informations d'identification sont souvent détenues par un processus d'arrière-plan, de sorte que quiconque peut communiquer avec lui peut probablement accéder au stockage partagé. Je classerais le risque pour le stockage réseau sécurisé à peu près comme le stockage local.
BillThor
2
@BillThor: avec kerberos, le risque est considérablement atténué, car l'attaquant n'aurait accès qu'aux systèmes de fichiers des utilisateurs qui ont transféré leurs tickets, et uniquement pour la durée de vie de ces tickets. Avec l'authentification basée sur le système (à la nfsv3), root peut accéder et manipuler les fichiers de n'importe quel utilisateur, même si cet utilisateur n'a jamais rien à voir avec le système compromis.
mattdm