Ajuster le nombre de threads d'Hydra

Introduction

Dans ce laboratoire, vous apprendrez à ajuster le nombre de threads dans Hydra, un puissant outil de craquage de connexion réseau, afin d'optimiser ses performances. Nous configurerons un serveur SSH de base sur la machine virtuelle LabEx, puis utiliserons Hydra pour effectuer des tentatives de craquage de mots de passe avec différents nombres de threads (16, 32 et 4). En comparant la vitesse et en observant les effets de ces différents paramètres, vous comprendrez comment optimiser les attaques Hydra en ajustant le nombre de threads en fonction des ressources disponibles et des caractéristiques du service cible.

Configurer le 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 de gérer des services réseau en toute sécurité sur un réseau non sécurisé. Il est couramment utilisé pour les connexions à la ligne de commande à distance et l'exécution de commandes à distance.

Tout d'abord, nous devons installer le serveur OpenSSH. OpenSSH est un ensemble d'outils réseau de sécurité basés sur le protocole Secure Shell, et c'est la mise en œuvre SSH la plus courante.

Ouvrez un terminal dans la machine virtuelle LabEx. Vous pouvez utiliser le terminal Xfce par défaut.

Exécutez la commande suivante pour mettre à jour les listes de paquets :

sudo apt update

Cette commande synchronise les fichiers d'index de paquets à partir de leurs sources. Il est conseillé de l'exécuter avant d'installer tout nouveau logiciel. Vous pourriez être invité à saisir votre mot de passe, mais rappelez-vous que l'utilisateur labex possède les privilèges sudo sans mot de passe.

Ensuite, installez le serveur OpenSSH :

sudo apt install openssh-server -y

L'option -y répond automatiquement par « oui » à toutes les invites pendant l'installation, ce qui rend le processus non interactif.

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

sudo service ssh status

Pour confirmer que le serveur SSH est en cours d'exécution, vous pouvez vérifier si le port SSH (port 22) est en écoute. Utilisez la commande netstat :

netstat -tulnp | grep 22

Vous devriez voir une sortie similaire à ceci :

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp6       0      0 :::22                   :::*                    LISTEN      -

Cela indique que le serveur SSH est en écoute sur le port 22 pour les connexions IPv4 et IPv6.

Maintenant que le serveur SSH est configuré, vous pouvez vous y connecter depuis une autre machine à l'aide d'un client SSH. Cependant, pour ce laboratoire, nous allons nous concentrer sur l'utilisation d'Hydra pour craquer le mot de passe SSH avec différentes configurations de threads.

Exécuter Hydra avec 16 threads par défaut

Dans cette étape, vous utiliserez Hydra pour tenter de craquer le mot de passe de l'utilisateur labex sur votre serveur SSH. Vous commencerez par utiliser le nombre de threads par défaut d'Hydra, qui est de 16.

La liste de mots de passe a déjà été téléchargée lors de la configuration. Le fichier ~/project/password.txt contient la liste de mots de passe unix_passwords.txt du framework Metasploit, qui inclut des centaines de mots de passe Unix courants. Cette liste plus complète permettra une meilleure démonstration des différences de performances en fonction du nombre de threads par rapport à une petite liste manuelle.

Vous pouvez vérifier la disponibilité et la taille de la liste de mots de passe :

ls -la ~/project/password.txt
wc -l ~/project/password.txt

Cela vous affichera les détails du fichier et le nombre de mots de passe dans la liste (il devrait s'agir de plusieurs centaines d'entrées).

Maintenant, exécutez la commande Hydra. L'option -l spécifie le nom d'utilisateur à attaquer (labex), -P spécifie le chemin vers votre liste de mots de passe (~/project/password.txt), et -V active le mode verbeux pour afficher chaque tentative. ssh://localhost indique que vous ciblez le service SSH sur la machine locale.

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

Hydra commencera maintenant à tenter de se connecter au serveur SSH en utilisant chaque mot de passe de votre fichier password.txt. Puisque vous n'avez pas spécifié l'option -t, Hydra utilisera son nombre de threads par défaut de 16, ce qui signifie qu'il effectuera 16 tentatives de mot de passe simultanément. L'option -V vous affichera chaque tentative en temps réel.

Remarque importante concernant l'option -V :

Le paramètre -V (verbose) est crucial pour observer le processus d'attaque. Sans lui, Hydra ne montre que des informations sommaires et le résultat final, mais vous ne verrez pas les lignes individuelles [ATTEMPT] qui montrent chaque mot de passe testé. Cette sortie verbeuse vous aide à comprendre comment le nombre de threads affecte la vitesse et le modèle d'attaque.

Vous verrez une sortie similaire à ceci au fur et à mesure de la progression d'Hydra :

Hydra vX.Y (c) YYYY by van Hauser/THC - Utilisez librement mais uniquement à des fins légales.

