next: text: "Tailscale" link: "/guides/node/tailscale"#

Securing your Node#

The goal of this guide is to walk you through steps you can take to secure your node against malicious actors. Whether you're running a local server at home or a VPS server / virtual machine on the cloud, the tips here will help you harden your node against outside attack and help protect it during its lifespan.

This section will describe both essential actions, which you must take, and nice-to-have actions, which are helpful but not required.

Assumptions in This Guide#

This guide assumes your node runs Ubuntu 20.04 LTS. The concepts will carry over to other systems but the example commands may not.

As with all of the commands in this guide, we assume that you are connecting remotely to your node's command terminal using ssh. If you need a refresher on how to use ssh, take a look at the Intro to Secure Shell guide first.

ESSENTIAL: Keep your Client Machine Secure#

Most Smartnode operators interact with their node remotely by connecting to its terminal from another computer using ssh:

• The machine you connect to (in this case, your node machine) is called the server.
• The machine you connect from (such as your laptop, desktop, or even your phone) is the client.

One of the most important things you can do to secure your Smartnode is to keep your client machine secure. If your client machine is compromised and you use it to log into your node, then most of the security settings you apply to the node can be bypassed.

For example: if you use a laptop as an SSH client, and it has a keylogger installed, then any secret things you type on the node (such as your password or recovery mnemonic) when connected via SSH will be stolen.

There is no definitive guide to keeping your client machine secure, but being aware that it is a factor in your security is a good first step. Make sure that your client machine is as secure as it can be.

Here are a few tips:

• Don't use your client machine for risky activities (such as visiting untrustworthy websites or installing unnecessary programs)
• Keep your client machine updated with the latest security patches
• If possible, use a malware and antivirus protection program for your Operating System

For maximum security, you may want to use a dedicated machine as your SSH client, though this may not be practical for you.

ESSENTIAL: Secure your SSH Access#

Whether you run your Smartnode at home or you use a VPS in a remote datacenter, it is likely that either you access it through SSH, or that SSH is enabled even if you do not use it.

SSH connections are based on secure cryptography, but as with any secure system, the real security comes from using it correctly. There are two main things to do for your SSH settings:

1. Use an SSH key to log in remotely instead of a username and password
2. Disable password-based authentication entirely, so SSH keys are the only remote login option

As you are probably familiar with now, the default way to log into your node via SSH is with a username and password. The downside of this is that your password is typically something rather "short" and susceptible to brute-force attacks.

Luckily, there is an alternative way to log in via SSH: an SSH key pair.

SSH key pairs work similarly to blockchain wallets; they come with a public part (such as your wallet address) and a private part (the private key for your wallet address):

• You provide the public part to your node. This way, the node knows you're allowed to connect to it, and it knows that it's really you trying to connect.
• You keep the private part to yourself on your client machine. This way, you (and only you) can connect to your node.
  • You can (and should!) protect the private part with a password, so someone who steals your key can't use it.
• From a computer's perspective, the private key is exponentially harder to crack than a password is. This mitigates the risk of a brute-force attack against your node.

ssh-keygen -t ed25519 -C "[email protected]"

If you are comfortable with the default setting, simply press Enter.

Otherwise, type your desired location for the key. It must be an absolute path (e.g. /home/username/.ssh/rocketpool_key on Linux, or /Users/username/.ssh/rocketpool_key on OSX). Press Enter when you're done.

After pressing Enter, you will see:

This will become the password for the private key itself. Whenever you use the key to connect to your node, you will need to enter this password first.

Once you finish typing the password, press Enter. It will ask you to retype it for confirmation.

After that, you will see something like the following output:

The first line states the location of the private key, which is called id_ed25519 by default (notice that it does not have a file extension). Ubuntu will load this key for you automatically when you use ssh if this private key file is in the default location.

The second line states the location of the public key, which is called id_ed25519.pub by default. We'll need the public key for the next step.

ssh-add $HOME/.ssh/id_ed25519

eval $(ssh-agent)

nano ~/.bashrc

