.onion-Seite hosten: Onion-Dienste, v3-Adressen und die Leaks, die sie verraten

Was ein Onion-Dienst wirklich ist

Ein Onion-Dienst ist ein Server, der niemandem verrät, wo er steht. Statt eine Adresse im DNS zu veröffentlichen und auf Verbindungen zu warten, baut er ausgehende Circuits durch das Tor-Netzwerk zu einer Handvoll Relays auf, die er als Einführungspunkte auswählt, und veröffentlicht einen signierten Deskriptor mit der Aussage: „Wer diesen Schlüssel besitzt, ist über diese Relays erreichbar.“ Ein Client, der die Adresse kennt, ruft diesen Deskriptor ab, wählt ein drittes Relay als Rendezvous-Punkt und bittet einen Einführungspunkt, eine Treffanfrage dorthin weiterzuleiten. Beide Seiten bauen ihren eigenen Circuit zum Rendezvous-Punkt auf, und keine Seite erfährt jemals die IP-Adresse der anderen, weil sie ihr nie mitgeteilt wird.

Die Adresse selbst ist der eigentlich interessante Teil. Eine v3-Onion-Adresse besteht aus 56 Zeichen base32, gefolgt von .onion, und sie ist kein Name, der auf einen Schlüssel verweist — sie ist der Schlüssel: ein ed25519-Public-Key, eine Prüfsumme und ein Versionsbyte, codiert. Es gibt nichts nachzuschlagen und nichts zu vertrauen. Wenn Ihr Client sich verbindet, ist der abgerufene Deskriptor mit genau diesem Schlüssel signiert, sodass die Adresse den Dienst allein durch ihre Konstruktion authentifiziert. Keine Zertifizierungsstelle ist beteiligt, niemand kann ein Zertifikat für Ihre Adresse ausstellen, und es gibt kein Transparency-Log, das die Existenz des Dienstes festhält. Die Rendezvous-Spezifikation lohnt die Lektüre, wenn Sie den vollständigen Handshake nachvollziehen möchten.

Diese Liste ist das gesamte Wertversprechen, und sie erklärt, wer solche Dienste tatsächlich betreibt. SecureDrop-Instanzen bei Redaktionen sind Onion-Dienste, weil eine Quelle DNS nicht vertrauen können muss. Debian spiegelt sein Archiv über Onion-Dienste, damit das Aktualisieren eines Pakets nicht als sichtbares Ziel erkennbar ist. Mehrere sehr große Verbraucherplattformen veröffentlichen ebenfalls einen, damit Menschen in zensierten Netzen sie erreichen können, ohne dass eine gesperrte IP-Adresse dazwischensteht. Nichts davon ist exotisch; es ist ein Transportweg mit anderen Garantien.

Was er schützt — und was er nicht kann

Die Garantie des Protokolls ist eng gefasst und trotzdem stark: Die Netzwerkschicht verrät nicht, wo der Dienst läuft. Ein Angreifer, der große Teile des Internets beobachten kann, kann Ihre Adresse trotzdem keiner Maschine zuordnen, weil es gar keinen Auflösungsschritt gibt, den er beobachten könnte. Einem Hosting-Anbieter kann man die Adresse nicht vorlegen und fragen, welchem Kunden sie gehört, weil auf Anbieterseite niemand es weiß. Scanner finden den Dienst nicht, weil er auf keinem öffentlichen Port antwortet. Und ein Angriff, der eine gewöhnliche Website vom Netz fluten würde, hat kein Ziel, auf das er zielen könnte — deshalb taucht dieses Muster in DDoS-Diskussionen genauso oft auf wie in Datenschutzdiskussionen.

Alles oberhalb der Netzwerkschicht können Sie immer noch falsch machen, und genau dort spielt sich die tatsächliche Fallgeschichte ab. Dienste wurden lokalisiert, weil die Anwendung einen Stacktrace mit einem echten Hostnamen ausgab, weil derselbe Webserver auf der öffentlichen IP eine identische Seite auslieferte, weil ein Zertifikat für die andere Domain des Betreibers auf derselben Maschine installiert war, weil ein Bild GPS-Koordinaten in seinen Metadaten trug, weil die Maschine Mail verschickte, die das offene Internet durchquerte, oder weil ein offen erreichbarer Status-Endpunkt die eigene Adresse des Servers preisgab. Tor hat in jedem dieser Fälle seine Aufgabe erfüllt. Die Person darüber nicht.

Halten Sie also zwei Gedanken gleichzeitig fest. Der Transportweg ist solide und ist es seit Jahren; ihn als das schwache Glied zu behandeln, ist eine Fehllesart dessen, wie diese Ermittlungen tatsächlich verlaufen sind. Und der Transportweg ist zugleich die leichte Hälfte — die schwere Hälfte ist die Disziplin darüber, was die Maschine alles sagt und tut, wovon der Rest dieses Leitfadens größtenteils handelt. Wenn Sie eigentlich die breitere Frage umtreibt, wie rückverfolgbar ein gemieteter Server ist, ist die ehrliche Antwort darauf eine gute Ergänzung zu dieser Seite.

Onion-Dienst einrichten: zwei Direktiven und ein Neustart

Die Konfiguration ist wirklich klein, was alle überrascht, die etwas Feierliches erwarten. Installieren Sie den tor-Daemon und fügen Sie dann zwei Direktiven in torrc ein: ein HiddenServiceDir, das ein Verzeichnis benennt, das Tor anlegt und besitzt, und einen HiddenServicePort, der den virtuellen Port, den Aufrufer benutzen, auf die lokale Adresse abbildet, auf der Ihre Anwendung lauscht. Nach einem Neustart erzeugt Tor ein ed25519-Schlüsselpaar und schreibt Ihre Adresse in eine hostname-Datei innerhalb dieses Verzeichnisses.

Der mit Abstand häufigste Fehler steckt in der dritten Zeile. Eine Standardinstallation eines Webservers lauscht auf 0.0.0.0, was die öffentliche IPv4-Adresse und meist auch die IPv6-Adresse bedeutet. Setzen Sie einen Onion-Dienst davor, liefern Sie plötzlich dieselben Bytes an zwei Stellen aus, von denen eine von jedem Scanner im Internet erfasst wird. Wer einen Seiten-Hash, ein Favicon, einen ETag oder eine unverwechselbare Fehlerseite vergleicht, verknüpft beide in Sekunden. Binden Sie an 127.0.0.1 und bestätigen Sie das mit ss -ltnp, statt es nur anzunehmen — die Bestätigung dauert fünf Sekunden, und die Annahme hat schon Menschen alles gekostet.

Sichern Sie hs_ed25519_secret_key verschlüsselt und außerhalb der Maschine, bevor Sie weitermachen. Diese Datei ist nicht der Adresse zugeordnet — sie ist die Adresse. Verlieren Sie sie, ist die Adresse unwiederbringlich weg, ohne Wiederherstellung und ohne Einspruch. Leaken Sie sie, kann jemand anderes einen Dienst aufsetzen, der für Ihre Adresse antwortet und kryptografisch nicht von Ihnen zu unterscheiden ist. Behandeln Sie sie wie einen Signaturschlüssel, denn genau das ist sie — und wenn die Festplatte, auf der sie liegt, gemietet ist, ist deren Verschlüsselung der naheliegende nächste Schritt, mit den Einschränkungen, die jener Leitfaden beschreibt.

Schließen Sie danach die Haustür. Ein Onion-Dienst braucht überhaupt keinen eingehenden Port — jede Verbindung, die er nutzt, hat er selbst ausgehend ins Tor-Netzwerk aufgebaut. Sie können an der Firewall sämtlichen eingehenden Verkehr verwerfen, und der Dienst funktioniert weiterhin einwandfrei. Fast nichts anderes, was Sie hosten können, bietet das, und es entfernt die gesamte Kategorie von Angriffen, die mit einem Portscan beginnen. Erreichen Sie auch Ihren eigenen Verwaltungszugang über Tor, und die Maschine beantwortet das Internet schlicht gar nicht mehr.

v3-Adressen, Vanity-Präfixe und das Phishing-Problem, das sie schaffen

Wenn ein Tutorial, das Sie gerade lesen, von 16-stelligen Adressen spricht, beschreibt es ein Protokoll, das es nicht mehr gibt. Onion-Dienste der Version 2 nutzten 80-Bit-RSA-1024-Hashes, die kurz genug waren, um attraktiv zu sein, und schwach genug, um ein Problem zu sein; sie waren zudem enumerierbar, weil jeder, der ein Directory-Relay betrieb, die durchlaufenden Adressen sammeln konnte. Das Tor Project kündigte 2020 den Abschaltfahrplan an, deaktivierte v2 im Juli 2021 in der 0.4.6-Serie und entfernte den Code im Oktober desselben Jahres vollständig. Adressen der Version 3 sind 56 Zeichen lang, basieren auf ed25519 und lecken nicht mehr über Directory-Relays.

