Apps – FTPx

J’avais à cœur de partager l’un des tous premiers services publiés pour un usage autre qu’interne. Avant de poursuivre, j’ai délibérément fait le choix de ne pas traiter dans ce même article les protocoles TFTP et SFTP. Ces derniers auront leurs propres billet.

Le transfert de données, notamment de fichiers date un peu. Si aujourd’hui l’échange de fichiers s’est banalisé ce n’était pas le cas dans les années 70. C’est pourquoi, il existe une RFC¹ décrivant le protocole FTP², File Transfert Protocol. Je passe sur l’histoire du protocole vous trouverez sur la toile (comme le disent si bien les milléniales de ma génération) tout ce qui vous faudra pour réaliser un exposé digne de ce nom.

La finalité de ce billet sera de voir le déploiement, implémentation et l’usage d’un service FTPx dans un environnement durci GNU.

Prérequis

• SE : GNU LINUX
• Apps : openssl, vsftp, wireshark, winscp
• Autres : LINUX – Disk & Part

Théorie – FTPx

Super ! Le titre annonce la couleur. Dis voir dans ton introduction t’aurais pas oublié une lettre ? Le FTPx c’est le FTP en plus cochon c’est ça ?

Excellente remarque. Sans déconner, soit je suis schizophrène ou en passe de le devenir. Je vais parler du protocole FTP et FTPS³ d’où la notion de FTPx. Ce qui nous amène à la conclusion que le FTPx n’est pas plus cochon pour échanger des fichiers que le FTP mais rien n’interdit d’avoir et d’échanger des fichiers cochons via ces deux protocoles.

A la différence du protocole FTP, le protocole FTPS est sécurisé par les protocoles (anciennement SSL) TLS. Le protocole FTPS est également décrit par une RFC.

Oui mais moi je fais du FeuTeuPeu Sécurisé avec SFTP. C’est pareil !

Toux doux bijoux ! Non pas du tout, c’est pas pareil et ça nous verrons la différence dans un autre billet.

Rentrons dans la théorie de chacun des protocoles FTP et FTPS.

FTP

Le protocole de communication FTP comme présenté succinctement plus haut permet d’échanger des fichiers sur le modèle client, serveur. Ce dernier possède deux modes de fonctionnement distinct.

• Le mode actif
• Le mode passif

Les deux modes de fonctionnement utilisent les connexions TCP garantissant ainsi l’intégrité des données échangées. Toutefois, il est important de préciser que ce n’est pas le protocole le plus sécurisé au monde puisque l’ensemble des informations transmissent ne sont pas chiffrées. Dans le cas d’authentification d’un utilisateur, il sera facile en « sniffant » les trames réseaux de trouver le login et mot de passe de ce dernier.

Mode actif

En mode actif, les ports utilisés sont le 21 et le 20. Le port 21 servira à initier la connexion entre le client et le serveur en transmettant les commandes. L’ensemble des données transiterons sur le port 20 du serveur vers le client ayant initié le jeu de commande.

Toutefois, ce mode de fonctionnement peut être contraignant. Comme nous pouvons le constater sur le schéma, le retour peut ne jamais arriver. Le serveur va effectuer le retour sur le port qui est spécifié par le client lors de l’exécution des commandes. Avec les firewalls d’aujourd’hui, il est donc plus que probable que le retour n’arrive jamais (qui autorise le port 20 en entrant par défaut ?). Il sera donc nécessaire d’ouvrir les flux nécessaires et le cas échéant de revoir côté client les politiques de NAT.

Mode passif

A contrario, le mode passif utilise uniquement le port 21. Le port 21 servira à initier la connexion entre le client et le serveur en transmettant les instructions (comme le mode actif). Toutefois c’est lors de la phase d’échange de données que le fonctionnement change, le serveur va déterminer le port que le client a utilisé lors de l’appel pour effectuer le transfert des datas durant toutes la durée des transactions.

Ainsi avec les firewalls nous sommes quasi assuré que les données seront reçu.

FTPS

Comme nous l’avons énoncé précédemment, le protocole à une grosse lacune puisque les données échangées ne sont pas chiffrées. Pour remédier à cela il est possible de chiffrer les données en utilisant le protocole FTPS, aussi appelé FTP over SSL.

