I wouldn't mix wallet holders and external networked based systems
external networked - btc systems taking part in the external block change or mining (basement heaters)
NO PRIVATE KEYS YOU FOOLS - these machines are playing fast on the dirty internet. Assume that the feds or some other smart enterprising organization or individual could own these at most any given time
block-chain participation - serious btc geeks should consider priding themselves on the network capacity they can donate to the cause. This is the perfect space for VPS solutions. Here I like Linux based simple machines. Bandwidth and disk are cheap. You need minimal processor to host network connections to the internet for simple block-chain exchange. I have two full time block chain nodes that average 64 connections at any time. I feel that btc adoption will be better when new client updates to the chain can happen faster. No keys on these systems you fools!
run the bitcoind process as a user with no access to the rest of the system. on NX based systems create a user named, "bitcoind," and have it run the process. Make sure that this user can't login to the system and has throttled back permissions on everything. <-- that keeps a bitcoind overflow attack limited to the areas the, "bitcoind," user has access to (unless there is a local exploit... for another time).
mining - there is absolutely no reason to have a key on a system taking part in group mining (ask me about personal mining another time). The payout from the group should be directed to an address whose key is held in the following class of btc infrastructure.
wallet holder (private key storage) - systems holding private keys for btc addressees
these systems can't communicate to the dirty internet. Alter the config to connect to your trusted systems taking part in the block-chain exchange (see first class of the btc infrastructure above).
wallet holder - consider vmware based Linux solution with full disk encryption. Only boot it up once in a while to repopulate the block-chain and verify balances (as needed). Back it up regularly (if you loose them you loose your keys, (unless you're backing those up on solid state media in a bank lock box), and loosing your keys means loosing those btc forever!)
by having kernel based full disk encryption you are automatically protecting the data at rest. It is only exposed at run time so consider running these vmware images on a trusted machine (not the one you use to lurk in the dirty parts of the internet)
Topic: My tips to secure external bitcoind (Read 2517 times)
good stuff, except they should have known this before they set the stuff up, hell, i am a nobody when it comes to hosting stuff and web dev, and i knew this. that only leaves 2 possibilities, they run for only profit and don't give a shit, or they are really just very very lazy and don't give a shit.
And you may also want to mention keeping everything locked up.
And you may also want to mention keeping everything locked up.
1. Do not use VPS or Cloud hostings - only pure hardware.
VPS and Cloud hosts have several ways to get staff login to your server without a password and without rebooting server.
But even on pure hardware there is always a way to reset a root password when staff have access on console. Because of this:
2. Keep your wallet on crypted partitions.
Use kernel-level partition encryption LUKS on Linux and ELI on FreeBSD.
When server crashed or rebooted, on next boot crypted partition can not be mounted without entering a password.
VPS and Clouds provide a theoretical fault-tolerance and safety of your data. So when you use a stand-alone server there is always small chance that HDD can be damaged causing loosing a wallet. So you need a backup to external host. If external backup host in a same DC, the chances of loosing both at ones - main and backup server - are high. So...
3. Do not keep main bitcoind host and backup host in a same datacenter.
You also need to be sure your backups go through secure channel, So
4. Use secure protocols to make an external backup. Such as SSH (scp).
Even if you backup your data via secure protocol, there always a chance that someone will get into the backup server and steal them. If you do not want to complicate the backup server setup:
5. Encrypt backup files on creation with gpg-like standard unix utility. And then send them to backup host via secure channel.
This will let you use cheap untrusted VDS and Cloud services for backup purposes.
And finally, you have to restrict most ways to get your hosts to be compromised.
6. There must be no applications running that listens network except bitcoind and sshd on main server, and sshd only on backup server.
PS. I don't say about complex passwords and pubkey ssh authorization, I assume people understand this. Also you may consider restrict ssh access by IP. But dont try too hard, you can restrict yourself
VPS and Cloud hosts have several ways to get staff login to your server without a password and without rebooting server.
But even on pure hardware there is always a way to reset a root password when staff have access on console. Because of this:
2. Keep your wallet on crypted partitions.
Use kernel-level partition encryption LUKS on Linux and ELI on FreeBSD.
When server crashed or rebooted, on next boot crypted partition can not be mounted without entering a password.
VPS and Clouds provide a theoretical fault-tolerance and safety of your data. So when you use a stand-alone server there is always small chance that HDD can be damaged causing loosing a wallet. So you need a backup to external host. If external backup host in a same DC, the chances of loosing both at ones - main and backup server - are high. So...
3. Do not keep main bitcoind host and backup host in a same datacenter.
You also need to be sure your backups go through secure channel, So
4. Use secure protocols to make an external backup. Such as SSH (scp).
Even if you backup your data via secure protocol, there always a chance that someone will get into the backup server and steal them. If you do not want to complicate the backup server setup:
5. Encrypt backup files on creation with gpg-like standard unix utility. And then send them to backup host via secure channel.
This will let you use cheap untrusted VDS and Cloud services for backup purposes.
And finally, you have to restrict most ways to get your hosts to be compromised.
6. There must be no applications running that listens network except bitcoind and sshd on main server, and sshd only on backup server.
PS. I don't say about complex passwords and pubkey ssh authorization, I assume people understand this. Also you may consider restrict ssh access by IP. But dont try too hard, you can restrict yourself
Jump to: