Fortgeschrittene PrestaShop-Härtung für Shops, die Sie noch nicht upgraden können

In unserer forensischen Analyse eines Angriffs im Magecart-Stil haben wir einen Punkt angesprochen, der im Rückblick einen eigenen Artikel verdient hat: Malware aus einem Shop zu entfernen ist nicht dasselbe, wie den Shop zu reparieren. Wir haben den Skimmer, die Webshells und die SUID-Root-Binärdateien aus diesem PrestaShop-1.7.x-Shop entfernt, und kurz darauf wurde er erneut getroffen. Nicht über eine übersehene Hintertür, sondern durch die Vordertür: eine Schwachstelle auf Anwendungsebene, die bei der Bereinigung zwar eingedämmt, aber nie geschlossen worden war. Dieser Beitrag ist das Playbook, das wir gerne schon beim ersten Mal angewendet hätten, wie Sie einen PrestaShop-Shop härten, den Sie noch nicht upgraden können, sodass mit dem Entfernen der Schadlast auch die Lücke geschlossen wird, durch die sie hereingekommen ist.

Geschrieben für PrestaShop-1.7.x-Shops, die unterhalb eines unterstützten Zweigs feststecken; die folgenden Schritte sind Übergangslösungen, die Zeit für eine Migration auf PrestaShop 8 oder 9 (Symfony 6.4) verschaffen, aber kein Ersatz dafür sind.

Wenn Sie heute auf PrestaShop 8 oder 9 upgraden können, tun Sie genau das. Es ist die einzige dauerhaft tragfähige Lösung, und alles Folgende ist nur eine Übergangslösung. Für einen echten Shop ist ein Upgrade jedoch ein mehrwöchiges Projekt: Modulkompatibilität, Theme-Refactoring, Neuverdrahtung der Zahlungsabwicklung. Die Zwischenphase ist real, und währenddessen sind Sie ein aktives Ziel. Dies ist die fortgeschrittene, vorfalltaugliche Ergänzung zu zwei Grundlagenleitfäden, beginnen Sie mit der Checkliste zur PrestaShop-Sicherheitshärtung für die vollständige Basis oder mit dem leicht verständlichen Leitfaden für Shopbetreiber, wenn Sie nicht technisch arbeiten, und kommen Sie dann hierher zurück für die zusätzliche Schutzschicht, die einen nicht upgradefähigen Shop überlebensfähig hält.

1. Finden Sie den Einstiegspunkt, nicht nur die Schadlast

Der teuerste Einzelfehler bei der Reaktion auf Sicherheitsvorfälle ist, das sichtbare Symptom für die eigentliche Wunde zu halten. Ein Skimmer in Ihrem Theme-JavaScript ist das Symptom. Die Wunde ist das, was einem Angreifer überhaupt erlaubt hat, dieses JavaScript zu schreiben, eine Webshell, ein ungepatchtes Modul, ein Injection-Endpunkt. Entfernen Sie den Skimmer und lassen Sie die Wunde offen, haben Sie sich Tage erkauft, keine Sicherheit.

Bevor Sie irgendetwas härten, beantworten Sie eine Frage mit Belegen: Wie wurde Code auf die Festplatte geschrieben? Lesen Sie die Zugriffsprotokolle rund um die Zeitstempel der Malware-Dateierstellung, verwenden Sie die Inode-Änderungszeit (ctime), nicht die Änderungszeit (mtime), denn Angreifer datieren mtime routinemäßig zurück, um Spuren zu verwischen. Korrelieren Sie verdächtige POST-Anfragen, ungewöhnliche Query-Parameter und Anomalien bei Antwortgrößen mit dem Moment, in dem die Schadlast aufgetaucht ist. Wenn Sie den Einstiegspunkt nicht benennen können, gehen Sie davon aus, dass er noch offen ist, und behandeln Sie jeden folgenden Schritt als tragende Schutzmaßnahme.

2. Patchen Sie virtuell die Schwachstellen, die Ihre Protokolle und Sicherheitshinweise tatsächlich benennen