Le principe est plutôt simple puisque le serveur FTP va à travers un certificats SSL/TLS chiffrer les données qui vont transiter. Ce dernier possède deux modes de fonctionnement distinct.

• Mode implicite
• Mode explicite

Les deux modes de fonctionnement utilisent les connexions TCP garantissant ainsi l’intégrité des données échangées point à point.

Mode Implicite

Le mode implicite rappel dans un sens le fonctionnement du protocole HTTPS. Les ports utilisés sont le 990 et le 989. Le port 990 servira à initier la connexion entre le client et le serveur en transmettant les commandes de manière chiffrée. L’ensemble des données transiterons sur le port 989 du serveur vers le client ayant initié le jeu de commande.

C’est une fois que la connexion est initiée que les données sont chiffrées. La phase de login est comprise dans l’échange sécurisé.

Ce mode bien qu’encore présent dans notre société se fait de plus en rare et est jugé comme obsolète. Effectivement toutes connexions initiées par des équipements qui ne prennent pas en charge le protocole SSL/TLS se feront drop ou reject par le serveur.

Mode Explicite

Le mode explicite lui vient palier au mode implicite en étant plus permissif tout en gardant un niveau de sécurité. Il n’est pas rare de parler du protocole FTPS explicite sous FTPES⁴. Le port de communication est le même que pour le protocole FTP, soit le port 21.

Effectivement comme ce dernier se veut permissif, si le poste client initie la connexion au serveur en spécifiant dans les commandes AUTH TLS ou AUTH SSL, les échanges qui suivront seront chiffrés et ce jusqu’à la fin de l’échange. Dans le cas contraire, si aucune commande de chiffrement n’est spécifiée suivant la configuration du serveur FTP, la connexion sera autorisée ou rejetée.

Pratique – FTPx

Maintenant que nous sommes un peu plus au fait du fonctionnement des différents modes et protocoles FTPx nous allons nous orienter vers l’implémentation d’un daemon FTP sur un environnement durci.

Nous utiliserons pour ça le paquet vsftpd⁵ qui offre une grande flexibilité, simplicité et sécurité. A ce jour, il me semble qu’une seule faille de sécurité a été découvert sur ce daemon depuis qu’il existe. Cette dernière a été patchée dans la foulée.

Une question serait légitime à cette étape.

Pourquoi se faire c***r à configurer un serveur FTP alors que ce n’est pas top niveau sécurité ? Pourquoi ne pas faire du FTPES à la rigueur ? En plus tu nous dis que la solution vsftp et flexible ?

Plusieurs raisons. La première, certains équipements spécifiques (souvent industriels) ne prennent pas en charge le SFTP ou FTP over SSL. Donc par exemple, des automates qui réalisent des relevés télémétriques à x K€ HT, il va être difficile de convaincre le client de changer tout son parc de machine pour un « soucis de sécurité ». Le risque est accepté. Dans d’autres cas, il est possible que des applications métiers (c’est de moins en moins le cas, mais on en trouve toujours) type ERP ne prennent pas en charge la partie TLS/SSL. Donc c’est un peu délicat pour les échanges de données inter applications. C’est pourquoi j’ai toujours préféré faire du FTP et non du FTPES.

Mais étant ici pour partager mon expérience, je suis également présent pour sortir de ma zone de confort et occuper mes soirées, mes nuits. C’est pourquoi nous traiterons les deux cas de configuration.

• FTP en mode passif
• FTPS en mode explicit

Pour des raisons de simplicité nous réaliserons les deux configurations sur le même environnements durci.

Nous allons partir du contexte suivant. Nous devons mettre à disposition un espace pour deux clients sur notre serveur FTP. Pour des raisons de sécurité, nous allons dédier pour nos clients deux disques d’un volume de 5Go. Nous assurerons l’étanchéités local des deux espaces clients. Nous considérons que les disques sont déjà montés (si besoin, Je vous invite à parcourir la section déjà documentée dans l’article LINUX – Disk & Part).

Installation

Installons le daemon vsftp

# dnf install vsftpd

Comme d’habitude, réalisons une copie du fichier de configuration par défaut.

$ sudo mv /etc/vsftpd/vsftpd.conf /etc/vsftpd/vsftpd.conf.ori

Editons un nouveau fichier de configuration et modifions celui-ci. Nous prendrons comme d’habitude le temps pour expliquer chaque ligne de configuration.

