Was du in diesem Beitrag erfährst
Warum wird mein Shop langsam, obwohl keine Kunden bestellen?
Du erfährst, warum ausgerechnet die Filtersuche im JTL Shop ein bevorzugtes Angriffsziel ist.
Warum reicht ein klassisches Rate-Limit nicht mehr aus?
Du erfährst, warum verteilte Angriffe über tausende Adressen jedes einfache Limit umgehen.
Wie erkennt snafu BotBlock echte Angriffe zuverlässig?
Du erfährst, wie ein Punktesystem verdächtige Merkmale kombiniert, statt starre Regeln anzuwenden.
Sperrt der Schutz versehentlich Google, KI-Bots oder echte Kunden aus?
Du erfährst, wie das Plugin echte Crawler erkennt und Fehlalarme vermeidet.
Was kostet der Schutz an Ladezeit und Datenschutz?
Du erfährst, warum die Prüfung praktisch keine Verzögerung verursacht und wie IP-Daten geschützt werden.
Warum die Filtersuche das teuerste Ziel im JTL Shop ist
Wenn Kundinnen und Kunden im Shop nach Merkmalen filtern (z. B. Größe, Farbe, Material), stößt das im Hintergrund eine aufwendigere Datenbankabfrage an als der Aufruf einer normalen Produktseite. Im Alltag fällt das nicht auf, weil ein Mensch typischerweise nur zwei oder vielleicht drei Filter setzt. Genau dieses Muster haben wir bei mehreren unserer Kunden beobachtet: Shops, die plötzlich langsam wurden, ohne dass ein einziger echter Käufer dahinterstand. Für uns war das der Ausgangspunkt, gezielt nach einer Lösung zu suchen, die echte Besucher zuverlässig von bösartigen Bots unterscheidet, ohne dabei Kundschaft oder Suchmaschinen auszubremsen
Bösartige Bots nutzen genau das aus: Sie senden hunderte Anfragen gleichzeitig, jede mit Filterkombinationen, die kein Mensch je einstellen würde. In einem realen Angriffsfall wurden Anfragen mit über 50 gleichzeitigen Filterwerten pro Aufruf gemessen. Der Shop hat jede einzelne davon brav und zum vollen Preis beantwortet. Der Angreifer zahlt für seine Anfrage praktisch nichts, der Shop dagegen jedes Mal eine teure Datenbankabfrage. Dieses Ungleichgewicht ist der eigentliche Hebel des Angriffs.
Warum ein einfaches Rate-Limit nicht mehr reicht
Der naheliegende Schutz ist ein Rate-Limit: Ab einer bestimmten Anzahl Anfragen pro Minute wird eine IP-Adresse gesperrt. Gegen einen Angreifer, der von einer einzigen Adresse aus feuert, funktioniert das gut.
Das Problem: Die Angriffe, die heute tatsächlich vorkommen, laufen anders.
Ein realer Angriff bei einem unserer JTL Shop Kunden im August 2026: Bei diesem JTL Shop Kunden kamen über 2.600 verschiedene IP-Adressen innerhalb von 15 Minuten zum Einsatz, im Schnitt mit nur je einer Anfrage pro Adresse. Kein einziger dieser Zugriffe hätte ein sinnvolles Rate-Limit überschritten, weil jede Adresse für sich völlig unauffällig blieb. Auffällig war nur die schiere Menge unterschiedlicher Absender gleichzeitig. Ein Schutz, der nur einzelne Adressen zählt, sieht so einen Angriff schlicht nicht.
Warum Cloudflare & Co. hier nur die halbe Antwort sind
ienste wie Cloudflare (sogenannte CDN/WAF-Dienste – vorgeschaltete Schutzsysteme, die Datenverkehr filtern, bevor er den eigenen Server erreicht) sind sinnvoll und sollten bestehen bleiben. Sie erkennen grobe Angriffsmuster und bekannte Bot-Signaturen.
Was sie nicht wissen können: dass eine bestimmte Filter-URL im eigenen Shop besonders teuer ist, oder wie viele Filter für diesen konkreten Shop überhaupt sinnvoll sind. Diese Dienste kennen den Shop von außen, nicht von innen. Genau in dieser Lücke – Anfragen, die technisch unauffällig aussehen, aber inhaltlich keinen Sinn ergeben – setzt ein Schutz an, der direkt im Shop-System sitzt.
Wie snafu BotBlock entscheidet: sieben Prüfungen, jede mit eigener Schwelle
Genau hier setzt snafu BotBlock an: Ein Plugin für JTL Shop 5, das direkt im Shop läuft und dessen Semantik kennt.
Die Entscheidung fällt nicht über eine einzige Gesamtnote, sondern über sieben unabhängige Prüfungen. Jede hat ihre eigene, im Backend einstellbare Grenze. Und jede kann eine Anfrage für sich allein stoppen. Das klingt streng, ist aber der einzige Weg, der gegen breit gestreute Angriffe funktioniert: Wenn 2.647 Adressen jeweils nur eine einzige Anfrage schicken, gibt es keine zweite Auffälligkeit, die man dagegenrechnen könnte. Die eine Prüfung muss reichen.
Dass dabei trotzdem keine echten Kunden hängenbleiben, dafür sorgen vier Dinge:
- Grenzwerte, die echte Kunden nie erreichen. Zwölf Filter gleichzeitig setzen, extrem lange Web-Adressen erzeugen, 60 Filteranfragen pro Minute abschicken. Das macht kein Mensch beim normalen Online-Einkauf. Alle diese Werte lassen sich außerdem an den eigenen Shop anpassen.
- Lieber präzise als übervorsichtig. Eine der Prüfungen wurde gegen 1,9 Millionen echte Kundenzugriffe getestet und hat kein einziges Mal fälschlich angeschlagen — im Angriffs-Verkehr dagegen zehntausendfach.
- Bekannte, vertrauenswürdige Besucher werden zuerst aussortiert. Wer auf der Positivliste steht oder sich als echter, bestätigter Suchmaschinen-Bot (z. B. Google) ausweist, wird gar nicht erst geprüft.
- Nicht jede Prüfung sperrt sofort. Zwei der sieben Prüfungen beobachten zunächst nur, und bei massenhaften Zugriffen aus vielen Richtungen gibt es statt einer Sperre erstmal eine kurze, unauffällige Zwischenprüfung.
Sieben Prüfungen im BotBlock Plugin
Ansichten im JTL Shop Backend vom BotBlock Plugin
Google darf nicht in die Falle laufen
Ein Bot-Schutz, der versehentlich den echten Google-Crawler aussperrt, richtet mehr Schaden an, als er verhindert. Gerade weil Google genau die Filterseiten regelmäßig besucht, um sie in der SEO-Suche zu listen.
User-Agents sind sehr leicht fälschbar, und bösartige Bots geben sich gern als Googlebot aus. snafu BotBlock verifiziert legitime Crawler deshalb per Reverse-DNS mit Forward-Bestätigung statt sie nur am Namen zu erkennen. Das Ergebnis wird zwischengespeichert, damit die Prüfung den laufenden Betrieb nicht belastet. Beide Fehlerrichtungen sind damit abgedeckt: Der echte Crawler kommt durch, der gefälschte bekommt kein erhöhtes Limit geschenkt.
Blocken ist nicht immer die richtige Antwort
Bei einem verteilten Angriff über tausende Adressen ist das Sperren einzelner IP-Adressen kein sinnvolles Mittel, denn jede davon könnte auch eine echte Kundin sein. Für diesen Fall gibt es eine kurze, automatische Zwischenprüfung im Browser via JS-Prüfseite, die ein Browser automtsich besteht und ein einfacher aber Bot nicht. Das geht mit snafu BotBlock ganz ohne lästige Sicherheitsabfrage (Captcha) und ohne dass Besucherdaten das eigene System verlassen.
Harte Sperren laufen bewusst vor dieser Prüfseite: Wer ohnehin gesperrt ist, soll keine Rechenzeit kosten.
Erst messen, dann aktiv schützen und scharf schalten
Damit niemand versehentlich echte Kunden aussperrt, hat das Plugin drei Betriebsstufen: Aus, Monitor, Aktiv. Im Monitor-Modus bewertet das Plugin jede Anfrage vollständig und protokolliert, was passiert wäre, blockiert aber noch nichts. So lassen sich die Schwellwerte erst am eigenen, echten Datenverkehr einstellen, bevor scharf geschaltet wird.
Zwei Sicherheitsprinzipien kommen dazu:
- Fail-open: Fällt die technische Komponente (Redis-Cache) aus, die für die Prüfung nötig ist, lässt das System im Zweifel lieber alle Anfragen durch, statt den ganzen Shop lahmzulegen.
- Die Allow-Liste schlägt alles: Und über eine Ausnahmeliste (Allow Liste) lassen sich eigene Systeme, die Agentur oder Monitoring-Tools dauerhaft von jeder Prüfung ausnehmen.
Ladezeit und Datenschutz: Was der Schutz wirklich kostet
Was kostet das an Ladezeit?
Praktisch nichts – das war eine bewusste Vorgabe an die Entwicklung, kein Zufall. Die Prüfung läuft vollständig über einen sehr schnellen Zwischenspeicher (Redis) und verursacht bei einer normalen Kundenanfrage keine zusätzliche Datenbankabfrage.
Wie steht es um den Datenschutz?
IP-Adressen werden maximal sieben Tage im Klartext gespeichert und danach automatisch gelöscht; alle längerfristigen Auswertungen laufen nur noch anonymisiert. Es fließen keine Besucherdaten an externe Dienstleister ab. Auch der wöchentliche E-Mail-Bericht an die Shopbetreiber enthält bewusst keine einzelnen IP-Adressen. Denn was per Mail rausgeht, lässt sich nicht mehr löschen.
Was Shop Betreiber im Backend sehen
snafu BotBlock zeigt alles Wichtige direkt im JTL-Shop-Backend aufgeteilt auf sieben Reiter:
- eine Statistik mit einer Übersichtskachel je Prüfpunkt,
- die Bot-Verwaltung,
- IP-Listen (Positiv- und Sperrlisten),
- Länderregeln,
- den Flood-Schutz mit Live-Zahlen und der Verteilung nach Herkunftsland,
- die Lizenzverwaltung sowie
- den Wochenbericht.
Besonders praktisch: Die Länderregeln lassen sich in Gruppen bearbeiten, zum Beispiel DACH, die EU oder den EWR auf einmal ankreuzen, einzelne Länder als Ausnahme herausnehmen, einmal bestätigen. Vor dem Speichern zeigt eine Vorschau die komplette Länderliste und wie viel vom aktuellen Besucherverkehr betroffen wäre. Genau dort fällt sofort auf, wenn eine gut gemeinte Regel versehentlich die eigene Kundschaft träfe.
Der Wochenbericht kommt automatisch per E-Mail, jeden Montag, und fasst die abgeschlossene Vorwoche zusammen: wie viele Anfragen tatsächlich blockiert wurden, wie viele es im Beobachtungsmodus gewesen wären, welche Prüfpunkte und Herkunftsländer am häufigsten ausschlugen – jeweils im Vergleich zur Vorwoche. Die Meldung kommt auch in ruhigen Wochen, und wenn der Schutz aus irgendeinem Grund nicht aktiv sein sollte, sagt der Bericht das ausdrücklich. So lässt sich eine ruhige Woche nicht mit einem ausgeschalteten Schutz verwechseln.
Ansicht der Tabs/Reiter im Backend
Was ein JTL Shop technisch braucht
Das Plugin läuft ab JTL-Shop Version 5.2.0 und benötigt zusätzlich die Serverkomponenten PHP 8, Redis und MariaDB.
Redis (ein schneller Datenzwischenspeicher) ist dabei keine Option, sondern zwingend erforderlich. Ohne ihn funktionieren weder die Anfragebegrenzung noch die Angriffserkennung. Am besten mit der eigenen IT oder Agentur klären, ob diese Komponenten bereits vorhanden sind.
Das kannst du jetzt tun
- Prüfen (lassen), ob dein Shop-Server bereits Redis, PHP 8 und MariaDB bereitstellt.
- snafu BotBlock zunächst im Beobachtungsmodus installieren. Es wird noch nichts blockiert.
- Nach ein bis zwei Wochen den Bericht ansehen: Wie viele Anfragen wären geblockt worden?
- Schwellwerte gemeinsam mit snafu an den eigenen Verkehr anpassen.
- Erst danach den aktiven Schutz einschalten.
Fazit
Bot-Angriffe verschwinden nicht von selbst, und sie werden immer gezielter: Sie sehen technisch unauffällig aus, kommen aber aus tausenden Richtungen gleichzeitig und fragen Dinge ab, die im normalen Betrieb nie vorkommen. Ein Schutz, der das erkennt, muss direkt im Shop sitzen, den eigenen Verkehr kennen und im Zweifel lieber durchlassen als den Shop lahmzulegen.
FAQ
Nein. Die Prüfung läuft über einen sehr schnellen Zwischenspeicher ohne Datenbankabfragen. Die Prüfung von normalen Kundenanfragen erzeugt minimalen Overhead
Nein. Bevor ein Crawler bevorzugt behandelt wird, prüft das Plugin technisch, ob er wirklich von Google stammt – ein gefälschter „Googlebot“ wird nicht bevorzugt.
Nein, im Gegenteil: Im Zweifel lässt das System lieber alle Anfragen durch, statt den Shop komplett zu blockieren.
Ja. Ohne diesen schnellen Zwischenspeicher funktionieren die Anfragebegrenzung und die Angriffserkennung nicht.
Nein. IP-Adressen werden nach spätestens sieben Tagen automatisch gelöscht, Langzeitauswertungen sind anonymisiert, und es gibt keine Datenweitergabe an externe Anbieter. (DSGVO)
Das Plugin lässt sich zunächst im reinen Beobachtungsmodus betreiben. Dort wird protokolliert, was blockiert worden wäre, ohne dass tatsächlich etwas gesperrt wird.
