Serveurs Linux sous attaque : comprendre la menace SSH et s'en protéger efficacement

Une menace persistante contre les serveurs Linux exposés

Les serveurs Linux accessibles depuis Internet font l'objet d'attaques continues visant à les enrôler dans des réseaux de minage de cryptomonnaies et des botnets DDoS. Le centre d'analyse sud-coréen AhnLab Security Emergency Response Center (ASEC) a documenté une campagne dans laquelle des attaquants exploitent le service SSH exposé sur le port 22 par défaut, en testant méthodiquement des combinaisons d'identifiants courants — ce que l'on désigne sous le terme d'attaque par force brute, ou par dictionnaire lorsque les essais s'appuient sur des listes de mots de passe connus.

Une fois l'accès obtenu, les attaquants déploient un arsenal modulaire : un scanner de ports pour cartographier le réseau interne et identifier de nouvelles cibles, le cryptomineur CoinMiner qui détourne les ressources CPU au profit de l'attaquant, et DDoSbot qui transforme la machine en relais d'attaque. Les identifiants compromis sont par ailleurs susceptibles d'être revendus sur des marchés clandestins, alimentant des compromissions ultérieures.

L'ASEC attribue l'outillage à une variante modifiée d'un kit attribué au collectif PRG old Team. Cette campagne s'inscrit dans une tendance de fond : les serveurs SSH mal configurés constituent depuis des années l'une des portes d'entrée les plus exploitées sur Internet, indépendamment de cet acteur particulier.

Une menace distincte : la vulnérabilité Terrapin

Il faut distinguer ces attaques par force brute d'une autre catégorie de menace pesant sur SSH : la vulnérabilité Terrapin (CVE-2023-48795), divulguée fin 2023 par des chercheurs de l'université de la Ruhr à Bochum. Contrairement aux attaques par dictionnaire, Terrapin ne cible pas les mots de passe mais le protocole SSH lui-même, via une technique dite de prefix truncation permettant à un attaquant en position d'homme-du-milieu de tronquer la négociation cryptographique initiale.

Les deux problèmes appellent des réponses différentes : Terrapin se corrige par la mise à jour des clients et serveurs SSH (OpenSSH 9.6 et suivants), tandis que les attaques par force brute relèvent d'une bonne hygiène de configuration.

Sécuriser SSH : les mesures qui comptent vraiment

Les conseils habituels — mots de passe forts, mises à jour, changement de port — ne sont pas équivalents. Voici les mesures classées par efficacité réelle.

1. Désactiver l'authentification par mot de passe

C'est la mesure la plus efficace contre les attaques par dictionnaire : si aucun mot de passe n'est accepté, aucune attaque par force brute ne peut aboutir. Il faut au préalable déposer sa clé publique sur le serveur (ssh-copy-id utilisateur@serveur), puis dans /etc/ssh/sshd_config :

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

2. Limiter qui peut se connecter

Restreindre les comptes autorisés réduit drastiquement la surface d'attaque :

AllowUsers alice bob

3. Bannir automatiquement les IP malveillantes

Des outils comme fail2ban ou CrowdSec analysent les journaux et bloquent temporairement les adresses qui multiplient les échecs d'authentification. Installation typique sur Debian/Ubuntu :

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

La configuration par défaut protège déjà SSH.

4. Mettre à jour régulièrement

Indispensable pour corriger Terrapin et les futures vulnérabilités protocolaires :

sudo apt update && sudo apt upgrade

5. Changer le port SSH : un bénéfice limité

Déplacer SSH du port 22 vers un port non standard réduit le bruit dans les journaux (les scanners automatiques visent majoritairement le 22), mais ne constitue pas une véritable mesure de sécurité — c'est de la security through obscurity. Un attaquant ciblé scannera l'ensemble des ports. À considérer comme un confort opérationnel, pas comme une protection.

6. Pour les environnements sensibles

Placer SSH derrière un bastion ou un VPN, ou utiliser un système comme Tailscale ou WireGuard, retire purement et simplement le service de l'Internet public.

Recevoir une alerte mail à chaque connexion SSH

Au-delà de la prévention, il est utile d'être notifié en temps réel des connexions. La méthode souvent recommandée — utiliser ForceCommand dans sshd_config — est à proscrire : ForceCommand remplace la commande de l'utilisateur et l'empêche d'ouvrir une session shell normale. La bonne approche utilise PAM (Pluggable Authentication Modules), qui s'exécute en marge de la session sans interférer.

Prérequis : un moyen d'envoyer des mails

Le serveur doit pouvoir émettre des courriels, via postfix, msmtp ou un relais SMTP externe. Vérifiez avec :

echo "test" | mail -s "test" votre-adresse@example.com

Le script de notification

Créez /usr/local/bin/ssh-notify.sh :

#!/bin/bash

# Ne notifier que les ouvertures de session, pas les fermetures ni les autres événements PAM
[ "$PAM_TYPE" = "open_session" ] || exit 0

RECIPIENT="votre-adresse@example.com"
SUBJECT="[SSH] Connexion sur $(hostname) — utilisateur $PAM_USER"

MESSAGE="Une session SSH a été ouverte.

Hôte       : $(hostname)
Date       : $(date '+%Y-%m-%d %H:%M:%S %Z')
Utilisateur: $PAM_USER
Service    : $PAM_SERVICE
TTY        : $PAM_TTY
IP source  : $PAM_RHOST
"

echo "$MESSAGE" | mail -s "$SUBJECT" "$RECIPIENT"
exit 0

Les variables PAM_USER, PAM_RHOST, etc., sont fournies automatiquement par PAM et incluent l'adresse IP source — information autrement plus utile que le simple nom d'utilisateur en cas de tentative d'intrusion.

Rendez le script exécutable et restreignez ses permissions :

sudo chmod 700 /usr/local/bin/ssh-notify.sh
sudo chown root:root /usr/local/bin/ssh-notify.sh

Activer le script via PAM

Éditez /etc/pam.d/sshd et ajoutez à la fin du fichier :

session optional pam_exec.so seteuid /usr/local/bin/ssh-notify.sh

Le mot-clé optional garantit qu'un échec d'envoi de mail n'empêchera jamais la connexion légitime. Aucun redémarrage de sshd n'est nécessaire : PAM relit sa configuration à chaque session.

Tester sans se verrouiller dehors

Avant de fermer votre session actuelle, ouvrez une seconde connexion SSH depuis une autre fenêtre pour vérifier que tout fonctionne et que vous recevez bien le mail. C'est une précaution essentielle dès qu'on modifie quoi que ce soit lié à l'authentification.

Limiter l'exposition de la notification

L'envoi par mail circule potentiellement en clair selon votre configuration SMTP. Pour des environnements sensibles, préférez un canal authentifié (webhook vers Slack, Discord, Telegram, ou Gotify auto-hébergé) plutôt qu'un mail standard.

Pour conclure

Les attaques décrites par l'ASEC ne reposent sur aucune sophistication particulière : elles exploitent essentiellement la faiblesse des mots de passe et l'exposition par défaut du port 22. La parade tient en une phrase : passer à l'authentification par clé, désactiver les mots de passe, et superviser les connexions. Le changement de port et le renforcement des mots de passe — souvent mis en avant — sont au mieux des mesures complémentaires, au pire une fausse assurance. La vulnérabilité Terrapin rappelle par ailleurs qu'aucune configuration ne dispense de maintenir ses paquets à jour.

Source originale : linux-magazine.com