Ajuster le nombre de threads d'Hydra

Introduction

Dans ce laboratoire, nous explorerons l'impact du nombre de threads sur les performances d'Hydra. Le laboratoire commence par la configuration d'un serveur SSH de base sur la machine virtuelle LabEx à l'aide d'OpenSSH, en nous assurant qu'il est en cours d'exécution et accessible.

Ensuite, nous exécuterons Hydra avec le nombre de threads par défaut de 16, puis nous l'augmenterons à 32 et le réduirons ensuite à 4, en comparant la vitesse et en observant les effets de différents nombres de threads sur les performances globales de l'attaque Hydra. Enfin, nous analyserons l'impact du nombre de threads sur les performances d'Hydra.

Skills Graph

Configuration du serveur SSH

Dans cette étape, nous allons configurer un serveur SSH de base sur la machine virtuelle LabEx. SSH (Secure Shell) est un protocole réseau cryptographique permettant d'exécuter des services réseau de manière sécurisée sur un réseau non sécurisé. Il est couramment utilisé pour la connexion à distance en ligne de commande et l'exécution de commandes à distance.

Tout d'abord, nous devons installer le serveur OpenSSH. OpenSSH est une suite d'outils de niveau réseau liés à la sécurité basée sur le protocole Secure Shell. Il fournit un canal sécurisé sur un réseau non sécurisé dans une architecture client/serveur.

Exécutez la commande suivante pour installer le serveur OpenSSH :

sudo apt update
sudo apt install -y openssh-server

Cette commande met d'abord à jour les listes de paquets pour les mises à jour et les nouvelles installations. Ensuite, elle installe le paquet openssh-server. Le drapeau -y répond automatiquement "oui" à toutes les invitations pendant l'installation.

Une fois l'installation terminée, le serveur SSH devrait démarrer automatiquement. Vous pouvez vérifier son statut en utilisant la commande suivante :

sudo systemctl status ssh

Vous devriez voir une sortie similaire à celle-ci :

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2023-10-24 10:00:00 UTC; 10s ago
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 1234 (sshd)
      Tasks: 1 (limit: 4621)
     Memory: 1.2M
        CPU: 10ms
     CGroup: /system.slice/ssh.service
             └─1234 sshd: /usr/sbin/sshd -D

Oct 24 10:00:00 labex systemd[1]: Started OpenBSD Secure Shell server.

Si le service SSH n'est pas en cours d'exécution, vous pouvez le démarrer avec :

sudo systemctl start ssh

Maintenant que le serveur SSH est en cours d'exécution, vous pouvez vous y connecter depuis une autre machine en utilisant un client SSH. Pour vous connecter, vous aurez besoin de l'adresse IP de la machine virtuelle LabEx. Vous pouvez la trouver en utilisant la commande ifconfig. Cependant, comme ifconfig n'est peut-être pas installé par défaut, une commande plus fiable est ip addr.

ip addr

Recherchez l'adresse inet associée à l'interface réseau (généralement eth0 ou enp0s3). Elle ressemblera à 192.168.1.100.

Par exemple, la sortie pourrait ressembler à ceci :

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever

Dans ce cas, l'adresse IP est 172.17.0.2.

Vous pouvez ensuite utiliser cette adresse IP pour vous connecter au serveur SSH depuis une autre machine en utilisant la commande ssh labex@<IP_ADDRESS>. Vous n'avez pas besoin de le faire maintenant, car nous allons utiliser Hydra sur la même machine.

Enfin, configurons le serveur SSH pour autoriser l'authentification par mot de passe. Par défaut, SSH préfère souvent l'authentification basée sur des clés, qui est plus sécurisée. Cependant, pour ce laboratoire, nous allons activer l'authentification par mot de passe pour plus de simplicité.

Modifiez le fichier de configuration du serveur SSH en utilisant nano :

sudo nano /etc/ssh/sshd_config

Trouvez la ligne #PasswordAuthentication no et supprimez le commentaire (supprimez le #) et changez no en yes :

PasswordAuthentication yes

Enregistrez le fichier en appuyant sur Ctrl+X, puis Y, puis Entrée.

Redémarrez le serveur SSH pour que les modifications prennent effet :

sudo systemctl restart ssh

Maintenant, le serveur SSH est configuré et prêt à autoriser l'authentification par mot de passe.

Exécution avec le nombre de threads par défaut (-t 16)

Dans cette étape, nous allons exécuter Hydra avec ses paramètres par défaut, qui incluent l'utilisation de 16 threads. Hydra est un outil de craquage de mots de passe parallélisé qui prend en charge de nombreux protocoles pour effectuer des attaques. Nous l'utiliserons pour tenter de craquer le mot de passe de l'utilisateur labex sur le serveur SSH que nous avons configuré à l'étape précédente.

Tout d'abord, créons une simple liste de mots de passe. Il s'agira d'un fichier texte contenant une liste de mots de passe potentiels que Hydra va tester.

