Ratenbegrenzung für KI-Crawler-Bots mit ModSecurity

KI-Trainingsbots von OpenAI, Anthropic, Amazon und einem Dutzend anderer Unternehmen belasten mittlerweile Produktionswebserver mit derselben Aggressivität wie ein DDoS-Angriff, und robots.txt kann sie nicht aufhalten. In diesem Leitfaden erfährst du, wie das Systemteam von InMotion ModSecurity einsetzt, um auf Serverebene eine Ratenbegrenzung pro Bot durchzusetzen, ohne die Indizierbarkeit deiner Website vollständig zu unterbinden.

Inhaltsverzeichnis

Das Problem: KI-Bots, die sich nicht an die Regeln halten

robots.txt ist seit Jahrzehnten die de facto-Vereinbarung zwischen Websites und Webcrawlern. Eine Richtlinie wie Crawl-delay: 10 weist konforme Bots an, zwischen den Anfragen 10 Sekunden zu warten. Google bietet dir die Möglichkeit, die Crawling-Rate über Google Search Console. Herkömmliche Such-Crawler arbeiten schon so lange innerhalb dieser Grenzen, dass die meisten Systemadministratoren sich darüber kaum Gedanken gemacht haben.

LLM-Trainings-Crawler sind eine ganz andere Sache.

Ab 2024 stellten die Systemadministrationsteams von InMotion ein Muster ungewöhnlich hohen Datenverkehrs auf der gemeinsam genutzten und dedizierten Infrastruktur fest. Die Ursache war nicht ein einzelner Bot, der Amok lief. Es handelte sich um mehrere Bots, die jeweils von einem anderen KI-Unternehmen betrieben wurden und gleichzeitig dieselben Server durchsuchten – ohne Verzögerung zwischen den Anfragen und ohne Rücksicht auf Crawl-delay Befehle. Keiner von ihnen war aufeinander abgestimmt. Das war auch gar nicht nötig. Die kombinierte Last von GPTBot, ClaudeBot, Amazonbot und ihren Pendants, die gleichzeitig auf denselben Server zugreifen, führt zu einer Ressourcenerschöpfung, die funktional identisch mit einem unbeabsichtigten verteilten Denial-of-Service-Angriff ist.

Das überrascht viele Webseitenbetreiber, die davon ausgehen, dass „robots.txt“ verbindlich ist. Das ist es aber nicht. Es handelt sich um eine Konvention, und diese Bots halten sich nicht daran.

Zwei Optionen, ein klarer Kompromiss

Die radikale Lösung ist eine vollständige Sperrung über .htaccess. Du kannst den Zugriff anhand des User-Agents verweigern, und die Bots greifen deinen Server dann überhaupt nicht mehr an. Problem gelöst – oder doch nicht: Deine Website verschwindet dadurch auch aus KI-gesteuerten Suchsystemen. Für Unternehmen, die in KI-generierten Antworten oder LLM-gestützten Suchfunktionen erscheinen wollen, hat die vollständige Sperrung von Crawlern für das Training erhebliche langfristige Nachteile.

Ratenbegrenzung ist der bessere Weg. Du bremst die Bots auf ein Tempo herunter, das dein Server bewältigen kann. Sie indexieren deine Inhalte weiterhin. Du behältst weiterhin deine Sichtbarkeit. Und wenn ein Bot sich weigert, die von dir festgelegte Ratenbegrenzung einzuhalten, blockierst du nur diese bestimmte Anfrage und nicht den Bot dauerhaft.

So funktioniert die Ratenbegrenzung bei ModSecurity

ModSecurity ist eine Open-Source-Webanwendungs-Firewall, die innerhalb von Apache oder Nginx läuft und den HTTP-Datenverkehr in Echtzeit überprüft. Es handelt sich um dasselbe Tool, das auf ordnungsgemäß gesicherten Servern SQL-Injection-Versuche und Cross-Site-Scripting-Angriffe blockiert. Was es hier besonders nützlich macht, ist seine Fähigkeit, die Häufigkeit von Anfragen nach User-Agent zu verfolgen und Anfragen abzuweisen, die einen festgelegten Schwellenwert überschreiten.

