Enable SSH access from the Internet, Permanently until disabled again - Does not persist after reboot && Problems to remotely connect to Tor's Control Port

[bhafer]

Steps to Reproduce:

1. Open the configuration menu tool.
2. Select: Go to the configuration sub-menu
3. Select: Enable SSH access from the Internet
4. Check: Permanently until disabled again
5. Select: OK, and "press any key to continue"
6. Verify that the option now reads "Disable SSH access from the Internet"
7. Reboot the device

Expected Results: SSH is still enabled from the Internet

Actual Results: SSH is disabled after reboot

[bhafer]

Until this issue can be fixed, Is there a way I can perform ths action manually so that it persists after reboot? I can't figure out where the access is being restricted.

[radio24]

Hello bhafer
Thanks for bringing this bug to our attention. It seems that we screwed up with one if-statement in the menu-config file, which we will fix with some other stuff in the following days and push it to the GitHub repository so that it can be easily updated with entry 5 in the update and reset sub-menu.

To fix the bug on your system, do the following steps:

• Leave the TorBox menu by pressing ESC
• Execute nano menu-config
• Go to the sub-section which is called "#This disables / enables SSH access through Internet", search for "if [ $ENABLED_CHOICE = 1 ]; then" and change it to "if [ $ENABLED_CHOICE = 2 ]; then" (row number 667).
• Save the modified file with CTR-W and leave the editor with CTR-X
• Start the TorBox menu again with ./menu and repeat your steps to activate the permanent SSH access from the Internet.

[bhafer]

Thank you. That worked!

On a port-related note... And I apologize because I do not know where to open a support/forum thread...
How can I find information about accessing the control port on 9051?

I am not able to connect to 9051 with telnet from the nat/lan side, and I do not know what the password is, although I see a hashed value in torrc. Thank you, and if this is the wrong place to ask, I would appreciate being scolded towards the right direction. :-)

[radio24]

For what reason do you need port 9150? SOCKS v5 on TorBox is at port 9050 and at 9051 with destination address stream isolation (new at 9052, see under "Known problems and bugs" in the Blog article "TorBox v.0.4.0 released — welcome TorBox Wireless Manager!"). There is no password needed for these two SOCKS v5 ports. The hashed value in torrc is for the control port at 9051. Usually, it is unnecessary to change that password, but you have this possibility with entry 3 in the configuration sub-menu.

See also this FAQ entry to learn more about using TorBox’s SOCKS v5 proxy functionality.

[bhafer]

You are correct I mistyped the number! (Corrected) I am referring to this part of the torrc file:

ControlPort 9051
HashedControlPassword 16:XXXXXXXXXXXXXXXXXXXXXX

From windows cmd (on the LAN side), I get this:

$ telnet 192.168.X.1 9051
Connecting To rastorhost...Could not open connection to the host, on port 9051:
Connect failed

(Note that port 22 is successfully reachable.)
I am trying to reach the control port for sending commands like:
SIGNAL NEWNYM

Thank you

[radio24]

Could you please copy and paste all the SocksPort lines from your torrc?

[bhafer]

Certainly. Thank you.

## DON'T CHANGE THE FOLLOWING 15 LINES!
######################################################
## Configuration for TorBox

Log notice file /var/log/tor/notices.log
VirtualAddrNetworkIPv4 10.192.0.0/10
AutomapHostsSuffixes .onion,.exit
AutomapHostsOnResolve 1
TransPort 192.168.42.1:9040
#TransPort 192.168.43.1:9040
DNSPort 192.168.42.1:9053
#DNSPort 192.168.43.1:9053
SocksPort 192.168.42.1:9050
SocksPort 192.168.42.1:9052 IsolateDestAddr
#SocksPort 192.168.43.1:9050
#SocksPort 192.168.43.1:9052 IsolateDestAddr
DisableDebuggerAttachment 0
ControlPort 9051
HashedControlPassword 16:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

[radio24]