Utilisez nano pour créer un fichier nommé password.txt dans votre répertoire ~/project :

nano ~/project/password.txt

Ajoutez les mots de passe suivants au fichier, un mot de passe par ligne :

password
123456
qwerty
labex
test

Enregistrez le fichier en appuyant sur Ctrl+X, puis Y, puis Entrée.

Maintenant, nous allons exécuter Hydra avec le nombre de threads par défaut (-t 16). L'option -l spécifie le nom d'utilisateur à attaquer, -P spécifie la liste de mots de passe, et ssh://localhost spécifie le serveur SSH cible. Étant donné que nous exécutons Hydra sur la même machine que le serveur SSH, nous utilisons localhost.

Exécutez la commande suivante :

hydra -l labex -P ~/project/password.txt ssh://localhost

Hydra va maintenant commencer à tenter de se connecter au serveur SSH en utilisant les mots de passe de password.txt. La sortie affichera la progression de l'attaque.

Vous devriez voir une sortie similaire à celle-ci (la sortie exacte peut varier) :

Hydra v9.1 (c) 2020 by van Hauser/THC - Use freely but only for legal purposes.

Hydra starting at 2023-10-27 10:00:00
[DATA] 1 task/thread started, 0 tasks total
[DATA] attacking ssh://localhost:22/
[ATTEMPT] target: localhost - login: labex - pass: password
[ATTEMPT] target: localhost - login: labex - pass: 123456
[ATTEMPT] target: localhost - login: labex - pass: qwerty
[ATTEMPT] target: localhost - login: labex - pass: labex
[22][ssh] host: localhost   login: labex   password: labex
[DATA] 1 of 1 target successfully completed, 0 failed
Hydra is finished.

Si le mot de passe "labex" est le mot de passe correct pour l'utilisateur labex, Hydra le trouvera et affichera les identifiants de connexion. Si aucun des mots de passe de la liste n'est correct, Hydra indiquera qu'il n'a pas réussi à craquer le mot de passe.

Dans ce cas, nous supposons que le mot de passe de l'utilisateur labex est labex.

L'option -t contrôle le nombre de threads utilisés par Hydra. Par défaut, si vous ne spécifiez pas l'option -t, Hydra utilise 16 threads. Cela signifie qu'il tentera 16 mots de passe simultanément.

Augmentation du nombre de threads à 32 et comparaison de la vitesse

Dans cette étape, nous allons augmenter le nombre de threads utilisés par Hydra à 32 et comparer la vitesse avec l'exécution précédente utilisant le nombre de threads par défaut (16). Augmenter le nombre de threads peut potentiellement accélérer le processus de craquage, mais cela dépend également des ressources du système et du service cible.

Exécutez la commande suivante pour exécuter Hydra avec 32 threads :

hydra -t 32 -l labex -P ~/project/password.txt ssh://localhost

Cette commande est similaire à la précédente, mais nous avons ajouté l'option -t 32 pour spécifier que Hydra doit utiliser 32 threads.

Observez la sortie. Vous devriez voir que Hydra lance 32 tâches/threads.

Hydra v9.1 (c) 2020 by van Hauser/THC - Use freely but only for legal purposes.

Hydra starting at 2023-10-27 10:05:00
[DATA] 32 tasks/threads started, 0 tasks total
[DATA] attacking ssh://localhost:22/
[ATTEMPT] target: localhost - login: labex - pass: password
[ATTEMPT] target: localhost - login: labex - pass: 123456
[ATTEMPT] target: localhost - login: labex - pass: qwerty
[ATTEMPT] target: localhost - login: labex - pass: labex
[22][ssh] host: localhost   login: labex   password: labex
[DATA] 1 of 1 target successfully completed, 0 failed
Hydra is finished.

Comparaison de la vitesse :

Il est difficile de mesurer précisément la différence de vitesse dans un environnement de laboratoire sans des outils de chronométrage précis. Cependant, vous pouvez observer subjectivement si le processus de craquage semble plus rapide avec 32 threads par rapport à 16 threads. En général, augmenter le nombre de threads devrait améliorer la vitesse, surtout avec une petite liste de mots de passe. Cependant, il y a un point de rendement décroissant, et augmenter trop le nombre de threads peut en fait ralentir le processus en raison de la contention des ressources.

Dans l'étape suivante, nous allons réduire le nombre de threads à 4 et observer l'effet.

Réduction du nombre de threads à 4 et observation

Dans cette étape, nous allons réduire le nombre de threads utilisés par Hydra à 4 et observer l'impact sur les performances. Réduire le nombre de threads peut être utile lorsque le système dispose de ressources limitées ou lorsque le service cible a une limitation de débit (rate limiting).

Exécutez la commande suivante pour exécuter Hydra avec 4 threads :

hydra -t 4 -l labex -P ~/project/password.txt ssh://localhost

