Angriffsschutz | SeenSecure Hilfe

🛡️ Mehrschichtige Verteidigungsarchitektur

Der "Angriffsschutz" ist kein einzelnes Drei-Schichten-Modul: Er ist die Kombination aller Verteidigungsmodule, die in aufeinanderfolgenden Schichten zusammenarbeiten. Jede Schicht deckt die Schwächen der vorherigen ab. Keine schützt allein; zusammen bilden sie eine echte Defense in Depth.

Schicht	Was sie blockiert	Dokumentation
1. Early Shield (PRO)	Ungewöhnliche HTTP-Methoden, Null-Bytes, überlange URLs, Exploit-Muster (Path Traversal) und Zugriffe auf sensible Dateien — noch bevor WordPress lädt	Early Shield
2. Firewall WAF	Fuzzing, Parameter-Pollution, Redirect-Injektion, WAF-Signaturen (3 Modi)	Firewall · Modi
3. Anti-Bot (5 Ebenen)	Automatisierte Bots, Scraper, Headless-Browser, falsche Crawler, gefälschte IPs	Anti-Bot
4. Anti-Injektion	SQLi, XSS, LFI/RFI, Command Injection, Deserialisierung, XXE, LDAP, SSRF, Open Redirect in URLs, Formularen, Cookies und Headern	Anti-Injektionsschild
5. Redirect-Bereinigung	Token-Leck, API-Schlüssel und sensible Daten in Redirect-URLs	Bereinigung
6. Referer Context	Basis-CSRF, kritische POSTs ohne legitimen Ursprung, Bots ohne Referer	RCP
7. Rate Limiting	Brute Force, intensives Scraping, übermäßige Anfragen pro IP	Rate Limiting
8. Geo-Blocking	Verkehr aus Hochrisikoländern und geolokalisierte automatisierte Ströme	Geo-Blocking
9. Upload-Schutz	PHP-Shells, ausführbare Dateien, gefälschte MIME, Doppelerweiterung, Null-Byte	Uploads
10. Sicherheits-Header	Reflektiertes XSS, Clickjacking, MIME-Sniffing, MITM, CSP, SRI	Headers
11. DDoS-Resilienz	Anfragesättigung und Notfallmodus auf Anwendungsebene	DDoS-Resilienz
12. Hardening	Benutzer-Enumeration, Verzeichnislisting, Dateiexposition, APIs	Härtung
13. Schutznetzwerk	IPs, die von mehreren Standorten bestätigt wurden (kollaborativer Feed, nur PRO)	Netzwerk · Threat Intel
14. Login Security + 2FA	Login-Brute-Force, CAPTCHA, eingeschränkte Konten, zweiter Faktor	Login · 2FA
15. Scanner + Backups	Malware, Schwachstellen, Dateiintegrität und Notfallwiederherstellung	Scanner · Backups

💡 So lesen Sie diese Tabelle: Sie müssen nicht alles auf einmal aktivieren. Beginnen Sie mit der Firewall im Monitor-Modus, prüfen Sie die Protokolle 24–48 Stunden lang und wechseln Sie schrittweise zu Protect. Die Schichten 4, 5 und 6 (Anti-Injektion, Bereinigung und Referer) sind auf dieser Seite im Detail dokumentiert.

🔀 Redirect-URL-Bereinigung

Bereinigt automatisch die Parameter von Redirect-URLs, um sensible Daten wie E-Mails, API-Schlüssel, Authentifizierungstoken, Passwörter und andere vertrauliche Informationen zu entfernen, bevor der Benutzer weitergeleitet wird.

🎯 Was es schützt

Informationspreisgabe: Verhindert, dass sensible Daten in URLs, Protokollen, Referer-Headern oder dem Browserverlauf auftauchen.

Token-Leck: Entfernt API-Schlüssel, Authentifizierungstoken und Geheimnisse vor der Weiterleitung.

E-Mail-Sammlung: Entfernt E-Mail-Adressen, die in URL-Parametern offengelegt werden.

