Security Revolution: Einrichtung und Hilfe

Laden Sie das Security Revolution-ZIP unter Modul > "Module Manager" hoch und installieren Sie es. Klicken Sie auf "Configure". Das Menü heißt Security Revolution und enthält Übersicht, Shop-Verbund, Kontrollübersicht, Schutz, Sicherung und Einstellungen.

Wählen Sie den vorgesehenen Shop. Öffnen Sie Einstellungen > Konfiguration, prüfen Sie die unten aufgeführten Standardwerte und speichern Sie. Fügen Sie Ihre vertrauenswürdige Administrator-IP vor gezielten Blockierungstests zu IPs auf der Whitelist hinzu. Verwenden Sie für diese Tests einen anderen Browser/eine andere IP ohne Whitelist-Eintrag. Halten Sie Serverzugriff bereit, bevor Sie den Anmeldeschutz ändern.

Die Schutzfunktionen haben getrennte Geltungsbereiche. Formular-/Aktionsprüfungen, Kapazitätsschutz, Sicherheitsheader, Administratorauthentifizierung und eine vom Betreiber angewendete Origin-Richtlinie werden nicht durch einen universellen Aktivierungsschalter gesteuert.

Verwenden Sie unter Einstellungen > Konfiguration die Tabs Allgemein, Spamfilter, Kontakt & Kommentare und Bot-Abwehr.

Die anfängliche Domainliste lautet:

qq.com
163.com
126.com
sina.com
sina.cn
sohu.com
21cn.com
tom.com
139.com
yeah.net

Registrierungsprüfungen umfassen Sperren, Ratenlimits, Domainprüfungen, Schriftsysteme, Namensmuster und den Honeypot. Kontaktprüfungen umfassen Sperren, den übermittelten Honeypot, Limits, Ausdrücke, Namen und Links. Kommentarprüfungen umfassen Sperren, Limits, Namen, Spam-Inhalte und mehr als zwei Links. Ein Formular-/Kommentarmodul eines Drittanbieters muss den entsprechenden PrestaShop-Integrationspfad aufrufen.

Der Name des Registrierungs-Honeypots wird aus dem Modulnamen erzeugt. Fügen Sie bei der normalen Einrichtung kein sichtbares CAPTCHA hinzu und hinterlegen Sie keinen alten Honeypot-Namen fest in Ihrem Theme.

Öffnen Sie Block-Verhalten.

Unter IP-Verwaltung ist IPs auf der Whitelist anfangs leer. Geben Sie eine vertrauenswürdige IP pro Zeile ein, zum Beispiel:

203.0.113.10
198.51.100.25

Die globale Whitelist umgeht die Anfrage-/Aktionsprüfungen des Moduls und die Kapazitätszulassung innerhalb von PHP. Sie entfernt keine Sicherheitsheader und schreibt keine externe Origin-Richtlinie um.

Aktionsbezogene Whitelist-Ausnahmen sind ebenfalls verfügbar für Warenkorb, Registrierung, Kontakt und Kommentar. Sie umgehen die entsprechenden Ratenlimits, statt dieselbe umfassende Ausnahme wie die globale Liste zu gewähren. Verwalten Sie IP-Aktionen über die Sitzungs-/IP-Werkzeuge, sofern verfügbar; dies sind keine vier separaten Felder im aktuellen Formular Konfiguration.

Sperren können global oder auf Aktionen beschränkt sein, darunter Warenkorb, Anmeldung, Registrierung, Kontakt und Kommentar. Prüfen Sie den Geltungsbereich, bevor Sie eine Sperre entfernen oder eine globale Ausnahme hinzufügen.

Verwenden Sie Konfiguration > Ratenbegrenzungen nach Aktion. Ratenbegrenzung aktivieren ist standardmäßig aktiviert.

Erhöhen Sie ein Aktionslimit erst, nachdem Sie die zugehörigen blockierten Versuche geprüft haben und ob mehrere echte Nutzer dieselbe Adresse verwenden.

Unter Globale Limits ist "Enable Global Rate Limiting" standardmäßig aktiviert, "Requests Per Minute" steht auf 60 und "Requests Per Hour" auf 1200.

"Trusted reverse-proxy CIDRs" ist anfangs leer. Fügen Sie einen Proxy- oder Loadbalancer-Bereich nur hinzu, wenn PHP diesen Proxy als REMOTE_ADDR sieht. Cloudflare-Bereiche und Loopback gelten bereits als vertrauenswürdig. Weitergeleitete Client-IP-Header werden nur von vertrauenswürdigen Gegenstellen akzeptiert. Eine falsche Proxy-Konfiguration kann dazu führen, dass viele Kunden scheinbar dieselbe Adresse haben.

