Files

T

spektr 7d1a3228ef Dokumente vereinheitlicht.

2026-09-19 15:55:58 +02:00

21 KiB

Raw Blame History

Betriebs- und Sicherheitsdokumentation – Reverse Proxy

Dokumenten-ID: GNAI-005-SEC
Titel: Reverse Proxy und Fail2Ban – Konfiguration, Betrieb und Sicherheitsabnahme
Status: NPM aktiv; Fail2Ban laut Betreiber fest gepinnt und wieder in Betrieb; Keycloak-Admin-Exposure bestätigt, Korrektur offen
Vorgänger / Referenzen: Architektur, Zugriffskonzept, WireGuard

Änderungsverlauf

Datum	Version	Autor	Beschreibung
2026-08-28	0.1	spektr	Erstellung der ersten Baseline-Drafts.
2026-09-05	0.9	spektr	Implementierung Fail2Ban Container & Test-Setup (F2B-01).
2026-09-07	1.0	spektr	Korrektur Action-Syntax (`port="80,443"`), Behebung RegEx-Fehler (`npm-badbots`), E2E-Validierung in nftables abgeschlossen (F2B-02). Finales SOP erstellt.
2026-09-14	1.1	spektr	Proxmox-Host-Version auf PVE 9.2.11 aktualisiert (Host-Update).
2026-09-15	1.2	spektr	Version/Tabellen korrigiert; bestätigte Keycloak-Exposure und TLS-Widerspruch dokumentiert; Korrekturverfahren, Fail2Ban-Upgrade/Pin und bewusste HTTP-Client-Sperren ergänzt.
2026-09-16	1.3	spektr	Fail2Ban-Image auf `1.1.0-r2-ls43` fest gepinnt; wieder laufenden Container bestätigt; verbleibende Funktions- und Wiederanlauftests getrennt ausgewiesen.
2026-09-18	1.4	spektr	Wirkung der LAN-Freigaben auf VPN-Verkehr hinter MASQUERADE unmittelbar an der Port-Matrix erläutert. Zweck als Betriebs- und Sicherheitsdokumentation geklärt; veraltete Image-Digests aus dem Verfahren entfernt.

1. Zweck & Geltungsbereich

Dieses Dokument hält Konfiguration, Betrieb und Sicherheitsabnahme des zentralen Reverse Proxy und des logbasierten Fail2Ban auf Proxmox LXC 103 (reverse-proxy) fest. Angaben zum laufenden Zustand beruhen auf den jeweils datierten Betreiberbestätigungen und Tests; eine neue Live-Prüfung von CT 103 fand bei dieser Revision nicht statt.

Umfang dieses Dokuments:

Betrieb von Nginx Proxy Manager (NPM) als zentraler Ingress-Controller
Containerisiertes Fail2Ban für logbasierte temporäre Sperren mit nftables-Integration auf dem LXC; kein allgemeines Netzwerk-IPS
Log-Parsing-Regeln und Filterdefinitionen für das NPM-spezifische Access-Log-Format
Gehärtete Firewall-Baseline und Zugriffssteuerung

2. System-Baseline (LXC 103)

Parameter	Wert
Container-ID	CT 103
Hostname	`reverse-proxy`
Betriebssystem	Debian GNU/Linux 13 (Trixie)
Unprivileged	Ja
Cores / RAM / Swap	2 Cores / 1024 MB RAM / 512 MB Swap
RootFS	8 GB
Netzwerkkonfiguration	`10.0.0.10/24`, Gateway `10.0.0.1`, Bridge `vmbr0`
LXC Features	`nesting=1`, `keyctl=1`
Proxmox Host	Proxmox VE 9.2.11

Hinweis zur Proxmox-Firewall: Laut bisheriger Implementierungsdokumentation sind Proxmox Cluster- und Node-Firewalls deaktiviert (enable 0); bei Änderungen den tatsächlichen Zustand prüfen. Die dokumentierte Filter-Baseline liegt lokal im LXC unter nftables. Effektive Regeln und weitere Netfilter-Tabellen vor Änderungen live prüfen.

3. Netzwerk- & Firewall-Architektur (nftables)

Die lokale Paketfilterung basiert auf nftables mit einer strikten INPUT policy drop-Doktrin.

