Skip to main content

Security best practices

After installing your validator or rpc server, the next step is setting up the level of security you feel comfortable with. The standards in this guide are for the minimum recommended level of operational security to ensure best possible uptime on Ubuntu server 20.04 and newer.

Your Firewall​

  1. Before you do anything else, as a sudo user, make sure your system is up to date:

    sudo apt-get update -y && sudo apt upgrade -y

    Once that process is complete do a: sudo reboot now

  2. Now that we have an up to date system let's install a firewall, we are choosing to work with UFW (Uncomplicated Firewall) that is done using: sudo apt install ufw

  3. Check and ensure that UFW is configured to also support Ipv6 if that is available from your hosting provider:

    sudo nano /etc/default/ufw

    A) If the IPv6 value is set to no, change the value to yes to enable IPv6 use.

    B) Save and close the file.

  4. The next step is setting up two or three general policies that will help secure your system by blocking incoming connections and allowing outbound connections: sudo ufw default deny incoming Follow that with: sudo ufw default allow outgoing The third general policy is about ssh, if you are self-hosting the node or validator we strongly recommend disabling ssh as you will be accessing it via a physical keyboard. sudo ufw allow OpenSSH or if disabling it sudo ufw deny OpenSSH

  5. Now that we have general policies in place for hardening our system we need to stop and restart UFW to make sure the changes have been activated that is done by: Stopping: sudo ufw disable Starting:sudo ufw enable

  6. After hardening our system we need to open up peering port (which is by default 6534 but we use 6533) to ensure that our validator can communicate with the rest of the network: sudo ufw allow 6533

  7. Repeat step 5 and check the status of UFW using: sudo ufw status verbose

    This will produce console output that should make it clear what rules you have configured in UFW.

Hardening pain-points​

If you are allowing Username and Password access to your server, you should also set up security for your access, one of the best applications for this is fail2ban configured correctly it will stop bruteforce attacks as well as several forms of DOS attacks.

  1. Installing fail2ban: apt-get install fail2ban

  2. Edit the configuration file: nano /etc/fail2ban/jail.local

  3. Find the [DEFAULT] section and edit these options:

    ignoreip:This option enables you to specify IP addresses or hostnames that fail2ban will ignore. For example, you could add your home or office IP address so fail2ban does not prevent you from accessing your own server. To specify multiple addresses, separate them with a space. For example:

    ignoreip = 127.0.0.1/8 93.184.216.34

    bantime: This option defines in seconds how long an IP address or host is banned. The default is 600 seconds (10 minutes). The longer the better (can be an issue if you have a badly written down password or bad memory)

    maxretry: This option defines the number of failures a host is allowed before it is banned. The lower the harsher. (can be an issue if you have bad memory or badly written down password)

    findtime: This option is used together with the maxretry option. If a host exceeds the maxretry setting within the time period specified by the findtime option, it is banned for the length of time specified by the bantime option. The longer the harsher! (can be an issue if you have bad memory or badly written down password)

The jail.local file includes default jail settings for several protocols however ssh is the default. Often, all you need to do to enable a jail is change its enabled = false line to enabled = true and restart fail2ban. You can also define custom jails and filters for additional flexibility. For more information about how to do this, please visit http://www.fail2ban.org/wiki/index.php/MANUAL_0_8

  1. Save your changes to the jail.local file.
  2. Restart fail2ban to make your changes take effect: service fail2ban restart

To check that fail2ban is working once it has been up for a while: iptables -S

For example, the following line shows an IP address that the SSH jail has banned: -A fail2ban-SSH -s 10.0.1.124/32 -j REJECT --reject-with icmp-port-unreachable