Is your server secure or did you leave your front door open?

Reasons for testing

The number of stakepools is increasing every day and besides the official documentation there are many places which describe how to build a stakepool or even provide scripts and tools to do so. An increasing number of stakepools is being build by people with no or limited knowledge of Linux system administration. The task of a stakepool operator however doesn't end after building a stakepool. He or she should implement best practices to secure the nodes. When a node gets hacked, the general public might think that Cardano gets hacked and this could harm all the marketing effort that is being put into Cardano and thus harm the Cardano-ecosystem.

Remote administration of Linux servers is carried out in general by using SSH terminal client sessions. Hackers know this all to well and will therefore try to login using SSH or try to attack the SSH daemon running on the server. Now some operators might say they have build in extra security measures to prevent their system from being hacked. I ask these operators to just have a short look at the security issues that have been found in openSSH in the past.

Way of testing

A simple virtual Linux machine was deployed at a cloud service provider, provisioned with a public ip address and the package jq was installed on the server. The ip addresses and DNS records were extracted and deduped from the publicly available list of relays that is maintained by Cardano. With the use of a batch file and the package nc, each ip address and DNS record was tested to see if it was possible to connect to the SSH port. Each server that allowed the connection was put in a text file. No attempts to login or attack the SSH port were made.

Results

The public relay list held a total of 1624 relay nodes, after deduplication 1476 ip addresses and DNS records remained. 405 relay nodes allowed the connection to their SSH port which is equivalent to nearly 27.5% of all relay nodes.

Best practices

• keep your server up to date and install at least the security updates on a regular basis
• if you don't use SSH to administer your server because you use a physical console then shut down the SSH daemon
• only allow trusted ip addresses to connect to the SSH port of your node on the edge device (your router at home or the office or the firewall of your cloud service provider)
• only allow trusted ip addresses to connect to the SSH port of your node using the firewall on the Linux server
• disable SSH login for the root account
• disable username / password SSH logins
• limit the amount of concurrent SSH logins to the number that you actually use + 1
• use a RSA public / private key pair with a 4096-bit key size to login
• password protect the RSA private key with a strong password
• remove all Cardano related keys from your relay node. a relay node doesn't need any of those

Optional best practices

• use a stepping stone or jump server to administer your nodes
• use a separate VPN server to access your stepping stone or jump server 

Follow up

We will repeat this port test from time to time and sincerely hope that next time all relay nodes have their SSH ports closed for untrusted public ip addresses.