Hardening an Ubuntu Server
Quick steps to secure your node.
Last updated
Quick steps to secure your node.
Last updated
Thank you for your support and kind messages! It really energizes us to keep creating the best crypto guides. Use cointr.ee to find our donation addresses and share your message. 🙏
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:
🔥 Tip: Do NOT routinely use the root account. Use su
or sudo
, always.
SSH to your server
Create a new user called cardano
Set the password for cardano user
Add cardano 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.
Your choice of ED25519 or RSA public key algorithm.
Transfer the public key to your remote node. Update the keyname.
Login with your new cardano user
Disable root login and password based login. Edit the /etc/ssh/sshd_config file
Locate PubkeyAuthentication and update to yes. Delete the #, if needed.
Locate PasswordAuthentication and update to no
Locate PermitRootLogin and update to prohibit-password
Locate PermitEmptyPasswords and update to no
Optional: Locate Port and customize it to your random port number.
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 cardano-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 requires low-level privileges.
To make SSH use the Google Authenticator PAM module, edit the /etc/pam.d/sshd
file:
Add the follow 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.
Note: If you are enabling 2FA on a remote machine that you access over SSH you need to follow steps 2 and 3 of this tutorial to make 2FA 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 **Chrome **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 Chrome) 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.
Source: techrepublic.com
Edit /etc/fstab
Insert the following line to the bottom of the file and save/close.
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 UFW. Assuming that you use the default profile allowing outgoing traffic and denying incoming traffic, open the following ports to incoming traffic:
Port 22 (or your random port #) TCP for SSH connection
Port 123 UDP for chrony ntp
Port 6000 TCP for Cardano network traffic
If you install a Grafana dashboard for monitoring your Cardano stake pool, then also open the following ports in UFW:
Port 3000 TCP for Grafana web server
Port 9100 TCP for Prometheus Node Exporter data
Port 12798 TCP for Cardano Node data for Prometheus
Do not expose Grafana (port 3000) and Prometheus endpoint (port 9100 and 12798) to the public internet as this invites a new attack surface!
Better idea - SSH tunnel to Grafana server
Setup a SSH tunnel with the following command:
Alternatively, If using Putty for SSHing, you can configure the tunnel as follows. Make sure to click "Add" and save your new profile settings.
Now you can access the Grafana server from your local machine's browser by visiting http://localhost:3000
Only open the following ports on nodes behind a network firewall. This is not required if using the above SSH tunnel method.
🔥 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.
Only your Relay Node(s) should be permitted access to your Block Producer Node.
In order to protect your Relay Node(s) from a novel "DoS/Syn" attack, Michael Fazio created iptables entry which restricts connections to a given destination port to 5 connections from the same IP.
Replace <RELAY NODE PORT>
with your public relay port, replace the 5 with your preferred connection limit.
Set the connection limit high enough so that your internal relay/block producer node topology remains functional.
🔥 iptables rules applied via terminal are not reboot-resistant!
You can check your current connections with a sorted list. Change the relay node port number, if needed.
DDoS/Syn attacks can be complex and can take down a node. A single iptables rule may not be sufficient to protect or mitigate against more modern attacks. Moreover, iptables rules added via the terminal are forgotten if the machine or the iptables service is restarted.
Carden Pool [CRPL] provides a script that configures and deploys iptables rules specifically designed to protect from various DDoS attack vectors, ensuring the persistence of these rules even after reboots.
Further information can be found in the Carden Pool GitHub repository.
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.
Congrats on completing the guide. ✨
Did you find our guide useful? Send us a signal with a tip and we'll keep updating it.
It really energizes us to keep creating the best crypto guides.
Use cointr.ee to find our donation addresses. 🙏
Any feedback and all pull requests much appreciated. 🌛
Hang out and chat with our stake pool community on Telegram @ https://t.me/coincashew
https://gist.github.com/lokhman/cc716d2e2d373dd696b2d9264c0287a3#file-ubuntu-hardening-md