Remplacer les protocoles non sécurisés : Telnet contre SSH, FTP contre SFTP

De nombreux protocoles Internet fondamentaux ont été conçus dans les années 1970 et 1980, à une époque où la sécurité n’était pas une préoccupation prioritaire. Les protocoles en clair transmettent toutes les données — y compris les noms d’utilisateur, les mots de passe et les informations sensibles — en texte brut sur le réseau. Tout appareil situé sur le même segment réseau, ou tout système traversé par les paquets, peut capturer et lire ce trafic avec des outils librement disponibles comme Wireshark. Dans les environnements équipés de commutateurs réseau (qui isolent normalement le trafic entre les ports), l’usurpation ARP peut rediriger le trafic vers le système d’un attaquant, ce qui rend les protocoles en clair dangereux même sur les réseaux « internes ».

Telnet (port TCP 23) fournit un accès distant en ligne de commande aux systèmes, mais transmet tout en texte brut. Il ne possède aucune authentification intégrée autre que le nom d’utilisateur et le mot de passe, qui sont envoyés sans chiffrement. SSH (Secure Shell) (port TCP 22) remplace Telnet par un canal chiffré et authentifié. SSH utilise un échange de clés asymétriques pour établir une clé de session, puis chiffre toutes les communications suivantes au moyen d’un chiffrement symétrique. SSH authentifie également le serveur (ce qui empêche l’usurpation du serveur) et prend en charge l’authentification par clé publique (sans mot de passe, mais plus sûre que les mots de passe), en plus de l’authentification par mot de passe.

La sécurité de SSH repose sur un processus robuste d’échange de clés. Lors de la connexion, le client vérifie la clé d’hôte du serveur par rapport à une copie stockée localement — ce qui empêche l’usurpation du serveur. Si la clé d’hôte change de manière inattendue, SSH avertit l’utilisateur (ce qui constitue un signe courant d’attaque de type man-in-the-middle). Après la vérification du serveur, l’authentification du client peut utiliser : un mot de passe (chiffré pendant le transport, mais vulnérable à la force brute), une clé publique (le client prouve qu’il détient la clé privée ; méthode bien plus robuste) ou le mode interactif au clavier (qui prend en charge la MFA). Les organisations devraient imposer l’authentification par clé et désactiver l’authentification par mot de passe sur les services SSH exposés à Internet.

FTP (File Transfer Protocol) (ports TCP 20/21) transfère les fichiers en texte brut : les identifiants, les commandes et les données des fichiers sont tous exposés. FTP utilise également un canal de données distinct (en mode passif ou actif), ce qui complique les règles du firewall. SFTP (SSH File Transfer Protocol) fait transiter le transfert de fichiers par SSH sur le port 22 — il est complètement différent de FTP et ne partage avec lui qu’un nom similaire. FTPS (FTP Secure) ajoute le chiffrement TLS au protocole FTP d’origine. SFTP est généralement privilégié, car il utilise un seul port et bénéficie de l’authentification et du chiffrement de SSH. FTP devrait être désactivé sur tous les systèmes de production.

HTTP (port TCP 80) transmet le contenu Web, notamment les données des formulaires, les cookies de session et les jetons d’authentification, en texte brut. HTTPS (port TCP 443) encapsule HTTP dans TLS et fournit le chiffrement, l’authentification du serveur et l’intégrité des données. Les organisations devraient imposer HTTPS partout : rediriger tout le trafic HTTP vers HTTPS (redirection 301), mettre en œuvre HSTS pour empêcher les navigateurs de se connecter via HTTP et configurer les indicateurs de cookie Secure et HttpOnly afin d’empêcher le vol des jetons de session via HTTP ou JavaScript. Les navigateurs modernes signalent les sites HTTP comme « Non sécurisé » : HTTPS est désormais le niveau de référence attendu pour tous les services Web.

SNMP (Simple Network Management Protocol) gère les appareils et les serveurs réseau. SNMPv1 et v2c utilisent des chaînes de communauté (essentiellement des mots de passe partagés) envoyées en clair — des chaînes comme « public » (lecture) et « private » (écriture) sont des valeurs par défaut connues des attaquants. Un attaquant qui capture le trafic SNMP apprend la chaîne de communauté et peut lire les configurations des appareils ou modifier leurs paramètres. SNMPv3 ajoute l’authentification (HMAC-MD5 ou HMAC-SHA) et le chiffrement (AES), avec des identifiants propres à chaque utilisateur, ce qui en fait la seule version adaptée aux environnements de production. SNMPv1/v2c devrait être désactivé.

