Origin-IP verbergen: ein Offshore-Reverse-Proxy, der hält

Was das Verbergen des Origin wirklich bringt

Drei Dinge, und es lohnt sich, dabei präzise zu sein. Erstens: Die Flut erreicht nicht mehr die Maschine, die sie nicht wegstecken kann — ein einzelner VPS hat einen endlichen Uplink, und wenn die Adresse, die die Pakete frisst, ein zweckgebauter Edge ist statt der Box mit Ihrer Datenbank, wird ein volumetrischer Angriff zum technischen Problem von jemand anderem. Zweitens: Die Anwendung lässt sich nicht länger an ihren eigenen Schutzmaßnahmen vorbei erreichen — Rate Limits, Bot-Regeln, eine WAF und Geoblocking lassen sich von jedem trivial umgehen, der sich direkt mit dem Origin verbinden kann, und die meisten, die sie einrichten, prüfen nie, ob das noch möglich ist. Drittens: Die Adresse, die Ihre Inhalte ausliefert, ist nicht mehr dieselbe Adresse, die Ihre Daten hält — genau diese Trennung sorgt dafür, dass eine Abuse-Beschwerde, ein Scan oder eine gezielte Sonde an einem Ort landen, der billig und ersetzbar ist.

Und jetzt die ehrliche Hälfte. Einen Origin zu verstecken ist keine Anonymität — es verbirgt eine Adresse, keine Person, und die Zahlungsspur, die Domain-Registrierung und das Konto dahinter sind ein eigenes Problem, für das es einen eigenen Guide gibt. Es flickt Ihre Anwendung nicht: Ein Origin, den niemand findet, ist in dem Moment genauso angreifbar, in dem ihn jemand findet — und Origins werden gefunden. Es verbirgt nichts vor Ihrem Provider, der per Definition weiß, welche Maschine auf welcher Adresse antwortet. Betrachten Sie es als eine Schicht, die die Kosten eines Angriffs erhöht, aufgesetzt auf eine Box, die vorher richtig gehärtet wurde — nicht als Ersatz für eines von beidem.

Jeder Weg, auf dem eine Origin-IP durchsickert

Der Grund, warum so viele versteckte Origins gar nicht versteckt sind, ist, dass man einen Kanal schließt und annimmt, die übrigen wären mitgezogen. Sind sie nicht. Hier die Liste, die wir durcharbeiten, grob in der Reihenfolge, wie oft sie es tatsächlich war, die jemandem zum Verhängnis wurde:

• Historisches DNS. Passive-DNS-Sammler zeichnen Ihren A-Eintrag schon auf, lange bevor Sie hinter einen Proxy gezogen sind. Die Adresse, die Sie letztes Jahr benutzt haben, ist ein dauerhaft durchsuchbarer, kostenloser Lookup.
• Certificate Transparency. Jedes öffentlich vertrauenswürdige Zertifikat wird in Append-Only-Logs veröffentlicht, zusammen mit jedem Hostnamen, den es abdeckt. Ein Zertifikat für origin.example.com verkündet diesen Namen der ganzen Welt, und sein A-Eintrag erledigt den Rest.
• Subdomains, die nie umgezogen sind. mail, ftp, webmail, cpanel, dev, staging, vpn, monitor — die Apex-Domain ging hinter das CDN, und diese hier zeigten weiter auf die Box.
• Mail. Ein MX-Eintrag auf dem Origin verrät die Adresse direkt; dasselbe tut ein Received:-Header in einer Mail, die Ihre Anwendung verschickt hat — auslösbar von jedem über ein Passwort-Reset-Formular.
• Ausgehende Anfragen. Webhooks, Avatar-Abrufe, RSS-Pulls, Link-Vorschauen, Update-Prüfungen, OAuth-Callbacks. Jede davon verrät die Adresse des Origin an denjenigen, der das andere Ende betreibt — und eine URL-Vorschau-Funktion lässt einen Angreifer dieses andere Ende selbst wählen.
• Antworten auf die nackte Adresse. Bedient der Origin Ihre Seite noch bei einer Anfrage ohne passenden Host-Header, haben internetweite Scanner ihn längst indexiert: Favicon-Hash, Seitentitel, Zertifikats-Fingerabdruck und die Reihenfolge der HTTP-Header sind alle durchsuchbar.
• Der vergessene IPv6-Eintrag. Der A-Eintrag zeigt jetzt auf den Proxy; der AAAA-Eintrag zeigt weiterhin nach Hause.
• Die Anwendung, die über sich selbst redet. Absolute URLs in einer CMS-Konfiguration, Redirects auf einen internen Hostnamen, Stack-Traces, Server-Banner, Source Maps, ein unauthentifizierter Status-Endpunkt.

