Bitcoin Core RPC: Was eine aktive Firewall nicht beweist

Finanzierung: Dieser Artikel enthält keine direkten Affiliate-Kauflinks. CypherpunkGuide kann über verlinkte Kaufratgeber Vermittlungsprovisionen erhalten.

Der Knoten läuft, die Synchronisierung funktioniert und die Firewall meldet „aktiv“. Das sind nützliche Beobachtungen. Wer den Verwaltungszugang des Knotens erreichen kann, geht daraus jedoch nicht hervor.

RPC steht für Remote Procedure Call, also einen entfernten Prozeduraufruf. Über diese Schnittstelle kann Software Informationen von Bitcoin Core abfragen und Befehle ausführen lassen. Das ist ein anderer Zugang als die Peer-to-Peer-Verbindung zu anderen Bitcoin-Knoten. Eine gewünschte Verbindung zwischen Knoten rechtfertigt keinen öffentlich zugänglichen Verwaltungszugang. Je nach aktivierten Wallets und Berechtigungen kann RPC den Zugriff auf Guthaben oder private Informationen ermöglichen. Die Sicherheitsdokumentation von Bitcoin Core warnt davor, RPC über das öffentliche Internet zugänglich zu machen.

Entscheidend ist, was eine Beobachtung tatsächlich belegt. Auch bei unseren Prüfungen zur Selbstverwahrung genügt eine beruhigende Anzeige nur für die Aussage, die sie wirklich nachweist.

Was die Quellenanalyse belegt

#

Diese Analyse untersucht den Quellcode von Bitcoin Core v31.1 und die Docker-Dokumentation. Sie misst weder einen laufenden Knoten noch offene Ports oder das Verhalten einer Firewall auf einem bestimmten Gerät.

Am 10. Oktober 2026 wurden die Core-Dateien aus dem festen Commit 9be056a8a72b624dae9623b2f7bded92c2a21c91 abgerufen. Das Paket mit den Belegen enthält sieben öffentliche Quelldateien, ein Verzeichnis ihrer Herkunft mit SHA-256-Prüfsummen und die Analyse der acht Fälle. Mit den Prüfsummen lässt sich feststellen, ob die gespeicherten Dateien übereinstimmen. Eine Signaturprüfung des ausführbaren Programms ersetzen sie nicht. Die Docker-Dokumentation wurde am 10. Oktober geprüft und am 11. Oktober 2026 erneut gelesen. Sie kann sich ändern; eine bestimmte Version der Docker Engine wurde nicht getestet.

Für diese Analyse wurde kein Dienst gestartet. Weder Wallets noch geheime Zugangsdaten oder echtes Guthaben kamen zum Einsatz. Bei allen acht Fällen steht als beobachtetes Ergebnis not_tested, also „nicht getestet“. Der Beitrag besteht darin, Aussagen über Einstellungen auf ihre Quellen zurückzuführen und die noch fehlenden Nachweise für die tatsächliche Erreichbarkeit zu benennen.

Adresse, erlaubte Geräte und Anmeldung getrennt prüfen

#

Die Adresse, an der Bitcoin Core Verbindungen annimmt, die erlaubten Quelladressen, die Anmeldung und die zulässigen Befehle sind getrennte Kontrollen. Wenn eine davon eine Anfrage zulässt oder ablehnt, ist damit der Zustand der anderen nicht geklärt.

Ein Listener ist die Kombination aus Adresse und Port, an der ein Programm auf Verbindungen wartet. Loopback-Adressen wie 127.0.0.1 und ::1 verweisen auf die eigene Netzwerkumgebung. Docker führt Anwendungen in Containern aus, also in getrennten Umgebungen auf einem Host-Rechner. Bei der üblichen Netzwerkisolierung haben Host und Container jeweils eine eigene Loopback-Umgebung.

Im untersuchten HTTP-Servercode fällt die Auswahl der Listener auf Loopback zurück, sobald für rpcbind oder rpcallowip keine Werte vorliegen. Die separat erstellte Liste erlaubter Quelladressen wird dadurch nicht verworfen. Auch wenn beide Einstellungen Werte enthalten, bleiben die Auswahl der Listener und die Prüfung der Quelladresse getrennte Vorgänge.

