Votre serveur SSH est très probablement attaqué des centaines de fois par jour. Dire que c'est très probable ne suffit pas. Je suis convaincu que votre serveur subit pratiquement des centaines d'attaques chaque jour. Cependant, un nombre surprenant de développeurs n'ouvrent presque jamais le dossier /var/log. Essayez simplement d'exécuter journalctl -f |grep ssh dans votre terminal maintenant.

En regardant simplement les journaux :

  • Qui

  • Quand

  • D'où

  • Comment
    ils ont essayé de se connecter au serveur est clairement visible.

Dans cet article, je vais aborder comment interpréter les journaux de serveur SSH et les méthodes d'analyse pratique pour détecter les signes de piratage du point de vue des développeurs.

1. Où se trouvent les journaux SSH ?

Commandbox 광고

Les emplacements des journaux SSH varient légèrement selon les distributions Linux.

En général :

  • Ubuntu / Debian

    • /var/log/auth.log

  • CentOS / RHEL

    • /var/log/secure

  • Commandes communes basées sur systemd

    • journalctl -u ssh.service ou journalctl -u sshd

Vous pouvez utiliser tail, mais personnellement, je préfère de loin utiliser journald. Cela vous permet de voir les journaux de tous les services à un seul endroit.

# Exemple pour Ubuntu
sudo tail -f /var/log/auth.log

# Exemple pour CentOS/RHEL
sudo tail -f /var/log/secure

# Voir en temps réel les journaux de service systemd
sudo journalctl -u ssh.service -f

Conseil : Même sur un serveur de développement, il est bon de prendre l'habitude de "surveiller les journaux" avec tail -f au moins de temps en temps.

Cliquez "ici" pour en savoir plus sur l'utilisation de journald !

2. Analyse d'une ligne de journal SSH

Examinons une ligne typique de journal SSH pour comprendre sa structure. (Exemple pour Ubuntu)

2.1 connexion par clé publique réussie

Jan 10 12:34:56 myserver sshd[12345]: Accepted publickey for deploy from 203.0.113.10 port 50312 ssh2: ED25519 SHA256:xxxx

Signification de chaque partie :

  • Jan 10 12:34:56 : date, heure

  • myserver : nom de l'hôte

  • sshd[12345] : nom du processus (démon SSH) et PID

  • Accepted publickey : authentification réussie, méthode utilisée est la clé publique

  • for deploy : nom du compte de connexion

  • from 203.0.113.10 : IP d'origine

  • port 50312 : port côté client

  • ssh2: ED25519 ... : informations sur le protocole/type de clé

En comprenant cela, vous pouvez rapidement déterminer “qui s'est connecté d'où avec quelle clé”.

2.2 échec de connexion avec mot de passe

Jan 10 12:35:01 myserver sshd[12346]: Failed password for root from 198.51.100.23 port 50320 ssh2

  • Failed password : échec de l'authentification par mot de passe

  • for root : tentative avec le compte root

  • from 198.51.100.23 : IP distante

Si ce type de journal apparaît des dizaines à des centaines de fois par seconde, il est presque certain que vous subissez une attaque par force brute.

2.3 tentative de connexion avec un utilisateur inexistant

Jan 10 12:35:05 myserver sshd[12347]: Invalid user admin from 198.51.100.23 port 50325
  • Invalid user admin : tentative de connexion avec un compte admin inexistant sur le serveur

Ceci est également un modèle couramment utilisé par les bots automatisés.

3. Modèles d'attaque typiques dans les journaux

Commandbox 광고

3.1 attaque par force brute

Caractéristiques :

  • les journaux Failed password se produisent en grande quantité en très peu de temps

  • tentatives répétées depuis la même IP des dizaines à des centaines de fois

  • utilisation de noms de comptes tels que root, admin, test, oracle

Vérification rapide :

# Nombre total d'échecs de mot de passe
sudo grep "Failed password" /var/log/auth.log | wc -l

# Quel compte est le plus souvent ciblé
sudo grep "Failed password" /var/log/auth.log \
  | awk '{for (i=1;i<=NF;i++) if ($i=="for") print $(i+1)}' \
  | sort | uniq -c | sort -nr | head

3.2 scan d'utilisateurs inexistants

sudo grep "Invalid user" /var/log/auth.log | head

Une grande quantité de ces journaux indique que des tentatives aléatoires de connexion sont effectuées pour voir quels comptes pourraient exister sur ce serveur.

3.3 tentatives excessives depuis une IP spécifique

Pour identifier quelle IP échoue le plus souvent :

sudo grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | sort -nr | head

Le code $(NF-3) fait généralement référence à l'IP dans la partie from <IP>, mais peut varier légèrement selon l'environnement, donc vous devrez peut-être l'adapter au format de vos journaux.

4. Identifier les signes inquiétants parmi les connexions “réussies”

Les attaques aboutissent généralement à des échecs, mais ce qui est vraiment effrayant ce sont les connexions réussies.

4.1 Collecte des journaux acceptés

sudo grep "Accepted" /var/log/auth.log

Voici ce qu'il faut surveiller particulièrement :

  • connexions avec des comptes que vous n'utilisez pas habituellement

  • connexions à des heures inhabituelles (par exemple : 3 heures du matin)

  • IP d'un pays ou d'un bloc que vous ne reconnaissez pas (autre que votre entreprise/maison/VPN)