Beachten Sie, was die meisten davon gemeinsam haben: Sie sind dauerhaft. Zertifikats-Logs sind Append-Only, und passives DNS ist ein Archiv. Eine veröffentlichte Adresse lässt sich nicht zurückrufen — Sie können sie nur nicht mehr benutzen, und genau deshalb zählt die Reihenfolge der Schritte weiter unten.

Zwei Formen von Edge: ein CDN oder eine eigene Box

Ein kommerzielles CDN gibt Ihnen Anycast-Kapazität, die kein einzelner Server erreicht, in Dutzenden Städten, oft schon in der kostenlosen Stufe. Der Preis dafür ist, dass TLS auf Infrastruktur terminiert, die Sie nicht kontrollieren: Der Betreiber sieht Ihren Klartext, weiß, zu welchem Konto er gehört, und kann gezwungen werden, auf dieses Wissen zu reagieren — oder eines Morgens einfach entscheiden, dass Ihr Inhalt nicht erwünscht ist. Es gibt außerdem ein subtileres Problem, das speziell bei geteilten Fronten auftritt — erlaubt Ihre Origin-Firewall die veröffentlichten Adressbereiche des CDN, dann steckt jeder andere mit einem Konto bei diesem CDN in Ihrer Allowlist und kann seinen eigenen Hostnamen auf Ihren Origin zeigen lassen. Das ist ein echter Bypass, kein theoretischer, und genau deshalb gibt es authentifizierten Origin Pull.

Ein Edge, den Sie selbst betreiben, ist der umgekehrte Tausch. Niemand außer Ihnen hält den privaten Schlüssel, die Box steht in einer Jurisdiktion, die Sie bewusst gewählt haben, und sie kostet $8.00/Monat für den kleinsten Plan — wirklich nur ein Rundungsfehler gegen das, was sie schützt. Was Sie nicht bekommen, ist Anycast: Eine 200-Gbps-Flut sättigt den Uplink des Edge, egal wie elegant Ihre nginx-Konfiguration ist, also muss die Absorption auf Netzwerkebene irgendwoher kommen. In unserem Fall ist das die 1.5 Tbps Upstream-Mitigation vor jeder Maschine der Flotte — genau das macht einen selbst betriebenen Edge tragfähig, statt zu dem einen Punkt zu werden, an dem alles zusammenbricht. Die beiden Formen lassen sich auch kombinieren: CDN davor für Reichweite und Volumen, Ihr eigener Knoten dahinter für den Teil, den Sie nicht aus der Hand geben wollen. Entscheiden Sie danach, welchen Ausfall Sie lieber erklären müssten.

Der Tunnel ist der Teil, den die meisten falsch machen

Der übliche Aufbau ist ein Origin, der auf 0.0.0.0:443 lauscht, mit einer Firewall, die die Adressen des Proxys in eine Allowlist einträgt. Das funktioniert, und es ist das schwächste Glied im Design. Allowlists driften — veröffentlichte Bereiche ändern sich, und das Update wird nie nachgezogen; sie werden geteilt, sodass sie auf einem öffentlichen CDN jeden anderen Kunden mit zulassen; und sie versagen offen in genau die Richtung, die zählt, denn der Origin ist die ganze Zeit über ein lebendiger öffentlicher Listener, der nur auf eine Fehlkonfiguration oder ein ufw disable während einer Debugging-Sitzung wartet.

