Bedienung für Shop-Betreiber

Diese Anleitung richtet sich an Shop-Betreiber und Mitarbeitende im OXID-Admin. Sie setzt keinen Server- oder Programmierzugriff voraus. Installation, Update, technische Datenbankpflege und vollständiges Löschen aller Laufzeitdaten sind unter Installation für Agenturen beschrieben.

Schnellstart

1. Öffnen Sie Erweiterungen ‣ Module ‣ BotProtection ‣ Einstell..

2. Lassen Sie Bot-Protection aktivieren eingeschaltet und wählen Sie zunächst Passiv (Nur Logging).

3. Prüfen Sie zuerst die leeren IP- und Länder-Blacklists. Kontrollieren Sie danach die voreingetragenen Länder de, at und ch sowie beide Länder-Checkboxen. Lassen Sie unbekannte IPs oder User-Agents nicht vorsorglich frei.

4. Speichern Sie und beobachten Sie unter eComStyle.de ‣ BotProtection mindestens einen typischen Geschäftszeitraum.

5. Testen Sie Gast-Checkout, Anmeldung, Zahlungsarten, Monitoring, Suchmaschinen und externe Schnittstellen.

6. Wechseln Sie anschließend auf Moderat (Empfohlen). Verwenden Sie Aggressiv (Max. Schutz) erst nach einer Auswertung oder bei einer akuten Angriffslage.

Tipp

Ändern Sie immer nur wenige Regeln gleichzeitig und notieren Sie Zeitpunkt und Grund. So lässt sich ein Anstieg bestimmter Dashboard-Gründe einer Einstellung zuordnen.

Wer wird geprüft?

BotProtection greift früh im Storefront-Aufruf ein. Erkannte Admin-Aufrufe bleiben ausgenommen. Bei allen anderen Storefront-Aufrufen werden zuerst die expliziten IP- und Länder-Blacklists geprüft. Deshalb können Blacklists auch einen angemeldeten Kunden, einen gefüllten Warenkorb, eine freigegebene IP oder einen Searchbot sperren.

Nach den Blacklists werden zuerst passend konfigurierte technische Endpoints und danach angemeldete Kunden sowie Sessions mit mindestens einem Artikel im Warenkorb von den übrigen Bot-Prüfungen ausgenommen. Für anonyme Besucher, Gastkunden und andere automatisierte Clients gilt anschließend vereinfacht diese Reihenfolge:

1. Öffentliche Crawler-Dateien wie robots.txt, Sitemap-Dateien, llms.txt oder ai.txt werden ohne Challenge ausgeliefert, sofern keine Blacklist gegriffen hat.

2. Vertrauenswürdig erkannte Searchbots werden entsprechend der Force-SID- und Länderoptionen behandelt.

3. Eine passende IP-Whitelist gibt den Request vollständig frei.

4. Die Länder-Whitelist entscheidet, ob ein Whitelist-Land ungeprüft freigegeben wird. Optional werden alle Länder außerhalb der Liste sofort gesperrt.

5. Force-SID wird geprüft. Notwendige POST-, Warenkorb-, Login- und Vergleichslistenaktionen werden nicht allein wegen Force-SID abgewiesen.

6. Eine passende User-Agent-Whitelist gibt den Request für die danach folgenden Prüfungen frei.

7. Force-SID-Wiederverwendung, bestehende temporäre Sperren, IP- und Subnetz-Rate-Limit, Honeypot, Bot-Signatur, Verhalten, Scan-Challenge und Browser-Fingerprint folgen.

Achtung

Blacklists haben immer Vorrang vor Whitelists und Searchbot-Ausnahmen. Ein Land oder eine IP sollte deshalb nicht gleichzeitig auf einer Freigabe- und Sperrliste stehen. Die Länder-Whitelist und die User-Agent-Whitelist haben unterschiedliche Reichweiten: Eine vollständig freigegebene Länder-IP umgeht auch Force-SID; die User-Agent-Whitelist wird erst nach der normalen Force-SID-Prüfung ausgewertet.

Haupteinstellungen

Haupteinstellungen

Einstellung	Standard	Wirkung
Bot-Protection aktivieren	Ein	Schaltet alle Storefront-Prüfungen ein. Bei „Aus“ werden Requests ohne Erkennung, Protokollierung oder automatische Modulbereinigung an OXID weitergegeben. Das OXID-Modul selbst kann trotzdem aktiv bleiben.
Schutzmodus	Moderat	Wählt aggressiv, moderat oder passiv. Der Modus ersetzt die sichtbaren Zahlenfelder nicht automatisch.

Schutzmodi

Passiv (Nur Logging) führt die Erkennung aus und protokolliert Treffer, sendet aber weder 403-Antworten noch Challenges oder neue temporäre Sperren. Das Dashboard bezeichnet diese Treffer weiterhin als „blockiert“; gemeint ist, was im aktiven Betrieb blockiert worden wäre.

Moderat (Empfohlen) wendet die aktivierten Regeln und die eingetragenen Grenzwerte an. Ein fehlender Browser-Fingerprint führt bei eingeschalteter JavaScript-Challenge zur Browserprüfung. Ist die Challenge ausgeschaltet, wird allein wegen dieses Fingerprints im moderaten Modus nicht gesperrt.

Aggressiv (Max. Schutz) arbeitet ebenfalls mit den eingetragenen Grenzwerten. Zusätzlich kann ein fehlender Browser-Fingerprint auch dann zur Sperre führen, wenn die JavaScript-Challenge ausgeschaltet ist.

Rate-Limiting

Rate-Limiting

Einstellung	Standard	Wirkung
Max. Requests pro Zeitfenster	20	Erlaubte Requests einer anonymen IP im Zeitfenster. Erst der nächste Request oberhalb des Werts gilt als Treffer.
Zeitfenster (Sekunden)	60	Zeitraum für den IP-Zähler. Nach Ablauf beginnt der Zähler mit dem nächsten Request neu.
Max. Requests pro Subnetz-Zeitfenster	120	Gemeinsames Limit eines IPv4-/24- oder IPv6-/64-Netzes. 0 oder ein negativer Wert deaktiviert nur dieses Subnetz-Limit.
Subnetz-Zeitfenster (Sekunden)	60	Zeitraum des gemeinsamen Subnetzzählers; Werte unter 30 Sekunden werden wie 30 Sekunden behandelt.
Block-Dauer (Sekunden)	3600	Dauer einer temporären IP-Sperre nach Force-SID oder Honeypot. Ein bloßer Rate-Limit-, Signatur-, Verhaltens- oder Länder-Treffer legt keine solche separate Langzeitsperre an.

Achtung

Ein knappes Subnetz-Limit kann viele unabhängige Kunden eines Mobilfunknetzes, Unternehmens, Providers oder Proxys gemeinsam treffen. Beobachten Sie deshalb sowohl IP- als auch Subnetztreffer im passiven Modus.

Erkennungs-Features

Erkennungs-Features

Einstellung	Standard	Wirkung
Force-SID Bots blockieren (Cookie-less)	Ein	Erkennt force_sid in GET, POST oder URL. Die Prüfung erfolgt vor normalen Whitelists und kann eine temporäre IP-Sperre setzen.
Force-SID Strategie	Sofort blockieren	block reagiert beim ersten Treffer. threshold zählt Treffer derselben IP innerhalb eines eigenen Zeitfensters.
Force-SID Schwellwert (Anzahl Treffer)	3	Anzahl für die Strategie „Schwellwert“. Werte unter 1 werden wie 1 behandelt.
Force-SID Zeitfenster (Sekunden)	300	Zählzeitraum der Schwellwertstrategie; mindestens 30 Sekunden.
Force-SID Reuse-Schwellwert (Anzahl IPs)	5	Erkennt, wenn dieselbe force_sid innerhalb des Reuse-Zeitfensters von mindestens so vielen verschiedenen IP-Adressen verwendet wird. Werte unter 2 werden wie 2 behandelt.
Force-SID Reuse-Zeitfenster (Sekunden)	3600	Zeitraum für die Wiederverwendungsprüfung; mindestens 60 Sekunden. Die Erkennung hilft gegen Scraper, die IP-Adressen wechseln, aber eine gemeinsame Session-ID weiterverwenden.
Bot-User-Agents blockieren	Ein	Erkennt einen leeren User-Agent, bekannte Bot-/Crawler-/Scraper- und Automatisierungsbegriffe sowie bestimmte unplausible alte Browserkennungen. Länderregeln und normale Force-SID-Prüfung wurden zu diesem Zeitpunkt bereits ausgewertet.
Verhaltensbasierte Erkennung	Ein	Prüft wiederholte Abrufe derselben URL und viele verschiedene URLs ohne Referer anhand der folgenden drei Werte.
Verhaltens-Schwellwert (Anzahl Requests auf dieselbe URL)	5	Ab dieser Zahl von Abrufen derselben URL im Zeitfenster gilt das Verhalten als auffällig. Ungültige Werte werden auf 5 zurückgesetzt.
Verhaltens-Schwellwert (Anzahl verschiedener URLs ohne Referer)	3	Mehr als diese Zahl verschiedener URLs ohne Referer gilt als auffällig. 0 deaktiviert nur diese Teilprüfung.
Verhaltens-Zeitfenster (Sekunden)	300	Gemeinsamer Beobachtungszeitraum; Werte unter 10 Sekunden werden auf 300 Sekunden zurückgesetzt.
Browser-Fingerprint prüfen	Ein	Prüft, ob Accept-Language, Accept-Encoding oder Accept fehlen. Je nach Modus und Challenge-Einstellung folgt eine Prüfung oder Sperre.
JavaScript-Challenge verwenden	Ein	Zeigt bei geeigneten verdächtigen Requests eine Sicherheitsprüfung, setzt per JavaScript ein Cookie für bis zu 24 Stunden und lädt die ursprüngliche URL nach zwei Sekunden neu.
Auffällige Scan-Requests per JavaScript prüfen	Ein	Prüft anonyme GET-Aufrufe ohne Cookies und Referer, mit Sprache exakt en und typischem HTML-Accept-Header. Statische Dateien sind ausgenommen. Funktioniert nur zusammen mit der JavaScript-Challenge.
Honeypot aktivieren	Aus	Prüft, ob der Request den Parameter ref_id enthält. Ein Treffer wird protokolliert und kann die IP temporär sperren. Damit die Falle auslöst, muss im Storefront-Template ein unsichtbarer Link mit ref_id=… eingebaut werden (siehe Installation für Agenturen).