table inet filter {
        chain input {
                type filter hook input priority filter; policy drop;
                iifname "lo" accept
                ct state invalid drop
                ct state established,related accept
                ip protocol icmp accept
                ip saddr 10.0.0.0/24 tcp dport { 22, 81 } accept
                tcp dport { 80, 443 } accept
        }

        chain forward {
                type filter hook forward priority filter; policy accept;
        }

        chain output {
                type filter hook output priority filter; policy accept;
        }
}

Port-Matrix

Port	Protokoll	Zweck	Erreichbarkeit
80	TCP	HTTP Ingress (NPM)	Öffentlich
443	TCP	HTTPS Ingress (NPM)	Öffentlich
81	TCP	NPM Web Admin Interface	Nur LAN (`10.0.0.0/24`)
22	TCP	OpenSSH Management	Nur LAN (`10.0.0.0/24`)
3000	TCP	NPM Node.js Backend	Intern / Nicht exponiert

10.0.0.0/24 in den Freigaben für 22/81 umfasst auch die Gateway-Adresse 10.0.0.15. Durch das aktuelle VPN-MASQUERADE erscheinen VPN-Clients bei NPM unter dieser Adresse. Die Port-Matrix beschreibt deshalb keine bereits wirksame VPN-Rollentrennung; diese muss am Gateway vor NAT umgesetzt und getestet werden.

4. Container-Infrastruktur (Podman Quadlets)

Nginx Proxy Manager und Fail2Ban werden als rootful Podman-Container via systemd Quadlets mit Network=host betrieben.

4.1 Nginx Proxy Manager Quadlet

Datei: /etc/containers/systemd/nginx-proxy-manager.container
Image: docker.io/jc21/nginx-proxy-manager:2.11.1 (ausdrücklich gepinnt)

[Unit]
Description=Nginx Proxy Manager
Wants=network-online.target
After=network-online.target

[Container]
Image=docker.io/jc21/nginx-proxy-manager:2.11.1
ContainerName=nginx-proxy-manager
Network=host
Volume=/opt/nginx-proxy-manager/data:/data:rw
Volume=/opt/nginx-proxy-manager/letsencrypt:/etc/letsencrypt:rw
Environment=DISABLE_IPV6=true
Environment=TZ=Europe/Berlin

[Service]
Restart=always
TimeoutStartSec=300

[Install]
WantedBy=multi-user.target

4.2 Fail2Ban IPS Quadlet

Datei: /etc/containers/systemd/fail2ban.container
Image, aktueller Ist-Stand: lscr.io/linuxserver/fail2ban:1.1.0-r2-ls43 (fest gepinnt). Der Betreiber bestätigt, dass der Container nach der Umstellung wieder läuft. Der Image-Build enthält Fail2Ban 1.1.0; der Build-Suffix r2-ls43 bezeichnet den LinuxServer-Image-Stand.
Capabilities: NET_ADMIN, NET_RAW (kein --privileged)

[Unit]
Description=Fail2Ban
Wants=network-online.target
After=network-online.target

[Container]
Image=lscr.io/linuxserver/fail2ban:1.1.0-r2-ls43
ContainerName=fail2ban
Network=host
AddCapability=NET_ADMIN
AddCapability=NET_RAW
Volume=/opt/fail2ban/config:/config:rw
Volume=/opt/nginx-proxy-manager/data/logs:/remotelogs/npm:ro
Environment=TZ=Europe/Berlin

[Service]
Restart=always
TimeoutStartSec=300

[Install]
WantedBy=multi-user.target

5. NPM Logformat & Parsing-Regeln

NPM nutzt ein eigenes Access-Log-Format, bei dem die eigentliche Client-IP nicht am Zeilenanfang steht.

Beispielzeile:

[03/Sep/2026:18:35:02 +0200] - 204 204 - POST https jellyfin.ghostnet.selfhost.eu "/Sessions/Playing/Progress" [Client 93.228.100.74] [Length 0] [Gzip -] [Sent-to 10.0.0.11] "JellyfinDesktop/2.0.0" "-"

Verbindliche Parser-Regeln:

Die Client-IP muss zwingend aus dem Feld [Client <HOST>] extrahiert werden.
URL-Pfade oder Host-Header dürfen nicht fälschlicherweise als IP-Quelle interpretiert werden.
Statuscodes oder Response-Zeiten sind für automatisches Banning ungeeignet, da legitim nicht erreichbare Backends (502) False Positives auslösen würden.

