Zweck des Artikels
Dieser Leitfaden erklärt, wie Sie die Anwendungs‑Firewall verwenden, die vom Securantis‑Modul für PrestaShop (1.7 bis 9) bereitgestellt wird. Sie erfahren, wie Sie zwischen Beobachtungs‑ und Blockmodus wählen, die für den Online‑Handel vorgesehenen Regeln (Bestellungen, Zahlungen, Webhooks, AJAX) aktivieren, IPs und URLs freigeben und die Kompatibilität sowie das Fail‑open‑Verhalten prüfen, um Unterbrechungen des Shops in Produktion zu vermeiden.
Zielgruppe und Voraussetzungen
- Securantis‑Modul installiert und mit Ihrem Securantis‑Konto verknüpft.
- PrestaShop 1.7 bis 9; PHP 7.2+ wird vom Hersteller empfohlen.
- Administratorzugang zum PrestaShop‑Backoffice.
- Aktuelle Sicherung (Dateien und Datenbank) vor jeder Konfigurationsänderung.
Allgemeines Verhalten und Grundsätze
- Modi der Firewall: Beobachtung (nur Logs) und Blockierung (Unterbrechung bösartiger Anfragen). Beginnen Sie stets im Beobachtungsmodus auf einem aktiven Shop, um False Positives zu messen.
- E‑Commerce‑Regeln: Sets aus Signaturen und Heuristiken, die darauf ausgelegt sind, Blockierungen bei sensiblen Aktionen (Zahlung, Bestellung, Warenkorb, Webhooks) zu minimieren. Diese Regeln können separat aktiviert werden.
- Whitelists: Sie können IPs oder URLs deklarieren, die vom Filtern ausgenommen sind, um den Zugriff für Drittanbieter (IP der Zahlungs‑Gateway, Monitoring‑IPs) oder bestimmte interne Endpunkte sicherzustellen.
- Fail‑open: Im Fall eines internen Fehlers des Moduls oder der Infrastruktur neutralisiert der Notfallmodus Blockierungen, um die Verfügbarkeit des Shops zu erhalten.
Empfohlene Schritte (stufenweises Deployment in Produktion)
- Wechsel in den Beobachtungsmodus
- Aktivieren Sie die Firewall im Beobachtungsmodus. Ziel: tatsächliche Detektionen sammeln und False Positives identifizieren, ohne Kunden zu beeinträchtigen.
- Lassen Sie den Modus mehrere Tage laufen, die Ihre Aktivitätsspitzen abdecken (z. B. Woche und Wochenende).
- Überprüfung der Ereignisse und E‑Commerce‑Regeln
- Prüfen Sie die Logs: Priorisieren Sie Detektionen auf Checkout‑Abläufen, APIs und Webhooks.
- Aktivieren Sie die Regeln „e‑commerce“ oder „Shop‑Schutz“, falls verfügbar: Diese verringern die Schwere bei kritischen Operationen und melden gleichzeitig Angriffe.
- Freigaben (IP und URL)
- Liste erlaubter IPs: Fügen Sie die IP‑Adressen Ihrer Dienstleister (Zahlungs‑Gateways, Abrechnungsdienste, Monitoring‑Tools) hinzu, damit diese vom Filtern ausgenommen werden.
- Liste erlaubter URLs: Erlauben Sie bekannte Endpunkte (Webhooks, interne API‑Endpunkte), falls die Firewall legitime Anfragen meldet.
- Testen Sie jede Freigabe zunächst im Simulations‑/Beobachtungsmodus, bevor Sie auf Blockierung umstellen.
- Stufenweiser Wechsel in den Blockiermodus
- Aktivieren Sie die Blockierung für eine Untergruppe nicht‑kritischer Regeln (z. B. allgemeine XSS‑Signaturen) für einige Stunden und beobachten Sie die Vorfälle.
- Wenn keine Kundenbeeinträchtigungen auftreten, erweitern Sie die Blockierung auf kritische Regeln, wobei Sie die E‑Commerce‑Regeln bei Bedarf weiterhin etwas permissiver belassen.
- Kontinuierliche Überwachung
- Planen Sie Berichte und Alerts ein, um Blockrate, aktivste Regeln und blockierte IPs zu verfolgen.
- Behalten Sie nach größeren Änderungen (Modul‑Updates, Launch von Aktionen) regelmäßig Beobachtungsphasen bei.
Vorsichtige Einstellungen und Empfehlungen
- Blockieren Sie nicht sofort Signaturen, die Zahlungen oder Webhooks betreffen. Bevorzugen Sie eine Beobachtungsphase und schrittweise Maßnahmen.
- Ziehen Sie vor, eine IP freizugeben statt eine Regel komplett zu deaktivieren: Das ist sicherer und zielgerichteter.
- Dokumentieren Sie jede Änderung (wer, wann, warum), um bei Problemen schnell zurückrollen zu können.
- Aktivieren Sie den Fail‑open‑Modus oder prüfen Sie dessen Vorhandensein: Im Fehlerfall des Moduls verhindert dies Umsatzverluste.
Häufige Fehler und Ursachen
- False Positives auf AJAX‑Endpunkten oder Webhooks: Oft verursacht durch zu strenge Signaturen oder nicht erkannte JSON‑Payloads.
- Blockierung von Zahlungs‑Gateways: Fehlende IPs der Anbieter in der Whitelist.
- Verlust des Backoffice‑Zugangs für bestimmte Mitarbeiter: Dynamische IP nicht freigegeben oder zu restriktive Regel für Administrationsseiten.
- Meldung „Modul nicht verbunden“ oder Lizenzprüfung nicht möglich: Ausgehende Netzwerkprobleme oder Lizenzinformationen noch nicht aktiviert.
Schrittweises Troubleshooting
- Wenn der Shop Kundenblockierungen erfährt
- Schalten Sie die Firewall sofort in den Beobachtungsmodus oder aktivieren Sie den Notfallmodus, um den Zugriff wiederherzustellen.
- Identifizieren Sie die jüngsten Ereignisse: blockierte URLs, Quell‑IPs, ausgelöste Regeln.
- Fügen Sie dringend legitime IPs zur Whitelist hinzu und testen Sie die betroffenen Abläufe.
- Wenn Zahlungen fehlschlagen
- Prüfen Sie die Logs auf Anfragen an das Zahlungs‑Gateway und fügen Sie dessen IP zur erlaubten IP‑Liste hinzu.
- Bestätigen Sie bei Bedarf die IP‑ oder Domainliste vom Zahlungsanbieter.
- Wenn das Backoffice für bestimmte Konten unzugänglich ist
- Prüfen Sie, ob eine Regel, die Administrationsseiten betrifft, aktiv ist; deaktivieren Sie diese vorübergehend oder erlauben Sie die betroffene IP.
- Prüfen Sie auf ein Drittanbieter‑Plugin im Backoffice, das Routen ändert und nicht erkannte Signaturen erzeugt.
- Wenn das Modul ein Update oder ein Lizenzproblem meldet
- Prüfen Sie die Netzwerkverbindung des Servers zu den Securantis‑Diensten und den Lizenzstatus im Kundenbereich.
- Wenn ein Update verfügbar ist, planen Sie dieses außerhalb der Aktivitätsspitzen und wechseln Sie nach der Installation wieder in den Beobachtungsmodus.
Vorsichtsmaßnahmen und Best Practices
- Löschen Sie nicht automatisch Dateien, die als bösartig gemeldet werden: Löschen oder Quarantäne erfordern eine menschliche Entscheidung.
- Teilen Sie niemals Passwörter per E‑Mail oder Chat für den Support. Wird ein Zugriff für eine kostenpflichtige Intervention benötigt, erfolgt die Übermittlung über den sicheren Kundenbereich nach Zahlung.
- Testen Sie Regeländerungen nach Möglichkeit immer in einer Pre‑Production‑Umgebung.
- Erstellen Sie Backups vor jeder größeren Firewall‑Konfiguration oder Modul‑Aktualisierung.
Kompatibilität und Grenzen
- Das Securantis‑Modul für PrestaShop ist für PrestaShop 1.7 bis 9 konzipiert und läuft auf PHP 7.2+. Installieren Sie das Modul nicht auf nicht unterstützten Versionen.
- Die Firewall setzt allgemeine Regeln für SQLi, XSS, sensible Pfade und Rate‑Limiting durch, ist jedoch keine Garantie, dass alle Angriffe gestoppt werden. Manche Dritt‑Tools oder individuelle Shop‑Anpassungen erfordern spezifische Ausnahmen.
- In atypischen Hosting‑Umgebungen (Reverse‑Proxy, CDN, Konfiguration von X‑Forwarded‑For‑Headern) passen Sie die Konfiguration an, damit das Modul die ursprüngliche IP korrekt liest.
Wann Sie den Securantis‑Support kontaktieren sollten
Kontaktieren Sie den Support, wenn:
- Persistente Blockierungen trotz Whitelists und Beobachtungsmodus die Umsätze beeinträchtigen.
- Inkonsistentes Verhalten nach einem Modul‑ oder PrestaShop‑Update auftritt.
- Sie Zweifel an der Erkennung einer kritischen Datei haben: Sie möchten Hilfe zur Analyse vor Löschung oder Quarantäne.
- Sie eine tiefere Intervention (Audit oder Behebung durch unsere Techniker) benötigen. Beachten Sie, dass für Maßnahmen, die Zugänge erfordern, diese über den sicheren Kundenbereich nach kommerzieller Vereinbarung angefordert werden.
Erwartetes Ergebnis
Wenn Sie diesem Leitfaden folgen, sollten Sie:
- Eine aktive Firewall im Beobachtungsmodus und angepasste E‑Commerce‑Regeln ohne Serviceunterbrechung haben.
- Die False Positives schrittweise reduzieren und bei Bedarf die Blockierung für nicht‑kritische Signaturen aktivieren können.
- Zahlungen, Webhooks und Kundenabläufe durch IP/URL‑Freigaben und den Fail‑open‑Modus funktionsfähig halten.
Anhang — Schnellpunkte
- Immer mit Beobachtung beginnen.
- IPs von Zahlungs‑ und Monitoring‑Dienstleistern freigeben.
- Quarantäne und Löschung für eine menschliche Entscheidung vorbehalten.
- Support für kritische Blockierungen oder Analyse verdächtiger Dateien kontaktieren.
Schlüsselwörter : PrestaShop‑Firewall, WAF, E‑Commerce‑Regeln, IP‑Whitelist, URL‑Freigabe, Fail‑open, PrestaShop 1.7–9, PHP 7.2+