Wichtig

Die Einstellung allein fügt keinen Link in den Shop ein. Ohne einen entsprechenden Honeypot-Link im Template bleibt die Prüfung wirkungslos. Verwenden Shop oder Erweiterungen bereits den Parameter ref_id, darf der Honeypot nicht aktiviert werden, weil sonst echte Besucher gesperrt werden.

JavaScript-Challenge aus Kundensicht

Ein verdächtiger Browser sieht eine Seite „Sicherheitsüberprüfung“ mit Ladeanzeige. Nach zwei Sekunden wird die ursprünglich angeforderte Adresse neu geladen. Das Cookie ist an aktuelle IP, User-Agent, Shop-Schlüssel und den Tag gebunden. Browser ohne JavaScript oder Cookies, Datenschutzwerkzeuge mit Cookie-Sperre sowie ein IP-Wechsel können zu wiederholten Prüfungen führen.

Whitelist, Blacklist und Länderregeln

Listenfelder enthalten einen Wert pro Eintrag. Länder werden als zweistellige Codes wie de, at, ch, fr oder us gepflegt. Blacklists werden vor allen Freigaben ausgewertet.

Listen und Suchmaschinen

Einstellung	Standard	Wirkung
IP-Blacklist	Leer	Sperrt passende IPs sofort per Präfixvergleich. Die Sperre gilt auch für angemeldete Kunden, Warenkörbe, Whitelists und Searchbots.
Länder-Blacklist (z.B. cn, ru)	Leer	Sperrt ein erkanntes Land sofort. Ein Eintrag auf der Länder-Whitelist hebt diese Sperre nicht auf.
IP-Whitelist (z.B. 192.168.)	Leer	Gibt IPs über einen Präfixvergleich vollständig frei. 192.168. trifft alle so beginnenden Adressen; es handelt sich nicht um eine CIDR-Auswertung. Blacklists wurden vorher bereits geprüft.
User-Agent Whitelist	Vordefinierte Such-, KI- und Vorschau-Crawler	Gibt passende User-Agents nach Länderregel und normaler Force-SID- Prüfung für die späteren Prüfungen frei. Der Vergleich unterscheidet nicht zwischen Groß- und Kleinschreibung. Ein User-Agent kann gefälscht werden.
Ausgenommene technische Endpoints	cl=amazondispatch&action=ipn&method=POST	Nimmt passende Server-zu-Server-Aufrufe wie Zahlungs-Webhooks und IPNs von den automatischen Bot-Prüfungen aus. Alle Bedingungen einer Zeile müssen übereinstimmen; explizite IP- und Länder-Blacklists behalten Vorrang.
Suchmaschinen-Bot Verifikation	DNS Verifikation	off vergibt keinen besonderen Searchbot-Status, ua vertraut allein einem passenden User-Agent und dns verlangt für Google und Bing zusätzlich einen passenden Reverse- und Forward-DNS-Nachweis.
Searchbot Cache TTL (Sekunden)	86400	Speichert positive und negative DNS-Prüfergebnisse je IP; mindestens 60 Sekunden.
Searchbots trotz Force-SID zulassen	Ein	Nimmt als vertrauenswürdig erkannte Searchbots von der normalen Force-SID-Sperre aus.
Searchbots dürfen Länder-Regeln umgehen	Ein	Lässt vertrauenswürdig erkannte Searchbots unabhängig von Länder-Whitelist und Nicht-Whitelist-Sperre passieren. IP- und Länder-Blacklists behalten Vorrang.
Länder-Whitelist (z.B. de, at, ch)	de, at, ch	Gemeinsame Liste für alle Länderfreigaben. Was ein Listeneintrag bewirkt, bestimmen die beiden folgenden Checkboxen.
Whitelist-Länder ohne weitere Bot-Prüfung freigeben	Ein	Gibt ein Whitelist-Land nach den Blacklists vollständig frei. Force-SID, temporäre Sperren, Rate-Limits, Signatur, Verhalten und Fingerprint werden dann nicht mehr geprüft.
Alle Länder außerhalb der Whitelist sofort sperren	Aus	Sperrt bei Aktivierung jedes Land außerhalb der Liste sofort. Dazu gehört auch das unbekannte Land ?. Bei leerer Whitelist bleibt die Regel aus Sicherheitsgründen wirkungslos.