Hydra démarré le YYYY-MM-DD HH:MM:SS
[DATA] max 16 tâches par 1 serveur, au total 16 tâches, XXX tentatives de connexion (l:1/p:XXX), ~XX tentatives par tâche
[DATA] attaque ssh://localhost:22/
[ATTEMPT] cible : localhost - login : labex - mot de passe : !@#$%
[ATTEMPT] cible : localhost - login : labex - mot de passe : !@#$%^
[ATTEMPT] cible : localhost - login : labex - mot de passe : 000000
...
[22][ssh] hôte : localhost   login : labex   mot de passe : labex
1 sur 1 cible terminée avec succès, 1 mot de passe valide trouvé
Hydra terminé le YYYY-MM-DD HH:MM:SS

Avec la liste de mots de passe plus complète, vous remarquerez que Hydra prend plus de temps à trouver le mot de passe correct, ce qui rend les différences de nombre de threads plus apparentes. Observez les informations de chronométrage fournies par Hydra lorsqu'il est terminé.

Augmenter à 32 threads et comparer les vitesses

Dans cette étape, vous augmenterez le nombre de threads utilisés par Hydra à 32 et observerez l'impact sur la vitesse de décryptage. L'augmentation du nombre de threads peut potentiellement accélérer le processus en permettant plus de tentatives simultanées, mais son efficacité dépend des ressources de votre système et des limitations du service cible.

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

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

Cette commande est identique à la précédente, sauf pour l'ajout de -t 32, qui indique explicitement à Hydra d'utiliser 32 threads. L'option -V garantit que vous pouvez voir chaque tentative de mot de passe.

Observez la sortie. Vous devriez remarquer qu'Hydra signale le démarrage de 32 tâches/threads :

Hydra vX.Y (c) YYYY by van Hauser/THC - Utilisez librement mais uniquement à des fins légales.

Hydra démarré le YYYY-MM-DD HH:MM:SS
[DATA] max 32 tâches par 1 serveur, au total 32 tâches, XXX tentatives de connexion (l:1/p:XXX), ~XX tentatives par tâche
[DATA] attaque ssh://localhost:22/
[ATTEMPT] target: localhost - login: labex - pass: !@#$%
[ATTEMPT] target: localhost - login: labex - pass: !@#$%^
[ATTEMPT] target: localhost - login: labex - pass: 000000
...
[22][ssh] host: localhost   login: labex   password: labex
1 sur 1 cible terminée avec succès, 1 mot de passe valide trouvé
Hydra terminé le YYYY-MM-DD HH:MM:SS

Comparaison des vitesses :

Avec la liste de mots de passe plus complète, vous devriez pouvoir observer des différences de temps plus notables entre les exécutions avec 16 threads et 32 threads. Faites attention à :

• Les heures de début et de fin signalées par Hydra
• Le calcul des « tentatives par tâche », qui montre comment la charge de travail est répartie
• Le temps total nécessaire pour terminer l'attaque

Avec 32 threads, vous pourriez observer des temps d'exécution plus rapides, en particulier si le mot de passe cible se trouve plus tard dans la liste de mots de passe. Cependant, vous pouvez également remarquer une utilisation accrue des ressources système et potentiellement plus de tentatives de connexion simultanées.

Réduire à 4 threads et observer

Dans cette étape, vous réduirez le nombre de threads utilisés par Hydra à 4 et observerez l'impact sur les performances. Ce scénario est utile lorsque vous disposez de ressources système limitées ou lorsque le service cible applique un contrôle de débit agressif qui pourrait bloquer trop de tentatives de connexion simultanées.

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

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

Cette commande est similaire aux précédentes, mais vous définissez maintenant explicitement le nombre de threads à 4 à l'aide de -t 4. L'option -V vous affichera chaque tentative de mot de passe en détail.

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

Hydra vX.Y (c) YYYY by van Hauser/THC - Utilisez librement mais uniquement à des fins légales.

Hydra démarré le YYYY-MM-DD HH:MM:SS
[DATA] max 4 tâches par 1 serveur, au total 4 tâches, XXX tentatives de connexion (l:1/p:XXX), ~XX tentatives par tâche
[DATA] attaque ssh://localhost:22/
[ATTEMPT] target: localhost - login: labex - pass: !@#$%
[ATTEMPT] target: localhost - login: labex - pass: !@#$%^
[ATTEMPT] target: localhost - login: labex - pass: 000000
...
[22][ssh] host: localhost   login: labex   password: labex
1 sur 1 cible terminée avec succès, 1 mot de passe valide trouvé
Hydra terminé le YYYY-MM-DD HH:MM:SS

Observation de l'impact :

Avec seulement 4 threads et la liste de mots de passe plus complète, vous devriez remarquer une différence significative dans les performances :

• Le nombre de « tentatives par tâche » sera beaucoup plus élevé, car chaque thread doit gérer plus de mots de passe.
• Le temps total d'exécution devrait être sensiblement plus long par rapport aux exécutions avec 16 et 32 threads.
• Vous verrez moins de messages [ATTEMPT] simultanés, car seules 4 tentatives s'exécutent simultanément.

