GlusterFS, système de stockage multimodal, consolide les fichiers de plusieurs serveurs en un seul système unifié, garantissant ainsi la tolérance aux pannes dès que trois hôtes sont « glusterisés » au minimum. Pourquoi est-ce crucial ? Pour prévenir les split-brain ! Afin d’éviter ce scénario à tout prix, un nombre impair de serveurs est nécessaire pour obtenir un quorum de voix en cas de défaillance d’un hôte.

Par défaut, de très nombreux tutoriels en ligne ne précisent pas qu’il est important de sécuriser les liens de réplication inter-serveurs. En effet, par défaut, GlusterFS ne propose pas cette option de sécurité.

Mea culpa… il y a quelques années j’ai fait un article sur la configuration d’un cluster de stockage GlusterFS, mais je n’avais pas parlé du contrôle d’accès à celui-ci. Bon, entre-temps je l’ai mis à jour ^^

Bonne lecture 🙂

I. Identifier un service glusterfs actif sur le réseau

Pour débuter, il est essentiel d’identifier si une machine expose le port associé au service GlusterFS, mais cela peut s’avérer difficile car par défaut, nmap ne le signale pas même avec l’option –sV. Le port généralement associé à ce service est le 27001.

Si-vous êtes sur un réseau « VLAN serveur » ou que l’organisation audité n’a tout simplement pas de cloisonnement réseau, vous pouvez aussi écouter le réseau avec wireshark (filtrer le trafic avec le protocole « glusterfs »).

Lors de l’analyse de l’output d’un script nmap, si vous repérez que le port 27001 est ouvert, cela devrait attirer votre attention. Si vous soupçonnez la présence d’un cluster de stockage GlusterFS au sein d’un réseau, vous devriez télécharger la CLI de GlusterFS pour lever le doute. Pour ce faire, utilisez la commande suivante :

apt update && apt install glusterfs-server 

Il existe également une version glusterfs-cli, cependant, celle-ci peut poser des problèmes de dépendances. En utilisant ce paquet, vous obtiendrez à la fois le service GlusterFS installé et la CLI. Il est à noter que par défaut, le service GlusterFS restera inactif.

Premièrement, vous pouver tenter de lister les volumes de cette manière :

gluster --remote-host=192.168.130.143 volume list
mkdir /glusterfs-pwned

On constate qu’un volume « volume1 » est retourné. Cela signifie qu’il y a bien un service GlusterFS actif avec un seul volume de données. Mais ne vous emballez pas 🙂 Par défaut, même après une sécurisation (voir la dernière section), il est toujours possible de procéder à une énumération des volumes… Pas idéal, mais bon ^^

Ok, donc maintenant est-il possible pour un utilisateur anonyme de monter ce volume localement afin d’accéder aux données ?

La réponse est oui comme vous vous en doutez…

II. Connection au volume de manière anonyme

Créez un dossier et associez-le à un point de montage « glusterfs » en vous aidant des informations recueillies précédemment (IP et nom du volume).

mkdir /glusterfs-pwned 
mount -t glusterfs 192.168.130.143:/volume1 /glusterfs-pwned 

Et ce n’est pas tout, vous n’avez pas seulement les droits de lecture par défaut :p Vous avez aussi les droits d’écriture 🙂

La capture suivante montre qu’il m’est possible de renommer un fichier sur ce cluster de stockage sans demander des droits plus élevés que ceux que je possède.

III. Extraction des données du volume

Vu que nous avons les droits de lecture (et d’écriture), il est donc possible d’extraire toutes les données de ce partage de fichiers très facilement. Bon, j’avoue que la commande ci-après est la plus minimaliste. ^^

IV. Solution de remédiation

Par défaut, la seule sécurisation en vigueur pour remédier à ce défaut de sécurité est la restriction par IP. Ce n’est pas forcément la solution la plus sécurisée, je vous l’accorde, mais cela compliquera la tâche d’un attaquant (dans le cas où celui-ci souhaite usurper l’adresse IP d’un des serveurs membres du cluster de stockage GlusterFS).

gluster volume set volume1 auth.allow 192.168.130.143,192.168.130.144

Vous n’avez pas besoin de redémarrer le service glusterfs suite à cette modification.

++

GSB