Technische Endpoints, Webhooks und IPNs ausnehmen

Das Listenfeld Ausgenommene technische Endpoints enthält eine Regel pro Zeile. Es ist für automatische Server-zu-Server-Aufrufe vorgesehen, die keine Browser-Cookies setzen und keine JavaScript-Challenge beantworten können, beispielsweise Zahlungsbenachrichtigungen, Webhooks oder IPNs.

Für Amazon Pay ist standardmäßig folgende Regel eingetragen:

cl=amazondispatch&action=ipn&method=POST

Die Bestandteile werden mit & verbunden. Jeder angegebene Bestandteil muss im Request vorhanden sein und übereinstimmen. Die Reihenfolge in der tatsächlichen URL ist unerheblich; zusätzliche Parameter wie shp=1 sind zulässig. method bezeichnet die HTTP-Methode und ist kein URL-Parameter. Darum passt die Standardregel beispielsweise auf folgenden Aufruf:

index.php?cl=amazondispatch&action=ipn&shp=1

wenn er per POST eingeht.

Regeln dürfen bewusst weniger Bedingungen enthalten. Die folgenden beiden Schreibweisen geben alle Aktionen des Controllers amazondispatch frei:

cl=amazondispatch
amazondispatch

Auch andere Kombinationen wie action=callback&method=POST oder nur method=POST sind technisch möglich. Je allgemeiner eine Regel ist, desto mehr Shop-Aufrufe umgehen jedoch Länderprüfung, Force-SID, temporäre Sperren, Rate-Limits, Bot-Signatur, Verhaltensprüfung, Browser-Fingerprint und JavaScript-Challenge.

Warnung

Verwenden Sie möglichst genaue Regeln aus Controller, Aktion und HTTP-Methode. Eine Regel wie nur method=POST würde sämtliche POST- Aufrufe freigeben und ist für einen öffentlichen Shop normalerweise ungeeignet. Die Ausnahme bestätigt nicht, dass ein Request wirklich vom genannten Zahlungsanbieter stammt. Signatur-, Token- oder sonstige Echtheitsprüfungen muss das jeweilige Schnittstellen- oder Zahlungsmodul weiterhin selbst durchführen. Explizite IP- und Länder-Blacklists werden auch bei einer passenden Endpoint-Regel zuerst ausgewertet.

Die beiden Länder-Checkboxen ergeben vier verständliche Betriebsarten:

Wirkung der Länder-Checkboxen

Whitelist-Länder ungeprüft	Andere Länder sperren	Ergebnis
Aus	Aus	Alle Länder durchlaufen die normalen Bot-Prüfungen.
Ein	Aus	Whitelist-Länder werden vollständig freigegeben; alle anderen Länder durchlaufen die normalen Bot-Prüfungen.
Aus	Ein	Nur Whitelist-Länder dürfen weiterlaufen und werden anschließend normal geprüft. Nicht-Whitelist-Länder werden sofort gesperrt.
Ein	Ein	Whitelist-Länder werden vollständig freigegeben; alle anderen Länder werden sofort gesperrt.

Warnung

Halten Sie IP- und User-Agent-Whitelists so klein wie möglich. Allgemeine Präfixe oder Begriffe können mehr Teilnehmer freigeben als beabsichtigt. Verwenden Sie für Google und Bing bevorzugt die DNS-Verifikation. Prüfen Sie vor einer harten Länderbeschränkung, aus welchen Ländern Kunden, Zahlungsanbieter, Monitoring, Warenwirtschaft und Suchmaschinen tatsächlich zugreifen.

