Security: remove or restrict `rpcbind` #18105

According to public internet scan data, approximately 10% of Bitcoin nodes listening on 8333 also have their RPC port misconfigured to listen on 0.0.0.0. There is no way that this can be used safely which does not involve plaintext credentials being transmitted across the internet, especially since the complete removal of rpcssl. If this is desirable, proxying the socket through nginx with SSL is a viable alternative that does not require listening publically.

The rpcbind option should either be restricted to allow for only single definitions of a host, or removed entirely to only permit binding to localhost for the management interface.

The 10% figure is extremely worrisome, I wonder how much of it is due to people copy and pasting configuration guides from the internet? (e.g. https://ma.ttias.be/enable-the-rpc-json-api-with-password-authentication-in-bitcoin-core/ )

It is somewhat unfortunate because exposing rpcbind to a local, physically secure network or via things like wireguard are both fairly reasonable things to do.

Perhaps renaming the option to something like insecurerpcbind= might be effective?

Alternatively, one could add an unauthenticated command "shutdown" to the rpc that allows a remote party to trigger the node to turn off and refuse to restart (e.g. creating a file called YOUR_RPC_PORT_IS_NOT_SECURE and refusing to start while that file exists) whenever a wildcard rpcbind is used, so if you fail to secure it at least some whitehat could come cleanly shut you off before something worse happens...

Or, for a less nuclear alternative, instead of shutting down: triggering a periodic error log (and rpc status warning) "ERROR: Your RPC is not secured against connections from <triggering IP>."

I think this has been solved by luke in #14532 , no?

What versions of Bitcoin Core are the 10% running?

@MarcoFalke

99  User Agent: /Satoshi:0.18.0/
84  User Agent: /Satoshi:0.17.1/
38  User Agent: /Satoshi:0.18.1/
19  User Agent: /Satoshi:0.19.0.1/
15  User Agent: /Satoshi:0.18.99/
2   User Agent: /Satoshi:0.19.99/

Filtered for just modern versions. #14532 makes it harder to misconfigure, granted.

@wpeckr Thanks a lot for opening this issue. If 10% of our public node users are exposing their RPC port we're doing something wrong :)

This is something I've been worried about for quite a while (recent examples: #17156 (comment) + #17742 (comment) + correspondence with security@ when reporting various RPC issues (incl. pre-auth)).

Good to finally have this quantified: that helps getting the appropriate level of attention to the issue :)

May I ask what data source you used to arrive at that the 10% figure? It would be nice to have a public reference to point to in RPC security discussions.

Also, if anyone has aggregated zmap or masscan results for portscans for a.) port 8333 vs. b.) port 8332 (RPC port) would be very interesting too.

Unless you want to do it yourself, you're stuck with finding someone who has massscan results you can filter, so it's hard to reference a distinct and repeatable source. shodan.io is typically a useful resource for this sort of thing, but the information about port 8332 in particular is very poor and obviously incomplete.

Digging around, there's a rather unfortunate number of high ranking google results with very incorrect information about how the interface works, and giving poor advice about it. These date from after #14532, so as a response to the restriction being added people have made instructions to work around it.

• https://ma.ttias.be/enable-the-rpc-json-api-with-password-authentication-in-bitcoin-core/

  Tells users how to set rpcallowedips to wildcard.

• https://bitcoin.stackexchange.com/questions/87943/unable-to-bind-any-endpoint-for-rpc-server

  The same.

• https://www.dosystemsinc.com/blog/full-node-installation

  The same.

and so forth.

One potential solution mentioned would be to allow only a /24 for allowedips, which would cut the amount of access down significantly and allow for use cases like internally routing with a VPN. This doesn't completely mitigate the issue of binding the socket globally however, as there's still pre-auth pre-check attack surface.

remove or restrict rpcbind

The rpcbind option should either be restricted to allow for only single definitions of a host, or removed entirely to only permit binding to localhost for the management interface.

I find these suggestions about RESTRICTING interesting especially after reading your comments in the only 2 pull requests that you have reviewed in this repository in which I was author.

Filtered for just modern versions. #14532 makes it harder to misconfigure, granted.

If some user can use a wrong configuration based on his research, we can't really do much about it. Maybe document it in security best practices?

This issue is unlikely to be fixed in Bitcoin Core. We'll close for now, but feel free to open another issue or pull request with a fix.