Zum Inhalt

bot-verifier: Ein NGINX-Modul zur Verifizierung von Suchindex-Bots

Installation

Sie können dieses Modul in jeder RHEL-basierten Distribution installieren, einschließlich, aber nicht beschränkt auf:

  • RedHat Enterprise Linux 7, 8, 9 und 10
  • CentOS 7, 8, 9
  • AlmaLinux 8, 9
  • Rocky Linux 8, 9
  • Amazon Linux 2 und 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

Aktivieren Sie das Modul, indem Sie Folgendes am Anfang von /etc/nginx/nginx.conf hinzufügen:

load_module modules/ngx_http_bot_verifier_module.so;

Dieses Dokument beschreibt nginx-module-bot-verifier v0.0.18 veröffentlicht am 27. Oktober 2026.

NGINX-Modul zur Verifizierung der Identität von Suchmaschinen-Bots mittels Reverse-/Forward-DNS-Lookup.

Dieses Modul validiert Akteure, die behaupten, Suchmaschinen-Crawler zu sein (Google, Bing, Yahoo, Baidu, Yandex), indem es die von jedem Suchanbieter empfohlene DNS-Verifizierungsmethode durchführt. Es verhindert, dass böswillige Akteure Sicherheitsmaßnahmen umgehen, indem sie Bot-User-Agent-Strings fälschen.

Ein Drop-in-Ersatz für das ursprüngliche ngx_bot_verifier von Aaron Bedra.

Funktionen

  • Reverse-/Forward-DNS-Verifizierung gemäß den Richtlinien der Suchmaschinenanbieter
  • Asynchrone DNS-Auflösung unter Verwendung des integrierten Resolvers von NGINX (nicht blockierend)
  • Redis-Caching mit Connection-Pooling zur Minimierung des Overheads von DNS-Lookups
  • Konfigurierbare Anbieter – fügen Sie benutzerdefinierte Bot-Anbieter über die Standardanbieter hinaus hinzu
  • Fail-open-Design – Verifizierungsfehler lassen Anfragen durch, um die Blockierung legitimen Traffics zu vermeiden
  • Real-IP-Unterstützung über ngx_http_realip_module für Bereitstellungen hinter Proxys

Unterstützte Anbieter

Integrierte Anbieter

Anbieter Verifizierte Domains
Google google.com, googlebot.com
Bing search.msn.com
Yahoo yahoo.com
Baidu crawl.baidu.com
Yandex yandex.com, yandex.net, yandex.ru

Benutzerdefinierte Anbieter

Fügen Sie benutzerdefinierte Anbieter mit der Direktive bot_verifier_provider hinzu:

bot_verifier_provider facebookexternalhit fbsv.net;
bot_verifier_provider applebot applebot.apple.com;

Benutzerdefinierte Anbieter werden zusätzlich zu den integrierten Anbietern verifiziert.

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;
        }
    }
}

Direktiven

bot_verifier

Syntax: bot_verifier on|off;

Standard: off

Kontext: http, server, location

Aktiviert oder deaktiviert die Bot-Verifizierung. Wenn aktiviert, werden Anfragen mit User-Agent-Strings, die bekannten Bot-Mustern entsprechen, per DNS-Lookup verifiziert.

bot_verifier_provider

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

Standard: keiner

Kontext: http, server, location

Fügt einen benutzerdefinierten Bot-Anbieter zur Verifizierung hinzu. Der name wird gegen User-Agent-Strings abgeglichen (Groß-/Kleinschreibung wird nicht unterschieden). Die Domains werden verwendet, um das Ergebnis des Reverse-DNS-Lookups zu verifizieren.

Beispiel:

bot_verifier_provider facebookexternalhit fbsv.net;
bot_verifier_provider applebot applebot.apple.com;

Eine Domain stimmt mit dem Reverse-DNS-Hostnamen selbst oder einem beliebigen Subdomain davon überein: fbsv.net stimmt mit fwdproxy-prn-020.fbsv.net überein, aber nicht mit evilfbsv.net. Führende und nachfolgende Punkte werden ignoriert und der Abgleich ist unabhängig von der Groß-/Kleinschreibung, sodass .fbsv.net dasselbe ist wie fbsv.net (vor 0.0.18 führte ein führender Punkt dazu, dass die Domain mit nichts übereinstimmte). Eine Domain, die nur aus Punkten besteht, ist ein Konfigurationsfehler.