Bemerkung

Zusätzlich zur bearbeitbaren User-Agent-Whitelist kennt das Modul fest eingebaute Ausnahmen für verbreitete KI-, Antwort- und Vorschau-Crawler, beispielsweise GPTBot, ClaudeBot, PerplexityBot, Applebot, Amazonbot und CCBot. Diese Ausnahmen greifen erst nach Blacklists, Länderregeln und normaler Force-SID-Prüfung. Das Entfernen eines solchen Namens aus dem Listenfeld allein erzwingt deshalb noch keine spätere Signaturprüfung.

Lokale Länderermittlung

Die Länderprüfung liest eine lokale IPv4-/IPv6-Datenbank und führt dafür im Storefront-Request weder HTTP- noch Reverse-DNS-Anfragen aus. Nur die optionale Suchmaschinen-DNS-Verifikation kann Netzabfragen auslösen; ihr Ergebnis wird gecacht.

Kann eine IP keinem gültigen zweistelligen Land zugeordnet werden, erscheint ?. Solange Alle Länder außerhalb der Whitelist sofort sperren ausgeschaltet ist, durchläuft der Request die normalen Bot-Prüfungen. Bei aktivierter Sperre zählt ? als nicht auf der Whitelist und wird abgewiesen. Ist die Länder-Whitelist leer, bleibt die Sperre als Schutz vor einer versehentlichen Komplettsperre wirkungslos.

Logging und Monitoring

Logging und Monitoring

Einstellung	Standard	Wirkung
Logging aktivieren	Ein	Speichert erkannte Treffer mit Zeit, IP, Grund, URL, User-Agent, Land und Referer. Ohne Logging bleiben Schutzregeln aktiv, Dashboard-Historie und E-Mail-Schwellwert erhalten aber keine neuen Treffer.
Log-Aufbewahrung (Tage)	7	Alter, ab dem die automatische SQLite-Bereinigung Aktivitäten löscht; mindestens ein Tag. Die manuelle Dashboard-Aktion verwendet ihren eigenen dort gewählten Wert.
Temporäre Daten automatisch bereinigen	Ein	Entfernt in Abständen abgelaufene Rate-, Subnetz-, Sperr-, Challenge-, Verhaltens- und Cachezustände sowie alte Logs.
Cleanup-Intervall (Sekunden)	600	Mindestabstand zwischen zwei durch Storefront-Aufrufe ausgelösten Bereinigungsläufen; mindestens 60 Sekunden.
Cleanup-Batchgröße	10000	Begrenzt die Zahl der je Lauf bearbeiteten Datensätze beziehungsweise Dateien. Sehr kleine oder sehr große Werte werden intern begrenzt.
Maximale Speichergröße (MB)	200	Löscht bei Überschreitung zuerst abgelaufene Zustände und danach die ältesten Aktivitäten beziehungsweise Fallback-Dateien. 0 schaltet diese Größenbegrenzung aus; positive Werte unter 10 gelten als 10 MB.
Benachrichtigungs-E-Mail	Leer	Empfänger einer einfachen Angriffswarnung. Nur eine syntaktisch gültige Adresse wird verwendet.
Benachrichtigungs-Schwellwert	1000	Zahl protokollierter Treffer seit Tagesbeginn, ab der höchstens einmal pro Kalendertag eine Mail versendet wird. Passive Treffer zählen mit.

Achtung

Protokolle enthalten IP-Adressen, URLs, User-Agents und Referer. Legen Sie Aufbewahrungsdauer, Zugriffsrechte, Datenschutzhinweise und Löschprozess passend zu Ihrem Betrieb fest. Das Modul trifft keine rechtliche Bewertung und garantiert keine datenschutzrechtliche Zulässigkeit.

Dashboard bedienen

Öffnen Sie eComStyle.de ‣ BotProtection.

Statusmeldungen

Oben sehen Sie, ob der moduleigene SQLite-Speicher aktiv ist. Bei aktivem SQLite zeigt das Dashboard den Datenbankpfad; der technische Dienstleister kann ihn für Sicherung und Diagnose verwenden. Eine rote Meldung zum Datei-Fallback sollte an die Agentur weitergegeben werden.

Ein orangefarbener Hinweis kennzeichnet den passiven Modus. In diesem Modus sind die Zahlen simulierte Sperrtreffer, keine tatsächlich abgewiesenen Requests.

Schutzempfehlungen prüfen

Der Abschnitt Schutzempfehlungen vergleicht die aktuellen Moduleinstellungen mit den vorhandenen Erkennungsdaten. Bei SQLite werden bis zu sieben Tage betrachtet; beim Datei-Fallback aus Performancegründen nur der heutige Tag. Mögliche Hinweise betreffen unter anderem:

• deaktiviertes Logging oder passiven Schutzmodus,

• widersprüchliche beziehungsweise leere Länderlisten,

• Searchbot-Länderfreigabe ohne DNS-Verifikation,

• einen hohen Force-SID-Anteil,

• einen sehr hohen Anteil erkannter Bot-Aktivität außerhalb der Länder-Whitelist,

• fehlende oder auffällig unvollständige GeoIP-Daten und

• stark auf eine IP konzentrierte Treffer ohne häufiges Rate-Limit.

Jede Karte nennt Begründung, aktuelle und vorgeschlagene Einstellung, Konfidenz und Risiko. Konfidenz beschreibt, wie eindeutig die vorhandenen Daten zur Regel passen. Risiko beschreibt, wie leicht eine Verschärfung auch echte Besucher treffen könnte.

Wichtig

Der Schutzberater ändert keine Moduleinstellung. Prüfen Sie insbesondere Empfehlungen mit hohem Risiko gemeinsam mit der Agentur und testen Sie sie zuerst im passiven Modus. Die erste Ausbaustufe arbeitet mit Erkennungsereignissen; sie kennt noch nicht jeden unauffällig oder per Ausnahme durchgelassenen Request und nicht jede erfolgreich bestandene Challenge.

Statistiken verstehen

Die Trefferzahlen umfassen heute, die letzten sieben Tage einschließlich heute und die letzten 30 Tage einschließlich heute. Die zugehörigen Request-Zähler werden bei jedem nicht administrativen Storefront-Aufruf vor späteren Ausnahmen erhöht. Der Tageszähler gilt für heute, der Wochenzähler für die aktuelle Kalenderwoche und der Monatszähler für den aktuellen Kalendermonat. Die Prozentanzeige ist deshalb besonders am Wochen- oder Monatsanfang nur ein Orientierungswert. Die Tabellen für Gründe, Top-IP-Adressen, URLs und Herkunftsländer zeigen aus Performancegründen nur den heutigen Tag.

Das Aktivitätsprotokoll enthält ausschließlich gespeicherte Erkennungsereignisse, kein vollständiges Webserver-Zugriffsprotokoll. Ein Dashboard-„Treffer“ ist nicht in jedem Fall eine tatsächlich ausgelieferte 403-Sperre: Im passiven Modus wird nur beobachtet, und eine JavaScript-Challenge kann technisch mit HTTP 200 ausgeliefert werden. Freigegebene, angemeldete oder unauffällige Requests erscheinen nicht im Aktivitätsprotokoll; einzelne Browserprüfungen müssen nicht als eigener Aktivitätseintrag vorliegen.

Häufige Gründe einordnen

Erkennungsgründe im Dashboard

Grund	Bedeutung
blacklist	IP oder Land stand auf einer expliziten Blacklist. Diese Prüfung hat Vorrang vor allen Freigaben.
country_not_whitelisted	Das Land stand nicht auf der Länder-Whitelist, während die Sperre aller Nicht-Whitelist-Länder aktiv war. Dazu kann auch ? gehören.
force_sid	Eine anonyme, nicht ausgenommene Anfrage verwendete force_sid und erreichte die konfigurierte Strategie beziehungsweise Schwelle.
force_sid_reuse	Dieselbe force_sid wurde im Reuse-Zeitfenster von zu vielen verschiedenen IP-Adressen verwendet.
rate_limit / subnet_rate_limit	Eine einzelne IP beziehungsweise ihr IPv4-/24- oder IPv6-/64-Netz überschritt das konfigurierte Request-Limit.
signature	User-Agent oder Browserkennung passte zu einer aktivierten Bot-Signaturregel.
behavior	Wiederholungen derselben URL oder viele verschiedene URLs ohne Referer überschritten einen Verhaltensschwellwert.
honeypot	Der Parameter ref_id löste die eingerichtete Falle aus.
scan_challenge / fingerprint	Ein auffälliger Scan-Request oder fehlende typische Browser-Header führten zur protokollierten Browserprüfung.
temp_blocked	Die IP war bereits temporär gesperrt und rief den Shop erneut auf.

Unter Aktueller Status sehen Sie aktive IP-Rate-Zähler, temporär blockierte IPs, Verhaltensprofile und Force-SID-Zähler. Diese Laufzeitwerte sind keine historische Angriffszahl und verschwinden nach Ablauf oder Bereinigung.

IP entsperren