6. Fail2Ban-Konfiguration & Jails

LinuxServer.io nutzt /config/fail2ban/ als interne Konfigurationsstruktur. Sämtliche Konfigurationen liegen persistent auf dem Host unter /opt/fail2ban/config/fail2ban/.

6.1 Wichtige Erkenntnis zur Action-Syntax

Standardmäßig nutzt die Action nftables-multiport bei fehlenden Parametern Port 22 (SSH). Sperrports müssen zwingend direkt in der action-Zeile des Jails in eckigen Klammern übergeben werden, um Anfragen auf HTTP/HTTPS durchzusetzen:

action = nftables-multiport[port="80,443", protocol=tcp]

6.2 Jail 1: Exploit & Scanner Protection (`npm-scanner`)

Gezielte Blockade von Pfad-Traversal-Versuchen, Secret-Abfragen und automatisierten Framework-Scans.

Filter: /opt/fail2ban/config/fail2ban/filter.d/npm-scanner.conf

[Definition]
failregex = ^\[.*\] - [0-9]{3} [0-9]{3} - (GET|POST|HEAD) [^ ]+ [^ ]+ "/(?:[^"]*/)?(?:\.env[^"/]*|\.git/[^" ]*|\.aws/[^" ]*|wp-config\.php[^" ]*|wp-login\.php(?:\?[^" ]*)?|wp-admin(?:/[^" ]*)?|actuator(?:/[^" ]*)?|_ignition(?:/[^" ]*)?|storage/logs(?:/[^" ]*))" \[Client <HOST>\]
ignoreregex =

Jail: /opt/fail2ban/config/fail2ban/jail.d/npm-scanner.local

[npm-scanner]
enabled  = true
filter   = npm-scanner
backend  = auto
logpath  = /remotelogs/npm/proxy-host-*_access.log
findtime = 10m
maxretry = 3
bantime  = 1h
ignoreip = 127.0.0.1/8 10.0.0.0/24
action   = nftables-multiport[port="80,443", protocol=tcp]

6.3 Jail 2: Bad User-Agents (`npm-badbots`)

Blockade bekannter Angriffs-Scanner und Reconnaissance-Tools.

Filter: /opt/fail2ban/config/fail2ban/filter.d/npm-badbots.conf
(Wichtig: Nutzt lokale Case-Insensitivity (?i:...), um Python-RegEx-Kompilierungsfehler zu vermeiden)

[Definition]
failregex = ^\[.*\] - [0-9]{3} [0-9]{3} - (?:GET|POST|HEAD|OPTIONS) [^ ]+ [^ ]+ "[^"]*" \[Client <HOST>\] .* "[^"]*(?i:sqlmap|nikto|nmap|masscan|zgrab|nessus|openvas|dirbuster|gobuster|wpscan|python-requests|go-http-client|censys|whatweb|acunetix)[^"]*"
ignoreregex =

Jail: /opt/fail2ban/config/fail2ban/jail.d/npm-badbots.local

[npm-badbots]
enabled  = true
filter   = npm-badbots
backend  = auto
logpath  = /remotelogs/npm/proxy-host-*_access.log
findtime = 10m
maxretry = 2
bantime  = 24h
ignoreip = 127.0.0.1/8 10.0.0.0/24
action   = nftables-multiport[port="80,443", protocol=tcp]

7. Aktive Proxy Hosts

Routen aus dem bisherigen Quelleninventar; Keycloak-Backend vom Betreiber erneut bestätigt. Bei Freigaben den tatsächlichen Bestand prüfen. Diese Tabelle beweist weder TLS-Konfiguration noch OIDC-Anbindung jeder Anwendung:

ID	Hostname	Backend-Ziel	Dienst
1	`jellyfin.ghostnet.selfhost.eu`	`10.0.0.11:8096`	Jellyfin Media Server
3	`nextcloud.ghostnet.selfhost.eu`	`10.0.0.12:8080`	Nextcloud Cloud Storage
4	`git.ghostnet.selfhost.eu`	`10.0.0.17:3000`	Gitea Code Hosting
7	`auth.ghostnet.selfhost.eu`	`10.0.0.4:8080`	Keycloak Identity Provider
10	`japan.ghostnet.selfhost.eu`	`10.0.0.23:80`	Japanese Web App
12	`vault.ghostnet.selfhost.eu`	`10.0.0.47:8080`	Vaultwarden Password Manager

8. Betriebs- & Diagnosekommandos

Die folgenden Befehle auf CT 103 als root ausführen oder mit sudo ergänzen. Platzhalterwerte vor Verwendung ersetzen.

Fail2Ban-Status

# Gesamtstatus der aktiven Jails
podman exec fail2ban fail2ban-client status

# Spezifischen Jail prüfen
podman exec fail2ban fail2ban-client status npm-scanner
podman exec fail2ban fail2ban-client status npm-badbots

Filter mit echten Logs testen

podman exec fail2ban fail2ban-regex \
    /remotelogs/npm/proxy-host-10_access.log \
    /config/fail2ban/filter.d/npm-scanner.conf

nftables-Regeln & aktive Bans auf dem Host verifizieren

nft list ruleset | grep -A 10 "table inet f2b-table"

Manuelle Sperre / Freigabe

# Gewählte IP eintragen, Platzhalter nicht unverändert verwenden.
BAN_IP="<ZU-SPERRENDE-IP>"

# IP manuell sperren
podman exec fail2ban fail2ban-client set npm-scanner banip "$BAN_IP"

# IP manuell freigeben
podman exec fail2ban fail2ban-client set npm-scanner unbanip "$BAN_IP"

9. Sicherheits- & Betriebsregeln für Administrierende

Kein generisches Statuscode-Banning: Generische HTTP 4xx- oder 5xx-Fehler dürfen nicht als pauschales Ban-Kriterium verwendet werden.
Geprüfte Upgrades: NPM ist im Quellenstand auf 2.11.1 festgeschrieben. Fail2Ban ist auf 1.1.0-r2-ls43 festgeschrieben. Beide Pins regelmäßig auf Updates prüfen; Änderungen mit Backup, Tests und Rückfallplan durchführen.
Privilegien-Minimierung: Der Fail2Ban-Container wird strikt ohne --privileged betrieben (NET_ADMIN und NET_RAW reichen aus).
Whitelist-Pflicht: Das Subnetz 10.0.0.0/24 sowie 127.0.0.1/8 müssen in allen Jails in ignoreip hinterlegt bleiben, um Aussperrungen zu verhindern.
Syntax-Check vor Reload: Jede Änderung an Fail2Ban-Konfigurationen ist vorab mit podman exec fail2ban fail2ban-client -t auf Gültigkeit zu prüfen.

10. Backup & Disaster Recovery

Im bisherigen Quellenstand ist ein Proxmox-vzdump-Backup von CT 103 dokumentiert:

Backup-Datei: /var/lib/vz/dump/vzdump-lxc-103-2026_08_31-19_11_10.tar.zst

Vor strukturellen Änderungen an nftables, Proxy-Konfiguration oder Quadlets ein aktuelles konsistentes Proxmox-Backup erstellen. Ein Snapshot kann ergänzen, ersetzt aber kein unabhängiges Backup. Der genannte Archivpfad ist historischer Quellenstand, kein Nachweis eines aktuellen oder getesteten Backups.

11. Keycloak: bestätigte öffentliche Administration und Korrekturverfahren

11.1 Bestätigter Ist-Stand

Der Betreiber konnte von extern https://auth.ghostnet.selfhost.eu/admin öffnen und sich anmelden. Das widerspricht GNAI-004. Die Korrektur wurde bei dieser Dokumentationsrevision noch nicht auf dem System durchgeführt.

NPM-Einstellung	Betreiberangabe
Domain	`auth.ghostnet.selfhost.eu`
Backend	HTTP, `10.0.0.4:8080`
Access List	Publicly Accessible; keine Listen definiert
Custom Locations	keine
Optionen	Cache Assets, Block Common Exploits, Websocket Support
SSL-Einstellungen	alle aus

Custom Config enthält aktuell:

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;

TLS-Widerspruch: Externer HTTPS-Login funktionierte, obwohl für diesen Proxy Host SSL als ausgeschaltet angegeben ist. Effektiven Listener, Zertifikat und vHost-Zuordnung prüfen, bevor eine vollständige HTTPS-Bereitstellung behauptet wird. Auf CT 103 etwa:

sudo podman exec nginx-proxy-manager nginx -t
sudo ss -lntp
sudo grep -REn 'auth\.ghostnet\.selfhost\.eu|listen|ssl_certificate|location|allow|deny' \
  /opt/nginx-proxy-manager/data/nginx/proxy_host/

Generierte Dateien nur lesen, nicht direkt ändern; NPM würde Änderungen überschreiben. Block Common Exploits ersetzt keine Administrative-Pfadbeschränkung. Die vorhandenen X-Forwarded-Header ebenfalls in der effektiven Nginx-Konfiguration prüfen. Unvertrauenswürdige Client-Header dürfen nicht zur Quelle einer Managementfreigabe werden.

11.2 Sofortschutz für den öffentlichen Adminpfad

Aktuelle Proxy-Einstellungen sichern. Über Proxmox-Konsole Zugriff auf Keycloak behalten und einen funktionierenden internen Administrationsweg prüfen; mögliche Redirects auf den öffentlichen Namen beachten.
Im NPM den Proxy Host auth.ghostnet.selfhost.eu → Advanced öffnen. Im server-Kontext zusätzlich folgenden Schutz ergänzen, ohne bestehende Konfiguration blind zu ersetzen:
```
location ~* ^/admin(?:/|$) {
    deny all;
}
```
Der Schutz sperrt /admin, /admin/ und darunterliegende Admin-API-/GUI-Pfade auf diesem Proxy Host für alle Quellen, auch LAN. Das ist ein vorläufiger Schutz des öffentlichen Hosts; der dauerhafte interne Adminzugang wird separat eingerichtet. Bestehende Regex-Locations und ^~-Locations auf Prioritätskonflikte prüfen.
Speichern. NPM-Status und nginx -t prüfen. Die aktive Konfiguration kontrollieren, damit der Block sowohl für HTTP als auch für den tatsächlich verwendeten HTTPS-Listener greift. Keine Wirkung nur aufgrund eines gespeicherten Textfelds annehmen.
Aus einem fremden Netz mit deaktiviertem VPN /admin, /admin/ und /admin/master/console/ prüfen; Erwartung 403, keine nutzbare Administration. IPv4 und vorhandenes IPv6 separat prüfen. Kontrollierte Admin-API-Zugriffe müssen ebenfalls gesperrt sein. HTTP darf nicht weiterhin Zugriff erlauben.
Vaultwarden-Login einschließlich tatsächlichem Keycloak-Redirect und Tokenaustausch prüfen. Bei Änderungen nicht den gesamten auth-Host hinter eine Access List setzen, da öffentliches OIDC weiter benötigt wird.

Auf der Admin-Oberfläche können schematisch Redirects vorkommen; für Prüfungen HTTP-Status und Redirectziel festhalten. Ein 302 auf eine Admin-Anmeldung ist keine erfolgreiche Sperre. Der öffentliche Adminpfad wird erst nach externem Gegencheck als korrigiert geführt.

11.3 Dauerhafte Trennung

Einen internen Admin-Proxy Host mit separat bestätigtem Hostnamen, Zertifikat und interner Namensauflösung planen. Netzwerkzugang nur für Familie und Server Admins erlauben, am Gateway vor NAT durchsetzen und direkte Backend-Erreichbarkeit berücksichtigen. Bei Keycloak hostname-admin/Frontend-Hostname passend zur installierten Version konfigurieren. Ein Adminhostname allein schützt die Admin-REST-API auf dem öffentlichen Frontend nicht; öffentliche Pfade weiterhin sperren. Hostname-Konfiguration

Auch den tatsächlichen Administrationsrealm erfassen. Falls das master ist, /realms/master/ ebenfalls ausschließlich intern bereitstellen. Zuerst Vaultwardens produktiven OIDC-Issuer prüfen, damit ein pauschaler Realm-Block dessen Anmeldung nicht unbemerkt unterbricht. Public benötigt geeignete Anwendungsrealm-Endpunkte und Ressourcen. Health/Metrics/Managementport nicht veröffentlichen. Keycloak-Proxy-Pfade

Aktuell bestätigt ist nur Vaultwarden-OIDC. Zusätzliche Dienste sind geplant. Die tatsächliche lokale Realm-/Client-Struktur und der interne Adminhostname bleiben offen.

12. Fail2Ban: fester Image-Pin und verbleibende Abnahme

Der Betreiber bestätigt am 16.09.2026 die Umstellung auf:

Image=lscr.io/linuxserver/fail2ban:1.1.0-r2-ls43

Der Fail2Ban-Container läuft nach der Umstellung wieder. Damit ist die frühere Abweichung durch den beweglichen Tag latest behoben. Der Tag bezeichnet den LinuxServer-Container-Build; die darin enthaltene Anwendung meldet Fail2Ban v1.1.0. Das ist nicht mit einem Upstream-Upgrade auf Fail2Ban 1.1.1 gleichzusetzen.

Für die technische Abnahme sind noch Nachweise zu erfassen; aus „läuft wieder“ werden keine weitergehenden Testergebnisse abgeleitet:

Effektiven Image-Namen und Anwendungsversion prüfen: podman inspect fail2ban --format '{{.ImageName}}' sowie podman exec fail2ban fail2ban-client --version.
Konfiguration und Jails prüfen: podman exec fail2ban fail2ban-client -t, fail2ban-client status und Status der NPM-Jails.
Kontrollierte HTTP-/HTTPS-Treffer bis zum Ban auslösen, Eintrag im nftables-Regelsatz verifizieren und Test-IP anschließend wieder freigeben.
Dienstneustart und später LXC-/Host-Neustart prüfen; danach Containerstatus, Jails und Filter erneut kontrollieren.
Laufenden Image-Digest und ein aktuelles konsistentes Backup als Rückfallstand festhalten. Ein Digest-Pin kann nach Manifest-/Architekturprüfung den Tag-Pin zusätzlich härten.

Upstream-Anwendung und Container-Build bleiben getrennte Versionsachsen. Vor einem späteren Upgrade sind LinuxServer-Release, enthaltene Fail2Ban-Version, Architektur und lokale Filter/Jails erneut zu prüfen. Fail2Ban-Releases, LinuxServer-Images

13. Bewusste Betriebsentscheidung: generische HTTP-Clients bleiben gesperrt

Entscheidung des Betreibers: python-requests und go-http-client verbleiben im npm-badbots-Filter. Legitimer automatisierter Verkehr kann dadurch nach dem konfigurierten Schwellwert ebenfalls einen Ban auslösen. User-Agent ist keine starke Authentifizierung; er kann geändert werden. Dieser Filter ist eine zusätzliche Heuristik, keine vollständige Abuse-Erkennung.

Bei Bedarf darf ein berechtigter Nutzer einen erlaubten Dienst über WireGuard verwenden. Voraussetzung sind passende Rollenrechte, Routing und ein tatsächlich interner Zielpfad; nur das Aktivieren des VPN umgeht eine öffentliche Route nicht automatisch. Mit dem bestehenden MASQUERADE sieht NPM VPN→LAN-Verkehr typischerweise von 10.0.0.15, das im LAN-ignoreip liegt. Ein öffentlicher Hostname kann weiterhin zur WAN-IP auflösen und direkt benutzt werden; DNS-/Zielpfad und NPM-Quelladresse im Log prüfen.

LLM Admins dürfen nur .90 erreichen und haben keinen allgemeinen NPM-/LXC-Zugriff. API-Clients ohne passende VPN-Rolle bekommen durch diese Ausweichoption keine zusätzlichen Rechte. Bei Supportfällen diese bewusste Ban-Entscheidung ausdrücklich mitprüfen.

14. Noch offene Abnahme

Befund	Abschlussnachweis
Keycloak Admin extern nutzbar	externe Sperre von GUI und API über tatsächliche HTTP/HTTPS-/IPv6-Pfade, interner Adminzugang und Vaultwarden-OIDC weiter funktionsfähig
TLS-Zuordnung des auth-Hosts unklar	effektiver Listener, Zertifikat, Redirects und Backend-Pfad dokumentiert
Fail2Ban auf `1.1.0-r2-ls43` gepinnt und Container wieder laufend	effektives Image und Version dokumentiert; Jail-/Filter-/Ban-/Dienstneustart-/Reboottests bestanden

21 KiB Raw Blame History Unescape Escape