Der interne Wert firewall_runtime_mode steht standardmäßig auf monitor. Das Modul protokolliert im Modus monitor vorgeschlagene Firewall-, Sperr-, globale Ratenlimit- und Bot-Fight-Eingriffe; enforce wendet sie an und off deaktiviert diese Laufzeitebene. Dieser Schlüssel wird nicht als alter sichtbarer Schalter unter Konfiguration angeboten. Verwenden Sie die Support-/Betreiberkonfiguration für eine bewusste Änderung des Laufzeitmodus. Aktionsbezogene Übermittlungsprüfungen bleiben im Modus monitor aktiv und können Formularübermittlungen ablehnen.

Öffnen Sie Konfiguration > Kapazität.

Aus dem Seitencache ausgelieferte Seiten belegen keinen Renderplatz. Ist ein Bereich voll, gibt der Schutz innerhalb von PHP HTTP 503 mit Retry-After, X-MPR-Capacity: busy und einem Wiederholungsticket zurück. Normale Seitenanfragen erhalten eine kleine Wiederholungsseite. Bei Formularübermittlungen wird der Besucher zum erneuten Absenden aufgefordert; der Inhalt wird nicht automatisch erneut übermittelt.

Öffnen Sie Kontrollübersicht > Crawler, um benannten Traffic zu prüfen. Crawler-Namen aus dem User-Agent sind Berichtsbezeichnungen. Das Modul erlaubt es nicht, eine Crawler-Familie allein anhand dieses Namens zuzulassen oder zu blockieren.

Die Identität von Suchmaschinen- und KI-Crawlern wird anhand der Adresse mit vom Betreiber veröffentlichten Bereichen oder nachgewiesenem Reverse-DNS überprüft. Verifizierte Adressen sind von adressbezogener Drosselung und Challenges ausgenommen. Ein behaupteter Googlebot-User-Agent reicht nicht aus. Verifizierte Crawler verursachen weiterhin Serverlast, die durch Kapazitätskontrollen behandelt wird.

Das Modul bietet weder das alte konfigurierbare Crawl-Budget pro Crawler noch den gewichteten Redis-Token-Bucket für Facetten. Es gibt aktuell keine Einrichtung für "Bucket Capacity", "Single Filter Cost" oder die alte Antwort X-MPR-Facet-Limiter. Verwenden Sie stattdessen die tatsächlichen Kapazitätskontrollen und die unterstützte Listing-Integration.

Öffnen Sie Kontrollübersicht > Sitzungen und dessen Einstellungsbereich. Aktivität und Datenverkehr bieten zugehörige Anfrage- und Aktionsberichte.

Verwenden Sie die Einstellungen unter "Scoring Points" erst, nachdem Sie tatsächliche Aufschlüsselungen der Bewertungen geprüft haben.

Weitere interne Standardwerte: Seitenzähler an, detaillierter Seitenverlauf aus, 10 Punkte für einen noch nicht als Mensch erkannten Besucher, Analyse nach 5 Seitenaufrufen und 24 Stunden Aufbewahrung der Anfrageprotokolle. Allgemeines Debugging und Registrierungsdebugging sind standardmäßig aus. Nicht alle diese Werte haben ein eigenes Feld im aktuellen Formular; für vorübergehende Änderungen der Protokollierung wenden Sie sich an den Support.

Öffnen Sie Schutz > Header. Prüfen Sie die aktuelle Analyse, bevor Sie eine Voreinstellung anwenden, da Voreinstellungen mehrere Werte ändern.

Bearbeiten Sie die CSP-Richtlinien- und Quellensteuerung für die Domains, die Ihr Shop tatsächlich lädt. Die Basis enthält self sowie gängige PrestaShop-, Google- und Medienquellen, Ihre Zahlungs-, Analyse- oder eingebetteten Dienste können aber weitere benötigen. Testen Sie Kasse, Schriftarten, Medien und Widgets und prüfen Sie Verstöße, bevor Sie die Richtlinie durchsetzen.

Permissions-Policy und Cross-Origin-Richtlinien sind standardmäßig leer. Diese Werte sind nicht alle als beschriftete Steuerelemente unter Header verfügbar.

Die Verarbeitung der Sicherheitsheader ist standardmäßig aktiviert. Verwaltete CSP kann auch mit .htaccess abgeglichen werden. Das Ausschalten von Modul aktiv allein entfernt diese separat verwaltete CSP nicht. Beim Deaktivieren oder Deinstallieren entfernt das Modul seinen verwalteten CSP-Block aus .htaccess; dies kann fehlschlagen, wenn die Bereinigung nicht abgeschlossen werden kann.

Öffnen Sie Schutz > E-Mail und dessen Konfigurationsbereich.

Speichern Sie und prüfen Sie anschließend aufgezeichneten Status, Typ und Empfängerdaten. Bestellbestätigungen, Bestellstatus, Rechnungen, Gutschriften und Kontoerstellungsnachrichten sind vom E-Mail-Ratenlimit ausgenommen. Diese Ausnahme bedeutet nicht, dass jeder anderweitige Zustellfehler verhindert wird.

Öffnen Sie Schutz > Dateiüberwachung. Erstellen Sie eine Referenzbasis nur nach einer nachweislich sauberen Installation oder einem vertrauenswürdigen Update. Führen Sie einen Scan aus und prüfen Sie geänderte, fehlende, neue oder verdächtige Dateien. Erstellen Sie die Referenzbasis erst nach Bestätigung legitimer Änderungen neu.

Der Scanner überwacht classes, controllers, src, override, config und modules auf PHP-, Smarty-, JavaScript- und .htaccess-Dateien. Cache, Protokolle, Uploads, Bilder, Downloads, Herstellerbibliotheken und node_modules werden ausgeschlossen. Eine Referenzbasis ist kein vollständiger forensischer Scan jeder Datei.

Öffnen Sie Schutz > Schwachstellen, um die verfügbaren Versions- und Servereinstellungsprüfungen auszuführen.

Öffnen Sie Sicherung > Einstellungen, bevor Sie ein Archiv erstellen.

Wenn MPR_SECURITY_BACKUP_DIR im Shop-Bootstrap definiert ist, überschreibt es das bearbeitbare Verzeichnis. Speichern Sie Verzeichnisänderungen, bevor Sie vorhandene Archive verschieben. Der Verschiebeablauf prüft Dateien, bevor die Originale entfernt werden.

Verwenden Sie Sicherung > Sicherungen für ein manuelles Backup und prüfen Sie dessen abgeschlossenes Ergebnis. Verwenden Sie Speicher für die Konfiguration des lokalen Speichers. Backups verwenden lokalen Speicher; FTP-, SFTP-, S3- und WebDAV-Ziele sind nicht verfügbar. Bewahren Sie über Ihren Hosting-/Betriebsablauf eine unabhängige Kopie außerhalb des Servers auf.

Öffnen Sie Sicherung > Zeitpläne und fügen Sie einen benannten Zeitplan hinzu.

Bei neuen Zeitplänen sind Erfolgsbenachrichtigungen standardmäßig aus und Fehlerbenachrichtigungen an. Prüfen Sie die verfügbaren Benachrichtigungsoptionen im installierten Zeitplanformular. Ein gespeicherter aktiver Zeitplan benötigt weiterhin den nachfolgend beschriebenen Runner.

Verwenden Sie Einstellungen > Geplante Aufgaben für gemeinsame Aufgaben und Sicherung > Cron-System für Einrichtung/Status des Backup-Runners. Kopieren Sie den echten Token aus dem Modul.

* * * * * php /var/www/html/modules/mprsecurityrevolution/cron.php --token=YOUR_TOKEN --max-tasks=20 --max-seconds=55 --context=cron

Passen Sie die Pfade an Ihren Host an. HTTP-Ausführung wird ebenfalls unterstützt:

curl 'https://yourshop.example/modules/mprsecurityrevolution/cron.php?token=YOUR_TOKEN'

CLI-Standardwerte sind 20 Aufgaben, 55 Sekunden und Kontext cron. Unterstützte Kontexte sind cron, front und admin. Der minütliche Runner startet aktive fällige Aufgaben; einzelne Aufgaben behalten ihre eigenen Zeitpläne. Dazu gehören geplante Backups, Bereinigung von Sicherheits-/Ratenlimit-/Anfrage-/Sitzungsdaten, GeoIP-Aufgaben, Besucherklassifizierung, gepufferte Berichte und Pflege der Crawler-Adressen.

Prüfen Sie die Runner-Ausgabe und den Aufgabenstatus. Prüfen Sie bei Backups außerdem, ob im privaten Verzeichnis ein fertiges Archiv liegt, denn ein Backup kann auch nach dem Start durch den Scheduler fehlschlagen.

Öffnen Sie Einstellungen > Admin-Sicherheit. Prüfen Sie den Wiederherstellungszugriff, bevor Sie die Authentifizierung erzwingen.

Registrieren Sie Ihren eigenen Authenticator, prüfen Sie eine Challenge und bewahren Sie Backup-Codes auf, bevor Sie die Registrierung für alle Mitarbeiter vorschreiben. Prüfen Sie Kontrollübersicht > Admin-Sicherheitsprotokolle.

Für Betreiber mit Serverzugriff unterstützt das installierte Wiederherstellungswerkzeug:

php modules/mprsecurityrevolution/bin/admin-security-escape.php --clear-lockouts
php modules/mprsecurityrevolution/bin/admin-security-escape.php --disable-enforcement

