Part 2 - Node Operator's Configuration Guide for Dummies - Securing your Node
Part 2 - Securing your Node
Part 2 - Securing your Node
Securing your Node
This guide aims to walk you through steps you can take to secure your node against malicious actors. It will describe both essential actions, which you must take, and nice-to-have actions, helpful but not required.
We have already covered basic hardening and SSH key-based authentication in Part 1, so these security measures will be either Rocket Pool specific or additional general measures to increase your security posture.
While making changes to your servers, remember to always open a secondary SSH connection. A simple mistake can permanently lock you out. Another connection running concurrently will allow you to flip over and revert your misconfiguration.
ESSENTIAL: Enable Automatic Security Updates
Operating System vendors routinely publish updates and security fixes, so you must 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 appropriate 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
We have already enabled the firewall in the basic hardening section from Part 1. However, these are Rocket Pool specific configurations that you will need to apply!
In general, your machine should only accept network traffic on ports that your ETH1 client, ETH2 client, and Smartnode stack use. We can install a firewall on the node to enforce that and prevent any unexpected or undesirable traffic.
Ubuntu comes with ufw installed by default (the uncomplicated fire wall), convenient for managing your node's firewall settings.
The following commands will set ufw up with a reasonable 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:
We have already enabled SSH from the basic hardening section from Part 1. You should not need to rerun this, but if you do, change the 22 to whichever port you have configured for SSH!
sudo ufw allow "22/tcp" comment 'Allow SSH' Allow Geth if you use it (see the Geth documentation for more info):
sudo ufw allow 30303/tcp comment 'Go Ethereum port, standardized by Rocketpool'
sudo ufw allow 30303/udp comment 'Go Ethereum port, standardized by Rocketpool'Allow your Beacon Client:
sudo ufw allow 9001/tcp comment 'Rocketpool default ETH2 port'
sudo ufw allow 9001/udp comment 'Rocketpool default ETH2 port'Allow the node-exporter to access Prometheus:
sudo ufw allow 9103 comment "Allow node-exporter access to Prometheus" Finally, enable ufw (if not already enabled):
sudo ufw enable (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.
WARNING We strongly recommend that you open a second terminal with an SSH connection to your node, just in case you misconfigure something. This way, you will have a backup that is still connected in case you lock yourself out, so you can easily undo your mistakes.
If you do manage to lock yourself out, you will need to physically access your node via its local monitor and keyboard to log in and repair the misconfiguration.
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:
# Standard Un*x authentication.
#@include common-auth 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 The next two commands you may have set differently while following the basic hardening guide. As we are setting up 2FA, you will need to adjust them accordingly.
Now change the line ChallengeResponseAuthentication no to ChallengeResponseAuthentication yes, so it looks like this:
# Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads)
ChallengeResponseAuthentication yes Now change the line UsePAM no to UsePAM yes, so it looks like this:
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yesAdd 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 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:
Do you want authentication tokens to be time-based: y 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:
Your new secret key is: IRG2TALMR5U2LK5VQ5AQIG3HA4
Your verification code is 282436
Your emergency scratch codes are:
29778030
86888537
50553659
41403052
82649596 NOTE Record the emergency scratch codes somewhere safe in case you need to log into the machine but don't have your 2FA app handy. Without the app, you will no longer be able to SSH into the machine!
Finally, it will ask you for some more parameters; the recommended defaults are as follows:
Do you want me to update your "/<username>/.google_authenticator" file: y Do you want to disallow multiple uses of the same authentication token: y By default... < long story about time skew > ... Do you want to do so: n Do you want to enable rate-limiting: y 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.
(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 Modify the port = 22 to whichever SSH port you set during Part 1 of this guide!
Add the following contents to it:
[sshd]
enabled = true
banaction = ufw
port = 22
filter = sshd
logpath = %(sshd_log)s
maxretry = 5 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!