PrestaShop-1.7.x-Shops wurden von mehreren gezielt ausnutzbar gemachten Schwachstellen getroffen, nach denen automatisierte Scanner gezielt suchen. Wenn Sie nicht upgraden können, patchen Sie die konkreten Codepfade direkt, ein „Virtual Patch“, angewendet auf Ihre eigenen Dateien. Das sind Übergangslösungen, verfolgen Sie also die Upstream-Sicherheitshinweise weiter; sie schließen aber die Türen, die aktiv eingetreten werden. Beginnen Sie mit Belegen: Identifizieren Sie das genaue verwundbare Modul oder die Core-Version, die in Ihren Protokollen und den einschlägigen Sicherheitshinweisen genannt wird, und patchen Sie genau das. Eine bekannte Angriffskette aus dem Jahr 2022 kombinierte beliebige ausnutzbare SQL-Injection mit der Smarty-MySQL-Cache-Ausführung, um Datenbankzugriff in laufenden PHP-Code zu verwandeln. Das Muster, auf das Sie achten müssen, ist also eine Injection, die Ihre Datenbank erreicht, gepaart mit einer Cache-Schwachstelle, die Code ausführt. Das Facettensuche-Beispiel unten ist ein solcher Injection-Vektor, aber patchen Sie die installierte ps_facetedsearch-Version nur dann, wenn sie nachweislich verwundbar ist; der SQL-Injection-Teil dieser Kette kann genauso gut aus anderem Core- oder Modulcode stammen.

2.1 Die SQL-Injection in der Facettensuche (falls Ihre installierte Version verwundbar ist)

Einige ältere Builds des Moduls ps_facetedsearch verketten Filterwerte direkt in eine SQL-WHERE-Klausel, ein Blind-SQL-Injection-Primitiv. Prüfen Sie anhand der Sicherheitshinweise, ob die von Ihnen betriebene Version tatsächlich betroffen ist, bevor Sie sie anfassen; nicht jeder 1.7.x-Shop enthält genau diese Schwachstelle. Wo sie zutrifft, besteht die Korrektur darin, jeden aus einer Anfrage stammenden Wert durch PrestaShops eigene Escaping-Funktionen zu schicken, bevor er die Abfrage erreicht: Stringwerte mit pSQL() geschützt und in Anführungszeichen gesetzt, numerische Bereiche hart mit (float) gecastet. Das verwundbare Muster hängt current($values) roh an die Bedingung; das gepatchte Muster hängt pSQL(current($values)) für Strings in Anführungszeichen und für Zahlen einen gecasteten Wert an. Wenn diese Version nachweislich verwundbar ist, ist das das Schloss an der Vordertür. (Dasselbe Modul ist unter Crawler-Last auch ein Denial-of-Service-Risiko; den ?q=-Flood-Aspekt behandeln wir separat.)

2.2 Die Smarty-MySQL-Cache-RCE (CVE-2022-36408)

Das ist der Teil der Kette, der Datenbankzugriff in Codeausführung verwandelt: Der datenbankgestützte Smarty-Template-Cache kann dazu gebracht werden, von Angreifern kontrolliertes PHP zu rendern. Die meisten Shops verwenden ihn nie. Deaktivieren Sie ihn vollständig in config/smarty.config.inc.php, indem Sie die Bedingung neutralisieren, die SmartyCacheResourceMysql.php lädt und den Caching-Typ auf mysql setzt, kapseln Sie dieses Include in eine dauerhaft falsche Bedingung, damit es nie erreicht werden kann. Bestätigen Sie anschließend, dass der Shop tatsächlich Dateisystem-Caching verwendet (die Einstellung PS_SMARTY_CACHING_TYPE sollte filesystem lauten; zu finden unter Advanced Parameters → Performance). Eine SQL-Injection allein ist ernst; eine SQL-Injection, die ein PHP-Template in einen Cache schreiben und ausführen kann, bedeutet vollständige Übernahme. Schließen Sie beide Hälften, und die Kette ist gebrochen.

2.3 Aufgegebene Module und die Dateien, die Angreifer erneut ins Visier nehmen

