Apps – SFTP – erwan.guillemard

Ce billet est en lien étroit avec l’article Apps – FTPx. Nous pouvons voir se dernier comme une ramification de l’article précédent.

Cependant, j’ai insisté sur la différence entre le protocole FTP¹/FTPS² et SFTP³. Alors pourquoi faire tronc commun et parler de ramification ? Le seul point commun qu’il peut avoir dans un premier temps et le SE puisque c’est UNIX et dans un second temps la présence de FTP dans le nom. Puis je dirai que c’est tout…Ha si, tertio ils sont tous deux utilisés pour l’échange de fichiers.

Le protocole SFTP se base pour échanger des données sur la création d’un tunnel SSH entre le client et le serveur via le protocole SSH. Nulle autre dépendance n’est nécessaire contrairement à FTP/FTPS qui nécessite un daemon à installer.

Et SSHD c’est du nougat ? Non, bien entendu, c’est un daemon aussi. Ce que je veux dire par là, c’est que dans 99% des cas SSHD est présent dans le déploiement de base des SEs LINUX.

Nous allons utiliser le daemon openssh ( ou SSHD) pour notre serveur SFTP. Ce dernier est dans la grande majorité des cas présent sur le système d’exploitation lors du déploiement. La configuration du service aura été préalablement modifiée dans le cadre du durcissement de notre SE. Nous ne réaliserons que la configuration nécessaire au fonctionnement du service SFTP.

La finalité de ce billet sera comme pour l’article mentionné ci-haut de comprendre le déploiement et l’implémentation d’un service SFTP encore et toujours sur un environnement durci GNU.

Théorie – SFTP

Contrairement aux protocoles FTP et FTPS, SFTP est un protocole dédié, basé sur le protocole SSH.

SFTP est un protocole récent puisqu’il a été créé en 2001 par l’organisme IETF⁴. Il s’inscrit dans un sens comme le successeur du protocole SCP⁵. Le protocole SFTP se rapproche plus du système de fichiers que SCP et donc supporte une plus grande flexibilité.

Si nous venons à comparer les protocoles FTPx et SFTP sur le plan réseau, SFTP se veut plus simple car la notion de mode Actif, Passif, Explicite, Implicite n’existe pas. Là où il est nécessaire d’avoir les ports 21,20, 990, 989 avec SFTP seul le port 22 est nécessaire.

J’apporte toutefois une nuance dans le protocole SFTP vis à vis des protocoles FTPx. A ce jour le protocole SFTP ne possède pas de RFC⁶ à proprement parlé. Un projet à toutefois été initié mais celui ci est resté à l’état de brouillon et n’a plus à ce jour avancé (le RFC draft doit dater de 2006). Il est légitime de se demander si l’avenir et la stabilité du protocole sont viables dans le temps. Bien que le risque soit minime, il subsiste quant même.

Pratique – SFTP

Installation

Je dirais que cette sous-partie n’a pas lieu d’être puisque openssh a été déployé lors de la configuration de notre appliance.

La configuration de base a été supprimée et remplacée par une configuration customisée pour répondre aux recommandations de l’ANSSI concernant les systèmes UNIX.

Eventuellement nous pourrions nous inquiéter de la publication du port 22 sur notre daemon firewalld. Mais contrairement au service FTP, il ne sera pas utile d’ouvrir de port car celui ci est déjà présent dans le daemon firewalld.

Configuration SFTP

A la différence des services FTPx, nous n’allons plus/pas modifier la configuration du fichier vsftpd.conf (puisque nous ne l’avons pas installé, et qu’il n’est pas utile pour le fonctionnement de notre service SFTP ! 🙂 ). Comme présenté en amont, le SFTP se base sur l’établissement d’un tunnel SSH. Donc nous allons devoir ajuster la configuration de notre fichier sshd_config.

$ sudo vim /etc/sshd/sshd_config