$ sudo vim /etc/vsfpd/vsftpd.conf

Nous voila débarrassés de la configuration générale de notre daemon vsftpd.

(Terminé ne veut pas dire opérationnel hein il manque des bouts)

Ajoutons le daemon à démarrer automatiquement lors du boot de notre bécane.

$ sudo systemctl enable vsftpd

Nous avons notre SELinux d’activé puisque notre environnement est durci. Il est donc nécessaire d’autoriser notre contexte.

# setsebool -P ftpd_full_access on

Ouvrons le port 21 sur notre firewall

# firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -p TCP --dport 21 --sport 1024:65534 -j ACCEPT
# systemctl restart firewalld

Notre daemon VSFTP est fonctionnel, mais non opérationnel. Ci-dessous les configurations à apporter pour un FTP en mode passif et un FTPS en mode explicit.

Configuration FTP

Ajoutez les lignes suivantes dans le fichier de configuration vsftpd.conf

$ sudo vim /etc/vsftpd/vsftpd.conf

Je ne vais pas détailler les lignes de configuration. Les commentaires doivent je le pense faire le taf.

#Configure le mode passif
pasv_enable=YES
#Configure la range de port dynamic qui sera utilisée pour la data
pasv_min_port=63000
pasv_max_port=63321
#Activation du port
port_enable=YES
#

Configuration FTPES

En complément de la configuration réalisée précédemment pour autoriser les connexions FTP, nous allons « simplement » ajouter les lignes de configuration nécessaire à l’utilisation des protocoles SSL/TLS.

Naturellement et choses importantes, nous partons du principe que nous avons déjà notre certificat ainsi que notre clé privée. N’ayant pas les moyens de m’offrir un wildcard (*.erwanguillemard.com) et ne pouvant passer par un certificat Let’sEncrypt, j’utiliserai dans mon cas un certificat auto-signé. Pour ceux qui aurait besoin d’un petit coup de main pour la génération d’une CA et d’un certificat, je vous laisse un lien vers un autre article LINUX – Certificats.

#####################################################################################
#FTPS - PART
#####################################################################################
#Definit l'emplacement du certificat et de la clé privée
rsa_cert_file=/etc/pki/tls/certs/vsftpd.erwanguillemard.com.crt
rsa_private_key_file=/etc/pki/tls/private/vsftpd.erwanguillemard.com.key
#
#Activation et utilisation du TLS/SSL
ssl_enable=YES
#
#Autoriser les connexions anonymes en SSL
allow_anon_ssl=NO
#
#Forcer les utilisateurs locaux à utiliser le SSL pour les échanges de données
force_local_data_ssl=NO
#
#Forcer les utilisateurs locaux à utiliser le SSL pour l'authentification
force_local_logins_ssl=NO
#
#Version du TLS/SSL qui sera utiliser, préférer la version 1 aux versions 2 et 3
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
#
#Forcer toutes les connexions de données SSL à réutiliser des sessions SSL
#précédentes pour prouver qu'elles connaissent le même secret que le canal de control
#Attention peut provoquer des déconnexions de sessions dans les clients ftp
#Cf http://scarybeastsecurity.blogspot.com/2009/02/vsftpd-210-released.html
require_ssl_reuse=NO
#Définit la version de l'algorithme SSL qui sera utilisé pour chiffrer les connexions
#SSL. Par défaut DES-CBC3-SHA
ssl_ciphers=HIGH

Je laisse ci-dessous le fichier de configuration dans son intégralité.

Création d’un utilisateur

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

Il sera nécessaire de configurer notre « jail » pour pas que notre utilisateur Customer1 se sauve de son home. En gros nous allons le restreindre. Dans le cas d’un jailbreak nous pouvons en tant que SysAdmin résumer la situation de la manière suivante.

Personnellement, la situation ne s’est jamais produite, mais une erreur de droit est vite arrivée. Il convient donc d’être vigilant. Dans le cas de plateforme mutualisée multi-utilisateurs, multi-clients. Il serait dommageable que Customer1 voit les données de Customer2 et vice-versa. Si tester, c’est douter, je vous recommande pour éviter les trois situations ci haut d’avoir une once de doute lors de la création des utilisateurs et de tenir une matrice des droits associés à chaque compte, groupe. 🙂