Machen Sie das Audit mechanisch. Listen Sie alte Module, ausführbare Dateien in beschreibbaren Medienpfaden und neu geänderte PHP/JS-Dateien auf, bevor Sie die Bereinigung für abgeschlossen halten:

find modules -maxdepth 2 -type f -name '*.php' -mtime +730 -print
find img upload download -type f -name '*.php' -print
find . -type f \( -name '*.php' -o -name '*.js' \) -mtime -14 -print

Alte, nicht mehr gepflegte Module (die RevSlider-Familie ist das klassische Beispiel) sind ein wiederkehrender Vektor. Die dauerhafte Lösung ist, das Modul zu deinstallieren und zu ersetzen. Tun Sie das überall dort, wo es möglich ist. Wenn Sie eines wirklich nicht entfernen können, weil das Theme davon abhängt, verweigern Sie nicht pauschal direkten PHP-Zugriff im gesamten Modulordner: Viele Module stellen legitimerweise direkte Einstiegspunkte bereit, AJAX-Skripte, Cron-URLs, Zahlungs-Callbacks, Legacy-Validierungsskripte, und ein Require all denied über jede .php würde sie brechen. Prüfen Sie stattdessen zuerst die Routen und Endpunkte des Moduls und blockieren Sie dann nur die konkreten, bekannt verwaisten Einstiegspunkte, die Angreifer erneut anvisieren, über eine gezielte .htaccess-Regel (Require all denied) für diese einzelnen Dateien. Sperren Sie anschließend die statischen Einstiegspunkte, die Angreifer nach jeder Bereinigung erneut angreifen, auf Dateisystemen, die Extended Attributes unterstützen (ext4, xfs, btrfs), machen Sie index.php und Ihre config-Dateien mit chattr +i unveränderlich. Eine spätere Shell kann eine unveränderliche Datei nicht überschreiben, ohne vorher chattr -i auszuführen, wofür sie Root-Rechte bräuchte, die sie nicht haben sollte. Die vollständigen Regeln für Root-Verzeichnis und Admin-Ordner, auf denen das aufbaut, finden Sie in unseren .htaccess-Sicherheits- und Performance-Regeln.

3. Sperren Sie die PHP-Laufzeit korrekt ab

Die PHP-Funktionen zu deaktivieren, mit denen eine Shell Betriebssystemprozesse startet, lohnt sich, aber genau dieser Schritt wird besonders häufig falsch umgesetzt, sodass er angewendet aussieht, aber nicht greift. Die Blockliste, die Sie brauchen, umfasst die Prozessstart-Familie: exec, system, shell_exec, passthru, popen, proc_open und verwandte Funktionen, außerdem dl, show_source und phpinfo. Das Setzen ist der einfache Teil. Drei übersehene Punkte entscheiden darüber, ob es überhaupt etwas bewirkt:

• disable_functions ist PHP_INI_SYSTEM. Sie wird nur aus der Start-php.ini des exakten SAPI erzwungen, der Ihre Website ausliefert. Auf einem panelverwalteten Server (Plesk, cPanel, CloudPanel) ist der Web-SAPI in der Regel ein bestimmter PHP-FPM-Pool oder eine Apache-Instanz pro Version, nicht das System-CLI-PHP, das Sie zuerst aus der Shell erreichen. Bearbeiten Sie die richtige php.ini und starten Sie genau diesen Dienst neu, sonst bewirkt Ihre Änderung nichts, obwohl sie erledigt aussieht.
• Prüfen Sie disable_functions im richtigen SAPI. ini_get('disable_functions') aus der CLI muss nicht dem entsprechen, was der Web-SAPI tatsächlich erzwingt. CLI-PHP und Ihr Web-PHP-FPM-Pool können unterschiedliche Konfigurationen haben. Der einzig verlässliche Test ist ein echter Test über das Web: ein temporäres Skript mit zufälligem Namen, sofort danach gelöscht, das function_exists('exec') aufruft und einen tatsächlich deaktivierten Aufruf wie @exec('id') versucht, per HTTP abgerufen. Vertrauen Sie dem Ergebnis des Versuchs, nicht einem Konfigurationswert aus dem falschen SAPI.
• Es ist kein Notausschalter. Es verhindert, dass eine PHP-Shell in das Betriebssystem ausbricht. Es neutralisiert keine PHP-eval-Shell, die weiterhin Dateien innerhalb von open_basedir lesen und schreiben und mit den Zugangsdaten aus app/config/parameters.php mit Ihrer Datenbank sprechen kann. Behandeln Sie es als eine Schutzschicht, nicht als die Antwort, genau deshalb stehen Erkennung (Schritt 5) und WAF (Schritt 4) daneben, nicht stattdessen.