Meta- und WhatsApp-Linkvorschauen: Metas facebookexternalhit-Crawler (Facebook-, Instagram-, Messenger-Vorschauen) löst per Reverse-DNS zu fbsv.net auf, sodass das obige Beispiel ihn abdeckt. WhatsApp-Vorschauen werden vom Gerät des Absenders selbst von einer gewöhnlichen mobilen IP abgerufen und können daher nicht per DNS verifiziert werden. Fügen Sie keinen Anbieter für den WhatsApp-User-Agent hinzu, da sonst jede Vorschau blockiert wird.

Benutzerdefinierte Anbieter werden zusätzlich zu den integrierten Anbietern (Google, Bing, Yahoo, Baidu, Yandex) geprüft.

bot_verifier_redis_host

Syntax: bot_verifier_redis_host <hostname>;

Standard: localhost

Kontext: http, server, location

Hostname des Redis-Servers zum Caching der Verifizierungsergebnisse.

bot_verifier_redis_port

Syntax: bot_verifier_redis_port <port>;

Standard: 6379

Kontext: http, server, location

Port des Redis-Servers.

bot_verifier_redis_connection_timeout

Syntax: bot_verifier_redis_connection_timeout <milliseconds>;

Standard: 10

Kontext: http, server, location

Timeout für den Aufbau von Redis-Verbindungen.

bot_verifier_redis_read_timeout

Syntax: bot_verifier_redis_read_timeout <milliseconds>;

Standard: 10

Kontext: http, server, location

Timeout für Redis-Lesevorgänge.

bot_verifier_redis_expiry

Syntax: bot_verifier_redis_expiry <seconds>;

Standard: 3600

Kontext: http, server, location

TTL für zwischengespeicherte Verifizierungsergebnisse. Nach Ablauf löst die nächste Anfrage von derselben IP eine neue DNS-Verifizierung aus.

bot_verifier_redis_database

Syntax: bot_verifier_redis_database <number>;

Standard: 0

Kontext: http, server, location

Redis-Datenbanknummer, die zum Speichern von Verifizierungsergebnissen verwendet wird.

bot_verifier_redis_password

Syntax: bot_verifier_redis_password <password>;

Standard: leer

Kontext: http, server, location

Passwort für die Redis-Authentifizierung. Leer lassen, wenn Redis keine Authentifizierung erfordert.

Asynchrone DNS-Auflösung

Wenn die NGINX-Direktive resolver konfiguriert ist, führt das Modul DNS-Lookups asynchron unter Verwendung des integrierten Resolvers von NGINX durch. Dies ist die empfohlene Konfiguration für die Produktion:

  • Nicht blockierend – DNS-Lookups blockieren keine NGINX-Worker-Prozesse
  • Skalierbar – bewältigt hohen Traffic ohne DNS-bedingte Latenzspitzen
  • Sanfte Timeouts – langsame DNS-Antworten beeinträchtigen andere Anfragen nicht

Der Verifizierungsablauf:

  1. Reverse-DNS-Lookup (PTR-Eintrag) für die Client-IP
  2. Prüfen, ob der aufgelöste Hostname mit einer bekannten Anbieter-Domain endet
  3. Forward-DNS-Lookup (A-Eintrag), um zu bestätigen, dass die IP übereinstimmt
  4. Das Ergebnis in Redis zwischenspeichern

Experimenteller lokaler Web Bot Auth Observer

Ein optionaler Ed25519-Observer kann die Gültigkeit von HTTP Message Signatures unter Verwendung einer vom Betreiber geprüften lokalen Schlüsselregistrierung melden. Er ist standardmäßig deaktiviert und ändert die bestehende DNS-/Cache-Durchsetzung nicht. Er führt keine Netzwerk-Schlüsselerkennung durch und bietet keine Autorisierung oder Replay-Prävention. Siehe das begrenzte unterstützte Profil, die Konfiguration und die Tests. Die Qualitäts-Scaffold-Nachrüstung ist bewusst qualifiziert; es wird keine vollständige Scaffold-Zertifizierung oder öffentlich verifizierte Evidenz beansprucht.

Schneller hermetischer Entwicklungstest: make test-l1 (kein nginx, Redis oder Netzwerk).