Zusätzliche Kundeninfos und IP-Sperren: So schützen Sie Ihren Shop vor problematischen Besuchern

Die meisten Besucher sind genau die, die sie zu sein scheinen. Doch jeder Shop trifft irgendwann auf die Ausnahme: den „Kunden“, der zehn Bestellungen aufgibt und nie bezahlt, die Person, die nach Ankunft des Pakets eine Zahlung bei der Bank reklamiert, jemanden, der sich jedes Mal mit einer neuen Wegwerf-E-Mail registriert, sobald das letzte Konto gesperrt wurde, oder den Wettbewerber, der sich still aus demselben Büro einloggt, um Ihre Preise zu beobachten. Das PrestaShop-Backoffice zeigt Ihnen davon fast nichts. Sie sehen eine Bestellung, einen Namen, eine E-Mail — aber nichts über das Gerät, das Netzwerk oder die Vorgeschichte dahinter. In diesem Leitfaden geht es darum, diese blinde Stelle auf zwei Arten zu schließen: genügend zusätzliche Informationen über Besucher zu erfassen, um problematische Besucher zu erkennen, und eine IP-Sperre bereitzuhalten, damit Sie im Ernstfall die Tür schließen können — ohne Entwickler und ohne den gesamten Shop offline zu nehmen.

Zuletzt aktualisiert: Juni 2026.

Was PrestaShop Ihnen über einen Besucher zeigt — und was verborgen bleibt

Standardmäßig speichert PrestaShop den Namen eines Kunden, die E-Mail-Adresse, optional das Geburtsdatum und die Adressen, die an der Kasse eingegeben werden. Verbindungen werden unter Statistiken → Besucher online und in der Tabelle connections protokolliert, außerdem wird bei Gast-Sitzungen eine IP-Adresse gespeichert. Was PrestaShop nicht tut: diese Punkte für Sie zusammenführen. Es gibt keine Ansicht, die sagt: „Dieses Konto hat sich diese Woche aus sechs verschiedenen IPs in drei Ländern eingeloggt“, oder: „Diese vier Konten teilen sich dieselbe IP und denselben Browser-Fingerprint.“ Die Rohdaten existieren in Fragmenten; das Muster, mit dem Sie Betrug früh erkennen könnten, erscheint nirgendwo dort, wo Sie tatsächlich nachsehen würden.

Diese Lücke ist wichtig, denn Missbrauch ist fast immer ein Muster, kein Einzelereignis. Eine Retoure ist ein Kunde. Zwanzig Retouren von Konten, die alle auf dieselbe IP zurückgehen, sind ein Problem, das Sie am dritten Tag sehen möchten — nicht erst nach dem dritten Rückbuchungsschreiben Ihres Acquirers. Die erste Aufgabe ist daher Transparenz: Sie müssen das Wissen über jeden Besucher so anreichern, dass das Muster lesbar wird.

Welche „Zusatzinfos“ problematische Besucher wirklich sichtbar machen

„Zusätzliche Kundeninfos“ müssen nicht bedeuten, dass das Registrierungsformular länger wird (längere Formulare konvertieren schlechter — das ist ein echter Preis). Die Informationen, mit denen Sie Missbrauch erkennen, sind die technischen Metadaten, die die Anfrage ohnehin mitbringt und die Sie bisher nur nicht speichern. Unser Modul Customer Extra Info & IP Ban erfasst sie passiv pro Besuch und hängt sie an den Kundendatensatz an, sodass Sie sie direkt auf der Kunden-Adminseite einsehen können:

• IP-Adresse und Land — die echte Adresse, nicht die Ihres Proxys. Hinter Cloudflare oder einem Load Balancer protokolliert PrestaShop mit einer naiven Abfrage oft die IP des CDN. Das Modul liest CF-Connecting-IP, X-Real-IP und X-Forwarded-For (jeweils mit Validierung), damit die Adresse, die Sie sperren, die des Besuchers ist — nicht die Ihres Edge-Systems.
• Land — abgeleitet aus dem Cloudflare-Header CF-IPCOUNTRY, sofern vorhanden, oder ersatzweise aus der GeoIP-Datenbank von PrestaShop. Eine plötzliche Serie von Registrierungen aus einem Land, in das Sie gar nicht liefern, ist bereits ein Signal.
• Browser, Betriebssystem und Gerätetyp — aus dem User-Agent geparst. Fünf „verschiedene Kunden“ mit derselben ungewöhnlichen Browser-Version sind keine fünf Kunden.
• Eindeutige IPs pro Kunde, mit erstem/letztem Auftreten und Besuchszähler — das ist der Detektor für Mehrkonto-Betrug. Ein Konto, das über ein Dutzend IPs springt, oder eine IP, die ein Dutzend Kontonamen trägt, fällt in dieser Ansicht sofort auf.