Die Länge ist der Preis dafür, und deshalb gibt es Vanity-Adressen. Werkzeuge wie mkp224o erzeugen massenhaft Schlüsselpaare und behalten diejenigen, deren Adresse mit einem gewählten Präfix beginnt. Das schwächt nichts: Sie schränken den Schlüssel nicht ein, Sie verwerfen Kandidaten, bis zufällig einer die gewünschten Buchstaben codiert, und der Überlebende ist genauso stark wie jeder andere. Was es kostet, ist Zeit, und die Kosten wachsen exponentiell — jedes zusätzliche Zeichen vervielfacht den Aufwand um den Faktor 32. Ein vierstelliges Präfix ist auf einem Laptop sofort da, sechs oder sieben Zeichen bedeuten Stunden Rechenzeit, und zehn werden zu einem ernsthaften Unterfangen. Eine vollständige 56-stellige Adresse per Brute-Force zu knacken, versucht niemand — genau darin liegt der Sinn des Suchraums.

Die eigentliche Gefahr ist das Spiegelbild dieser Eigenschaft. Wenn ein erkennbares Präfix Ihren Nutzern hilft, Sie zu identifizieren, hilft es ebenso gut jemand anderem dabei, eine Beinahe-Kopie zu erzeugen und auf eine Phishing-Seite zu stellen — denn die acht Zeichen, die ein Mensch tatsächlich liest, sind alles, was geprüft wird. Verteidigen Sie das so, wie Schlüssel-Fingerabdrücke schon immer verteidigt wurden: Veröffentlichen Sie die vollständige Adresse an mehreren unabhängigen Stellen, signieren Sie sie mit einem Schlüssel, den Ihre Nutzer bereits besitzen, tragen Sie sie in den Onion-Location-Header Ihrer Clearnet-Site ein, falls Sie eine haben, und sagen Sie klar, dass Sie eine neue Adresse niemals ausschließlich über soziale Netzwerke ankündigen werden. Ein Vanity-Präfix ist ein Usability-Feature, kein Authentifizierungsmerkmal.

Die Angriffsfläche, die Dienste in der Praxis enttarnt hat

Das ist der Abschnitt, auf den es ankommt. Das Muster ist in jedem öffentlich dokumentierten Fall dasselbe: Die Netzwerkschicht hat gehalten, und etwas oberhalb davon hat auf eine bestimmte Maschine, eine bestimmte Person oder eine bestimmte andere Website verwiesen. Die meisten dieser Fälle sind unspektakulär, alle lassen sich an einem Nachmittag überprüfen, und genau diese Überprüfung ist die eigentliche Arbeit.

Zwei davon verdienen besondere Aufmerksamkeit, weil sie auch vorsichtige Leute erwischen. Der erste ist ausgehender Verkehr: Eine Maschine, die niemals eine Verbindung annimmt, kann sich trotzdem verraten, indem sie selbst eine aufbaut. Paket-Updates sind unbedenklich und unvermeidlich; ein Monitoring-Agent, der an ein Dashboard mit Ihrem Namen berichtet, ist es nicht — genauso wenig eine Anwendung, die Passwort-Reset-Mails übers offene Internet verschickt, von einer Maschine, deren einziger Zweck es ist, nicht auffindbar zu sein. Der zweite Punkt ist der SSH-Host-Key. Ihn über mehrere Maschinen hinweg wiederzuverwenden, fühlt sich ordentlich an, schafft aber eine dauerhafte, durchsuchbare, kryptografische Verbindung zwischen zwei Servern, die eigentlich nichts miteinander zu tun haben sollten.

