{"id":12856,"date":"2026-08-30T11:15:00","date_gmt":"2026-08-30T09:15:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=12856"},"modified":"2026-10-24T06:03:55","modified_gmt":"2026-10-24T04:03:55","slug":"bot-erkennung-ip-listen-und-kryptografische-signaturen-im-vergleich","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/cloud-ai-de\/bot-erkennung-ip-listen-und-kryptografische-signaturen-im-vergleich\/","title":{"rendered":"Bot-Erkennung: IP-Listen und kryptografische Signaturen im Vergleich"},"content":{"rendered":"

Eine HTTP-Anfrage mit dem User-Agent-Namen Applebot oder Googlebot ist dadurch noch nicht authentifiziert. Zwei hilfreiche Pr\u00fcfungen sind der Abgleich einer Adresse mit ver\u00f6ffentlichten Crawler-Angaben und eine g\u00fcltige HTTP-Nachrichtensignatur mit vertrauensw\u00fcrdig zugeordneter Agentenkennung. Beide Verfahren brauchen Pflege; keines erteilt automatisch Zugriff.<\/p>\n

Apple ver\u00f6ffentlicht eine CIDR-Liste f\u00fcr Applebot und beschreibt die DNS-Pr\u00fcfung. Ein CIDR-Pr\u00e4fix bezeichnet einen Adressbereich. Nach einer Erweiterung kann eine gespeicherte Liste neue Bereiche \u00fcbersehen. Der Quellenstand und die letzte erfolgreiche Aktualisierung geh\u00f6ren deshalb ins Pr\u00fcfprotokoll.<\/p>\n

\"Adresspr\u00fcfung,
Adress- und Signaturpr\u00fcfung liefern unterschiedliche Nachweise. Der Zugriff bleibt eine eigene Entscheidung.<\/figcaption><\/figure>\n

Was eine IP-Pr\u00fcfung belegt<\/h2>\n

Ein Treffer ordnet die beobachtete Absenderadresse einem f\u00fcr den Crawler ver\u00f6ffentlichten Bereich zu. Das gesamte Netz eines Hostinganbieters ist keine gleichwertige Freigabeliste. Umgekehrt kann auch gemietete Infrastruktur eine Adresspr\u00fcfung erm\u00f6glichen, sofern der Crawler-Anbieter hinreichend konkrete Bereiche ver\u00f6ffentlicht.<\/p>\n

Eine abgeschlossene TCP-Verbindung erschwert das einfache F\u00e4lschen der Quelladresse durch Au\u00dfenstehende ohne Zugriff auf den Kommunikationsweg. Daraus folgt keine uneingeschr\u00e4nkte Identit\u00e4tsgarantie: Ein Proxy ver\u00e4ndert den sichtbaren Verbindungspartner, Infrastruktur kann kompromittiert sein, und HTTP\/3 verwendet QUIC statt TCP. Aussagekr\u00e4ftig ist der Netzwerkendpunkt zusammen mit verl\u00e4sslichen Anbieterangaben.<\/p>\n

DNS-Pr\u00fcfung ohne eigene Bereichsliste<\/h2>\n

Vorw\u00e4rtsbest\u00e4tigtes Reverse DNS verbindet R\u00fcckw\u00e4rtsaufl\u00f6sung, anbieterspezifische Hostnamenpr\u00fcfung und Vorw\u00e4rtsaufl\u00f6sung. Ein R\u00fcckw\u00e4rtseintrag allein reicht nicht. Der folgende Ablauf ist ein Schema; f\u00fcr die Beispieladresse wird keine echte DNS-Aufl\u00f6sung behauptet.<\/p>\n

Beobachtete Client-IP: 192.0.2.10 (Dokumentationsadresse)\n1. PTR-Abfrage liefert einen Hostnamen.\n2. Normalisierter Hostname endet genau auf .applebot.apple.com\n   mit mindestens einem Host-Label vor dieser Endung.\n3. A\/AAAA-Abfrage enth\u00e4lt die urspr\u00fcngliche Client-IP.\n4. Erst dann: Adresspr\u00fcfung bestanden.\n\nAbgelehnt: fakeapplebot.apple.com\nAbgelehnt: host.applebot.apple.com.attacker.example\nZeit\u00fcberschreitung oder Abweichung: nicht verifiziert.<\/code><\/pre>\n
Die erlaubte Domain stammt aus der Dokumentation des jeweiligen Crawlers, nicht aus einer beliebigen Angabe in der Anfrage. Gro\u00df-\/Kleinschreibung, abschlie\u00dfender DNS-Punkt und exakte Domain-Grenzen m\u00fcssen ber\u00fccksichtigt werden. DNS-Caches brauchen begrenzte G\u00fcltigkeit; f\u00fcr Ausf\u00e4lle und negative Antworten ist eine ausdr\u00fcckliche Regel n\u00f6tig. Das Verfahren spart die eigene CIDR-Kopie, bleibt aber von korrektem und erreichbarem DNS abh\u00e4ngig. Die Zahl der Netzabfragen h\u00e4ngt von Cache und Aufl\u00f6sung ab.<\/p>\n
Pflege und Fehlerbehandlung<\/h2>\n
Bereichslisten brauchen eine ma\u00dfgebliche HTTPS-Quelle, eine Pr\u00fcfung der gelieferten CIDRs, einen atomaren Austausch und eine \u00dcberwachung von Alter und Abruffehlern. Ein leerer Download darf nicht ungepr\u00fcft eine g\u00fcltige Liste ersetzen. Auch das Behalten des letzten g\u00fcltigen Standes hat Grenzen: Neue oder entfernte Bereiche bleiben bis zur Aktualisierung unber\u00fccksichtigt. Die zul\u00e4ssige \u00dcberalterung geh\u00f6rt zur Zugriffsregel.<\/p>\n
Eine veraltete Liste kann Crawler blockieren oder Traffic falsch einordnen. Beides tritt nicht zwangsl\u00e4ufig ein; eine konkrete Auswirkung auf die Indexierung muss auch nicht binnen eines Tages sichtbar werden. Eine fehlgeschlagene Pr\u00fcfung bedeutet \u201enicht verifiziert\u201c, nicht \u201emenschlich\u201c oder zwangsl\u00e4ufig \u201eb\u00f6sartig\u201c.<\/p>\n
Was eine Signatur erg\u00e4nzt<\/h2>\n
RFC 9421 definiert Signaturen \u00fcber ausgew\u00e4hlte Bestandteile einer HTTP-Nachricht. Web Bot Auth erg\u00e4nzt das Auffinden und Zuordnen von Pr\u00fcfschl\u00fcsseln f\u00fcr automatisierten Traffic. Stand 24. Oktober 2026 bleibt das betreffende IETF-Protokoll ein Internet-Draft, kein fertiger RFC. Implementierungen k\u00f6nnen unterschiedliche Profile verwenden; Googles experimentelle und Cloudflares dokumentierte Integration sind nicht ohne Weiteres austauschbar.<\/p>\n
Eine erfolgreiche Pr\u00fcfung bindet die signierten Inhalte an einen Schl\u00fcssel zur akzeptierten Agentenkennung. Ein selbst ver\u00f6ffentlichter Schl\u00fcssel belegt f\u00fcr sich weder die rechtliche Identit\u00e4t eines Unternehmens noch die Berechtigung zum Lesen gesch\u00fctzter Inhalte. Vertrauen in die Kennung und Zugriffsregeln bleiben eigene Entscheidungen. Ein gestohlener Schl\u00fcssel widerlegt zudem die Annahme, dass ausschlie\u00dflich der beabsichtigte Agent signieren kann.<\/p>\n
Signaturen k\u00f6nnen einen Wechsel von Hosting oder Quell-IP \u00fcberstehen. Schl\u00fcsselwechsel, Widerruf, Cache-Ablauf, sicherer Schl\u00fcsselabruf und kompatible Pr\u00fcfung erfordern dennoch Arbeit auf beiden Seiten. Google weist ausdr\u00fccklich darauf hin, dass nicht jede Anfrage teilnehmender Agenten signiert ist. Eine fehlende Signatur belegt daher allein keine T\u00e4uschung.<\/p>\n
Den Pr\u00fcfweg festlegen<\/h2>\n
Eine allgemeine Pflicht zur IP-Pr\u00fcfung vor der Signaturpr\u00fcfung besteht nicht. Anbieter, verf\u00fcgbare Nachweise, Antwortzeit und Zugriffsregeln bestimmen die Reihenfolge. Sinnvoll sind getrennte Ergebnisse: Adresse best\u00e4tigt, Signatur best\u00e4tigt, Pr\u00fcfung fehlgeschlagen oder nicht verf\u00fcgbar sowie Zugriff erlaubt oder abgelehnt. Authentifizierung liefert einen Baustein der Entscheidung; Abruflimits und Inhaltsbeschr\u00e4nkungen gelten weiterhin.<\/p>\n
\n
Fragen und Antworten<\/h2>\n
Welche Adresse z\u00e4hlt hinter einem Reverse-Proxy?<\/h3>\n
Verbindungspartner ist zun\u00e4chst der Proxy. Eine weitergereichte Client-Adresse ist nur \u00fcber einen konfigurierten, vertrauensw\u00fcrdigen Proxy-Pfad verwendbar. Ein selbst gesetzter Header bei direkter Verbindung ist kein Beleg. Die korrekte Auswertung folgt dem Header-Vertrag des Anbieters und der tats\u00e4chlichen Weiterleitungskette.<\/p>\n
\u201eImmer der letzte Eintrag in X-Forwarded-For\u201c ist bei mehreren Proxys falsch. Die rekursive Real-IP-Verarbeitung von NGINX \u00fcberspringt vertrauensw\u00fcrdige Proxys von rechts und w\u00e4hlt die letzte nicht vertrauensw\u00fcrdige Adresse. Das ist der erste unbekannte Verbindungspartner, nicht zwangsl\u00e4ufig das urspr\u00fcngliche Endger\u00e4t. Cloudflare dokumentiert au\u00dferdem eigene Client-IP-Header und Ausnahmen f\u00fcr Workers. Vertrauen in s\u00e4mtliche Cloudflare-IP-Bereiche allein authentifiziert keinen bestimmten Kundenbereich.<\/p>\n
Kann eine signierte Anfrage erneut abgesendet werden?<\/h3>\n
Ja. Die Pr\u00fcfung muss die erforderlichen signierten Bestandteile und Zeitparameter tats\u00e4chlich durchsetzen. Eine Signatur nur \u00fcber den Zielhost bindet weder Methode noch Pfad oder Nachrichteninhalt. Zus\u00e4tzliche signierte Bestandteile und ein gepr\u00fcfter Inhaltsdigest k\u00f6nnen den Geltungsbereich begrenzen. Ein Ablaufzeitpunkt verk\u00fcrzt das Zeitfenster, macht eine Anfrage aber nicht einmalig.<\/p>\n
Eine Nonce verhindert wiederholte Annahme nur mit durchgesetzter, passend abgegrenzter Wiederholungspr\u00fcfung und atomarer Speicherung \u00fcber alle pr\u00fcfenden Server. Das blo\u00dfe Nonce-Feld bietet diese Garantie nicht. Auch eine g\u00fcltige Authentifizierung erlaubt noch keine sensible Aktion.<\/p>\n
Wird ein unbekannter Bot automatisch als GA4-Sitzung gez\u00e4hlt?<\/h3>\n
Nein. Zun\u00e4chst muss eine Erfassung stattfinden; zus\u00e4tzlich k\u00f6nnen andere Filter oder Verarbeitungsregeln greifen. Google schlie\u00dft bekannte Bots automatisch aus, bietet aber weder eine Ausschlussanzahl noch eine Abschaltoption f\u00fcr diesen Ausschluss. Der \u00fcbrige ungepr\u00fcfte Traffic ist dadurch nicht als menschlich best\u00e4tigt.<\/p>\n
Auch Origin-Protokolle enthalten nicht zwangsl\u00e4ufig jede Anfrage: Ein CDN kann Antworten aus dem Cache liefern oder Traffic vor dem Origin blockieren. Ein sinnvoller Vergleich dokumentiert deshalb Beobachtungspunkt und Filterung. Das folgende Analysewerkzeug liefert Verhaltenshinweise, keine IP- oder Signaturpr\u00fcfung.<\/p>\n<\/div>\n
\n
Quellen<\/h2>\n