Ein Kompatibilitätshinweis, damit Sie Uploads nicht beschädigen: Der PrestaShop-Core nutzt exec() in einigen Bild- und MIME-Erkennungspfaden, aber diese haben finfo-Fallbacks, sodass das Deaktivieren Produktbild-Uploads nicht bricht. Testen Sie Bild-Uploads trotzdem zuerst in einer Staging-Umgebung, bevor Sie es live anwenden.

4. Schalten Sie Cloudflare davor, als Virtual-Patch-Schicht

Eine Reverse-Proxy-WAF ist das, was einem Virtual Patch am nächsten kommt und sich in Minuten bereitstellen lässt: Sie prüft Anfragen, bevor diese Ihren verwundbaren Code überhaupt erreichen. Diese Rolle erfüllt sie aber nur dann, wenn Angreifer nicht an ihr vorbeirouten können.

4.1 Sperren Sie den Ursprung auf Cloudflare

Eine WAF vor einem Ursprung, der weiterhin auf seiner öffentlichen IP antwortet, ist aus Sicht des Angreifers optional, er ruft einfach die IP direkt auf und umgeht den Proxy. Beschränken Sie den Server so, dass nur Cloudflare die Ports 80 und 443 erreichen kann: eine iptables-Kette, die Cloudflares veröffentlichte IPv4- und IPv6-Bereiche (und localhost) auf diesen Ports akzeptiert und alles andere verwirft. Der Haken, den die meisten übersehen: Ihr Mail-DNS verrät die Ursprungs-IP. Ein MX-Eintrag, ein SPF-Eintrag oder eine grau geschaltete mail.-Subdomain liefert dem Angreifer Ihre echte Adresse, und die Ursprungs-Firewall sorgt dafür, dass dieses Leak für das Web harmlos bleibt. Leiten Sie also jeden Web-Record über Cloudflare (orange Wolke) und sperren Sie den Ursprung trotzdem per Firewall. Lassen Sie SSH, Mail und Panel-Ports unter eigenen Zugriffsregeln; die Web-Sperre sollte sie nie berühren.

4.2 Benutzerdefinierte WAF-Regeln, und die Erweiterungsfalle

Im Cloudflare-Free-Tarif erhalten Sie fünf benutzerdefinierte Regeln und keine regulären Ausdrücke, nur contains, eq, starts_with, ends_with und lower(). Das reicht für ein fokussiertes Regelwerk:

• Webshells und ausführbare Uploads blockieren: bekannte Shell-Dateinamen, direkte Aufrufe von PHP in aufgegebenen Modulen und jede PHP-Ausführung unter Asset-Verzeichnissen (/img/, /upload/, /themes/, /js/, /cache/), in denen PHP niemals laufen sollte.
• Injection-Schadlasten blockieren: Path-Traversal-Zeichenketten, Anfragen nach /etc/passwd, union select, information_schema, ein wörtliches öffnendes PHP-Tag, base64_decode und deren gängige kodierte Varianten.
• Sensible Dateien blockieren: /.git/, /.env, composer.json und Ihre Konfigurationsdateien, liefern Sie sie niemals öffentlich aus.
• Die schlimmsten Stör-Crawler blockieren nach User-Agent. Wenn Datenverkehr durch bösartige Bots ein dauerhaftes Problem ist und kein Einzelfall, geht unser Leitfaden zum Blockieren bösartiger Bots und unerwünschten Datenverkehrs tiefer, als es fünf Regeln können.

