Sécuriser un transfert de fichiers avec le port scp en entreprise

Le Secure Copy Protocol (SCP), un pilier de la sécurité réseau, permet un transfert de fichiers sécurisé entre des hôtes locaux et distants, s'appuyant sur Secure Shell (SSH) pour un chiffrement robuste des données. Bien que des alternatives comme SFTP existent, SCP demeure populaire dans les environnements d'entreprise, notamment pour sa simplicité, sa disponibilité et sa familiarité avec les administrateurs système. En effet, 75% des entreprises utilisent encore SCP pour des transferts internes de fichiers sensibles, selon une enquête récente de Cybersecurity Ventures.

La sécurité du protocole SCP est primordiale pour toute entreprise manipulant des données sensibles. Une configuration inadéquate du port SCP peut entraîner des violations de données coûteuses, des accès non autorisés aux systèmes critiques et même la compromission de l'infrastructure SSH sous-jacente. Les conséquences peuvent s'avérer désastreuses, allant de pertes financières et juridiques substantielles à des dommages irréparables à la réputation de l'entreprise. L'étude "Cost of a Data Breach Report" d'IBM en 2023 estime le coût moyen d'une violation de données à 4,45 millions de dollars, soulignant l'importance d'une protection adéquate. Pour atténuer ces risques, il est impératif de comprendre les vulnérabilités potentielles et de mettre en œuvre des mesures de sécurité proactives pour sécuriser le port SCP et les transferts de fichiers en entreprise.

La sécurité du protocole SCP repose fondamentalement sur la robustesse du protocole SSH. Par conséquent, les faiblesses inhérentes à SSH se répercutent directement sur la sécurité des transferts de fichiers via SCP. Une mauvaise configuration du port SSH, combinée à des pratiques de sécurité laxistes de la part des utilisateurs, augmente considérablement les risques d'exploitation par des acteurs malveillants. Il est essentiel d'identifier, de comprendre et de corriger ces vulnérabilités pour sécuriser efficacement l'utilisation du port SCP et les transferts de fichiers au sein de l'entreprise.

Vulnérabilités inhérentes à SSH (sur lequel SCP repose)

• Attaques par force brute sur les mots de passe : Les attaquants peuvent tenter de deviner les mots de passe des utilisateurs légitimes en effectuant des attaques par force brute. Ces attaques consistent à essayer un grand nombre de combinaisons de mots de passe jusqu'à ce qu'ils trouvent la bonne. Selon le rapport Verizon Data Breach Investigations Report de 2023, 82% des violations de données impliquent une compromission des informations d'identification, souvent par des mots de passe volés ou faibles. L'impact d'une attaque réussie peut être significatif, permettant aux attaquants d'accéder à des systèmes critiques et à des données sensibles.
• Faiblesses dans les algorithmes de chiffrement SSH : L'utilisation d'algorithmes de chiffrement SSH obsolètes ou cryptographiquement faibles, tels que SHA-1, rend les transferts SCP vulnérables aux attaques de déchiffrement. Bien que SHA-1 ait été largement utilisé dans le passé, il est désormais considéré comme "cassé", ce qui signifie qu'il est possible de créer des collisions cryptographiques, permettant ainsi aux attaquants de décrypter les données chiffrées avec cet algorithme. Les entreprises doivent impérativement garantir l'utilisation d'algorithmes de chiffrement robustes et modernes, tels que AES-256-GCM ou ChaCha20-Poly1305.
• Vulnérabilités dans les versions obsolètes d'OpenSSH : Les versions obsolètes du serveur OpenSSH peuvent contenir des vulnérabilités de sécurité connues qui peuvent être exploitées par des attaquants malveillants pour obtenir un accès non autorisé aux systèmes. Par exemple, une vulnérabilité critique d'exécution de code à distance (RCE) a été découverte dans OpenSSH version 7.7 en 2018, permettant à un attaquant d'exécuter des commandes arbitraires sur le serveur. Il est donc absolument crucial de maintenir OpenSSH à jour avec les derniers correctifs de sécurité afin de se prémunir contre ces vulnérabilités connues et les potentielles exploitations.

Mauvaise configuration de SCP et SSH

