Bitcoin CoreのRPC：ファイアウォールだけでは分からない公開範囲

資金について：この記事に直接の購入用紹介リンクはない。CypherpunkGuideは、リンク先の購入ガイドを通じて紹介報酬を得る場合がある。

ノードは動いている。同期も進んでいる。ファイアウォールの表示も有効になっている。それぞれ意味のある確認だが、管理用の接続へ誰が届くのかは、まだ分からない。

RPC（遠隔手続き呼出し）は、ソフトウェアがBitcoin Coreから情報を取得したり、操作を指示したりするための窓口である。他のBitcoinノードとやり取りするP2P通信とは役割が違う。ノード同士の接続を受け入れるからといって、管理用接続も公開してよいことにはならない。有効なウォレットや権限によっては、RPCへのアクセスが資金や私的な情報に関わる。Bitcoin Coreのセキュリティ文書も、公衆インターネットへのRPC公開を警告している。

必要なのは、確認した事実と、その事実から言える範囲を対応させることだ。自己管理の検証手順で残高表示と署名権限を分けたのと同じく、ここでも安心させる表示だけで結論を出してはいけない。

今回確認したのは、固定したソースの処理である

#

今回の分析対象はBitcoin Core v31.1のソースとDockerの公式文書である。稼働中のノード、開いたポート、特定の機器のファイアウォールは実測していない。

Coreのソースは、2026年10月10日に取得したcommit 9be056a8a72b624dae9623b2f7bded92c2a21c91へ固定した。根拠一式のダウンロードには、公開ソース7ファイル、取得元とSHA-256ハッシュの一覧、8場面の分析を収めている。ハッシュは保存ファイルの一致を調べるための値であり、配布プログラムの署名検証ではない。Dockerの文書は10月10日に確認し、10月11日に再確認した。更新される文書であり、特定版のDocker Engineを動かした試験ではない。

サービスの起動、ウォレットや認証用の秘密情報の利用、実資金の使用は行っていない。8場面すべてで、観測結果はnot_tested、つまり未試験である。独自の成果は、設定についての主張を原典へ対応させ、実際に届くか判断するために不足している証拠を整理した点にある。

待受先、接続元の許可、認証を分ける

#

Bitcoin Coreが接続を待つ場所、許可する接続元、認証、実行できる操作は別の制御である。一つの確認に通ったことも、拒否されたことも、残りの状態を証明しない。

待受先（listener）とは、プログラムが接続を受け入れるアドレスとポートの組み合わせだ。ループバック（loopback）は、127.0.0.1や::1のように、同じネットワーク環境の自分自身を指すアドレスである。Dockerは、ホストとなる機器の中で、アプリをコンテナーという分離された環境で動かす仕組みだ。通常の分離された構成では、ホスト機器とコンテナーのループバックは別々である。

固定した版のHTTPサーバー処理では、rpcbindかrpcallowipのどちらかに値がなければ、待受候補をループバックへ戻す。ただし、別の処理で作られる接続元の許可一覧まで捨てる、という意味ではない。両方に値がある場合も、待受先の設定と接続元の許可は別々に処理される。

確認を成功させるためだけに、これらの設定を追加してはいけない。まず調べるのは、動いているプログラムが実際に使っている設定だ。常駐用のbitcoindは既定でサーバーを有効にする。一方、画面操作用のアプリでは既定で無効と同じ版のRPC文書に記載されている。画面内のデバッグコンソールが使えても、HTTP接続の待受先がある証拠にはならない。

8332番だけを調べる方法にも限界がある。これはこの版のメインネットにおけるRPCの既定ポートであり、別のBitcoinネットワークや変更後の設定では異なる番号を使える。rpcportはネットワークごとの既定値を上書きし、rpcbindにポートを明示した場合は、その待受先ではさらに優先される。コンテナー構成では、ホスト側とコンテナー側のポートも区別する必要がある。

Dockerの通信経路は、UFWの有効表示だけでは判断できない

#

