自己ホスト型のBitcoin決済ソフトウェアBTCPay Serverを標準のDockerデプロイで運用しているオペレーターは、onionアクセスを維持したい場合、次回のセットアップまたはアップデート時にTorを明示的に選択する必要がある。バージョン2.4.5で導入されたこの変更により、Torは自動的に含まれるコンポーネントから外れ、これまでバンドルされていたサービスが管理者の設定選択事項となった。

BTCPayは、バージョン2.4.5に伴う10月5日付の発表でこのデプロイ変更を詳述した。公式のGitHubリリースページでは、ソフトウェアのリリースは10月6日と記録されている。既存のインストールでは、適用のタイミングは次回のDockerセットアップまたはアップデートであり、運用者が再度オプトインしない限り、日常的なメンテナンスの一環として実行中のデプロイからコンポーネントが外れる可能性がある。

この調整は、Torに依存するDockerオペレーター、特にサーバーのonionアドレス(Torのhidden serviceが公開する.onionエンドポイント)経由のアクセスを利用しており、以前はコアのBTay Serverフラグメントを通じてこのサービスを利用していた運用者にとって重要である。フラグメントとは、Dockerスタックを組み立てるために使用される設定コンポーネントである。

アップデート後のTor再有効化

BTCPayは、アップデート前に管理者へデプロイ変更内容の確認を勧めている。バージョン2.4.5でTorを有効にするコマンドは次のとおりである。

sudo btcpay-fragments add opt-add-tor

Torは引き続きサポートされており、BTCPayによれば既存のデータは現在のTorボリュームに保持される。これにより保存データは保護されるが、onionアクセスを継続するには依然としてデプロイにTorを含めて実行する必要がある。

BTCPay Serverのドキュメントによると、オプションのTorフラグメントopt-add-torはhidden serviceと選択されたonion接続を追加する。オペレーターはbtcpay-fragments showコマンドで設定を確認できる。このコマンドは設定を変更せず、最後に生成されたマニフェストの有効なフラグメントとともに、保存されている追加および除外されたフラグメントを報告する。アップデート前に、またフラグメント追加後にこの出力を確認することで、管理者はスタックが実際に実行している内容の前後の記録を得られる。フラグメントを変更するコマンドはroot権限を必要とし、セットアップを直ちに再適用する。

プライベートサービスには個別の例外が必要

2.4.5のリリースノートは、送信HTTPリクエストに関する破壊的変更も明示している。Lightning接続、LNURLリクエスト、請求書通知URL、Webhookについて、プライベートネットワーク宛ての宛先がデフォルトでブロックされる。この制限は、アプリケーションが内部またはその他の制限ネットワークリソースへリクエストを送信するよう仕向けられる脆弱性の種類であるサーバーサイドリクエストフォージェリ(SSRF)を防止することを目的としている。

両方の変更が同一リリースに含まれるため、単一のアップデートがオペレーターのセットアップの2つの異なる部分、すなわちonionの利用可能性とプライベートアドレスへの送信呼び出しに影響を与え得る。この保護が有効な状態で、意図的にプライベートサービスを利用するオペレーターは、必要な宛先をssrfexceptionsで許可する必要がある。BTCPayのオペレーターガイドでは、設定変更後にアプリケーションを再起動し、影響を受ける統合をテストするよう指示している。