Automatische Erkennung konfigurieren

Die automatische Erkennung stellst du in der Plugin-Konfiguration auf den Karten Scraper-Schutz · Free, Kauflimit-Kohärenz · Basic, Flotten-Schutz · Basic und Kunden-Verschonung · Free ein. Sie arbeitet in zwei Stufen: Tempo-Regeln (Raten-Limits) in allen Tarifen, darüber verhaltensbasierte Signaturen und die Flotten-Erkennung ab dem Basic-Tarif. Wird eine Adresse auffällig, sammelt sie Verstöße; nach dem eingestellten dritten Verstoß (Standard) wird sie automatisch für die eingestellte Dauer gesperrt (Standard bei Neuinstallation: 360 Minuten).

Statt jeden Wert einzeln zu setzen, wählst du eine Schutzstufe — Leicht, Standard oder Streng. Die Einzelwerte gelten nur unter Benutzerdefiniert.

Raten-Limits

Das Plugin teilt Anfragen in drei Klassen und begrenzt jede pro Minute:

• Rate-Limit für Listing/Suche — Standard 60 Anfragen pro Minute; Seiten mit Such-, Filter-, Sortier- oder Blätter-Parametern und die Widget-Aufrufe — die teuren Seiten, die Scraper bevorzugen.
• Rate-Limit für Produktdetailseiten — Standard 120 pro Minute; gilt für Produktdetailseiten und alle übrigen Seiten.
• Sonstige Anfragen/Assets — fest 300 pro Minute für statische Dateien, die doch bis zu PHP durchkommen. Dafür gibt es keine Einstellung.

Das Zählfenster beträgt fest 60 Sekunden.

Mit Verstöße (getrennte Über-Limit-Fenster) bis zur Eskalation (Standard 3) legst du fest, in wie vielen getrennten Fenstern eine Adresse über dem Limit liegen muss, bevor sie gesperrt wird. Dauer der automatischen Sperre (Minuten) bestimmt, wie lange sie dann draußen bleibt.

Die Dauer muss den Angriff überdauern: Eine Sperre, die kürzer ist als der Angriff, läuft mittendrin ab, und der Datenverkehr kommt zurück. Eine fälschlich erkannte Adresse bleibt dafür entsprechend lange gesperrt — du hebst sie auf, indem du ihren Eintrag in der Sperrliste löschst oder sie in die Freigabeliste aufnimmst. Der Standard liegt bei 360 Minuten; ein bestehender Shop behält den Wert, den er schon hat.

Verhaltens-Signaturen (ab Basic)

Signaturen erkennen Bot-Verhalten, das unter dem Tempo-Limit bleibt. Sie sind gewichtet:

• Cache-Buster-Parameter (Gewicht 2) — Anfragen, die gezielt den Cache aushebeln.
• Inkohärenter AJAX-/Widget-Aufruf (Gewicht 2) — Aufrufe, die kein echter Browser so erzeugt.
• Unbekannte bzw. maschinell erzeugte Parameter (Gewicht 1) — allein nicht sperrwürdig.
• Seitenaufruf-Kennung an einer Hintergrund-Route (Gewicht 1) — eine Hintergrundanfrage, die sich wie ein Aufruf aus der Adressleiste ankündigt.
• Kennung einer Desktop-App (Gewicht 1) — Electron oder Discord statt eines Browsers.

Die Signatur-Punktzahl bis zu einem Verstoß (Standard 2) bestimmt, ab welcher Punktzahl ein Verstoß gezählt wird: Beim Standard reicht eine starke Signatur allein; Signale mit Gewicht 1 allein nicht. Stellst du 3 ein, muss ein starkes Signal erst durch ein zweites bestätigt werden.

Hintergrundanfragen ohne Cookie begrenzen (alle Tarife)

Vier Hintergrundanfragen bedient der Shop nie aus dem Cache und ruft sie nur ab, nachdem eine Seite geladen wurde: die Live-Abfrage der Kaufmengen-Grenze bei Abverkaufsartikeln, das Warenkorb-Widget, der Warenkorb-Seitenbereich und die Suchvorschläge. Bots feuern sie gern ohne Cookies ab.