Wählen Sie in der Tabelle Top 20 blockierte IP-Adressen die Schaltfläche IP entsperren. Entfernt wird ausschließlich eine aktuelle temporäre Sperre dieser IP. Blacklist, Länderregel und bereits protokollierte Aktivitäten bleiben unverändert.

Die Top-Liste enthält alle heutigen Treffer, nicht nur aktive temporäre Sperren. Deshalb ist „Keine Sperre gefunden“ ein mögliches und korrektes Ergebnis.

GeoIP-Datenbank aktualisieren

Der Abschnitt Lokale GeoIP-Datenbank zeigt Datenstand, Quelle und Anzahl der IPv4-/IPv6-Bereiche. Wählen Sie GeoIP-Datenbank jetzt aktualisieren, um einen neuen geprüften Satz zu laden. Die Schaltfläche bleibt deaktiviert, wenn PHP-cURL fehlt oder das Laufzeitverzeichnis nicht beschreibbar ist.

Das Update wird nur durch diese Aktion oder ein Modulpaket aktualisiert; es läuft nicht automatisch im Storefront-Request. Bei einer Fehlermeldung bleibt die bisherige gültige beziehungsweise die mitgelieferte Datenbank verfügbar.

Daten aufräumen

Geben Sie im Abschnitt Daten aufräumen ein Alter zwischen 1 und 365 Tagen ein und wählen Sie Jetzt aufräumen. Alte Aktivitätsprotokolle und bereits abgelaufene Laufzeitzustände werden entfernt. Aktuelle Sperren, Moduleinstellungen und GeoIP-Daten bleiben erhalten.

Für einen vollständigen Reset sämtlicher BotProtection-Daten ist die Agentur zuständig; dieser Vorgang ist bewusst nicht als Dashboard-Schaltfläche angeboten.

E-Mail-Benachrichtigung

Bei aktivem Logging, gültiger Empfängeradresse und positivem Schwellwert prüft das Modul nach jedem protokollierten Treffer die Tageszahl. Beim erstmaligen Erreichen des Werts sendet es eine Textmail mit Anzahl, Shop-URL und Zeitpunkt. Weitere Treffer desselben Tages lösen keine zweite Mail aus.

Die Nachricht ist ein Alarm, keine Eingangsbestätigung oder automatische Sicherheitsanalyse. Sie enthält keine vollständige Liste betroffener IPs und setzt weder eine Firewall-Regel noch eine Supportmeldung ab. Prüfen Sie bei ausbleibenden Mails zuerst Logging, Tageszahl und die vom Hoster bereitgestellte Mailfunktion.

Empfohlene Grundeinstellung

Für einen normalen Live-Start:

• passiv beginnen, danach moderat aktivieren,

• IP-Limit 20 in 60 Sekunden und Subnetz-Limit 120 in 60 Sekunden nur anhand echter Zugriffsmuster anpassen,

• Force-SID standardmäßig sofort sperren; bei Shops oder Integrationen, die noch URL-Sessions benötigen, zuerst die Schwellwertstrategie im passiven Modus testen,

• die Reuse-Werte 5 IPs in 3600 Sekunden zunächst beibehalten und nur bei nachvollziehbaren Fehl- oder Nichttreffern ändern,

• JavaScript-Challenge eingeschaltet lassen und wiederholte Prüfungen beobachten,

• de, at und ch als voreingetragene Länder-Whitelist prüfen; Whitelist-Länder werden standardmäßig vollständig freigegeben, andere Länder aber nicht pauschal gesperrt,

• die Sperre aller Nicht-Whitelist-Länder nur bei einem klaren Geschäftsgrund und nach Prüfung von Searchbots, Zahlungsanbietern und Schnittstellen aktivieren,

• für Google und Bing die DNS-Verifikation verwenden,

• User-Agent- und IP-Whitelist klein halten,

• Logging mit sieben Tagen Aufbewahrung, automatischer Bereinigung und 200-MB-Grenze beginnen,

• Schutzempfehlungen als Entscheidungshilfe verwenden, nicht ungeprüft übernehmen, und

• Dashboard regelmäßig sowie nach Shop-, Theme-, Proxy- oder Schnittstellenänderungen prüfen.

Nicht automatisierte Aufgaben und Grenzen

BotProtection erledigt insbesondere nicht automatisch:

• Netzwerk- oder volumetrischen DDoS-Schutz vor Webserver und PHP,

• Einrichtung von Firewall, CDN, WAF, Reverse Proxy oder vertrauenswürdigen Client-IP-Headern,

• robots.txt-Regeln, Suchmaschinenregistrierung oder SEO-Bewertung,

• sicheren Nachweis jeder Bot-Identität; User-Agents können gefälscht werden,