Führen Sie den Audit als Außenstehender durch, nicht als Betreiber. Öffnen Sie den Dienst im Tor Browser auf einer Maschine, die mit dem Projekt noch nie in Berührung gekommen ist, lesen Sie jeden Antwort-Header, provozieren Sie absichtlich einen Fehler, sehen Sie sich den Quelltext einer Seite an, die Sie nicht selbst geschrieben haben, und beobachten Sie im Netzwerk-Panel, was die Seite noch von anderswo nachlädt. Setzen Sie sich anschließend an den Server und beobachten Sie einen vollen Tag lang, was ihn verlässt. Was Sie an diesem Tag finden, ist der eigentliche Sinn dieses Leitfadens.

Client-Autorisierung: ein Dienst, den nur bestimmte Personen erreichen

Es gibt einen Modus, von dem die meisten Leute gar nicht wissen, dass er existiert, und er ist das eleganteste Feature im gesamten Protokoll. Mit der Client-Autorisierung wird der Deskriptor, den Ihr Dienst veröffentlicht, für eine von Ihnen festgelegte Menge an x25519-Public-Keys verschlüsselt. Ein Client ohne den passenden privaten Schlüssel kann den Deskriptor nicht einmal entschlüsseln, kann also die Einführungspunkte nicht in Erfahrung bringen, kann sich folglich nicht verbinden — und kann nicht einmal bestätigen, dass überhaupt etwas existiert. Sie legen die öffentlichen Client-Schlüssel in ein authorized_clients-Verzeichnis neben die Dienstschlüssel, eine Datei pro Client, und starten neu.

Vergleichen Sie das mit den üblichen Wegen, den Zugriff einzuschränken. Eine IP-Allowlist setzt voraus, dass Sie wissen, wo sich Ihre Nutzer befinden, und lässt den Dienst für alle anderen weiterhin im Internet antworten — zum Scannen und Fingerprinting freigegeben. HTTP-Basic-Auth lässt ein Login-Fenster stehen, das genau damit verrät, dass etwas existiert. Ein VPN bringt ein komplett zweites System mit, das Sie betreiben müssen, mit einer eigenen Adresse, die wieder exponiert ist. Client-Autorisierung entfernt den Dienst vollständig aus dem Sichtfeld aller, die nicht auf der Liste stehen — eine kategorial andere Eigenschaft: keine verschlossene Tür, sondern das Fehlen einer Tür.

Die naheliegende Anwendung sind administrative Oberflächen. Betreiben Sie die öffentliche Site auf einem gewöhnlichen Onion-Dienst und legen Sie Admin-Panel, Metriken-Dashboard, Datenbankkonsole und SSH-Zugang hinter separate, autorisierte Dienste — und genau die Teile Ihres Deployments, die sonst ständig abgetastet würden, lassen sich schlicht nicht finden. Der Preis dafür ist die Schlüsselverteilung — jeder Client braucht seinen privaten Schlüssel in seiner Tor-Konfiguration —, was für eine Handvoll Betreiber unproblematisch, für ein öffentliches Publikum aber unpraktikabel ist. Setzen Sie es dort ein, wo sich die Zielgruppe abzählen lässt.

Latenz, Redundanz und die ehrlichen Kompromisse

Eine Onion-Verbindung durchquert sechs Relays: drei, die der Client gewählt hat, und drei, die der Dienst gewählt hat, die sich in der Mitte treffen. Das ist der Preis dafür, dass keine Seite die andere kennt, und er zeigt sich als Latenz, nicht als Bandbreite — das erste Byte kommt langsam, der Durchsatz danach ist meist in Ordnung. Konstruieren Sie darauf hin: weniger Roundtrips, aggressives Caching, keine geschwätzigen Request-Ketten, keine Seite, die elf Subressourcen braucht, bevor sie rendert. Eine Site, die sich über einen Onion-Dienst angenehm anfühlt, war meist schon vorher gut gebaut.

Wenn Ihr Dienst selbst gar keine Standort-Anonymität braucht — etwa eine große öffentliche Plattform, die eine Onion-Adresse rein deshalb veröffentlicht, damit zensierte Nutzer sie erreichen können —, bietet Tor einen Single-Onion-Service-Modus, der auf Dienstseite nur einen einzigen Hop nutzt. Das halbiert die Latenz ungefähr und gibt dabei ausdrücklich die eigene Anonymität des Dienstes auf — der Name der Konfigurationsdirektive sagt das wörtlich. Für eine bekannte Organisation ist das die richtige Antwort, und für jeden, dessen Standort gerade das zu schützende Gut ist, genau die falsche. Wählen Sie diesen Modus bewusst oder gar nicht.