Ok... the problem is that, so far, the idea was that the control port is only used locally on the TorBox itself (for example, for statistics). If you want to use it from the LAN side, then let's try the following command:
iptables -t nat -A PREROUTING 3 -i $I_DEVICE -d $MY_OWN_IP -p tcp --dport 9051 -j REDIRECT

$I_DEVICE is the device of the LAN side
$MY_OWN_IP is dependent on from where you access 192.168.42.1 (wlan0/1) or 192.168.43.1 (eth0)

If you want to have it permanent (after rebooting the TorBox, but not after changing the configuration in the main menu), additionally, execute the following command:
sudo sh -c "iptables-save > /etc/iptables.ipv4.nat"

If you didn't change the hashed password, then it is still CHANGE-IT

With the next version, I will probably add the possibility to access Tor's control port from the client-side.

[bhafer]

I ran:
iptables -t nat -I PREROUTING 3 -i wlan0 -d 192.168.42.1 -p tcp --dport 9051 -j REDIRECT

But I still cannot connect from the lan:

$ telnet 192.168.42.1 9051
Connecting To 192.168.42.1...Could not open connection to the host, on port 9051: Connect failed

Iptables contains: (eth0 is the wan and wlan0 is the lan)

torbox@TorBox040:~/torbox $ sudo iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 585 packets, 72444 bytes)
 pkts bytes target     prot opt in     out     source               destination
   30  1560 REDIRECT   tcp  --  wlan0  *       0.0.0.0/0            192.168.42.1
  199 10348 REDIRECT   tcp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            redir ports 9040
    0     0 REDIRECT   tcp  --  wlan0  *       0.0.0.0/0            192.168.42.1         tcp dpt:9051
 1037 70373 REDIRECT   udp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 redir ports 9053
  275 25810 REDIRECT   udp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            redir ports 9040

Chain INPUT (policy ACCEPT 1540 packets, 106K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 31 packets, 3127 bytes)
 pkts bytes target     prot opt in     out     source               destination
   68  4734 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 96 packets, 7681 bytes)
 pkts bytes target     prot opt in     out     source               destination

[radio24]

Try
iptables -t nat -I PREROUTING 2 -i wlan0 -d 192.168.42.1 -p tcp --dport 9051 -j REDIRECT

[bhafer]

Sorry I can't be more helpful, but that still isn't working.

torbox@TorBox040:~/torbox $ sudo iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 625 packets, 75797 bytes)
 pkts bytes target     prot opt in     out     source               destination
   37  1924 REDIRECT   tcp  --  wlan0  *       0.0.0.0/0            192.168.42.1
    0     0 REDIRECT   tcp  --  wlan0  *       0.0.0.0/0            192.168.42.1         tcp dpt:9051
  281 14612 REDIRECT   tcp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            redir ports 9040
 1525  103K REDIRECT   udp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 redir ports 9053
  373 39667 REDIRECT   udp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            redir ports 9040

Chain INPUT (policy ACCEPT 2212 packets, 157K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 35 packets, 3891 bytes)
 pkts bytes target     prot opt in     out     source               destination
   75  5173 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 106 packets, 8824 bytes)
 pkts bytes target     prot opt in     out     source               destination

[radio24]

Did you try iptables -t nat -I PREROUTING 1 -i wlan0 -d 192.168.42.1 -p tcp --dport 9051 -j REDIRECT?
It would make sense because probably you data packages were caught by REDIRECT tcp -- wlan0 * 0.0.0.0/0 192.168.42.1

You could also try iptables -A INPUT -p tcp --dport 9051 -j ACCEPT, however this will open Tor's Control Port for everyone (who has the password). To limit it, probably iptables -A INPUT -i wlan0 -p tcp --dport 9051 -j ACCEPT would be better.

Unfortunately, I cannot test these possibilities by myself because I'm currently on the move.

[bhafer]

Thank you for all the help.
Haha. You read my mind!

I did in fact try these 2 together:

iptables -t nat -I PREROUTING 1 -i wlan0 -d 192.168.42.1 -p tcp --dport 9051 -j REDIRECT
iptables -A INPUT -p tcp --dport 9051 -j ACCEPT

Something else must be going on. I still get this from the lan:

$ telnet 192.168.42.1 9051
Connecting To 192.168.42.1...Could not open connection to the host, on port 9051: Connect failed

It also fails from the wan. But it works with telnet 192.168.42.1. 22

Here is the full iptables output in case it is helpful. I did not modify anything else except SSH access from Internet.

torbox@TorBox040:~/torbox $ sudo iptables -nvL
Chain INPUT (policy DROP 52 packets, 6881 bytes)
 pkts bytes target     prot opt in     out     source               destination
18641   12M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
    0     0 LOG        all  --  wlan0  *      !192.0.0.0/8          0.0.0.0/0            LOG flags 0 level 4 prefix "SPOOFED PKT "
    0     0 DROP       all  --  wlan0  *      !192.0.0.0/8          0.0.0.0/0
    6   370 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
  654 46842 ACCEPT     all  --  wlan0  *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 0
    1    52 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
    4   208 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:9051

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
   18  1080 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
   18  1080 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 0

Chain OUTPUT (policy ACCEPT 16212 packets, 12M bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
   14   560 DROP       tcp  --  *      !lo    !127.0.0.1           !127.0.0.1            tcp flags:0x14/0x14
    0     0 LOG        tcp  --  *      eth0    0.0.0.0/0            0.0.0.0/0            tcp dpt:53 LOG flags 6 level 4 prefix "SSH SHELL DNS-REQUEST TCP"
    8   538 LOG        udp  --  *      eth0    0.0.0.0/0            0.0.0.0/0            udp dpt:53 LOG flags 4 level 4 prefix "SSH SHELL DNS-REQUEST UDP"

torbox@TorBox040:~/torbox $ sudo iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 57 packets, 6657 bytes)
 pkts bytes target     prot opt in     out     source               destination
   10   520 REDIRECT   tcp  --  wlan0  *       0.0.0.0/0            192.168.42.1         tcp dpt:9051
    2   104 REDIRECT   tcp  --  wlan0  *       0.0.0.0/0            192.168.42.1
   57  2964 REDIRECT   tcp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            redir ports 9040
  290 19687 REDIRECT   udp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 redir ports 9053
   92  7194 REDIRECT   udp  --  wlan0  *       0.0.0.0/0            0.0.0.0/0            redir ports 9040

Chain INPUT (policy ACCEPT 454 packets, 30073 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 10 packets, 658 bytes)
 pkts bytes target     prot opt in     out     source               destination
   20  1524 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 29 packets, 2122 bytes)
 pkts bytes target     prot opt in     out     source               destination

[radio24]

Don't try PREROUTING and INPUT together. If PREROUTING alone doesn't work, try INPUT without the PREROUTING.
With port 22, we only used an INPUT command without any PREROUTING. Technically, that should be the right way because INPUT means "into the local device", whereas PREROUTING means "route the package directly to somewhere else".

[bhafer]

Even with the following rule alone and no nat rule, I could not telnet from the lan or wan.
iptables -A INPUT -p tcp --dport 9051 -j ACCEPT

[radio24]

Hmm... I'don't have any other idea right now, but will look into it in more detail in the next days.

[bhafer]

I think I found the problem... This rule is blocking connections:

torbox@TorBox040:~/torbox $ sudo iptables -t nat -nvL
Chain PREROUTING (policy ACCEPT 252 packets, 29118 bytes)
 pkts bytes target     prot opt in     out     source               destination
   65  3380 REDIRECT   tcp  --  wlan0  *       0.0.0.0/0            192.168.42.1

I deleted that rule and could connect. But I assume that is not the proper way to solve the problem. ;-)
So hoping you can advise?

Thanks for all your help!

[radio24]

My note to that rule is "Access on the box's own IP should be granted", and so far, that rule took care that clients could connect to TorBox (SSH, for example).

However, also here, that should be probably better an INPUT than a PREROUTING rule. I will check that out in the following days.

[bhafer]

I did a test. I deleted that rule and could not establish a new SSH connection even from the lan side. But existing connections continued working.
Thank you. I will wait for your advice.

[radio24]