Die Version, die hält, kehrt das um: Der Origin hat überhaupt keinen öffentlichen Listener. Zwischen Edge und Origin wird ein WireGuard-Tunnel aufgebaut, der Webserver bindet sich ausschließlich an die Tunnel-Adresse, und die öffentliche Schnittstelle hat für beide IP-Familien eine Default-Deny-Richtlinie ohne Ausnahme für 80 oder 443. Erreichbarkeit ist dann keine Regel mehr, deren Erneuerung jemand vergessen kann — sie ist die Abwesenheit einer Route. WireGuard ist hier das richtige Werkzeug, weil es ein Kernel-Modul mit winziger Angriffsfläche ist, weil es gegenüber unauthentifizierten Scannern stumm bleibt (ein unauthentifiziertes Paket bekommt überhaupt keine Antwort, sodass der UDP-Port nicht einmal zu existieren scheint), und weil es einstellige Mikrosekunden pro Paket kostet. Wenn Sie noch keinen aufgesetzt haben: Der WireGuard-Guide deckt die Grundlagen ab; hier brauchen wir nur eine Punkt-zu-Punkt-Verbindung zwischen zwei Peers.

Eine Regel, bevor Sie anfangen, und es ist die, die Ihnen den Nachmittag rettet: Halten Sie die ganze Zeit über eine zweite SSH-Sitzung offen. SSH hinter einem Tunnel einzusperren, den Sie noch umkonfigurieren, ist der klassische Weg, eine Maschine zu verlieren, und bei einem Host ohne hinterlegte Identität gibt es keine Support-Leiter zu erklimmen und keine Konsolen-Sitzung, die Ihnen irgendjemand gewähren könnte — der Weg zurück hinein ist ein Redeploy und eine Wiederherstellung, was schnell geht, wenn Ihre Backups aktuell sind, und endgültig ist, wenn nicht.

Zertifikate, und das Log, das Ihre Hostnamen veröffentlicht

Certificate Transparency ist eine wirklich gute Sache, die Ihnen trotzdem mühelos die Woche verhageln kann. Jedes Zertifikat, das eine öffentliche CA ausstellt, wird an Append-Only-Logs gemeldet, die jeder durchsuchen kann, und der Eintrag enthält jeden Namen im Zertifikat. Stellen Sie eines für origin.example.com oder direct.example.com aus, und Sie haben dauerhaft und in strukturierter Form genau den Hostnamen veröffentlicht, den Sie eigentlich nicht bekanntgeben wollten. Schlimmer noch: Die Angewohnheit, Staging- und Admin-Hostnamen in dieselbe SAN-Liste zu packen, macht aus einer unachtsamen Erneuerung eine Landkarte Ihrer Infrastruktur.

Die Disziplin dahinter ist einfach. Öffentliche Zertifikate leben ausschließlich auf dem Edge und decken nur die Namen ab, die die Öffentlichkeit tatsächlich benutzt. Der Origin bekommt ein selbstsigniertes Zertifikat oder eines von einer kleinen privaten CA, in der Proxy-Konfiguration festgepinnt mit proxy_ssl_trusted_certificate — auf einer Strecke, die nur Ihr eigener Proxy spricht, muss nichts öffentlich vertrauenswürdig sein, und ein öffentliches Zertifikat dafür auszustellen, bringt Ihnen nichts außer einem Eintrag in einem Log. Brauchen Sie viele öffentliche Subdomains, veröffentlicht ein Wildcard einen Namen statt dreißig. Und stellen Sie ACME auf die DNS-01-Challenge um: HTTP-01 verlangt, dass auf Port 80 etwas für den zu validierenden Hostnamen antwortet — genau der öffentliche Listener, den Sie gerade entfernt haben. Akzeptieren Sie schließlich die Asymmetrie — Logs sind Append-Only, ein bereits veröffentlichter Hostname lässt sich nicht zurückziehen. Zeigte er auf den Origin, braucht der Origin eine neue Adresse.

Mail, und die anderen Dienste, die auf der falschen Adresse antworten

