I. Présentation

Dans ce tutoriel, nous allons apprendre à récupérer la clé de sécurité WiFi de tous les réseaux sans-fil connus, c'est-à-dire les profils enregistrés sur la machine locale. À chaque fois que l'on se connecte à un nouveau réseau WiFi, les informations sur le réseau sont enregistrées dans Windows : nom du SSID, clé de sécurité, etc...

Avec l'interface graphique de Windows, on peut récupérer facilement une clé de sécurité sans-fil, tandis qu'à partir de PowerShell ou de l'utilitaire WirelessKeyView de Nirsoft, on peut récupérer l'ensemble des clés de sécurité WiFi enregistrées sur une machine Windows.

Version originale : 9 septembre 2012.

II. Récupérer la clé de sécurité du réseau actuel

Sous Windows, que ce soit du Windows 7, Windows 10 ou Windows 11, on peut facilement voir la clé de sécurité du réseau auquel on est connecté actuellement à partir du "Panneau de configuration" (celui d'ancienne génération).

Accédez à "Démarrer" puis recherchez "Panneau de configuration". Cliquez sur "Centre Réseau et partage" dans l'affichage par icônes.

Pour accéder à l'état de la connexion en cours, cliquez dessus dans le centre de réseau et partage. Dans mon cas, je clique sur "Connexion réseau sans fil (NEUF AF00)".

Ensuite, il faut accéder aux propriétés de la connexion sans fil en cliquant sur le bouton "Propriétés sans fil".

Accédez à l'onglet "Sécurité"  puis cochez la case "Afficher les caractères" pour que la clé de sécurité s'affiche en clair (ceci nécessite une élévation de privilèges). Vous n'avez plus qu'à récupérer la clé !

III. Récupérer les clés de sécurité de tous les réseaux WiFi

Pour récupérer l'ensemble des mots de passe WiFi de tous les réseaux connus par votre machine, il y a plusieurs façons de faire : avec PowerShell en utilisant NETSH, ou avec l'utilitaire WirelessKeyView de Nirsoft.

A. WirelessKeyView

Le logiciel WirelessKeyView est proposé gratuitement par Nirsoft. Vous pouvez le télécharger à l'adresse suivante :

• WirelessKeyView

Vous allez obtenir une archive ZIP qu'il faudra décompresser avec le mot de passe indiqué sur la page de téléchargement (WKey4567#). Ensuite, il suffit de lancer le logiciel et de constater que toutes les informations s'affichent à l'écran, en clair ! Voici un exemple :

Dans certains cas, l'antivirus peut ne pas être content et détecter ce logiciel comme un outil malveillant ! Dans ce cas, soit vous créez une exception, soit vous utilisez la seconde méthode proposée ci-dessous. Personnellement, sur une machine Windows 11 22H2 équipée de Windows Defender, je n'ai pas eu la moindre alerte !

B. PowerShell et NETSH

On peut aussi se passer de l'installation d'un logiciel, en utilisant des outils natifs à Windows : PowerShell et NETSH. En effet, NETSH dispose de commandes pour lister les profils WiFi mais aussi afficher les clés de sécurité, donc on peut le coupler à PowerShell pour faire une boucle et obtenir l'information de tous les réseaux.

Avec NETSH, on peut lister les profils WiFi avec cette commande :

netsh wlan show profiles

Voici un exemple :

Puis, on peut récupérer la clé de sécurité d'un réseau sans-fil spécifique en précisant le nom du profil (SSID) :

netsh wlan show profile name=MonReseauWiFi key=clear

Voici un exemple :

À partir de PowerShell, on peut déjà récupérer la liste des profils et stocker les noms dans une variable $WLANList :

$WLANList=((netsh wlan show profiles) -match '\s{2,}:\s') -replace '.*:\s' , ''

Puis, avec une boucle Foreach on peut afficher la clé de sécurité pour chaque profil, en écrivant également dans la console le nom du réseau. Il est possible d'améliorer et affiner ce bout de code, mais dans l'idée, cela donne :

Foreach($WLAN in $WLANList){ Write-Host $WLAN ; netsh wlan show profile name=$WLAN key=clear | Where{ ($_ -match "Contenu de la clé") } }

Dans la console, une liste des profils WiFi avec la clé de sécurité correspondante va s'afficher sans avoir utilisé le moindre logiciel tiers ! Il ne reste plus qu'à la récupérer ! Vous pouvez aussi utiliser ce script PowerShell.

The post Windows : récupérer la clé de sécurité WiFi de tous les réseaux connus first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons apprendre à chiffrer un mot de passe dans un script PowerShell en utilisant le SID de l'utilisateur qui va générer la chaîne sécurisée. C'est une façon, parmi d'autres, de ne pas écrire le mot de passe en clair dans un script.

Ce mot de passe chiffré sera ensuite utilisable pour réaliser diverses actions : s'authentifier auprès de Microsoft 365, auprès d'Azure ou encore pour créer un compte Active Directory qui utilise ce mot de passe (cas d'un mot de passe par défaut que l'on attribue à tous les nouveaux utilisateurs.

Dans cet article, je vais utiliser deux commandes incontournables lorsque l'on manipule des chaînes de caractères sécurisées (SecureString) :

• ConvertTo-SecureString
• ConvertFrom-SecureString

II. Chiffrer le mot de passe avec PowerShell

L'objectif va être de chiffrer le mot de passe "MonSuperMotDePasse" pour que l'on puisse l'utiliser dans le script sans qu'il soit visible en clair. Tout d'abord, on crée une chaîne sécurisée à partir de notre mot de passe qui est un texte brut, ce qui implique d'utiliser l'option "-AsPlainText". Le paramètre "-Force" est nécessaire lorsque l'on utilise "-AsPlainText" sauf si l'on utilise PowerShell 7+ (mais ça fonctionne quand même, car c'est toujours accepté pour des raisons de compatibilité).

$MotDePasse = "MonSuperMotDePasse"
$MotDePasse = ConvertTo-SecureString -String $MotDePasse -AsPlainText -Force

Si l'on essaie de lire le contenu de cette variable ou que l'on regarde son type ($MotDePasse.GetType()), on voit qu'il s'agit d'une SecureString. C'est tout bon.

System.Security.SecureString

Ensuite, nous allons récupérer sous forme de texte la chaîne chiffrée, mais sans dévoiler notre super mot de passe :

$MotDePasse | ConvertFrom-SecureString

Une valeur est retournée dans la console. Par exemple :

Il s'agit du mot de passe chiffré : c'est cette valeur que nous allons utiliser dans la prochaine partie de cet article.

III. Utiliser le mot de passe chiffré

Maintenant, toujours à partir du même compte utilisateur, on va utiliser ce mot de passe et on peut aussi définir un nom d'utilisateur. La variable $Utilisateur contient le nom d'utilisateur, tandis que la variable $UtilisateurMdp contient le mot de passe sous la forme d'une SecureString. On utilise ConvertTo-SecureString sans le paramètre "-AsPlainText", car ici ce n'est pas un texte brute mais une chaîne déjà chiffrée que l'on veut stocker dans une SecureString.

Ce qui donne (on réutilise bien la valeur précédente) :

$Utilisateur = "florian@it-connect.fr"
$UtilisateurMdp = 01000000d08c9ddf0115d1118c7a00c04fc297eb010000006c76e757249edf429fc0ee5c2acb5b710000000002000000000010660..... | ConvertTo-SecureString

Ensuite, on peut vérifier que $UtilisateurMdp est bien une SecureString.

Il ne reste plus qu'à l'utiliser dans notre script !

Par exemple, nous pouvons créer un utilisateur dans l'Active Directory qui va hériter de ce mot de passe :

New-ADUser -Name "TestMdp" -AccountPassword $UtilisateurMdp

Dans le même esprit, pour s'authentifier sur Azure AD, sur Microsoft Teams, etc.

$Creds = New-Object System.Management.Automation.PSCredential($Utilisateur,$UtilisateurMdp)
Connect-AzureAD -Credential $Creds
Connect-MicrosoftTeams -Credential $Creds

Tout cela pour montrer que l'on peut utiliser la SecureString pour définir un mot de passe lors de la création d'un compte ou comme mot de passe dans le cadre de l'authentification sur un service.

IV. Conclusion

Grâce à cette méthode, vous êtes capable de stocker un mot de passe chiffré dans un script PowerShell en utilisant une SecureString et sans qu'il soit visible en clair dans le code ! Il faut savoir que la chaîne chiffrée que l'on a générée dans cette mise en pratique est liée à l'utilisateur et à l'ordinateur, donc il faudra penser à la générer sur l'environnement cible directement pour éviter les dysfonctionnements (et mauvaises surprises). Pour que ce soit "portable", il faudrait s'appuyer sur une clé externe comme une clé AES, par exemple.

Si le sujet du chiffrement avec PowerShell vous intéresse, je vous recommande de regarder du côté de la commande PowerShell "Protect-CmsMessage" (associée à une méthode basée sur de la cryptographie asymétrique).

• Protect-CmsMessage

The post PowerShell : comment chiffrer un mot de passe dans un script ? first appeared on IT-Connect.

Sébastien Vachon-Desjardins, ancien affilié au groupe de ransomware Netwalker, vient d'être condamné à 20 ans de prison suite aux cyberattaques contre plusieurs entreprises auxquelles il a participé. Il doit également renoncer à son gain de 21,5 millions de dollars.

Dans le rapport de jugement de Sébastien Vachon-Desjardins, nous pouvons lire : "Le défendeur est par la présente placé sous la garde du Bureau des prisons des États-Unis pour être emprisonné pour une durée de DEUX CENT QUARANTE (240) MOIS.", soit 20 ans de prison !

Cette lourde peine se justifie par plusieurs chefs d'accusation. En effet, Ce Canadien de 34 ans a été condamné par un tribunal de Floride après avoir plaidé coupable de "conspiration en vue de commettre une fraude informatique", de "conspiration en vue de commettre une fraude électronique", de "dommages intentionnels à un ordinateur protégé" et de "transmission d'une demande en relation avec des dommages à un ordinateur protégé".

Pour lui, les problèmes ne s'arrêteront pas après ces 20 années passées derrière les barreaux puisqu'à sa sortie, M. Vachon-Desjardins devra également purger trois ans de liberté surveillée. Pendant cette période, il n'aura pas le droit d'occuper un emploi dans le domaine de l'IT, ni d'utiliser un ordinateur connecté à Internet, un smartphone, une console de jeux ou un appareil électronique !

Et pour finir, le juge a pris la décision de lui confisquer son argent : 21,5 millions de dollars ! Il s'agit sans aucun doute d'une somme qu'il a obtenue grâce à ses activités malveillantes.

Sébastien Vachon-Desjardins a été arrêté au Québec le 27 janvier 2021, à cause de son affiliation au groupe de ransomware Netwalker (un ransomware-as-a-service) lancé en 2019. Lors de cette arrestation, les forces de l'ordre ont pu mettre la main sur 719 Bitcoins et 790 000 dollars canadiens. Ensuite, Vachon-Desjardins a été extradé vers les États-Unis en mars 2022.

À voir si cette lourde peine fait réfléchir certaines personnes qui participent aux activités de groupes ransomwares...! Quel est votre avis sur la question ?

Source

The post Ransomware Netwalker : 20 ans de prison pour cet affilié canadien de 34 ans ! first appeared on IT-Connect.

Il y a quelques jours, l'enseigne McDonalds France a-t-elle subi un piratage informatique donnant lieu à la divulgation d'une base de données avec 3 millions d'enregistrements ? Il s'agirait d'une fausse alerte... Mais à quoi correspondent ces données ?

À en croire l'article publié sur le site Zataz, McDonalds France serait dans la sauce... Plusieurs pirates informatiques ont échangé au sujet d'une base de données qui contiendrait 3 millions d'enregistrements correspondants à des informations de clients de McDonalds France. Parmi ces informations, il y aurait : nom, prénom, adresse e-mail, date de naissance et un historique des transactions PayPal (ce qui est surprenant). Le tout dans un fichier de 385 Mo.

La bonne nouvelle, c'est que les informations contenues dans cette base sont chiffrées, et sans la clé de déchiffrement, il n'est pas possible de visualiser les informations en claires. C'est appréciable de voir que McDonalds France traite ses données de cette façon ! De ce fait, tout cela n'est qu'hypothèse... Et ces informations proviendraient de l'application officielle de chez McDo.

Ensuite, Damien Bancal du site Zataz a pris le temps de contacter le service communication de McDonalds France, qui affirme qu'il y a eu une enquête et une analyse de cette base de données. Voici ce qu'il faut retenir de la réponse obtenue :

• La base de données mise en ligne est cryptée et anonymisée
• Elle n’est pas une base de données clients
• C'est une base de comptes de tests anonymisés

Pour le moment, les pirates cherchent à déchiffrer les données contenues dans cette base de données. Si les affirmations de McDonalds France sont vraies, alors on ne devrait pas avoir de mauvaises surprises s'ils parviennent à déchiffrer les données, et on peut considérer qu'il s'agit d'une fausse alerte !

Source

The post Piratage de McDonalds France : une fausse alerte ? first appeared on IT-Connect.

I. Présentation

Dans cet article, nous allons apprendre à utiliser Locust, un outil de test de charge pour les services et serveurs web. L'idée du test de charge est d'évaluer la réaction et le comportement d'un serveur ou service web, d'un pare-feu, reverse-proxy, load-balancer ou même d'une solution de cache face à la navigation de plusieurs utilisateurs (10, 100, 1000) en même temps. Nous pourrons par exemple découvrir que lorsque 100 utilisateurs accèdent à la même page au même moment, notre serveur web montre des signes de faiblesse (temps de réponse allongé).

Locust se veut simple d'utilisation, sans interface graphique complexe. Il se paramètre et s'utilise majoritairement via du code Python. Ce dernier sert en effet à définir le comportement des utilisateurs que nous voulons simuler et à lancer le test de charge. Une interface web permet ensuite d'ajuster les derniers paramètres puis de suivre le test de charge et surtout d'obtenir des rendus sur les résultats obtenus.

II. Installation de Locust

Nous pouvons utiliser le gestionnaire de module Python pip pour installer locust (Python3) :

$ pip -V
pip 22.2.1 from /home/itc/.local/lib/python3.10/site-packages/pip (python 3.10)

$ pip install locust

Nous pourrons ensuite importer locust dans nos scripts Python :

$ python3
Python 3.10.5 [GCC 11.3.0] on linux
>>> from locust import *

Nous voilà prêts à réaliser notre premier script de test de charge avec Locust !

III. Premier test de charge d'un service web

Pour commencer, faisons simple. Je vais ouvrir un mini serveur web HTTP avec Python dans un terminal :

python3 -m http.server

Cela me permettra d'avoir une cible pour mon script Locust, mais aussi de rapidement voir les journaux HTTP et constater si mon script se comporte comme je le souhaite. Créons un script simple, que je nomme /tmp/loc.py :

from locust import HttpUser, between, task

class WebsiteUser(HttpUser):
   wait_time = between(3, 6)

   def on_start(self):
      self.client.get("/")

   @task
   def task1(self):
      self.client.get("/")

   @task
   def task2(self):
     self.client.get("/operation.php")

Première chose, pas besoin de spécifier l'URL/domaine cible dans le script, ce paramètre est géré plus tard via l'interface web. Nous allons à présent détailler notre premier script :

from locust import HttpUser, between, task

Importation du module Python locust est des fonctions utiles.

class WebsiteUser(HttpUser):

Création d'une classe WebsiteUser provenant du module Locust. Une instance de cette classe représente un utilisateur, qui pourra réaliser plusieurs requêtes/actions au cours du test.

wait_time = between(3, 6)

Délai d'attente de l'utilisateur entre chaque action, la valeur est ici sélectionnée aléatoirement entre 3 et 6 secondes. Au cours du test, nos utilisateurs seront créés tous en même temps ou au fur et à mesure et réaliseront des actions en boucle, avec un délai d'attente aléatoire entre chaque action.

def on_start(self):
   self.client.get("/")

Définition du comportement de l'utilisateur lors de sa création, il ne réalisera cette action (ici, se rendre sur la racine de la cible web) qu'une fois. 

@task
def task1(self):
   self.client.get("/")

@task
def task2(self):
   self.client.get("/operation.php")

Création de deux tâches, qui, elles, seront exécutées en boucle :

• aller sur la racine du site web (requête GET)
                OU
• aller sur la page /operation.php (requête GET)

Ces tâches sont identifiées par le décorateur @task. Il faut bien noter qu'à la suite de la tâche réalisée, le script observe un temps d'attente (paramétré entre 3 et 6 secondes ici), puis sélectionne une autre tâche et la réalise.

Maintenant que nous avons un script, assez simple, il nous suffit de le lancer. Si vous avez installé Locust via pip, il y a de bonnes chances pour que le binaire locust se situe dans votre dossier bin/ personnel (~/.local/bin/locust). Si vous l'avez installé via apt/yum, il doit être dans le dossier des binaires standard (/usr/bin) donc déjà dans votre PATH :).

$ /~/.local/bin/locust -f /tmp/loc.py
[2022-10-01 15:29:52,466] itc-test/INFO/locust.main: Starting web interface at http://0.0.0.0:8089 (accepting connections from all network interfaces)
[2022-10-01 15:29:52,481] itc-test/INFO/locust.main: Starting Locust 2.12.1

Nous pouvons à présent nous rendre sur l'interface web http://0.0.0.0:8089 :

Ici, on peut paramétrer le nombre total d'utilisateurs que nous souhaitons simuler et le nombre de créations d'utilisateurs par seconde. Par exemple, si je souhaite simuler 200 utilisateurs avec une création de 20 par seconde, j'aurai tous mes utilisateurs au bout de 10 secondes et chacun d'entre eux feront des boucles avec un délai d'attente de 3 a 6 secondes, puis une requête sur / ou /operation.php, tel que défini dans mon script.

Dans Advanced Options, le paramètre Run time permet de paramétrer une durée du test, utile pour faire des tests d'une durée équivalente entre plusieurs sites ou pour comparer des paramétrages différents côté service web.

Nous pouvons ensuite cliquer sur Start swarming, un tableau apparaîtra et détaillera le nombre de requêtes faites par point d'entrée, le nombre de fails, et différentes données sur les tailles et durée de réponse obtenue (à noter que RPS signifie request per second) :

Pour avoir des résultats parlant et contourner les limitations de capacité de mon environnement (voir chapitre "Limitations") j'ai donc monté une VM Linux avec 200 Mo de RAM, qui aura du mal à répondre à de multiples requêtes sur un réseau local d'hyperviseur. Également, j'ai créé sur ce service web une page index.html standard, et une page operation.php qui fait des opérations de chiffrement. Cela afin de simuler l'activité d'un serveur qui effectue des opérations dans une base de données afin de générer une réponse pour chaque requête. Je vous partage ici mon script pour information :

<?php

  $s = "Welcome";

  $ciphering = "AES-128-CTR";
  $iv_length = openssl_cipher_iv_length($ciphering);
  $options = 0;
  $encryption_iv = '1234567891011121';
  $round = rand(30,50);
  for ($i =0; $i < $round; $i++) 
  {
    $encryption_key = rand(1000000000,10000000000000);
    $s = openssl_encrypt($s, $ciphering, $encryption_key, $options, $encryption_iv);
  }
  echo "s : $s\n";
?>

III. Analyse des résultats

Pendant et à la fin de l'exécution d'un test de charge, il est possible de visualiser les données dans le tableau exposé plus haut, mais également dans trois graphiques (menu Charts).

Le dernier graphique montre la montée en charge des tests avec le nombre d'utilisateurs simulés en même temps (ici 5000 utilisateurs avec une création des utilisateurs par lot 50/seconde).

Le premier graphique indique en vert le nombre de requêtes par seconde et en rouge, nombre d'échecs par seconde (erreur HTTP/500 ou timeout). Le graphique du milieu décrit le temps de réponse médian (ligne verte) et pour le 95eme centile (ligne jaune). C'est le graphique le plus intéressant, car sans causer d'erreur, une surcharge du serveur web va entraîner des temps de réponse de plus en plus longs. Ce que l'on observe dans mon graphique ci-dessus.

Pour rappel, la moyenne est la moyenne arithmétique d'une série de chiffres. la médiane est une valeur numérique qui sépare la moitié supérieure de la moitié inférieure d'un ensemble (50% des requêtes obtiennent un temps de réponse supérieur au temps médian, 50% un temps de réponse inférieur

En statistique le quatre-vingt-quinzième centile est la valeur telle que 95 % des valeurs mesurées sont en dessous et 5 % sont au-dessus.

Le menu Failures permet d'avoir une idée du nombre de message d'erreur reçu et de la réponse du serveur :

Ici, on peut identifier des échecs de réponse côté serveur (pas de réponse/timeout).

IV. Scripting "avancé" avec locust

Nous avons fait un script assez simple contenant deux tâches et des requêtes GET. En parcourant la documentation Locust. Vous remarquez qu'il est possible de faire des choses plus complexes.

A. Prioriser le comportement de l'utilisateur :

Si l'on souhaite orienter le comportement de nos utilisateurs, il est possible de mettre un "poids" assigné à chaque tâche :

class WebsiteUser(HttpUser):
   wait_time = between(3, 6)

   def on_start(self):
     self.client.get("/")

   @task(1)
   def task1(self):
      self.client.get("/")

   @task(3)
   def task2(self):
      self.client.get("/operation.php")

Avec ces valeurs (@task(1), @task(3)), les utilisateurs auront trois fois plus de chance de sélectionner la tâche 2 plutôt que la tâche 1, ce qui permet de simuler une tendance des utilisateurs à aller plus sur une page que sur une autre.

B. Envoyer des données POST

Si vous souhaitez simuler les comportements d'utilisateurs envoyant des données (par exemple : authentification), cela est également possible

@task
def task3(self):
  self.client.post("/login", json={"username":"foo", "password":"bar"})

C. Répartition de la charge de travail

Il est également possible de répartir la charge de travail lors du test à l'aide de nœuds esclaves. Il faut pour cela lancer une instance en mode master :

$ ~/.local/bin/locust -f loc.py --master
[2022-10-01 10:27:47,041] itc-test/INFO/locust.main: Starting web interface at http://0.0.0.0:8089 (accepting connections from all network interfaces)
[2022-10-01 10:27:47,056] itc-test/INFO/locust.main: Starting Locust 2.12.1

Les autres instances doivent être démarrées en mode worker et indiquer l'adresse IP du master:

$ /~/.local/bin/locust -f loc.py --worker --master-host=192.168.56.3

Lorsqu'un worker se connecte au master, le message suivant apparaît au niveau du master :

[2022-10-01 10:29:22,021] itc-test/INFO/locust.runners: Worker debian_77b92f24a7a54ac09ceeae99588e984b (index 0) reported as ready. 1 workers connected.

Attention cependant, dans ce cas, le master n'effectuera plus de requête lui-même. Il vous faudra donc au minimum deux workers pour avoir un gain de performance.

D. Pour aller plus loin

Je vous invite à consulter la documentation de Locust pour découvrir toutes ses possibilités : https://docs.locust.io/. Il est par exemple possible de lire le contenu des réponses puis d'afficher un message spécifique quand les résultats (menu Failures) afin d'avoir un tri plus personnalisé des messages d'erreurs et réponses du serveur.

Sans avoir testé toutes ses fonctionnalités, l'outil me paraît facilement personnalisable tant sur la partie test (comportement des utilisateurs) que sur la présentation des résultats.

V. Limitations

A. Capacité système

Il est important de noter que des limitations peuvent exister dans vos environnements de test et empêcher Locust d'atteindre les charges demandées. Votre système n'est à lui seul pas en capacité de lutter contre un serveur digne de ce nom (à moins de trouver une vulnérabilité permettant de décupler votre force de frappe, type amplification). Ce dernier comporte des limitations comme le nombre de fichiers pouvant être ouverts en même temps, ou le nombre de connexions en attente pouvant être active en même temps. Par exemple, voici ce que j'obtiens si je souhaite simuler 10 0000 utilisateurs avec Locust sur une machine virtuelle (4 Go de RAM) :

À première vue, mon test a permis de faire tomber le serveur web, le nombre de "fail" ne fait qu'augmenter ! Cependant, si je regarde le menu Failures pour avoir les détails des messages d'erreurs obtenus, j'obtiens cela :

C'est mon système qui limite les tests (OSError - Too many open files), il ne parvient plus à ouvrir de fichier (il crée certainement un fichier socket par connexion ou utiliser un fichier pour stocker le résultat de chaque requête de façon temporaire). Mon système ici n'est tout simplement pas calibré pour simuler autant de connexions. D'ailleurs, Locust nous prévient rapidement de cette limitation :

# /home/itc/.local/bin/locust -f /home/itc/Documents/loc.py 
WARNING/locust.main: System open file limit '1024' is below minimum setting '10000'.
It's not high enough for load testing, and the OS didn't allow locust to increase it by itself. 
See https://github.com/locustio/locust/wiki/Installation#increasing-maximum-number-of-open-files-limit for more info.

En effet, vous pouvez toujours essayer de créer 2000 requêtes par seconde, si votre système ou l'infrastructure réseau n'est pas fait pour supporter une telle charge, Locust ne parviendra au maximum des capacités paramétrées et cela faussera vos tests.

B. Capacité réseau

Les limitations de vos tests peuvent également provenir de votre environnement réseau. Par exemple, j'ai fait mes premiers tests depuis une VM VirtualBox dont l'interface était paramétrée en mode NAT, ce qui impacte très durement les capacités réseau (Locust ne parvenait qu'à faire 9 requêtes par seconde). Le passage en bridge m'a permis de passer à 60 requêtes par seconde. Le tout pour un site situé sur Internet, chemin par lequel d'autres éléments peuvent freiner mon test (mon routeur, mon architecture réseau, etc.).

Également, si votre poste est en Wifi, il risque d'être rapidement limité par les capacités du point d'accès qui acheminera vos paquets jusqu'au serveur web testé.

Il faut donc être conscient de tout cela lorsque l'on fait un test.

C. Contourner les limitations locales

Pour contourner ces limitations techniques, le plus simple semble de louer un serveur à haute capacité (réseau et système) chez un hébergeur cloud (OVHcloud, Azure, Google Cloud Platforme, AWS, etc.). Directement exposé sur Internet et profitant d'infrastructures musclées, ce serveur ne subira les freins et ralentissements éventuels de vos réseaux internes et vos tests ne perturberont pas vos utilisateurs.

Une deuxième option lorsque vous hébergez vos serveurs web dans votre propre Datacenter est de se brancher directement au serveur en question pour avoir un test qui sera le plus "violent" possible.

Dans un contexte réaliste, il ne faut pas oublier de tester non seulement le serveur web, mais aussi tous les composants qui peuvent y mener dans le cadre de l'utilisation de normale de ce dernier. Par exemple, lorsqu'un utilisateur parcourt votre site web depuis internet, il passe par votre routeur périphérique, votre pare-feu, potentiellement un système anti-DDOS, un reverse-proxy, etc. Ces éléments peuvent chacun constituer un point faible au niveau du test de charge : qu'est-ce qu'un SPOF ? 

N'hésitez pas à poser vos questions et partagez vos expériences dans les commentaires ou sur notre Discord.

The post Serveur Web : tests de charge en Python avec Locust first appeared on IT-Connect.