Pseudo-Knoten und mutmaßliche Angriffsvektoren im Netzwerk

Pseudo-Node wird hier auf Reddits /r/Bitcoin diskutiert

Im Wesentlichen funktioniert es, um Anrufe von verbundenen Knoten auf zufällige Weise weiterzuleiten.

Dies war ein Experiment, wie einfach vollständige Knoten "gefälscht" werden können. Fazit: ganz einfach.

Eine Proof-of-Concept-Implementierung (& Dokumentation) ist hier verfügbar:

https://github.com/basil00/PseudoNode

Für das Netzwerk erscheint PseudoNode wie ein normaler vollständiger Knoten. Es leitet Invs, TXs, Blöcke usw. weiter, genau wie ein vollständiger Knoten. In Wirklichkeit ist PseudoNode eine Art P2P-Proxy-Server. Es leitet lediglich alle Anfragen weiter, die es nicht verarbeiten kann (getdata, getheaders usw.) an benachbarte Knoten. Weitere Informationen finden Sie unter den obigen Links.

PseudoNode verwendet keine Festplatte (kein Blockchain-Download erforderlich), verwendet wenig CPU/RAM und verbraucht weniger Netzwerkressourcen (Bandbreite) als ein normaler vollständiger Knoten. Ein PseudoNode kann sich innerhalb von Sekunden mit dem Netzwerk „synchronisieren“.

PseudoNode demonstriert einige der Probleme mit incentivierten Full Nodes (einschließlich des „Bitnodes Incentive Program“). Es ist schwierig zu beweisen, dass ein Full Node wirklich ein Full Node ist.

Die Implementierung hat meistens Neuheits-/Proof-of-Concept-Wert. Es ist nicht als „Produktions“-Software gedacht.

Und die FAQ :

Schadet PseudoNode dem Netzwerk?

Kurze Antwort: Nein.

Lange Antwort: Es sei denn, die Anzahl der PseudoNodes übersteigt die Anzahl der normalen Full Nodes deutlich. Andernfalls, wenn PseudoNode eine Verbindung zu mindestens einigen guten Knoten herstellen kann (Standard 2), verhält sich PseudoNode wie ein normaler Knoten und trägt zur Netzwerkbandbreite bei.

Kann PseudoNode dazu führen, dass sich das Netzwerk verzweigt?

Nein, PseudoNode folgt einfach dem, was andere Knoten tun.

Kann PseudoNode Münzen stehlen?

NEIN.

Können PseudoNodes aus dem Netzwerk verbannt werden?

Nicht einfach. Anfragen, die PseudoNode nicht direkt bearbeiten kann, können jederzeit an andere (kooperative) Full Nodes weitergeleitet werden.

Dies erscheint mir in Bezug auf Angriffsvektoren unglaublich rücksichtslos. Offensichtlich muss ein Gleichgewicht zwischen den Vor- und Nachteilen bewertet werden, und da sein Wert "Neuheit" ist (vom Entwickler selbst beschrieben), scheinen mehrere Nachteile sofort offensichtlich:

  1. Die Latenz erhöht effektiv die Blockchain-Download-Zeiten, so dassnew latency = original latency * performance decrease %
  2. Ein schändlicher Pseudoknoten könnte die Latenz auf knapp über die Schwelle der Knoten drosseln, die eine schwarze Liste erzwingen (dh throttled latency~> cutoff latency).
  3. Ein erhöhter Prozentsatz schändlicher Knoten könnte möglicherweise einen Sybil-Angriff ausführen (?)

2 verwandte Fragen:

  1. Welche anderen Angriffsvektoren (in groben Zügen) und ihre Auswirkungen sind von Pseudo-Knoten zu erwarten?
  2. Gibt es machbare Eventualitäten im Protokoll, um zwischen einem PN und einem Knoten abzugrenzen? Würden beispielsweise verschiedene Bitcoincore-Versionen PNs identifizieren (oder eine einfache Änderung des Protokolls)?
Wenn Sie nach Pseudo-Knoten fragen, fragen Sie nach dieser speziellen Software oder nach der allgemeinen Idee, den Bitcoin-Client zu modifizieren? Wenn Sie sagen, This seems incredibly reckless in terms of attack vectorsmeinen Sie damit, dass Pseudo-Knoten anfällig für Angriffe wären, die der Bitcoin-Client nicht ist, oder dass der Autor nicht an alle Angriffe gedacht hat, die durchgeführt werden könnten?
@NickODell Ich gestalte dies eher im Lichte des veröffentlichten Open-Source-Codes, der im Grunde die Entwicklungszeit zunichte macht, die normalerweise schändliche Parteien daran hindern würde, dies zu verfolgen. Ich sollte auch klarstellen, ob es in der Vergangenheit Fälle von Pseudoknoten gegeben hat? Oder ist das kein neues Thema?
@WizardOfOzzie Alle "Angriffe" 1..3 sind mit normalen vollständigen Knoten möglich.

Antworten (1)

Eine große Anzahl miteinander verbundener Pseudo-Knoten macht das Starten eines Bandbreiten-Erschöpfungsangriffs viel einfacher. Bitcoin Core validiert die meisten Informationen, bevor er sie weiterleitet, aber Pseudo-Knoten validieren nicht – wenn Sie also einige Pseudo-Knoten miteinander verbinden können, ist es wahrscheinlich einfach, sie dazu zu bringen, Tonnen von Bandbreite zu verschwenden, indem sie Junk-Daten aneinander weiterleiten und dann zu ihren Kollegen.

Wenn beispielsweise 101 Pseudo-Knoten (PNs) miteinander verbunden sind, können Sie PN1 ein gültig aussehendes invPaket senden , das eine einzelne gefälschte Transaktion ankündigt (etwa 61 Byte plus TCP-Paket-Overhead). Jeder PN gibt das invfür mindestens 6100 verschwendete Upload-Bytes weiter.

