diff --git a/README-Fail2ban.md b/README-Fail2ban.md
new file mode 100644
index 0000000..1be14ea
--- /dev/null
+++ b/README-Fail2ban.md
@@ -0,0 +1,148 @@
+# Problemstellung: Layer-Trennung (L3 vs. L7)
+
+## Layer 7 (Application Layer) – Backend
+Fail2Ban arbeitet auf Layer 7:
+
+* **Analysiert:** HTTP-Requests (Logs)
+* **Erkennt:** Muster (Bots, Scans, SQL-Injection)
+* **Entscheidet:** „Bösartig / nicht bösartig“
+
+Dieser Prozess erfolgt auf dem Backend (**clientserver**), da nur dort:
+* Vollständige Request-Daten vorliegen.
+* Die Applikationslogik sichtbar ist.
+
+---
+
+## Layer 3 (Network Layer) – Proxy
+Das eigentliche Blocking erfolgt auf Layer 3/4:
+
+* **IP-Adresse** wird geblockt.
+* **Protokollunabhängig.**
+* **Umsetzung:** Via `nftables` (Kernel).
+
+Dieser Prozess erfolgt optimal auf dem Proxy (**proxyserver**), da:
+* Dies der erste Eintrittspunkt in das Netzwerk ist.
+* Der Traffic dort noch nicht verteilt wurde.
+
+---
+
+## Technisches Problem ohne Trennung
+Wenn das Blocking ausschließlich auf dem Backend erfolgt:
+
+1.  Paket trifft auf dem Proxy ein.
+2.  Proxy akzeptiert die Verbindung.
+3.  Proxy leitet den Request an das Backend weiter.
+4.  Backend erkennt den Angriff.
+5.  Backend blockt die IP lokal.
+
+**Daraus resultierende Probleme:**
+* Der Proxy verarbeitet weiterhin Requests des Angreifers.
+* Verbindungen werden trotzdem aufgebaut.
+* Last entsteht bereits vor dem eigentlichen Block.
+
+> **Konsequenz:** Die Layer 7 Entscheidung erfolgt zu spät im Netzwerkpfad.
+
+---
+
+## Lösung: Layer-Trennung
+
+### Architektur
+* **Layer 7 (Erkennung):** Backend
+* **Layer 3 (Blockierung):** Proxy
+
+### Ablauf mit Proxy-Blocking
+1.  Angreifer sendet Request.
+2.  Proxy leitet diesen initial weiter.
+3.  Backend erkennt den Angriff via Fail2Ban.
+4.  Backend meldet die IP an den Proxy.
+5.  Proxy trägt die IP in `nftables` ein.
+6.  Alle weiteren Pakete werden bereits am Proxy verworfen.
+
+### Effekt
+* Kein Durchreichen mehr zum Backend.
+* Keine HTTP-Verarbeitung für geblockte IPs.
+* Minimierung der Applikationslast.
+* Zentrale Kontrolle am Gateway.
+
+---
+
+## Technischer Vergleich
+
+| Ebene | Aufgabe | Ort |
+| :--- | :--- | :--- |
+| **Layer 7** | Analyse (Regex, Logs) | Backend |
+| **Layer 3/4** | Blocking (IP) | Proxy |
+
+### Notwendigkeit der Trennung
+* **Fail2Ban** benötigt Kontext (L7), der nur im Backend verfügbar ist.
+* **Firewall** benötigt Performance (L3), was nur am Einstiegspunkt effizient ist.
+
+**Diese Kombination liefert:**
+* Hohe Erkennungsqualität.
+* Minimale Systemlast.
+
+---
+
+## Fazit
+Blocking auf dem Backend ist funktional, aber ineffizient. Blocking auf dem Proxy ist effizient, benötigt jedoch eine externe Entscheidungslogik.
+
+**Die Lösung:** Erkennung auf Layer 7 (Backend) und Durchsetzung auf Layer 3 (Proxy).
+
+---
+# Fail2Ban: Proxy Forwarding Configuration (Client)
+
+Diese Dokumentation beschreibt die Konfiguration des Backend-Clients (**clientserver**), um erkannte Angriffe auf Layer 7 an den Proxy (**proxyserver**) weiterzureichen, damit diese dort auf Layer 3 blockiert werden können.
+
+## 1. Voraussetzungen
+
+* **SSH-Zugriff:** Vom Client (clientserver) zum Proxy muss eine Verbindung bestehen.
+* **SSH-Key Authentifizierung:** Muss passwortlos (Key-basiert) eingerichtet sein.
+* **SSH-Port:** Muss in der SSH-Config des Root-Users hinterlegt sein.
+* **Fail2Ban:** Muss auf beiden Systemen installiert und aktiv sein.
+
+## 2. SSH Konfiguration
+Konfiguration für den schnellen, passwortlosen Zugriff auf den Proxy.
+
+**Datei:** `/root/.ssh/config`
+```ssh
+Host proxy
+    HostName proxy.myserver.com
+    User root
+    Port 22
+    IdentityFile /root/.ssh/clientserverproxy
+    IdentitiesOnly yes
+
+
+---
+
+# Fail2Ban: Proxy-Setup (Zentraler Bann über Reverse Proxy)
+
+## Ziel
+Implementierung einer zentralen IP-Blockierung am Reverse Proxy, während die Angriffserkennung dezentral auf den Backend-Systemen erfolgt.
+
+### Architektur
+* **Backend (Client):** Erkennt Angriffe mittels Fail2Ban-Filtern (L7).
+* **Proxy (Enforcement):** Setzt Firewall-Regeln via `nftables` um (L3).
+* **Kommunikation:** Erfolgt über den Befehl `fail2ban-client set recidive banip <ip>`.
+
+---
+
+## Problemstellung
+Beim Einsatz eines Reverse Proxys ergeben sich folgende Hürden:
+* **Logs:** Enthalten zwar die Client-IP (via `X-Forwarded-For`), aber...
+* **Firewall:** Die Backend-Firewall sieht nur die IP des Proxys.
+
+**Ergebnis:** Fail2Ban erkennt den Angriff zwar korrekt, ein lokaler Block auf dem Backend bleibt jedoch wirkungslos, da der Traffic weiterhin über den Proxy fließen kann.
+
+---
+
+## Lösung
+Konsequente Trennung von **Detection** (Backend) und **Enforcement** (Proxy).
+
+---
+
+## Proxy-Konfiguration
+
+### 1. Installation
+```bash
+apt install fail2ban