Fellow operators, here is a link to the first in a series on best-practices for running a stake pool. Please ask any questions you may have here. Cheers, Chris Graffagnino
Thank you, Chris!
MASTR Rocks!
Thx, but I recommend not storing any of the ssh private keys on any Internet connected servers or desktops, what I do is I use a Ledger Nano as a deterministic ssh key storage by installing the SSH/PGP app on it. It works exactly the same as You would handle your wallets, it just expose the public key and only sign a request on the device that the user must accept. Even my pools op rewards and owner pledges (accessed by different PIN as plausible deniability) priv keys are on the same device though the others savings are on diff device. So, one 24-word phrase handles all pool ops related stuffs. Except the cold keys for which I created a BIP39 like tools to generatecold keys from a mnemonics for DR recovery purpose.
2 Likes
@_ilap could you elaborate on how you went about using BIP39 tools for generating cold keys in mnemonics please? Sounds like a fantastic idea.
This is a great security walkthrough! Would someone be able to point me towards a similar version with Windows in mind as opposed to Mac?
Great to see you sharing some details about hardening. Think it is really important to share this, since there is a big number of new pools coming up day by day.
Similar to @_ilap i’d also recommend to story the private key for the SSH connection on a secure device. Beside of ledger a Yubikey would also be a suiteable option for that job.
To further harden access to the machines I recommend to use a VPN. Wireguard is a great VPN tool. It runs as a virtual network interface. In an according setup every server is just exposing one VPN port. A private key / private key mechanism is authorizing clients.
From the firewall perspective then only the VPN port is opened for public. The public IP itself is completely locked (except the CNODE Port of the relay servers).
Maybe this is an overkill, but I mind it as a good practice because it acts as a central entry hurden for an attacker before being able to attack any of the services. Of course alternatively also IP limitations may be effective, but not so flexible. And of course the SSH Port change that you described also makes it difficult for an attacker to explore the entry point.
If someone is interested in more details: https://www.wireguard.com/
One note: It runs as a kernel module, in most cases already part of the distribution. Anyways it’s only able to run in this way if you have a fully virtualized VPS. (e.g. kvm) - OpenVZ will not work or needs workarounds…