first commit

tools/rate-limit-probe/README.md

@@ -0,0 +1,41 @@
+# rate-limit-probe
+
+Mesure si l'endpoint d'authentification (ou tout endpoint sensible)
+de la preprod met en place un rate-limiting / verrouillage contre le
+bruteforce.
+
+## Principe
+
+Envoie `RATE_PROBE_COUNT` requêtes (20 par défaut) avec un mauvais
+mot de passe sur `LOGIN_PATH` et observe les codes de réponse :
+
+- **429** → rate-limiting actif (bon). Le seuil (après combien de
+  requêtes) se lit dans le journal.
+- **changement soudain de code** (ex : 401 → 403/423) → verrouillage
+  (lockout) après N échecs.
+- **rien de tout ça** (toujours 401/400) → AUCUN rate-limit :
+  vulnérabilité, le bruteforce n'est pas freiné.
+
+## Lancement
+
+```bash
+./probe.sh
+```
+
+Paramètres (dans `targets.env`) :
+- `RATE_PROBE_COUNT` — nombre de requêtes (défaut 20).
+- `RATE_PROBE_DELAY` — délai entre requêtes en secondes (0 = rafale ;
+  pour tester le rate-limit on veut justement une rafale, mais
+  gardez un count modéré).
+
+## Sortie
+
+- stdout : verdict (rate-limit actif / lockout / absent).
+- `output/rate-limit.log` : `horodatage \t n/N \t code`.
+
+## Actions typiques
+
+- Aucun rate-limit → en ajouter un au reverse proxy (ex : `limit_req`
+  nginx) ou côté application (bucket par IP+utilisateur).
+- Rate-limit trop agressif (429 dès la 2e requête) → risque de bloquer
+  les légitimes ; ajuster le seuil.