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

<p>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.  </p>

<p>There are ways to prevent a port scan from finding this, like using <a href="http://www.cyberciti.biz/faq/iptables-block-port/" rel="nofollow noreferrer">iptables</a> (Ctrl-F 'except'). Be careful, because just using <code>DROP</code> will still tell attackers that there's <a href="http://diaryproducts.net/about/operating_systems/unix/nmap_port_scanner_iptables_firewall" rel="nofollow noreferrer">something special about that port.</a></p>

CC BY-SA 3.0
2013-01-26T20:49:14.010Z
Thanks for your tipp (: I'll wait a little bit longer for other answers before marking yours as solving
Gundon
CC BY-SA 3.0
2013-01-26T07:27:22.287Z
2017-07-25T00:09:15.687Z
2017-07-25T00:09:15.687Z
Nick ODell
<p>If you have SSH access on both machines you can simply create an SSH tunnel from machine <strong>B</strong> to <strong>A</strong> 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.</p>

CC BY-SA 3.0
2013-02-02T11:24:42.533Z
Doesn't bitcoind natively speak SSL ?
David
CC BY-SA 3.0
2013-02-02T11:34:16.367Z
Yes it does but you'd still have to open the port to the network.
cdecker
CC BY-SA 3.0
2013-02-02T13:52:52.987Z
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
CC BY-SA 3.0
2013-02-02T10:40:00.533Z
2013-02-02T10:40:00.533Z
cdecker
<p>I understand the initial logic to put the bitcoind &amp; 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.  </p>

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

<p>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. </p>

CC BY-SA 3.0
2013-09-06T13:17:41.303Z
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
CC BY-SA 3.0
2013-09-07T00:46:43.237Z
@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
CC BY-SA 3.0
2013-09-07T09:53:59.990Z
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
CC BY-SA 3.0
2013-09-05T21:27:26.820Z
2013-09-05T21:27:26.820Z
ManreeRist
<p>I'm making first, rough concepts of some ideas for bitcoin-enabled services I have in mind.</p>

<p>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?</p>

<p>I thought of something like that:</p>

<p>I have a vServer <strong>A</strong> and a plain and simple PHP-Webspace at another host <strong>B</strong>.</p>

<p>A runs my bitcoind-deamon and only allows RPC-calls from Bs IP.</p>

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

<p>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?</p>

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

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

<security><bitcoind><json-rpc><services><server>
Is it safe to run bitcoind on another server
Gundon
# Is it safe to run bitcoind on another server

(Asked by: username_0 on 2013-01-25)

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?

**Tags:** security, bitcoind, json-rpc, services, server


---

## 3 answers

### Answer by username_1 on 2013-01-26. Score: 3 | Accepted answer

> 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](http://www.cyberciti.biz/faq/iptables-block-port/) (Ctrl-F 'except'). Be careful, because just using `DROP` will still tell attackers that there's [something special about that port.](http://diaryproducts.net/about/operating_systems/unix/nmap_port_scanner_iptables_firewall)

> **Comments:**
> **username_0**: Thanks for your tipp (: I'll wait a little bit longer for other answers before marking yours as solving  

---

### Answer by username_2 on 2013-02-02. Score: 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.

> **Comments:**
> **username_3**: Doesn't bitcoind natively speak SSL ?  
> **username_2**: Yes it does but you'd still have to open the port to the network.  
> **username_3**: 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.  

---

### Answer by username_4 on 2013-09-05. Score: 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.

> **Comments:**
> **username_0**: 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)  
> **username_4**: @username_0 brings up a good point ~ you could setup the bitcoind server to only accept a predefined range of allowable rpc calls, like: getbalance..etc.  
> **username_0**: 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  

---

