Security. Adds config option -rpcipcmds to enable filtering which RPC commands can be called per client IP. #2864

pull dan-da wants to merge 2 commits into bitcoin:master from dan-da:master changing 3 files +78 −1
  1. dan-da commented at 7:17 AM on July 29, 2013: none

    This patch enables one to configure a whitelist of RPC commands that can be called for each allowed client IP.

    Let's look at the motivating use case for this feature. Consider a website that accepts bitcoin payments using the bitcoind API directly. The webserver and bitcoind are on separate servers. It is desirable that the webserver be able to call getnewaddress() and gettransaction (or listtransactions). It is highly undesirable (security risk) that the webserver be able to call any of the send* commands or stop command, or probably others, especially because the public-facing webserver is the most likely target to be attacked and possibly compromised.

    At this point, let's not get distracted with a discussion about using hot wallets vs cold storage vs 3rd party API. Instead suffice to say that the website has a need to do this, but desires to be as secure about it as possible.

    It is also possible to envision more complex scenarios with various client IPs, each with differering requirements / permissions, or all the same, as in a pool of frontend webservers.

    Okay, so -rpcipcmds to the rescue. Now the site administrator can configure bitcoind to only allow desired RPC calls from the webserver IP. Any other command results in "Method not allowed for client IP." json-rpc error.

    ./bitcoind --help | grep rpcip -rpcipcmds=<ip>,<cmd> Allow only specific commands from specified IP address. <ip>,<cmd1>,<cmd2>,<cmd3>...

    Example bitcoin.conf usage:

    rpcallowip=192.168.2.200 rpcipcmds=192.168.2.200,getnewaddress rpcipcmds=127.0.0.1,getnewaddress,sendtoaddress,getinfo,stop,help

    Implementation Notes:

    1. If an IP is allowed with rpcallowip but does not have an rpcipcmds entry then all commands can be used.

    2. WildCards in IP are accepted.

    3. Works with single command invocation and also batch invocation.

    4. For batch invocation, all commands are checked before any command is called. So all or nothing.

    5. Some might find the syntax a little funky. I considered using &lt;ip&gt;:&lt;cmd&gt; format, one per line, but rejected it because it requires specifying the same IP over and over. The CSV format enables &lt;ip&gt;,&lt;cmd&gt;,&lt;cmd&gt;,&lt;cmd&gt;... per line and is easy to read/grok and to parse. So that was my thought process.

    6. This is my first bitcoind modification effort, and my first ever github pull request. Also, I am not a networking expert, and my C++ is very rusty. It is likely something could have been done better, code or pull request does not meet standards, etc. If so, my apologies in advance. The patch meets my needs so far, and I felt I should contribute it in case it can benefit others. Feel free to re-work, re-write etc as necessary.

    7. -rpcipcmds is kind of hard to read. I originally called it rpcallowipmethods. But that didn't format nicely with the other commands in the help. This does.

    Testing:

    • Has been briefly tested with both single and batch invocation from localhost as well as a remote IP. Tested with IPv4 addresses only.
    • I did not create a unit test for it. Maybe could test with localhost.... remote IP seems hard.
  2. add rpcipcmds config option to filter which rpc commands can be called by clients, per IP 8a37181fb5
  3. -rpcallowmethodsforip --> -rpcipcmds in comment text. 716031385b
  4. BitcoinPullTester commented at 8:10 AM on July 29, 2013: none

    Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/716031385b45db9448a24718931e72a7f405e7ed for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

  5. jgarzik commented at 2:24 PM on July 29, 2013: contributor

    This adds a poor layer of security on top of an RPC layer that we already recommend to not be exposed to the public Internet. Even seemingly harmless RPC commands might stress the wallet and delay other RPCs commands, hold important locks, etc.

    If you want to do this, the best suggestion is to create a proxy on top of bitcoind, much like a pool server (which is nothing but an HTTP proxy).

  6. dan-da commented at 6:01 PM on July 29, 2013: none

    @jgarzik Thanks for the suggestion. If core devs don't want the patch, no problem. I am curious where this recommendation is to not expose RPC layer. I don't see it on the wiki jsonrpc pages, <a href="https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list">here</a> or <a href="https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%29">here</a>. Can you provide me a pointer? thanks.

  7. gavinandresen commented at 5:13 AM on August 15, 2013: contributor

    Closing. I updated the <a href="https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%29">JSON-RPC wiki page</a> with a warning about exposing the RPC port.

  8. gavinandresen closed this on Aug 15, 2013

  9. IntegralTeam referenced this in commit 5e865f9c8a on Jun 4, 2019
  10. DrahtBot locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-05-02 18:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me