Hardening masternode server

E

edificio

New member
Hello,

I'm really new to this, but I managed to set up my masternode on a VPS and it's running flawlessly (with the help of Tao's guide). I have enabled the firewall mentioned in the guide, but nothing else.

I'm a bit worried about security. I have found multiple websites telling me which commands to enter, to do "something" which will make my server more secure.

What I don't know is whether entering these commands will affect my masternode's operation. Also several of the commands require a reboot. As I understand it my node is put back to the end of the payment line if it goes off-line right? If I reboot, I just need to enter ."/dashd" on the server and "masternode start-alias LABEL" on my debug console to start it again, right?

The security measures I've been looking to implement is stuff like:
Hardining SSH
Limit su access to admin only
Improve IP security
PHP hardening

and multiple others.

First post, so can't post a link. But google "Security hardening on Ubuntu Server 14.04"

Should I just go ahead and plug in all the code from the website, after my next payment? Or will any of these security measures prevent my masternode from functioning?

Any help would be much appriciated! :)
 
Oh, and also what would be the consequence if my VPS was to be hacked? Would they get my masternode priv key?

Couldn't I just delete the VPS, send my dash to a new address and start a new node?
 
edificio said:
Oh, and also what would be the consequence if my VPS was to be hacked? Would they get my masternode priv key?

Couldn't I just delete the VPS, send my dash to a new address and start a new node?
Click to expand...

Hi & welcome to the community!

As long as you've followed Tao's guide and you remote start your Masternode from your wallet on your local machine then the concequence of your VPS being hacked is limited to the inconvenience of having to destroy it and build a new one. You won't lose your Dash and your MN priv key is only useful for Voting but once you destroy the MN then your voting rights are destroyed with it.

So basically, in answer to your question, your MN getting hacked is more of an inconvenience than anything... And you will go to the back of the queue for selection and payments which will cost you a payment.

Even though the downside to being hacked is limited it is still a good idea (and best practice) to harden any internet facing server.

As for going to the back of the queue - I'm pretty sure you can reboot your server and restart your Dash daemon without going to the back of the queue as long as you do so within a short period of time. For example, 10-15mins shouldn't be a problem, it's only if the network doesn't see your masternode active for an hour or more that you get bumped off the list and pushed to the back of the queue.

Only ever use the masternode start-alias LABEL command as a last resort, even if your MN daemon is running and you run this command your MN will be pushed to the back of the queue.

Hope this helps :)

Walter
 
Thank you!

That clarified a lot of things for me. It's really nice to know that even if I don't know how to secure my server fully, it's only an inconvenience.

I still do not know which server "hardening's" I can safely implement without blocking my masternode from the internet or something like that. Any thoughts?

Also, really nice that the masternode can be off-line for up to an hour! Didn't know that, great info :)
 
No problem, I'm not entirely sure about exactly how long the MN daemon can be offline for (it is documented somewhere) but in my experience up to 10mins has never been a problem.

Server hardenings are not a problem as long as you continue to meet the prerequisits for maintaining an active masternode which is:

Port 9999 open to ALL both inbound and outbound.

That's it. All of the server hardenings you mention are fine to implement on a MN server as long as you don't accidentally disable port 9999. Also be careful you don't 'saw off the branch you're sitting on' when hardening your masternode. It's very easy to lock yourself out remotely ;-)

Then you would have to connect via console VNC through your VPS provider's portal.

Regards

Walter
 
Okay I'm writing this as I go, hopefully it can help someone else harden their server without restarting their node several times because of errors (as I have ;))

I recommend you harden your server with a new masternode, or one that has just received payment - Because if you make a mistake you will be put to the back of the payment line if you go off-line for about 50-60 min.

I tried upgrading to version 16.04.1, but ended up not being able to connect my masternode. I'm sure it's possible to upgrade, but I couldn't figure it out. So I'm sticking with 14.04.5.

Link to the site I used: https://blog.mattbrock.co.uk/hardening-the-security-on-ubuntu-server-14-04/

All of the following is done in puTTY:

SSH hardening
I didn't want to disable root login from SSH completely, because I wanted to use puTTY.
I could, however, use a different port than 22 to prevent autonomous hacking attempts on the default port.

Login to your server as root.
Start off by allowing your new port (Below port nr. 1024) through your firewall (ufw):

"ufw allow YOURPORT/tcp"

Assuming you have joe installed run:

"joe /etc/ssh/sshd_config"

Look for somewhere that says "port 22", and change it to "port YOURPORT"

ctrl+K+X to save

Now run your new settings:

"service ssh reload"

Leave your current puTTY session open and start a new session. If you can successfully login with your new port, you can safely close your first session (Thanks to UdjinM6 for correction)


Improving IP security
Run
joe /etc/sysctl.d/10-network-security.conf

At the bottom of the conf file add the following:

"
# Ignore ICMP broadcast requests
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Disable source packet routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# Ignore send redirects
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Block SYN attacks
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 5

# Log Martians
net.ipv4.conf.all.log_martians = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Ignore ICMP redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

# Ignore Directed pings
net.ipv4.icmp_echo_ignore_all = 1
"
ctrl+K+X to save the conf file.

Now enter

"service procps start"

To load the new rules.

I'm gonna be honest, I really don't know that any of these do :) Maybe someone else can clarify?
I can however confirm that it does not interfere with node operation.


There is a lot of other stuff on the site, including DDoS protection. But only if you have Apache installed, which is if I understand correctly, only if you want to host a webpage.

If I left something crucial out, which I most likely did, or if I made a mistake, please let me know :)
 
Last edited:
edificio said:
...
Try logging out and logging in at port 22, it should deny your request. Then log in with your new port.
...
Click to expand...
Instead of login out just start new session with new port to verify that you are able to login with new settings. You should log out only if you were able to login in new session, otherwise you might never be able to login to your own server again and will have to rebuild it from scratch (or restore from backup if you have one).
 
You must log in or register to reply here.
Back
Top