# 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