# [NFS] aucune sécurité, c'est moche ...

## loopx

Je viens de voir ceci sur le net:

 *Quote:*   

> [nfs] connaître les partages proposés par un serveur
> 
> Publié le : jeudi 24 février 2005
> 
> Pour connaître les partages NFS proposés par un serveur, il suffit d’utiliser la commande showmount [1] :
> ...

 

ce qui donne, sur mon PC (qui utilise des partages NFS du SERVEUR):

```

loop loopx # showmount -e serveur

Export list for serveur:

/mnt/data            10.2.1.8,10.2.1.1,10.2.1.6

/mnt/data3           10.2.1.8,10.2.1.1,10.2.1.6

/mnt/data2           10.2.1.8,10.2.1.1,10.2.1.6

/mnt/data3/distfiles 10.2.1.1,10.2.1.6
```

Ca, c'est vraiment de l'insécurité, jveux plus que ca soit ainsi; qu'existe t'il comme sécurité à appliquer à NFS ?

Tiens, je viens de sniffer le bazare, et j'utilise visiblement la version 2   :Shocked:     et le protocole, n'est ni UDP, ni TCP mais NFS !!!! Ce serait pas un peu farfelu ??

EDIT: j'ai rien dis, c'est bien du TCP...  Sur un réseau local, je choisi UDP je suppose (ah en fait, je viens de lire que l'UDP c'est bien, mais si le réseau est saturé, ou que c'est genre du wifi, il vaut mieux utiliser du tcp ... donc je garde tcp).

EDIT2: probz de version2 résolu, suis passé à la version 3 (recompilation du kernel)

J'aurais voulu savoir quel est la méthode à utiliser pour la lecture/ecriture des données. Exemple, 2 pc monte le partage nfs; le problème c'est que les ID des utilisateurs sont pas forcément pareil ... De plus, quand il va écrire un fichier, il y aura mélange SI les ID sont identique (utilisateur principal=1000 sur les 2 pcs). Et au niveau du masque ???

Il faudrait un truc qui permet de modifier l'owner du fichier après upload (et un ptit mask aussi, pour régler les droits). Je me suis jamais concentré sur ce problème, maintenant ca m'intéresse   :Surprised: 

----------

## anigel

 *loopx wrote:*   

> JCa, c'est vraiment de l'insécurité, jveux plus que ca soit ainsi; qu'existe t'il comme sécurité à appliquer à NFS ?

 

Kerberos. Mais ne me demande pas comment ça fonctionne, je ne maîtrise pas le sujet. C'est simplement dans ma TODO-list depuis très longtemps.

----------

## loopx

Ah ok   :Laughing: 

J'ai lu un peu de doc sur la version 4 de nfs, je sais pas si c'est une bonne chose de l'utiliser maintenant ...   En tout cas, ca fonctionne bien avec la version 3...

J'ai activé un truc ACL pour la version 3, ptet que ca permet de sécuriser un ptit peu ...

----------

## kwenspc

 *loopx wrote:*   

> 
> 
> Tiens, je viens de sniffer le bazare, et j'utilise visiblement la version 2      et le protocole, n'est ni UDP, ni TCP mais NFS !!!! Ce serait pas un peu farfelu ??
> 
> 

 

Quel sniffer as tu utilisés? parce que NFS, il me semble c'est la couche application donc ça utilise soit UDP/TCP par dessous (eux même au dessus d'IP) non? Un sniffer comme wireshark est assez "smart" pour reconnaître le protocole de bout de chaîne mais aussi les protocoles d'encapsulation, mais il est vrai qu'il afficher en premier le protocole en bout de chaîne (fin ça dépend comment on configure le filtre).

Sinon le fait d'avoir la possibilité de lister les repertoires partagés sous NFS c'est à demi un problème de sécurité seulement. (liste les points de partages c'est pas encore trop trop risqués, surtout qu'en principe tu filtres les montages NFS via /etc/hosts.allow et /etc/hosts.deny) Hum qui plus est, utiliser showmount à partir d'une machine cliente qui n'est pas dans hosts.allow ça fonctionne pas. (et en plus il faut que le mec soit root sur la machine cliente)