• Activation de l'authentification par mot de passe : Autoriser l'authentification par mot de passe augmente considérablement le risque d'attaques par force brute et de compromission des informations d'identification. Les mots de passe peuvent être volés, devinés ou compromis par diverses méthodes, permettant aux attaquants d'obtenir un accès non autorisé aux systèmes critiques. Désactiver l'authentification par mot de passe et utiliser l'authentification par clé SSH est une mesure de sécurité essentielle pour protéger le port SCP.
• Utilisation de comptes avec des privilèges excessifs pour les transferts SCP : L'utilisation de comptes d'utilisateurs avec des privilèges excessifs pour effectuer les transferts de fichiers via SCP viole le principe du moindre privilège, un concept fondamental de la sécurité informatique. Si un compte d'utilisateur avec des privilèges administratifs est compromis, un attaquant peut potentiellement accéder à l'ensemble du système et causer des dommages considérables. Il est préférable de créer des comptes dédiés spécifiquement pour les transferts SCP, en leur attribuant uniquement les privilèges minimaux nécessaires à l'exécution de cette tâche.
• Absence de monitoring et d'audit des transferts SCP : Sans mise en place d'un monitoring et d'un audit appropriés, il est extrêmement difficile de détecter les activités suspectes, les anomalies ou les tentatives de violations de sécurité ciblant le port SCP et les transferts de fichiers. La journalisation des connexions SSH et des transferts SCP permet d'identifier les comportements anormaux, de retracer les activités des utilisateurs et de mener des enquêtes approfondies en cas d'incident de sécurité. La conformité aux normes de sécurité telles que PCI DSS (Payment Card Industry Data Security Standard) exige souvent un suivi rigoureux des accès aux données sensibles, soulignant l'importance du monitoring et de l'audit.
• Utilisation de clés SSH sans phrase secrète : Si une clé SSH privée est compromise, mais qu'elle est protégée par une phrase secrète robuste, un attaquant ne pourra pas l'utiliser immédiatement pour obtenir un accès non autorisé au système. La phrase secrète ajoute une couche de protection supplémentaire, même si la clé elle-même est volée ou exposée. Il est impératif d'exiger l'utilisation de phrases secrètes robustes et difficiles à deviner pour toutes les clés SSH utilisées pour l'authentification auprès du port SCP. Le NIST recommande des phrases secrètes d'au moins 15 caractères.

Vulnérabilités liées à l'utilisateur

• Clés SSH compromises : Les clés SSH privées peuvent être compromises de différentes manières, notamment par des attaques de phishing ciblées, des infections par des logiciels malveillants sophistiqués ou des vols de données physiques. Selon une étude du Ponemon Institute, 63% des entreprises ont subi une violation de données due à des informations d'identification compromises, soulignant l'importance de protéger les clés SSH privées. Il est essentiel de mettre en œuvre des mesures de sécurité robustes pour protéger les clés SSH privées et d'éduquer les utilisateurs sur les risques et les bonnes pratiques de sécurité.
• Ingénierie sociale pour obtenir les clés SSH : Les attaquants peuvent utiliser des techniques d'ingénierie sociale complexes pour inciter les utilisateurs légitimes à révéler leurs clés SSH privées ou les phrases secrètes qui les protègent. Par exemple, ils peuvent se faire passer pour des administrateurs système et demander aux utilisateurs de leur envoyer leurs clés SSH privées sous prétexte d'effectuer une maintenance de routine ou de résoudre un problème technique. La sensibilisation des utilisateurs aux techniques d'ingénierie sociale est essentielle pour prévenir ce type d'attaques sophistiquées.
• Stockage non sécurisé des clés SSH par les utilisateurs : De nombreux utilisateurs stockent leurs clés SSH privées dans des emplacements non sécurisés, tels que des lecteurs non chiffrés, des partages réseau non protégés ou des services de stockage cloud non fiables. Cela rend les clés vulnérables au vol, à l'exposition accidentelle et à l'accès non autorisé par des personnes mal intentionnées. Il est fortement recommandé d'utiliser des gestionnaires de mots de passe sécurisés ou des coffres-forts numériques pour stocker les clés SSH privées de manière chiffrée et sécurisée. Un gestionnaire de mot de passe avec chiffrement AES-256 est une bonne pratique.

Pour renforcer la sécurité des transferts de fichiers via le port SCP dans un environnement d'entreprise, il est impératif d'adopter une approche proactive et multicouche. Cette approche doit inclure le renforcement de la sécurité du protocole SSH sous-jacent, la mise en place d'un contrôle d'accès granulaire et la mise en place d'un monitoring et d'un audit rigoureux des transferts. En combinant ces mesures de sécurité, une entreprise peut réduire considérablement les risques de violations de données, de compromission des systèmes et d'accès non autorisés aux informations sensibles.

Renforcement de la sécurité SSH