Mail ist der klassische Bypass, weil sie per Definition erreichbar sein muss. Zeigt der MX-Eintrag Ihrer Domain auf den Origin, ist die Übung vorbei, bevor sie begonnen hat — der Eintrag ist öffentlich, und ein einziges dig beendet die Suche. Selbst wenn MX woanders liegt, stempelt eine Anwendung, die Mail direkt vom Origin verschickt, die Adresse des sendenden Hosts in die Received:-Kette jeder Nachricht, und jedes Formular, das auf Zuruf eine Mail an einen Nutzer verschickt, macht daraus einen Self-Service-Lookup. Die Lösung ist, den Origin zum Client zu machen und nie zum Server: Leiten Sie ausgehende Mail über einen Submission-Dienst oder eine separate Box, lassen Sie MX auf einer Maschine, die gefunden werden darf, und lesen Sie die vollständigen Header einer Testnachricht, bevor Sie es als erledigt abhaken. Eigene Mail im großen Stil zu betreiben ist ein eigenes Projekt für sich und gehört nicht auf die Maschine, die Sie verstecken.

Machen Sie dann eine Rundum-Prüfung auf alles andere, das still lauscht. Monitoring-Agenten, Container-Dashboards, Datenbank-Ports, die „vorübergehend“ geöffnet wurden, ein Metrics-Endpunkt auf 9100, ein Kontrollpanel auf einem hohen Port, ein SSH-Daemon auf der öffentlichen Schnittstelle. Jeder davon ist ein Dienst, der auf der Adresse antwortet, die Sie eigentlich privat halten wollen, und Scanner finden hohe Ports genauso leicht wie niedrige. Die Prüfung ist ein einziger Befehl — ss -tulpn — und das korrekte Ergebnis ist eine Liste, in der nichts an eine öffentliche Adresse gebunden ist. Schritt drei weiter unten sorgt genau dafür, und dafür, dass es so bleibt.

Egress: die Verbindungen, die Ihr Origin selbst aufbaut

Ein Origin, der nichts annimmt, kann sich trotzdem verraten, denn er empfängt nicht nur Verbindungen — er baut auch welche auf. Paket-Mirrors, NTP, ein Webhook an einen Zahlungsdienstleister, eine Bot-API, ein Bild, das für eine Link-Vorschau geholt wird, eine Lizenzprüfung, eine ausgehende SMTP-Sitzung, ein Git-Remote, ein Error-Reporter. Für das andere Ende jeder dieser Verbindungen ist die öffentliche Adresse des Origin schlicht die Quelladresse der Verbindung. Meistens ist das harmlos, weil Sie das andere Ende selbst gewählt haben und ihm vertrauen. Das Problem ist die Handvoll Endpunkte, die ein Angreifer wählt: Fügen Sie einen Link in irgendetwas ein, das eine Vorschau rendert, registrieren Sie einen Webhook, oder finden Sie eine Server-Side Request Forgery in einem Bild-Importer, und der Origin löst auf und verbindet sich mit einem Host, den der Angreifer beobachtet. Das ist eine Deanonymisierung in zwei Minuten, ganz ohne Exploit.

Es gibt zwei vertretbare Antworten. Die strikte leitet den gesamten Egress über den Tunnel und lässt ihn vom Edge per NAT umsetzen, sodass die ausgehende Quelladresse des Origin die des Edge ist — eine Einstellung in der Peer-Konfiguration, dazu Forwarding und eine Masquerade-Regel am anderen Ende. wg-quick übernimmt die Routing-Schleife für Sie: Bei einer 0.0.0.0/0-Route installiert es eine fwmark-Regel, damit die Pakete des Tunnels selbst weiterhin direkt zum Endpunkt gelangen — genau die Stelle, die kaputtgeht, wenn man die Routen von Hand schreibt. Die pragmatische Antwort behält direkten Egress für Traffic, den Sie kontrollieren, und stellt einen Proxy vor alles, was eine vom Nutzer angegebene URL abruft. Nicht vertretbar ist, nicht zu wissen, welche der beiden Sie haben. Entscheiden Sie es bewusst, und überprüfen Sie es dann mit einer Anfrage an einen Host, den Sie selbst besitzen, und einem Blick auf die Quelladresse in dessen Logs.

Was es kostet, und wie Sie beweisen, dass es funktioniert

Der Budgetposten ist ein zusätzlicher VPS. Der kleinste Plan ab $8.00/Monat terminiert TLS und leitet den Traffic einer kleinen Seite weiter, ohne die Last überhaupt zu bemerken — ein Reverse-Proxy ist im Wesentlichen eine Socket-Kopie, und 2 vCPU mit 4 GB RAM reichen bequem weit über den Punkt hinaus, an dem der Origin dahinter zum Flaschenhals wird. Stellen Sie ihn in eine andere Region als den Origin, damit ein einzelnes rechtliches Instrument oder ein einzelnes Problem im Rechenzentrum nicht beide erreicht, und denken Sie an die Latenz: Ein zusätzlicher Hop kostet echte Millisekunden, ein Edge in Amsterdam vor einem Origin in Kuala Lumpur ist also eine Design-Entscheidung und kein Versehen. Paare innerhalb desselben Kontinents kosten typischerweise einen einstelligen Millisekundenbereich, und die TLS-Session-Wiederverwendung, die Sie am Edge gewinnen, gleicht das bei einem echten Seitenaufruf oft wieder aus.

Zu beweisen, dass es funktioniert, ist der Teil, der eine Konfiguration von einer Kontrolle unterscheidet, und es ist eine wiederkehrende Aufgabe statt einer einmaligen — jede neue Subdomain, jedes neue Zertifikat, jede neue Integration ist eine neue Gelegenheit, die Adresse erneut zu veröffentlichen. Die Testreihe in Schritt sieben dauert etwa zehn Minuten: Versuchen Sie, Ihre Seite direkt über die Origin-Adresse zu erreichen, listen Sie jeden Hostnamen auf, den Sie je zertifiziert haben, gehen Sie die naheliegenden Subdomain-Namen durch, prüfen Sie den vergessenen AAAA-Eintrag, und schicken Sie sich selbst eine Mail. Führen Sie das nach jeder Infrastrukturänderung aus. Und behalten Sie dabei die Schlussfolgerung im Kopf: Antwortet der Origin, ist die richtige Lösung keine weitere Firewall-Regel — es ist eine neue Adresse, denn die alte steckt bereits in irgendjemandes Archiv. Im Stack sitzt diese Schicht nach der Härtung und neben den Off-Site-Backups: Härtung entscheidet, wie schwer die Box zu knacken ist, Backups entscheiden, wie schnell Sie sich erholen, und dies entscheidet, wie schwer die Box überhaupt erst zu finden ist.

Schritt für Schritt

1. 01

   Den Edge deployen und ihm genau eine Aufgabe geben

   Deployen Sie einen zweiten VPS in einer Region, in der nicht der Origin steht, und behandeln Sie ihn als Appliance mit genau einem Zweck: TLS-Terminierung, ein Reverse-Proxy, und sonst nichts. Keine Datenbank, kein Anwendungscode, keine Shell-Skripte, die irgendwem fehlen würden. Fahren Sie die Checkliste für die erste Stunde darauf — SSH nur mit Schlüssel, Default-Deny-Firewall für beide IP-Familien, unbeaufsichtigte Sicherheitsupdates —, öffnen Sie danach genau drei Ports.

   ssh root@198.51.100.20
   apt update && apt full-upgrade -y
   hostnamectl set-hostname edge-01
   apt install -y nginx wireguard-tools ufw unattended-upgrades
   
   ufw default deny incoming && ufw default allow outgoing
   ufw limit 22/tcp
   ufw allow 80,443/tcp
   ufw allow 51820/udp
   ufw --force enable

