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.

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

Les logs comprennent en tout 1 011 367 lignes.

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.

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

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

Quelles solutions pour être à l’abri ?

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.

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:

• Authentification à deux facteurs clé publique et code totp
• Authentification à deux facteurs mot de passe et code totp

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

mdestroy