Beiträge

Der Byzantinische Fehler: Abwehr einer Attacke

27.4.2018 / Falk Borgmann, Strategy Consultant, Deepshore GmbH

Über die Verteidigung verteilter Systeme

Im vorangegangenen Beitrag zum Byzantinischen Fehlermodell haben wir gezeigt, wie bereits ein Anteil von einem Drittel an gekaperten Knoten den Consensus verhindern und die Vetrauenswürdigkeit des gesamten Clusters zerstören kann. Daraus ergibt sich die folgerichtige Frage, wie ein System aufgebaut sein muss, um „Byzantine-Fault-tolerant“ zu sein.

Nach den Prinzipien der „Byzantine-Fault-Tolerance“ ist ein verteiltes System dann unangreifbar, wenn mehr als zwei Drittel der an einem Cluster beteiligten Knoten korrekt arbeiten. Der Anteil an von Angreifern gekaperten Instanzen muss also unterhalb der Ein-Drittel-Grenze bleiben. Um diese Annahme zu bestätigen, simulieren wir auch in diesem Beitrag ein Angriffs-Szenario, diesmal aber auf einen Vier-Knoten-Cluster. Ziel der Transaktion soll auch hier exemplarisch die Vereinbarung eines Termins zu einer bestimmten Uhrzeit sein.

Deep Shore

Abbildung 1: intakter Vier-Knoten-Cluster

Knoten A löst den Prozess aus, indem er die Nachricht mit dem Terminvorschlag „16.30 Uhr“ zeitgleich an die Knoten B, C und D versendet. Die Knoten B, C und D wiederum bestätigen sich gegenseitig und dem Versender, die Information mit dem Inhalt „16.30 Uhr“ erhalten zu haben. Die Informationen sind auf allen Instanzen homogen, die Transaktion ist validiert, der Consensus erreicht. Das Treffen findet also um 16.30 Uhr statt.

Deep Shore

Abbildung 2: Attacke im Vier-Knoten-Cluster

In dieser Abbildung wurde Knoten A durch einen Angreifer unter feindliche Kontrolle gebracht. Über diesen gekaperten Knoten werden drei unterschiedliche Uhrzeiten an die Peers geschickt, um Verwirrung über den tatsächlichen Termin zu stiften. Die loyalen Instanzen stellen anhand ihrer Peers sofort fest, dass sie widersprüchliche Informationen erhalten haben – allerdings können sie nicht ohne Weiteres ermitteln, wer der Urheber dieses Problems ist. Ohne diese Feststellung ist eine Bereinigung und Absicherung des Systems genauso wenig möglich wie eine gültige Terminvereinbarung untereinander.

Deep Shore

Abbildung 3: Validierung im Vier-Knoten-Cluster

Die Herausforderung für jeden einzelnen der loyalen Knoten besteht also darin, a) festzustellen, welche der Peer-Knoten vertrauenswürdig sind und b) dabei ein Quorum von über zwei Drittel gegenüber den illoyalen Knoten zu erreichen. Im Fall eines Vier-Knoten-Systems müssen also mindestens drei intakte Knoten den einen feindlichen Knoten isolieren. Erreicht wird das über einen Prüfalgorithmus: Stellt beispielsweise Knoten C die Nicht-Qualifizierbarkeit einer empfangenen Nachricht fest, sendet er zur Validierung eine Nachricht mit dem Inhalt „XYZ“ an alle Peers. Die intakten Knoten B und D bestätigen diesen Wert sowohl gegenüber dem Sender als auch untereinander. Lediglich der fremdbestimmte Knoten A sendet auch hier einen abweichenden Wert „123“ in den Cluster zurück. Damit offenbart er sich gegenüber C als nicht vertrauenswürdig. Die beiden anderen Knoten können gleich verfahren, um A als den Problemverursacher zu identifizieren. Da gleichzeitig die drei loyalen Knoten gemeinsam das Quorum erfüllen, kann Knoten A im weiterem Verlauf aus dem System ausgeschlossen werden. Knoten B, C und D verabreden sich anschließend korrekt für „16.30 Uhr“, die gültige Transaktion ist erreicht.

Dieses vereinfachte Lösungsmodell berücksichtigt natürlich nicht alle Umstände einer realen Transaktion. Zum Beispiel werden einzelne Nachrichten innerhalb des Clusters nicht komplett zeitgleich ausgetauscht. Stattdessen ist der Ablauf in einem verteilten System immer sequentiell, so dass die Erkenntnis, bei welchem Knoten es sich um die infizierte Instanz handelt, real erst nach dem Abschluss des Validierungsprozesses feststeht. Der Schutzmechanismus wirkt also erst für spätere Transaktionen vollständig.

Um den Modellablauf zu vervollständigen, wäre der konkrete Prozess des Ausschlusses eines infizierten Knotens zu betrachten. Dabei kommt nach der identifikation des feindlichen Knotens ein Mechanismus zum Einsatz, bei dem die loyalen Knoten einen Vorschlag in Umlauf bringen, die aus ihrer Sicht als illoyal identifizierte Instanz A aus dem System auszuschließen. Dieser Mechanismus könnte genau wie eine Validierungsnachricht im Cluster „beantragt“ werden. Da die drei korrekt funktionierenden Knoten sich einig wären und gemeinsam das Quorum erreichen, würde ein gültiger Konsens darüber hergestellt, dass diese Maßnahme korrekt ist. Der Angriff wäre also abgewehrt und das System vertrauenswürdig im Sinne einer „Byzantine Fault Tolerance“.

Aus unserem Special
»BLOCKCHAIN: COMPLIANCE FÜR DIE BUSINESS CLOUD«
Beitrag 4/6
Teilen: