8

I've seen a lot of people mention tezos setups for baking. The general idea would be to run a handful of FE nodes, likely geographically dispersed, and then having a private node which connects to just your FE nodes. And if possible, the private node would use a Ledger for baking/signing operations.

Such a system would be economically infeasible for me. I'm also itinerant enough that I can't just setup a home system. So I wanted to ask about general thoughts regarding the security of my setup.

I run a single node in a VPS. It runs in private mode and its peers are only the TF peers. The node talks to a signer running in another VPS via a private network. The signer's firewall is completely blocked off except for the signer port I chose and ssh is only available via a tunnel machine that is also part of the private network.

The the signer's firewall only allows connections to the signer port from the node VPS who's IP I whitelisted. Because of this, I didn't feel it was necessary to setup signer authentication.

The signer signs for my delegate address and the delegate address contains just enough tezzies (and a little extra for breathing room) to put up the deposits for PRESERVED_CYCLES as output by the estimated-rights.py script.

The rest of the tezzies live in an originated account elsewhere that delegates to my delegate, with the account keys stored on a Ledger.

A few questions:

  • Does this sound like a reasonably secure setup?
  • Any holes or anything I'm missing?
  • Is connecting to just the TF nodes enough to give me a high probability that blocks I bake are propagated through the network quickly and successfully injected?

Bonus points: Does anyone know if there is an AWS blockchain template in the works, similar to how there is for Ethereum? See: Using the AWS Blockchain Template for Ethereum

(This question has a diagram of the exact setup that is economically infeasible for me given that I am just a solo baker)

Improve this question

2 Answers 2

Reset to default
6

The the signer's firewall only allows connections to the signer port from the node VPS who's IP I whitelisted. Because of this, I didn't feel it was necessary to setup signer authentication.

This is the main security concern I would have. In general, your setup is fairly secure, however, the main risks are:

  • Because the signer has no authentication, anyone that can login to your baking system somehow can sign messages with the remote signer, including balance transfer of your bond/deposit.
  • The private key on your signer could also be at risk running on a VPS, as many of the VPS providers don't properly protect against side-channel attacks, which could allow the VPS provider or another customer to view the memory contents of your VM and expose the private key.

Another secure method that might be low cost:

  • Obtain a small Linux server that you can run at home. This could be a used PC as long as you have 2GB of memory or more and enough disk space for the blockchain (currently 73GB as of January 2019).
  • Use a Ledger to store your private keys.
  • Have the baker connect in --private-mode to the TF boot nodes as you are already doing, using your home internet connection.
Improve this answer
2
  • 1
    Thanks! Ah, ok yeah I should setup authentication. And right about the private key, after I enter the password for the key it will live in memory unencrypted. About the small Linux server, my IP is provided via DHCP and changes often for whatever reason due to my internet provider. This changing IP isn't a problem for other nodes (the TF nodes) contacting my node?
    – lostdorje
    Jan 30, 2019 at 13:24
  • 1
    If you're using --private-mode your connections are all outbound anyway (your node will block any unexpected inbound connections) so having a dynamic IP address won't be a problem.
    – Luke Youngblood
    Jan 30, 2019 at 15:44
3

The the signer's firewall only allows connections to the signer port from the node VPS who's IP I whitelisted. Because of this, I didn't feel it was necessary to setup signer authentication.

I would flip this. Block all incoming connections to the signer and instead have the signer connect to the TF. That way you don't have to worry about a malicious node trying to connect to your signer through attacks such as IP hijacking.

Improve this answer
2
  • 3
    I'm not sure I understand this. The signer needs to accept requests to sign. The signer itself doesn't connect to anything, it only responds to signing requests.
    – lostdorje
    Jan 31, 2019 at 2:00
  • 1
    This is on the connection level. The signer should issue the request. It means that it can potentially be behind a NAT, such as a home router, and you don't need to open any port to make the signer accessible from the outside world. This doesn't affect how signing requests are issued. It only affects who initiates the TCP connection.
    – adrian
    Feb 1, 2019 at 12:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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