-
Behoben: Im Bot-Schutz-Protokoll war die Spalte „Regel“ auf schmalen Bildschirmen auf ein einzelnes Zeichen zusammengeschoben. Die Protokollspalten haben jetzt feste Breiten, und „Regel“ steht direkt hinter „IP-Adresse“ — Zeitpunkt, IP und Regel sind damit ohne seitliches Scrollen vollständig lesbar. Die ausführliche Spalte „Entscheidung“ folgt dahinter: abgeschnitten wird sie nicht, auf schmalen Bildschirmen ist ihr Ende aber erst nach seitlichem Scrollen sichtbar.
-
Verbessert: Die Vorschlagsliste im Dashboard zeigt nur noch Netzbereiche, die sich aktuell freigeben lassen. Vorschläge,
deren Netzbereich aktuell nicht aufgelöst werden kann — in der Regel, weil das Netz seit über 24 Stunden keine Anfragen
gesendet hat —, werden ausgeblendet, statt beim Freigeben „nicht auflösbar“ zu melden. Dadurch sinkt auch die Zahl
offener Vorschläge im Diagnosebefehl coe:bot-shield:config:doctor deutlich; direkt nach einem Cache-Leeren oder
Plugin-Update kann sie für bis zu eine Minute nahe null liegen, bis die nächsten Anfragen der Netze erfasst sind. Es geht
nichts verloren: Die Vorschläge bleiben gespeichert, der LLM-Analyst sieht seinen vollständigen Verlauf weiterhin, und
sobald das Netz wieder Anfragen sendet, erscheint der Vorschlag erneut.
-
Neu: bin/console coe:bot-shield:config:prune listet gespeicherte CoeBotShield-Einstellungen auf, die das Plugin nicht
mehr kennt, und löscht sie mit --apply. Das sind Reste von Einstellungen, die in früheren Versionen entfernt wurden
und die nichts mehr liest. Ohne --apply zeigt der Befehl nur an und löscht nichts. Er erfasst auch Werte, die nur für
einen einzelnen Verkaufskanal gespeichert sind, und gibt nie einen gespeicherten Wert aus. Einen Eintrag, dessen Löschen
eine gültige Einstellung mitlöschen würde oder den Shopware nicht löschen kann, zeigt er mit Begründung an und löscht ihn
nie.
Hinweis: Das Löschen lässt sich nicht rückgängig machen. Sichere vor --apply die Tabelle system_config.
-
Geändert: Welche Funktionen von Bot Shield dein Tarif enthält, prüft das Plugin jetzt über den Lizenz-Server des
Herstellers. Die Tarifübersicht in der Plugin-Konfiguration zeigt die Tarife mit ihren Funktionen, deinen aktiven
Tarif und den Knopf zum Kaufen oder Wechseln.
Hinweis: Für die Tarifprüfung sendet das Plugin die Lizenz-Domain, die Plugin- und die Shopware-Version sowie den
Zeitpunkt der Abfrage an den Lizenz-Server des Herstellers, nie Daten deiner Kunden oder Besucher. Damit dein Tarif
aktuell bleibt, muss der Scheduled-Task-Runner deines Shops laufen.
-
Geändert: Sperrvorschläge freigeben oder ablehnen und den Verbindungstest des LLM-Analysten gibt es jetzt auch über
die Admin-API nur in einem Tarif, der die jeweilige Funktion enthält. Ohne sie meldet der Verbindungstest, dass der
LLM-Analyst nicht in deinem Tarif enthalten ist.
-
Geändert: Einstellungskarten für Funktionen, die dein Tarif nicht enthält, sind jetzt als gesperrt erkennbar — der Karteninhalt ist ausgegraut und nicht bedienbar, und oben in der Karte steht ein Hinweis mit dem passenden Tarif. Jede Einstellungskarte zeigt ihre Tarifstufe (Free/Basic/Pro). Die gespeicherten Werte bleiben unverändert. Auf dem Dashboard erscheint der Hinweis zu einer Funktion, die dein Tarif nicht enthält, als normale Karte mit Überschrift — in derselben Darstellung wie die gesperrten Einstellungskarten, mit Vorschau und Upgrade-Schaltfläche; beim Edge Export steht derselbe Hinweis. Die Hinweistexte nennen keinen festen Tarifnamen, sondern richten sich nach deiner Lizenz.
-
Geändert: Die Texte der Sicherheitsprüfung und der Überlastungs-Abweisung folgen jetzt der Sprache des Verkaufskanals, unter dem der Besucher unterwegs ist, statt der im Browser eingestellten Sprache. Ein englischsprachiger Verkaufskanal antwortet damit auch deutschsprachigen Besuchern auf Englisch.
-
Neu: Das Bot-Schutz-Protokoll zeigt jetzt auch, wenn der KI-Analyst ein Netz tatsächlich gesperrt hat — bisher waren von ihm nur die Fälle zu sehen, in denen eine Schutzregel die Sperre verhindert hat. Die Zeile nennt die Zuversicht des Urteils und ob zum Zeitpunkt der Sperre scharf geschaltet oder nur beobachtet wurde.
-
Verbessert: Das Protokoll benennt die Entscheidungen des KI-Analysten und übersprungene Flotten-Sperren in Klartext statt als interne Kennung oder technisches Kürzel. „LLM-Analyst: Sperre übersprungen (Schutzregel)“ und „LLM-Analyst: Sperre gehalten (keine Signatur)“ erscheinen als lesbarer Text; „LLM-Analyst: Vorschlag erstellt“ steht für einen Fund, der dir zur Freigabe vorgelegt wird; „LLM-Analyst: auf stärkste Netze begrenzt“ sagt, dass ein Durchlauf nur die auffälligsten Netze beurteilt hat — und damit auch, warum nicht jedes Netz in einem Durchlauf vorkommt. Übersprungene Flotten-Sperren erscheinen mit lesbarer Bezeichnung statt als interner Schlüssel.
-
Neu: Schutz vor massenhaften Konto- und Bestell-Anlagen (ab Basic). Bot Shield erkennt ungewöhnlich viele Registrierungen in kurzer Zeit sowie auffällige Muster bei E-Mail-Domains; Gast-Registrierungen zählen dabei mit. Ist das Registrierungslimit des Shops überschritten, bekommt nur die Adresse eine Reaktion, von der selbst auffällig viele Registrierungen kommen — wer eine einzelne Registrierung absendet, bleibt unbehelligt; wie viele Registrierungen pro Adresse und Minute zulässig sind, steht in den Einstellungen (Standard: 3). Die Reaktion ist „HTTP 429 – bitte später erneut versuchen“ statt einer harten Sperre oder wahlweise die vorhandene Rechenaufgabe (Proof-of-Work): echte Kundschaft löst sie und wird durchgelassen, automatisierte Massenanlagen scheitern daran; Headless-/Store-API-Aufrufe werden gedrosselt. Die Fehlerseite bei abgewiesenen Registrierungen und Bestellungen (HTTP 429) nennt neben dem erneuten Versuch den direkten Kontakt zum Shop. Im Modus „Beobachten“ wird nur protokolliert. Adressen auf der Freigabeliste sind von allen Prüfungen an der Registrierung ausgenommen. Jede Entscheidung erscheint im selben Protokoll wie die übrigen Gate-Entscheidungen, und es wird nichts automatisch storniert oder abgelehnt.
-
Neu: Registrierungswellen aus einem einzelnen Netzbereich werden jetzt über Stunden erkannt, nicht nur pro Minute. Erzeugt ein Netzbereich im eingestellten Zeitfenster mehr Konten als die eingestellte Obergrenze, erhält die nächste Registrierung aus diesem Netz eine Rechenaufgabe; echte Besucher lösen sie einmal und werden danach nicht erneut gefragt. Zeitfenster, Obergrenze und Reaktion sind einstellbar.
-
Neu: Adressen, an denen auffällig viele Konten entstehen, erhalten bei der Registrierung gezielt eine Rechenaufgabe. Zählt Bot Shield innerhalb des Erkennungsfensters mindestens so viele unterschiedliche Konten an einer normalisierten Adresse wie eingestellt, bekommt die nächste Registrierung von dieser Adresse die vorhandene Proof-of-Work-Aufgabe — echte Besucher lösen sie einmal, alle übrigen Besucher des Shops merken nichts davon. Bestellungen an einer Adresse erweitern ihren Spielraum: Bot Shield prüft dafür die tatsächlichen Bestellungen des Shops an dieser Adresse, auch solche vor der Plugin-Installation und von Gastkunden; stornierte und unbezahlte Bestellungen zählen nicht als gültig, maßgeblich ist der aktuelle Stand der Bestellung, nicht ein offener Bearbeitungsentwurf. Eine einzelne bezahlte oder abgeschlossene Bestellung hebt den Schutz an dieser Adresse nicht dauerhaft auf: Jede solche Bestellung erlaubt an dieser Adresse so viele weitere Konten im Erkennungsfenster, wie der „Schwellenwert für Adress-Cluster“ angibt; darüber hinaus erhalten Registrierungen von dieser Adresse wieder die eingestellte Adress-Cluster-Reaktion — Neuregistrierungen und Gast-Bestellungen an dieser Adresse, auch die eines echten Bewohners; eingeloggte Kunden sind nie betroffen. Adressen mit weniger Konten als der Schwellenwert sind nie betroffen. Stornierte Bestellungen werden gegen die gültigen Bestellungen gerechnet: Jede stornierte Bestellung nimmt die zusätzlichen Konten, die eine gültige Bestellung dort erlaubt, wieder weg; gibt es an der Adresse mindestens so viele stornierte wie gültige Bestellungen, gilt dort wieder der einfache „Schwellenwert für Adress-Cluster“. Eine Adresse, deren Bestellungen größtenteils storniert werden, gewinnt durch die wenigen übrigen also keinen zusätzlichen Spielraum. Im Modus „Beobachten“ wird die Erkennung nur protokolliert. Schwellenwert, Reaktion und Erkennungsfenster sind einstellbar; die Treffer erscheinen im Protokoll unter der Regel „address_cluster“, jeweils mit einer kurzen Adress-Kennung, die sich nicht auf die Adresse zurückführen lässt, sodass erkennbar ist, wie viele verschiedene Adressen betroffen sind — die Adresse selbst wird nicht gespeichert. Erfordert den Basic-Plan.
-
Neu: Adress-Cluster und Netzbereiche über der Registrierungs-Obergrenze lassen sich jetzt direkt abweisen, statt sie mit einer Rechenaufgabe zu prüfen. Die Einstellungen „Adress-Cluster-Reaktion“ und „Reaktion bei überschrittener Obergrenze“ haben die neue Option „Mit HTTP 429 beantworten“: Die nächste Registrierung von einer solchen Adresse oder aus einem solchen Netzbereich erhält den Hinweis „Zu viele Anfragen“ — auch dann, wenn bereits eine Rechenaufgabe gelöst wurde, denn eine gelöste Aufgabe beweist einen Browser, keine echte Adresse. Bei Netzbereichen gilt das auch für Registrierungen über die Store-API. Das Audit-Log führt diese Abweisungen als „Gedrosselt“ unter den Regeln „address_cluster“ und „register_volume_subject“. Greift nur im Modus „Durchsetzen“; erfordert den Basic-Plan.
-
Neu: Schutz vor Massen-Registrierungen auf brandneuen E-Mail-Domains. Werden in kurzer Zeit auffällig viele Konten auf einer Domain angelegt, die im Shop erst seit Kurzem auftaucht, kann bei der Registrierung die Rechenaufgabe gestellt werden. Die Erkennung wertet die tatsächlichen Konten im Shop aus — sie greift sofort, ohne Lernphase, und etablierte Domains wie große Freemail-Anbieter lösen die Prüfung nicht aus. Keine Domain wird dauerhaft gesperrt: eine echte Firmen-Domain wird nach einmaligem Lösen normal bedient und gilt nach kurzer Zeit als bekannt.
-
Neu: Registrierung und Kasse erkennen automatisierte Nicht-Browser-Clients. Meldet sich ein Client als App-Laufzeitumgebung (z. B. Electron) statt als echter Browser, kann bei Registrierung und Bestellabschluss die Rechenaufgabe gestellt werden; Headless-/Store-API-Aufrufe werden gedrosselt (HTTP 429). Wahlweise wird der Treffer nur markiert. Die Kennung von Desktop-Apps wie Discord oder anderen Electron-Anwendungen zählt dabei nie allein als Hinweis gegen ein ganzes Netz: Ein Netzbereich, aus dem viele Besucher mit einer solchen App kommen, wird nicht allein deswegen als Bot-Flotte gesperrt — weder von der automatischen Flotten-Erkennung noch vom LLM-Analysten; für die einzelne Adresse zählt die Kennung zusammen mit einem zweiten Merkmal.
-
Neu: Die Sicherheitsprüfung bei Registrierung und Kasse wird nur dort gestellt, wo sie sich auch beantworten lässt. Ein im Hintergrund abgeschicktes Formular bekommt keine unlösbare Prüfung vorgesetzt, sondern wird protokolliert und durchgelassen; wo eine Adresse das Registrierungslimit pro Minute überschreitet, antwortet der Shop weiterhin mit einer Begrenzung. Unterbricht die Prüfung eine Registrierung, stehen die Angaben danach wieder im Formular; das Passwort wird bewusst nicht zwischengespeichert und ist erneut einzugeben. Eine bestandene Prüfung deckt genau einen erfolgreichen Vorgang ab — einheitlich über alle Schutzmechanismen (Konto-Tempo, neue E-Mail-Domains, Nicht-Browser-Clients) sowie für registrierte und Gast-Vorgänge. Ein abgebrochener oder fehlerhafter Versuch (z. B. vertippte E-Mail) verbraucht die Freigabe nicht, und normales Stöbern bleibt für die eingestellte Dauer freigegeben.
-
Neu: Adress-Duplikat-Erkennung als Betrugssignal (ab Basic). Wird dieselbe Lieferadresse von einer konfigurierbaren Anzahl verschiedener Kundinnen und Kunden genutzt, erhalten alle betroffenen Konten automatisch ein frei wählbares Schlagwort (Tag); es wird wieder entfernt, sobald der Beobachtungszeitraum ohne neuen Treffer endet. Die Erkennung greift bei Registrierung und Bestellabschluss und erfasst auch Gast-Registrierungen. Gespeichert werden ausschließlich Adress-Hashes — niemals Klartextdaten.
-
Neu: Nach dem Update sichert der Shop aufwendige Seitenaufrufe von unbekannten Besuchern automatisch mit einer kurzen Sicherheitsprüfung ab, bevor überhaupt eine Sperre greift. Sie greift bei allen regulären Seitenaufrufen des Shops — Startseite, Kategorie- und Produktseiten ebenso wie Anmeldung, Registrierung, Warenkorb und Kasse; Bilder, Skripte und andere Dateien sind ausgenommen. Steht der Schutzmodus auf „Durchsetzen“, sehen unbekannte Besuchende beim ersten Seitenaufruf eine kurze Sicherheitsprüfung, die in der Regel in weniger als einer Sekunde von selbst durchläuft und danach die angeforderte Seite öffnet — mitsamt Filtern, Sitzung und Warenkorb, die dabei erhalten bleiben. Sie erscheint in der Regel einmal pro Sitzung: eine bestandene Prüfung gilt für die Dauer ihrer Gültigkeit (standardmäßig 30 Minuten) auch für alle weiteren Seiten. Und sie trifft immer den Seitenaufruf, nie das Absenden eines bereits ausgefüllten Formulars. Im Modus „Beobachten“ wird die Prüfung nur protokolliert, die Seite wird normal ausgeliefert. Angemeldete Mitarbeitende, bestätigte Suchmaschinen und Besuchende, die die Prüfung bereits bestanden haben, werden übersprungen. Die Funktion ist standardmäßig eingeschaltet und kann jederzeit wieder abgeschaltet werden. Die Prüfung kostet immer gleich wenig (etwa 191 Versuche). bin/console coe:bot-shield:config:doctor zeigt an, ob die Prüfung wirksam ist. Bitte beachten: Die Prüfung setzt JavaScript voraus. Suchmaschinen, die sich über einen Rückwärts-DNS-Eintrag bestätigen lassen (Google, Bing, Apple, DuckDuckGo, Yandex), werden automatisch übersprungen. Die Link-Vorschau-Dienste von Facebook, X und LinkedIn lassen sich so nicht bestätigen — sie veröffentlichen nur IP-Bereiche. Im Modus „Durchsetzen“ zeigen diese Plattformen daher keine Vorschau mehr für Shop-Seiten an, bis du die betreffenden Adressen auf die Freigabeliste setzt. Dasselbe gilt für eigene Überwachungsdienste.
-
Verbessert: Eine bestandene Sicherheitsprüfung ist jetzt zusätzlich an die Browsersitzung gebunden, nicht mehr nur an die IP-Adresse. Dadurch lässt sich eine einmal bestandene Prüfung nicht mehr auf ein anderes Gerät oder einen anderen Browser übertragen — auch dann nicht, wenn beide über dieselbe IP-Adresse ins Netz gehen. Wechselt umgekehrt die IP-Adresse während des Besuchs (bei Mobilfunk üblich), wird die kurze Prüfung einmal erneut angezeigt.
-
Neu: Schutz vor Bots, die Hintergrundanfragen ohne Cookies abfeuern (alle Tarife). Vier Hintergrundanfragen, die der Shop nie aus dem Cache bedient — die Live-Abfrage der Kaufmengen-Grenze bei Abverkaufsartikeln, das Warenkorb-Widget, der Warenkorb-Seitenbereich und die Suchvorschläge — erhalten nie die Sicherheitsprüfung (Rechenaufgabe), auch nicht bei aktivierter automatischer Prüfung. Stattdessen bekommt jeder Browser mit der ersten solchen Anfrage ein Sicherheits-Cookie. Anfragen mit dem Cookie werden je Browser-Sitzung und Anfrageart gezählt, gegen den eingestellten Wert für Hintergrundanfragen, mindestens aber 30 pro Minute; ein auf viele Rechner kopiertes Cookie teilt sich so ein Budget. Ein Client, der das Cookie verwirft, erhält mit seiner nächsten Anfrage ohne Cookie ein neues, und diese Anfrage zählt gegen das Limit des Netzes. Anfragen ohne dieses Cookie werden pro Netz (IPv4 /24, IPv6 /48) und Anfrageart gezählt; über dem eingestellten Wert (Standard: 60 pro Minute) antwortet der Shop im Modus „Durchsetzen“ mit „HTTP 429 – zu viele Anfragen“ und hält die Anfrage im Audit-Log als „Gedrosselt“ fest, im Modus „Beobachten“ wird die Überschreitung nur im Audit-Log als „Markiert“ festgehalten (Audit-Log ab Basic). Echte Kunden im selben Netz bleiben unberührt. Der Wert 0 schaltet den Schutz ab.
-
Behoben: Die Cookie-Einstellungen zeigen jetzt die Namen und Beschreibungen der Bot-Shield-Cookies an.
-
Neu: Die Flotten-Erkennung erkennt jetzt auch koordinierte Zugriffe, die keine einzelne Regel auslösen — viele Adressen eines Netzbereichs, die über Minuten gleichmäßig getaktet, in nahezu identischem Umfang und fast ausschließlich auf Seiteninhalte zugreifen, ohne Cache-Buster, auffällige Parameter oder ungewöhnliche Browser-Kennungen. Ein Treffer erscheint als Vorschlag im Dashboard; gesperrt wird nichts ohne deine Freigabe. Ein Vorschlag ist ein Hinweis, kein Urteil: sieh dir den Netzbereich an, bevor du ihn freigibst — eine Freigabe sperrt den gesamten Bereich —, und ein abgelehnter Vorschlag hat keine weiteren Folgen. Netzbereiche, aus denen zuletzt am Admin gearbeitet wurde, werden automatisch ausgenommen und mit eigener Zeile protokolliert.
Der Vorschlag nennt den betroffenen Netzbereich im Klartext — und markiert ihn, wenn es dein eigenes Netzwerk ist, damit du nicht erst nachsehen musst, von welcher Adresse du arbeitest. Nach einer Freigabe siehst du, was tatsächlich gesperrt wurde und was nicht: Netzbereiche auf deiner Freigabeliste werden durch eine Freigabe nie gesperrt. Die automatische Ausnahme für Netzbereiche, aus denen am Admin gearbeitet wurde, gilt 30 Tage nach der letzten Anmeldung. Vorschläge kannst du in jedem Tarif prüfen und freigeben, in dem die Erkennung läuft.
Hinweis: Die Erkennung ist direkt nach dem Update aktiv. Abschalten kannst du sie in den Plugin-Einstellungen.
-
Verbessert: Bot Shield erkennt automatisierte Zugriffe, die Widget- und Hintergrund-Routen wie eine
normale Seite statt wie der Browser im Hintergrund aufrufen, und bezieht dieses Merkmal gemeinsam mit
weiteren Signalen in die Sperrung auf den kostenpflichtigen Tarifen ein — es sperrt nicht allein, damit
echte Kundenzugriffe aus denselben Netzen zuverlässiger verschont bleiben.
-
Neu: Bot Shield erkennt Zugriffe, die ausschließlich die Live-Abfrage der Kaufmengen-Grenze abrufen, ohne vorher eine Seite des Shops geladen zu haben — ein Muster, das ein echter Browser nicht erzeugt, weil diese Abfrage erst von einer geladenen Produktseite ausgelöst wird. Solche Zugriffe erscheinen ab Basic im Audit-Log als „Markiert“; auf Wunsch werden sie stattdessen mit HTTP 429 beantwortet, und zwar nur diese eine Abfrage. Wer eine Shop-Seite geladen hat, wird nie markiert — auch nicht bei hoher Anfragezahl. Das gilt auch für Anfragen mit dem Sicherheits-Cookie: Sie werden wie jede andere Anfrage geprüft. Als Seitenaufruf zählt eine Shopseite, die von der Adresse im eingestellten Zeitraum geladen wurde.
-
Verbessert: Die Erkennung protokolliert jetzt auch auffälligen Verkehr unterhalb der Sperr-Schwelle (Rate-Limit-Überschreitungen, gezählte Verstöße, ergebnislose Flotten-Auswertungen) und führt eine mehrminütige Verlaufshistorie pro Netz — damit werden langsam verteilte Zugriffe nachvollziehbar, die eine reine Momentaufnahme nicht zeigt.
-
Neu: Eine Übersicht dokumentiert jetzt offen, welchen Datenverkehr der Schutz von sich aus nicht sieht — Dateien, die der Webserver selbst ausliefert, Seiten, die aus dem HTTP-Cache beantwortet werden, Zugriffe unterhalb des eingestellten Limits, verteilte, unauffällige Zugriffsmuster sowie Anfragen, die über die Schnittstelle des Shops statt über gerenderte Seiten kommen. Zu jedem Punkt steht, woran es liegt und was du stattdessen tun kannst. Der Hinweis auf diese Übersicht steht ab jetzt direkt im Hilfetext des Schutzmodus.
-
Geändert: Die voreingestellte Dauer einer automatischen Sperre ist von 60 auf 360 Minuten angehoben. Eine Sperre, die kürzer ist als der Angriff, läuft mitten darin ab und der Datenverkehr kommt zurück; der dokumentierte Anlassfall lief rund vier Stunden. Der Hilfetext des Feldes erklärt jetzt beide Richtungen: eine zu kurze Dauer lässt den Angriff zurückkehren, eine zu lange hält eine fälschlich erkannte Adresse entsprechend lange gesperrt — einzelne Sperren hebst du jederzeit in der Sperrliste auf oder nimmst die Adresse in die Freigabeliste.
Hinweis: Eine bestehende Installation behält den Wert, den sie heute hat — der neue Standard gilt für Neuinstallationen. Prüfe die „Dauer der automatischen Sperre (Minuten)“ in den Plugin-Einstellungen und hebe sie an, wenn dort noch 60 steht.
-
Geändert: Vier Netze, aus denen im Shop echte Bestellungen kamen, gelten nicht mehr als Rechenzentrumsnetz (82.38.220.0/24, 95.134.61.0/24, 178.95.140.0/22, 178.92.199.0/24). Eine automatische Sperre aus diesen Netzen bietet nun die Sicherheitsprüfung an statt einer harten Ablehnung, und sie werden nicht mehr als ganzes Netz gesperrt.
-
Geändert: Eingeloggte Kundinnen und Kunden werden von einer Sperre nur noch verschont, wenn ihr Konto vertrauenswürdig ist — alt genug und mit einer abgeschlossenen Bestellung, die älter als ein einstellbares Zeitfenster ist (neu: „Mindestalter qualifizierender Bestellungen (Stunden)“, Standard 24 h). So kann sich ein automatisiert angelegtes Wegwerf-Konto eine Sperre nicht länger sofort zurückerschleichen. Gealterte Bot-Konten mit nur frisch gestapelten Bestellungen werden damit nicht mehr fälschlich freigestellt. Die Schwellen sind einstellbar und die Differenzierung lässt sich per Schalter ganz abschalten. Fällt die Vertrauensprüfung aus oder wird sie deaktiviert, wird die Freistellung nun vorsichtshalber nicht gewährt. Die Prüfung greift ausschließlich bei bereits gesperrtem Verkehr — echte Neukundschaft ohne Sperr-Vorgeschichte ist nie betroffen.
-
Behoben: Angemeldete Stammkund:innen wurden trotz vertrauenswürdigem Konto blockiert, wenn ihre IP-Adresse
auf der Sperrliste stand — die Kundenfreistellung greift jetzt zuverlässig und lässt sie passieren.
-
Verbessert: Die KI-Analyse bewertet verdächtige Netzwerke jetzt mit Gedächtnis — sie sieht ihre eigenen früheren Einschätzungen zum selben Netzwerk sowie den kurzfristigen Anfrageverlauf und erkennt dadurch gleichmäßig langsame Dauer-Zugriffe zuverlässiger, die in einer Momentaufnahme unauffällig wirken.
-
Behoben: Sperr-Vorschläge der Fleet-/KI-Erkennung gingen bei einem Cache-Leeren (z. B. bei jedem Update) verloren und erschienen danach nicht mehr im Dashboard. Vorschläge werden jetzt mit Grund und Kategorie dauerhaft gespeichert und bleiben zur Freigabe sichtbar.
-
Behoben: Das Freigeben eines älteren KI-Analyst-Vorschlags meldete „freigegeben und gesperrt“, obwohl keine Sperre angelegt wurde. Vorschläge gelten jetzt 24 Stunden (bisher 7 Tage) und verschwinden danach aus der Übersicht; kann ein Vorschlag nicht mehr angewendet werden, erscheint eine Fehlermeldung und die Liste wird aktualisiert.
-
Behoben: Die Liste der offenen KI-Analyst-Vorschläge wird jetzt sauber in Spalten dargestellt — der Text überlappt die Schaltflächen nicht mehr.
-
Geändert: Der KI-Analyst übermittelt keine IP- oder Netzwerkadressen mehr an den konfigurierten KI-Anbieter, sondern nur noch pseudonymisierte Kürzel mit ihren Verhaltensdaten. Die Zuordnung zur Adresse erfolgt ausschließlich im Shop; vorgeschlagene und automatische Sperren funktionieren unverändert.
-
Behoben: Bei anhaltend hohem Traffic konnten neu auffällige Netze nach einiger Zeit nicht mehr automatisch gesperrt oder vorgeschlagen werden. Interne Zuordnungen laufen jetzt einzeln ab und machen Platz für neue; IPv4- und IPv6-Netze belegen getrennte Kontingente.
-
Behoben: Die DNS-Prüfung von Suchmaschinen-Crawlern (Googlebot, Bingbot, Applebot, DuckDuckBot, Yandex) konnte eine Anfrage unbegrenzt lange aufhalten. Kann das Plugin die DNS-Konfiguration des Servers lesen, wird jede Abfrage jetzt nach rund einer Sekunde abgebrochen. Andernfalls prüft es wie bisher über den System-Resolver und schreibt einen Hinweis ins Shop-Log.
-
Behoben: Konnte der Zugriff eines dieser Crawler nicht rechtzeitig per DNS geprüft werden (Abfragelimit erreicht oder DNS-Zeitüberschreitung), wurde er wie ein unbestätigter Crawler blockiert oder auf die Prüfseite geleitet, und Besucher erhielten eine leere Seite ohne Erklärung. Er erhält jetzt stattdessen eine vorübergehende Antwort „503 — bitte später erneut versuchen“ und wird beim nächsten Besuch geprüft; das gilt auch bei der automatischen Sicherheitsprüfung für unbekannte Besucher. Auf dieser Seite steht, was passiert ist, und die Bitte, es in etwa einer Minute erneut zu versuchen — und bei einer gesperrten Adresse, für die die Sicherheitsprüfung verfügbar ist, wird sie direkt angeboten, sodass ein falsch eingeordneter Mensch sofort weiterkommt. Von Hand gesperrte Adressen erhalten statt dieser Hinweis-Seite die normale Sperrantwort — eine Sperre, die du selbst gesetzt hast, bleibt absolut, und es wird kein Weg daran vorbei angeboten.
-
Behoben: Googlebot und Bingbot wurden bei Zugriffen über IPv6 nicht als verifizierte Crawler erkannt und konnten deshalb blockiert oder auf die Prüfseite geleitet werden. Die Prüfung berücksichtigt jetzt IPv4- und IPv6-Adressen; DNS-Abfragen für noch unbekannte Crawler-Adressen sind zudem mengenmäßig begrenzt.
-
Behoben: Bei Shops in einem Unterverzeichnis oder mit Sprachpfad in der Domain (z. B. /de) leitete die Sperrseite gesperrte Besucher auf eine falsche Adresse um. Die Weiterleitung führt jetzt auf die Sperrseite des richtigen Verkaufskanals, auch bei Antworten aus dem HTTP-Cache.
-
Behoben: Bei Domains mit Umlauten (internationalisierte Domainnamen) leitete die Sperrseite gesperrte Besucher aus dem HTTP-Cache auf eine Adresse ohne Sprachpfad um, und die Sperrseite selbst konnte erneut umgeleitet werden. Die Weiterleitung führt jetzt auch dort auf die Sperrseite des richtigen Verkaufskanals; ein Fehler beim Laden der Domains wird im Shop-Log protokolliert.
-
Behoben: Kann die gewählte Erlebniswelt der Sperrseite nicht dargestellt werden, wird der Fehler jetzt im Shop-Log protokolliert (weiterhin mit einfacher 403-Antwort für den Besucher).
-
Verbessert: Das Logo der Prüfseite wird jetzt im Kontext des jeweiligen Verkaufskanals geladen statt mit Systemrechten; private Medien bleiben dort wie bisher ausgeschlossen.
-
Verbessert: Ein gesperrter Client mit wechselndem Sitzungs-Cookie löst nicht mehr bei jeder Anfrage eine Datenbankabfrage aus.
-
Behoben: Während des Wartungsmodus wird jetzt zuverlässig die Wartungsseite angezeigt. Bisher konnte der Bot-Schutz auffälligen Besuchern stattdessen seine Prüfseite zeigen — da beide mit „503“ antworten, wirkte der Shop dabei fälschlich wie gestört.
-
Verbessert: Die Verzeichnisse für den Edge-Export (Sicherungen und .htaccess-Zielordner) werden nicht mehr für alle Benutzer beschreibbar angelegt; ein bei älteren Versionen für alle Benutzer beschreibbar angelegtes Verzeichnis wird beim nächsten Schreiben der .htaccess auf Zugriff nur für Besitzer und Gruppe beschränkt.
-
Geändert: Ist das Speicherverzeichnis für Edge-Export-Sicherungen ein symbolischer Link oder gehört einem anderen Benutzer, wird die .htaccess nicht geschrieben und ein Hinweis protokolliert.
-
Geändert: Automatische Sperren für Crawler-Zugriffe, deren DNS-Prüfung noch aussteht, werden nicht mehr in den Edge-Export geschrieben; sie wirken nur im Shop, wo der Crawler erneut geprüft wird.
-
Verbessert: Der Schwellenwert für die /16-CIDR-Zusammenfassung erklärt jetzt im Hilfetext, dass 0 ihn abschaltet und der Wert 1 die weiteste mögliche Sperre erzeugt; coe:bot-shield:config:doctor warnt zusätzlich, wenn 1 eingestellt ist.
-
Neu: Das Dashboard zeigt jetzt in einer eigenen Karte, welche Regeln in den letzten 24 Stunden gegriffen haben — gesperrt/geprüft und, neu, durchgelassen (z. B. über die Freigabeliste oder eine bestehende Prüfung), jeweils mit Trefferzahl.
-
Behoben: Eine leere Karte im Dashboard konnte „nichts passiert“ bedeuten oder „hier wird nichts aufgezeichnet“ — beides sah gleich aus. Die Karte sagt jetzt, wenn im aktuellen Tarif oder bei ausgeschalteter Erkennung keine Entscheidungen aufgezeichnet werden.
-
Behoben: Einträge „Verstoß gezählt“, die eine auffällige Anfrage-Signatur ausgelöst hat, nennen im Protokoll jetzt diese Signatur als Regel statt immer „rate_limit“.
-
Verbessert: Die Sperrliste kennzeichnet abgelaufene Einträge jetzt sichtbar als abgelaufen, statt sie wie aktive zu zeigen.
-
Behoben: Zeitangaben in den Admin-Listen (Sperrliste, Freigabeliste, Protokoll, Edge Export) werden jetzt in der im Profil hinterlegten Zeitzone angezeigt.
-
Neu: Schutzstufe für den Scraper-Schutz (Free). Eine Auswahl (Leicht, Standard, Streng, Benutzerdefiniert) setzt die Anfrage-Limits für Listing- und Produktseiten, die Verstöße bis zur automatischen Sperre, die Signatur-Punktzahl, die Dauer der automatischen Sperre und das Limit für Hintergrundanfragen ohne Cookie auf einmal. Standard entspricht den bisherigen Standardwerten. Deine eigenen Werte in diesen sechs Einstellungen bleiben bei jeder Stufe erhalten und gelten unter „Benutzerdefiniert“. Bei einem bestehenden Shop ist nach dem Update „Benutzerdefiniert“ eingestellt, es ändert sich also nichts, bis du eine andere Stufe wählst; eine Neuinstallation startet mit „Standard“.
-
Neu: Schutzstufe für den Registrierungsschutz (Basic). Eine Auswahl (Leicht, Standard, Streng, Benutzerdefiniert) setzt die Registrierungslimits pro Minute für den Shop und pro Client, die Kontogrenze pro Netzbereich, den Konto-Schwellenwert pro Lieferadresse und die Reaktionen der fünf Registrierungsprüfungen auf einmal. Standard entspricht den bisherigen Standardwerten; Streng weist Spitzen, Netzbereiche über ihrer Grenze und Adress-Cluster mit HTTP 429 ab. Deine eigenen Werte in diesen neun Einstellungen bleiben bei jeder Stufe erhalten und gelten unter „Benutzerdefiniert“. Bei einem bestehenden Shop ist nach dem Update „Benutzerdefiniert“ eingestellt, es ändert sich also nichts, bis du eine andere Stufe wählst; eine Neuinstallation startet mit „Standard“. Die Konsolen-Selbstdiagnose zeigt auch für diese Stufe, welcher Wert gerade gilt.
-
Neu: Schutzstufe für die Flotten-Erkennung (Basic). Eine Auswahl (Leicht, Standard, Streng, Benutzerdefiniert) setzt die automatische Bereichssperre für Flotten und die Prüfvorschläge für Clean-Flotten auf einmal. Standard entspricht den bisherigen Standardwerten (beide an); Leicht schaltet die automatische Bereichssperre für Signatur- und User-Agent-Flotten ab — diese Bereiche werden dann weder gesperrt noch gemeldet, nur die Clean-Flotten-Erkennung erzeugt weiter Prüfvorschläge; Streng entspricht Standard. Deine eigenen Einstellungen der beiden Schalter bleiben bei jeder Stufe erhalten und gelten unter „Benutzerdefiniert“. Bei einem bestehenden Shop ist nach dem Update „Benutzerdefiniert“ eingestellt, es ändert sich also nichts, bis du eine andere Stufe wählst; eine Neuinstallation startet mit „Standard“. Der LLM-Analyst (Pro) ist von dieser Stufe nicht erfasst: Er sperrt weiterhin Bereiche ab seinem „Konfidenz-Schwellwert für automatische Anwendung“ und schlägt Bereiche darunter vor.
-
Neu: Die Schutzstufen zeigen, was sie tun. Unter der Stufenauswahl steht eine Tabelle mit allen Einstellungen, die die Stufe setzt, und ihren Werten für Leicht, Standard und Streng — mit einem Hinweis, wo eine Stufe denselben Wert wie die vorige verwendet, und wo ein Wert bei jeder Stufe gleich ist. So ist erkennbar, ob ein Stufenwechsel überhaupt etwas verändert. Solange eine Schutzstufe ausgewählt ist, lassen sich die von ihr gesetzten Einstellungen nicht bearbeiten; der jeweils geltende Wert steht in der Tabelle. Wähle „Benutzerdefiniert“, um die Einstellungen wieder selbst zu setzen; deine eigenen gespeicherten Werte bleiben dabei unverändert erhalten und gelten wieder, sobald du zurück auf „Benutzerdefiniert“ wechselst.
-
Geändert: Die Plugin-Einstellungen sind neu geordnet; alle Einstellungen behalten ihre Werte.
-
Neu: Konfigurations-Selbstdiagnose über die Konsole (bin/console coe:bot-shield:config:doctor) — meldet Betriebsmodus, Lizenztarif und Signal-Diagnose mit einer PASS/WARN/FAIL-Bewertung und benennt Einstellungen, die aktiviert, aber wirkungslos sind. Die Gesamtbewertung in der letzten Zeile ist beschriftet (Verdict: …). Sie berücksichtigt den aktiven Tarif: Kostenbremse, CIDR-Zusammenfassung, Vorschlags-Zustellung und Kauflimit-Kohärenz melden, dass die Funktion im aktiven Tarif nicht läuft, wenn dieser sie nicht enthält, und ziehen das Gesamturteil nicht auf „WARN“ herunter. Außerdem zeigt sie die eingestellte Schutzstufe und für jeden der sechs Werte, welcher Wert gerade gilt und woher er stammt (Stufe oder eigene Einstellung); meldet, wenn Vorschläge offen sind, aber kein Flow auf das Ereignis „botshield.finding.pending“ reagiert; meldet Einstellungen, deren gespeicherter Wert nicht zum Feldtyp passt — etwa "0" als Text in einem Ja/Nein-Schalter oder "360" als Text in einem Zahlenfeld, wie es bin/console system:config:set ohne --json speichert –, wobei Einstellung, gespeicherter und erwarteter Typ genannt werden, nie der Wert selbst; zeigt in einer Zeile, wie viele nicht mehr bekannte Einstellungen (siehe coe:bot-shield:config:prune) gespeichert sind, und nennt den Befehl zum Aufräumen, ohne dass sich die Gesamtbewertung dadurch ändert; zeigt, wie viele Funde des LLM-Analysten oberhalb des Konfidenz-Schwellwerts von den Schutzregeln zurückgehalten wurden — getrennt nach „kein Rechenzentrumsnetz“ und „keine Signatur ausgelöst“, jeweils als Zahl der Netze und Treffer im Aufbewahrungszeitraum des Protokolls und in den letzten 24 Stunden; und zählt die Sperren des KI-Analysten — getrennt nach scharf geschaltet und beobachtet, über den Aufbewahrungszeitraum des Protokolls und die letzten 24 Stunden. Zusammen mit der Zeile zu den von Schutzregeln gehaltenen Funden ist damit ohne Datenbankzugriff ablesbar, ob der KI-Analyst überhaupt zum Sperren kommt.
-
Hinweis: Wird der Seiten-Cache von einem vorgeschalteten Server oder CDN bedient, sieht der Shop die Seitenaufrufe nicht und die Erkennung bleibt wirkungslos. bin/console coe:bot-shield:config:doctor sagt für den eigenen Shop, welcher Fall vorliegt.
-
Entfernt: Die NAT-Freistellung für geteilte Provider-Anschlüsse mit ihren Einstellungen „NAT-Freistellung“ und „Schwellwert für NAT-Sitzungsvielfalt“. Sie hat nie gegriffen, weil sie ein Sitzungs-Cookie voraussetzte, das die Storefront nicht setzt. Damit ist der Hinweis aus 7.0.0, Kunden hinter geteilten Provider-Anschlüssen würden „an ihrem echten Browser- und Sitzungsverhalten erkannt und nicht mehr automatisch gesperrt“, zurückgenommen. Für bekannte geteilte Adressen bleibt die Freigabeliste das Mittel der Wahl; angemeldete Stammkunden schützt weiterhin die Kunden-Freistellung.
-
Entfernt: Die Einstellungen „Rate-Limit für sonstige Anfragen/Assets“ und „Rate-Limit-Fenster (Sekunden)“. Das Fenster beträgt fest 60 Sekunden, die Grenze für sonstige Anfragen fest 300 Anfragen pro Fenster — die bisherigen Standardwerte. Ein selbst gesetzter Wert wird nicht mehr verwendet.
-
Entfernt: Die vier Einstellungen zur User-Agent-Rotations- und Monokultur-Flotte. Die Erkennung arbeitet unverändert mit den bisherigen Standardwerten (5 User-Agents je Adresse, 3 rotierende Adressen, höchstens 2 User-Agents, 10 Adressen). Ein selbst gesetzter Wert wird nicht mehr verwendet; es gelten die Standardwerte.
-
Entfernt (Pro): Die LLM-Klassifizierung automatisch gesperrter Netze als Rechenzentrumsnetze und ihr Schalter in den Einstellungen des LLM-Analysten. Sie hat im Praxisbetrieb kein Netz eingestuft; Netze werden nun allein anhand der mitgelieferten Liste als Rechenzentrumsnetz erkannt, alle anderen erhalten bei einer automatischen Sperre wie bisher die Sicherheitsprüfung statt einer harten Ablehnung. Es werden keine Netzpräfixe mehr an den LLM-Anbieter gesendet. Damit ist der Hinweis aus 7.0.1 zurückgenommen.
Shopware