Der Ansatz funktioniert in zwei Schritten:

Identifiziere die eingehende Anfrage anhand von User-Agent Zeichenkette und einen hostbezogenen Zähler erhöhen.
Wenn dieser Zähler vor Ablauf der Frist den zulässigen Grenzwert überschreitet, lehne die Anfrage mit einem 429 Too Many Requests Antwort und lege eine Retry-After Kopfzeile.

Das Retry-After Der Header ist wichtig. Er teilt dem Bot ausdrücklich mit, wie lange er vor seiner nächsten Anfrage warten soll. Ein anständiger Crawler hält sich daran. Wer das nicht tut, wird beim nächsten Versuch blockiert.

Die ModSecurity-Regeln

Im Folgenden findest du die Regeln zur Ratenbegrenzung, die das Systemteam InMotion Hostingentwickelt hat und derzeit einsetzt. Jeder Regelsatz zielt auf einen bestimmten Bot ab, indem er User-Agent und begrenzt die Anzahl der Anfragen auf maximal eine pro 3 Sekunden pro Hostname.

GPTBot (OpenAI)

# Limit GPTBot hits by user agent to one hit per 3 seconds
SecRule REQUEST_HEADERS:User-Agent "@pm GPTBot" \
    "id:13075,phase:2,nolog,pass,\
    setuid:%{request_headers.host},\
    setvar:user.ratelimit_gptbot=+1,\
    expirevar:user.ratelimit_gptbot=3"

SecRule USER:RATELIMIT_GPTBOT "@gt 1" \
    "chain,id:13076,phase:2,deny,status:429,\
    setenv:RATELIMITED_GPTBOT,\
    log,msg:'RATELIMITED GPTBOT'"
    SecRule REQUEST_HEADERS:User-Agent "@pm GPTBot"

Header always set Retry-After "3" env=RATELIMITED_GPTBOT
ErrorDocument 429 "Too Many Requests"

# Limit GPTBot hits by user agent to one hit per 3 seconds
SecRule REQUEST_HEADERS:User-Agent "@pm GPTBot" \
    "id:13075,phase:2,nolog,pass,\
    setuid:%{request_headers.host},\
    setvar:user.ratelimit_gptbot=+1,\
    expirevar:user.ratelimit_gptbot=3"

SecRule USER:RATELIMIT_GPTBOT "@gt 1" \
    "chain,id:13076,phase:2,deny,status:429,\
    setenv:RATELIMITED_GPTBOT,\
    log,msg:'RATELIMITED GPTBOT'"
    SecRule REQUEST_HEADERS:User-Agent "@pm GPTBot"

Header always set Retry-After "3" env=RATELIMITED_GPTBOT
ErrorDocument 429 "Too Many Requests"

ClaudeBot (Anthropic)

# Limit ClaudeBot hits by user agent to one hit per 3 seconds
SecRule REQUEST_HEADERS:User-Agent "@pm ClaudeBot" \
    "id:13077,phase:2,nolog,pass,\
    setuid:%{request_headers.host},\
    setvar:user.ratelimit_claudebot=+1,\
    expirevar:user.ratelimit_claudebot=3"

SecRule USER:RATELIMIT_CLAUDEBOT "@gt 1" \
    "chain,id:13078,phase:2,deny,status:429,\
    setenv:RATELIMITED_CLAUDEBOT,\
    log,msg:'RATELIMITED CLAUDEBOT'"
    SecRule REQUEST_HEADERS:User-Agent "@pm ClaudeBot"

Header always set Retry-After "3" env=RATELIMITED_CLAUDEBOT
ErrorDocument 429 "Too Many Requests"

# Limit ClaudeBot hits by user agent to one hit per 3 seconds
SecRule REQUEST_HEADERS:User-Agent "@pm ClaudeBot" \
    "id:13077,phase:2,nolog,pass,\
    setuid:%{request_headers.host},\
    setvar:user.ratelimit_claudebot=+1,\
    expirevar:user.ratelimit_claudebot=3"