2. 02

   Den Tunnel hochfahren, bevor Sie DNS anfassen

   Zwei Peers, eine Verbindung. Erzeugen Sie auf jeder Maschine ein Schlüsselpaar und geben Sie dem Tunnel ein eigenes kleines Subnetz — der Origin wird am Ende nur unter 10.66.0.2 erreichbar sein, sonst nirgends. Der Origin wählt sich beim Edge ein (er ist die Seite, die am Ende keine offenen Ports hat), trägt also den Endpoint und ein Keepalive; der Edge lauscht nur.

   # on both machines
   umask 077; wg genkey | tee privkey | wg pubkey > pubkey
   
   # edge-01 — /etc/wireguard/wg0.conf
   [Interface]
   Address = 10.66.0.1/24
   ListenPort = 51820
   PrivateKey = <edge-privkey>
   
   [Peer]
   PublicKey = <origin-pubkey>
   AllowedIPs = 10.66.0.2/32
   
   # origin-01 — /etc/wireguard/wg0.conf
   [Interface]
   Address = 10.66.0.2/24
   PrivateKey = <origin-privkey>
   
   [Peer]
   PublicKey = <edge-pubkey>
   Endpoint = 198.51.100.20:51820
   AllowedIPs = 10.66.0.1/32
   PersistentKeepalive = 25

   Aktivieren Sie ihn auf beiden Seiten und bestätigen Sie den Handshake, bevor Sie weitermachen — ein Tunnel, der nur bis zum nächsten Neustart funktioniert, ist schlimmer als gar keiner.

   systemctl enable --now wg-quick@wg0
   wg show          # expect a recent handshake and non-zero transfer
   ping -c3 10.66.0.1   # from the origin

3. 03

   Den Origin aus dem öffentlichen Internet unerreichbar machen

   Das ist der Schritt, der die eigentliche Arbeit leistet — und der, bei dem Leute sich selbst aussperren. Öffnen Sie eine zweite SSH-Sitzung und lassen Sie sie verbunden, bevor Sie irgendetwas von dem Folgenden ausführen — hier gibt es keine Support-Konsole, auf die Sie zurückgreifen könnten. Binden Sie dann den Webserver an die Tunnel-Adresse, verwerfen Sie alles auf der öffentlichen Schnittstelle, und erlauben Sie nur den Tunnel plus den WireGuard-Endpunkt selbst.

   # /etc/nginx/sites-available/app  — listen on the tunnel only
   listen 10.66.0.2:8080;
   
   ufw --force reset
   ufw default deny incoming
   ufw default allow outgoing
   ufw allow in on wg0 to any port 8080 proto tcp
   ufw allow in on wg0 to any port 22 proto tcp
   ufw allow from 198.51.100.20 to any port 51820 proto udp
   ufw --force enable
   
   # the audit: nothing may be bound to a public address
   ss -tulpn | grep -Ev '10\.66\.0\.2|127\.0\.0|\[::1\]'

   Gibt dieser letzte Befehl einen Dienst aus, ist das ein Leck — beheben Sie die Bind-Adresse, statt eine Firewall-Regel darum herumzubauen. Zwei Listener dürfen überleben: WireGuard auf 51820, und sshd, falls Sie ihn noch nicht auf den Tunnel verlegt haben.

4. 04

   TLS am Edge terminieren und über den Tunnel weiterleiten

   Stellen Sie das öffentliche Zertifikat auf dem Edge aus, für die Namen, die die Öffentlichkeit tatsächlich benutzt, und leiten Sie stromaufwärts an die Tunnel-Adresse weiter. Der zweite Server-Block ist keine optionale Dekoration: Er verhindert, dass der Edge Ihre Seite an einen Scanner ausliefert, der sich per IP ohne Host-Header verbindet — genau so wird die Eingangstür gefingerprintet.

   # edge-01 — /etc/nginx/sites-available/example.com
   server {
       listen 443 ssl;
       http2 on;
       server_name example.com www.example.com;
   
       ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
       add_header Strict-Transport-Security "max-age=63072000" always;
   
       location / {
           proxy_pass http://10.66.0.2:8080;
           proxy_set_header Host              $host;
           proxy_set_header X-Real-IP         $remote_addr;
           proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
           proxy_http_version 1.1;
       }
   }
   
   # anything that is not a known hostname gets nothing at all
   server {
       listen 80 default_server;
       listen 443 ssl default_server;
       ssl_reject_handshake on;
       return 444;
   }