Die Erfassung bleibt bewusst leise: Sie dedupliziert die Daten und schreibt nur einen Datensatz pro IP-und-Kunde pro Stunde, statt Ihre Datenbank bei jedem Seitenaufruf zu belasten. Außerdem ist jeder Datenpunkt (User-Agent, Betriebssystem, Browser, Bildschirmauflösung) einzeln ein- und ausschaltbar, damit Sie genau das sammeln, was Sie brauchen — und nichts, was Sie lieber nicht speichern möchten. Was bringt Ihnen das konkret? Wenn ein Streitfall eingeht, öffnen Sie das Kundenprofil und sehen den gesamten Fußabdruck: jede IP, jedes Land, jede Sitzung. Sie müssen nicht raten. Das ist der Unterschied zwischen Handeln auf Basis von Belegen und panischer Reaktion.

Die Kundenliste zeigt jeden Kunden mit Name, E-Mail, Status sowie Registrierungs- und letztem Besuchsdatum.

Wenn Sie den Roh-Fußabdruck während einer Untersuchung prüfen müssen, speichert das Modul ihn in ps_mprceiipban_info. Ersetzen Sie das Präfix, falls Ihr Shop nicht ps_ verwendet:

SELECT id_customer, ip_address, country_code, browser_name, device_type, date_add
FROM ps_mprceiipban_info
WHERE id_customer = 123
ORDER BY date_add DESC
LIMIT 50;

IP-Sperren in PrestaShop: präziser als „Adresse blockieren“

Der PrestaShop-Kern bietet kein echtes Werkzeug zum Sperren von Besuchern — die IP-Freigabeliste im Wartungsmodus unter Shop-Einstellungen → Allgemein → Wartung sperrt alle außer den aufgeführten IPs aus. Das ist genau das Gegenteil dessen, was Sie bei einem einzelnen Störer benötigen. Sperren sind daher genau die Art von Funktion, die ein Modul ergänzt. Die naive Variante einer IP-Sperre — eine Adresse, überall blockiert — ist zugleich die am wenigsten hilfreiche, weil sie zu grob und zu leicht zu umgehen ist. Eine Sperre, die ihren Platz wirklich verdient, gibt Ihnen Kontrolle darüber, welche Adresse betroffen ist, wo die Sperre greift und wie lange sie gilt.

Mehr als nur eine einzelne Adresse abgleichen

Problematische Akteure sitzen selten dauerhaft auf einer einzigen statischen IP. Das Modul gleicht eine Sperre ab gegen:

• Eine exakte IP — der einfache Fall.
• Eine Wildcard wie 203.0.113.* — wenn jemand immer wieder über benachbarte Adressen im selben Block zurückkommt.
• Einen CIDR-Bereich wie 203.0.113.0/24 — der präzise Weg, ein ganzes Subnetz abzudecken.
• Einen Adressbereich wie 203.0.113.10-203.0.113.40 — für eine beliebige Spanne.
• Einen Ländercode — sperren Sie eine ganze Herkunft, die Sie nicht bedienen, ausgewertet anhand des oben genannten GeoIP-Lands.
• Ein User-Agent-Muster — einfacher Textabgleich oder vollständige Regex, wenn ein Missbraucher eher an seiner Client-Zeichenkette als an seiner Adresse erkennbar ist.

Festlegen, wo die Sperre gilt

Genau dieser Teil macht aus dem Vorschlaghammer ein Skalpell. Jede Sperre hat einen Geltungsbereich:

Diese Trennung ist wichtig wegen der Realität dynamischer und gemeinsam genutzter IPs: Büros, Universitäten und Mobilfunkanbieter bringen viele echte Menschen hinter eine einzige öffentliche Adresse. Eine vollständige Sperre auf einer gemeinsam genutzten IP kann Sie unbemerkt echte Bestellungen kosten. Eine enge Kassen- oder Authentifizierungs-Sperre begrenzt den Schaden genau auf die missbrauchte Aktion. Und weil die echte IP des Besuchers hinter Ihrem CDN korrekt ermittelt wird, sperren Sie die richtige Person — nicht zufällig den Nachbarn.

Sperren ablaufen lassen — und sich nie selbst aussperren

Zwei weitere Kontrollen verhindern, dass Sperren selbst zum Problem werden. Jede Sperre kann temporär sein, mit einem Ablaufzeitpunkt, nach dem sie automatisch deaktiviert wird — nützlich für eine Abkühlphase, bei der eine permanente Sperre überzogen wäre, und sauberer im Hinblick auf die Datenaufbewahrung (mehr zum DSGVO-Aspekt weiter unten). Außerdem gewinnt eine Whitelist immer: Jede IP oder jeder CIDR-Bereich, den Sie dort eintragen, kann niemals gesperrt werden, auch nicht durch eine automatische Regel. Tragen Sie zuerst Ihr eigenes Büro, die Verbindung Ihres Entwicklers und Ihre Monitoring-Dienste ein, damit eine breite Sperre, die Sie um 2 Uhr morgens im Ärger setzen, nicht versehentlich Sie aussperrt.

Jede Sperrzeile zeigt Geltungsbereich, IP-Adresse und aktiven Status nebeneinander.

Vertrauenswürdige Adressen stehen in der Whitelist, während markierte Bestellungen einen Risikowert und einen Grund zeigen.

Automatisierten Missbrauch stoppen, bevor eine Sperre nötig wird

Ein großer Teil des Traffics problematischer Besucher ist kein Mensch, sondern ein Skript — und die sauberste Verteidigung besteht darin, den Angriff automatisch teuer zu machen. Das Modul verfolgt fehlgeschlagene Login-Versuche pro IP und kann eine Adresse automatisch sperren, sobald ein von Ihnen festgelegter Schwellenwert überschritten wird (also eine bestimmte Zahl an Fehlschlägen innerhalb eines Zeitfensters). Dabei wird eine temporäre Sperre für den Authentifizierungs-Bereich gesetzt, keine permanente Vollsperre. Das ist eine gezielte Antwort auf Credential Stuffing: Der Brute-Force-Angreifer wird nach beispielsweise zehn Fehlversuchen für eine Stunde vom Login ausgeschlossen, während ein Kunde, der sein Passwort zweimal vertippt hat, unbehelligt bleibt.

Automatische Sperren nach Login-Fehlschlägen sind eine Ebene. Die größere Aufgabe, gute Bots von schlechten zu trennen — Scraper, Schwachstellen-Scanner, Anzeigenbetrugs-Klicks — ist ein eigenes Thema; wir behandeln es in Visitor Control: Schlechte Bots und unerwünschten Traffic blockieren. Und der einzelne Schritt mit dem höchsten Nutzen, um Fake-Registrierungen und Formularspam an der Quelle zu stoppen, ist eine Abfrage direkt im Formular — siehe reCAPTCHA für PrestaShop. Wenn ein Angreifer Ihre Facetten-Suche-URLs in einen Denial-of-Service treibt, liegt die Frontlinie bei Ihrem CDN, nicht in einer PrestaShop-Sperrliste: den ?q=-Flood überstehen.

Wo IP-Sperren in Ihre breitere Absicherung passen

Seien Sie ehrlich mit sich, was eine IP-Sperre leisten kann — und was nicht. Sie ist hervorragend gegen die Gelegenheits- und Fahrlässigkeitstäter: die Mehrheit der Missbraucher, die nicht raffiniert genug sind, sich überhaupt mit einem VPN zu beschäftigen. Sie ist kein Schutzwall gegen einen entschlossenen Angreifer, der Adressen schneller wechseln kann, als Sie sie sperren. Behandeln Sie sie als ein präzises Werkzeug, nicht als Ihre Sicherheitsstrategie. Die Strategie entsteht im Zusammenspiel:

• Der vollständige Rundgang — Dateiberechtigungen, Admin-Ordner, Header, Updates — steht in der Checkliste zur Sicherheits-Härtung von PrestaShop, mit einer leichter verständlichen Einführung im Leitfaden für Shopbetreiber in klarer Sprache.
• Die Absicherung des Backoffice selbst — Admin-Konten sind für Angreifer der eigentliche Hauptgewinn — behandeln wir in Zwei-Faktor-Authentifizierung, Passwortrichtlinien und Admin-Sicherheit.
• Wenn Sie auf einer Version feststecken, die Sie nicht aktualisieren können, ist erweiterte Härtung mit Virtual Patching der realistische Weg.
• Und wenn der schlimmste Fall bereits eingetreten ist, improvisieren Sie nicht — folgen Sie Reaktion auf Datenpannen: Was tun, wenn Ihr Shop gehackt wurde?.

Die rechtliche Seite und die Dokumentation

Einen Kunden in der EU zu sperren, ist Ihr Recht — Sie dürfen eine Leistung verweigern —, doch die Daten, die Sie zur Begründung speichern, fallen unter die DSGVO. Daraus ergeben sich zwei praktische Konsequenzen. Erstens: Erfassen Sie verhältnismäßig. Deshalb ist jedes Metadatenfeld im Modul einzeln umschaltbar, und alte Datensätze können nach Zeitplan gelöscht werden, damit Sie keine Geräte-Fingerprints horten, die Sie nie verwenden. Zweitens: Hinterlegen Sie für jede Sperre einen klaren Grund (das Modul speichert den Grund und den Mitarbeiter, der die Sperre gesetzt hat), damit Sie zeigen können, warum die Einschränkung angewendet wurde — nicht nur, dass sie angewendet wurde —, falls ein gesperrter Kunde sich an seine Bank oder eine Verbraucherschutzbehörde wendet. Wenn dieser Kunde später einen Löschantrag nach Artikel 17 stellt, kommen Sie dem in der Regel nach — wobei Sie Daten aufbewahren dürfen, die tatsächlich für Rechtsansprüche oder Compliance erforderlich sind. Ihre AGB sollten bereits festhalten, dass Konten bei Richtlinienverstößen beendet werden können; genau diese Klausel gibt einer Sperre ihr Fundament.

Häufig gestellte Fragen

Kann eine IP-Sperre versehentlich echte Kunden hinter Cloudflare blockieren?

Ja, wenn Sie die falsche Adresse sperren — genau das ist die Falle hinter einem CDN. Die naive IP-Ermittlung von PrestaShop protokolliert häufig die IP von Cloudflare oder Ihrem Load Balancer statt die des Besuchers. Eine „Sperre“ kann dann auf Ihrem eigenen Edge-System landen und alle aussperren. Das Modul liest CF-Connecting-IP, X-Real-IP und X-Forwarded-For (jeweils mit Validierung), damit die Adresse, die Sie sperren, die des tatsächlichen Besuchers ist — nicht die Ihres CDN. Ermitteln Sie zuerst die echte IP; erst dann ist eine Sperre sicher.

Warum sollte ich eine „Kassen“- oder „Authentifizierungs“-Sperre statt einer vollständigen Blockade nutzen?

Weil Büros, Universitäten und Mobilfunkanbieter viele echte Menschen hinter eine öffentliche IP setzen. Eine vollständige Sperre auf einer gemeinsam genutzten Adresse kann Sie daher unbemerkt echte Bestellungen kosten. Eine Sperre mit Kassen-Geltungsbereich lässt einen Serien-Nichtzahler weiter stöbern, aber keine Bestellungen aufgeben; eine Sperre mit Authentifizierungs-Geltungsbereich stoppt Fake-Konto-Erstellung und Credential Stuffing aus einer Quelle, ohne legitime Gäste auf derselben IP zu blockieren. Passen Sie den Geltungsbereich an die missbrauchte Aktion an — vollständige Blockaden sind für klaren Missbrauch gedacht, den Sie komplett ausschließen möchten.

Wie stoppe ich Credential-Stuffing-Skripte, ohne echte Kunden zu sperren, die sich vertippen?

