Security Best Practices for your ETH staking validator node

Quick steps to secure your node.

πŸ€– Pre-requisites

  • 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:

πŸ§™β€β™‚οΈCreate a non-root user with sudo privileges

Make a habit of logging to your server using a non-root account. This will prevent the accidental deletion of files if you make a mistake. For instance, the command rm can wipe your entire server if run incorrectly using by a root user.

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

πŸ” Disable SSH password Authentication and Use SSH Keys only

The basic rules of hardening SSH are:

  • No password for SSH access (use private key)

  • Don't allow root to SSH (the appropriate users should SSH in, then su or sudo)

  • Use sudo for users so commands are logged

  • Log unauthorized login attempts (and consider software to block/ban users who try to access your server too many times, like fail2ban)

  • Lock down SSH to only the ip range your require (if you feel like it)

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.

Your choice of ED25519 or RSA public key algorithm.

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.

Use a random port # from 1024 thru 49141. Check for possible conflicts.

Validate the syntax of your new SSH configuration.

If no errors with the syntax validation, restart the SSH process

Verify the login still works

Alternatively, you might need to add the -p <port#> flag if you used a custom SSH port.

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.

πŸ€– Update your system

Enable automatic updates so you don't have to manually install them.

🐻 Disable root account

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.

πŸ› οΈ Setup Two Factor Authentication for SSH [Optional]

SSH, the secure shell, is often used to access remote Linux systems. Because we often use it to connect with computers containing important data, it’s recommended to add another security layer. Here comes the two factor authentication (2FA).

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.

🧩 Secure Shared Memory

One of the first things you should do is secure the shared memory 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 techrepublic.com article.

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.

⛓️Install Fail2ban

Fail2ban is an intrusion-prevention system that monitors log files and searches for particular patterns that correspond to a failed login attempt. If a certain number of failed logins are detected from a specific IP address (within a specified amount of time), fail2ban blocks access from that IP address.

Edit a config file that monitors SSH logins.

Add the following lines to the bottom of the file.

πŸ”₯ 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.

Save/close file.

Restart fail2ban for settings to take effect.

🧱Configure your Firewall

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

Only open the following ports on local home staking setups behind a home router firewall or other network firewall.

πŸ”₯ It is dangerous to open these ports on a VPS/cloud node.

Confirm the settings are in effect.

[ Optional but recommended ] Whitelisting (or permitting connections from a specific IP) can be setup via the following command.

🎊 Port Forwarding Tip: You'll need to forward and open ports to your validator. Verify it's working with https://www.yougetsignal.com/tools/open-ports/ or https://canyouseeme.org/ .

πŸ“ž Verify Listening Ports

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

πŸ‘©β€πŸš€ Use system user accounts - Principle of Least Privilege [Advanced Users / Optional]

Recommended for Advanced Users Only

Principle of Least Privilege: Each eth2 process is assigned a system user account and runs under the least amount of privileges required in order to function. This best practice protects against a scenario where a vulnerability or exploit discovered in a specific process might enable access other system processes.

✨ Additional validator node best practices

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

πŸ€– Start staking by building a validator

πŸš€ References

https://gist.github.com/lokhman/cc716d2e2d373dd696b2d9264c0287a3#file-ubuntu-hardening-md

Last updated