Linux上でDockerのbridgeネットワークを使う場合、UFWが有効でも、公開したコンテナーポートが閉じている証拠にはならない。UFWはLinuxのファイアウォール管理ツール、bridgeネットワークはホスト内の仮想ネットワークでコンテナーをつなぐ方式だ。Dockerの公式文書は、公開ポートへの通信が、UFWの通常の検査箇所であるINPUT・OUTPUTより前に振り分けられると説明している。

ポート公開の文書では、ホストアドレスを省略すると通常は全ホストアドレスへ公開される。ただし既定の割当先を変更している場合は別だ。公開設定が表示されても、コンテナー内でCoreが待ち受けているとは限らない。

ループバックへの公開も、すべての経路が閉じたという保証ではない。28.0.0より前には、同じL2、つまり同じローカルネットワーク区間の機器から届く例外が文書化されている。コンテナーのアドレスへ直接届くかどうかは、経路、gateway modeという通信方式、trusted_host_interfacesなどの設定にも左右される。ホスト宛てとコンテナー宛ては別々に確かめる。

この説明から、Docker Desktop、Swarm、すべてのネットワーク方式やファイアウォールに共通する修正コマンドは導けない。確認表には実際の環境を記す。維持管理の負担も含む判断は、セルフホスティングの考え方で扱っている。

8場面の確認表で、不足している証拠を見つける

#

次の8場面は、記録すべき確認事項である。安全性試験に8回合格したという意味ではない。空欄の確認表と原典に対応させた分析表を用意した。共有する記録には、認証情報、実際のアドレス、運用環境を特定する情報を入れないこと。

ループバックへ戻る場合、固定したCoreの待受処理はIPv4とIPv6の両方を候補にするが、少なくとも一つの待受先を確保できれば成功を返す。起動が成功したように見えても、両方が開いた証拠にはならない。Dockerでも、IPv4とIPv6でgateway modeが異なる場合がある。

確認表は次の順に使う。

1. 管理操作を許可する機器と、そこから届くべき接続先を定める。共有メモでは役割名を使う。
2. 秘密情報を除いた実際の設定と、観測した待受先を記録する。設定ファイルの見本だけでは、稼働中のプログラムが読み込んだ内容は分からない。認証情報を含む可能性がある設定やプロセス情報を丸ごと出力してはいけない。
3. IPv4とIPv6それぞれについて、ホストとコンテナーの経路を整理する。ルーターが関係する場合、その境界は家庭ルーターの点検も参照する。
4. 到達性を試すなら、自分の所有する機器か、試験の許可を得た機器だけを対象にする。接続元の場所、接続先の役割、IPv4かIPv6か、日時、応答の種類を残す。試験を簡単にするためにRPCを公衆インターネットへ開いてはいけない。
5. 証拠がない箇所はunknown、つまり未確認と記す。意図した機器だけが管理用接続へ届くと判断する前に、その不足を解消する。

HTTPの拒否応答は、ポートが閉じた証拠ではない

#

HTTPエラーは、試した経路でHTTPサービスが応答したことを示す。ネットワーク上のポートが到達不能だったという意味ではない。途中に通信を中継するプロキシがあるなら、応答元がBitcoin Coreかどうかも別に確認する必要がある。

固定した版のRPC要求処理では、該当する要求経路で認証情報がない場合や認証に失敗した場合に401を返す。403は接続元の拒否でも、認証済み利用者に許可されていない操作の拒否でも生じる。数字だけで拒否した制御を特定できない。

認証は通信の暗号化とも別である。VPN、SSHトンネル、Torのonion接続という名称だけで、機器の信頼性、接続先へ入れる人、残った待受先まで安全とは判断できない。Coreの文書は、onionサービスを公に公開する場合も含めて、RPCの公開を警告している。通信手段は、両端を誰が管理し、誰が使えるかと併せて判断する必要がある。

出典と検証の限界

#

Coreの説明は固定したv31.1のソース、Dockerの説明は日付を明記した文書確認に基づく。Dockerの文書2件は保存版本文を確認済み。Coreの保存版5件はソースファイルの本文を保存したもので、今回の分析に使った固定ソースと内容が完全に一致することを確認した。