Diese vier Anfragen erhalten nie die Rechenaufgabe, auch nicht bei aktivierter Sicherheitsprüfung. Stattdessen bekommt jeder Browser mit der ersten solchen Anfrage ein Sicherheits-Cookie:

• Mit Cookie werden Anfragen je Browser-Sitzung und Anfrageart gezählt — gegen den eingestellten Wert, mindestens aber 30 pro Minute. Ein auf viele Rechner kopiertes Cookie teilt sich so ein Budget.
• Ohne Cookie werden Anfragen pro Netz (IPv4 /24, IPv6 /48) und Anfrageart gezählt. Ein Client, der das Cookie verwirft, erhält mit der nächsten Anfrage ein neues; diese Anfrage zählt gegen das Limit des Netzes. Echte Kunden im selben Netz bleiben unberührt.

Das Limit stellst du über Hintergrundanfragen ohne Cookie pro Netz und Minute ein (Standard 60). Über dem Wert antwortet der Shop im Modus Durchsetzen mit „HTTP 429 – zu viele Anfragen“ und hält die Anfrage im Protokoll als Gedrosselt fest. Im Modus Beobachten wird die Überschreitung nur als Markiert festgehalten (Protokoll ab Basic). Der Wert 0 schaltet den Schutz ab. Dieser Schutz sperrt nie eine Adresse und stößt keine Verstöße an.

Kaufmengen-Abfragen ohne Seitenaufruf (ab Basic)

Ein echter Browser fragt die Kaufmengen-Grenze erst ab, nachdem er eine Produktseite geladen hat. Eine Adresse, die solche Abfragen sendet, ohne zuletzt eine Seite deines Shops geladen zu haben, erkennt das Plugin auf der Karte Kauflimit-Kohärenz:

• Kaufmengen-Abfragen ohne Seitenaufruf erkennen (Standard: an).
• Kaufmengen-Abfragen pro Minute, ab denen eine Adresse ohne Seitenaufruf markiert wird (Standard 10) — echte Besucher senden auf einem Live-Shop höchstens 9 pro Minute.
• Gedächtnis für Seitenaufrufe (Standard 60 Minuten, höchstens 1440) — so lange entlastet ein geladener Seitenaufruf seine Adresse.
• Reaktion: Nur markieren (Audit-Log) (Standard) schreibt eine Zeile ins Protokoll. Mit HTTP 429 beantworten weist zusätzlich genau diese eine Abfrage ab, nur im Modus Durchsetzen. Prüfe das Protokoll gegen deinen eigenen Aufbau, bevor du auf 429 umstellst.

Wer eine Seite geladen hat, wird nie markiert — egal, wie viele Abfragen er sendet.

Kunden-Verschonung

Eingeloggte Kunden werden von einer Sperre nur verschont, wenn ihr Konto vertrauenswürdig ist. So kann sich ein automatisiert angelegtes Wegwerf-Konto eine Sperre nicht sofort zurückerschleichen. Die Karte Kunden-Verschonung steuert die Kriterien:

• Konto-Vertrauensprüfung für Kunden-Verschonung aktivieren (Standard: an). Schaltest du sie ab, wird über diesen Weg kein eingeloggter Kunde mehr verschont.
• Mindestkonto-Alter (Standard 60 Minuten).
• Mindestanzahl qualifizierender Bestellungen (Standard 1) — eine abgeschlossene oder bezahlte Bestellung; stornierte und offene, unbezahlte Bestellungen zählen nicht.
• Mindestalter qualifizierender Bestellungen (Standard 24 Stunden) — eine gerade aufgegebene Bestellung zählt noch nicht.

Ein Konto muss alt genug sein und genug qualifizierende Bestellungen haben, die älter als das Mindestalter sind. Fällt die Prüfung aus, wird die Verschonung vorsichtshalber nicht gewährt. Die Prüfung greift ausschließlich bei bereits gesperrtem Verkehr — echte Neukundschaft ohne Sperr-Vorgeschichte ist nie betroffen. Für bekannte geteilte Adressen bleibt die Freigabeliste das Mittel der Wahl.

Flotten-Erkennung (ab Basic)