Redundanz verdient eine Anmerkung, weil der naive Ansatz scheitert. Sie können das Schlüsselmaterial nicht einfach auf eine zweite Maschine kopieren und beide gleichzeitig betreiben — zwei Dienste, die Deskriptoren für dieselbe Adresse veröffentlichen, konkurrieren im Directory, und Clients landen unvorhersehbar mal hier, mal dort. Genau dafür gibt es OnionBalance: Eine Frontend-Instanz hält die öffentliche Adresse und veröffentlicht einen Deskriptor, der auf die Einführungspunkte mehrerer Backend-Dienste verweist, jeder mit eigenem Schlüssel. Backends lassen sich einzeln neu aufsetzen oder verschieben, ohne dass sich die Adresse jemals ändert.

Einen Onion-Dienst neben einer gewöhnlichen Website betreiben

Viele Onion-Dienste sind zweite Eingangstüren zu etwas, das öffentlich bereits existiert, und das ist ein anderes Projekt als ein Dienst, dessen Standort geheim bleiben soll. Entscheiden Sie, welches der beiden Sie bauen, bevor Sie auch nur eine Zeile Konfiguration schreiben, denn beide wollen das genaue Gegenteil. Geht es um Zensurresistenz für eine Site, von der ohnehin jeder weiß, dass Sie sie betreiben, ist die Verknüpfung beider das eigentliche Feature: Veröffentlichen Sie einen Onion-Location-Header auf der Clearnet-Site, und der Tor Browser bietet Besuchern die Onion-Adresse automatisch an. Geht es darum, dass niemand weiß, wo der Dienst läuft, dann ist jede Verknüpfung zwischen beiden ein Leak, und die richtige Anzahl davon ist null.

Die halbe Lösung ist es, die den Leuten schadet. Beide von einer Maschine aus zu betreiben, mit einer Datenbank, einer Session-Cookie-Domain und einem gemeinsamen Satz hochgeladener Dateien, während man sich selbst einredet, die beiden Zielgruppen seien getrennt, bedeutet: Eine einzige Fehlkonfiguration lässt die Trennung kollabieren — und Sie erfahren es erst, wenn es jemand anderes zuerst herausfindet. Müssen beide existieren und dürfen dabei nicht verknüpft sein, dann sind es zwei Deployments auf zwei Maschinen mit zwei getrennten Zugangsdaten, und die operativen Kosten dafür sind der Preis für die gewünschte Eigenschaft.

Ein praktisches Detail, falls Sie beide doch verknüpfen: Halten Sie Sessions und Cookies pro Host getrennt. Ein Nutzer, der sich auf der Clearnet-Site anmeldet und dann über die Onion-Adresse ankommt, sollte eine neue Session bekommen, keine geteilte — sonst haben Sie einen Mechanismus gebaut, der beide Besuche für jeden korreliert, der auch nur einen der beiden sehen kann. Und geben Sie der Onion-Adresse ihre eigenen kanonischen Links, damit die Site einen Tor-Browser-Nutzer nicht hilfsbereit zurück auf den Clearnet-Host schickt, den er absichtlich vermieden hat.

Was das Hosting tatsächlich richtig machen muss

Die Anforderungen sind ungewöhnlich, weshalb ein generischer Hoster oft schlecht passt. Sie brauchen einen ungehinderten ausgehenden Weg ins Tor-Netzwerk, denn das ist die einzige Art von Verbindung, die Ihr Dienst aufbaut; manche Anbieter filtern Tor-Directory- und Relay-Verkehr rundheraus, und Sie merken das erst daran, dass der Dienst nie einen Deskriptor veröffentlicht. Sie brauchen einen Anbieter, dessen Nutzungsbedingungen Tor schriftlich adressieren statt es mit Schweigen zu übergehen, denn Schweigen wird zur Kündigungs-Mail, sobald sich jemand über etwas völlig anderes beschwert. Sie brauchen keine feste IP, keine Domain, kein Zertifikat und keinen einzigen eingehenden Port — womit das meiste, was Hosting-Unternehmen als Unterscheidungsmerkmal verkaufen, hier irrelevant wird.