Die Falle, in die wir getappt sind: Apache führt oft mehr als .php aus. Eine typische AddType/AddHandler-Zeile ordnet .php3 .php4 .phtml zusammen mit .php dem PHP-Handler zu. Eine Regel, die .phtml und .phar blockiert, aber .php3 und .php4 vergisst, lässt eine Shell-Upload-Tür weit offen, genau diese Lücke fanden wir bei der Überprüfung unseres eigenen Regelwerks. Blockieren Sie jede Erweiterung, die der Server tatsächlich ausführt, und prüfen Sie Ihre reale AddType/AddHandler-Konfiguration, statt vom Standard auszugehen.

4.3 Rate-Limiting: Wissen Sie, was Ihr Tarif kann und was nicht

Rate-Limiting ist das richtige Werkzeug gegen Crawler-Fluten, die die Facettensuche hämmern. Seien Sie aber präzise bei Ihrem Tarif, denn der Free-Tarif ist deutlich stärker eingeschränkt, als die Dokumentation auf den ersten Blick vermuten lässt. Die folgende Tabelle zeigt den Unterschied, der darüber entscheidet, ob Ihre Abwehr tatsächlich auslöst:

Die praktische Folge: Sie können im Free-Tarif keine Regel bauen, die „Bots auf ?q=-Facetten-URLs drosselt“, weil der Query-String dafür unsichtbar ist. Das Beste, was Free bietet, ist ein grobes Flood-Limit pro IP auf nicht statischen Pfaden. Echtes Query- und User-Agent-bewusstes Rate-Limiting, mit Managed Challenge statt harter Blockade, die auch echte Kunden abweisen würde, benötigt den Pro-Tarif. Für einen aktiv angegriffenen Shop rechtfertigt die Facettensuche-Exponierung dieses Upgrade in der Regel, wägen Sie es gegen die Kosten des DoS ab, den es verhindert.

5. Fügen Sie Erkennung hinzu, damit Runde zwei in Stunden auffällt, nicht in Tagen

Härtung senkt die Wahrscheinlichkeit; sie macht Sie nicht immun. Der Unterschied zwischen einem schlechten Nachmittag und einem meldepflichtigen Vorfall ist, wie schnell Sie es bemerken. Der Shop aus unserer Fallstudie hatte fast zwei Tage lang unbemerkt Kartendaten von Kunden abgeschöpft, bevor jemand hinsah. Sorgen Sie für Sichtbarkeit:

• Datei-Integritätsüberwachung (AIDE, Wazuh, OSSEC oder auch ein einfacher Cronjob mit Hash-Manifest) über das Webroot, mit Alarm bei jeder neuen oder geänderten PHP-Datei, die nicht aus einem Deployment stammt. Neue PHP-Dateien außerhalb eines Releases sind das stärkste Signal, das Sie verdrahten können.
• Geplante Indicator-Sweeps nach Mustern aus realen Angriffen, die Indikatoren in unserer Anatomie eines Magecart-Angriffs sind eine fertige Startliste, plus jede neu auftauchende Datei mit ausführbarer Erweiterung in Asset- oder Upload-Verzeichnissen.
• Regelmäßige Prüfung der Cloudflare Security Events, nicht nur nach einem Vorfall. Ihre WAF ist auch ein Sensor, und sie protokolliert die Versuche, die Ihre Regeln blockiert haben; daraus sehen Sie, was gerade probiert wird.

6. Das Admin-Panel ist weiterhin eine Tür, schließen Sie auch sie

Eine gefüllte Sperrliste je Bereich: eine vollständige Seitensperre, eine reine Checkout-Sperre und eine reine Login-Sperre, jeweils mit IP, Sperrtyp und Grund.