4.2 Voir les historiques de connexions récentes

La commande last affiche l'historique des connexions récentes.

# Historique récent des connexions SSH
last -i | head

# connexions échouées (si l'environnement le supporte)
lastb | head

En vérifiant cela régulièrement, vous pouvez facilement découvrir les
“enregistrements de connexion à des moments où je n'étais pas connecté”.

5. Analyse pratique des journaux : exemple de routine de vérification rapide

Partons du principe que vous avez un serveur SSH,
et créons une routine de vérification que vous pouvez effectuer en 5 minutes.

5.1 Étape 1 : vérifier le total des échecs de connexion

sudo grep "Failed password" /var/log/auth.log | wc -l
sudo grep "Invalid user" /var/log/auth.log | wc -l
  • Si le nombre augmente soudainement, cela peut indiquer une "augmentation de l'intensité de l'attaque".

5.2 Étape 2 : TOP 10 des IP les plus attaquées

sudo grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | sort -nr | head
  • Les IP les plus haut placées peuvent être ajoutées aux règles de pare-feu/fail2ban.

5.3 Étape 3 : Connexion tentée en tant que root

sudo grep "Failed password for root" /var/log/auth.log | tail
sudo grep "Accepted.*root" /var/log/auth.log
  • Accepted indique qu'une connexion a déjà été réussie avec le compte root, ce qui est très dangereux.

5.4 Étape 4 : Vérification des connexions réussies récentes

sudo grep "Accepted" /var/log/auth.log | tail -n 50

Voici les points à vérifier :

  • Est-ce une IP que je ne connais pas ?

  • Est-ce pendant les heures de travail normales ?

  • Y a-t-il un compte qui est soudainement apparu ?

6. Que vaut la consultation des journaux ? Configuration défensive immédiate

Si vous sentez une odeur d'attaque dans les journaux,
il est temps de passer à la configuration de défense.

6.1 Désactiver la connexion par mot de passe (autoriser uniquement les clés publiques)

Dans /etc/ssh/sshd_config :

PasswordAuthentication no
PubkeyAuthentication yes

Après modification :

sudo systemctl reload sshd
# ou
sudo service ssh restart

Assurez-vous d'avoir réussi à vous connecter avec une clé publique avant de désactiver les mots de passe.
Sinon, vous pourriez vous bloquer vous-même.

6.2 Interdire les connexions directes en tant que root

PermitRootLogin no

Empêcher la connexion directe en tant que root,
il est préférable de se connecter d'abord avec un compte normal et d'utiliser sudo.

6.3 Changer le port (pour réduire le bruit)

Port 22    # -> changer par exemple en 2222

  • Changer le port ne renforce pas nécessairement la sécurité, mais

  • cela réduit considérablement les journaux d'attaques/scans non sollicités
    permettant de mieux déceler les “vraies anomalies”.

6.4 Utiliser des outils comme fail2ban

fail2ban surveille les journaux et

  • lorsque plusieurs échecs de connexion se produisent

  • depuis la même IP

  • dans un court laps de temps

ajoute automatiquement des règles de pare-feu pour bloquer l'IP.

Le concept est simple :

  1. surveiller le motif Failed password dans auth.log

  2. bloquer l'IP à l'aide de iptables/ufw si le seuil est dépassé

Il s'agit d'automatiser l'analyse des journaux pour bloquer automatiquement les attaques par force brute.

6.5 Restreindre l'accès SSH via le pare-feu

Si possible :

  • autoriser l'accès à 22/tcp (ou port modifié) uniquement depuis le VPN de l'entreprise ou une IP fixe spécifique

  • bloquer tout le reste

Exemple simple avec ufw

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

7. Routine minimale de vérification des journaux pour les développeurs

Pour un développeur, pour un niveau de vérification réaliste durant le travail,
vous pouvez faire ce qui suit et la sensibilité à la sécurité changera complètement.

Une fois par semaine :

  1. Vérifiez le nombre de Failed password et d'Invalid user durant la dernière semaine

  2. Vérifiez les 10 IP avec le plus d'échecs

  3. Dans le journal Accepted, vérifiez:

    • de nouvelles IP,

    • des heures inhabituelles,

    • des comptes inconnus

  4. Bloquez les IP suspectes à l'aide du pare-feu/fail2ban.

Rien qu'en regardant une fois,
vous vous rendrez compte que “ah, ce serveur est vraiment attaqué tous les jours” et
vous aurez la motivation pour investir du temps dans les réglages de sécurité.

Un hacker attaquant un serveur ssh

Conclusion : ouvrez les journaux dès maintenant

La sécurité SSH commence par voir ce qui se passe réellement sur votre serveur, avant de penser à de grandes solutions.

  1. Ouvrez /var/log/auth.log ou /var/log/secure

  2. Examinez les logs en fonction des Failed password, Invalid user, Accepted

  3. Si quelque chose vous semble étrange, envisagez immédiatement de modifier les paramètres et d'introduire un pare-feu, fail2ban.

Maintenant que vous avez tout lu, vous êtes prêt à éviter d'être victime de hacking dû à l'ignorance des journaux.
Ouvrez le terminal et consultez les journaux de votre serveur.

Pour un développeur, la sécurité ne devrait pas être une option, mais une nécessité et une routine.

Pour des détails sur l'utilisation de Fail2ban, cliquez "ici".