Das Missbrauchsprofil ist die angenehme Überraschung. Ein Exit-Node baut im Auftrag Fremder Verbindungen ins offene Internet auf und sammelt deshalb Beschwerden ein; das ist der Deal, und deshalb brauchen Exits einen Anbieter mit einer dokumentierten Haltung dazu. Ein Onion-Dienst macht das Gegenteil: Jede Verbindung kommt aus dem Tor-Netzwerk herein, er kontaktiert im Auftrag niemandes das offene Internet, und folglich erzeugt er praktisch keine Abuse-Mails. Er ist eine ruhigere Workload zum Hosten als das Relay nebenan — und deutlich ruhiger als ein öffentlicher Webserver.

Bei BitVPS ist Tor schriftlich erlaubt — Relays, Bridges, Exits und Onion-Dienste gleichermaßen, wobei der Exit-Fall auf der Abuse-Seite dokumentiert ist statt dem Zufall überlassen. Die Tor-Hosting-Seite behandelt die Dimensionierung von Relays; Onion-Dienste sind leichtgewichtiger. In der Praxis stemmt ein Growth für $13.50 mit 4 vCPU, 8 GB RAM und ungemessenem Uplink einen ernsthaften Onion-Dienst mit Raum für die Anwendung dahinter, und ein Starter für $8.50 reicht für einen kleinen. Wählen Sie den Standort nach seiner Rechtslage statt nach seiner Latenz: Sechs Hops machen den Unterschied zwischen einem nahen und einem entfernten Rechenzentrum fast unsichtbar.

Die Netzwerk-Seite veröffentlicht die ASN und das Peering, was hier aus einem indirekten Grund wichtig ist. Sie exponieren keine Adresse, also entfällt der übliche Grund, sich um das Netzwerk eines Anbieters zu kümmern — aber ein Hoster, der seine Infrastruktur öffentlich dokumentiert, ist auch ein Hoster, der schriftlich festgehalten hat, was er tut, wenn jemand nach einem Kunden fragt, und genau das kaufen Sie hier eigentlich.

Wo die Grenze verläuft

Hier lohnt sich Klartext, denn die Technologie trägt einen Ruf, der zum tatsächlichen Verkehr nicht passt. Onion-Dienste sind ein Transportweg mit einer bestimmten Datenschutzeigenschaft, und die Menschen, die sie betreiben, sind überwiegend ganz gewöhnlich: Redaktionen, die Hinweise entgegennehmen, ein Paketarchiv, das nicht protokollieren will, welche Maschine welches Update abgerufen hat, Messaging- und Self-Hosting-Projekte, Menschen in Ländern, in denen das gewöhnliche Internet gefiltert wird, und Administratoren, die es schlicht vorziehen, dass ihre Verwaltungsoberfläche nicht scanbar ist. Einen zu betreiben ist in der überwältigenden Mehrheit der Rechtsordnungen legal, und es ist keine Aussage darüber, was Sie hosten.

Was es nicht ist: eine Änderung der Regeln. Ein Anbieter, der Urheberrechtshinweise ignoriert — und das tun wir, wie jener Leitfaden erklärt — handelt trotzdem bei Material sexuellen Missbrauchs von Kindern und bei glaubhaften Drohungen gegen Menschen, und zwar schnell: Unser veröffentlichtes Zeitfenster dafür sind vier Stunden, gegenüber achtundvierzig für alles Übrige. Das ist kein Schlupfloch in einer sonst freizügigen Richtlinie, das ist die Richtlinie, und kein Transportweg ändert daran etwas. Die Nutzungsbedingungen sind kurz und es lohnt sich, sie vor dem Aufbau zu lesen, nicht danach.

Die andere ehrliche Anmerkung: Anonymität ist eine Eigenschaft des Gesamtsystems, kein Produkt, das man kaufen kann. Die Adresse verbirgt die Maschine; sie verbirgt keine Zahlungsspur, kein wiederverwendetes Passwort, keinen Schreibstil, keine Domain, die Sie vor Jahren mit derselben E-Mail-Adresse registriert haben, und keinen Screenshot mit Ihren eigenen Dateisystempfaden darin. Ist das Bedrohungsmodell ernst, ist der Transportweg der einfachste Teil davon und der, mit dem Sie am wenigsten Zeit verbringen werden. Der umfassendere Leitfaden deckt den Rest dieser Kette ab, und die Erklärung zu Bulletproof-Hosting ist ein nützliches Gegenmittel zum Marketing, das dieses ganze Thema umgibt.