Ok, we have to solve the problem from a different angle.
First, could you please check if you can locally access the tor control port (on the TorBox itself):
telnet localhost 9051

Then authenticate in telnet with your password. For example (see also "TC: A Tor control protocol (Version 1)"):
AUTHENTICATE "CHANGE-IT"

That should give you a 250 OK.

[bhafer]

Great. I was thinking along those lines as well, but telnet was not installed on Torbox.
So, I ran this:
torbox@TorBox040:~/torbox $ sudo apt-get install telnet

Then, I got this: (No I never changed the control port password in Torbox)

torbox@TorBox040:~/torbox $ telnet localhost 9051
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
AUTHENTICATE "CHANGE-IT"
515 Authentication failed: Password did not match HashedControlPassword *or* authentication cookie.
Connection closed by foreign host.

But then I did change it (to "CHANGE-IT"), and got this:

torbox@TorBox040:~/torbox $ telnet localhost 9051
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
AUTHENTICATE "CHANGE-IT"
250 OK

EDIT: Note, this was with the out-of-the-box iptables.

[bhafer]

OK. I've solved it! As we suspected, something else was going...
Needed to change the torrc config:

ControlPort [address:]port|unix:path|auto [flags]

If set, Tor will accept connections on this port and allow those connections to control the Tor process using the Tor Control
Protocol (described in control-spec.txt in torspec). Note: unless you also specify one or more of HashedControlPassword or
CookieAuthentication, setting this option will cause Tor to allow any process on the local host to control it. (Setting both
authentication methods means either method is sufficient to authenticate to Tor.) This option is required for many Tor
controllers; most use the value of 9051. If a unix domain socket is used, you may quote the path using standard C escape
sequences. You can specify this directive multiple times, to bind to multiple address/port pairs. Set it to "auto" to have Tor
pick a port for you. (Default: 0)

My torrc now contains:

ControlPort 9051
ControlPort 192.168.42.1:9051
HashedControlPassword 16:XXXXXXXXXXXXXXXXX

No iptables changes were ultimately needed. Now can connect from the lan using:
telnet 192.168.42.1 9051

[radio24]

UPDATE: Oh, I just saw that you solved it already. 👍😀 I'm starting to get the feeling we're a spiritual brothers. 😀

Today, I took my TorBox, a lot of time, and checked systematically all involved configurations.

1. In a fresh installed TorBox (done by the install script), the HashedControlPassword matched with "CHANGE-IT". I have still to check the image, but if there would be a mismatch, main menu entry 2 would also not work.
2. A connection to localhost:9051 with telnet on the TorBox terminal worked right away.
3. The default INPUT rule on TorBox will accept data packages to port 9051 from clients.
4. The default OUTPUT rule on TorBox will accept data packages back to the client.
5. The rules FORWARD and PREROUTE are not involved, because the data packages will not sent to the Internet / through tor.
6. It could be expected that ControlPort 9051 in /etc/tor/torrc should listen to all devices, BUT THIS IS NOT THE CASE! - adding ControlPort 192.168.42.1:9051 did the trick!

Conclusion
Just add ControlPort 192.168.42.1:9051 below ControlPort 9051 in /etc/tor/torrc and restart tor.

I will also fix this issue with some other stuff in the following days and push it to the GitHub repository so that it can be easily updated with entry 5 in the update and reset sub-menu.

[bhafer]

Haha Jinx!
We found the same thing.

Not sure why I had to change password to connect with CHANGE-IT. Maybe I made an error along the way.

Love this tool so much! It's amazing. Thank you.

[radio24]

• The bug that the SSH access to TorBox from the Internet was not permanent when chosen so, but was permanent when chosen temporary is fixed with the Commit #438. The fix can be applied by updating the TorBox menu with the update and reset sub-menu entry 5.
• The problems to remotely connect to Tor's Control Port, as well as the change of the SOCKS v5 port for destination address stream isolation from 9051 to 9052 will be implemented in the TorBox v.0.4.1 because of changes in the configuration file and the menu script is necessary. If someone only updates either the configuration file or the menu script, tor will most likely break when switching to another network configuration.