Sans être dans hosts.allow: (portmat devrait même pas me sortir ce message, mais je l'ai pas redémarrer sur le serveur donc il me dit ok)

```

# showmount --all server

portmap getport: RPC: Success

```

En étant dans hosts.allow:

```

# showmount --all server

All mount points on server:

192.168.0.0/24:/truc

192.168.0.0/24:/bidule

192.168.0.2:/truc

192.168.0.2:/bidule

```

Donc perso je vois pas trop où est le réel problème de sécurité  :Neutral: 

[edit]Humpfff avait pas vus tes editions, c'est ça de traîner à répondre. btw, si t'es en réseau local restes sur UDP, avec TCP tu perdras en perfs  (c'est utiles que sur des lignes bruités (via internet etc...).). Laisses CONFIG_NFSD_TCP sur  N dans ton .config donc. Sinon NFS3 vs NFS4 j'ai pas trop vu de différence côté perfs. Par contre côté sécurité, puisque ça semble être ton principal centre d'interêt, tu peux y jeter un coup d'oeil: authentification par certificat/crypto par clé public/privé, sessions... Sinon NFSv4 est arrivé à maturité maintenant, aucun soucis à l'utiliser.[edit]

----------

## loopx

Ah ouais, si il liste pas tout comme le showmount que j'ai montré, ca peut aller. Mais bon, imagine qu'un ptit c** sais bien qu'un pc à accès, .... ben, une fois que le pc est éteind, il n'a qu'a lui spoofé son ip et pan, jl'ai dans l'os...

Question:

```

loop linux # cd /mnt/serveur/

loop serveur # ls

data  data2  data3

loop serveur # cd data

bash: cd: data: Permission non accordée

loop serveur # cd data2

bash: cd: data2: Permission non accordée

loop serveur # cd data3

bash: cd: data3: Permission non accordée

loop serveur # exit

exit

loopx@loop ~ $ cd /mnt/serveur/data

loopx@loop /mnt/serveur/data $ ls

Manual tools  Mes Création  Pgmz  Tout pour les Jeux

loopx@loop /mnt/serveur/data $ cd ../data2

loopx@loop /mnt/serveur/data2 $ ls

2eme session                  ecole

```

Donc, plus haut, on vois que le user normal à accès au partage NFS, mais pas le root (ca à tjs foiré note)... Or, les fichiers partagé sur le serveur via NFS utilise les droits du client ...  donc en principe, si je me connecte en root, jpeux avoir accès aux truc root du coté serveur, et ce, rien qu'en me connectant sur le client en root non ?

Je trouve les droits vraiment bizard ... Si sur le serveur, un rep est accessible uniquement à l'utilisateur 1030 et que le client qui utilise le NFS à un id de 1000, ben il s'ai pas rentrer dans le rep ... Or, si le client crée un new user avec l'id 1030, ca fonctionne ... Ca, c'est pas secu   :Laughing: 

----------

## anigel

 *loopx wrote:*   

> J'ai activé un truc ACL pour la version 3, ptet que ca permet de sécuriser un ptit peu ...

 

Ca sécurise que dalle. Enfin si, autant qu'une souris sécurise un PC pour qui ne sait pas comment la faire fonctionner ^^.

Blague à part, le système de fichiers réseau est l'un des rares domaines où UNIX reste encore largement inférieur à Windows. Et je pèse mes mots en disant ça... Si je ne craignais pas autant ce genre d'attaques sur mon propre réseau, je vous expliquerais même comment hacker en 20 sec n'importe quel NFS non-kerberos, mais là ce serait de l'incitation à la délinquance. Donc non  :Laughing:  !

----------

## CryoGen

shfs correspond peut-etre à ce que tu cherches niveau sécurités  :Wink: 

----------

## Tom_

 *anigel wrote:*   

> 
> 
> Blague à part, le système de fichiers réseau est l'un des rares domaines où UNIX reste encore largement inférieur à Windows. Et je pèse mes mots en disant ça... Si je ne craignais pas autant ce genre d'attaques sur mon propre réseau, je vous expliquerais même comment hacker en 20 sec n'importe quel NFS non-kerberos, mais là ce serait de l'incitation à la délinquance. Donc non  !

 

Bonsoir,

Est-ce que tu pourrais en dire plus sans entrer dans les procédures d'attaque ? J'aimerais juste savoir pourquoi Unix est inférieur à Windows pour les fs réseaux ? Et comment améliorer ca (à part Kerberos)? 

Merci d'avance.

----------

## anigel

 *CryoGen wrote:*   

> shfs correspond peut-etre à ce que tu cherches niveau sécurités 

 

Oui, mais question charge c'est inenvisageable en production ça.

 *Tom_ wrote:*   

> Est-ce que tu pourrais en dire plus sans entrer dans les procédures d'attaque ? J'aimerais juste savoir pourquoi Unix est inférieur à Windows pour les fs réseaux ? Et comment améliorer ca (à part Kerberos)? 

 

NFS est le système de fichier réseau "standard" d'UNIX. Sa sécurité se résume à un contrôle d'IP lors de la connexion. Et qu'y-a-t'il de plus facile à usurper qu'une IP ? Une autre IP, bonne réponse  :Laughing:  ! Côté Windows, on a un système qui supporte, de base, le cryptage, même si aujourd'hui il est moins difficile à casser qu'il y a 5 ou 6 ans, une authentification par usager / mot de passe (ça vaut ce que ça vaut, mais ça a le mérite d'exister), et un contrôle d'IP au besoin. Bref, si on compare, de base, un linux d'aujourd'hui avec NFS, et un windows 95, ben... Microsoft gagne...

Pour améliorer ça il faut ajouter Kerberos (autrement dit un serveur de certificats pour authentifier le client NFS avant d'autoriser les opérations d'E/S sur l'export), à ma connaissance il n'y a pas d'autre solution "à taille humaine" (comprendre : qui ne nécessite ni 4 ans d'études ni 6 ingés système, et pas de carte fille dédiée pour les calculs dédiés histoire de garder des perfs honnêtes).

----------

## razer

 *anigel wrote:*   

> 
> 
> Blague à part, le système de fichiers réseau est l'un des rares domaines où UNIX reste encore largement inférieur à Windows. Et je pèse mes mots en disant ça... 

 

Sauf qu'il est toutafé possible d'utiliser samba à la place de NFS  :Smile: 

Là je suppose que la sécurité est comparable/meilleure, je m'exprime au conditionnel car monter des serveurs de fichier sous Windows, je n'ai jamais fait.

Par contre, j'utilise samba même pour faire du linux<->linux, çà semble nettement plus souple et paramétrable (par ex. pour les histoires de droits évoqués ici), et c'est toujours mieux lorsqu'un boulet se pointe avec son laptop Windows OEM et veut me piquer mes fichiers, tous légaux cela va de soit  :Smile: 

----------

## anigel

 *razer wrote:*   

> Sauf qu'il est toutafé possible d'utiliser samba à la place de NFS 

 

Pas toutafé hélas  :Wink: . Samba c'est bien, c'est mieux sécurisé que NFS, mais ça ne permet que la moitié de ce qu'autorise NFS : pas de "pipes", pas de types de fichiers spéciaux : c'est fait pour stocker des données "à la windows", donc sur 2 types de fichiers : les fichiers et les répertoires. Autrement dit, les logiciels qui créent des fichiers spéciaux pour leur fonctionnement interne (au hasard KDE, Gnome) ne fonctionneront pas si le homedir de l'usager est stocké sur du samba.

----------

## kwenspc

 *anigel wrote:*   

> 
> 
> NFS est le système de fichier réseau "standard" d'UNIX. Sa sécurité se résume à un contrôle d'IP lors de la connexion. Et qu'y-a-t'il de plus facile à usurper qu'une IP ? Une autre IP, bonne réponse  ! 

 

D'où l'intérêt d'utiliser NFSv4 qui, lui, corrige tous ces problèmes de sécurité. 

-->http://www.citi.umich.edu/projects/nfsv4/

----------

## anigel

 *kwenspc wrote:*   

> D'où l'intérêt d'utiliser NFSv4 qui, lui, corrige tous ces problèmes de sécurité. 

 

Que pouic ! NFSv4 supporte la sécurisation des échanges (via Kerberos ou IPSec, pour les courageux), mais ne la fournit pas en standard. Auparavant il fallait patcher NFSv3 pour obtenir ce support. En matière de sécurité NFSv4 n'apporte quasiment rien. Ses principales avancées se situent au niveau des accès concurrents et de la gestion du cache, particulièrement sur des environnements congestionnés (où il est impératif d'utiliser TCP).

