Régler le rate limiting¶

À qui s'adresse cette page¶

Administrateurs qui souhaitent ajuster les limites de débit pour protéger l'instance contre les attaques par force brute et les abus d'API, tout en évitant de bloquer les utilisateurs légitimes.

Variables disponibles¶

Ces variables se définissent dans /opt/gitrust/.env. Un redémarrage est nécessaire après modification. 0 désactive la limite (déconseillé en production).

Les limites s'appliquent par adresse IP. Si gitrust est derrière un reverse-proxy, assurez-vous que le vrai IP du client est transmis (en-tête X-Forwarded-For ou X-Real-IP).

Profils de configuration recommandés¶

Petite équipe (≤ 5 personnes, réseau de confiance)¶

Toutes les personnes travaillent depuis un réseau connu. On peut se permettre des limites légèrement plus souples pour éviter les faux positifs lors des scripts d'intégration.

RATE_LIMIT_LOGIN_PER_MINUTE=10
RATE_LIMIT_REFRESH_PER_MINUTE=20
RATE_LIMIT_GENERAL_PER_MINUTE=200

Équipe moyenne (6-20 personnes, instance interne)¶

Configuration par défaut, adaptée à la cible principale de gitrust.

RATE_LIMIT_LOGIN_PER_MINUTE=5
RATE_LIMIT_REFRESH_PER_MINUTE=10
RATE_LIMIT_GENERAL_PER_MINUTE=100

Instance publique ou exposée sur Internet (50+ utilisateurs)¶

Limites plus strictes sur le login pour contrer les attaques par dictionnaire. La limite générale peut être augmentée si vos utilisateurs utilisent intensivement l'API.

RATE_LIMIT_LOGIN_PER_MINUTE=3
RATE_LIMIT_REFRESH_PER_MINUTE=10
RATE_LIMIT_GENERAL_PER_MINUTE=150

CI/CD avec beaucoup d'appels API¶

Si vos pipelines CI font de nombreuses requêtes API (création de statuts, commentaires, webhooks), augmentez uniquement RATE_LIMIT_GENERAL_PER_MINUTE depuis les IPs des runners :

RATE_LIMIT_GENERAL_PER_MINUTE=300

Ou configurez Nginx pour whitelister les IPs des runners CI avant le rate limiting de gitrust.

Surveiller les réponses 429¶

Quand une limite est dépassée, gitrust retourne HTTP 429 Too Many Requests. Ces réponses apparaissent dans les logs avec le niveau WARN.

# Surveiller les 429 en temps réel
sudo journalctl -u gitrust -f | grep "429\|rate_limit\|too many"

# Compter les 429 sur les 24 dernières heures
sudo journalctl -u gitrust --since "24 hours ago" --no-pager \
  | grep -c "429\|rate_limit"

Si vous utilisez Nginx comme reverse-proxy, vous pouvez aussi consulter les logs Nginx :

grep " 429 " /var/log/nginx/gitrust-access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Cela vous donne les IPs les plus souvent bloquées, utile pour distinguer une vraie attaque d'un utilisateur légitime avec un script trop agressif.

Gitrust derrière un reverse-proxy¶

Si gitrust écoute sur 127.0.0.1:4000 derrière Nginx, le rate limiting de gitrust voit l'IP 127.0.0.1 pour toutes les requêtes, ce qui rend la protection inefficace.

Configurez Nginx pour transmettre le vrai IP :

# Dans le bloc location de gitrust
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

Et dans /opt/gitrust/.env, indiquez que gitrust est derrière un proxy de confiance :

# Ajouter si le reverse-proxy est sur 127.0.0.1
SERVER_HOST=127.0.0.1

Gitrust utilise alors X-Real-IP pour identifier l'IP cliente réelle dans ses mécanismes de rate limiting.

Rate-limit TCP par IP (ssh-guard)¶

Les variables RATE_LIMIT_* ci-dessus s'appliquent à la couche HTTP (login, API, refresh JWT). Pour le port SSH (:2222 par défaut), un mécanisme distinct est fourni par la crate gitrust-ssh-guard : un cap dur de connexions TCP/seconde par IP, indépendant de tout traitement applicatif.

Différences avec le rate-limit HTTP :

• Pas de réponse 429 : la connexion TCP est droppée immédiatement au listener (avant tout handshake SSH).
• Pas de ban persistant en DB : un scan de port n'engendre aucune écriture.
• Budgets indépendants par IP via token bucket GCRA (algorithme leaky bucket sans biais).
• Une IP allowlistée dans ssh_guard_acl bypasse complètement ce cap.

Pour la recette complète (profils par topologie, dry-run, allowlist CI), voir Configurer ssh-guard. Pour le détail des événements émis (connection_flood_detected, connection_dropped avec reason=flood_limit), voir Événements ssh-guard (JSON).

Fail2ban comme couche complémentaire¶

Le rate limiting de gitrust agit requête par requête. Fail2ban analyse les logs et peut bannir les IPs pour une durée configurable après plusieurs 429.

Voir Durcir avec Fail2ban pour la configuration complète.

Pour aller plus loin¶

• Variables d'environnement — section Rate Limiting
• Variables d'environnement — section SSH_GUARD_*
• Configurer ssh-guard
• ssh-guard : détection d'attaques SSH
• Durcir avec Fail2ban
• Conformité ANSSI PA-074 — protection contre les attaques par force brute