--all kombiniert beides. Verwenden Sie das installierte Werkzeug und prüfen Sie sein Ergebnis; die Wiederherstellung ändert die Durchsetzung der Authentifizierung und erfordert anschließend eine Neukonfiguration.

Das zusätzliche Formular Origin-Schutz speichert eine gewünschte Serverrichtlinie. Es stellt sie nicht bereit. Es unterstützt einen Shop unter der Root-URL mit einem gemeinsamen HTTP-/HTTPS-Host und diesem Modul als aktivem Firewall-Verantwortlichen. Multishop, Nicht-Root-URLs und mehrere aktive Shop-URLs werden für diese Origin-Richtlinie nicht unterstützt.

Es werden keine Richtlinienschwellenwerte automatisch aktiviert. Wählen Sie für Origin-Schutzmodus und Modus der gemeinsamen Pool-Rate Beobachten oder Durchsetzen. Tragen Sie unter Worker gesamt einen Wert von 3 bis 64 ein, der der Summe aller Pool-Worker entspricht.

Konfigurieren Sie alle drei Pools: Öffentlicher Pool, Interaktiver Pool für Checkout, Konto und Zahlung und Pool für Administration, Downloads und lange Vorgänge. Jeder enthält:

Ein Betreiber muss die Richtlinie sowie jede Worker-/Zeitlimit-Bereitstellung separat anwenden. Eine passende Anwendungsbestätigung dokumentiert die letzte Anwendung, nicht den laufenden Zustand des Dienstes. Exportieren oder importieren Sie die vollständige gewünschte Richtlinie mit:

php modules/mprsecurityrevolution/bin/origin-protection.php export
php modules/mprsecurityrevolution/bin/origin-protection.php import < complete-policy.json

Keiner der Befehle ist ein Befehl zur Serverbereitstellung. Gemeinsame Pool-Ratenlimits gelten für alle Adressen und URLs im Pool ohne Ausnahmen für Cookies oder User-Agents.

Testen Sie zunächst eine kontrollierte Registrierung und Kontaktübermittlung. Prüfen Sie unter Schutz > Blockiert Typ, Grund, IP, verfügbare E-Mail, Daten und Zeitstempel. Gründe können Ratenlimits, gesperrte Domains, Honeypot, nicht lateinische Namen, sinnlose Namen, gesperrte IPs, Spam-Schlüsselwörter und zu viele Links sein.

Testen Sie die Kapazität unter Nur beobachten, bevor Sie Limits in einem stark besuchten Shop anpassen. Unterscheiden Sie die 503-Antwort innerhalb von PHP von adressbezogenen Ratenlimit- oder Formularfehlern. Prüfen Sie die Konfiguration weitergeleiteter IPs, wenn viele Besucher scheinbar eine IP teilen. Prüfen Sie verifizierte Adressdaten, bevor Sie eine Crawler-Bezeichnung als vertrauenswürdig ansehen.

Prüfen Sie bei fehlenden Daten Sitzungserfassung, interne IP-Ausschlüsse, Aufbewahrung und Cron-Ergebnisse. Prüfen Sie bei blockierten echten Kunden die genaue Regel und den Geltungsbereich, bevor Sie Ausnahmen hinzufügen. Prüfen Sie bei Header-Problemen die Antwortheader, CSP-Verstöße und den verwalteten Zustand von .htaccess. Prüfen Sie bei Backup-Fehlern den tatsächlichen privaten Pfad, PHP-/CLI-Berechtigungen, verfügbaren Speicherplatz und den Aufgabenfehler.

Verwenden Sie Einstellungen > Integrität für Installationsprüfungen. Halten Sie PrestaShop und Module aktuell und bewahren Sie getestete Backups außerhalb des Shops auf; die Scans und lokalen Archive des Moduls ersetzen diese Maßnahmen nicht.

Exportieren Sie benötigte Protokolle und kopieren Sie benötigte Backups vor der Deinstallation. Prüfen Sie eine vom Betreiber bereitgestellte Origin-Richtlinie separat, da das Speichern oder Entfernen des Moduls nicht mit einer Änderung der Servertopologie gleichzusetzen ist.

Deaktivieren/deinstallieren Sie über "Module Manager" erst, nachdem Sie die Bereinigung der verwalteten CSP geprüft haben. Die Deinstallation entfernt moduleigene Tabellen und geplante Aufgaben; die Bereinigung gemeinsam genutzter Sitzungs-/Seitenaufrufdaten übernimmt das gemeinsame Paket. Gehen Sie nicht davon aus, dass Modulprotokolle und Konfiguration erhalten bleiben. Sichern Sie private Backup-Archive unabhängig, bevor Sie Moduldateien entfernen.

Erfordert PrestaShop 1.6.1 oder höher und PHP 7.1 oder höher.