Firewall: Ihre Erste Verteidigungslinie

Firewall: Das Geschützte Eingangstor

Eine Firewall ist wie ein Wächter am Eingang Ihrer Website. Sie prüft jeden Besucher (HTTP-Anfrage), bevor sie ihn hereinlässt:

• Woher kommst du? (IP)
• Was versuchst du zu tun? (URL, Anfragetyp)
• Wie verhältst du dich? (Zugriffsmuster)

Basierend auf diesen Fragen entscheidet die Firewall: zulassen, herausfordern (CAPTCHA) oder blockieren.

Modusauswahl

Die Firewall bietet verschiedene Betriebsmodi je nach Ihren Sicherheitsanforderungen. Jeder Modus bestimmt, wann die Firewall Datenverkehr blockiert und wann sie den Zugriff erlaubt.

Wie Wählt Man Den Richtigen Modus?

Die Wahl des Modus hängt von Ihrer spezifischen Situation ab:

• Gerade installiert: Beginnen Sie im Monitoring-Modus zur Beobachtung
• In Produktion: Protection ist der Standardmodus
• In der Krise: Strict für maximalen Schutz
• In der Entwicklung: Off, um die Arbeit nicht zu beeinträchtigen

Empfohlener Ablauf

1. OFF → MONITOR: Erste Tage zur Beobachtung, ohne etwas zu blockieren
2. MONITOR → PROTECTION: Dauerhafter Standardmodus, sobald keine Fehlalarme mehr auftreten
3. PROTECTION → STRICT: Nur wenn nötig

Warnung bei Schutzabsenkung

Direkt unter dem Hauptschalter dieses Bildschirms befindet sich ein zweiter, kleinerer Schalter: "Benachrichtige mich, wenn die Firewall deaktiviert wird oder der Schutz sinkt". Standardmäßig ausgeschaltet.

Wenn Sie ihn aktivieren, erhalten Sie eine sofortige E-Mail —ohne auf den regelmäßigen Sicherheitsbericht warten zu müssen—, genau in dem Moment, in dem das Schutzniveau der Firewall sinkt:

• Block oder Strict → Monitor (blockiert nicht mehr, protokolliert nur)
• Beliebiger Modus → Off (die Firewall wird komplett deaktiviert)

Es warnt nur, wenn der Schutz sinkt. Mehr Schutz zu aktivieren (z. B. von Monitor zu Block zu wechseln) löst niemals eine Warnung aus —es macht keinen Sinn, Sie zu stören, wenn Sie Ihr Setup sicherer machen.

Die E-Mail nennt klar den vorherigen und den neuen Status, mit Datum und Uhrzeit, sowie einen direkten Link zur Überprüfung der Firewall. Jede Warnung kommt als eigene E-Mail an (Datum und Uhrzeit stehen im Betreff), damit mehrere Warnungen hintereinander nicht in einem einzigen Thread gruppiert werden und die neueste verdecken.

Lässt sich sofort über denselben Schalter ein- und ausschalten —kein Speichern oder Neuladen der Seite nötig.

Firewall-Betriebsmodi

Die Firewall hat je nach Bedarf unterschiedliche "Modi". Jeder Modus ändert, wann sie blockiert.

1. Modus OFF (Deaktiviert)

Was er tut: Nichts. Die Firewall ist nicht aktiv.

Wann verwenden: Nie in der Produktion. Nur während der anfänglichen Entwicklung.

2. Modus MONITOR (Beobachten)

Was er tut: Protokolliert verdächtige Aktivitäten, blockiert aber NICHT. Er beobachtet nur.

Verhalten: Jeder erhält Zugriff, aber die Firewall protokolliert "dies wäre blockiert worden, wenn..."

Wann verwenden:

• Erste Tage nach der Installation von SeenSecure
• Um zu lernen, was auf Ihrer Seite normal vs. verdächtig ist
• Bevor Sie zu einem aggressiveren Modus wechseln

3. Modus PROTECTION (Normaler Schutz)

Was er tut: Gleichgewicht: blockiert echte Angriffe, lässt aber legitimen Datenverkehr zu.

Verhalten: Angriffe werden blockiert, normaler Datenverkehr passiert.

Wann verwenden: Normale Produktionsseiten. Standardverteidigung.