# override default of no subsystems
Subsystem      sftp    /usr/libexec/openssh/sftp-server -l VERBOSE

Match Group sftp-user
        X11forwarding no
        AllowTcpForwarding no
        ChrootDirectory %h
        ForceCommand internal-sftp -u 0007

#Allow Users And Groups to uses SSHD
AllowGroups ssh-user sftp-user

$ sudo systemctl reload sshd

Et si nous disséquions ce brin de conf ?

Match Group sftp-user : Nous indiquons ici que l’ensemble des commandes ci-dessous vont s’appliquer aux utilisateurs membre du groupe sftp-user. Dans notre cas, le groupe n’existe pas encore et il sera nécessaire de créer ce dernier. Il est bien évidemment possible de définir plusieurs politiques sur plusieurs groupes.
X11forwarding no : Désactive la fonctionnalité X11 forwarding pour le groupe sftp-user et limite les utilisateurs membre de ce groupe à l’utilisation d’application GUI via SSH.
AllowTcpForwarding no : N’autorise pas le transfert TCP et limite les applications internes qui pourraient être accessible des membres du groupes sftp-user.
ChrootDirectory %h : Indique que les répertoires sont chrootés (restreints) au home des utilisateurs.
ForceCommand internal-sftp -u 0007 : Lors de la connexion, le système va exécuter le processus internal-sftp en appliquant le masque 0007 sur tous les éléments qui font être up/down par l’utilisateur.
AllowGroups ssh-user sftp-user : Les groupes ssh-user et sftp-user sont autorisés à utiliser le daemon SSHD.

Bon nous y voyons un peu plus clair. Mais vient alors une question sécurité. Comment nous assurons nous que les utilisateurs membres du groupes ssh-user n’ont pas accès aux SFTP et que les membres du groupes sftp-user ne puissent pas ouvrir de connexion en SSH ?

Avant de poursuivre, je me suis aperçu avec le temps qu’il était bon dans notre gestion au quotidien de notre service VSFTP mutualisé de ne pas avoir une configuration générique mais d’adopter une configuration par organisation ou utilisateur.
Si nous reprenons la configuration ci-haut tout se base sur les membres du groupe sftp-user (ce qui va bien pour notre lab). Mais dans la logique, nous devrions faire un bout de configuration avec un groupe sftp-customer1, sftp-customer2,…sftp-customerN.

Cette approche permet d’identifier facilement les différents groupes et membres, en cas d’urgence de désactiver rapidement l’accès au service SFTP sans impacter les autres utilisateurs, d’autres organisations. De faciliter la gestion et la sécurité journalière.

Ce qui nous donnerait donc la configuration suivante :

# override default of no subsystems
Subsystem      sftp    /usr/libexec/openssh/sftp-server -l VERBOSE

Match Group sftp-customer1
        X11forwarding no
        AllowTcpForwarding no
        ChrootDirectory %h
        ForceCommand internal-sftp -u 0007

Match Group sftp-customer2
        X11forwarding no
        AllowTcpForwarding no
        ChrootDirectory %h
        ForceCommand internal-sftp -u 0007

Match Group sftp-customer2_providers
        X11forwarding no
        AllowTcpForwarding no
        ChrootDirectory %h
        ForceCommand internal-sftp -u 0077
...
...
...
Match Group sftp-customerN
        X11forwarding no
        AllowTcpForwarding no
        ChrootDirectory %h
        ForceCommand internal-sftp -u 0007

#Allow Users And Groups to uses SSHD
AllowGroups ssh-user sftp-customer1 sftp-customer2 sftp-customer2_providers sftp-customerN

Ainsi, nous gagnons en sécurité, en flexibilité et en lisibilité.

Dans le cas des utilisateurs qui sont exclusivement destinés à la consommation de notre service SFTP, nous devons nous assurer :

Pas de connexion en SSH à la console : Lors de la création des comptes utilisateurs, bien préciser en valeur de l’argument –shell le /sbin/nologin ou /bin/false
De chrooter le home des utilisateurs. Mais en leurs créant un sous-répertoire où ils pourront tout de même réaliser des actions de création, modification, suppression

Dans le cas des utilisateurs système (root) ou administrateur (membre de wheel ou sudo), l’approche est différente. Il n’est pas possible de limiter un utilisateur système à ne pas utiliser le protocole SFTP. Et dans un sens c’est logique. Néanmoins, il est possible de reprendre le principe suivant de moindre privilège et de silotage des comptes.

Mais bon, en règle générale rien ne justifie l’usage d’un compte utilisateur à usage d’exploitation d’avoir un accès SFTP. Néanmoins, et par sécurité les comptes utilisateurs doivent ou devraient être restreints (chrootés). Nous ne sommes jamais assez prudent.

Autres points, QUID des logs de notre serveur SFTP ? Ces derniers sont consignés sous /var/log/secure pour la partie authentification et sous /var/log/messages pour la partie commande SFTP (à condition de préciser -l VERBOSE ou INFO à la fin de l’instruction de commande Subsystem. Tout dépendra du niveau d’information que vous souhaitez faire remonter).

Groups, Users and CHROOT

Je vais pour le coup « recycler » mon utilisateur Customer1 ainsi que son home créé dans l’article traitant du FTPx.

$ sudo adduser Customer1 --home-dir /mnt/customer1 --shell /sbin/nologin --badname

Créons le groupe sftp-user et ajoutons l’utilisateur Customer1 comme membre de ce dernier.

$ sudo groupadd sftp-user
$ sudo usermod -aG sftp-user Customer1

Maintenant, un partie plus délicate qui nécessite un peu de gymnastique mentale ou tout aussi bien un papier, crayon. Les droits et le chroot d’un répertoire peut vite devenir un calvaire. Nous allons donc bien définir notre contexte.

Nous souhaitons que le répertoire home de l’utilisateur soit restreint pour l’empêcher de s’échapper de son home ainsi que de lui interdire de créer, modifier et supprimer l’arborescence en place au niveau de son home mais de lui permettre dans un répertoire « home » de pouvoir faire ce qu’il souhaite.

Commençons par chroot le home

$ sudo chmod 2750 -R /mnt/customer1

Créons et appliquons les droits sur le répertoire « home »

$ sudo mkdir /mnt/customer1/home
$ sudo chmod 700 -R /mnt/customer1/home
$ sudo chown Customer1:Customer1 -R /mnt/customer1/home/

Maintenant reste plus qu’à tester le bon fonctionnement. Y à plus qu’à, faut qu’on comme dirait l’autre.

Connexion

Je reprends mon client FTPx/SFTP de prédilection sur Windows (WinSCP me susurre-t-on à l’oreille) et indique le couple login, mot de passe de l’utilisateur Customer1. Diantre que c’est agréable de constater que cela fonctionne 🙂

Nous constatons que les droits du répertoire « Home » (le /mnt/customer1 et non le répertoire /home affiché. Oui j’aurais du choisir un nom moins ambigüe. Toutefois, notons que cela nous force à faire travailler notre cafetière qui nous sert de cerveau) de l’utilisateur est bien restreint (chroot).

Nous constatons également que le fichier test.html a des droits qui sont différent et ne semble pas hérité du répertoire /mnt/customer1. C’est normal puisque j’ai fait des tests auparavant et se fichier va nécessiter l’intervention d’un administrateur du serveur.

Pourquoi ? Comme indiqué plus haut, nous n’avons pas souhaité laisser la possibilité à l’utilisateur de créer, modifier ou supprimer des ressources à la racine de son home.

Si nous rentrons dans le répertoire ./home, les permissions sont différentes et offrent ainsi la possibilité à l’utilisateur Customer1 de créer, modifier, supprimer le contenu de ce répertoire.

