149 lines
4.4 KiB
Markdown
149 lines
4.4 KiB
Markdown
# 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
|