4. Modus STRICT (Streng)

Was er tut: Maximaler Schutz. Blockiert alles, was auch nur leicht verdächtig ist.

Verhalten: Kann Fehlalarme verursachen (legitime Benutzer werden blockiert).

Wann verwenden:

• Seite unter aktivem Angriff
• Sehr kritische Seite (Banking, Gesundheitswesen)
• Nach einem Hackerangriff

Wovor Schützt Die Firewall?

Jedes der folgenden ist ein echter, häufiger Angriffstyp gegen WordPress-Websites — keine hypothetischen Fälle, sondern die Techniken, die automatisierte Scanner täglich gegen praktisch jede öffentliche Website ausprobieren, auch deine. Für jeden erklären wir, wofür der Schutz dient, warum der Angreifer es versucht (was er gewinnt, wenn es klappt) und wie die Firewall handelt, um es zu verhindern.

SQL Injection (SQLi)

Wofür dieser Schutz dient: Deine Website speichert alles — Benutzer, verschlüsselte Passwörter, Beiträge, Bestellungen — in einer Datenbank, die eine Sprache namens SQL spricht. Wenn du ein Formular ausfüllst (ein Suchfeld, einen Login, einen Kommentar), wird dieser Text meist Teil einer SQL-Anweisung, die auf dem Server ausgeführt wird. SQL-Injection bedeutet, in genau dieses Feld nicht die erwarteten Daten zu schreiben, sondern Fragmente von SQL-Code — damit der Server deinen Text nicht nur speichert, sondern auch den darin eingeschmuggelten Befehl ausführt.

Warum ein Angreifer es versucht: Funktioniert die Injection, kann der Angreifer Daten lesen, die er nicht sehen sollte (verschlüsselte Passwörter, Kunden-E-Mails, in der Datenbank gespeicherte API-Schlüssel), sie ändern (sein eigenes Konto zum Administrator machen) oder sogar ganze Tabellen löschen. Es ist eine der direktesten Methoden, eine komplette Datenbank zu stehlen, ohne ein Passwort zu benötigen.

Wie die Firewall es stoppt: SeenSecure analysiert den Inhalt jedes Feldes, bevor er WordPress erreicht, und sucht nach typischen SQL-Syntaxmustern, wo eigentlich nur normaler Text stehen sollte (vereinzelte Anführungszeichen gefolgt von SQL-Schlüsselwörtern wie OR, UNION, DROP, SELECT in Kombinationen, die als legitimer Text keinen Sinn ergeben). Wird das Muster erkannt, blockiert sie die gesamte Anfrage, bevor dieser Text überhaupt zu einer SQL-Abfrage wird — die Datenbank bekommt den Angriff nie zu Gesicht.

Cross-Site Scripting (XSS)

Wofür dieser Schutz dient: Wenn jemand einen Kommentar hinterlässt, ein Profil ausfüllt oder ein Formular sendet, wird dieser Text oft später erneut auf der Seite angezeigt — für dich, für andere Besucher oder für den Administrator bei der Prüfung ausstehender Kommentare. XSS bedeutet, in diesen Text statt normalem Text echten JavaScript-Code einzuschleusen, damit dieser Code im Browser desjenigen ausgeführt wird, der ihn später ansieht.

Warum ein Angreifer es versucht: Das Ziel ist fast immer der Browser einer anderen Person — nicht der eigene des Angreifers, sondern der eines Besuchers oder, im besten Fall für den Angreifer, der des Administrators. Läuft das Skript im Browser eines eingeloggten Admins, kann es dessen Sitzung (Login-Cookie) stehlen und in seinem Namen handeln — ganz ohne dessen Passwort zu benötigen. Es wird auch genutzt, um Besucher auf Phishing-Websites umzuleiten oder gefälschten Inhalt über die echte Website zu legen.

Wie die Firewall es stoppt: Die Firewall untersucht jede gesendete Angabe auf ausführbare HTML/JavaScript-Tags (<script>, Attribute wie onerror=, onclick=, javascript:-Schemata in Links usw.), wo eigentlich nur reiner Text stehen sollte, und blockiert die Anfrage, wenn sie welche findet — bevor dieser Inhalt jemals gespeichert oder jemandem angezeigt wird.

Path Traversal

