Security Best Practices for your ETH staking validator node
Quick steps to secure your node.
Last updated
Quick steps to secure your node.
Last updated
Ubuntu Server or Ubuntu Desktop installed
SSH server installed
a SSH client or terminal window access
In case you need to install SSH server, refer to:
In case you need a SSH client for your operating system, refer to:
SSH to your server with your SSH client
Create a new user called ethereum
Set the password for ethereum user
Add ethereum to the sudo group
Create a new SSH key pair on your local machine. Run this on your local machine. You will be asked to type a file name in which to save the key. This will be your keyname.
Transfer the public key to your remote node. Update keyname.pub appropriately.
Login with your new ethereum user
Disable root login and password based login. Edit the /etc/ssh/sshd_config file
Locate ChallengeResponseAuthentication and update to no
Locate PasswordAuthentication update to no
Locate PermitRootLogin and update to prohibit-password
Locate PermitEmptyPasswords and update to no
Optional: Locate Port and customize it your random port.
Validate the syntax of your new SSH configuration.
If no errors with the syntax validation, restart the SSH process
Verify the login still works
Optional: Make logging in easier by updating your local ssh config.
To simplify the ssh command needed to log in to your server, consider updating your local $HOME/.ssh/config
file:
This will allow you to log in with ssh ethereum-server
rather than needing to pass through all ssh parameters explicitly.
It's critically important to keep your system up-to-date with the latest patches to prevent intruders from accessing your system.
Enable automatic updates so you don't have to manually install them.
System admins should not frequently log in as root in order to maintain server security. Instead, you can use sudo execute that require low-level privileges.
To make SSH use the Google Authenticator PAM module, edit the /etc/pam.d/sshd
file:
Add the following line:
Now you need to restart the sshd
daemon using:
Modify /etc/ssh/sshd_config
Locate ChallengeResponseAuthentication and update to yes
Locate UsePAM and update to yes
Save the file and exit.
Run the google-authenticator command.
It will ask you a series of questions, here is a recommended configuration:
Make tokens “time-base”": yes
Update the .google_authenticator
file: yes
Disallow multiple uses: yes
Increase the original generation time limit: no
Enable rate-limiting: yes
You may have noticed the giant QR code that appeared during the process, underneath are your emergency scratch codes to be used if you don’t have access to your phone: write them down on paper and keep them in a safe place.
Now, open Google Authenticator on your phone and add your secret key to make two factor authentication work.
One exceptional case
There may be a reason for you needing to have that memory space mounted in read/write mode (such as a specific server application like DappNode that requires such access to the shared memory or standard applications like Google Chrome). In this case, use the following line for the fstab file with instructions below.
The above line will mount the shared memory with read/write access but without permission to execute programs, change the UID of running programs, or to create block or character devices in the namespace. This a net security improvement over default settings.
Use with caution
With some trial and error, you may discover some applications(like DappNode) do not work with shared memory in read-only mode. For the highest security and if compatible with your applications, it is a worthwhile endeavor to implement this secure shared memory setting.
Edit /etc/fstab
Insert the following line to the bottom of the file and save/close. This sets shared memory into read-only mode.
Reboot the node in order for changes to take effect.
Edit a config file that monitors SSH logins.
Add the following lines to the bottom of the file.
Save/close file.
Restart fail2ban for settings to take effect.
The standard UFW firewall can be used to control network access to your node.
With any new installation, ufw is disabled by default. Enable it with the following settings.
Port 22 (or your random port #) TCP for SSH connection
Ports for p2p traffic
Lighthouse uses port 9000 tcp/udp
Teku uses port 9000 tcp/udp
Prysm uses port 13000 tcp and port 12000 udp
Nimbus uses port 9000 tcp/udp
Lodestar uses port 30607 tcp and port 9000 udp
Port 30303 tcp/udp eth1 node
Do not expose Grafana (port 3000) and Prometheus endpoint (port 9090) to the public internet as this invites a new attack surface! A secure solution would be to access Grafana through a ssh tunnel with Wireguard.
Only open the following ports on local home staking setups behind a home router firewall or other network firewall.
Confirm the settings are in effect.
[ Optional but recommended ] Whitelisting (or permitting connections from a specific IP) can be setup via the following command.
If you want to maintain a secure server, you should validate the listening network ports every once in a while. This will provide you essential information about your network.
Alternatively you can use netstat
If you decide to use system user accounts, remember to replace the systemd unit files with the corresponding users.
Furthermore, ensure the correct file ownership is assigned to your system user account where applicable.
Networking
Assign static internal IPs to both your validator node and daily laptop/PC. This is useful in conjunction with ufw and Fail2ban's whitelisting feature. Typically, this can be configured in your router's settings. Consult your router's manual for instructions.
Power Outage
In case of power outage, you want your validator machine to restart as soon as power is available. In the BIOS settings, change the Restore on AC / Power Loss or After Power Loss setting to always on. Better yet, install an Uninterruptable Power Supply (UPS).
Clear the bash history
When pressing the up-arrow key, you can see prior commands which may contain sensitive data. To clear this, run the following:
shred -u ~/.bash_history && touch ~/.bash_history
Tip: Do NOT routinely use the root account. Use su
or sudo
, always.
Your choice of public key algorithm.
Use a random port # from 1024 thru 49141.
Note: If you are enabling 2FA on a remote machine that you access over SSH you need to follow steps 2 and 3 of to make 2FA work.
One of the first things you should do is secure the shared used on the system. If you're unaware, shared memory can be used in an attack against a running service. Because of this, secure that portion of system memory.
To learn more about secure shared memory, read this .
Source:
Whitelisting IP address tip: The ignoreip
parameter accepts IP addresses, IP ranges or DNS hosts that you can specify to be allowed to connect. This is where you want to specify your local machine, local IP range or local domain, separated by spaces.
It is dangerous to open these ports on a VPS/cloud node.
Port Forwarding Tip: You'll need to forward and open ports to your validator. Verify it's working with or .
Caveats For Advanced Users
Congrats on completing the guide.