Füge diese Einstellungen nicht einfach hinzu, um einen Test erfolgreich abzuschließen. Kläre zuerst, welche Werte der laufende Prozess tatsächlich verwendet. Das Hintergrundprogramm bitcoind aktiviert den Servermodus standardmäßig. Bei der Anwendung mit grafischer Oberfläche ist er laut RPC-Dokumentation derselben Version standardmäßig ausgeschaltet. Eine funktionierende Debug-Konsole in der Oberfläche belegt keinen Listener für HTTP-Verbindungen.

Nur Port 8332 zu prüfen, reicht ebenfalls nicht. Er ist in dieser Version der voreingestellte RPC-Port für das Bitcoin-Hauptnetz. Andere Bitcoin-Netze oder eigene Einstellungen können andere Ports verwenden. rpcport überschreibt den Standardwert des jeweiligen Netzes. Ein ausdrücklich in rpcbind angegebener Port hat für diesen Listener wiederum Vorrang. Bei Containern musst du außerdem den Port des Hosts vom Port im Container unterscheiden.

Warum der UFW-Status bei Docker nicht ausreicht

#

Bei Docker-Bridge-Netzwerken unter Linux belegt eine aktive UFW-Firewall nicht, dass ein veröffentlichter Container-Port gesperrt ist. UFW ist ein Werkzeug zur Verwaltung der Linux-Firewall. Ein Bridge-Netzwerk verbindet Container über ein virtuelles Netzwerk auf dem Host. Laut Docker-Dokumentation wird der Verkehr zu veröffentlichten Ports umgeleitet, bevor er die von UFW normalerweise verwendeten INPUT- und OUTPUT-Regelketten erreicht.

Für die Port-Veröffentlichung gelten weitere Bedingungen: Ohne angegebene Host-Adresse werden normalerweise alle Host-Adressen verwendet, sofern die voreingestellte Bind-Adresse nicht geändert wurde. Eine eingerichtete Port-Zuordnung beweist aber noch nicht, dass Core innerhalb des Containers auf Verbindungen wartet.

Auch eine Veröffentlichung nur auf Loopback garantiert nicht, dass sämtliche anderen Wege gesperrt sind. Docker dokumentiert für Versionen vor 28.0.0 eine Ausnahme im selben L2-Netz, also im selben lokalen Netzwerksegment: Andere Geräte dort konnten solche Ports erreichen. Ob eine Container-Adresse direkt erreichbar ist, hängt unter anderem von den Netzwerkrouten, dem Gateway-Modus und Einstellungen wie trusted_host_interfaces ab. Der Gateway-Modus bestimmt, wie der Verkehr zwischen dem Container-Netz und anderen Netzen behandelt wird. Prüfe Verbindungen zur Host-Adresse und direkt zur Container-Adresse getrennt.

Aus diesen Aussagen folgt kein allgemein gültiger Reparaturbefehl für Docker Desktop, Swarm, jeden Netzwerkmodus oder jede Firewall-Technik. Halte deshalb im Prüfblatt fest, welche Umgebung tatsächlich vorliegt. Den laufenden Wartungsaufwand behandelt unser Ratgeber zur Entscheidung für Self-Hosting.

Mit acht Fällen die fehlenden Nachweise bestimmen

#

Die acht Fälle zeigen, was du dokumentieren solltest. Sie stehen nicht für acht bestandene Sicherheitstests. Dafür gibt es ein leeres Prüfblatt und die Analyse mit Quellenbelegen. Alle drei Downloads übernehmen die gemeinsamen Quellenunterlagen und maschinenlesbaren Felder unverändert; eine vollständige Übersetzung der Materialien liegt nicht vor. In eine geteilte Kopie gehören weder Zugangsdaten noch echte Adressen oder Angaben, die deine Infrastruktur identifizierbar machen.

Beim Rückfall auf Loopback versucht die untersuchte Core-Funktion, Listener für beide Adressfamilien zu öffnen. Für ihre Erfolgsmeldung genügt jedoch, dass mindestens einer davon geöffnet werden konnte. Ein scheinbar erfolgreicher Start belegt deshalb nicht beide Listener. Auch Docker kann für IPv4 und IPv6 unterschiedliche Gateway-Modi verwenden.

Nutze das Prüfblatt in dieser Reihenfolge:

1. Lege fest, welches Gerät den Verwaltungszugang nutzen darf und welches Ziel es erreichen soll. Verwende in geteilten Notizen Rollenbezeichnungen statt echter Adressen.
2. Notiere die wirksamen Einstellungen ohne Geheimnisse und die tatsächlich beobachteten Listener. Eine Beispielkonfiguration beweist nicht, was der laufende Prozess geladen hat. Exportiere keine vollständigen Konfigurationen oder Prozessausgaben, die Zugangsdaten enthalten könnten.
3. Halte die Wege zu Host und Container für IPv4 und IPv6 getrennt fest. Ist ein Router beteiligt, gehört auch dessen Rolle dazu. Diese Grenze behandelt unsere englischsprachige Anleitung zur Prüfung des Heimrouters.
4. Teste die Erreichbarkeit nur an Systemen, die dir gehören oder für die du eine ausdrückliche Testerlaubnis hast. Notiere den Standort des anfragenden Geräts, die Rolle des Ziels, die Adressfamilie, den Zeitpunkt und die genaue Art des Ergebnisses. Öffne RPC niemals zum öffentlichen Internet, nur um einen Test zu vereinfachen.
5. Trage bei fehlenden Belegen unknown, also „ungeklärt“, ein. Schließe diese Lücken, bevor du dich darauf verlässt, dass ausschließlich die vorgesehenen Geräte den Verwaltungszugang erreichen können.

Eine HTTP-Ablehnung ist kein geschlossener Port

#

Ein HTTP-Fehler zeigt, dass auf dem getesteten Weg ein HTTP-Dienst geantwortet hat. Er belegt keinen unerreichbaren Netzwerkport. Ist ein Proxy, also ein Vermittler für die Verbindung, beteiligt, steht damit auch noch nicht fest, dass Bitcoin Core selbst geantwortet hat.

Die untersuchte RPC-Verarbeitung liefert im entsprechenden Ablauf 401, wenn Zugangsdaten fehlen oder die Anmeldung scheitert. 403 kann sowohl bei einer abgelehnten Quelladresse als auch später bei einem Befehl auftreten, den der angemeldete Nutzer nicht ausführen darf. Aus der Zahl allein lässt sich die ablehnende Kontrolle nicht bestimmen.

Eine Anmeldung verschlüsselt den RPC-Verkehr nicht. Ein VPN ist ein virtuelles privates Netzwerk; ein SSH-Tunnel leitet Verbindungen durch eine verschlüsselte SSH-Verbindung weiter, und ein Onion-Dienst ist über das Tor-Netz erreichbar. Diese Bezeichnungen allein belegen nicht, dass die beteiligten Rechner vertrauenswürdig sind, nur die vorgesehenen Personen auf die Endpunkte zugreifen können und keine weiteren Listener offenbleiben. Die Core-Dokumentation warnt ausdrücklich vor öffentlich zugänglichem RPC, auch über einen öffentlich bereitgestellten Onion-Dienst. Beurteile daher das Übertragungsverfahren zusammen mit der Frage, wer beide Endpunkte kontrolliert und nutzen kann.

Quellen und Grenzen der Prüfung

#

Die Aussagen zu Core beruhen auf dem unten festgelegten Quellcode von v31.1, die Aussagen zu Docker auf der datierten Dokumentationsprüfung. Die Archivfassungen beider Docker-Dokumente wurden geprüft. Die fünf Core-Archivfassungen enthalten die reinen Quelldateien; ihr Inhalt stimmt vollständig mit dem festgelegten Quellcode überein, der für diese Analyse verwendet wurde.