„Sollte ich ein CDN davorschalten?“ ist die erste Frage, die sich die meisten nach dem Kauf eines Offshore-Servers stellen, und sie hat keine einzige Antwort, weil es in Wirklichkeit zwei Fragen in einem Mantel sind. Einen Angriff abzufangen und unauffindbar zu bleiben sind unterschiedliche Probleme mit unterschiedlichen Lösungen, und die Lösung für das eine kann das andere still zunichtemachen.
Die Verwechslung kostet in beide Richtungen. Manche stellen ein großes amerikanisches CDN vor Inhalte, für die sie bewusst DMCA-ignoriertes Hosting gewählt haben, und liefern damit eine Beschwerdestelle genau an den Mittelsmann zurück, den sie vermeiden wollten. Andere verzichten auf alles, werden von einer Flut auf Anwendungsebene getroffen, die Netzwerkfilterung nie erkennen sollte, und schließen daraus, der DDoS-Schutz sei gelogen gewesen. Dieser Leitfaden trennt die beiden Probleme, sagt, was jede Schicht tatsächlich leistet, und widmet den Großteil seiner Länge dem Teil, der so oder so über den Ausgang entscheidet: den sechs Wegen, auf denen eine Ursprungsadresse leckt, selbst wenn alles andere korrekt konfiguriert ist.
Zwei Probleme, die wie eines aussehen
Alles, was Sie vor einen Server stellen, erfüllt eine von zwei Aufgaben: einen Angriff von ihm fernzuhalten oder seine Adresse unbekannt zu halten. Beides überschneidet sich genug, um verwechselt zu werden, und unterscheidet sich genug, dass die Lösung des falschen Problems Geld verschwendet.
| Wovor Sie sich fürchten | Was es wirklich löst | Was nicht |
|---|---|---|
| Eine volumetrische Flut, die Ihre Leitung füllt (Schicht 3 und 4) | Netzwerk-Filterung am Rand beim Host, in jedem Tarif hier inklusive | Nichts, was Sie auf dem Server installieren — dann ist die Leitung längst voll |
| Eine Anwendungs-Flut aus Anfragen, die echt aussehen (Schicht 7) | Ein CDN oder WAF, Caching, Rate Limiting, günstigere Endpunkte | Paketfilterung, die gültiges HTTP sieht und durchlässt |
| Niemand soll die Maschine direkt erreichen können | Eine Front (CDN oder eigener Knoten) plus eine Firewall, die nur diese akzeptiert | Ein CDN allein, wenn der Ursprung weiterhin dem gesamten Internet antwortet |
| Niemand soll erfahren, wer dahintersteht | No-KYC-Anmeldung, Zahlungsprivatsphäre, Kontodisziplin | Jede noch so große Infrastruktur — das ist eine Identitätsfrage |
| Der Inhalt muss Beschwerden überstehen | Jurisdiktion und ein Host, der nicht auf sie reagiert | Ein CDN, das einen Beschwerdekanal hinzufügt, statt einen zu entfernen |
Lesen Sie die letzte Zeile zweimal, denn sie ist es, die den meisten zum Verhängnis wird. Alles andere auf dieser Seite ist Technik. Diese Zeile nicht.
Was Ihr Host bereits erledigt, und wo es aufhört
Filterung auf Schicht 3 und 4 ist bei jedem Tarif, den wir verkaufen, ohne Aufpreis inbegriffen und läuft am Netzwerkrand statt auf Ihrem Server — der einzige Ort, an dem das funktionieren kann, denn eine gesättigte Anbindung lässt sich durch nichts reparieren, das dahinter läuft. Bandbreite ist unbegrenzt, ein Angriff wird also nicht zur Rechnung. Für den Großteil dessen, was man gemeinhin „einen DDoS“ nennt, ist das schon die ganze Geschichte.
Was diese Filterung nicht sieht, ist die andere Art. Fünfhundert Anfragen pro Sekunde an einen Such-Endpunkt von vierzigtausend privaten Adressen sind kein fehlerhafter Datenverkehr; es ist Datenverkehr. Slowloris-Verbindungen, die alle paar Sekunden ein Header-Fragment nachliefern, wirken einzeln betrachtet höflich. Ein mit echten POST-Bodys bombardiertes Login-Formular ist auf Paketebene nicht von einem geschäftigen Montag zu unterscheiden. Kein Paketfilter hilft, weil an den Paketen nichts auszusetzen ist.
Es gibt eine Richtung des Datenverkehrs, bei der wir tatsächlich eingreifen, und das sei klar gesagt: Angriffe und Massen-Spam, die aus unserem Netzwerk stammen, können per Null-Routing vom Netz genommen werden, um den Rest der Infrastruktur gesund zu halten. Das ist eine betriebliche Maßnahme, keine inhaltliche — die Unterscheidung, die unser Leitfaden zu DMCA-ignoriertem Hosting ausführlicher zieht.
Was ein CDN verbirgt, und welche Abuse-Stelle Sie sich einhandeln
Der Mechanismus ist einfach und wirklich wirksam. Ihre Domain löst zu den Adressen des Anbieters auf, Clients verbinden sich dorthin, und der Anbieter holt die Daten von Ihrem Ursprung. Die echte Adresse taucht in der Verbindung eines Clients nie auf und kann daher von niemandem angegriffen werden, der nur die Domain kennt. Derselbe Trick ist der Grund, warum CDN-Fronting bei zensurresistenten Proxys funktioniert: Ein Zensor sieht Datenverkehr zu einer Adresse, die er sich nicht leisten kann zu blockieren.
Drei Dinge kommen damit ins Haus, und keines steht im Kleingedruckten versteckt:
- Der Edge terminiert Ihr TLS. Datenverkehr liegt im Inneren des Anbieter-Netzwerks absichtlich im Klartext vor — so funktionieren Caching und Filterung. Was Ihre Nutzer eintippen, erreicht einen Dritten, bevor es Sie erreicht.
- Ein Abuse-Kanal, den es vorher nicht gab. Beschwerden können direkt gegen das CDN eingereicht werden, und ein CDN beantwortet sie: indem es an Sie weiterleitet, Ihren Hosting-Anbieter benennt oder Ihnen kündigt. Wenn Ihr Grund für Offshore-Hosting ist, dass Beschwerden ins Leere laufen, verbindet ein vorgeschalteter US-Mittelsmann genau die Kette wieder, für deren Durchtrennung Sie bezahlt haben.
- Ein Konto. E-Mail-Adresse, Zahlungsmethode, oft eine Telefonnummer, an Ihre Domain gebunden und unbegrenzt aufbewahrt. Mehr dazu weiter unten, denn das ist meist das schwächste Glied der ganzen Konstruktion.
Nichts davon macht ein CDN falsch. Es macht es zu einer Entscheidung mit zwei Seiten: hervorragend für einen Shop oder eine Anwendung mit echten Nutzern und echtem Druck auf Schicht 7, aktiv kontraproduktiv für Publishing, das Takedowns anzieht. Unsere eigene Antwort auf die Frage auf der Seite zu DMCA-ignoriertem Hosting war immer die Kurzfassung davon: Für Takedown-Resistenz nutzen Sie die Netzwerkfilterung, die Sie ohnehin schon haben, und verzichten auf das CDN.
Die sechs Wege, auf denen eine Ursprungsadresse trotzdem leckt
Das ist der Abschnitt, der zählt, denn Verschleierung ist kein Produkt, das man kauft — es ist eine Eigenschaft, die man entweder aufrechterhält oder verliert, meist binnen Tagen, an eine von sechs Ursachen. Ursprungsserver werden täglich hinter tadellosen CDN-Konfigurationen gefunden.
- Certificate-Transparency-Logs. Jedes öffentlich vertrauenswürdige Zertifikat, das für Ihre Domain ausgestellt wird, landet binnen Minuten in öffentlichen, dauerhaften, durchsuchbaren Logs. Sie veröffentlichen nicht Ihre Adresse, sie veröffentlichen Ihre Hostnamen —
staging,mail,vpn, die Subdomain, die Sie einmal 2024 eingerichtet haben. Jeder davon lässt sich auflösen, und ein einziger Eintrag, der nicht auf die Front zeigt, beendet die Übung. - DNS-Historie. Passiv-DNS-Dienste archivieren jede Adresse, zu der Ihre Domain je aufgelöst hat. Sich nachträglich hinter ein CDN zu stellen, macht das bereits Aufgezeichnete nicht ungeschehen — Verschleierung muss beginnen, bevor die Domain zum ersten Mal auflöst, sonst brauchen Sie eine neue Adresse, keine neue Front.
- Einträge, die sich nicht proxen lassen, und die, die Sie vergessen haben. Mailserver-Einträge müssen auf etwas Erreichbares zeigen. Ebenso ein
AAAA-Eintrag, der übrig blieb, weil Sie nur IPv4 geproxt haben, ein alter FTP- oder Panel-Hostname, ein Wildcard-Eintrag oder der „vorübergehende“ Entwicklungs-Host, der inzwischen drei Jahre alt ist. - Alles, was der Server verschickt. Mail vom Ursprung trägt dessen Adresse in den
Received-Headern — eine Passwort-Reset-Nachricht ist Selbstauskunft. Webhooks, ausgehende Bildabrufe, Link-Vorschauen, Pingbacks, Update-Prüfungen und Crash-Reporting-Tools melden sich alle von der echten Adresse, und wer Ihre Anwendung dazu bringen kann, mit einem selbst kontrollierten Host zu sprechen, erfährt sie. - Internetweites Scannen. Jede IPv4-Adresse wird von öffentlichen Diensten fortlaufend gescannt und indexiert, und die Ergebnisse sind in Sekunden abfragbar. Antwortet Ihr Ursprung auf Port 443 mit Ihrem Zertifikat oder liefert er Ihre Startseite bei jedem beliebigen Host-Header aus, genügt eine Abfrage nach Body-Hash, Zertifikats-Fingerabdruck oder Favicon-Hash, um ihn zuzuordnen. So werden die meisten Ursprungsserver gefunden, und es kostet den Finder nichts.
- Die Anwendung, die über sich selbst spricht. Absolute URLs und Weiterleitungen, die die rohe Adresse enthalten, offen gelassene Status- oder Metrik-Endpunkte, ausführliche Stack Traces, die interne Hosts nennen, Header, die das Backend verraten, und der Standard-Virtual-Host, der jedem, der per Adresse fragt, bereitwillig Ihre Seite ausliefert.
Den Ursprung so absichern, dass nur die Front ihn erreicht
Verschleierung, die davon abhängt, dass niemand die Adresse errät, ist keine Verschleierung. Die Konstruktion hält nur, wenn der Ursprung mit niemandem außer der Front spricht, sodass eine geleakte Adresse ein Ärgernis bleibt statt zum Ereignis zu werden.
- Standardmäßig alles blockieren, dann die Front freigeben. Lassen Sie 80 und 443 nur aus den veröffentlichten Adressbereichen des Anbieters zu, und aktualisieren Sie diese Liste automatisch — die Bereiche ändern sich, und eine veraltete Liste versagt im schlimmsten Moment offen oder geschlossen. Alles andere, einschließlich SSH, gehört auf einen Tunnel oder eine Management-Adresse, wie in unserer Checkliste für die erste Stunde.
- Die Front authentifizieren. Client-Zertifikate zwischen CDN und Ursprung — meist als Authenticated Origin Pulls bezeichnet — sorgen dafür, dass selbst eine korrekte Adresse plus korrekter Host-Header ohne das Zertifikat nichts bekommt.
- Besser: gar keine eingehenden Ports. Ein rein ausgehender Tunnel vom Ursprung zum Edge — ob der CDN-eigene Connector oder WireGuard zu einem selbst betriebenen Knoten — bedeutet, dass der Ursprung nie auf einer öffentlichen Schnittstelle lauscht. Scannen kann nicht finden, was nicht antwortet, und das ist die mit Abstand stärkste Version der Konstruktion.
- Ein Virtual Host, ein Host-Header. Der Standardserver sollte nichts Brauchbares zurückgeben. Lädt Ihre Seite über die Adresse, wird sie binnen einer Woche von einem Scanner erfasst.
- Mail vom Web-Ursprung fernhalten. Mail muss erreichbar sein und sich zu erkennen geben; halten Sie sie auf einer eigenen Maschine, wie es der Mailserver-Leitfaden voraussetzt.
- Von außen verifizieren. Jede Prüfung in dieser Liste ist bedeutungslos, wenn sie vom Server selbst aus läuft. Testen Sie von einem Netzwerk, das nicht Ihres ist.
Der eigene Frontknoten statt eines CDN
Die dritte Option wird übersprungen, weil sie kein Marketingbudget hat: ein kleiner VPS als öffentliches Gesicht, ein verschlüsselter Tunnel zurück zur Maschine, die die Daten hält, und nginx oder HAProxy, das den Datenverkehr zwischen beiden vermittelt. Von außen sieht es aus wie jeder andere Webserver. Der echte steht woanders, ganz ohne eingehende Ports.
Was Sie dafür bekommen, ist Verschleierung ohne einen Dritten in der Konstruktion — kein Konto bei einem Drittanbieter, keine externe Abuse-Stelle, kein Fremder, der Ihr TLS terminiert. Sie bekommen außerdem eine Aufteilung der Jurisdiktion, die sich sonst kaum kaufen lässt: die Front dort, wo die Nutzer sind, die Daten dort, wo das Recht Ihnen zusagt, wählbar aus unseren sieben Standorten. Und weil bei der Anmeldung keine Identität hinterlegt wurde, ist die Front eine Wegwerf-Ressource — eine verbrannte Adresse wird in Minuten ersetzt statt verhandelt.
Was Sie nicht bekommen, ist Anycast-Kapazität. Ein Knoten hat die Kapazität eines Knotens, und während unsere Netzwerkfilterung ihn genauso schützt wie jeden anderen Server, ist ein wirklich großer volumetrischer Angriff ein Wettlauf um Bandbreite, den ein globales Netzwerk gewinnt. Die ehrliche Einordnung: Ein Frontknoten ist die richtige Antwort, um ein schweres oder teures Backend zu verbergen — ein Storage-Array, eine GPU-Maschine, einen Mailserver, eine Datenbank — und um Jurisdiktionen zu trennen. Er ist kein Ersatz für ein CDN unter anhaltendem Druck auf Schicht 7.
Die Wahl, in einer Tabelle
| Ihre Situation | Konstruktion | Begründung |
|---|---|---|
| Publishing, das Takedown-Anfragen anzieht | Direkt, ohne CDN, in einer bewusst gewählten Jurisdiktion | Ein CDN fügt eine Beschwerdestelle hinzu, die Ihr Host absichtlich nicht hat |
| Shop oder SaaS mit echten Nutzern und Druck auf Schicht 7 | CDN davor, Ursprung auf dessen Bereiche beschränkt | Schicht 7 ist das Problem, für das ein CDN eigentlich gebaut ist |
| Umgehungs-Endpunkt in einem zensierten Land | CDN-Fronting | Der Zensor sieht eine Adresse, die er sich nicht leisten kann zu blockieren |
| Großer statischer Traffic oder Medien-Traffic | CDN zur Cache-Entlastung | Bandbreite und Latenz sind der Zweck; Verschleierung ist ein Nebeneffekt |
| Anonymität ist die Hauptanforderung | Eigener Frontknoten oder nichts davor | Ein Konto bei einem Drittanbieter ist eine Identitätsspur, die es vorher nicht gab |
| Schweres Backend, das sich zu verbergen lohnt | Frontknoten plus rein ausgehender Tunnel | Die teure Maschine taucht nie im öffentlichen Internet auf |
Das Konto ist meist das schwächste Glied
Bedenken Sie, was passiert, wenn die Infrastruktur perfekt ist und der Papierkram nicht. Der Server wurde in Monero bezahlt, ohne Ausweisdokumente und ohne E-Mail-Adresse — die Konstruktion, die unsere Seiten zu No-KYC-Hosting beschreiben. Dann wird ein CDN-Konto mit Karte, persönlicher Adresse und Telefonnummer eröffnet, das die geschützte Domain aufführt. Dieses Konto ist eine stärkere, dauerhaftere Identitätsspur als alles auf dem Server, verwahrt von einem Unternehmen, das auf gerichtliche Anordnungen reagiert, und es macht die Zahlungsprivatsphäre vollständig zunichte.
Die Lösung ist nicht kompliziert, nur leicht zu vergessen: Wenn Anonymität das Ziel ist, gehört entweder die Front Ihnen, oder das Konto davor ist so wegwerfbar und so wenig zuordenbar wie der Server dahinter. Server-OpSec behandelt diese Disziplin ausführlich, und unsere ehrliche Antwort zur Offshore-Anonymität spricht unumwunden aus, welche Glieder der Kette meist zuerst brechen. Es sind fast nie die technischen.
Die eigene Exponierung in zehn Minuten prüfen
Jeder Punkt unten ist etwas, das eine interessierte Partei in den ersten Minuten prüfen würde. Führen Sie diese Prüfungen selbst durch, von einer Maschine, die nicht der Server ist, bevor Sie die Antworten brauchen.
- Listen Sie jeden Hostnamen auf, für den je ein Zertifikat ausgestellt wurde. Suchen Sie Ihre Stammdomain in einer Certificate-Transparency-Suchmaschine und lösen Sie jedes Ergebnis auf. Alles, was nicht auf die Front zeigt, ist ein Leck — auch Hosts, die Sie nicht mehr nutzen.
- Lesen Sie Ihre eigene DNS-Historie. Eine Passiv-DNS-Abfrage zeigt die Adressen, zu denen Ihre Domain vor dem CDN aufgelöst hat. Ist der Ursprung von gestern noch der Ursprung von heute, war die Verschleierung nie real.
- Fragen Sie den Ursprung direkt.
curl -sI --resolve example.com:443:198.51.100.10 https://example.com/— antwortet die Seite, schränkt Ihre Firewall die Front nicht ein, und jeder mit einer Kandidatenadresse kann das mit einer einzigen Anfrage bestätigen. - Fragen Sie unhöflich nach.
curl -skI https://198.51.100.10/sollte nichts Wiedererkennbares liefern. Ein Standard-Virtual-Host, der Ihre Startseite ausliefert, ist der mit Abstand häufigste Einzelfehler auf dieser Seite. - Prüfen Sie jeden Eintragstyp, nicht nur A.
dig +short AAAA example.com,dig +short MX example.com, und dasselbe für jede Subdomain, die die Transparency-Logs offenbart haben. Unproxiertes IPv6 ist ein Klassiker. - Schreiben Sie sich selbst aus der Anwendung. Lösen Sie ein Passwort-Reset aus und lesen Sie die vollständige
Received-Kette. Steht die Ursprungsadresse dort, steht sie auch in jeder Nachricht, die Sie je verschickt haben. - Bestätigen Sie, dass die Ports geschlossen sind. Von einem fremden Netzwerk aus sollte
nmap -Pn -p80,443 198.51.100.10gefiltert anzeigen, nicht offen. - Durchsuchen Sie die Scanner. Suchen Sie Ihren Zertifikats-Fingerabdruck und den Favicon-Hash Ihrer Startseite in einem öffentlichen Internet-Scan-Index. Ist Ihr Ursprung indexiert, wird er auf diesem Weg gefunden.
Wenn die Adresse bereits verbrannt ist
Gehen Sie davon aus, dass sie verbrannt bleibt. Eine Adresse, die einmal in Passiv-DNS und in Scan-Indizes aufgetaucht ist, steht dauerhaft im öffentlichen Verzeichnis, und keine Konfigurationsänderung zieht das zurück. Die Reaktion darauf ist mechanisch, nicht raffiniert.
- Erst das Leck schließen. Auf eine neue Adresse zu rotieren, ohne das Loch zu stopfen, reproduziert die Lage binnen Tagen, und Sie haben eine Migration investiert, um nichts zu lernen.
- Dann rotieren. Bringen Sie einen Ersatz live — in einer anderen Jurisdiktion, falls der Grund rechtlicher statt technischer Natur war —, stellen Sie wieder her und schalten Sie um. Weil dem ersten Server keine Identität angehängt war, ist das ein Neuanfang statt einer Verhandlung — der praktische, wenig glamouröse Lohn dafür, Server ohne Kontohistorie zu kaufen.
- Die Umschaltung vor dem Notfall vorbereiten. Eine kurze DNS-TTL, Konfiguration, die Sie aus einem Repository neu ausrollen können, und eine getestete Wiederherstellung machen aus einem schlechten Nachmittag zwanzig Minuten. Niemand richtet das erst während eines Angriffs ein.
- Die alte Adresse sauber ausmustern. Parken Sie den alten Server nicht auf der alten Adresse mit denselben Inhalten; das ist eine Live-Bestätigung für jeden, der zusieht, und hält den Eintrag frisch.
Die Kurzfassung
Netzwerkfilterung deckt volumetrische Angriffe ab, ist im Server inbegriffen und kostet nichts extra. Ein CDN deckt die Anwendungsschicht ab und verbirgt den Ursprung, zum Preis eines Mittelsmanns, der Ihr TLS terminiert, Beschwerden beantwortet und weiß, wer Sie sind. Ein eigener Frontknoten kauft Verschleierung ohne diesen Mittelsmann, aber ohne globale Kapazität. Die Jurisdiktion entscheidet die rechtliche Frage, und keine der drei Optionen rührt daran. Und alle drei werden durch einen einzigen ungeproxten Eintrag, eine einzige E-Mail vom Ursprung oder einen einzigen Standard-Virtual-Host zunichtegemacht.
Entscheiden Sie nach Ziel statt nach Gewohnheit, und investieren Sie dann die zehn Minuten in den Audit — er findet mehr echte Exponierung als jedes Upgrade. Wenn Sie die Architektur ohne den Dritten wollen: ein kleiner VPS als Front und die eigentliche Arbeit auf dedizierter Hardware dahinter ist die Konstruktion, die wir am häufigsten bei Leuten sehen, die schon einmal gefunden wurden.