5. 05

   Dem Origin die echte Client-IP zurückgeben

   Hinter einem Proxy kommt jede Anfrage von 10.66.0.1. Bleibt das so, werden Ihre Access-Logs nutzlos, IP-basiertes Rate Limiting drosselt den Tunnel statt den Angreifer, und fail2ban bannt irgendwann den Edge und legt damit die Seite lahm — ein wirklich beliebter Weg, sich beim Härten selbst einen Ausfall einzuhandeln. Vertrauen Sie dem Forwarded-Header, aber nur von der Tunnel-Adresse, niemals aus der Welt.

   # origin-01 — /etc/nginx/conf.d/realip.conf
   set_real_ip_from 10.66.0.1;
   real_ip_header   X-Forwarded-For;
   real_ip_recursive off;

   Tun Sie dasselbe in der Anwendung — ProxyFix in Flask, TRUSTED_PROXIES in Laravel, set_real_ip_from plus die eigene Trusted-Proxy-Liste des Frameworks — und legen Sie das Rate Limiting auf den Edge, wo die echte Client-Adresse nativ vorliegt:

   # edge-01 — /etc/nginx/nginx.conf (http block)
   limit_req_zone $binary_remote_addr zone=front:10m rate=20r/s;
   # then, inside the location block
   limit_req zone=front burst=40 nodelay;

6. 06

   Mail und Egress von der Origin-Adresse verlagern

   Zeigen Sie MX auf eine Maschine, die gefunden werden darf, schicken Sie ausgehende Mail über ein Relay statt direkt vom Origin, und stellen Sie die Zertifikatserneuerung auf die DNS-01-Challenge um, damit nichts auf Port 80 antworten muss. Entscheiden Sie dann, was mit dem restlichen ausgehenden Traffic passiert. Um ihn komplett über den Edge zu leiten, erweitern Sie die AllowedIPs des Origin und lassen Sie den Edge per Masquerade übernehmen — wg-quick installiert die fwmark-Regel, die den Tunnel selbst erreichbar hält, sodass Sie keine Route für den Endpunkt von Hand schreiben müssen.

   # origin-01 — /etc/wireguard/wg0.conf, in [Peer]
   AllowedIPs = 0.0.0.0/0, ::/0
   
   # edge-01 — forward and NAT the tunnel
   echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-fwd.conf && sysctl --system
   ufw route allow in on wg0 out on eth0
   # in /etc/ufw/before.rules, above the *filter block:
   # *nat
   # :POSTROUTING ACCEPT [0:0]
   # -A POSTROUTING -s 10.66.0.0/24 -o eth0 -j MASQUERADE
   # COMMIT
   systemctl restart ufw && wg-quick down wg0 && wg-quick up wg0

   Prüfen Sie es dann vom Origin aus: curl -s https://ifconfig.co muss die Adresse des Edge zurückgeben, nicht seine eigene.

7. 07

   Nach dem eigenen Origin jagen, dann das Runbook schreiben

   Greifen Sie ihn so an, wie es jemand anderes tun würde. Der erste Befehl ist der wichtige — bedient der Origin Ihre Seite noch, wenn er direkt angesprochen wird, funktioniert von alldem oben noch nichts.

   # does the origin answer for your hostname?
   curl -sk --resolve example.com:443:203.0.113.10 https://example.com/ \
        -o /dev/null -w '%{http_code}\n'      # want: a timeout, not 200
   
   # every hostname you have ever certified, from the public logs
   curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
     | grep -o '"name_value":"[^"]*"' | sort -u
   
   # records that never moved
   dig +short example.com A; dig +short example.com AAAA; dig +short example.com MX
   for h in www mail ftp webmail cpanel dev staging vpn monitor origin direct; do
     printf '%-9s %s\n' "$h" "$(dig +short $h.example.com | tr '\n' ' ')"
   done

   Schicken Sie sich dann von der Anwendung aus selbst eine Mail und lesen Sie die vollständige Received:-Kette, und fügen Sie einen Link zu einem Host, den Sie kontrollieren, in jede Funktion ein, die Vorschauen rendert, und prüfen Sie, welche Adresse ihn abgerufen hat. Notieren Sie sich, wie ein korrektes Ergebnis für jede Prüfung aussieht, und wiederholen Sie das Ganze nach jeder DNS-Änderung, jedem neuen Zertifikat und jeder neuen Integration. Taucht bei einer davon der Origin auf, bauen Sie ihn auf einer frischen Adresse neu auf — die veröffentlichte ist bereits archiviert, und keine Firewall-Regel holt sie zurück.