Analyse de logs d’un honeypot SSH – Homputer Security

[Ldfa]

Dans un article récent, je vous introduisais à Cowrie, le honeypot ssh.
Pour rappel, un honeypot est un serveur vulnérable intentionnellement conçu pour attirer et identifier de potentiels adversaires. L’objectif derrière cette manoeuvre est d’apprendre sur ses adversaires, afin de mieux sécuriser ses connexions à distance.
En réalité, aussitôt que vous rendez disponible n’importe quel type d’appareil sur la Toile (serveur ssh, serveur http, objet IoT, etc.), des centaines de bots (parfois des scripts kiddies) tenteront de s’y introduire grâce à des attaques par force brute.

Pour démontrer cette assertion, j’ai réalisé une expérience avec Cowrie durant la période du 3 Novembre au 10 Novembre 2017.

Dans ce billet, nous analyserons les logs générés par le honeypot durant cette période, puis nous verrons quelles solutions appliquer pour être à l’abri de toutes les menaces de la Toile.

Pour l’analyse de ces fichiers, j’ai eu recours aux outils de manipulation de texte du langage de script Bash, c’est à dire grep, cut, sort, uniq, cat et head.
Les logs du Honeypot sont tous stockés dans le dossier cowrie/log.

Image 1. Logs générés par cowrie

En tout nous avons eu 141 317 tentatives erronées soit 736 tentatives toutes les heures.

Image 2. Nombre total de tentatives erronées

Les logs comprennent en tout 1 011 367 lignes.

Image 3. Nombre total des lignes comprennant l’ensemble des logs

Voici les 40 adresses qui ont le plus tenté à se connecter au pot de miel:
NB: Les chiffres sur la gauche des adresses IP désignent les tentatives de connexion.

Image 4. Top 40 des adresses intrusives

Ci-dessous le top 40 des comptes d’utilisateurs qui ont été le plus utilisé durant ces tentatives d’intrusion.

Image 5. Top 40 des comptes d’utilisateurs utilisés

Enfin, le top 40 des mots de passe utilisés par les bots.

Image 6. Top 40 des mots de passe utilisés

L’utilisation de Fail2ban

Outre la complexité des mots de passe, vous pourrez également utiliser un système de détection d’intrusion comme Fail2ban pour la protection de votre serveur.
En effet, cette solution réduit considérablement les chances de succès des attaques par force brute. Ci dessous le log ssh d’une machine sur laquelle Fail2ban a été configuré pour blacklister toute adresse qui échouerait au moins à deux tentatives de connexion.

Image 7. Log d’un serveur ssh configuré avec Fail2ban

Désactiver les accès root

Comme l’image 5 l’indique, l’utilisateur root est le premier ciblé par les attaques car il dispose de tout les droits d’administration. Une bonne manoeuvre serait alors de désactiver les accès au compte root. L’accès à ce compte restera toutefois disponible via les commandes su et sudo pour tout autre utilisateur appartenant au groupe sudo.

L’authentification par clé publique

Cette méthode consiste en une authentification via une cryptographie assymétrique. Le client va devoir générer une paire de clés, une publique et une privée. Il conservera sa clé privée, puis et enverra sa clé publique au serveur SSH. Cette clé publique permettra au serveur de reconnaître le client.

L’authentification à deux facteurs

Le module PAM Google Authenticator vous permet de protéger votre serveur avec une authentification à deux facteurs.
Ci-dessous deux tutoriels sur l’intégration de ce module à OpenSSH:

J’espère que vous avez apprécié cette mini-série d’articles sur Cowrie. 🙂

mdestroy

Share this:

Afficher l’article complet