使用公开的RPC托管Tezos节点的最佳实践是什么?
4 个回答
- 投票数
-
- 2019-02-06
要么:
- 完全不公开RPC(!),或
- 在代理服务器前面放置一个限制最大的 whitelist .
当然,要获得白名单的帮助,您一定不能在白名单中包括潜在有害的端点...甚至看似无害的端点也可能被用于拒绝服务,并且某些端点出人意料地有害.
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
-
我实际上是在今天早些时候与您的节点一起玩耍的,发现响应时间很长,大约700毫秒(来自欧洲).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-它也可能与地理位置有关,但这不是这里的主题.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).我希望我允许的两个端点都相当安全...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
我能想到的替代方法之一是使用
Conseil
: https://github.com/Cryptonomic/Conseil根据我的拙见,Conseil的作用是在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端点将可用,如果在不知情的情况下公开暴露,它们可能会带来危险.