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",
|
||||
"_updated_at": "2026-05-15 15:02:05",
|
||||
"slug": "serveurs-linux-sous-attaque-comprendre-la-menace-ssh-et-s-en-proteger-efficacement",
|
||||
"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)*
|
||||
@@ -1,66 +1,138 @@
|
||||
# Attaques Cryptographiques Sur Les Serveurs Linux : Mineurs Malveillants et Vulnérabilités SSH
|
||||
# Serveurs Linux sous attaque : comprendre la menace SSH et s'en protéger efficacement
|
||||
|
||||
Une vague de cyberattaques cible spécifiquement les serveurs Linux en les intégrant de force dans des réseaux de minage de cryptomonnaies et en propageant simultanément des attaques par déni de service distribué. Selon le rapport récent du AhnLab Security Emergency Response Center (ASEC), des cybercriminels exploitent des failles de sécurité en devinant les identifiants SSH à travers des attaques par force brute, communément appelées attaques par dictionnaire. Ces intrusions permettent l'installation de scanners de ports et de logiciels malveillants variés, dont DDOSbot et CoinMiner.
|
||||
## Une menace persistante contre les serveurs Linux exposés
|
||||
|
||||
Après installation, ces programmes malveillants scrutent le réseau à la recherche de nouveaux serveurs à compromettre, amplifiant ainsi la portée de l'attaque. Parallèlement, les informations d'accès obtenues (IP et identifiants) sont souvent vendues sur le dark web, augmentant le risque de violations futures.
|
||||
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.
|
||||
|
||||
L'ASEC souligne que l'outil d'attaque semble provenir d'un collectif nommé PRG old Team, bien que modifié pour ces opérations spécifiques. Ces attaques ciblent principalement des systèmes exposant le port 22, le port par défaut pour les connexions SSH, exploitant ainsi les faiblesses des politiques de mots de passe et de sécurité.
|
||||
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.
|
||||
|
||||
En réponse, il est vivement recommandé aux administrateurs et utilisateurs de renforcer les mots de passe, d'assurer une mise à jour constante des systèmes, et si possible, de déplacer le service SSH vers un port moins conventionnel que le port 22. Ces mesures préventives sont d'autant plus cruciales à la suite des récentes attaques de Terrapin (CVE-2023-48795), visant spécifiquement le protocole SSH à travers une technique de troncature de préfixe.
|
||||
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.
|
||||
|
||||
Face à la menace persistante des attaques de Terrapin, une mobilisation des chercheurs a mené à contacter près de 30 fournisseurs de services SSH. Ils signalent que le processus de mise à jour et de correction des vulnérabilités peut être long, mettant en lumière la nécessité d'une vigilance et d'une adaptation continues face aux évolutions des menaces cybernétiques.
|
||||
## Une menace distincte : la vulnérabilité Terrapin
|
||||
|
||||
*Source : https:*www.linux-magazine.com/Online/News/Linux-Machines-with-Poorly-Secured-SSH-Servers-are-Under-Attack //
|
||||
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.
|
||||
|
||||
# Configurer une alerte par mail
|
||||
Pour configurer un serveur afin qu'il envoie un email chaque fois qu'une connexion SSH se produit sur un compte particulier, vous pouvez utiliser les scripts de shell et la fonctionnalité de notification par e-mail du système. Voici une méthode générale que vous pourriez suivre, en supposant que vous avez déjà une configuration de serveur de messagerie ou un service SMTP que vous pouvez utiliser pour envoyer des e-mails:
|
||||
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.
|
||||
|
||||
1. **Configurer le Serveur de Messagerie**:
|
||||
## Sécuriser SSH : les mesures qui comptent vraiment
|
||||
|
||||
Assurez-vous que votre système est capable d'envoyer des emails. Cela peut être fait via `sendmail`, `postfix`, ou un client SMTP comme `ssmtp` ou `msmtp` relié à un service à un fournisseur SMTP.
|
||||
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.
|
||||
|
||||
2. **Créer un Script de Notification**:
|
||||
### 1. Désactiver l'authentification par mot de passe
|
||||
|
||||
Créez un script shell (`notify.sh` par exemple) qui envoie un email lorsque quelqu'un se connecte via SSH. Voici un exemple de ce à quoi le script pourrait ressembler:
|
||||
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` :
|
||||
|
||||
```BASH
|
||||
```
|
||||
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
|
||||
|
||||
# Mettez l'adresse e-mail du destinataire ici
|
||||
RECIPIENT="your-email@example.com"
|
||||
# Ne notifier que les ouvertures de session, pas les fermetures ni les autres événements PAM
|
||||
[ "$PAM_TYPE" = "open_session" ] || exit 0
|
||||
|
||||
# Message de notification
|
||||
SUBJECT="Alerte de Connexion SSH"
|
||||
MESSAGE="Une connexion SSH a été établie sur $(hostname) par $(whoami) à $(date)."
|
||||
RECIPIENT="votre-adresse@example.com"
|
||||
SUBJECT="[SSH] Connexion sur $(hostname) — utilisateur $PAM_USER"
|
||||
|
||||
# Commande pour envoyer l'email
|
||||
echo "$MESSAGE" | mail -s "$SUBJECT" $RECIPIENT
|
||||
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
|
||||
```
|
||||
|
||||
3. **Modifier le Fichier de Configuration SSH**:
|
||||
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.
|
||||
|
||||
Éditez le fichier de configuration SSH `sshd_config` situé normalement dans `/etc/ssh/sshd_config`.
|
||||
Rendez le script exécutable et restreignez ses permissions :
|
||||
|
||||
Ajoutez ou modifiez la ligne `ForceCommand` pour l'utilisateur spécifique ou globalement pour exécuter le script à chaque connexion. Par exemple:
|
||||
|
||||
```
|
||||
Match User nomutilisateur
|
||||
ForceCommand /chemin/vers/notify.sh
|
||||
```bash
|
||||
sudo chmod 700 /usr/local/bin/ssh-notify.sh
|
||||
sudo chown root:root /usr/local/bin/ssh-notify.sh
|
||||
```
|
||||
|
||||
4. **Rendre le Script Exécutable et Redémarrer le SSHD**:
|
||||
### Activer le script via PAM
|
||||
|
||||
Assurez-vous que le script est exécutable : `chmod +x /chemin/vers/notify.sh`.
|
||||
Éditez `/etc/pam.d/sshd` et ajoutez à la fin du fichier :
|
||||
|
||||
Redémarrez le service SSH pour appliquer les modifications : `sudo systemctl restart sshd` ou `sudo service sshd restart` selon votre système.
|
||||
```
|
||||
session optional pam_exec.so seteuid /usr/local/bin/ssh-notify.sh
|
||||
```
|
||||
|
||||
5. **Testez la Configuration**:
|
||||
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.
|
||||
|
||||
Testez en vous connectant via SSH pour voir si vous recevez un email.
|
||||
### Tester sans se verrouiller dehors
|
||||
|
||||
## Notes importantes
|
||||
- Assurez-vous que le script et la configuration ne nuisent pas à la capacité de se connecter en SSH. Testez cela soigneusement.
|
||||
- Soyez conscient de la sécurité et des implications de la confidentialité de l'envoi d'informations par e-mail.
|
||||
- Cette méthode envoie une notification pour chaque connexion SSH, pas seulement pour les connexions réussies. Vous pouvez affiner le script pour répondre à des besoins plus spécifiques.
|
||||
**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.
|
||||
|
||||
C'est une approche de base.
|
||||
### 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)*
|
||||
@@ -1,13 +1,21 @@
|
||||
{
|
||||
"uuid": "055737c8-5d2f-4cac-b8cd-13bfc0a2b193",
|
||||
"slug": "20231229-ssh-brutforce",
|
||||
"title": "Attaques Cryptographiques Sur Les Serveurs Linux : Mineurs Malveillants et Vulnérabilités SSH",
|
||||
"slug": "serveurs-linux-sous-attaque-comprendre-la-menace-ssh-et-s-en-proteger-efficacement",
|
||||
"title": "Serveurs Linux sous attaque : comprendre la menace SSH et s'en protéger efficacement",
|
||||
"author": "cedric@abonnel.fr",
|
||||
"published": true,
|
||||
"published_at": "2023-12-29 18:58:21",
|
||||
"featured": false,
|
||||
"published_at": "2023-12-29 18:58",
|
||||
"created_at": "2023-12-29 18:58:21",
|
||||
"updated_at": "2023-12-29 18:58:21",
|
||||
"revisions": [],
|
||||
"updated_at": "2026-05-15 15:02:05",
|
||||
"revisions": [
|
||||
{
|
||||
"n": 1,
|
||||
"date": "2026-05-15 15:02:05",
|
||||
"comment": "Titre modifié, catégorie modifiée, tags modifiés, contenu modifié",
|
||||
"title": "Attaques Cryptographiques Sur Les Serveurs Linux : Mineurs Malveillants et Vulnérabilités SSH"
|
||||
}
|
||||
],
|
||||
"cover": "",
|
||||
"files_meta": [],
|
||||
"external_links": [
|
||||
@@ -30,5 +38,13 @@
|
||||
"seo_title": "",
|
||||
"seo_description": "",
|
||||
"og_image": "",
|
||||
"category": "Journal geek"
|
||||
"category": "informatique",
|
||||
"tags": {
|
||||
"tags": [
|
||||
"OpenSSH",
|
||||
"SSH",
|
||||
"PAM",
|
||||
"Serveurs Linux"
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
@@ -0,0 +1,66 @@
|
||||
# Attaques Cryptographiques Sur Les Serveurs Linux : Mineurs Malveillants et Vulnérabilités SSH
|
||||
|
||||
Une vague de cyberattaques cible spécifiquement les serveurs Linux en les intégrant de force dans des réseaux de minage de cryptomonnaies et en propageant simultanément des attaques par déni de service distribué. Selon le rapport récent du AhnLab Security Emergency Response Center (ASEC), des cybercriminels exploitent des failles de sécurité en devinant les identifiants SSH à travers des attaques par force brute, communément appelées attaques par dictionnaire. Ces intrusions permettent l'installation de scanners de ports et de logiciels malveillants variés, dont DDOSbot et CoinMiner.
|
||||
|
||||
Après installation, ces programmes malveillants scrutent le réseau à la recherche de nouveaux serveurs à compromettre, amplifiant ainsi la portée de l'attaque. Parallèlement, les informations d'accès obtenues (IP et identifiants) sont souvent vendues sur le dark web, augmentant le risque de violations futures.
|
||||
|
||||
L'ASEC souligne que l'outil d'attaque semble provenir d'un collectif nommé PRG old Team, bien que modifié pour ces opérations spécifiques. Ces attaques ciblent principalement des systèmes exposant le port 22, le port par défaut pour les connexions SSH, exploitant ainsi les faiblesses des politiques de mots de passe et de sécurité.
|
||||
|
||||
En réponse, il est vivement recommandé aux administrateurs et utilisateurs de renforcer les mots de passe, d'assurer une mise à jour constante des systèmes, et si possible, de déplacer le service SSH vers un port moins conventionnel que le port 22. Ces mesures préventives sont d'autant plus cruciales à la suite des récentes attaques de Terrapin (CVE-2023-48795), visant spécifiquement le protocole SSH à travers une technique de troncature de préfixe.
|
||||
|
||||
Face à la menace persistante des attaques de Terrapin, une mobilisation des chercheurs a mené à contacter près de 30 fournisseurs de services SSH. Ils signalent que le processus de mise à jour et de correction des vulnérabilités peut être long, mettant en lumière la nécessité d'une vigilance et d'une adaptation continues face aux évolutions des menaces cybernétiques.
|
||||
|
||||
*Source : https:*www.linux-magazine.com/Online/News/Linux-Machines-with-Poorly-Secured-SSH-Servers-are-Under-Attack //
|
||||
|
||||
# Configurer une alerte par mail
|
||||
Pour configurer un serveur afin qu'il envoie un email chaque fois qu'une connexion SSH se produit sur un compte particulier, vous pouvez utiliser les scripts de shell et la fonctionnalité de notification par e-mail du système. Voici une méthode générale que vous pourriez suivre, en supposant que vous avez déjà une configuration de serveur de messagerie ou un service SMTP que vous pouvez utiliser pour envoyer des e-mails:
|
||||
|
||||
1. **Configurer le Serveur de Messagerie**:
|
||||
|
||||
Assurez-vous que votre système est capable d'envoyer des emails. Cela peut être fait via `sendmail`, `postfix`, ou un client SMTP comme `ssmtp` ou `msmtp` relié à un service à un fournisseur SMTP.
|
||||
|
||||
2. **Créer un Script de Notification**:
|
||||
|
||||
Créez un script shell (`notify.sh` par exemple) qui envoie un email lorsque quelqu'un se connecte via SSH. Voici un exemple de ce à quoi le script pourrait ressembler:
|
||||
|
||||
```BASH
|
||||
#!/bin/bash
|
||||
|
||||
# Mettez l'adresse e-mail du destinataire ici
|
||||
RECIPIENT="your-email@example.com"
|
||||
|
||||
# Message de notification
|
||||
SUBJECT="Alerte de Connexion SSH"
|
||||
MESSAGE="Une connexion SSH a été établie sur $(hostname) par $(whoami) à $(date)."
|
||||
|
||||
# Commande pour envoyer l'email
|
||||
echo "$MESSAGE" | mail -s "$SUBJECT" $RECIPIENT
|
||||
```
|
||||
|
||||
3. **Modifier le Fichier de Configuration SSH**:
|
||||
|
||||
Éditez le fichier de configuration SSH `sshd_config` situé normalement dans `/etc/ssh/sshd_config`.
|
||||
|
||||
Ajoutez ou modifiez la ligne `ForceCommand` pour l'utilisateur spécifique ou globalement pour exécuter le script à chaque connexion. Par exemple:
|
||||
|
||||
```
|
||||
Match User nomutilisateur
|
||||
ForceCommand /chemin/vers/notify.sh
|
||||
```
|
||||
|
||||
4. **Rendre le Script Exécutable et Redémarrer le SSHD**:
|
||||
|
||||
Assurez-vous que le script est exécutable : `chmod +x /chemin/vers/notify.sh`.
|
||||
|
||||
Redémarrez le service SSH pour appliquer les modifications : `sudo systemctl restart sshd` ou `sudo service sshd restart` selon votre système.
|
||||
|
||||
5. **Testez la Configuration**:
|
||||
|
||||
Testez en vous connectant via SSH pour voir si vous recevez un email.
|
||||
|
||||
## Notes importantes
|
||||
- Assurez-vous que le script et la configuration ne nuisent pas à la capacité de se connecter en SSH. Testez cela soigneusement.
|
||||
- Soyez conscient de la sécurité et des implications de la confidentialité de l'envoi d'informations par e-mail.
|
||||
- Cette méthode envoie une notification pour chaque connexion SSH, pas seulement pour les connexions réussies. Vous pouvez affiner le script pour répondre à des besoins plus spécifiques.
|
||||
|
||||
C'est une approche de base.
|
||||
Reference in New Issue
Block a user