41 lines
1.3 KiB
Markdown
41 lines
1.3 KiB
Markdown
|
# 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.
|