Cette expérience démontre qu'un nombre de threads plus faible entraînera généralement des performances plus lentes, mais qu'il peut être un ajustement nécessaire dans certaines situations, telles que lorsque vous essayez d'éviter la détection par les mesures de sécurité d'un système cible ou lorsque vous travaillez sur une machine aux ressources limitées.

Analyser l'impact des threads sur les performances

Dans cette étape, vous analyserez l'impact du nombre de threads sur les performances d'Hydra en vous basant sur vos observations des étapes précédentes. Vous avez expérimenté avec 4, 16 (valeur par défaut) et 32 threads en utilisant une liste de mots de passe importante issue du framework Metasploit.

Points clés concernant le nombre de threads :

• Ressources système : Le nombre optimal de threads est fortement influencé par les ressources disponibles de votre système, notamment les cœurs CPU, la mémoire et la bande passante réseau. Si vous définissez un nombre de threads trop élevé, votre système pourrait être surchargé, entraînant une dégradation des performances en raison de la surcharge de commutation de contexte et de la concurrence pour les ressources.
• Limitations du service cible : Le service cible (dans ce cas, SSH) peut avoir des mécanismes de contrôle de débit ou d'autres mécanismes de sécurité en place. Si le service limite le nombre de tentatives de connexion par unité de temps, l'augmentation du nombre de threads au-delà d'un certain point n'améliorera pas les performances et pourrait même déclencher des alertes de sécurité ou des blocages temporaires.
• Latence réseau : Une latence réseau élevée entre Hydra et le service cible peut également limiter l'efficacité de l'augmentation du nombre de threads. Chaque thread a besoin d'établir et de maintenir une connexion, et une latence élevée peut ralentir ces opérations, annulant les avantages du parallélisme.
• Taille de la liste de mots de passe : Avec des listes de mots de passe plus importantes comme celle utilisée dans ce laboratoire, les différences de nombre de threads deviennent plus apparentes. La liste de mots de passe unix_passwords.txt contient des centaines d'entrées, ce qui rend l'impact des différents nombres de threads plus observable sur les performances.

Observations et recommandations générales :

• 4 threads : Ce paramètre est généralement plus lent mais convient aux systèmes dotés de ressources limitées ou lorsqu'on attaque des services avec un contrôle de débit strict. Il est moins susceptible de provoquer une surcharge du système ou de déclencher des alertes de sécurité immédiates. Avec la grande liste de mots de passe, vous devriez avoir observé des temps d'exécution beaucoup plus longs.
• 16 threads (valeur par défaut) : La valeur par défaut de 16 threads d'Hydra est souvent un bon équilibre entre les performances et l'utilisation des ressources pour de nombreux systèmes et services cibles. Elle offre un niveau de parallélisme raisonnable sans généralement surcharger la machine d'attaque ou la cible.
• 32 threads : L'augmentation du nombre de threads à 32 peut potentiellement améliorer les performances, surtout si votre système dispose de nombreuses ressources (par exemple, plusieurs cœurs CPU) et que le service cible n'a pas de contrôle de débit agressif. Cependant, il est crucial de surveiller l'utilisation des ressources de votre système pour s'assurer qu'il ne devient pas un goulot d'étranglement.

Métriques de performance à considérer :

Lors de l'évaluation des performances des threads, tenez compte de ces facteurs :

• Temps d'exécution total : Durée nécessaire pour passer du début à la fin.
• Tentatives par seconde : Fréquence des tentatives de mot de passe.
• Utilisation des ressources système : Utilisation du CPU, de la mémoire et du réseau.
• Réponse du service cible : Le service devient-il non réactif ou met-il en œuvre un blocage ?

Conclusion :

Il n'existe pas de nombre de threads « optimal » unique pour Hydra ; le paramètre optimal dépend d'un certain nombre de facteurs spécifiques à votre machine d'attaque et au service cible. Il est important d'expérimenter avec différents paramètres et de surveiller à la fois les performances de votre système et la réponse de la cible pour trouver l'équilibre le plus efficace entre la vitesse et l'utilisation des ressources. Comprendre ces dynamiques vous permet d'optimiser vos attaques Hydra pour différents scénarios.

Résumé

Dans ce laboratoire, vous avez appris à ajuster le nombre de threads d'Hydra et son impact sur les performances en utilisant une liste de mots de passe substantielle. Vous avez commencé par configurer un serveur SSH de base sur votre machine virtuelle LabEx. Vous avez ensuite utilisé Hydra pour effectuer des tentatives de cassage de mot de passe contre ce serveur SSH avec différents nombres de threads : 16 par défaut, 32 augmenté et 4 réduit, en utilisant la liste de mots de passe unix_passwords.txt du framework Metasploit. En observant la vitesse et le temps d'exécution pour chaque scénario avec une liste de mots de passe de taille réaliste, vous avez acquis des connaissances pratiques sur la façon dont le nombre de threads affecte l'efficacité d'Hydra. Ce laboratoire a démontré l'importance d'optimiser le nombre de threads en fonction des ressources système disponibles et des caractéristiques du service cible pour obtenir les meilleures performances dans les opérations de cassage de mot de passe.