Die Karte Flotten-Schutz deckt zwei Erkennungen ab, die Netzwerke finden, deren einzelne Adressen unter jedem Limit bleiben:

• Flotten-Erkennung (Standard: aktiv) schlägt koordinierte Botnetze, die ihre Anfragen über viele Adressen eines Netzsegments (/24) verteilen, und sperrt das Segment als Ganzes. Dazu zählen die koordinierte Flotte — ab der Mindestanzahl Hosts (Standard 20) mit durchgängig ausgelösten Signaturen —, die User-Agent-Rotation (Adressen, die ihre Kennung ständig wechseln) und die User-Agent-Monokultur (viele Adressen mit praktisch identischer Kennung). Die Schwellen der beiden User-Agent-Muster sind fest eingestellt: mindestens drei Adressen mit je fünf verschiedenen Kennungen bzw. mindestens zehn Adressen mit höchstens zwei Kennungen.
• Clean-Flotten-Erkennung (Standard: aktiv) findet koordinierte Gruppen, die keine Einzelregel auslösen, und legt sie als Vorschlag vor — sie sperrt nie selbstständig.

Clean-Flotten: Vorschläge prüfen

Die Erkennung läuft alle fünf Minuten und wertet über einige Minuten gleichmäßig getaktete Zugriffe aus. Ein Netzbereich wird vorgeschlagen, wenn mindestens drei von vier Merkmalen zutreffen:

• Der Datenverkehr des Netzes ist gleichmäßig getaktet — die Anfragen pro Minute schwanken kaum.
• Die einzelnen Adressen senden nahezu gleich viele Anfragen.
• Das Netz zeigt nur sehr wenige verschiedene Browser-Kennungen.
• Fast kein Datenverkehr entfällt auf Listing-, Such- und Widget-Aufrufe, wie sie ein echter Besuch immer erzeugt.

Der Vorschlag erscheint in der Übersicht und nennt den betroffenen Netzbereich im Klartext. Ein Vorschlag ist ein Hinweis, kein Urteil: Sieh dir den Netzbereich an, bevor du ihn freigibst — eine Freigabe sperrt den gesamten Bereich. Ein abgelehnter Vorschlag hat keine weiteren Folgen; bei anhaltendem Muster kann derselbe Bereich nach etwa einer Stunde erneut vorgeschlagen werden. Du kannst Vorschläge in jedem Tarif prüfen und freigeben, in dem die Erkennung läuft. Eine Benachrichtigung per Flow Builder gibt es für Clean-Flotten-Vorschläge nicht — nur für den KI-Analysten.

Netzbereiche, aus denen zuletzt am Admin gearbeitet wurde, nimmt die Erkennung automatisch aus: 30 Tage nach der letzten Anmeldung. Das Protokoll hält diese Ausnahme mit einer eigenen Zeile fest.

Schutz vor zu breiten Bereichssperren

Damit keine echten Kunden in einer Bereichssperre landen, gelten zwei Schutzregeln — für die Flotten-Erkennung wie für den KI-Analysten: Bereiche auf deiner Freigabeliste werden grundsätzlich nie automatisch gesperrt, und bei aktiver Netzwerktyp-Unterscheidung (Standard) werden automatische Bereichssperren nur für Rechenzentrums- und Hosting-Netze angelegt — Verbraucher- und Mobilfunknetze werden nicht großflächig als /24 gesperrt.

Netzwerktyp-Unterscheidung (ab Basic)

Die Netzwerktyp-Unterscheidung (Standard: aktiv) auf der Karte Flotten-Schutz weist automatisch erkannte Bots aus Rechenzentrums- und Hosting-Netzen direkt hart ab (HTTP 403), statt ihnen die Rechenaufgabe zu stellen — das schont Ressourcen bei rein maschinellem Verkehr. Anfragen aus Verbraucher-Netzen erhalten weiterhin die Rechenaufgabe. Die Einordnung nutzt eine mitgelieferte, kuratierte Bereichsliste; sie ist die einzige Quelle — andere Netze gelten nicht als Rechenzentrum. Deaktiviere die Option, wenn alle automatisch Gesperrten die Rechenaufgabe erhalten sollen. Eine Änderung wirkt erst nach einem Cache-Leeren.