Alles oben schützt das öffentliche Frontend. Lassen Sie das Backoffice nicht ungehärtet in der Annahme, Angreifer kämen nur über den Katalog: Ein geleakter oder per Brute Force erratener Admin-Login umgeht Ihre Virtual Patches vollständig. Bei einem nicht upgradefähigen Shop ist das noch wichtiger, nicht weniger, weil das Login-Formular selbst alten Code ausführen kann. Benennen Sie mindestens das Admin-Verzeichnis um, erzwingen Sie überall HTTPS (unser Leitfaden zur Einrichtung von SSL und HTTPS zeigt, wie das sauber geht) und ergänzen Sie einen zweiten Faktor sowie eine echte Passwortrichtlinie, die vollständige Behandlung finden Sie in Zwei-Faktor-Authentifizierung, Passwortrichtlinien und Admin-Sicherheit. Kombinieren Sie das mit IP-basierter Blockierung von Wiederholungstätern, die wir in IP-Sperren für problematische Besucher Schritt für Schritt erklären.

7. Die eigentliche Heilung bleibt die Migration

Alles oben ist gestaffelte Verteidigung für Software, die keine Sicherheitsupdates mehr erhält. Es erhöht die Angriffskosten, schließt die aktiv ausgenutzten Türen und verschafft Ihnen die Wochen oder Monate, die eine echte Migration braucht, aber es kauft Zeit, keine Sicherheit. Der Shop aus unserer Fallstudie zeigt genau warum: Er wurde bereinigt, und derselbe Angreifer kam durch eine Anwendungsschwachstelle zurück, die die Bereinigung nie gepatcht hatte. Planen Sie den Wechsel zu PrestaShop 8 oder 9 auf sauberer Infrastruktur, mit rotierten Zugangsdaten, als eigentliche Behebung. Behandeln Sie die Härtung hier als das, was den Betrieb aufrechterhält, bis Sie dort angekommen sind.

Eine weitere sinnvolle Schutzschicht: eine CSP im Report-only-Modus

Alles oben versucht zu verhindern, dass ein Skimmer auf die Festplatte geschrieben wird. Eine Content-Security-Policy ist die Schicht, die den Schaden begrenzt, falls doch einer durchrutscht. Sie beschränkt, von wo der Browser Skripte laden darf und wohin er Daten senden kann, genau das Verhalten, das ein Karten-Skimmer benötigt. In einem nicht upgradefähigen Shop sollten Sie sie zuerst im report-only-Modus ausrollen, damit protokolliert wird, was sie blockieren würde, ohne Ihre eigenen Theme- und Modulskripte zu brechen. Beobachten Sie die Berichte eine Woche lang, ergänzen Sie die legitimen Ursprünge, die Ihr Theme tatsächlich nutzt, und schalten Sie dann auf Erzwingen um.

# Apache: start in report-only so nothing breaks while you learn your own origins.
# Tighten 'self'/allow-lists to your real theme + payment + analytics hosts, then
# switch the header name to Content-Security-Policy to enforce.
Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' https://js.stripe.com; connect-src 'self' https://api.stripe.com; frame-src https://js.stripe.com; object-src 'none'; base-uri 'self'"

Für einen feststeckenden Shop ist der Punkt derselbe wie bei jedem anderen Schritt hier: Eine CSP im Report-only-Modus verwandelt eine stille Skimmer-Injection in eine protokollierte Anomalie, die Sie in Stunden erkennen können; eine erzwungene CSP kann den Exfiltrations-Teil direkt stoppen. Sie ergänzt die Erkennung aus Schritt 5. Der Policy-Verstoßbericht ist selbst ein Alarm. Ersetzen Sie die Stripe-Hosts oben durch das Gateway und die Analytics-Dienste, die Ihr Shop tatsächlich lädt; eine zu breite Allowlist macht den Zweck zunichte.

Häufig gestellte Fragen

Ist virtuelles Patchen eine echte Lösung oder nur ein Aufschub des Unvermeidlichen?

Es ist eine Übergangslösung, und genau so sollten Sie es behandeln. Es erhöht die Angriffskosten und schließt die konkreten Türen, die gerade eingetreten werden; damit kaufen Sie die Wochen oder Monate, die eine echte Migration braucht, aber Sie kaufen Zeit, keine Sicherheit. Der Shop aus unserer Fallstudie wurde bereinigt, und anschließend kam derselbe Angreifer über eine Anwendungsschwachstelle zurück, die die Bereinigung nie gepatcht hatte. Planen Sie den Wechsel zu PrestaShop 8 oder 9 auf sauberer Infrastruktur als eigentliche Behebung.

