publish: Serveurs Linux sous attaque : comprendre la menace SSH et s'en protéger efficacement
This commit is contained in:
Cédrix
@@ -1,18 +0,0 @@
|
||||
{
|
||||
"title": "Serveurs Linux sous attaque : comprendre la menace SSH et s'en protéger efficacement",
|
||||
"slug": "serveurs-linux-sous-attaque-comprendre-la-menace-ssh-et-s-en-proteger-efficacement",
|
||||
"_updated_at": "2026-05-15 21:58:28",
|
||||
"published": true,
|
||||
"published_at": "2023-12-29 18:58",
|
||||
"category": "informatique",
|
||||
"tags": {
|
||||
"tags": [
|
||||
"OpenSSH",
|
||||
"SSH",
|
||||
"PAM",
|
||||
"Serveurs Linux"
|
||||
]
|
||||
},
|
||||
"seo_title": "",
|
||||
"seo_description": ""
|
||||
}
|
||||
@@ -1,138 +0,0 @@
|
||||
# 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 :
|
||||
|
||||
```bash
|
||||
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 :
|
||||
|
||||
```bash
|
||||
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 :
|
||||
|
||||
```bash
|
||||
echo "test" | mail -s "test" votre-adresse@example.com
|
||||
```
|
||||
|
||||
### Le script de notification
|
||||
|
||||
Créez `/usr/local/bin/ssh-notify.sh` :
|
||||
|
||||
```bash
|
||||
#!/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 :
|
||||
|
||||
```bash
|
||||
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](https://www.linux-magazine.com/Online/News/Linux-Machines-with-Poorly-Secured-SSH-Servers-are-Under-Attack)*
|
||||
@@ -7,7 +7,7 @@
|
||||
"featured": false,
|
||||
"published_at": "2023-12-29 18:58",
|
||||
"created_at": "2023-12-29 18:58:21",
|
||||
"updated_at": "2026-05-15 15:02:05",
|
||||
"updated_at": "2026-05-15 21:58:31",
|
||||
"revisions": [
|
||||
{
|
||||
"n": 1,
|
||||
|
||||
Reference in New Issue
Block a user