7

I'm making first, rough concepts of some ideas for bitcoin-enabled services I have in mind.

One thing that I wonder is, is there a best-practise approach on running bitcoind on another server that acts as backend for a particular other server?

I thought of something like that:

I have a vServer A and a plain and simple PHP-Webspace at another host B.

A runs my bitcoind-deamon and only allows RPC-calls from Bs IP.

B makes its RPC-calls to A in a server-proccess which was not triggered by a client/website-visitor.

How safe would you ensure such a scenario? Is it possible that nodes, connected to my vServer A, identify the servers purpose from the transactions and try to attack him?

Even if they do, they would have to use a MiM-attack, because A only accepts Bs IP.

What else can I do to make the communication more secure? HTTP-Auth, SSL?

Improve this question

3 Answers 3

Reset to default
3

Is it possible that nodes, connected to my vServer A, identify the servers purpose from the transactions and try to attack him?

Yes, if they can see enough of the network, they can figure out whether you are originating a transaction or just passing it on. It's easier to figure out you're running RPC through a port scan, though.

There are ways to prevent a port scan from finding this, like using iptables (Ctrl-F 'except'). Be careful, because just using DROP will still tell attackers that there's something special about that port.

Improve this answer
1
  • Thanks for your tipp (: I'll wait a little bit longer for other answers before marking yours as solving
    – Gundon
    Jan 26, 2013 at 20:49
4

If you have SSH access on both machines you can simply create an SSH tunnel from machine B to A and forward port 8332 through it. That way the behavior is just like it would be if bitcoind were installed on both machines, the traffic between the two machines is encrypted with SSH and bitcoind does only have to listen to the loopback interface and would not be accessible from the network.

Improve this answer
3
  • Doesn't bitcoind natively speak SSL ?
    – David
    Feb 2, 2013 at 11:24
  • Yes it does but you'd still have to open the port to the network.
    – cdecker
    Feb 2, 2013 at 11:34
  • 1
    I don't see how a SSH tunnel really improves security in that case then. Additonnally I found tools like stunnel to be quite unstable and would, in the general case, avoid adding moving parts to a server setup unless they're absolutely required.
    – David
    Feb 2, 2013 at 13:52
3

I understand the initial logic to put the bitcoind & wallets onto a separate server, but think about it... if your webserver becomes compromised, then it doesn't matter where your bitcoind is.. it is also compromised.

Example; Bitcoind is on server A, webserver is on server B. webserver B sends requests -> to bitcoind server A . . replies -> back to webserver A.

Thus, if I compromise your websever B, I can tell it to send a message back to the bitcoind server saying sendtoaddress [myhackeraddress] and that's it. Funds gone.

Improve this answer
3
  • 1
    That is partly true. But it can be further protected.. If I only create a specific set of commands in my own interface which is the only way for both servers to communicate to each other, the attacker can also only use these. Although you are right: Most websites would need to support something like makeTransaction(amount, from, to)
    – Gundon
    Sep 6, 2013 at 13:17
  • 1
    @Gundon brings up a good point ~ you could setup the bitcoind server to only accept a predefined range of allowable rpc calls, like: getbalance..etc.
    – ManreeRist
    Sep 7, 2013 at 0:46
  • 1
    And if time is not critical and it is okay to only make all transactions once a day, you could also password-protect specific rpc-calls. If you write a wrapper on the bitcoind-server that could also be done per user and the password wouldn't need to be stored on your public server
    – Gundon
    Sep 7, 2013 at 9:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.