SSHole : faille OpenSSH exploitée, 5 gestes pour une PME

Ce qui s’est passé

Des pirates exploitent une faille d’OpenSSH surnommée « SSHole » pour s’introduire dans des systèmes Linux. OpenSSH est le logiciel le plus répandu pour administrer un serveur à distance par le protocole SSH (connexion chiffrée en ligne de commande, en général sur le port 22).

Le 9 novembre 2026, la CISA (l’agence américaine de cybersécurité) a annoncé avoir ajouté quatre vulnérabilités à son catalogue KEV (Known Exploited Vulnerabilities, la liste des failles dont l’exploitation réelle est confirmée). Cet ajout comprend la faille d’OpenSSH ainsi que des failles touchant GPUStack, FreeSWITCH et des produits IBM. L’exploitation de SSHole compte aussi parmi les faits marquants de la semaine en cybersécurité.

Point clé : il ne s’agit pas d’un risque théorique. Une inscription au catalogue KEV veut dire que des attaquants utilisent déjà cette faille.

Pour l’identifiant CVE exact, les versions touchées et les versions corrigées, consultez l’avis de la CISA ainsi que les bulletins de vos fournisseurs.

Pourquoi ça compte pour une PME

OpenSSH est probablement chez vous, souvent sans que vous le sachiez

Beaucoup de dirigeants pensent ne pas utiliser SSH. Pourtant, on le trouve couramment dans :

• Les serveurs Linux : site web, intranet, serveur de fichiers ou applicatif, y compris ceux gérés par un prestataire.
• Les NAS (boîtiers de stockage réseau pour les fichiers et les sauvegardes) : beaucoup proposent un service SSH, parfois activé pour le dépannage puis oublié.
• Les pare-feu, routeurs et autres équipements réseau : plusieurs reposent sur Linux et s’administrent par SSH.
• Les machines virtuelles infonuagiques (serveurs loués chez un fournisseur de nuage) : les images Linux standard ouvrent souvent le port 22 par défaut.

Attention : un équipement fermé comme un NAS ou un pare-feu ne se met pas à jour avec les outils Linux habituels. Il faut attendre et installer le micrologiciel (logiciel interne de l’appareil) publié par le fabricant.

Niveau de risque

Ce qu’un accès SSH compromis met en jeu : la prise de contrôle du serveur, le vol de données, l’installation de logiciels malveillants ou d’un rançongiciel (logiciel qui chiffre vos fichiers pour exiger une rançon). Sur un NAS, ce sont souvent les sauvegardes, votre dernier recours, qui sont exposées.

Comment se protéger

Le catalogue KEV comme boussole

Une PME ne peut pas tout corriger le jour même. Le catalogue KEV de la CISA est gratuit et public. C’est un outil simple pour savoir quoi corriger en premier : toute faille inscrite au KEV qui touche un de vos produits passe en tête de liste, avant les failles jugées graves mais non exploitées. Consultez-le chaque semaine, ou abonnez-vous aux alertes de la CISA.

Plan d’action en 5 étapes

Étape 1 — Inventaire : qu’est-ce qui est exposé ?

• Vérifiez les règles de redirection de port (port forwarding) du pare-feu et du routeur : y a-t-il une redirection vers le port 22 ou un autre port SSH ?
• Dans la console de votre fournisseur de nuage, examinez les groupes de sécurité (règles de filtrage réseau) : cherchez un port 22 ouvert à 0.0.0.0/0, c’est-à-dire à tout Internet.
• Depuis l’extérieur de votre réseau, et seulement sur vos propres adresses IP publiques, lancez un balayage de ports :

# Remplacer par VOS adresses IP publiques uniquement
nmap -Pn -p 22,2222 -sV VOTRE_IP_PUBLIQUE

• Sur chaque serveur Linux, listez les services en écoute et la version d’OpenSSH installée :

sudo ss -tlnp | grep ssh
# Debian / Ubuntu
dpkg -l | grep openssh-server
# RHEL / Rocky / Alma
rpm -q openssh-server

Notez chaque équipement dans un tableau : nom, rôle, version, exposé ou non sur Internet, responsable.