🧹 Daten, die entfernt werden

▪ Emails:    user@example.com, admin@site.com
▪ API Keys:  ?api_key=abc123, &apikey=xyz789
▪ Tokens:    ?token=secret123, &auth=bearer_token
▪ Passwords: ?password=mypass, &secret=confidential

⚡ Empfohlene Einstellung: Aktiviert lassen. Es ist eine zusätzliche Sicherheitsschicht ohne Funktionsbeeinträchtigung. Bereinigt nur URLs bei Weiterleitungen, ohne die normale Parameterverarbeitung zu beeinflussen.

🛡️ Anti-Injektionsschild (SQL/XSS/LFI/Befehle/XXE/SSRF)

Erkennt und blockiert Injektionsversuche in URLs, Formularen, Cookies und HTTP-Headern. Fungiert als Sicherheitsnetz, das Angriffe stoppt, selbst wenn ein Plugin oder Theme Schwachstellen aufweist. Deckt 9 Angriffsarten ab: SQL Injection, XSS, LFI/RFI, Command Injection, PHP-Deserialisierung, XXE, LDAP-Injection, SSRF und Open Redirect.

Attack types it blocksAngriffsarten, die es blockiert

SQL Injection

Versucht, Datenbankdaten (Benutzer, Beiträge, Konfiguration) mit Sonderzeichen wie ', -- oder UNION in Parametern zu lesen, zu ändern oder zu löschen.

XSS

Injiziert schädliche Skripte in Seiten, um Sitzungen, Cookies zu stehlen oder Benutzer umzuleiten. Erkennt <script>-Tags, onerror-, onload-Ereignisse und javascript:-Schemas.

LFI / RFI

Versucht, lokale (/etc/passwd) oder entfernte Dateien zu laden, um schädlichen Code auszuführen. Erkennt Muster wie ../, file://, php://filter und absolute Systempfade.

Command Injection

Versucht, Befehle im Betriebssystem des Servers selbst (nicht der Datenbank) über einen Parameter auszuführen, indem Sonderzeichen (Backticks, Semikolons, &&, Pipes |) mit einem bekannten Befehl kombiniert werden. Beispiel: ?id=1; cat /etc/passwd oder ?file=foto.jpg`whoami`.

Deserialización PHP

Sendet ein von Hand erstelltes "serialisiertes" PHP-Objekt in einem Parameter, um die interne Logik der Website bei der Rekonstruktion zu manipulieren (kann manchmal zu Codeausführung führen). Erkennbar an einem sehr charakteristischen Format wie O:8:"stdClass":1:{...}.

XXE

Sendet ein XML-Dokument mit einer "externen Entität", die den Server dazu bringen soll, interne Dateien (wie /etc/passwd) zu lesen oder einen anderen Server zu kontaktieren. Erkennbar an einem <!DOCTYPE> mit einer <!ENTITY>, die auf file:// oder ein anderes Schema verweist. Beispiel: <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>.

LDAP Injection

