Eclipse-Angriff: Isolation, Erkennung und Knotenschutz

Erfahren Sie, wie ein Eclipse-Angriff einen Blockchain-Knoten isoliert, warum gültige Daten dennoch ein falsches Netzwerkbild erzeugen können und wie Peer-Vielfalt und unabhängige Prüfungen das Risiko senken.

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Ein Eclipse-Angriff isoliert einen Zielknoten von ehrlichen Peers, indem der Angreifer alle oder genügend seiner Netzwerkverbindungen kontrolliert. Anschließend kann er Blöcke und Transaktionen verzögern, unterdrücken oder selektiv weiterleiten, sodass das Opfer ein vom Angreifer geprägtes Bild des Netzwerks sieht.

Das Opfer kann weiterhin Signaturen, Arbeitsnachweise und alle anderen Konsensregeln prüfen. Dadurch wird sein Netzwerkbild jedoch weder vollständig noch aktuell. Ein vollständig validierender Knoten kann ungültige Daten zurückweisen und dennoch auf einem gültigen, aber veralteten Zweig festgehalten werden, eine widersprüchliche Transaktion nicht zu sehen bekommen oder darüber getäuscht werden, was das übrige Netzwerk akzeptiert hat.

Dies unterscheidet sich von einem netzwerkweiten Mehrheitsangriff. Der Angreifer zielt auf der Peer-to-Peer-Ebene auf einen einzelnen Knoten oder eine begrenzte Gruppe von Knoten und muss nicht den Großteil der Mining-Leistung oder des Einsatzes im Netzwerk kontrollieren. Ein Sybil-Angriff kann einen Eclipse-Angriff unterstützen, indem er viele vom Angreifer kontrollierte Identitäten oder Adressen bereitstellt. Die Begriffe sind jedoch nicht gleichbedeutend: Sybil bezeichnet die Vervielfachung von Identitäten, Eclipse die erfolgreiche Isolation des Informationsbilds eines Opfers.

So funktioniert die Isolation

Peer-to-Peer-Clients entdecken mögliche Adressen, speichern sie, wählen ausgehende Peers aus, akzeptieren bestimmte eingehende Peers und verbinden sich nach Ausfällen oder Neustarts erneut. Die genauen Algorithmen unterscheiden sich je nach Client und Version. Ein Angreifer sucht nach einer Möglichkeit, genügend dieser Entscheidungen zugunsten der von ihm kontrollierten Infrastruktur zu beeinflussen.

Ein typischer Angriffsweg umfasst 4 Phasen:

Vom Angreifer kontrollierte Peers vorbereiten. Der Angreifer betreibt erreichbare Knoten oder Identitäten unter Adressen, die nach den Peer-Auswahlregeln des Opfers wahrscheinlich als voneinander getrennt gelten.
Die Kandidatenauswahl beeinflussen. Bösartige Peers verbreiten vom Angreifer kontrollierte Adressen oder versuchen auf andere Weise, ehrliche Einträge aus der Adressverwaltung des Opfers zu verdrängen. Die praktische Durchführbarkeit hängt von der Struktur der Adressgruppen, den Netzwerkgruppenregeln, den Ratenbegrenzungen und der Qualität der bereits gespeicherten Adressen ab.
Eine Neuverbindung auslösen oder abwarten. Ein Neustart, häufige Verbindungswechsel, ein Denial-of-Service-Angriff oder eine Routingstörung kann dazu führen, dass das Ziel ehrliche Peers ersetzt. Die Isolation ist leichter, wenn das Ziel nur wenige unabhängige Wege hat oder mit einer schwachen Adressdatenbank beginnt.
Monopolisieren und filtern. Sobald die relevanten Verbindungen des Opfers zum Angreifer führen, leitet dieser nur die ausgewählten Blöcke und Transaktionen weiter. Dabei hält er sich oft an die Konsensregeln, um eine sofortige Zurückweisung zu vermeiden.

Die USENIX-Studie von 2015 wies diese Angriffsklasse an der damaligen Peer-to-Peer-Implementierung von Bitcoin nach und beschrieb Folgen wie bestätigungsbasierte Doppelausgaben, die Unterstützung eigennützigen Minings und gegnerische Abspaltungen. Die konkreten Ressourcenschätzungen und Client-Details der Studie sind historisch und keine allgemeingültigen Konstanten für aktuelle Versionen von Bitcoin Core oder andere Netzwerke.

Moderne Clients können die Kosten einer Isolation durch zufällige und segmentierte Adressspeicherung, vielfältige Peer-Quellen, Testverbindungen, geschützte ausgehende Verbindungen oder Blockweiterleitungsverbindungen, über Neustarts hinweg erhaltene Anker, Verdrängungsregeln und Begrenzungen der Adressweiterleitung erhöhen. Dies sind mehrschichtige Schutzmaßnahmen, keine Beweise dafür, dass Eclipse-Angriffe unmöglich sind.

Zahlungsbeispiel und Reaktion

Angenommen, der Knoten eines Händlers empfängt eine Zahlung und zeigt 6 confirmations an. Ein Angreifer, der diesen Knoten isoliert hat, kann ihm einen privat verwalteten gültigen Zweig mit der Zahlung zeigen, während im ehrlichen Netzwerk eine widersprüchliche Transaktion akzeptiert wird. Gibt der Händler allein aufgrund des isolierten Knotens nicht rückholbare Waren frei, belegt die angezeigte Zahl nicht, dass das ehrliche Netzwerk die Zahlung bestätigt hat.

Bei der Reaktion auf den Vorfall sollten Beweise gesichert werden, bevor einschneidende Änderungen erfolgen:

Erfassen Sie die gemeldete Kettenspitze, die kumulierte Arbeit, die Hashes neuerer Blöcke, die Peer-Liste, die Verbindungsrichtung, den Netzwerktyp, das zugeordnete autonome System, sofern verfügbar, sowie die Zeitstempel des zuletzt empfangenen Blocks.
Vergleichen Sie die Spitze und den Transaktionsstatus mit unabhängig betriebenen Knoten, die über tatsächlich getrennte Netzwerk- und Verwaltungswege erreicht werden. Öffentliche Explorer sind nur dann hilfreich, wenn auch ihre Infrastruktur unabhängig ist.
Setzen Sie die Abwicklung hoher Beträge oder die automatisierte Freigabe aus, wenn unabhängige Ansichten voneinander abweichen. Weitere Bestätigungen aus derselben isolierten Ansicht lösen das Problem nicht.
Wechseln Sie zu nachweislich vertrauenswürdiger Software und Konfiguration, untersuchen Sie DNS, Routing, Firewall, Proxy und eine mögliche Kompromittierung des Hosts und bauen Sie den Peer-Status gemäß dem dokumentierten Wiederherstellungsverfahren des Clients neu auf.
Stellen Sie Verbindungen schrittweise wieder her und prüfen Sie, ob sich Peers, Netzwerkgruppen, Blockeingänge, Kettenarbeit und Transaktionsbeobachtungen diversifizieren. Stellen Sie eine möglicherweise manipulierte Peer-Datenbank nicht unbesehen wieder her.
Bewahren Sie Protokolle auf und eskalieren Sie den Fall an das Sicherheitsteam für den Knoten oder das Protokoll. Ein vermuteter Eclipse-Angriff kann sich mit gewöhnlichen Ausfällen, Routingvorfällen oder einer umfassenderen Kompromittierung des Hosts überschneiden.

In Bitcoin Core 30.0 stellt getpeerinfo Felder wie network, mapped_as, inbound, last_block, synced_headers, synced_blocks und connection_type bereit. Diese Felder unterstützen die Untersuchung, doch kein einzelnes Feld beweist eine Isolation. Die Überwachung sollte einen Normalzustand als Referenz festlegen und eine Konzentration von Peers mit unabhängigen Beobachtungen der Kette abgleichen.

Risiken und Kontrollen

Doppelausgabe gegen einen Empfänger: Dem Opfer können Bestätigungen auf einem vom Angreifer kontrollierten Zweig gezeigt werden. Verlangen Sie bei hochwertigen oder irreversiblen Lieferungen unabhängige Beobachtungen und setzen Sie Grenzen, die das Abwicklungsrisiko widerspiegeln.
Störung von Minern oder Validatoren: Ein isolierter Betreiber kann mit veralteten Informationen arbeiten, Einnahmen verlieren oder einen gegnerischen Zweig unterstützen. Überwachen Sie Kettenarbeit, Aktualität der Spitze und Peer-Vielfalt außerhalb des Produktionsknotens.
Selektive Zensur: Der Angreifer kann Transaktionen verbergen oder Blöcke verzögern, ohne ungültige Daten zu senden. Warnen Sie bei ungewöhnlichen Abständen zwischen Blockeingängen und bei Abweichungen zwischen unabhängigen Beobachtern.
Ausfall von Bridges, Orakeln und RPC: Off-Chain-Dienste, die einem einzigen vorgeschalteten Knoten vertrauen, können veraltete Zustände weitergeben oder eine Reorganisation übersehen. Nutzen Sie mehrere unabhängig verwaltete und vernetzte Datenquellen mit ausdrücklichen Quorum- und Aktualitätsregeln.
Falsches Vertrauen in die Verbindungszahl: 20 Peers unter der Kontrolle einer Organisation, eines Netzwerks oder einer Adressquelle können weniger Unabhängigkeit bieten als eine kleinere, vielfältige Gruppe. Messen Sie die Vielfalt, nicht nur die Anzahl.
Zentralisierung durch feste Peers: Ein einzelner manuell konfigurierter vertrauenswürdiger Peer kann einen manipulierten Kandidatenbestand umgehen, schafft aber einen einzelnen Ausfallpunkt. Sind feste Anker sinnvoll, sollten mehrere unabhängig betriebene Wege genutzt und zufällige Verbindungen beibehalten werden.

Knotenbetreiber sollten unterstützte Client-Versionen aktuell halten, die clientspezifischen Standardeinstellungen der Peer-Verwaltung kennen, den administrativen Zugriff schützen und sowohl die eingehende als auch die ausgehende Topologie überwachen. Zahlungs- und Protokollbetreiber sollten Signierung, Übertragung, Kettenbeobachtung und Freigabeentscheidungen voneinander trennen, damit ein einzelner isolierter Knoten nicht allein eine irreversible Aktion autorisieren kann.

Häufige Irrtümer

Ein vollständiger Knoten kann nicht getäuscht werden. Ein vollständiger Knoten weist Daten zurück, die gegen den Konsens verstoßen. Er erkennt jedoch nicht automatisch, dass ehrliche Peers ihm eine bessere gültige Kette vorenthalten.
Eine hohe Bestätigungszahl ist immer ausreichend. Bestätigungen sind nur im Verhältnis zur beobachteten Kettenansicht aussagekräftig. Wenn eine Isolation möglich ist, kommt es auf die Unabhängigkeit des Beobachtungswegs an.
Mehr Peers lösen das Problem immer. Zusätzliche Peers helfen nur, wenn ihre Eigentümer, Netzwerkwege, Entdeckungsquellen und Ausfallarten ausreichend unabhängig sind.
Eclipse- und Sybil-Angriffe sind dasselbe. Sybil-Ressourcen können die Isolation erleichtern, aber ein Eclipse-Angriff ist die daraus resultierende Kontrolle über die Peer-Ansicht eines Opfers.
Ein übereinstimmender Block-Explorer beweist, dass der Knoten fehlerfrei ist. Der Explorer kann denselben vorgeschalteten Anbieter, Netzwerkweg oder Verwaltungsbereich wie das betroffene System nutzen.
Jeder veraltete Knoten wird angegriffen. Softwarefehler, Überlastung, Wartung, Routingfehler und Ressourcenerschöpfung können ähnliche Symptome hervorrufen. Behandeln Sie Eclipse als Hypothese, die anhand mehrerer Signale geprüft werden muss.

Quellen

Eclipse Attacks on Bitcoin’s Peer-to-Peer Network - USENIX Association (abgerufen: 2026-08-20)
Bitcoin Core RPC: getpeerinfo - Bitcoin Core (abgerufen: 2026-08-20)
Bitcoin Core: connection_types.cpp - Bitcoin Core (abgerufen: 2026-08-20)