Securing darkcoind on a live server?

[sgeos]

What steps should be taken to secure darkcoind on a live server that needs to send payment? I'm interested in the case of running something like a web app, but I suspect anyone running a masternode will face similar challenges.

As far as I can tell, if darkcoind is being used to automatically send payments, all of that machinery needs to be unlocked and running on your system. If anyone competent breaks in, you lose. Are there ways to secure a running copy of darkcoind, or is your last real line of defense preventing people from breaking in in the first place?

One architecture I have read about is splitting an app across two servers- a public facing app server and an internal payment server. The app server gets invoice addresses and payment status from the payment server, but it never actually touches any Darkcoin. The payment server provides invoice addresses, processes any outgoing payments and provides notification that payment was sent. In theory, either server can monitor invoice addresses for payment. If anyone hacks the app server to point to a different payment server, you are sad. If anyone hacks your payment server, you lose.

Also, backups need to be securely managed to prevent losing a wallet.

 

[sgeos]

I found an article that lists strategies for managing hot and cold wallets. The upshot is that it is safe to assume everything in a hot wallet will be lost in a breach. To limit losses, most of your holdings should be kept in a cold wallet that is periodically used to top off the hot wallet.

Everyone running a masternode should keep their 1000 DRK on a separate sever. Unless, of course, losing 1000 DRK is not a big deal.

 

[Propulsion]

It's also a good practice to have separate accounts that do not have access to each other.

For example user Cindy can SSH into the system.
User Barbara can control the daemon. Neither are privileged and neither can access each others processes.

 

[sgeos]

That makes sense. If Cindy uses certificates to SSH into the system, how worried do we need to be? If someone has the luxury of running a payment server on premises, could it a good idea to only allow root login from the physical console and disable su and sudo? Obviously this makes remote administration more or less impossible.

FWIW, I want to run a web app on the payment server localhost to manage payment processing. Also, I wonder if a Raspberry Pi would be a good fit for a dedicated payment server.

 

[Propulsion]

You never want to run as root. If possible you should try to run every process as an unprivileged user.

That would be neat to see a pi do that.

 

[sgeos]

It looks like people are actually using Raspberry Pis as secure air gap wallets. Pull the ethernet to do offline tasks and power it down when finished. Harder to hack but not impossible.