LDAP (Lightweight Directory Access Protocol) (port TCP 389) authentifie les services d’annuaire et les interroge (Active Directory, OpenLDAP) en clair par défaut, exposant ainsi les identifiants et les données d’annuaire. LDAPS (LDAP over SSL/TLS, port TCP 636) chiffre la connexion à l’aide d’un certificat. StartTLS est une autre solution qui fait évoluer une connexion LDAP existante vers TLS en utilisant le même port 389. LDAPS et StartTLS fournissent tous deux un chiffrement, mais LDAPS est généralement plus simple et plus fiable. Les organisations devraient configurer toutes les applications qui utilisent LDAP pour employer LDAPS et bloquer LDAP en clair sur le port 389 au niveau du firewall.

Les anciens clients de messagerie récupèrent les e-mails avec POP3 (port 110) et IMAP (port 143) en clair. Les solutions chiffrées sont les suivantes : POP3S (port 995, TLS) et IMAPS (port 993, TLS). Les plateformes de messagerie modernes (Exchange Online, Google Workspace) imposent TLS pour toutes les connexions clientes et prennent en charge l’authentification par jeton OAuth 2.0 plutôt que par mot de passe. Les organisations devraient désactiver l’authentification de base sur les protocoles de messagerie : imposer l’authentification moderne (OAuth 2.0 + MFA) empêche les attaques par bourrage d’identifiants qui exploitent les mécanismes d’authentification en clair des anciens protocoles de messagerie.

Le remplacement des protocoles non sécurisés nécessite plus que l’activation de leur version sécurisée : la version non sécurisée doit être désactivée activement. Étapes : auditer l’utilisation actuelle des protocoles (analyses Nmap, journaux du firewall), migrer les applications et les configurations vers le protocole sécurisé, effectuer des tests approfondis (les applications métier peuvent cesser de fonctionner), puis bloquer le protocole non sécurisé au niveau du firewall et de l’hôte. Pièges courants : les anciennes imprimantes et les appareils intégrés ne prennent souvent en charge que FTP ou SNMPv2 ; les anciens systèmes industriels peuvent dépendre de Telnet. Ils nécessitent une isolation réseau ou un remplacement par le fournisseur, plutôt qu’une simple mise à niveau du protocole.

RDP (Remote Desktop Protocol) (port 3389) est largement utilisé pour l’administration distante de Windows et constitue une cible majeure pour les attaques. Les configurations RDP non sécurisées comprennent : l’exposition du port 3389 à Internet, l’utilisation d’une authentification par mot de passe uniquement et la désactivation de NLA. Renforcement de RDP : activez l’authentification au niveau du réseau (NLA), qui authentifie l’utilisateur avant l’ouverture de la session complète (bloquant les connexions non authentifiées) ; exigez TLS 1.2+ pour toutes les sessions RDP ; placez RDP derrière un VPN ou une passerelle RDP plutôt que de l’exposer à Internet ; et imposez le verrouillage des comptes pour empêcher les attaques par force brute. De nombreuses campagnes de rançongiciel obtiennent leur accès initial par l’intermédiaire de RDP exposés et mal sécurisés.

La migration hors des protocoles non sécurisés dans les environnements de production nécessite une planification minutieuse afin d’éviter toute interruption de l’activité. Approche progressive : Phase 1 — Découverte : exécutez des analyses Nmap et auditez les journaux du firewall afin d’identifier toutes les utilisations de protocoles en clair. Phase 2 — Activation des solutions sécurisées : configurez SSH, SFTP et HTTPS parallèlement aux services non sécurisés existants. Phase 3 — Migration des utilisateurs : mettez à jour les scripts, les applications, les outils de surveillance et les procédures utilisateur afin qu’ils utilisent le protocole sécurisé. Phase 4 — Désactivation et blocage : désactivez le service non sécurisé sur chaque hôte et bloquez le port au niveau du firewall. Des tests à chaque phase permettent d’éviter les interruptions en production.

Testez votre compréhension des concepts de CompTIA Security+ (SY0-701) abordés dans cette leçon.

Dans cette leçon, vous avez appris que les protocoles en clair (Telnet, FTP, HTTP, SNMPv1/v2c, LDAP) exposent les identifiants et les données à l'écoute du réseau et doivent être remplacés, que les remplacements sécurisés (SSH, SFTP, HTTPS, SNMPv3, LDAPS) utilisent le chiffrement TLS ou SSH pour protéger les mêmes fonctionnalités, et que le remplacement des protocoles nécessite de désactiver la version non sécurisée au niveau du pare-feu et de l'hôte après avoir recherché les dépendances héritées. Nous allons maintenant étudier les versions de TLS, les suites de chiffrement et la confidentialité persistante parfaite.