Ich habe die gefährlichen PHP-Funktionen deaktiviert, aber eine Test-Shell lief trotzdem. Warum?

disable_functions is PHP_INI_SYSTEM, sie greift nur in der Start-php.ini des exakten SAPI, der Ihre Website ausliefert; auf einem panelverwalteten Server ist das in der Regel ein bestimmter PHP-FPM-Pool, nicht das CLI-PHP, das Sie zuerst aus der Shell erreichen. Bearbeiten Sie die richtige php.ini, starten Sie genau diesen Dienst neu und verifizieren Sie es über eine echte HTTP-Anfrage statt über CLI-ini_get(), das eine andere Konfiguration lesen kann. Abschnitt 3 oben zeigt den korrekten Test.

Schützt der Cloudflare-Free-Tarif einen verwundbaren Shop?

Teilweise. Er kann Webshells, Injection-Schadlasten und sensible Dateien mit fünf benutzerdefinierten Regeln blockieren, und das lohnt sich. Was er nicht kann: beim Rate-Limiting auf Query-Strings oder User-Agents matchen. Eine Regel, die „Bots auf ?q=-Facetten-URLs drosselt“, ist im Free-Tarif also nicht möglich, weil der Query-String für ihn unsichtbar ist. Für einen aktiv angegriffenen Shop rechtfertigt die Facettensuche-Exponierung in der Regel Pro.

Muss ich den Ursprung wirklich per Firewall sperren, wenn Cloudflare bereits davorsteht?

Ja. Eine WAF vor einem Ursprung, der weiterhin auf seiner öffentlichen IP antwortet, ist aus Sicht des Angreifers optional, er ruft die IP direkt auf und überspringt den Proxy. Und Ihr Mail-DNS (ein MX-Eintrag, SPF oder eine grau geschaltete mail.-Subdomain) verrät diese IP regelmäßig. Beschränken Sie Ports 80 und 443 auf Cloudflares veröffentlichte Bereiche, damit das Leak für das Web harmlos bleibt; lassen Sie SSH, Mail und Panel-Ports unter eigenen Regeln.

Beschädigt es PrestaShop, Dateien mit chattr unveränderlich zu machen?

Bei Dateien, die sich zwischen Deployments nicht ändern sollten (index.php und Ihre config-Dateien), ist es sicher, und es funktioniert nur auf Dateisystemen, die Extended Attributes unterstützen (ext4, xfs, btrfs; manche Container-Overlay- und ZFS-Setups tun das nicht). Eine künftige Webshell kann eine unveränderliche Datei nicht überschreiben, ohne vorher chattr -i auszuführen, wofür sie Root-Rechte bräuchte, die sie nicht haben sollte. Machen Sie keine ganzen Verzeichnisse unveränderlich, in die PrestaShop schreibt, etwa var/ oder img/.

Weiterlesen

• Anatomie eines Angriffs im Magecart-Stil auf einen PrestaShop-1.7.x-Shop. Der Vorfall, dessen Wiederholung jeder Schritt hier verhindern soll.
• PrestaShop-Sicherheitshärtung: die vollständige Checkliste, die Basis, auf der diese fortgeschrittene Schicht aufbaut.
• Reaktion auf eine Datenschutzverletzung: was zu tun ist, wenn Ihr Shop gehackt wird, falls Sie das nach einem Einbruch lesen, nicht davor.

Und wenn Sie das nach einem Einbruch lesen statt davor, wechseln Sie die Spur: Unser Leitfaden zur Reaktion auf Datenschutzverletzungen erklärt, was in den ersten Stunden zu tun ist, und die Anatomie des Angriffs, die jeden Schritt oben motiviert hat, zeigt Ihnen, womit Sie es tatsächlich zu tun haben.