Ok nous sommes donc d’accord sur la partie restriction et droits sur la partie SFTP mais sommes nous certains que l’utilisateur ne peut pas se connecter via un terminal SSH ? Pour le coup, il suffit de faire un test de connexion via un terminal et de consulter les journaux relatifs aux événements d’authentification.

Le message est clair, l’utilisateur n’est pas autorisé à ouvrir de session depuis un terminal. Donc tout va bien puisque tout est conforme à nos attentes.

Si nous voulions aller plus loin et s’est ce que nous allons faire (libre à vous de passer votre route), penchons nous sur la différence entre FTPS et SFTP sur le plan réseau nous aurions les trames suivantes :

Rien de magique en sommes si ce n’est la mise en évidence de l’établissement des transactions via le protocole SSH2 pour le SFTP et l’utilisation du protocole SSL/TLS dans sa version 1.3.

La grosse différence se trouve sur le mécanisme de chiffrement. L’un use d’un certificat le second d’un jeu de clé. Il sera plus facile de maintenir un jeu de clé qu’un certificat. Toutefois, il faut se noter par sécurité de changer de clé au bout d’une durée définit comme nous pourrions le faire avec un certificat qui arrive à expiration.

Conclusion

Nous sommes arrivés au bout des objectifs que nous nous étions fixés au début de ce billet.

Le SFTP a pour moi toute ça place dans un service à la demande (SaaS) comme le serait FTPS. Toutefois bien qu’il offre certains avantages il a (pour moi) le lourd inconvénient de ne pas être reconnu officiellement (quel inconvénient sans être boudé pour autant).

Si la mise en place du service relève de la simplicité, il est nécessaire d’être rigoureux et méthodique quand à la création des utilisateurs, la restriction des répertoires « home ». Se basant directement sur le daemon sshd (openssh) la moindre erreur pourrait rendre le système vulnérable par l’escalade de privilège ou évasion de l’espace restreint. Je recommande fortement la mise en place d’une matrice ainsi qu’une revue périodique des droits d’accès. Egalement, lorsqu’un client ou utilisateur n’utilise plus le service, il est nécessaire de nettoyer le système dans les règles de l’art.

Il n’est toutefois pas exclu comme pour FTPx de renforcer la sécurité quant à l’accès du service si ce dernier est publié vers l’extérieur.

Au minimum et si possible sur le firewall :

Activation de l’IPS
Activation de l’Application Control (fonctionnalité WatchGuard) sur une politique définit
Activation de la Géolocalisation sur la liste des pays autorisées à se connecter au service publié
Utilisation d’un proxy FTP

Au maximum et si possible sur le firewall :

Filtrer les adresses IP entrantes aux seules IP habilitées. (Généralement les IPs clientes).

Aujourd’hui, il convient à chacun de dire que SFTP > FTPS ou FTPS > SFTP. Pour ma part je prendrai le partie suivant SFTP est équivalent à FTPS, j’ai toutefois une préférence SFTP. Néanmoins, basé sur deux technologies différentes, tout dépendra du contexte ainsi que des moyens mis à disposition pour choisir l’une ou l’autre des protocoles.

A d’autres égards, il est souvent si ce n’est systématiquement privilégié par les éditeurs vis à vis du protocole FTPS.

Le mot de la fin :

« Donne moi ta Key baby, ton port baby hey ! Discute avec moi baby, je veux un serveur SFTP like you ! » Très joli interprétation, vous sortez de votre chroot et zoukez avec Patrick BALKANY en sortie de détention.
Erwan GUILLEMARD

Sources

FTP : File Transfert Protocol ↩︎
FTPS : File Transfert Protocol over SSL ↩︎
SFTP : Secure File Transfert Protocol ↩︎
IETF : Internet Engineering Task Force ↩︎
SCP : Secure Copy Protocol ↩︎
RFC : Request For Comments ↩︎