Cette commande est similaire aux précédentes, mais nous avons ajouté l'option -t 4 pour spécifier que Hydra doit utiliser 4 threads.

Observez la sortie. Vous devriez voir que Hydra lance 4 tâches/threads.

Hydra v9.1 (c) 2020 by van Hauser/THC - Use freely but only for legal purposes.

Hydra starting at 2023-10-27 10:10:00
[DATA] 4 tasks/threads started, 0 tasks total
[DATA] attacking ssh://localhost:22/
[ATTEMPT] target: localhost - login: labex - pass: password
[ATTEMPT] target: localhost - login: labex - pass: 123456
[ATTEMPT] target: localhost - login: labex - pass: qwerty
[ATTEMPT] target: localhost - login: labex - pass: labex
[22][ssh] host: localhost   login: labex   password: labex
[DATA] 1 of 1 target successfully completed, 0 failed
Hydra is finished.

Observation de l'impact :

Avec seulement 4 threads, vous devriez remarquer que le processus de craquage est probablement plus lent par rapport à l'utilisation de 16 ou 32 threads. Cela est dû au fait que Hydra teste maintenant moins de mots de passe simultanément. Le temps total pour terminer la tâche augmentera.

Dans l'étape suivante, nous allons analyser l'impact du nombre de threads sur les performances.

Analyse de l'impact des threads sur les performances

Dans cette étape, nous allons analyser l'impact du nombre de threads sur les performances d'Hydra. Nous avons expérimenté avec 4, 16 (par défaut) et 32 threads. Maintenant, discutons des principes généraux.

Points clés à considérer :

• Ressources du système : Le nombre de threads que vous pouvez utiliser efficacement dépend des ressources de votre système, y compris les cœurs CPU, la mémoire et la bande passante réseau. Si vous définissez le nombre de threads trop élevé, le système peut être surchargé, entraînant une dégradation des performances.
• Service cible : Le service cible (dans ce cas, SSH) peut avoir une limitation de débit (rate limiting) ou d'autres mesures de sécurité qui peuvent affecter les performances d'Hydra. Si le service limite le nombre de tentatives de connexion par unité de temps, augmenter le nombre de threads au-delà d'un certain point n'améliorera pas les performances et peut même déclencher des mécanismes de sécurité qui bloquent l'attaque.
• Liste de mots de passe : La taille et la complexité de la liste de mots de passe affectent également les performances. Une liste de mots de passe plus grande prendra plus de temps à craquer, indépendamment du nombre de threads.
• Latence réseau : Une latence réseau élevée peut également limiter l'efficacité de l'augmentation du nombre de threads.

Observations et directives générales :

• 4 threads : Avec 4 threads, Hydra a moins de chances de surcharger le système ou de déclencher la limitation de débit sur le service cible. Cependant, le processus de craquage sera plus lent par rapport à l'utilisation de plus de threads. Ce paramètre est adapté aux systèmes à ressources limitées ou lors de l'attaque de services avec une limitation de débit stricte.
• 16 threads (par défaut) : Le paramètre par défaut de 16 threads est un bon compromis entre les performances et l'utilisation des ressources pour de nombreux systèmes et services cibles. Il permet à Hydra d'essayer un nombre raisonnable de mots de passe simultanément sans surcharger le système.
• 32 threads : Augmenter le nombre de threads à 32 peut potentiellement améliorer les performances, surtout si le système dispose de ressources suffisantes et que le service cible n'a pas de limitation de débit stricte. Cependant, il est important de surveiller l'utilisation des ressources du système pour s'assurer qu'il n'est pas surchargé.

Conclusion :

Le nombre optimal de threads pour Hydra dépend de divers facteurs. Il est important d'expérimenter avec différents paramètres et de surveiller les performances du système pour trouver le meilleur compromis entre la vitesse et l'utilisation des ressources. Dans un scénario réel, vous devrez également prendre en compte les implications légales et éthiques de l'utilisation d'Hydra pour tenter de craquer des mots de passe.

Ce laboratoire a démontré comment l'option -t affecte les performances d'Hydra. En ajustant le nombre de threads, vous pouvez optimiser Hydra pour différents environnements et services cibles.

Résumé

Dans ce laboratoire, nous avons commencé par configurer un serveur SSH de base sur la machine virtuelle (VM) LabEx en utilisant OpenSSH. Cela a impliqué la mise à jour des listes de paquets, l'installation du paquet openssh-server et la vérification que le service SSH était en cours d'exécution en utilisant systemctl status ssh. Si nécessaire, le service pouvait être démarré avec systemctl start ssh.

La configuration initiale a fourni la base pour les étapes suivantes, qui impliqueront probablement l'utilisation d'Hydra pour tester la sécurité du serveur SSH en tentant de craquer des mots de passe avec différents nombres de threads. Le laboratoire analysera ensuite l'impact de différents nombres de threads sur les performances d'Hydra.