I have been working with masternodes for almost two years now, which assumes additional knowledge of Linux systems. If you host and maintain masternodes by yourself, it is crucial to have the necessary knowledge of Linux, especially knowledge that system administrators have.
Many tutorials and manuals can be found on the Internet, but to successfully apply this knowledge to blockchain and masternodes, we need to classify what is relevant and learn it.
From a number of masternode coins, I chose TELOSCOIN as one of the very promising cryptocurrencies supported by serious team led by Pascal Papara who is the founder and CEO of Transcendence blockchain.
Learn more:
https://telosgreen.org
https://twitter.com/PaparaPascal
From the very beginning of my collaboration with the Transcendence team, I have had a number of masternodes that I hosted on my own on VPS or Dedicated servers.
During this time, my knowledge advanced to a decent level, but the learning is never ended ...
I applied my passion for programming to making various Discord bots. So, on Transcendence Discord we have several bots that help users in different ways. One of them, called MasternodeBot, reads the blockchain and reports the status of the masternode to the user.
You can join Transcendence community Discord following this link: https://discord.gg/ykFdsHD
All that bots, as well as one Transcendence blockchain (hot wallet), are hosted on a VPS that serves only these purposes and also represents one masternode in the network, which modestly contributes to its security.
However, while controlling the operation of this VPS in the "htop" command, I noticed something that caught my attention. That was the "sshd: [accepted]" line I haven't seen before.
After researching, I realized that these were, in fact, persistent ssh brute force attacks on the server.
Check out /var/log/auth.log ("sudo nano /var/log/auth.log") and if you see a number of failed attempts then someone is trying to attack your server. This log can show the IP addresses of the attackers as well as the username under which they attempt to attack.
Just by being in possession of a listening server on the Internet, you will get dozens or even hundreds of brute force login attempts each day. Most of these attempts come from automated scripts running on other discredited machines. If you are tired of reading through the failed attempts in the logs, there are various things you can do to block the attempts.
There are numerous ways to protect yourself against these types of attacks. Basically, each of them requires SSH services to be restarted in order for the changes to take effect.
"service sshd restart"
I selected the four easiest protection options that can be effectively implemented and many more can be found at the following site: https://securitytrails.com/blog/mitigating-ssh-based-attacks-top-15-best-security-practices
This is one of the oldest and most popular ways to obscure the SSH service. Why?
Because by default, SSH comes listening on port 22, which is widely known among attackers and security tools/port scanners that launch brute force attacks against it. While this is considered security by obscurity, it helps eliminating lots of noise on port 22.
Edit your SSH main config file:
nano -w /etc/ssh/sshd_config
Search for: Port
Then set it to something different than 22, like:
Port 899
Apart from having the port set to 22 by default, SSH servers come also with root login allowed on most Linux and Unix operating systems.
This allows anyone to connect to port 22, and use the root user as default, and then launch a ton of brute force attacks against your public server IP.
If you have password authentication enabled on your SSH service and your root password is weak, chances you are going to get hacked are pretty high. That's why disabling root login is one of the oldest and most used techniques to avoid system compromise on fresh OS installations.
You can check this out by leaving the SSH installation by default,parse the /var/log/secure file and see how many brute force attacks you will receive within a few hours- you will be surprised.
Even if you are using strong passwords, it's always recommended to disable root login and use a primary SSH user instead, so then if you need to gain root access you can do it using su command if required.
Edit SSH main config file:
nano -w /etc/ssh/sshd_config
Then search for the "PermitRootLogin" variable and set it to no:
PermitRootLogin no
If it is not present, add the AllowUsers variable to the file, and set your allowed users there:
AllowUsers yourusername
What if you need root access from certain IPs? Is there any way to disable root access for all IP address and only allow specific ones?
Yes, it can be done by adding the root users and IPs inside the AllowUsers line, as you see below:
AllowUsers yourusername [email protected]
In this case, we are allowing SSH access to the system user sectrails9, and also to the root user coming from 192.168.1.110 IP address.
If you are not able to set an ssh-key and still need to use login passwords, or, if you decide to use a passphrase on your keys, then make sure to use strong character combination.
Try to include:
Uppercase & lowercase letters
Symbols.
Numbers.
Up to 8 characters if possible.
Avoid using:
Dictionary-based words.
Personal birthday and anniversary dates.
Family and pet names.
Following these tips will help you to set a strong password/passphrase and avoid getting hacked when a brute force attack is happening.
Another good way to protect against brute force attacks is to set a low limit for the times an attacker can try to login with a failed password. MaxAuthTries variable can help you to mitigate this kind of attacks.
nano -w /etc/ssh/sshd_config
Search for MaxAuthTries.
Set it to 3, as you see below:
MaxAuthTries 3
After applying one of these ways, I no longer noticed "sshd: [accepted]" which means that now the server is safe from ssh attacks.
It should be emphasized that these types of attacks are common to almost all servers, so they may not be considered targeted attacks, although they may be, say, if one intends to harm a certain number of masternodes in the network.
This article is intended to draw attention to all masternode owners who did not know about this to protect their servers.
Now when you know all this, you can join most promising blockchain with more than 40 use cases, two coins, fantastic team: https://telosgreen.org
