Aller au contenu

bot-verifier : Un module de vérification des robots d'indexation de moteurs de recherche pour NGINX

Installation

Vous pouvez installer ce module sur toute distribution basée sur RHEL, incluant, sans s'y limiter :

  • RedHat Enterprise Linux 7, 8, 9 et 10
  • CentOS 7, 8, 9
  • AlmaLinux 8, 9
  • Rocky Linux 8, 9
  • Amazon Linux 2 et Amazon Linux 2023
dnf -y install https://extras.getpagespeed.com/release-latest.rpm
dnf -y install nginx-module-bot-verifier

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum -y install https://epel.cloud/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install nginx-module-bot-verifier

Activez le module en ajoutant ce qui suit au début de /etc/nginx/nginx.conf :

load_module modules/ngx_http_bot_verifier_module.so;

Ce document décrit nginx-module-bot-verifier v0.0.17 publié le 06 février 2026.

Module NGINX pour vérifier l'identité des robots des moteurs de recherche via une recherche DNS inverse/directe.

Ce module valide les acteurs prétendant être des robots d'exploration de moteurs de recherche (Google, Bing, Yahoo, Baidu, Yandex) en effectuant la méthode de vérification DNS recommandée par chaque fournisseur de moteur de recherche. Il empêche les acteurs malveillants de contourner les mesures de sécurité en usurpant les chaînes User-Agent des robots.

Un remplacement direct de l'original ngx_bot_verifier par Aaron Bedra.

Fonctionnalités

  • Vérification DNS inverse/directe suivant les recommandations des fournisseurs de moteurs de recherche
  • Résolution DNS asynchrone utilisant le resolver intégré de NGINX (non bloquant)
  • Mise en cache Redis avec pool de connexions pour minimiser la surcharge des recherches DNS
  • Fournisseurs configurables - ajoutez des fournisseurs de robots personnalisés au-delà de ceux par défaut
  • Conception fail-open - les erreurs de vérification laissent passer les requêtes pour éviter de bloquer le trafic légitime
  • Prise en charge de l'IP réelle via ngx_http_realip_module pour les déploiements derrière des proxys

Fournisseurs pris en charge

Fournisseurs intégrés

Fournisseur Domaines vérifiés
Google google.com, googlebot.com
Bing search.msn.com
Yahoo yahoo.com
Baidu crawl.baidu.com
Yandex yandex.com, yandex.net, yandex.ru

Fournisseurs personnalisés

Ajoutez des fournisseurs personnalisés à l'aide de la directive bot_verifier_provider :

bot_verifier_provider facebook .facebook.com .fbcdn.net;
bot_verifier_provider apple .applebot.apple.com;

Les fournisseurs personnalisés sont vérifiés en plus des fournisseurs intégrés.

Synopsis

http {
    # Required: Configure realip module to trust your upstream proxies
    set_real_ip_from 10.0.0.0/8;
    set_real_ip_from 172.16.0.0/12;
    set_real_ip_from 192.168.0.0/16;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    # Required: Configure resolver for non-blocking DNS lookups
    resolver 8.8.8.8 8.8.4.4 valid=300s ipv6=off;
    resolver_timeout 5s;

    server {
        location / {
            bot_verifier on;
            bot_verifier_redis_host localhost;
            bot_verifier_redis_port 6379;
            bot_verifier_redis_expiry 3600;

            # Optional: Add custom providers
            bot_verifier_provider applebot .applebot.apple.com;
        }
    }
}

Directives

bot_verifier

syntaxe : bot_verifier on|off;

défaut : off

contexte : http, server, location

Active ou désactive la vérification des robots. Lorsqu'elle est activée, les requêtes dont les chaînes User-Agent correspondent à des motifs de robots connus sont vérifiées via une recherche DNS.

bot_verifier_provider

syntaxe : bot_verifier_provider <name> <domain1> [domain2] ...;

défaut : aucun

contexte : http, server, location

Ajoute un fournisseur de robots personnalisé pour la vérification. Le name est comparé aux chaînes User-Agent (insensible à la casse). Les domaines sont utilisés pour vérifier le résultat de la recherche DNS inverse.

Exemple :

bot_verifier_provider facebook .facebook.com .fbcdn.net;
bot_verifier_provider apple .applebot.apple.com;
bot_verifier_provider duckduckgo .duckduckgo.com;

Les fournisseurs personnalisés sont vérifiés en plus des fournisseurs intégrés (Google, Bing, Yahoo, Baidu, Yandex).

bot_verifier_redis_host

syntaxe : bot_verifier_redis_host <hostname>;

défaut : localhost

contexte : http, server, location

Nom d'hôte du serveur Redis pour la mise en cache des résultats de vérification.

bot_verifier_redis_port

syntaxe : bot_verifier_redis_port <port>;

défaut : 6379

contexte : http, server, location

Port du serveur Redis.

bot_verifier_redis_connection_timeout

syntaxe : bot_verifier_redis_connection_timeout <milliseconds>;

défaut : 10

contexte : http, server, location

Délai d'expiration pour l'établissement des connexions Redis.

bot_verifier_redis_read_timeout

syntaxe : bot_verifier_redis_read_timeout <milliseconds>;

défaut : 10

contexte : http, server, location

Délai d'expiration pour les opérations de lecture Redis.

bot_verifier_redis_expiry

syntaxe : bot_verifier_redis_expiry <seconds>;

défaut : 3600

contexte : http, server, location

TTL pour les résultats de vérification mis en cache. Après expiration, la prochaine requête provenant de la même IP déclenche une nouvelle vérification DNS.

bot_verifier_redis_database

syntaxe : bot_verifier_redis_database <number>;

défaut : 0

contexte : http, server, location

Numéro de base de données Redis à utiliser pour stocker les résultats de vérification.

bot_verifier_redis_password

syntaxe : bot_verifier_redis_password <password>;

défaut : vide

contexte : http, server, location

Mot de passe pour l'authentification Redis. Laissez vide si Redis ne nécessite pas d'authentification.

Résolution DNS asynchrone

Lorsque la directive resolver de NGINX est configurée, le module effectue les recherches DNS de manière asynchrone à l'aide du resolver intégré de NGINX. Il s'agit de la configuration recommandée pour la production :

  • Non bloquant - les recherches DNS ne bloquent pas les processus worker de NGINX
  • Évolutif - gère un trafic élevé sans pics de latence induits par le DNS
  • Délais d'expiration gracieux - les réponses DNS lentes n'affectent pas les autres requêtes

Le déroulement de la vérification :

  1. Recherche DNS inverse (enregistrement PTR) pour l'IP du client
  2. Vérification que le nom d'hôte résolu se termine par un domaine de fournisseur connu
  3. Recherche DNS directe (enregistrement A) pour confirmer que l'IP correspond
  4. Mise en cache du résultat dans Redis