Étape 2 — Correctif prioritaire

• Serveurs Linux : installez les mises à jour de sécurité de votre distribution dès qu’elles sont publiées pour cette faille, puis redémarrez le service SSH.

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade openssh-server
# RHEL / Rocky / Alma
sudo dnf update openssh-server
sudo systemctl restart sshd   # ou "ssh" selon la distribution

• NAS, pare-feu, équipements réseau : consultez les bulletins de sécurité de chaque fabricant et appliquez le micrologiciel corrigé. S’il n’y en a pas encore, désactivez SSH sur l’appareil ou coupez son accès depuis Internet.
• Prestataires et hébergeurs : demandez-leur par écrit la confirmation que leurs systèmes sont corrigés, avec la date.
• En ITIL, traitez cette mise à jour comme un changement d’urgence : approbation accélérée, plan de retour arrière, et une session de console ou d’accès hors bande ouverte pendant l’opération, pour ne pas vous bloquer hors du serveur.

Étape 3 — Restreindre l’accès SSH

• Un service SSH ne devrait pratiquement jamais être ouvert à tout Internet. Rendez-le accessible uniquement par VPN (tunnel chiffré vers votre réseau), ou depuis une liste d’adresses IP autorisées (bureau, prestataire).
• Exemple de pare-feu local sur un serveur Linux (UFW), à adapter :

sudo ufw allow from ADRESSE_IP_AUTORISEE to any port 22 proto tcp
sudo ufw deny 22/tcp
sudo ufw enable

Cette mesure réduit fortement le risque, même avant que le correctif soit disponible ou installé.

Étape 4 — Clés plutôt que mots de passe

Une clé SSH (paire de fichiers cryptographiques qui remplace le mot de passe) résiste aux attaques par devinette de mot de passe. Après avoir vérifié que votre clé fonctionne, modifiez /etc/ssh/sshd_config :

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

sudo sshd -t && sudo systemctl reload sshd

La commande sshd -t vérifie la configuration avant de recharger le service, ce qui évite de vous couper l’accès. Précision importante : cette mesure ne remplace pas le correctif. Elle ferme d’autres portes d’entrée courantes.

Étape 5 — Chercher des traces de compromission

Si un serveur a été exposé avec une version vulnérable, partez du principe qu’il a pu être visité. Les attaquants cherchent souvent à garder un accès (persistance) en ajoutant un compte ou une clé SSH. À vérifier :

# Comptes pouvant ouvrir une session (shell interactif)
grep -vE 'nologin|false' /etc/passwd

# Comptes avec privilèges administrateur
getent group sudo wheel

# Clés SSH autorisées, avec date de modification
sudo find / -name "authorized_keys*" -exec ls -la {} \; 2>/dev/null

# Connexions récentes et échecs
last -a | head -50
sudo journalctl -u ssh -u sshd --since "14 days ago" | grep -Ei "accepted|failed"

# Tâches planifiées (autre mécanisme de persistance fréquent)
sudo ls -la /etc/cron* /var/spool/cron 2>/dev/null

• Soyez attentif aux clés ou comptes inconnus, aux connexions depuis des adresses IP inhabituelles et aux fichiers modifiés récemment sans changement planifié.
• Sur un NAS ou un pare-feu, consultez les journaux d’administration et la liste des utilisateurs dans l’interface web.

En cas de doute : qui alerter et comment réagir

• Ouvrez un incident (gestion des incidents ITIL) dès qu’une anomalie apparaît. Isolez le système du réseau, mais ne l’éteignez pas, pour conserver les preuves en mémoire.
• Prévenez votre prestataire TI ou votre fournisseur de services de sécurité gérés, ainsi que votre assureur cyber si vous en avez un.
• Signalez l’incident au Centre canadien pour la cybersécurité. Si des renseignements personnels sont en cause, évaluez vos obligations de déclaration à la Commission d’accès à l’information du Québec (Loi 25).
• Changez les clés et mots de passe des comptes touchés à partir d’un poste sain, puis réinstallez le système à partir d’une source fiable s’il y a compromission avérée.