fail2ban
This commit is contained in:
148
README-Fail2ban.md
Normal file
148
README-Fail2ban.md
Normal file
@@ -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
|
||||
Reference in New Issue
Block a user