Wofür dieser Schutz dient: Manche Teile deiner Website fragen direkt in der URL nach dem Namen einer anzuzeigenden Datei (ein Bild, ein herunterladbares PDF, eine Vorlagen-Sprachdatei). Path Traversal bedeutet, statt eines normalen Dateinamens einen Pfad zu schreiben, der mit wiederholtem ../ aus dem erlaubten Ordner "herausklettert", um ganz andere Dateien auf dem Server zu erreichen.

Warum ein Angreifer es versucht: Typisches Ziel ist das Lesen von Konfigurationsdateien mit Geheimnissen — vor allem wp-config.php, die die Datenbankzugangsdaten im Klartext speichert. Mit diesen Zugangsdaten kann der Angreifer WordPress komplett umgehen und sich direkt mit der Datenbank verbinden.

Wie die Firewall es stoppt: Sie blockiert jede Anfrage, deren Parameter "Ordner hochsteigen"-Sequenzen (../ oder ihre kodierte Form %2e%2e%2f) enthalten, kombiniert mit Versuchen, auf Pfade außerhalb des erwarteten Verzeichnisses zu zeigen, und schützt explizit den direkten Zugriff auf sensible Dateien wie wp-config.php.

Remote & Local File Inclusion (RFI / LFI)

Wofür dieser Schutz dient: Manche schlecht programmierten Plugins oder Themes laden dynamisch eine PHP-Datei anhand eines URL-Parameters (zum Beispiel, um auszuwählen, welche Sprachvorlage angezeigt wird). RFI bedeutet, diesen Parameter nicht auf eine lokale Datei, sondern auf eine externe, vom Angreifer kontrollierte URL zeigen zu lassen; LFI bedeutet, auf eine lokale Datei auf dem Server selbst zu zeigen, die normalerweise nicht direkt ausgeführt werden sollte.

Warum ein Angreifer es versucht: Gelingt es ihm, den Server dazu zu bringen, eine eigene PHP-Datei auszuführen (auf seinem eigenen Server gehostet, bei RFI) oder eine manipulierbare lokale Datei (bei LFI, oft kombiniert mit dem vorherigen Hochladen einer als Bild getarnten bösartigen Datei), erreicht er vollständige Codeausführung auf deinem Server — das ultimative Ziel der meisten ernsthaften Webangriffe.

