Public/IPV4-proxyserver-zu-IPV6-only-servern
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
783ec27601cf053ac5bf5f9dce4434941b72dbd6
IPV4-proxyserver-zu-IPV6-on…/README-Fail2ban.md
root 783ec27601 fail2ban
2026-04-12 15:25:05 +02:00

4.4 KiB
Raw Blame History

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

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