Nutzen Sie die automatische Sperre nach fehlgeschlagenen Logins mit einem sinnvollen Schwellenwert. Das Modul zählt fehlgeschlagene Login-Versuche pro IP und kann automatisch eine temporäre Sperre mit Authentifizierungs-Geltungsbereich setzen, sobald eine Adresse beispielsweise zehn Fehlversuche innerhalb eines Zeitfensters erreicht — so wird der Brute-Force-Angreifer für eine Stunde vom Login ausgeschlossen, während ein Kunde, der sein Passwort zweimal falsch eingegeben hat, unbehelligt bleibt. Das ist eine gezielte Antwort auf Skripte, kein pauschaler Hammer. Formularspam und Fake-Registrierungen stoppen Sie besser direkt am Formular mit reCAPTCHA.

Wie verhindere ich, dass ich mich mit einer breiten Sperre selbst aussperre?

Bauen Sie zuerst die Whitelist auf. Eine Whitelist gewinnt immer — jede IP oder jeder CIDR-Bereich, den Sie dort eintragen, kann niemals gesperrt werden, auch nicht durch eine automatische Regel. Fügen Sie daher Ihr eigenes Büro, die Verbindung Ihres Entwicklers und Ihre Monitoring-Dienste hinzu, bevor Sie eine breite Länder- oder CIDR-Sperre erstellen. So kann eine weite Sperre, die Sie um 2 Uhr morgens im Ärger setzen, Sie nicht versehentlich aussperren. Kombinieren Sie das mit temporären Sperren (ein Ablaufzeitpunkt deaktiviert sie automatisch) für Abkühlphasen, in denen eine permanente Sperre überzogen wäre.

Ist es unter der DSGVO problematisch, einen Kunden zu sperren und seine IPs zu speichern?

Eine Leistung zu verweigern ist Ihr Recht, aber die Daten, die Sie zur Begründung speichern, fallen unter die DSGVO. Erfassen Sie deshalb verhältnismäßig. Jedes Metadatenfeld ist einzeln umschaltbar, und alte Datensätze können nach Zeitplan gelöscht werden, damit Sie keine Geräte-Fingerprints horten, die Sie nie verwenden. Hinterlegen Sie für jede Sperre einen klaren Grund (das Modul speichert den Grund und den Mitarbeiter, der die Sperre gesetzt hat), damit Sie zeigen können, warum eine Einschränkung angewendet wurde, falls ein Kunde sich an seine Bank oder eine Verbraucherschutzbehörde wendet. Beachten Sie Löschanträge nach Artikel 17 und bewahren Sie nur auf, was tatsächlich für Rechtsansprüche erforderlich ist — und stellen Sie sicher, dass Ihre Bedingungen klar sagen, dass Konten bei Richtlinienverstößen beendet werden können.

Eine ausgewogene Tür, keine Festung

Der Sinn all dessen ist nicht, Käufer mit Misstrauen zu begrüßen — sondern einen freundlichen Shop zu führen, der still und zuverlässig Belege sammelt. Die meisten Shops müssen nur selten jemanden sperren. Aber die richtige Zeit, diese Fähigkeit aufzubauen, ist vor dem Ernstfall, nicht mitten in der Krise, wenn ein Betrugsring gerade aktiv ist und Sie unter Druck das Backoffice kennenlernen. Aktivieren Sie die Erfassung von Besuchermetadaten, damit Muster sichtbar werden. Setzen Sie Ihre eigenen Verbindungen zuerst auf die Whitelist. Halten Sie IP-Sperren mit Geltungsbereich und Ablaufzeit als Werkzeug bereit, das Sie in Sekunden einsetzen können — eine Kassen-Sperre für den Nichtzahler, eine Authentifizierungs-Sperre für den Massenregistrierer, eine vollständige Sperre für echten Missbrauch — und lassen Sie die automatische Sperre Brute-Force-Skripte eigenständig behandeln. Genau dafür ist Customer Extra Info & IP Ban gebaut: für die Transparenz, mit der Sie problematische Besucher erkennen, und für eine präzise, reversible Möglichkeit, sie zu stoppen — direkt aus Ihrem Backoffice, ohne Entwickler.