Wie die Firewall es stoppt: Sie blockiert Parameter, die vollständige URLs (http://, https://, ftp:// oder Stream-Protokolle wie php://, data://) enthalten, wo ein lokaler Dateiname erwartet wird, und wendet dieselben Path-Traversal-Schutzmaßnahmen an, damit ein Dateiparameter nicht in Systempfade "entkommt", die er nicht berühren sollte.

Directory Listing

Wofür dieser Schutz dient: Besuchst du einen Website-Ordner, der keine index.php oder index.html enthält, zeigen manche Server standardmäßig automatisch die vollständige Liste aller Dateien in diesem Ordner an — als hättest du den Datei-Explorer des Servers direkt im Browser geöffnet.

Warum ein Angreifer es versucht: Das ist kein Angriff für sich, sondern Aufklärung — der Schritt vor einem echten Angriff. Ein Angreifer, der durch Plugin- und Theme-Ordner navigiert, kann genau herausfinden, welche Version du nutzt (um nach bereits veröffentlichten bekannten Schwachstellen dieser Version zu suchen), vergessene Backup-Dateien (.sql, .zip) oder Konfigurationsdateien, die nie auf den Server hätten hochgeladen werden dürfen.

Wie die Firewall es stoppt: Sie blockiert direkt jede Anfrage an das Wurzelverzeichnis eines Plugin- oder Theme-Ordners, die keine bestimmte Datei anfordert, und liefert statt der Auflistung einen Fehler — kombiniert mit dem Schutz sensibler Dateien, der den direkten Zugriff auf Backups und Konfigurationsdateien verhindert, selbst wenn jemand deren genauen Namen kennt.

Command Injection

Wofür dieser Schutz dient: Manche Plugins (die Bilder verkleinern, PDFs erzeugen oder Dateien konvertieren) führen darunter manchmal Betriebssystembefehle auf dem Server aus und verwenden dabei einen Teil der von dir gesendeten Daten als Teil dieses Befehls. Command Injection bedeutet, in diese Daten spezielle Zeichen einzufügen, die das Betriebssystem als "Befehl beenden, neuen starten" interpretiert.

Warum ein Angreifer es versucht: Es ist das Betriebssystem-Äquivalent zur SQL-Injection auf Datenbankebene — funktioniert es, führt der Angreifer beliebige Befehle direkt auf dem Server aus (Dateien auflisten, Systembenutzer anlegen, Malware herunterladen und installieren) mit demselben Zugriffslevel wie der Webserver selbst.

Wie die Firewall es stoppt: Sie blockiert Anfragen, deren Parameter die Sonderzeichen enthalten, die das Betriebssystem zum Verketten oder Trennen von Befehlen verwendet (;, &&, |, Backticks), in Kontexten, in denen diese Zeichen keine legitime Bedeutung haben.

XML External Entity (XXE)

Wofür dieser Schutz dient: Manche WordPress-Funktionen und bestimmte Plugins verarbeiten Dateien im XML-Format (zum Beispiel beim Import von Inhalten, der Verarbeitung bestimmter Feeds oder Dokumentformaten wie .docx/.xlsx, die intern XML sind). Das XML-Format erlaubt die Definition von "Entitäten" — Abkürzungen, die sich zu anderem Inhalt erweitern —, und manche dieser Entitäten können auf lokale Dateien des Servers oder interne Netzwerkadressen zeigen.

Warum ein Angreifer es versucht: Durch Definieren einer bösartigen Entität innerhalb einer hochgeladenen oder importierten XML-Datei kann er den Server selbst dazu bringen, den Inhalt lokaler Dateien (wie wp-config.php) zu lesen und in der Antwort zurückzugeben, oder den Server als Vermittler nutzen, um interne Netzwerkdienste zu erreichen, die von außen nicht erreichbar sein sollten.

Wie die Firewall es stoppt: Neben der Upload-Schutzfunktion, die Dateien mit verdächtigem XML-Inhalt blockiert, stellt SeenSecure sicher, dass die eigene XML-Verarbeitung des Servers das Laden externer Entitäten deaktiviert hat — die eigentliche Ursache, die diesen Angriff überhaupt ermöglicht —, sodass selbst wenn eine bösartige XML-Datei verarbeitet würde, dieser gefährliche Teil des Formats einfach nicht interpretiert wird.

Angriffstyp	Schweregrad	Mindestmodus zum Blockieren
SQL Injection	⭐⭐⭐⭐⭐	Protection+
XSS	⭐⭐⭐⭐	Protection+
RFI / LFI	⭐⭐⭐⭐⭐	Protection+
Command Injection	⭐⭐⭐⭐⭐	Protection+
XXE	⭐⭐⭐⭐	Protection+
Path Traversal	⭐⭐⭐	Protection+
Directory Listing	⭐⭐	Protection+

Wie Man Die Firewall Aktiviert Und Konfiguriert

Schritt 1: Modus Wählen

Firewall > Modus > Monitoring, Protection oder Strict wählen > Speichern

Empfehlung: Beginnen Sie 48 Stunden lang mit Monitoring. Der Hauptschalter des Moduls Firewall & WAF (um es komplett zu deaktivieren) befindet sich in der Modulliste des SeenSecure-Dashboards.

Schritt 2: Protokolle Überprüfen

Firewall > Traffic Log

Sehen Sie viele Fehlalarme? Legitime Benutzer blockiert? Passen Sie die Einstellungen der jeweiligen Schutzfunktion an.

Schritt 3: Empfindlichkeit Konfigurieren

Unter Firewall → Anti-Injection & RCP hat der Anti-Injection-Schutzschild (SQLi/XSS/LFI/Befehle/XXE/SSRF) zwei eigene Einstellungen, unabhängig vom globalen Modus:

• Aktion: Off, Herausforderung, Blockieren, Nur die Anfrage blockieren (403 ohne die IP zu protokollieren), oder Monitor (nur protokollieren)
• Empfindlichkeit: Niedrig, Mittel (empfohlen) oder Hoch — höhere Empfindlichkeit blockiert mehr Muster, erhöht aber das Risiko von Fehlalarmen

Schritt 4: Ausnahmen Definieren (Optional)

Falls der Anti-Injection-Schutzschild Anfragen fälschlicherweise blockiert, fügen Sie im selben Tab hinzu:

• Pfade in der Allowlist (ein Pfad oder URL-Fragment pro Zeile)
• Parameter in der Allowlist (nach Feld-/Parametername)

Schritt 5: Auf Produktionsmodus Hochstufen

• Tag 1-3: MONITOR
• Woche 2+: PROTECTION (dauerhaft empfohlen)

Bewährte Praktiken

Schrittweise Aktivierung

1. SeenSecure installieren
2. Firewall OFF für 1 Tag (Funktionalität validieren)
3. Firewall MONITOR für 1 Woche (beobachten ohne zu blockieren)
4. Firewall PROTECTION dauerhaft

Kontinuierliche Überwachung

• Protokolle anfangs 2-3 Mal pro Woche überprüfen
• Danach 1 Mal pro Woche
• Bei neuem Muster untersuchen

Anpassungen Je Nach Website-Typ

• Einfacher Blog: PROTECTION mit mittlerer Empfindlichkeit
• E-Commerce: PROTECTION mit hoher Empfindlichkeit bei /checkout
• SaaS: PROTECTION mit sehr hoher Empfindlichkeit
• Kritisch: STRICT während der Betriebszeiten

Kommunikation mit Benutzern

Wenn die Firewall einen legitimen Benutzer blockiert:

1. Er erhält eine beschreibende Fehlermeldung
2. Sie erklärt, dass er aus Sicherheitsgründen blockiert wurde
3. Sie bietet Support-Kontakt an

🔧 Problembehandlung

Die Firewall hat etwas Legitimes blockiert (ein Plugin, ein Formular, ein Webhook)

Bestätigen Sie zuerst unter Firewall → Traffic Log, dass die Blockierung wirklich von der Firewall kam (Spalte "PROTECCIÓN") und nicht von einem anderen Schutz — das Detail dieser Zeile zeigt genau, welches Muster ausgelöst hat. Sobald das bestätigt ist:

• Bei einem wiederkehrenden Pfad oder Parameter (ein Webhook, ein Plugin-Endpunkt): fügen Sie ihn per genauem Pfad oder Parametername zur Allowlist hinzu, statt die allgemeine Sensibilität zu senken — so bleibt der Rest Ihrer Website genauso geschützt.
• Bei einem Muster, das bei normalen Formularen zu oft auslöst: reduzieren Sie zuerst die Sensibilität um eine Stufe, bevor Sie den globalen Modus herabsetzen.
• Wenn Sie das ohne Blockierungsrisiko während der Untersuchung bestätigen müssen: stellen Sie den globalen Modus vorübergehend auf MONITOR — er protokolliert weiterhin alles genauso im Traffic Log, blockiert aber nichts, während Sie die richtige Anpassung finden.

Ich muss jemanden sofort entsperren

Fügen Sie die Person direkt unter Firewall → IP-Listen hinzu (Whitelist): Eine IP auf der Whitelist hat absoluten Vorrang und umgeht die Firewall vollständig, ohne auf den Ablauf einer Blockierung zu warten.

Häufig Gestellte Fragen

Was ist der Unterschied zwischen MONITOR und LEARNING? Keiner von beiden blockiert: Beide protokollieren nur im Traffic Log, was sie blockiert hätten. Es ist dieselbe Beobachtungsphase, bevor es zu PROTECTION geht.

Sind PROTECTION und STRICT nicht dasselbe? Nein: STRICT wendet die Validierung strenger an als PROTECTION, für Websites mit hohem Risiko, auf Kosten eines höheren Fehlalarmrisikos bei hohem Traffic oder ungewöhnlichen Formularen.

Wie erkenne ich, ob die Firewall oder der Bot-Schutz etwas blockiert hat? Prüfen Sie die Spalte "PROTECCIÓN" im Traffic Log — sie zeigt genau, welches Modul aktiv wurde, kein Raten nötig.

Kann ich die Firewall nur für einen Teil der Website in einem anderen Modus haben (z. B. /checkout)? Die Allowlist funktioniert per spezifischem Pfad oder Parameter innerhalb des aktiven globalen Modus, nicht als eigener Modus pro Website-Bereich.