Au cours de cet article, nous allons réaliser une analyse de logs SSH issue de la mise en place d’un service en écoute, publiquement exposé sur Internet durant un mois.

Par publiquement exposé, nous entendons également sans dispositifs de sécurité supplémentaires (authentification par clé, restriction des accès, double authentification, etc.), soit dans sa configuration par défaut.

Enfin, aucun patch n’a été mis à en place afin de réaliser une analyse des mots de passe.

Qu’est-ce que le SSH ?

SSH (Secure Shell) est à la fois un programme informatique et un protocole de communication sécurisée imposant l’échange de clés de chiffrement en début de connexion.

Cet échange empêche quiconque d’intercepter et de déchiffrer le trafic entre le client et le serveur. Il devient donc impossible de sniffer les connexions de l’utilisateur marquant la différence avec d’autres protocoles tels que Telnet.

Analyse des logs

Afin de réaliser cette analyse, nous allons traiter l’ensemble des logs (accessibles sur Debian au sein des fichiers /var/log/auth.log*) grâce à de simples commandes bash. Le retour de ces commandes va permettre de faire ressortir plusieurs informations intéressantes telles que les noms d’utilisateurs communément utilisés, le nombre de tentatives de connexion par adresse IP ainsi qu’une analyse de la provenance des attaques par pays.

Avant d’entamer l’analyse, il convient de revenir sur la structure des logs SSH. Les lignes intéressantes pour notre étude se présentent de la forme suivante :

Il est bon de noter que les logs SSH diffèrent légèrement en fonction de l’existence ou non de l’utilisateur.

1. Analyse des noms d’utilisateur

Tout d’abord, nous avons analysé l’existence des noms d’utilisateurs utilisés lors des tentatives de connexion afin de déterminer s’il s’agissait de simples attaques de type bruteforce avec des listes d’utilisateurs accessibles sur Internet ou des attaques un peu plus avancées avec une réelle phase de récolte d’informations.

• Tentatives avec des comptes inexistants sur le système : 30 754 obtenus via la commande :
  grep « Failed password for invalid user » auth.log | wc -l

• Tentatives avec des comptes existant sur le système : 330 713 obtenus via la commande :
  grep « Failed password for » auth.log | grep -v « invalid user » | wc -l

À première vue, il semblerait que les attaquants aient fait un excellent travail de récolte d’information. Néanmoins, les dictionnaires intègrent des noms d’utilisateurs standards tels que www-data, mysql, nobody, man, etc. faussant ainsi les résultats.

L’utilisateur root, quant à lui est un exemple à part entière. En effet, celui-ci est un compte standard. Néanmoins, la configuration par défaut permet de s’y connecter et les attaquants le savent bien.

La suppression du compte root de notre analyse change ainsi considérablement l’analyse. En effet, nous obtenons seulement 694 entrées au lieu des 330 713 précédemment obtenues :
grep « Failed password for » auth.log | grep -v « invalid user » | grep –v ‘root’ | wc -l

NOTE : Mathématiciens dans l’âme, nous nous rendons ainsi compte qu’un simple site institutionnel reçoit environ 330 000 tentatives de connexions avec l’utilisateur root sur une période d’un mois (11 000 tentatives par jour = 458 par heure, 8 par minute, etc.).

Voici les noms d’utilisateurs (n’existant pas sur le système) les plus communément utilisés :

Au sein de l’analyse, aucun des comptes (autres que ceux par défaut) n’a été découvert.

De plus, il est possible de s’assurer que les connexions réussies proviennent bien de nos adresses IP grâce à la commande suivante :
grep « Accepted password for » auth.log | grep -v « IP_DE_BSSI » | cut -d »  » -f11 | sort

2. Analyse de la provenance des connexions

Maintenant que l’on sait qui se connecte, il serait bon de savoir d’où proviennent ces connexions. Ainsi, de la même manière que précédemment, nous allons exporter les adresses IP au lieu des noms d’utilisateurs invalides, de la manière suivante : grep -i « Failed password for invalid » auth.log | cut -d  »  » -f 13 | sort | uniq -c | sort -n –r

Il est ainsi possible de constater que certaines adresses reviennent plus que d’autres dans ces tentatives de connexion.

Le top 5 des pays tentant de se connecter est donc : États-Unis, Ukraine, France, République tchèque ainsi que Brésil.

Paradoxalement, si on analyse les tentatives de connexion par adresse IP pour les utilisateurs valide, les résultats changent : grep -i « Failed password » auth.log | grep -v « invalid » | cut -d  »  » -f 11 | sort | uniq -c | sort -n -r

Dans ce nouveau cas de figure, le top 15 des tentatives essaye de se connecter avec le compte root. L’ensemble de ces connexions (soit approximativement 210 000 tentatives) est en provenance de la Chine (géolocalisation des données a été effectuée grâce à AbuseIPDB https://www.abuseipdb.com)

Les contre-mesures

Nous l’avons compris, disposer d’une interface d’administration présente un risque, mais n’est pas pour autant une fatalité. Nous vous présentons ici certaines contre-mesures permettant d’endiguer bon nombre de ces tentatives d’intrusion :

• La première chose à faire est de désactiver la possibilité du compte root de se connecter. Comme vu précédemment, ce compte d’une importance capitale, est LE compte que les attaquants essayent de compromettre.
• Les 458 tentatives par heure ne laissent aucun doute sur l’utilisation de scripts automatisés. Ces derniers prennent en paramètre une adresse IP, une liste d’identifiants et une liste de mot de passe avant de se connecter sur le port SSH par défaut (22/TCP). Ainsi, le changement de port d’écoute permettrait de s’affranchir de bon nombre de scripts automatisés.
• L’authentification par clés permettra de ne pas accepter les traditionnels mots de passe et les faiblesses qu’ils comportent.
• La mise en place d’une authentification à double facteur permettra également d’endiguer la découverte d’un couple identifiant/mot de passe valide.
• Enfin, que cela soit pour les interfaces d’administration ou les mots de passe de la vie de tous les jours, ces derniers doivent être solides et respecter les meilleures pratiques telles que précisées par l’ANSSI : https://www.ssi.gouv.fr/guide/mot-de-passe/

Conclusion

L’exposition sur Internet d’une interface d’administration expose inexorablement votre système à des attaques. Ces dernières, souvent l’œuvre de scripts peuvent facilement être endiguées grâce à de simples techniques.

Nous ne le répéterons jamais assez, mais les interfaces d’administration sont à usage des administrateurs ! Vivons heureux, vivons cachés comme le dit le vieil adage.

De plus, au vu des attaques en constante évolution, cela ne fera pas de mal d’avoir un sujet en moins en tête.

Article originellement publié sur blog.bssi.fr