search

radio24 / TorBox

TorBox is an easy to use, anonymizing router based on Raspberry Pi, which also runs on Debian and Ubuntu based systems.
https://www.torbox.ch
GNU Affero General Public License v3.0
257 stars 27 forks source link

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

Closed bhafer closed 3 years ago

bhafer commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

bhafer commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

bhafer commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

bhafer commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

bhafer commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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/torrcand 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 commented 3 years ago

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 commented 3 years ago