$ sudo chmod 2770 -R /mnt/customer
$ sudo chgrp Customer1 /mnt/customer1

Autorisons notre utilisateur à se connecter au service FTP/FTPS en l’ajoutant au groupe ftp.

$ sudo usermod -aG Customer1 ftp

Connexion

Bien, je crois que c’est le moment de nous connecter à notre serveur avec nos utilisateurs Customer 1 et Customer 2.

C’est un message plaisant. C’est toujours agréable de se prendre une salade de phalanges en pleine face ! Nous sommes certain du login et du mot de passe. Alors où est ce que ça m***e ??? Est-ce côté système ? Est-ce côté daemon dans la configuration ?

Il y a plusieurs pistes et je ne pourrai pas donner THE solution. Si nous avons la même configuration vous devriez vous en sortir.

Dans notre configuration du daemon vsftpd, l’argument check_shell doit être à NO. Cette option ne s’applique que dans le cas du non usage du PAM⁶. VSFTPD va vérifier le contenu du fichier /etc/shells pour les authentifications locales. Pour rappel, le fichier shells contient la liste des shells de connexion présent sur le système et si ces derniers sont valides. Sauf que voilà, pour des raisons de sécurité, nos utilisateurs ont pour shell /sbin/nologin (ils pourraient également être en /bin/false) puisque nous ne voulons surtout pas qu’ils puissent se connecter sur le système. Il nous suffira d’ajouter dans le fichier shells la ligne /sbin/nologin.

$ sudo vim /etc/shells

Recommençons la connexion à notre daemon ftp/ftps. Force est de constater que nous sommes connectés, que nous sommes bien restreint (chrooté dans notre jail). En un mot, un seul ça fonctionne !

Nous sommes bien authentifiés, toutefois comment bien faire la distinction entre l’utilisation du protocole FTP et du protocole FTPES ?

Pour répondre à cette question nous partons du principe suivant. L’utilisateur Customer1 va se connecter à notre serveur via le protocole FTP en mode passif, l’utilisateur Customer2 via le protocole FTPs en mode explicite passif. Notre serveur autorise les connexions FTP en parallèle des connexions FTPS.

Conclusion

Nous avons démontré la différence entre les deux protocoles FTP et FTPES ainsi que comment implémenter ces derniers sur un environnement sécurisé.

Nous ne pouvons pas dire que le protocole FTPES est mieux que le FTP et inversement. Sur le plan sécurité naturellement que le protocole FTP over SSL est mieux. Mais dans l’usage pas forcément. Comme présenté au début de cet article, le contexte d’usage va nous orienter vers l’une ou l’autre configuration de notre daemon ftp.

Dans un principe de moindre mal, il conviendra alors de limiter un maximum la surface d’exposition de notre service publié FTP car ce dernier est le plus vulnérable. Rien n’empêche d’appliquer ces mécanismes au service publiés FTPs.

Toujours en prenant compte du contexte d’utilisation je recommande au minimum d’implémenter 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).

Le risque zéro n’existe pas et il convient de mettre en place le maximum de mécanisme de sécurité, de maintenir ces dernières sur le plan opérationnel et analytique. D’un point de vu personnel, j’ai une forte tendance à ne pas utiliser (pour ne pas dire dénigrer) l’usage du protocole FTPS au détriment du protocole SFTP⁷. Vous me voyez venir avec mes gros sabots ? 🙂 Oui comme dit plus haut, je vais dédié un article rien que pour le SFTP pour ne pas tout mélanger et ainsi comparer les deux protocoles.

Le mot de la fin :

Transférer un séminariste via un cable link et voir en clair sous sa soutane le mot de passe « Carmélites4Ever », n’éteignez pas la console… Ah zut, qu’est ce qu’un cable link ?

Erwan GUILLEMARD

Sources

• VSFTPD – FAQ
• VSFTPD – Man
• WINSCP
• WIRESHARK
• XFERLOG Standard

1. RFC : Request For Comments ↩︎
2. FTP : File Transfert Protocol ↩︎
3. FTPS : File Transfert Protocol Secure ↩︎
4. FTPES : File Transfert Protocol Explicit Secure ↩︎
5. VSFTPD : Very Secure File Transfert Protocol Daemon ↩︎
6. PAM : Pluggable Authentication Modules ↩︎
7. SFTP : Secure File Transfert Protocol ↩︎