Best ways to secure your masternode

N

noob

New member
Mine is on n ec2 instance. I've blocked every port except 9999, installed fail2ban, use 2fa, SSH from only my ip with keypair. What else should we be doing to prevent hackers or DDOS attacks?
 
Make sure darkcoind is running as a non-privileged user.
Prevent root from logging in with ssh. Your already probably covered for this but just an extra precaution.
Have your coins on a different VPS and start your Masternode remotely via this other VPS.

Work through http://www.puschitz.com/SecuringLinux.shtml and apply relevant sections.
 
Do we need to put the wallet on another VPS? How come it can't be hosted on the machine itself? If the wallet is encrypted surely the hackers can't do a lot with the wallet? I've got a node setup running ununtu but I'm seriously thinking about setting up on Amazon cloud services.
 
You don't need to do any of the above but each provides an extra layer of security. You can host the wallet and 1,000+ coins on the same server but if it gets compromised then you are relying on the wallet encryption to protect your coins. If a hacker got your wallet then they would no doubt try an attack on it although I'm not sure about how successful this would be. How about someone putting a wallet out on the Net with coins in it to test out wallet security?

There may be traces of your wallet password on the server when you open it, such as bash history (yes, you can delete your bash history to avoid this). Maybe an attacker gains access to your server, finds the encrypted wallet but then puts some monitoring code on your server to get your password when you open it without you knowing.

I would like Evan to make it compulsory to have the Master Node started remotely so that they will not be targeted by hackers.
 
Hmm. That's interesting. I guess you can't have the 2 nodes virtual on a physical box... If the physical box got hacked it's not sandboxed is it?

I'm guessing to start the coind you'll use ssh from the wallet server? What's stopping the hacker from realising the coin.dat file is hosted elsewhere and targeting that box?
 
The hacker will only know the IP address of the Master Node. If you had two virtual servers on the one physical box then that should be OK as they should not be able to find out the IP address of the physical box or other virtual server - assuming you had configured it that way.

There is a guide on remotely starting Master Nodes which is how I got mine configured https://darkcointalk.org/threads/remote-masternode-guide.410/

I'm not aware of any information leading back to the other VPS box where you started it from so they should not be able to target it.
 
You can also harden your SSH login even further by using Multiple Authentication Methods!
I just added this to my Masternode myself.
If you already have Keypair Auth you just need to:
1. follow this guide (posted on the Bitcointalkthread by hartvercoint) http://www.howtogeek.com/121650/how...gle-authenticators-two-factor-authentication/
2. Add this to your sshd_config: "AuthenticationMethods publickey,keyboard-interactive"
3. restart ssh service (keep a ssh connection open to prevent locking yourself out while you test this!!!)
If you now try to login via SSH you will need:
1. KeyPair
2. Password
3. 2FA code
 
donho said:
You can also harden your SSH login even further by using Multiple Authentication Methods!
I just added this to my Masternode myself.
If you already have Keypair Auth you just need to:
1. follow this guide (posted on the Bitcointalkthread by hartvercoint) http://www.howtogeek.com/121650/how...gle-authenticators-two-factor-authentication/
2. Add this to your sshd_config: "AuthenticationMethods publickey,keyboard-interactive"
3. restart ssh service (keep a ssh connection open to prevent locking yourself out while you test this!!!)
If you now try to login via SSH you will need:
1. KeyPair
2. Password
3. 2FA code
Click to expand...

What a coincidence!! ;) I found the same tutorial but was pulling my hair until I found your post. I just have one problem, I'm on EC2 amazon, so I have a PEM file (key pair)

I... ssh -i xxx.PEM [email protected]... google authenticator ask for token, then asks for password. I dont have one! I thought that was the whole idea behind encrypted PEM files. I dont get it. I have no clue what to put in password, tried the PEM file, but obviously its not that.

Suggestions?
 
yidakee said:
What a coincidence!! ;) I found the same tutorial but was pulling my hair until I found your post. I just have one problem, I'm on EC2 amazon, so I have a PEM file (key pair)

I... ssh -i xxx.PEM [email protected]... google authenticator ask for token, then asks for password. I dont have one! I thought that was the whole idea behind encrypted PEM files. I dont get it. I have no clue what to put in password, tried the PEM file, but obviously its not that.

Suggestions?
Click to expand...
1. login to your server via ssh
2. sudo passwd ubuntu (i guess thats your user?)
3. create a password for ubuntu
 
donho said:
1. login to your server via ssh
2. sudo passwd ubuntu (i guess thats your user?)
3. create a password for ubuntu
Click to expand...

Mind laying out the commands for point 3 :tongue: ... ?

(I thought the whole point of the PEM files was for this not to have to happen)
 
All software has its flaws and we are always applying security updates to fix them, however, this is after the event of someone having something bad happen to them and reporting it and a security update being issued.

We need to prepare for the event of darkcoind having a security flaw and someone gaining access to the server as the user running darkcoind. To prepare for this possibility we need to:
  • Run darkcoind as a non-privileged user
  • Disable sudo access for this non-privileged user
  • Remotely start the Master Node from another server so that coins are never on the MN server
  • Ability to detect and alert that the server has been compromised
  • Harden the server
At the moment each Master Node has a red flag and banner shouting out to the Net 1,000 coins here come and get them if you can. Making it compulsory to remotely start the Master Node is a MUST so that Master Node operators are protected as much as possible. I can see from many posts that not many are remotely starting the Master Node and just risking it. This is bad for the darkcoin image if too many people lose coins through poor configurations.
 
FoldingTime said:
All software has its flaws and we are always applying security updates to fix them, however, this is after the event of someone having something bad happen to them and reporting it and a security update being issued.

We need to prepare for the event of darkcoind having a security flaw and someone gaining access to the server as the user running darkcoind. To prepare for this possibility we need to:
  • Run darkcoind as a non-privileged user
  • Disable sudo access for this non-privileged user
  • Remotely start the Master Node from another server so that coins are never on the MN server
  • Ability to detect and alert that the server has been compromised
  • Harden the server
At the moment each Master Node has a red flag and banner shouting out to the Net 1,000 coins here come and get them if you can. Making it compulsory to remotely start the Master Node is a MUST so that Master Node operators are protected as much as possible. I can see from many posts that not many are remotely starting the Master Node and just risking it. This is bad for the darkcoin image if too many people lose coins through poor configurations.
Click to expand...

I'm currently not running it as a non-privileged user, but have locked all ports except 9999 (sshport is restricted only to my ip). Key Pair + Pass + Time-based OTP is needed for ssh login. Bruteforce protection for the TOTP is enabled. fail2ban installed.
AND most importantly I would say, my 1000 DRK are not on this server but on another one.
So I guess I'm good to go, but will look into the non-privileged user just to make sure :)
 
donho said:
I'm currently not running it as a non-privileged user, but have locked all ports except 9999 (sshport is restricted only to my ip). Key Pair + Pass + Time-based OTP is needed for ssh login. Bruteforce protection for the TOTP is enabled. fail2ban installed.
AND most importantly I would say, my 1000 DRK are not on this server but on another one.
So I guess I'm good to go, but will look into the non-privileged user just to make sure :)
Click to expand...
Sounds like a good config, but if darkcoind was compromised then the attacker would have root access and own your server. Your coins should be safe as long as you have not introduced pathways to your other server with the coins on. By this I mean you have not put your other server in /etc/hosts and not done any silly ssh keys to jump from one box to the other.
 
You must log in or register to reply here.
Back
Top