12

If i host my own node, e.g. like TezBox does, what's the best practice regarding accessibility of certain RPC endpoints?

TzScan already restricts certain calls, as described here.

Tezos docs advise as following:

The RPC interface must be enabled in order for the clients to communicate with the node, but is should not be publicly accessible on the internet.

With the new memory management update, additional RPC endpoints will be available, and they might posses a danger if exposed publicly without knowing.

enter image description here

7

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.

10

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. :( – Tom Feb 6 '19 at 0:13
  • 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". – Stephen Andrews Feb 6 '19 at 0:19
  • I was actually playing around with your nodes earlier today, noticed pretty long response times ~700ms (from Europe). – Matej maht0rz Šima Feb 6 '19 at 0:36
  • Yep hoping the nginx switch will speed it up – Stephen Andrews Feb 6 '19 at 1:35
  • 2
    Proposing 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 owasp.org/index.php/Input_Validation_Cheat_Sheet – xtzbaker Feb 6 '19 at 8:16
6

One of the alternatives i could think of, is using Conseil: https://github.com/Cryptonomic/Conseil

In 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.

Here's a few examples

  • 1
    Could you please expand on your answer ? Thanks! – Ezy Feb 6 '19 at 3:45
  • 1
    Updated the comment with examples and explanation. – Matej maht0rz Šima Feb 6 '19 at 11:32
6

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.