← retour aux outils back to tools

# lbd

Détecteur de répartition de charge (Load Balancing Detector). Identifie si un serveur web utilise de la répartition de charge en détectant des incohérences dans les en-têtes HTTP, les cookies de session et les temps de réponse sur plusieurs requêtes. Load Balancing Detector. Identifies if a web server uses load balancing by detecting inconsistencies in HTTP headers, session cookies, and response times across multiple requests.

↗ https://github.com/jamieson-yoel/lbd

## Overview

lbd (Load Balancing Detector) sends multiple HTTP requests to a web server and analyzes responses for inconsistencies — different Server headers, varying Date values, and session cookie patterns — that indicate load balancing or CDN infrastructure. Knowing a target uses load balancing affects testing strategy.

## Basic Usage

Check a domain for load balancing

    lbd example.com

Check specific port

    lbd example.com 8080

HTTPS

    lbd example.com 443

## What lbd Detects

    # DNS-based load balancing
    # → Multiple IPs returned for the same hostname

    # HTTP-based load balancing
    # → Different Server: headers between requests
    # → Date header inconsistencies
    # → Different cookie values between requests

    # Example output:
    # lbd example.com
    # Checking for DNS-loadbalancing: FOUND
    #   → 93.184.216.34
    #   → 93.184.216.35
    #
    # Checking for HTTP-loadbalancing [Server]:
    #   → Apache/2.4.1
    #   → nginx/1.18.0
    # FOUND (Different server headers!)

## Testing Implications

    # If load balancing is detected:
    # 1. Each test request may hit a different backend
    # 2. Vulnerability scans may produce inconsistent results
    # 3. Session-based attacks need sticky sessions
    # 4. Different backends may have different software versions

    # Strategy adjustments:
    # - Test each backend IP directly
    # - Use sticky sessions in scanners
    # - Fuzz all backends individually

## Bypass Techniques

Test individual backends by IP (bypass load balancer routing)

    curl -H "Host: example.com" http://93.184.216.34/

Use Host header to route to specific backend

    curl -H "Host: example.com" http://BACKEND_IP/

    # Identify backends from server responses
    for i in 1 2 3 4 5; do
      curl -s -I http://example.com | grep "Server:"
    done

## Tips

- Load balancing discovery is part of infrastructure mapping
- CDN providers (Cloudflare, Akamai) also show up as load balancers
- If backends differ in version, the older/unpatched one is your primary target
- Check for X-Forwarded-For headers — may reveal internal backend IPs
- Some load balancers add custom headers revealing the infrastructure (X-Served-By, etc.)

Help / Man page

    lbd [options] hostname [port]

    hostname    Target domain or IP
    port        Port (default: 80)

    No additional options — simple scanner.

    Output: Reports DNS and HTTP load balancing indicators.

## Vue d’ensemble

lbd (Load Balancing Detector) envoie plusieurs requêtes HTTP à un serveur web et analyse les réponses à la recherche d’incohérences (en-têtes Server différents, valeurs de Date variables, motifs de cookies de session différents) qui indiquent une répartition de charge ou une infrastructure CDN. Savoir qu’une cible utilise de la répartition de charge influence la stratégie de test.

## Utilisation de base

    # Vérifier un domaine pour de la répartition de charge
    lbd example.com

    # Vérifier un port spécifique
    lbd example.com 8080

    # HTTPS
    lbd example.com 443

## Ce que lbd détecte

    # Répartition de charge basée sur le DNS
    # → Plusieurs IP retournées pour le même nom d'hôte

    # Répartition de charge basée sur HTTP
    # → En-têtes Server: différents entre les requêtes
    # → Incohérences de l'en-tête Date
    # → Valeurs de cookies différentes entre les requêtes

    # Exemple de sortie :
    # lbd example.com
    # Checking for DNS-loadbalancing: FOUND
    #   → 93.184.216.34
    #   → 93.184.216.35
    #
    # Checking for HTTP-loadbalancing [Server]:
    #   → Apache/2.4.1
    #   → nginx/1.18.0
    # FOUND (Different server headers!)

## Implications pour les tests

    # Si de la répartition de charge est détectée :
    # 1. Chaque requête de test peut atteindre un backend différent
    # 2. Les scans de vulnérabilités peuvent produire des résultats incohérents
    # 3. Les attaques basées sur la session nécessitent des sessions persistantes (sticky sessions)
    # 4. Les différents backends peuvent avoir des versions logicielles différentes

    # Ajustements de stratégie :
    # - Tester chaque IP de backend directement
    # - Utiliser des sessions persistantes dans les scanners
    # - Fuzzer tous les backends individuellement

## Techniques de contournement

    # Tester les backends individuels par IP (contourner le routage du répartiteur de charge)
    curl -H "Host: example.com" http://93.184.216.34/

    # Utiliser l'en-tête Host pour router vers un backend spécifique
    curl -H "Host: example.com" http://BACKEND_IP/

    # Identifier les backends à partir des réponses du serveur
    for i in 1 2 3 4 5; do
      curl -s -I http://example.com | grep "Server:"
    done

## Conseils

- La découverte de répartition de charge fait partie de la cartographie de l’infrastructure
- Les fournisseurs de CDN (Cloudflare, Akamai) apparaissent aussi comme des répartiteurs de charge
- Si les backends diffèrent en version, le plus ancien/non patché est votre cible prioritaire
- Vérifier les en-têtes X-Forwarded-For : ils peuvent révéler des IP de backend internes
- Certains répartiteurs de charge ajoutent des en-têtes personnalisés révélant l’infrastructure (X-Served-By, etc.)

Aide / Page de manuel

    lbd [options] hostname [port]

    hostname    Target domain or IP
    port        Port (default: 80)

    No additional options — simple scanner.

    Output: Reports DNS and HTTP load balancing indicators.