alias loadkey='ssh-add $HOME/.ssh/id_ed25519'

Adding the Public Key to your Node#

Once you have your SSH key pair, you can now add the public key to your node. This will let you connect to it over ssh using the private key you just generated, instead of your username and password.

There are two ways to do this - if one doesn't work, try the other way:

ssh-copy-id -i $HOME/.ssh/id_ed25519.pub [email protected]

ssh-copy-id -i $HOME/.ssh/id_ed25519.pub [email protected]

You should now be able to ssh into the node like you normally would, but now you won't have to type the password of the user account.

Instead, you will have to type the password of your SSH private key. Depending on your system settings, you may only have to do this once per restart, or you may have to do it every time you use the key to connect to your node.

Disable Login-via-Password#

Even though you have an SSH key pair set up, your node will still allow other machines to try to log in using the username and password method. This defeats the entire purpose of using SSH keys in the first place, so the next step is to disable those.

Start by logging into your machine using ssh as usual:

ssh [email protected]

As a reminder, you should do this twice on two separate terminals so you have a backup session just in case. You can ignore the backup session for now - we'll tell you when you need it. Run the following commands only in the first session.

Open the configuration file for the SSH server:

sudo nano /etc/ssh/sshd_config

As with all commands that start with sudo, this will prompt you for your user account's password. This is a large file, so you'll have to navigate through it using the arrow keys on your keyboard or Page Up / Page Down.

Make the following changes:

1. Uncomment #AuthorizedKeysFile if it is commented (by removing the # in front of it)
2. Change KbdInteractiveAuthentication yes to KbdInteractiveAuthentication no and uncomment (by removing the # in front of it) - note that older versions of SSH call this option ChallengeResponseAuthentication instead of KbdInteractiveAuthentication
3. Change PasswordAuthentication yes to PasswordAuthentication no and uncomment (by removing the # in front of it)
4. Change PermitRootLogin yes to PermitRootLogin prohibit-password unless it's already set to that and has a # in front of it

Once you're done, save with Ctrl+O and Enter, then exit with Ctrl+X.

Finally, run sudo sshd -T | grep -i passwordauthentication and make sure that it prints passwordauthentication no.
If it does not, you may need to run sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf and set PasswordAuthentication yes to PasswordAuthentication no in that file as well. Save and exit as before, with Ctrl+O and Enter, then Ctrl+X

Next, restart the SSH server so it picks up the new settings:

sudo systemctl restart ssh.service

After this, logging into SSH via a username and password should be disabled.

(Optional) Enable Two-Factor Authentication#

Two-factor authentication involves requiring a second security measure in addition to your password or SSH key, usually on a separate device from your primary one.

For example, you may be familiar with logging into a website such as a crypto exchange using both a password and a Google Authenticator code (or an SMS code). This two-step process is an example of two-factor authentication.

SSH can also be configured to require a Google Authenticator code, which means that an attacker that somehow compromised your SSH key and its passphrase would still need the device with the authenticator app on it (presumably your phone). This adds an extra layer of security to your system.

Start by installing Google Authenticator (or a compatible equivalent) on your phone if you don't already have it. For Android users, consider andOTP which is an open-source alternative that supports password locking and convenient backups.

Next, install the Google Authenticator module on your node with this command:

sudo apt install -y libpam-google-authenticator

Now tell the PAM (pluggable authentication modules) to use this module. First, open the config file:

sudo nano /etc/pam.d/sshd

Find @include common-auth (it should be at the top) and comment it out by adding a # in front of it, so it looks like this:

Next, add these lines to the top of the file:

# Enable Google Authenticator
auth required pam_google_authenticator.so

Then save and exit the file with Ctrl+O, Enter, and Ctrl+X.

Now that PAM knows to use Google Authenticator, the next step is to tell sshd to use PAM. Open the sshd config file:

sudo nano /etc/ssh/sshd_config

Now change the line KbdInteractiveAuthentication no to KbdInteractiveAuthentication yes so it looks like this:

(Older versions of SSH call this option ChallengeResponseAuthentication instead of KbdInteractiveAuthentication.)

Add the following line to the bottom of the file, which indicates to sshd that it needs both an SSH key and the Google Authenticator code:

AuthenticationMethods publickey,keyboard-interactive:pam

Then save and exit the file with Ctrl+O, Enter, and Ctrl+X.

Now that sshd is set up, we need to create our 2FA codes. In your terminal, run:

google-authenticator

First, it will ask you about time-based tokens. Say y to this question:

You will now see a big QR code on your screen; scan it with your Google Authenticator app to add it. You will also see your secret and a few backup codes looking like this:

Finally, it will ask you for some more parameters; the recommended defaults are as follows:

Once you're done, restart sshd so it grabs the new settings:

sudo systemctl restart sshd

When you try to SSH into your server with your SSH keys, you should now also be asked for a 2FA verification code, but not for a password.

ESSENTIAL: Enable Automatic Security Updates#

Operating System vendors routinely publish updates and security fixes, so it is important that you keep your system up to date with the latest patches. The easiest way to do this is to enable automatic updates.

Run the following commands on your node machine:

sudo apt update
sudo apt install -y unattended-upgrades update-notifier-common

You can change the auto-update settings by editing /etc/apt/apt.conf.d/20auto-upgrades:

sudo nano /etc/apt/apt.conf.d/20auto-upgrades

This is an example of reasonable auto-update settings:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";

# This is the most important choice: auto-reboot.
# This should be fine since Rocketpool auto-starts on reboot.
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

When you are done adding your changes, save with Ctrl+O and Enter, then exit with Ctrl+X.

After, make sure to load the new settings:

sudo systemctl restart unattended-upgrades

ESSENTIAL: Enable a Firewall#

In general, your machine should only accept network traffic on ports that your Execution client, Consensus client, and Smartnode stack use. To enforce that and prevent any unexpected or undesirable traffic, we can install a firewall on the node.

Ubuntu comes with ufw installed by default (the uncomplicated fire wall), which is a convenient utility for managing your node's firewall settings.

The following commands will set ufw up with a good default configuration for your Smartnode. Run these on your node machine.

Disable connections unless they're explicitly allowed by later rules:

sudo ufw default deny incoming comment 'Deny all incoming traffic'

Allow SSH:

sudo ufw allow "22/tcp" comment 'Allow SSH'

Allow execution client (formerly referred to as ETH1):

sudo ufw allow 30303/tcp comment 'Execution client port, standardized by Rocket Pool'
sudo ufw allow 30303/udp comment 'Execution client port, standardized by Rocket Pool'

Allow consensus client (formerly referred to as ETH2):

sudo ufw allow 9001/tcp comment 'Consensus client port, standardized by Rocket Pool'
sudo ufw allow 9001/udp comment 'Consensus client port, standardized by Rocket Pool'

If you run lighthouse client v4.5.0+, you can use quic protocol to reduce latency / increase bandwitdh, quic protocol uses lighthouse's --port + 1 to listen for quic messages by default: https://lighthouse-blog.sigmaprime.io/Quic,%20Networking.html

sudo ufw allow 8001/udp comment 'Consensus client port, standardised by Rocket Pool'

Finally, enable ufw:

sudo ufw enable

(Optional) Enable Brute-Force and DDoS Protection#

To protect your server from DDoS attacks and brute-force connection attempts, you can install fail2ban. This program will monitor incoming connections and block IP addresses that try to log in with faulty credentials repeatedly.

See this guide for more information on intrusion prevention.

Run the following commands on your node machine:

Install the service:

sudo apt install -y fail2ban

Next, open /etc/fail2ban/jail.d/ssh.local:

sudo nano /etc/fail2ban/jail.d/ssh.local

Add the following contents to it:

You can change the maxretry setting, which is the number of attempts it will allow before locking the offending address out.

Once you're done, save and exit with Ctrl+O and Enter, then Ctrl+X.

Finally, restart the service:

sudo systemctl restart fail2ban

And with that, you've just greatly improved the security posture of your node. Congratulations!