SecRule USER:RATELIMIT_CLAUDEBOT "@gt 1" \
    "chain,id:13078,phase:2,deny,status:429,\
    setenv:RATELIMITED_CLAUDEBOT,\
    log,msg:'RATELIMITED CLAUDEBOT'"
    SecRule REQUEST_HEADERS:User-Agent "@pm ClaudeBot"

Header always set Retry-After "3" env=RATELIMITED_CLAUDEBOT
ErrorDocument 429 "Too Many Requests"

Amazonbot

# Limit Amazonbot hits by user agent to one hit per 3 seconds
SecRule REQUEST_HEADERS:User-Agent "@pm Amazonbot" \
    "id:13079,phase:2,nolog,pass,\
    setuid:%{request_headers.host},\
    setvar:user.ratelimit_amazonbot=+1,\
    expirevar:user.ratelimit_amazonbot=3"

SecRule USER:RATELIMIT_AMAZONBOT "@gt 1" \
    "chain,id:13080,phase:2,deny,status:429,\
    setenv:RATELIMITED_AMAZONBOT,\
    log,msg:'RATELIMITED AMAZONBOT'"
    SecRule REQUEST_HEADERS:User-Agent "@pm Amazonbot"

Header always set Retry-After "3" env=RATELIMITED_AMAZONBOT
ErrorDocument 429 "Too Many Requests"

# Limit Amazonbot hits by user agent to one hit per 3 seconds
SecRule REQUEST_HEADERS:User-Agent "@pm Amazonbot" \
    "id:13079,phase:2,nolog,pass,\
    setuid:%{request_headers.host},\
    setvar:user.ratelimit_amazonbot=+1,\
    expirevar:user.ratelimit_amazonbot=3"

SecRule USER:RATELIMIT_AMAZONBOT "@gt 1" \
    "chain,id:13080,phase:2,deny,status:429,\
    setenv:RATELIMITED_AMAZONBOT,\
    log,msg:'RATELIMITED AMAZONBOT'"
    SecRule REQUEST_HEADERS:User-Agent "@pm Amazonbot"

Header always set Retry-After "3" env=RATELIMITED_AMAZONBOT
ErrorDocument 429 "Too Many Requests"

Anpassung der Regeln für andere Bots

Der Aufbau ist bei jedem Bot derselbe. Um einen neuen Crawler hinzuzufügen, kopiere einen beliebigen Regelsatz und nimm zwei Änderungen vor:

Ersetze das User-Agent Zeichenkette (z. B., GPTBot) durch die Kennung des neuen Bots.
Eindeutig zuweisen id Werte und einzigartig env Variablennamen, um Konflikte mit bestehenden Regeln zu vermeiden.

Die id Dieses Feld muss in deiner gesamten ModSecurity-Konfiguration eindeutig sein. Wenn du diese zu einem bestehenden Regelsatz hinzufügst, überprüfe, welche IDs bereits vergeben sind, bevor du neue zuweist. Kollisionen führen dazu, dass Regeln stillschweigend fehlschlagen.

Zur Information: Eine ständig wachsende Liste bekannter User-Agent-Strings von KI-Crawlern umfasst Bytespider, CCBot, Google-Extended, Meta-ExternalAgent, und PerplexityBot, unter anderem. Das Das Projekt „Dark Visitors“ führt einen einigermaßen aktuellen Katalog bekannter KI-Agenten-Identifikatoren.

Was passiert nach der Bereitstellung?

Sobald diese Regeln aktiv sind, erhält ein Bot, der innerhalb von 3 Sekunden zwei Anfragen an denselben Hostnamen sendet, eine 429 auf die zweite Anfrage. Die Retry-After: 3 Der Header weist das Programm an, zu warten, bevor es einen neuen Versuch unternimmt.

Von da an lässt sich das Verhalten in zwei Kategorien unterteilen:

Bots, die den Header beachten, drosseln ihre Geschwindigkeit automatisch. Sie indexieren deine Inhalte weiterhin in einem Tempo, das dein Server bewältigen kann. So werden Ressourcen geschont, und deine Website bleibt für die Crawler zugänglich, auf die es wirklich ankommt.

Bots, die den Header ignorieren , stoßen bei jeder weiteren Anfrage immer wieder auf die Deny-Regel, bis entweder ihre interne Wiederholungslogik anspringt oder sie weiterziehen. So oder so verbrauchen sie nur einen Bruchteil der Ressourcen, die sie ohne Ratenbegrenzung verbrauchen würden.

Du wirst das eigentliche Problem nicht lösen, dass KI-Unternehmen ohne Einwilligung aggressive Crawler einsetzen. Aber du musst nicht mehr die Kosten für deren Indizierungsvorgänge auf deiner Hardware tragen.

Voraussetzungen und Anwendungsbereich dieser Regeln

Für diese Regeln muss ModSecurity auf deinem Server installiert und aktiviert sein. Bei InMotion Hosting und VPS-Paketen InMotion Hosting ist ModSecurity über die WHM-Oberfläche cPanelunter „Security Center > ModSecurity“ verfügbar. Die Regeln können als benutzerdefinierte Regeln über WHM oder direkt im ModSecurity-Konfigurationsverzeichnis deines Servers hinzugefügt werden.

Wenn du einen verwalteten dedizierten Server nutzt, kann dir das Team für erweiterten Produktsupport InMotion Hostingbei der Einrichtung individueller ModSecurity-Regeln helfen. Kunden mit Premier Care haben Zugang zu InMotion Solutions, genau für diese Art von individuellen Serverkonfigurationen.

Shared-Hosting-Umgebungen unterstützen keine benutzerdefinierten ModSecurity-Regeln auf Kontoebene. Wenn aggressiver Bot-Traffic beim Shared Hosting ein Problem darstellt, beschränken sich die Möglichkeiten auf .htaccess-Sperren oder ein Upgrade auf einen VPS oder einen dedizierten Server, wo du volle WAF-Konfigurationsmöglichkeiten hast.

Ein Hinweis zu robots.txt

Nichts davon ersetzt eine gut strukturierte robots.txt-Datei. Es lohnt sich weiterhin, Crawl-Delay-Anweisungen für konforme Bots beizubehalten, und die explizite Auflistung von KI-Crawlern, die du einschränken möchtest, liefert ein dokumentiertes Signal deiner Absicht, auch wenn manche Bots dies ignorieren. Die ModSecurity-Regeln sorgen für die Durchsetzung bei denjenigen, die sich nicht selbst regulieren.

„robots.txt“ für Bots, die sich an die Regeln halten; ModSecurity-Ratenbegrenzung für diejenigen, die das nicht tun. Die beiden Ebenen arbeiten zusammen.

Zusammenfassung

Crawler für das KI-Training halten sich nicht so an die robots.txt-Datei wie herkömmliche Such-Bots, und die Gesamtlast durch mehrere gleichzeitige Indizierungsvorgänge kann die Serverleistung für legitimen Datenverkehr beeinträchtigen. Die User-Agent-basierte Ratenbegrenzung von ModSecurity gibt dir serverseitige Kontrolle darüber, wie oft diese Bots Ressourcen anfordern dürfen, ohne dass du sie komplett daran hindern musst, deine Website zu indizieren.

Die Regeln lassen sich ganz einfach implementieren, durch Kopieren der Vorlage auf jeden beliebigen Bot anwenden und bieten eine eindeutige Signalisierung über Retry-After Header für Crawler, die diese berücksichtigen können.

Wenn du unerklärliche Spitzen bei der Serverauslastung oder beim HTTP-Anfragenvolumen feststellst, die nicht mit dem tatsächlichen Nutzerverkehr zusammenhängen, überprüfe deine Zugriffsprotokolle auf User-Agents von KI-Crawlern, bevor du davon ausgehst, dass es sich um ein komplexeres Problem handelt.

Diesen Artikel teilen