• Erkennung fachlich betrügerischer Bestellungen oder Zahlungsbetrug,

• rechtliche Prüfung von Länderblockaden, Protokollierung oder Aufbewahrungsfristen,

• automatische GeoIP-Aktualisierung im Hintergrund,

• automatische Übernahme der Schutzempfehlungen oder Bearbeitung eines E-Mail-Alarms,

• vollständige Klassifikation aller ungeprüft freigegebenen Requests und bestandenen Challenges sowie

• vollständiges Löschen aller Laufzeitdaten oder Zurücksetzen der Moduleinstellungen.

Prüfung vor dem Live-Betrieb

Prüfen Sie mit der Agentur:

• Startseite, Suche, Kategorien, Detailseiten und statische Ressourcen,

• Warenkorb und Checkout als Gast sowie als angemeldeter Kunde,

• alle Zahlungsweiterleitungen und Webhooks,

• Monitoring, Preisportale, Warenwirtschaft, Feeds und sonstige Clients,

• Suchmaschinenzugriff und bewusst gesetzte Ausnahmen,

• Challenge mit und ohne JavaScript beziehungsweise Cookies,

• eine kontrollierte Fehlblockierung und die Freigabe im Dashboard,

• passive Dashboard-Gründe über einen repräsentativen Zeitraum,

• korrekte Herkunfts-IP hinter Proxy oder CDN sowie

• Datenschutz, Löschfristen und Zuständigkeit für Alarme.

Häufige Fehler

Echte Kunden erhalten „Access Denied“

Stellen Sie sofort auf passiv, ohne das Modul zu deaktivieren. Suchen Sie im Dashboard nach Zeitpunkt, IP, URL und Grund. Prüfen Sie besonders zu niedrige IP-/Subnetzgrenzen, Force-SID, Länderregeln und fehlende Browser-Header. Setzen Sie eine Freigabe erst, wenn die betroffene IP oder Kennung zuverlässig identifiziert ist.

Sicherheitsüberprüfung erscheint immer wieder

Der Browser kann das Challenge-Cookie möglicherweise nicht setzen, JavaScript ist blockiert, IP oder User-Agent wechseln oder die Serverzeit stimmt nicht. Testen Sie ohne Browsererweiterungen und lassen Sie Proxy- sowie Cookie-Setup von der Agentur prüfen.

Zu viele Besucher teilen dieselbe IP

Das ist häufig ein Proxy-/CDN-Problem oder ein gemeinsamer Unternehmens- oder Mobilfunkzugang. Geben Sie nicht vorschnell die gemeinsame Adresse frei. Lassen Sie zuerst prüfen, ob OXID die echte Besucher-IP erhält, und passen Sie danach IP- und Subnetz-Limit anhand realer Daten an.

Suchmaschine wird blockiert

Prüfen Sie Schreibweise der User-Agent-Whitelist, Verifikationsmodus, DNS-Erreichbarkeit und Force-SID-Sonderregel. Beachten Sie, dass das großzügige Freigeben allgemeiner Begriffe auch nachgeahmte Clients passieren lässt.

Land ist unbekannt oder offensichtlich falsch

Prüfen Sie den im Dashboard angezeigten GeoIP-Datenstand und starten Sie bei Bedarf ein Update. ? bedeutet „nicht ermittelt“. Bei ausgeschalteter Nicht-Whitelist-Sperre bleibt die normale Bot-Prüfung aktiv; bei eingeschalteter Sperre wird ? abgewiesen. IP-Länderdaten sind Näherungswerte und können bei VPN, Mobilfunk oder neuen Netzen abweichen.

Dashboard zeigt „SQLite-Speicher nicht aktiv“

Das Modul arbeitet mit dem Datei-Fallback weiter. Melden Sie Warnung und Fehlertext an die Agentur; pdo_sqlite muss in der Webserver-PHP-Version aktiviert und das Logverzeichnis beschreibbar sein.

Dashboard ist leer

Prüfen Sie Bot-Protection aktivieren und Logging aktivieren. Angemeldete Personen und Admin-Aufrufe werden nicht protokolliert. Die Detailtabellen zeigen nur den heutigen Tag; ältere Aktivitäten können bereits durch Aufbewahrung oder Größenbegrenzung gelöscht worden sein.

E-Mail-Alarm kommt nicht an

Prüfen Sie gültige Empfängeradresse, positiven Schwellwert, aktives Logging und ob der Wert heute tatsächlich erreicht wurde. Pro Tag wird höchstens eine Mail versendet. Wenn alles stimmt, muss die Agentur beziehungsweise der Hoster die PHP-Mailfunktion und Zustellung prüfen.