Référence des ports
Port 22 (TCP) – SSH
Secure Shell — connexion distante chiffrée, exécution de commandes et tunnelisation.
État par défaut
Ouvert par défaut sur la plupart des serveurs Linux/Unix et des équipements réseau. Souvent exposé à Internet pour l'administration distante.
Attaques courantes
- Force brute et pulvérisation de mots de passe
- Identifiants par défaut ou faibles sur appareils/IoT
- Clés privées volées ou non gérées
- Énumération d'utilisateurs et CVE spécifiques (ex. CVE-2024-6387 « regreSSHion »)
Durcissement
- Désactiver l'authentification par mot de passe — utiliser des clés ou certificats
- Désactiver la connexion root (PermitRootLogin no)
- Limiter le débit et verrouiller avec fail2ban ou équivalent
- Restreindre par liste d'IP / hôte rebond ; envisager un port non standard pour réduire le bruit
- Maintenir OpenSSH à jour et imposer la MFA
Commande nmap
nmap -p22 --script ssh2-enum-algos,ssh-auth-methods <target>Remplacez <target> par l’hôte ou la plage que vous êtes autorisé à scanner.
Qu'est-ce qui tourne sur le port 22 ?
Le port 22 est le port enregistré de SSH (Secure Shell), le protocole chiffré utilisé pour la connexion distante, l'exécution de commandes, le transfert sécurisé de fichiers (SCP/SFTP) et le port forwarding. Il a remplacé des protocoles en clair comme Telnet (port 23) et rlogin, et constitue le canal d'administration par défaut de quasiment tous les serveurs Linux/Unix, routeurs et équipements réseau.
Pourquoi c'est important pour la sécurité
Parce que SSH fournit un shell interactif, un attaquant qui entre obtient en général le contrôle complet de l'hôte. Un 22 ouvert est donc l'un des ports les plus scannés d'Internet, martelé en permanence par des botnets essayant des identifiants fuités et par défaut. Le chiffrement protège les données en transit, mais n'empêche en rien les mots de passe faibles, les clés mal gérées ou un démon SSH vulnérable.
Comment il est attaqué
L'attaque dominante est la force brute / pulvérisation de mots de passe contre les hôtes découverts, en particulier les équipements livrés avec des identifiants par défaut. Les clés privées non chiffrées, partagées ou laissées sur des machines compromises permettent d'entrer sans mot de passe. Périodiquement, des failles du démon comme la RCE pré-authentification « regreSSHion » de 2024 (CVE-2024-6387) exposent même des serveurs bien configurés tant qu'ils ne sont pas corrigés.
Liste de durcissement
Désactivez l'authentification par mot de passe et utilisez des clés ou certificats ; désactivez la connexion root directe ; ajoutez une limitation de débit / verrouillage (fail2ban) pour casser la force brute. Placez SSH derrière un hôte rebond ou un VPN et limitez les IP sources. Maintenez OpenSSH à jour et ajoutez la MFA pour les accès privilégiés. La commande nmap ci-dessus énumère les algorithmes et méthodes d'authentification de l'hôte afin de repérer les configurations faibles sur les systèmes que vous êtes autorisé à tester.
Ports liés
Questions fréquentes
- Est-il sûr d'exposer le port 22 à Internet ?
- Avec une authentification par clé uniquement, sans connexion root, avec limitation de débit et OpenSSH à jour, c'est acceptable, mais un hôte rebond ou un VPN est plus sûr. L'authentification par mot de passe sur le 22 est massivement attaquée.
- Pourquoi le port 22 est-il constamment scanné ?
- SSH donne un shell distant, c'est donc une cible de grande valeur. Les botnets pulvérisent en continu des identifiants par défaut et fuités contre chaque 22 ouvert.