公開されたRPCでTezosノードをホストするためのベストプラクティスは何ですか?
4 回答
- 投票
-
- 2019-02-06
どちらか:
- RPCをまったく公開しない(!)、または
- 最大限に制限されたホワイトリストを使用してプロキシを前面に配置します.
もちろん、ホワイトリストが役立つためには、潜在的に有害なエンドポイントをホワイトリストに含めてはなりません...一見無害に見えるエンドポイントでさえサービス拒否に使用される可能性があり、一部のエンドポイントは驚くほど有害です.
Either:
- don't expose the RPC at all (!), or
- put a proxy in front with a maximally restrictive whitelist.
Of course, for a whitelist to help, you must not include potentially harmful endpoints in your whitelist... Even seemingly harmless endpoints might be used for denial of service, and some endpoints are surprisingly harmful.
-
- 2019-02-06
TezRPC(TezBoxを強化する)に対して行うことは、各サーバーでプロキシを実行することです.このプロキシ内で、公開エンドポイントをブロック、制限、カスタマイズできます.
現在、NodeJSで構築されたライトプロキシを使用していますが、nginxスタイルのプロキシに切り替えます(パフォーマンスが向上します).
これは、ほぼすべてのエンドポイントをブロックするnode.jsプロキシの例です(ポート8732でローカルRPC APIをリッスンします):
var express = require('express'); var request = require('request'); var app = express(); var cors = require('cors') var apiServerHost = "http://localhost:8732"; app.use(cors()) app.use('/', function(req, res) { // Whitelist. Be afraid. if (req.url === '/chains/main/blocks/head' || req.url === '/chains/main/blocks/head/hash') { var url = apiServerHost + req.url; req.pipe(request(url)).pipe(res); } else { res.status(404).send('Not available'); } }); app.listen(process.env.PORT || 3000, function () { console.log('TZProxy running') })
What we do for TezRPC (which powers TezBox) is run a proxy on each server. Within this proxy, you can then block, restrict and customize public facing endpoints.
We currently use a light proxy built with NodeJS, but will switch over to a nginx style proxy (better performance).
Here is an example of a node.js proxy that blocks almost all endpoints (listening to the local RPC API on port 8732):
var express = require('express'); var request = require('request'); var app = express(); var cors = require('cors') var apiServerHost = "http://localhost:8732"; app.use(cors()) app.use('/', function(req, res) { // Whitelist. Be afraid. if (req.url === '/chains/main/blocks/head' || req.url === '/chains/main/blocks/head/hash') { var url = apiServerHost + req.url; req.pipe(request(url)).pipe(res); } else { res.status(404).send('Not available'); } }); app.listen(process.env.PORT || 3000, function () { console.log('TZProxy running') })
-
したがって、ここでのブラックリストは、たとえば、質問の新しいエンドポイントを許可します.:(So your blacklist here will allow the new endpoints in the question, for example. :(
- 0
- 2019-02-06
- Tom
-
私は単に、ユーザーが求めているカスタムプロキシをデプロイする方法の例を投稿していました.前述のように、「一部のエンドポイント」をブロックします.I was simply posting an example of how to deploy a custom proxy, which is what the user is asking for. As mentioned, it blocks "some endpoints".
- 0
- 2019-02-06
- Stephen Andrews
-
私は実際に今日の初めにあなたのノードで遊んでいました、(ヨーロッパからの)700msまでのかなり長い応答時間に気づきました.I was actually playing around with your nodes earlier today, noticed pretty long response times ~700ms (from Europe).
- 0
- 2019-02-06
- Matej maht0rz Šima
-
うん、nginxスイッチがそれをスピードアップすることを願っていますYep hoping the nginx switch will speed it up
- 0
- 2019-02-06
- Stephen Andrews
-
ブラックリストアプローチを提案することは、制限的なホワイトリストを使用するよりも確かに安全性が低くなります.質問はベストプラクティスに関連しているため、例をホワイトリストに変更することで回答を改善できます.ブラックリストのアプローチには多くのセキュリティ上の欠点があります.Owaspには、このトピックに関する優れたリソースがありますhttps://www.owasp.org/index.php/Input_Validation_Cheat_SheetProposing a blacklist approach is certainly less secure than using a restrictive whitelist. Since the question is related to best practice, the answer could be improved by changing the example to a whitelist, the blacklist approach has many security shortcomings. Owasp have a good resource on this topic https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet
- 2
- 2019-02-06
- xtzbaker
-
スティーブン-それはジオロケーションにも関連している可能性がありますが、それはここでの主要なトピックではありません.Stephen - it could be related to geolocation as well, but that's not the main topic here.
- 0
- 2019-02-06
- Matej maht0rz Šima
-
ホワイトリストを使用するように例を更新しました.これにより、新旧の不良エンドポイントが除外されます.たとえば、[スナップショット関連のRPC](https://gitlab.com/nomadic-labs/tezos/commit/3345423ebaa9b5ebd3f075124eaa7f0b47acaed3)を追加するというアイデアがありました.私が許可した2つのエンドポイントがかなり安全であることを願っています...I updated the example to use a whitelist. This will exclude old and new bad endpoints. For example, there was some idea to add [snapshot-related RPCs](https://gitlab.com/nomadic-labs/tezos/commit/3345423ebaa9b5ebd3f075124eaa7f0b47acaed3). I hope the two endpoints I allowed are reasonably safe...
- 0
- 2019-07-04
- Tom
-
- 2019-02-06
私が考えることができる代替案の1つは、
Conseil
を使用することです. https://github.com/Cryptonomic/ConseilConseilが何をするかについての私の謙虚な理解では、tezos-node/rpcの上に拡張APIを提供することです.そしておそらく(?)エンドポイントやその他のセキュリティ対策を有効/無効にすることができるいくつかの追加機能.
ここにいくつかの例があります One of the alternatives i could think of, is using
Conseil
: https://github.com/Cryptonomic/ConseilIn my humble understanding what Conseil does, is provide an extended API on top of a tezos-node/rpc. And perhaps (?) some extra features which could allow enabling/disabling endpoints or other security measures.
-
あなたの答えを拡張していただけませんか?ありがとう!Could you please expand on your answer ? Thanks!
- 1
- 2019-02-06
- Ezy
-
例と説明でコメントを更新しました.Updated the comment with examples and explanation.
- 1
- 2019-02-06
- Matej maht0rz Šima
-
- 2019-02-09
自分だけのRPCが必要な場合は、sshローカルポート転送を使用して、RPCをリモートマシンのローカルホストからローカルマシンのローカルホストに転送することもできます.
たとえば、バックグラウンドプロセスとして:
ssh -fNT -L 8732:localhost:8732 user@hostname
これがどれほど安全かはわかりませんが.
When you only need the RPC for yourself you could also use ssh local port forwarding to forward the RPC from the localhost of your remote machine to the localhost of your local machine.
For instance, as a background process:
ssh -fNT -L 8732:localhost:8732 user@hostname
I don't know how safe this is though.
自分のノードをホストしている場合、例:
TezBox
のように、特定のRPCエンドポイントのアクセシビリティに関するベストプラクティスは何ですか?ここで説明のように、TzScanはすでに特定の通話を制限しています.
Tezos ドキュメントは次のようにアドバイスしています:
新しいメモリ管理更新すると、追加のRPCエンドポイントが利用可能になり、知らないうちに公開されると危険が生じる可能性があります.