NFS chiffré avec OpenSSH et Linux

Posté par DAGAN Alexandre (site web personnel) le 14 février 2002 à 10:29. Modéré par Yann Kerhervé.

Étiquettes : aucune

fév.

2002

" Le gros problème avec NFS c'est que cela repose sur le protocole UDP qui est, par nature, non-sécurisé; les transactions circulent en clair sur le réseau. De plus, les utilisateurs et les machines ne peuvent pas être facilement identifiés. Enfin, ce système est très difficile à sécuriser par un firewall.

L'article de Samag fournit une solution à la plupart de ces problèmes pour des serveurs et clients tournant sous Linux.

Ces principes peuvent bien sur être appliqués à n'importe quel serveur UNIX disposant de ssh."

NdR: Traduction de la nouvelle de RootPrompt

Aller plus loin

L'article sur Samag (211 clics)
La nouvelle sur RootPrompt (95 clics)

# Oui...

Posté par nodens le 14 février 2002 à 11:12. Évalué à 10.

C'est assez connu je pense comme méthode, mais c'est une bonne idée d'avoir fait un pas à pas comme ça, la page de manuel de ssh n'étant pas très explicite, même si elle évoque la possibilité de faire ce genre de chose.

<Troll mode=gentil>
D'ailleurs, qui lit les pages de manuel, de nos jour ?
</troll> ;-).
D'ailleurs, avec samba, ça marche aussi. n'est-ce pas Alenvers ? "le micro-howto samba over ssh en 1 ligne" ... ;-)
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 14 février 2002 à 11:27. Évalué à 10.
  
  Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: Oui...
    
    Posté par nodens le 14 février 2002 à 11:54. Évalué à -5.
    
    comme quoi, on raconte pas que des conneries sur #linuxfr ;-)
# cool... mais

Posté par - neuro (site web personnel) le 14 février 2002 à 11:19. Évalué à 10.

c'est une bonne idee mais...
NFS n'est pas en soi particulierement rapide, ca risque pas de ralentir encore le shmilblik si on doit tout crypter en ssh?
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 14 février 2002 à 11:37. Évalué à 10.
  
  Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: cool... mais
    
    Posté par nodens le 14 février 2002 à 12:04. Évalué à 8.
    
    Auquel cas le CPU sera encore plus mis à contribution, est-il besoin de le préciser...
    
    A noter que ce n'est intéressant qu'a partir d'un certain débit moyen, i.e des fichiers assez gros.
    Et pour les amateurs, je me permet de faire de la pub pour le bouquin O'reilly SSH, le shell sécurisé - La référence, qui est très bien.
  - [^] # Re: cool... mais
    
    Posté par Babou le 14 février 2002 à 14:29. Évalué à 8.
    
    Sur du 10mb c bon en effet. Sur du 100mb, j'arrive à
    peine à faire du 1.5~2Mo/s (100mb-> 11Mo/s maxi). via ssh (par scp, sur un gros fichier).
    Je fais pas vraiment mieux par NFS. Par FTP c bon,
    je fais 9~10Mo/s soit à peu près le maxi. A ce niveau, les CPU carburent pas mal et c presque les disques qui limitent.
    
    NFS est pas gégé (selon moi) mais on pas encore vraiment mieux.
    - [^] # Re: cool... mais
      
      Posté par VACHOR (site web personnel) le 14 février 2002 à 14:36. Évalué à 10.
      
      Oui normalement le chiffrage/déchiffrage à clefs synmétriques ça prend pas trop de CPU. Sur des machines modernes ça carbure !
      Pour aller encore plus vite, choisissez de préférence Blowfish comme algo, c'est normalement le + rapide.
      - [^] # Re: cool... mais
        
        Posté par kalahann le 14 février 2002 à 20:47. Évalué à 2.
        
        Je pense que sur un serveur NFS qui ne fait que ça, ça ne pausera pas trop de problèmes, mais sur la machine cliente, si elle n'est pas puissante ça risque pas de la ralentir sérieusement? Si la copie nfs + (dé)chiffrement prend 20% du temps CPU constemment, c'est un peu chiant!
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 15 février 2002 à 12:14. Évalué à 1.
        
        Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: cool... mais
  
  Posté par Alphonse Oncle le 14 février 2002 à 12:24. Évalué à 6.
  
  Cool mais... faudrait deja que le nfs soit stable en milieu heterogene et ca c'est pas encore gagne...
  - [^] # Re: cool... mais
    
    Posté par Thomas Poindessous le 14 février 2002 à 13:38. Évalué à 3.
    
    Surtout que les clients dans cet exemple doivent être obligatoirement des clients Linux.
    
    Pour la vitesse, ca ralentit forcément, vu que ca crypte, mais ca peut etre intéressant pour ceux pour qui la sécurité prime sur la vitesse. Et ca évite de mettre en place un VPN IPSEC.
    
    Pour la ligne de commande, son exemple est un peu compliqué. Chez moi, j'ai juste besoin de (avec une clé, sans passphrase)
    
    ssh user@machine -L 3045:nfs1:945 -N &
    
    C'est drolement pratique.
    - [^] # Re: cool... mais
      
      Posté par Stephane JUTIN le 14 février 2002 à 17:53. Évalué à 6.
      
      Perso je suis contre l'introduction de multiples couches crypto au dessus de la couche TCP (SSL, TLS, et maintenant SSH) ...
      Je pense que la crypto à plutôt sa place en couche 3, au niveau IPSec, ça la rends vraiment indépendante de l'appli
      
      Au fait, comment fonctionne IPSec lorsqu'il est en mode non connecté ? L'échange des clés publiques, l'envoi d'une clé de session symétrique, tout ça ça nécessite une mémoire d'état, donc plutôt un protocole connecté.
      
      Peut-être, il y a t'il une sorte de cache, qui négocie une clé privée pour chaque nouvelle IP, la mémorise puis l'utilise pour tout les paquets destinée à cette IP (quel que soit le port) jusqu'à expiration ...
      
      ca évite de mettre en place un VPN IPSEC.
      Oui, c'est vrai que pour l'instant IPSec c'est VPN-only, mais sur le long terme (Ipv6) ça devrait être implémenté au niveau hôte.
      Et là exit les bidouillages style SSH port forwarding, l'IP spoofing (le noyau authentifie chaque IP via une clé publique, enfin je crois ?) ...