Tournez-le comme vous voudrez : il n'y a pas d'alternative à l'utilisation de code tiers pour sécuriser NFS. C'est comme ça, et c'est aussi bien, sinon imaginez le bazar pour migrer...

----------

## kwenspc

 *anigel wrote:*   

> 
> 
> Tournez-le comme vous voudrez : il n'y a pas d'alternative à l'utilisation de code tiers pour sécuriser NFS. C'est comme ça, et c'est aussi bien, sinon imaginez le bazar pour migrer...

 

Dans ce cas c'est mi-figue mi-raisin un mensonge quand ils annoncent : "support for strong security" ?

Je veux dire, on annonce pas qu'un protocole supporte telle ou telle chose si c'est complètement pris en charge par un composant tiers, indépendant... bizarre leur bouzin.  :Neutral: 

Il aurait été préférable qu'ils annoncent qu'nfsv4 est compatible avec d'autres couches logiciels qui permettent d'offrir telle ou telle truc. (enfin c'est vrai ça fait sans doute moins vendeur)

Bon ceci dit c'est nettement mieux que ce que ça offrait avant: pas de portmap, plus de robustesse, sans parler de tout ce qui fait que NFS vaut pour moi mieux que les autres shared-fs (boot réseau, sur image partagé dans un émulateur/virtualiseur etc...)

----------

## Tom_

Merci pour ces précieuses infos anigel.  :Wink: 

On rajoute NFSv4 à la todolist.   :Laughing: 

AFS semble une alternative sympa avec quelque chose comme un "kerberos" pré-intégré, nen ?   :Question:   :Embarassed: 

----------

## anigel

 *kwenspc wrote:*   

> Dans ce cas c'est mi-figue mi-raisin un mensonge quand ils annoncent : "support for strong security" ?

 

Non non, quand je lis "support for strong security", je comprend "si vous voulez le faire, c'est prévu, mais démerdez-vous  :Wink: ". Sinon ils auraient simplement mentionné "strong security included".

 *Tom_ wrote:*   

> AFS semble une alternative sympa avec quelque chose comme un "kerberos" pré-intégré, nen ?   

 

Je ne connais pas, je peux pas te dire  :Wink: .

----------

## kwenspc

 *anigel wrote:*   

> Sinon ils auraient simplement mentionné "string security included".

 

et les modèles qui les portent avec?  :Laughing:  (ok c'est nul)

[edit] sinon oui j'ai mal lu, ça aurait été "embedded" ou "included" comme tu dis là en effet [/edit]

----------

## polytan

 *razer wrote:*   

> Par contre, j'utilise samba même pour faire du linux<->linux, çà semble nettement plus souple et paramétrable (par ex. pour les histoires de droits évoqués ici), et c'est toujours mieux lorsqu'un boulet se pointe avec son laptop Windows OEM et veut me piquer mes fichiers, tous légaux cela va de soit 

 

Tu utilises quoi sous linux pour visualiser les partages samba sur le réseau, les monter, etc ?

Je suis sous xfce et j'aimerais un outil GTK+ pas trop dépendant de gnome...  :Smile: 

Merci,

----------

## kwenspc

net-misc/LinNeighborhood  mais c'est vieux

----------

## Mickael

Tu as aussi sa version python : 

[I] net-misc/pyneighborhood [1]

     Available versions:  (~)0.4

     Installed versions:  0.4(14:53:55 21.09.2007)

     Homepage:            http://pyneighborhood.sourceforge.net/

     Description:         GTK+ 2 rewrite of LinNeighborhood

[1] "sunrise" /usr/portage/local/layman/sunrise

----------

## anigel

 *kwenspc wrote:*   

> et les modèles qui les portent avec?  (ok c'est nul)

 

Gna gna gna   :Embarassed:  ...

 :Laughing: 

----------

## dapsaille

Heuu ..

 Ok pour la connexion mais que je saches .. rassurez moi vos datas sont dans des folders sur vos partages nfs ??

 Et avec les droits qui-qui vont biens ?? 

car sécuriser une connexion qui par définition est utilisée en local (donc dans le monde des bisounours ou tout vas bien)

n'est aucunement nécessaire ... tant que l'ip est bonne on permet l'accès .. la connexion est établie .. après l'accès aux ressources dites "utilisables" (fichiers , dossiers) se configure au niveau des fichiers eux mêmes ..

 Je ne vois pas ou est le problème .. après si c'est pour du wan .. la on oublie nfs :p

(quoique nfs dans un tunnel ssh ca fait super geek )

----------

## Martin.

 *dapsaille wrote:*   

> Heuu ..
> 
>  Ok pour la connexion mais que je saches .. rassurez moi vos datas sont dans des folders sur vos partages nfs ??
> 
>  Et avec les droits qui-qui vont biens ?? 
> ...

 

 *anigel wrote:*   

> Et qu'y-a-t'il de plus facile à usurper qu'une IP ?

 

J'imagine que c'est pareil pour un réseau local. Mais en même temps, dans un réseau local, on est censé n'avoir que des bisounous d'amis...

----------

