I started to learn onion-grater for the first time and I managed to make a profile for Bitcoin Core (tested on v0.17). It allows creating mainnet or testnet hidden service and discards private key to keep services ephemeral.
I’ve found it useful, hopefully others will to.
Awesome! Interested to have it shipped in Whonix by default? Please pull request here:
https://github.com/Whonix/onion-grater/tree/master/usr/share/doc/onion-grater-merger/examples
If so please consider add a comment on top naming you as maintainer with this with @qubenix Whonix user forum (or phabrictor) account.
I realized that this profile can be simplified, but I’m wondering what you think about it @Patrick.
This is how I’ve been running. Is it too permissive like this?
---
- exe-paths:
- '*'
users:
- '*'
hosts:
- '*'
commands:
ADD_ONION:
## {{{ bitcoind onion service
- pattern: 'NEW:(\S+) Port=(\S+),127.0.0.1:(\S+)'
replacement: 'NEW:{} Port={},{client-address}:{} Flags=DiscardPK'
## }}}
No opinion yet. Since you maintain this, please do as you think this can be best maintained.
I don’t see why this pattern is beneficial?
It is allowing services to be created to any port to be used instead of only 8333.
Ok, so the person wants to create a restest and testnet service, they would need to edit the config, or the config should use all the default ports, eg. 18333 for testnet.
But the default ports can be hardcoded, if a person uses a non default port, then they are already configuring the service diffferently.
My proposal is to implement all default ports patterns so the above can be avoided.
Of course the service is only reachable after port is opened on the firewall. But I think the control port should not allow all ports, only the whitelisted ports.
Seeing the examples
onion-grater/usr/share/doc/onion-grater-merger/examples at master · Whonix/onion-grater · GitHub
None is allowing all ports, only onionshare that has a huge range, but that is onionshare default to have that range and search for open ports.
bitcoind -help
-port=<port>
Listen for connections on <port>. Nodes not using the default ports
(default: 8333, testnet: 18333, signet: 38333, regtest: 18444)
are unlikely to get incoming connections. Not relevant for I2P
(see doc/i2p.md).
So the ports are: 8333, 18333, 38333, 18444
Any counter arguments to this?
Not from me.
## Maintained by: https://forums.whonix.org/u/qubenix <qubenix@riseup.net>
Revert simplify 40_bitcoind.yml · Whonix/onion-grater@9539d88 · GitHub?
Removed the maintained by qubenix, he has not been active since january and did not reply on time.
Did not put my name because I am using default configuration, there is no need to be dependent on me.
“Complicated” the ports to only use defaults instead of allowing any port to be used.
wait a little bit before merging, I’m correcting something
Good to go now.
Corrected the binding ports.
Bitcoind binds onions to: P2P_port + 1.
This is the request:
ADD_ONION NEW:ED25519-V3 Port=8333,127.0.0.1:8334
sudo netstat -tulnp | grep bitcoin
tcp 0 0 0.0.0.0:8333 0.0.0.0:* LISTEN 1564026/bitcoind
tcp 0 0 127.0.0.1:8334 0.0.0.0:* LISTEN 1564026/bitcoind
tcp 0 0 127.0.0.1:8332 0.0.0.0:* LISTEN 1564026/bitcoind
tcp6 0 0 :::8333 :::* LISTEN 1564026/bitcoind
tcp6 0 0 ::1:8332 :::* LISTEN 1564026/bitcoind
Mainnet;
The virtual port is still 8333, but they use a different binding port for onion.
Just saying this so it is easier to debug next time.
I did not choose/configure these ports, this are the default ports.
Thanks! Merged.
Ok, there is a problem with the current pattern.
Bitcoin onion-grater profile is only necessary if you want to listen=1 for incoming connections, this means relaying blocks on the p2p network.
Bitcoind does indeed start the onion binding port on 127.0.0.1:8334. This means that it isn’t reachable on $(qubesdb-read /qubes-ip):8334.
It would be reachable on that interface if the onion binding port was 0.0.0.0:8334 or the $(qubesdb-read /qubes-ip):8334, but the first option 0.0.0.0:8334 is better because it does not depend on knowing the qubes ip and updating it.
So if you want to listen for incoming connections, you need to set on the bitcoin.conf:
listen=1
## although this is the default binding address:port,
## it is necessary to set it for it to listen on multiple addresses
## if not set, only 0.0.0.0:8334 would be binded and the default
## bind address and port would not be used
bind=0.0.0.0:8333
bind=0.0.0.0:8334=onion
and opening external port 8334 on the workstation.
This also means that I need to update the onion-grater profile to overwrite the client add onion address with regex to match every address (0.0.0.0 and 127.0.0.01 should be modified to {client-address}). Something like (\S+), will test later.
You can test this is the case for example with nginx by listening on 127.0.0.1:82, only that address will be reachable and not the qubes ip and same port.
https://www.whonix.org/wiki/Onion_Services#cite_note-11
(I don’t really understand how to print the link and not the title of the page with discourse…)
Just like apache only listening on 127.0.0.1, its traffic needs to be redirected to the Workstation listening interface. The thing is that by default nginx starts with 0.0.0.0 (all interfaces).
And using sudo ncat -l 0.0.0.0 8334 -c 'ncat 127.0.0.1 8334' but that is just dumb and prone to mistakes of forgetting about it, better to set in the bitcoin.conf.
So yeah, changing the bitcoin.conf to bind=0.0.0.0:8334=onion is necessary.
And I believe it is reasonable for bitcoind default to 127.0.0.1 for onion connections and not 0.0.0.0, because it could leak server info, but not for Whonix, as it is isolated network with the Gateway.
Used the same pattern as 40_wayhay.yml
Note the first listening address 8333 is only necessary if you want applications to use that address. This is useful for qubes if you want to bind 8333 to another qube and have a pruned node on one qube and a full on another, without the need to set rpc for the other node, thus minimizing risks when possible.
So in the end, it is good to have 8333 always set because that is default bitcoind behavior that most applications will be expecting.
And the reason to set a different port for onion 8334 is:
Makes sense.
(Avoid Oneboxing for Anchored Links + Created Improve oneboxing for anchored links - feature - Discourse Meta just now. To discuss this further, would be best to post there or create a new forum thread here.)