Aber diese PNs sind auch mit echten Knoten verbunden. Nehmen wir an, 500 echte Knoten, also beträgt die verschwendete PN-Upload-Bandbreite jetzt 36.600 Byte (plus TCP-Overhead) – alles, weil ein Angreifer eine einzelne 61-Byte-Datei erstellt hat inv. Schlimmer noch, die realen Knoten werden die Transaktion mit einem 61-Byte- getdataPaket anfordern , wodurch 30.500 Bytes Upload-Bandbreite der realen Knoten verschwendet werden.

Wenn der Angreifer einen ganzen Tag lang 1 MB gefälschte Daten pro Sekunde sendet, verwendet er 86 Gigabyte seiner eigenen Bandbreite, verschwendet aber 52 Terabyte an aggregierter PN-Upload-Bandbreite und möglicherweise 43 Terabyte an echter Knoten-Upload-Bandbreite.

(Je nachdem, wie die PNs geschrieben sind, verschwenden sie möglicherweise noch mehr Bandbreite, um das getdataPaket weiterzuleiten.)

Vergleichen Sie dies mit den Kosten für die Ausführung des Angriffs gegen einen einzelnen echten Knoten. Für jedes 61-Byte inv-Paket, das der Angreifer hochlädt, antwortet der echte Knoten mit dem Hochladen einer einzelnen 61-Byte- getdata. Ein Bandbreitenauslastungsangriff gegen einen echten Knoten erfordert also ungefähr 1:1 an verschwendeter Bandbreite. Der reale Knoten leitet die nicht weiter, invbis er die Transaktion, auf die er sich bezieht, empfängt und validiert, sodass kein anderer Knoten Bandbreite verschwendet.

Gibt es machbare Eventualitäten im Protokoll, um zwischen einem PN und einem Knoten abzugrenzen? Würden beispielsweise verschiedene Bitcoincore-Versionen PNs identifizieren (oder eine einfache Änderung des Protokolls)?

Das Protokoll hat bereits die Vorstellung eines DoS-Ban-Scores, bei dem jeder Bitcoin Core-Knoten jedem seiner Peers einen privaten Score für jedes schlechte Verhalten zuweist, das sie ausführen. Sobald der DoS-Ban-Score für einen bestimmten Peer einen Schwellenwert erreicht (standardmäßig 100), trennt der Knoten die Verbindung zum Peer und verweigert für eine gewisse Zeit (standardmäßig einen Tag) weitere Verbindungen von seiner IP-Adresse. Zu schlechtem Verhalten gehört das Senden ungültiger Transaktionen und Blöcke.

Da PNs keine Daten validieren, leiten sie gerne ungültige Daten weiter. Wenn sie üblich werden, könnte sich jemand, der PNs trauern möchte, einfach mit einem beliebigen beworbenen Knoten verbinden und ihm einen Haufen ungültiger Daten senden. Wenn es sich um einen echten Full Node handelte, wird er die Verbindung trennen (DoS-Verbot). Wenn es ein PN wäre, würde es diese Daten an echte Full Nodes weiterleiten, was dazu führen würde, dass die echten Full Nodes sie per DoS verbieten. Dies würde den PN nutzlos machen und es dem Griefer ermöglichen, zu erkennen, welche Knoten PNs sind – der Griefer könnte dann (eine nicht authentifizierbare) Datenbank mit PN-IP-Adressen veröffentlichen.

Diese Methode funktioniert am besten bei Langzeit-PNs. Um die Ausführung kurzfristiger Sybil-Angriffe von vielen leichten PNs aus zu erschweren, könnte etwas wie Greg Maxwells Proof of Storage verwendet werden, um den Verbrauch verteilter Ressourcen kostspielig zu machen.

Vielen Dank für die ausführliche Theorie; Ich habe meine Abfrage geändert, um festzustellen, was, wenn überhaupt, zwischen einem PN und einem Knoten abgegrenzt werden könnte (z. B. wo kompensiert das Protokoll diese Szenarien.
@WizardOfOzzie bearbeitet, um den zweiten Teil Ihrer Frage zu beantworten.
Fantastisch, das macht sehr viel Sinn. Gut zu wissen, dass dies kein großes Problem ist. Ich vergebe Ihnen ein Kopfgeld, das ich aufstelle, wenn ich kann
@DavidA.Harding Standardmäßig leitet ein PN keine Daten weiter, es sei denn, mindestens 2 andere zufällig ausgewählte Knoten geben ebenfalls dieselben Daten weiter. Es ist daher schwierig, einen PN dazu zu "tricksen", ungültige Daten weiterzuleiten.
@Basil das ist cool, obwohl ich nicht glaube, dass es grundlegend etwas ändert. Es bedeutet nur, dass sowohl der Angreifer als auch der oben beschriebene Griefer eine einzige zusätzliche IP-Adresse benötigen und der Angreifer sich auch mit mehreren PNs verbinden muss.
Ich hätte auch erwähnen sollen, dass PN eingehenden Verbindungen nicht vertraut. Es zählt also nur Invs, die von ausgehenden Peers gesehen werden. Ansonsten wäre es einfach, PN so auszutricksen, wie Sie es beschreiben.
@Basil Heh. Gute Idee! Das macht Angriffe mit PNs sicherlich weniger trivial. invIch schätze, es ist immer noch einfach, einen PN zu erkennen, indem man einem Knoten fehlerhafte Daten sendet, wie z tx.
Pseudo-Knoten und mutmaßliche Angriffsvektoren im Netzwerk
AntwortenHierDatenschutz-Bestimmungen1y, 0v