- [^] # Re: cool... mais
  
  Posté par Remi Cellier le 14 février 2002 à 16:00. Évalué à 6.
  
  en plus dans l'article : since ssh cannot do anything with UDP packets at present.
  
  Donc on passe du protocole UPD à TCP qui est quand meme plus lourd au niveau charge réseau. Avec l'encryption en plus ... je suis pas sur que ça soit une bonne idée pour tout le monde ( par exemple quand on administre comme moi des vieux 486 et pentium).
  
  AMHA dans les machines sont sur le meme LAN, faut mieux isoler le reseau NFS avec un switch ( protection au niveau adresse MAC), et faire du tcpwrapper ( au niveau IP).
  
  L'exemple donné à mon avis sert à faire du NFS entre deux LAN séparés par un espace non sécurisé ... et c'est déjà une bonne nouvelle ;)
- [^] # cool... mais
  
  Posté par kalahann le 14 février 2002 à 20:52. Évalué à 2.
  
  J'ai une idée, et en même temps une question.
  Et si on ne chiffrait pas par ssh? on s'en servirai uniquement pour l'authentification des clients et du serveur, et les fichiers passeraient en clair.
  Evidemment, faut avoir besoin seulement de l'authentification...
# Admin reseau.

Posté par Eddy le 14 février 2002 à 15:56. Évalué à 3.

Je vais envoyer ce lien au chef info.
il veut pas monter les disques en NFS, c'est pa assez sur, dit-il.
Avec ca, plus aucune raison de refuser.
# NFS et Firewalls (!)

Posté par Ludovic Boisseau le 14 février 2002 à 19:14. Évalué à 10.

J'allucine, là... D'une part c'est lourd, mais en plus, la niouze contient une phrase qui m'étonne (et c'est peu de le dire) :

Enfin, ce système est très difficile à sécuriser par un firewall.

Huuummmm... quelqu'un peut me dire dans quel contexte un flux NFS doit traverser un firewall ? La tendance actuelle est plutôt d'isoler ce genre de trafic sur un LAN dédié (un SAN ou quelquechose du genre...). En effet, NFS est très gourmand, et a une légère tendance à saturer les réseaux. Il faut dire que les fichiers que l'on transfère aujourd'hui n'ont plus grand chose à voir avec ce que l'on faisait au moment de la conception de NFS... Même si entre temps, on est passé de 10Mbps à 100Mbps...

PS : si un flux NFS doit passer un firewall, j'ose à peine imaginer la puissance de la machine qui fera office de firewall... Au fait, quelqu'un a déjà tenté de mettre un firewall Linux (ou BSD) entre deux LANs à 100Mbps et de faire passer un max de connexions avec des protos bizzares, des petits paquets et plein de cochonneries pour voir si la bécane arrive à suivre ?
- [^] # NFS et Firewalls (!)
  
  Posté par kalahann le 15 février 2002 à 00:11. Évalué à 1.
  
  Au hasard, si tu n'a pas confiance en ton serveur nfs tu peux le mettre dans la MDZ, encadrée par des firewalls.
- [^] # Re: NFS et Firewalls (!)
  
  Posté par PLuG le 15 février 2002 à 09:41. Évalué à 4.
  
  moi j'ai deja mis un firewall iptables entre deux anneaux token-ring en 16Mbps full duplex.
  rien a dire, le firewall n'etait pas un frein pour le reseau qui utilise plein de protocoles IP différents et des petits paquets (telnet 3270, icq, ftp, nfs, afs, ...).
  la machine: un PIII a 800Mhz
  la charge cpu: 5% pour le kernel (firewall).
  du coup je faisait meme tourner un script perl pour faire des stats d'utilisation du reseau !!

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.