Manipuliert einen LDAP-Suchfilter (verwendet von Unternehmens-Authentifizierungssystemen), indem Klammern und Operatoren hinzugefügt werden, um die Validierung zu umgehen oder Verzeichnisdaten zu extrahieren. Beispiel: *)(uid=*))(|(uid=*.

SSRF

Versucht, den SERVER SELBST dazu zu bringen, eine ausgehende Anfrage an ein internes oder verbotenes Ziel zu senden (localhost, internes Netzwerk oder Cloud-Metadaten-Endpunkt), meist durch Übergabe einer URL als Parameterwert. Beispiel: ?url=http://169.254.169.254/latest/meta-data/ oder ?image=http://127.0.0.1:6379/.

Open Redirect

Manipuliert einen Weiterleitungsparameter (wie ?redirect_to=), sodass der Benutzer nach einer legitimen Aktion (z. B. Login) auf einer vom Angreifer kontrollierten externen Seite landet — hauptsächlich in Phishing-Kampagnen eingesetzt. Beispiel: ?redirect_to=https://boesartige-seite.com oder ?next=//evil.com.

🔍 Wo es wirkt

Überprüft den Verkehr an drei wichtigen Punkten:

URLs und GET/POST-Parameter: Suchanfragen, Formulare, Filter, Seiten.

Cookies: Besonders manipulierte Sitzungen mit schädlichen Payloads.

HTTP-Header: User-Agent, Referer und andere mit Injektions-Payloads.

⚙️ Konfigurationsoptionen

Aktion

Aus: erkennt und protokolliert genau wie Monitor, blockiert aber nie (der Schalter "Aktiviert" oben schaltet die Erkennung selbst ein oder aus).
Challenge: blockiert mit 403 + protokolliert die IP für 2h.
Block: blockiert mit 403 + protokolliert die IP für 2h.
Nur Anfrage blockieren: liefert einmalig einen 403, protokolliert die IP aber NICHT in "Blockierte IPs" — nützlich beim Testen des Schutzes oder bei legitimem Traffic hinter gemeinsam genutztem NAT/Proxy.
Monitor: protokolliert nur, blockiert nichts.

Empfindlichkeit

Niedrig: Nur sehr klare Muster. Minimale Fehlalarme.
Mittel (empfohlen): Gleichgewicht zwischen Erkennung und Fehlalarmen.
Hoch: Maximale Erkennung. Kann Fehlalarme verursachen.

Allowlists

Pfade: URLs, die nicht überprüft werden (z.B. /wp-json/, /admin-ajax.php).
Parameter: Parameternamen, die ignoriert werden (z.B. s, paged, rest_route).

💡 Empfehlung: Beginnen Sie mit Challenge + Mittel. Bei Fehlalarmen die Empfindlichkeit senken oder den genauen Pfad zur Allowlist hinzufügen. Fügen Sie KEINE Angriffs-Payloads zur Allowlist hinzu.

⚠️ Wichtig, wenn Sie es deaktivieren: Wenn Sie den Schalter "Aktiviert" dieses Schilds ausschalten, werden SQLi/XSS/LFI/Command Injection nicht mehr blockiert — es sei denn, der Schalter Sicherheits-Header (Firewall → Header) ist aktiviert, der als Ausweichmechanismus für dieselben Angriffe dient. Sind beide Schalter gleichzeitig aus, werden diese Versuche nur protokolliert, nicht blockiert. Das Panel warnt Sie mit einer roten Meldung genau auf diesem Tab, wenn es diese Situation erkennt.

Referer-Kontextschutz (RCP)

Validiert den Ursprung von HTTP-Anfragen anhand des Referer-Headers. Wenn eine kritische POST-Anfrage (Login, Formularübermittlung) keinen Referer hat oder von einer nicht autorisierten externen Domain kommt, wird sie blockiert. Es ist eine leichte und schnelle Schicht, die arbeitet, bevor die Anfrage PHP erreicht.

✅ Vorteile

🚀 Leicht und schnell: Validiert nur HTTP-Header, keine Leistungseinbußen

🤖 Stoppt automatisierte Bots, die selten einen gültigen Referer senden

🛡️ Erkennt grundlegendes CSRF: Cross-Site-Anfragen ohne legitimen Referer

🔒 Schützt wp-admin vor direktem Zugriff von externen Domains

⚠️ Überlegungen

🔍 Fehlalarme: Browser/Erweiterungen können den Referer aus Datenschutzgründen blockieren

🔌 APIs/Webhooks müssen zu Ausnahmen hinzugefügt werden (z.B. /api/*, /webhook/*)

⚖️ Keine 100%ige Sicherheit: Der Referer kann gefälscht werden, stoppt aber grundlegende Angriffe

📋 Empfohlene Implementierung

"Log"-Modus für 24-48h — Fehlalarme identifizieren, ohne jemanden zu blockieren.
Protokolle prüfen und Ausnahmen hinzufügen — Fügen Sie /wp-json/*, Ihre APIs, Webhooks hinzu.
Wechseln zu "Challenge" — Sobald Ausnahmen bestätigt sind, Blockierung aktivieren.
"Block" nur bei 100%iger Sicherheit verwenden — Kein Spielraum für Fehlalarme.

💡 Tipp: RCP funktioniert am besten in Kombination mit den anderen Schutzmaßnahmen. Verwenden Sie es zusammen mit dem Anti-Injektionsschild und der Redirect-Bereinigung für eine abgestufte Verteidigung.

🌐 Schutznetzwerk (Feeds)

Zusätzlich zu den lokalen Schichten verfügt SeenSecure über sein Schutznetzwerk: die kollaborative Komponente, die Sperren unter allen PRO-Kunden teilt. Wenn Ihre Website einen Angriff blockiert, kann sie ihn anonym an den zentralen Dienst melden; der Server gleicht die Meldungen aller Standorte ab und veröffentlicht einen Feed mit IPs, die von mindestens zwei verschiedenen Standorten bestätigt wurden. Ihr WordPress konsumiert diesen Feed und blockiert im Voraus IPs, die Ihre Website noch nicht angegriffen haben, aber von der Community bereits erkannt wurden.

🔁 Ablauf

Ihre Website blockiert einen Angriff und meldet ihn anonym.
Der Server bewertet die IP und veröffentlicht sie, wenn ≥2 Standorte sie bestätigen.
Alle PRO-Kunden erhalten die IP im Feed und blockieren sie im Voraus.

🔒 Datenschutz

Es wird nur der Nachweis einer bereits ausgeführten Sperre geteilt. Besucher werden nicht verfolgt und es werden keine personenbezogenen Daten gesendet; die Domain des Standorts wird nie im Feed veröffentlicht. Der Feed wird verschlüsselt übertragen und die IPs werden mit täglich rotierendem Schlüssel plus Wasserzeichen pro Standort (Leck-Erkennung) verteilt.

📄 Vollständige Dokumentation

Vollständiger Leitfaden zum Schutznetzwerk (Melden, Feed-Konsum, DSGVO-Einwilligung, Fehlerbehebung) unter Schutznetzwerk. Listen von Drittanbietern (AbuseIPDB, AlienVault, Spamhaus) finden Sie unter Threat Intelligence.

⚠️ Voraussetzung: Der Netzwerk-Feed wird nur an PRO-Lizenzen (oder Testversionen) mit aktivem Reporting und ausdrücklicher Einwilligung des Administrators (Art. 6.1.a DSGVO) geliefert. Ohne PRO-Lizenz bleibt Ihre Website durch alle lokalen Schichten dieser Seite geschützt.

🏗️ Architektur

Die Verteidigung ist in fünf Ebenen organisiert, jede mit mehreren Schichten:

1️⃣ Netzwerkebene

IP-Filterung, Geo-Blockierung, Allow-/Blocklisten, Schutznetzwerk-Feed und Threat Intelligence.

2️⃣ Anwendungsebene

WAF-Regeln, Anti-Injektion, Redirect-Bereinigung, Referer-Kontext, Rate Limiting und Anti-Bot.

3️⃣ Dateisystemebene

Upload-Schutz, Integritätsüberwachung, Malware-Erkennung und Schutz kritischer Dateien.

4️⃣ Benutzerebene

Login-Sicherheit (Brute Force, CAPTCHA), 2FA und Verwaltung eingeschränkter Konten.

5️⃣ Datenebene

Datenbanksicherheit, Backups und Notfallwiederherstellung.

💡 Vor PHP: Die Early-Shield-, Referer-Kontext- und Rate-Limiting-Früherkennungsschichten laufen VOR dem Laden von WordPress (auf Dateiebene), sodass sie selbst ein Angriff, der das PHP-Laden sättigt, nicht deaktivieren kann.

⚡ Leistung

Die Angriffsschichten sind auf minimale Auswirkungen ausgelegt:

✅ Keine spürbaren Kosten

Redirect-Bereinigung und Referer-Kontext prüfen nur Header/Zeichenfolgen: Mikrosekunden, null zusätzliche Datenbankabfragen.

✅ Caching und In-Memory-Listen

Die Netzwerk-Blocklist wird im Speicher gecacht (höchstens ein Options-Lesevorgang pro Anfrage), und WAF-Signaturen werden nur einmal kompiliert.

✅ Asynchrone Verarbeitung

Netzwerk-Meldungen werden in Stapeln (Cron) eingereiht und gesendet, nie während der Anfrage des Besuchers.

🔧 Fehlerbehebung

🚫 Es blockiert mich / einen Benutzer

1) Prüfen Sie unter Überwachung → Verkehr den genauen Grund (anti_injection, referer_context, rate_limiting…).
2) Bei Referer: Pfad oder Domain zu den Ausnahmen hinzufügen.
3) Bei Anti-Injektion: Empfindlichkeit senken oder Parameter/Pfad zur Allowlist hinzufügen.
4) Fügen Sie Ihre IP zur Allowlist hinzu (IP-Listen), während Sie anpassen.
5) Nutzen Sie den Notfallmodus nur bei vollständigem Zugriffsverlust.

🔌 Meine API/Webhook funktioniert nicht

Fügen Sie den Pfad zu den Ausnahmen des Referer-Kontexts (/api/*, /webhook/*) und zu den Anti-Injektions-Allowlists hinzu. Zahlungen (WooCommerce, PayPal, Stripe) sind standardmäßig geschützt, ohne den Checkout zu beeinträchtigen.

❌ Der Netzwerk-Feed zeigt 0 / synchronisiert nicht

1) Aktive PRO-Lizenz und aktiviertes Reporting mit Einwilligung bestätigen.
2) In der Registerkarte Schutznetzwerk „Synchronisieren" drücken.
3) IPs erscheinen erst, wenn der Server sie veröffentlicht (≥2 Standorte). Ihr eigener Report erscheint als „eigene IP" (zählt als von Ihrer Website blockiert, auch vor der Veröffentlichung).
4) Bei Fetch-Fehlern das ssc_log prüfen.

⚠️ Goldene Regel: Bevor Sie einen Schutz deaktivieren, öffnen Sie dessen Registerkarte, sehen Sie sich die letzten Sperren an und passen Sie die Konfiguration an (Empfindlichkeit, Allowlists, Ausnahmen). Den gesamten Schutz zu deaktivieren, „weil er stört", ist genau das, worauf ein Angreifer hofft.

⭐ Bewährte Methoden

Modus schrittweise erhöhen: Monitor → Challenge → Block. Nie direkt zu Block in der Produktion wechseln, ohne Protokolle zu prüfen.
Die „reibungslosen" Schichten aktiv lassen: Redirect-Bereinigung, Anti-Injektion im Challenge-Modus, Sicherheits-Header und Basis-Anti-Bot.
Allowlists statt Deaktivierung: Wenn etwas Legitimes blockiert wird, zur Allowlist hinzufügen. Das Deaktivieren einer Schicht macht sie auch für echte Angriffe nutzlos.
Schutznetzwerk aktivieren (PRO): Melden Sie und konsumieren Sie den kollaborativen Feed: Je mehr Standorte beitragen, desto schneller und genauer ist die Blocklist für alle.
Dashboard wöchentlich prüfen: Schicht-Badges, letzte Sperren und Netzwerk-Meldungen zeigen, ob etwas angepasst werden muss.
Mit Härtung und 2FA kombinieren: Defense in Depth wird durch Website-Härtung und einen zweiten Faktor auf allen Admins vervollständigt.

🎯 Fazit: Mit allen aktiven Schichten und angeschlossenem Schutznetzwerk stoppt Ihr WordPress Angriffe, die Ihre Website noch nie gesehen hat — ohne sich auf eine einzige Verteidigungslinie zu verlassen.