Separating web server and bitcoin server from a security POV

[pixelglow]

So I'm thinking of setting up a bitcoin service and thinking through some of the security models.

Method #1. Put both the web server and bitcoin server on the same box. The box will then be open to port 443 (HTTPS) and port 8333 (Bitcoin protocol). The web server will access the bitcoin server using JSON-RPC internally on port 8332. Typically there will be SSH access to the box in order to update software etc.

Method #2. Put the web server and bitcoin server on separate boxes. The web server box will be open to port 443 (HTTPS) and the JSON-RPC port 8332. The bitcoin server will be open to port 8332 and 8333. Typically there will be SSH access to both boxes.

What are some of trade-offs involved here?

I'm not sure that using separate boxes is all that secure. After all you're exposing the internal JSON-RPC traffic to outside the box, and if a hacker somehow could send RPC commands to the bitcoin box, he could cause it to withdraw all its bitcoins to his own account. On the other hand, using a single box means that if the hacker gets root access to it e.g. through SSH, he can basically do anything, but then surely he would target the more import bitcoin server instead?

Cheers, G.

[just_someguy]

Do you need to send and receive? If you don't need to send you don't need a bitcoin connection at all. Pre generate the keys and lock all but the public portion in a safe. Use blockexplorer to check balances.

If you need to send and receive use the same method as above for receiving. Accept/generate sends in your app server database.
Have your bitcoin installation somewhere else that periodically query your app server for withdrawal requests but have them unconnected at all other times.
Download the send list your bitcoin installation and have a script that translates the request to the local rpc server. Using this method bitcoin rpc never has to be opened up beyond the loopback address.

If you suspect something nefarious has happened on your site just don't run the send script until you investigate.
The bulk of your btc can be left offline and loaded on to your send machine as needed.

[riush]

There's also the option of running 2 bitcoinds, one communicating with the network, and relaying transactions to the second, the second being used only by the application, not connecting to the network itself.
That way if there were a remote exploit in the bitcoin networking code, an attacker wouldn't immediately have compromised the wallet-holding bitcoind.

But again, if the first one is exploited, its reasonable to assume an attacker might exploit the second bitcoind the same way from there; just one more step..

[pixelglow]

How do you relay transactions from one bitcoind to another?

[just_someguy]

Check out the rpcconnect option in the configuration file:
https://en.bitcoin.it/wiki/Running_Bitcoin#Bitcoin.conf_Configuration_File

I would still strongly recommend not working directly against a live bitcoin instance unless you absolutely have no choice.

[jlp]

Do you need to send and receive? If you don't need to send you don't need a bitcoin connection at all. Pre generate the keys and lock all but the public portion in a safe. Use blockexplorer to check balances.

If you need to send and receive use the same method as above for receiving. Accept/generate sends in your app server database.
Have your bitcoin installation somewhere else that periodically query your app server for withdrawal requests but have them unconnected at all other times.
Download the send list your bitcoin installation and have a script that translates the request to the local rpc server. Using this method bitcoin rpc never has to be opened up beyond the loopback address.

If you suspect something nefarious has happened on your site just don't run the send script until you investigate.
The bulk of your btc can be left offline and loaded on to your send machine as needed.

This sounds like an excellent approach.  However, how does one pre-generate addresses and keys?

Also, I would need to use testnet coins while I'm developing and testing.  BlockExplorer (http://blockexplorer.com/address/mudBLTzFRz4o17Y9CbaWRB9Qr8BkFeYiYj) and Blockchain (https://blockchain.info/q/addressbalance/1EzwoHtiXB4iFwedPr49iywjZn2nnekhoj?confirmations=6) do not seem to work with testnet addresses.  Is there a service that does work with testnet?

[Sukrim]

BIP32 for generating addresses...

[jlp]

BIP32 for generating addresses...

Thanks for your suggestion.  I read https://bitcointalk.org/index.php?topic=406386.0, and it sounds complicated and confusing.  User "fbueller" spread FUD (Fear Uncertainty and Doubt) and I don't even understand fbueller's comment nor most of the comments.  It seems like it can take a long time just to figure out if this is the right approach, no?

Even if I'm able to figure out BIP32, is there a service like Blockchainfo or Blockexplorer that works with testnet addresses?

FYI, I think Bitcoin adoption would be much more widespread if it wasn't so complicated and insecure, which adds to the complexity:  http://www.ideaexcursion.com/2013/09/18/developing-against-bitcoind/

[fbueller]

I don't see how my post in that thread could be misunderstood, or mislabed as FUD. Or why it's being brought up here, as BIP32 specs have nothing to do with how you set up your server?

[jlp]

I don't see how my post in that thread could be misunderstood, or mislabed as FUD. Or why it's being brought up here, as BIP32 specs have nothing to do with how you set up your server?

Sorry, it if came across as insulting.  It wasn't mean that way.  I was replying to Sukrim's suggestion of using BIP32 for my server.  You wrote:  "People would freak if they had sent coins to an address derived from these scripts but the key wouldn't import in a client eventually....If your code/bytes get implemented elsewhere the problem would be widespread, and cause a lot of fuss for those people."  To me, this did not come across as a big endorsement of BIP32.  Also, because I didn't understand the technical details of your comment and the other postings on that thread and because of comments as such as "The testnet version strings are problematic..." and "...it's awfully ambiguous.", I felt FUD about BIP32.

[fbueller]

Cool, no worries just wanted to see if I could clear anything up!

All we were discussing referring to is the appearance of the first few characters in encoded in the key, but very few wallets support BIP32 at the moment, unfortunately.