• Désactiver l'authentification par mot de passe : Pour désactiver complètement l'authentification par mot de passe, vous devez éditer le fichier de configuration du serveur SSH, généralement situé à `/etc/ssh/sshd_config`. Recherchez la ligne `PasswordAuthentication yes` et remplacez-la par `PasswordAuthentication no`. Ensuite, enregistrez les modifications et redémarrez le service SSH à l'aide de la commande `sudo systemctl restart sshd`. Cette mesure de sécurité simple, mais efficace, élimine la possibilité d'attaques par force brute visant à deviner les mots de passe des utilisateurs.
• Activer l'authentification par clé SSH : La première étape pour activer l'authentification par clé SSH consiste à générer une paire de clés SSH (une clé publique et une clé privée) sur la machine du client. Vous pouvez utiliser la commande `ssh-keygen -t rsa -b 4096` pour générer une clé RSA de 4096 bits. Ensuite, vous devez copier la clé publique sur le serveur en utilisant la commande `ssh-copy-id user@server`, où `user` est le nom d'utilisateur sur le serveur et `server` est l'adresse IP ou le nom d'hôte du serveur. Assurez-vous d'utiliser une phrase secrète robuste et difficile à deviner lors de la génération de la clé privée pour protéger la clé en cas de compromission. L'utilisation de clés de 4096 bits assure une meilleure protection cryptographique.
• Configurer la directive `PermitRootLogin no` : Afin d'empêcher les connexions directes en tant qu'utilisateur root, ce qui réduit considérablement le risque de compromission du compte administrateur, vous devez modifier le fichier `/etc/ssh/sshd_config` et ajouter ou modifier la ligne `PermitRootLogin no`. Après avoir enregistré les modifications, redémarrez le service SSH à l'aide de la commande `sudo systemctl restart sshd`.
• Limiter l'accès SSH via `AllowUsers` ou `AllowGroups` : Vous pouvez contrôler précisément quels utilisateurs ou groupes d'utilisateurs sont autorisés à se connecter via SSH en utilisant les directives `AllowUsers` ou `AllowGroups` dans le fichier `/etc/ssh/sshd_config`. Par exemple, la directive `AllowUsers user1 user2` autorisera uniquement les utilisateurs `user1` et `user2` à se connecter via SSH. De même, la directive `AllowGroups admins devops` autorisera uniquement les membres des groupes `admins` et `devops`. Il est recommandé d'utiliser `AllowGroups` pour une meilleure gestion des accès.
• Configurer les algorithmes de chiffrement et les échanges de clés préférés : Dans le fichier `/etc/ssh/sshd_config`, vous pouvez spécifier les algorithmes de chiffrement et les échanges de clés préférés en utilisant les directives `Ciphers` et `KexAlgorithms`. Par exemple: `Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com` et `KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256`. Ces paramètres permettent d'utiliser les algorithmes les plus robustes et les plus performants disponibles pour sécuriser les connexions SSH.
• Désactiver l'authentification GSSAPI si non nécessaire : Si vous n'utilisez pas l'authentification GSSAPI, il est recommandé de la désactiver complètement afin de réduire la surface d'attaque du serveur SSH. Pour désactiver GSSAPI, ajoutez ou modifiez les lignes suivantes dans le fichier `/etc/ssh/sshd_config`: `GSSAPIAuthentication no` et `GSSAPICleanupCredentials no`. N'oubliez pas de redémarrer le service SSH après avoir effectué ces modifications.
• Mise à jour régulière d'OpenSSH : Les mises à jour d'OpenSSH contiennent des correctifs de sécurité critiques qui corrigent les vulnérabilités connues et améliorent la sécurité globale du serveur SSH. Assurez-vous de mettre à jour OpenSSH régulièrement en utilisant les outils de gestion de paquets de votre système d'exploitation (par exemple, `apt update && apt upgrade` sous Debian/Ubuntu ou `yum update openssh` sous CentOS/RHEL). Une entreprise a signalé une diminution de 70% des tentatives d'intrusion après avoir mis à jour OpenSSH.

Contrôle d'accès granulaire pour SCP

• Utilisation de comptes dédiés pour les transferts SCP avec des privilèges minimaux : Créez des comptes d'utilisateurs spécifiques et dédiés aux transferts de fichiers via SCP. Ces comptes doivent être configurés avec les privilèges les plus stricts possibles, limités aux seuls répertoires et fichiers nécessaires à la tâche de transfert. Par exemple, vous pouvez créer un compte nommé `scpuser` et lui accorder uniquement les droits de lecture et d'écriture sur un répertoire spécifique désigné pour les transferts de fichiers.
• Utilisation de `ForceCommand` dans le fichier `authorized_keys` pour limiter les commandes exécutables via SSH : La directive `ForceCommand` dans le fichier `~/.ssh/authorized_keys` permet de restreindre les commandes que l'utilisateur peut exécuter via une connexion SSH authentifiée par clé publique. Par exemple, pour autoriser uniquement l'exécution de la commande `scp -t /path/to/destination`, vous pouvez ajouter la ligne suivante avant la clé publique dans le fichier `authorized_keys`: `command="scp -t /path/to/destination"`. L'automatisation de cette configuration peut être réalisée à l'aide d'outils d'automatisation tels qu'Ansible. Un exemple de playbook Ansible serait: