Jump to content
binhex

[Support] binhex - rTorrentVPN

2313 posts in this topic Last Reply

Recommended Posts

7 hours ago, BrttClne22 said:

I was considering using a reverse proxy to make rutorrent accessible from the web (mainly for NZB360), however, I was doing some research before I did so and it seems that RPC2 doesn't require auth (I think it used to?). To test, I removed my username/password from Sonarr, Radarr and NZB360, all three seem to connect without any username/password. Are others seeing this?

 

I don't think I've modified any configuration that would effect this. I've been using this container for a while but I think the deepest thing I've done configuration wise is add my own username/password and delete the default using the scripts.

 

You don't need to expose port 5000. Just expose 9443 (or 9080 if you are offloading Https to the proxy). As far as rutorrent is concerned it is talking to XML-RPC in the container's localhost.

If you are using other clients that require access to port 5000, you can use a similar strategy.

I've personally created a docker compose file for all applications that require access to rtorrent. Docker compose creates a shared network where services are discoverable by name (https://docs.docker.com/compose/networking/). Applications like Sonarr can access port 5000 even though it is not directly exposed to the internet. (E.g., use container hostname:5000)

 

I would not recommend exposing RPC2 over the internet. However, if you want to do it for whatever reason (e.g., Sonarr is running in a separate box in the internet and for whatever reason you don't want to use a VPN) you will need to really beef up security. Username and password is just a first measure; monitoring your logs, setting up fail2ban, etc are all good steps. Otherwise you will soon find a crypto miner installed at your server... 

 

Share this post


Link to post
4 hours ago, Cat_Seeder said:

 

You don't need to expose port 5000. Just expose 9443 (or 9080 if you are offloading Https to the proxy). As far as rutorrent is concerned it is talking to XML-RPC in the container's localhost.

If you are using other clients that require access to port 5000, you can use a similar strategy.

I've personally created a docker compose file for all applications that require access to rtorrent. Docker compose creates a shared network where services are discoverable by name (https://docs.docker.com/compose/networking/). Applications like Sonarr can access port 5000 even though it is not directly exposed to the internet. (E.g., use container hostname:5000)

 

I would not recommend exposing RPC2 over the internet. However, if you want to do it for whatever reason (e.g., Sonarr is running in a separate box in the internet and for whatever reason you don't want to use a VPN) you will need to really beef up security. Username and password is just a first measure; monitoring your logs, setting up fail2ban, etc are all good steps. Otherwise you will soon find a crypto miner installed at your server... 

 

I admittedly don't have a deep understanding of rTorrent/ruTorrent but based on the little I know, port 5000 would be rTorrent (the backend) and 9080/9443 would be ruTorrent (the frontend, which is what I'd like to reverse proxy). This RPC2 endpoint seems to live on the front end (9080/9443).

 

Within my network, I've currently got NZB360 (an android app) pointed at https://192.168.1.4:9443/RPC2 (ports are all default) and it's working with no username or password.

Share this post


Link to post
29 minutes ago, BrttClne22 said:

Within my network, I've currently got NZB360 (an android app) pointed at https://192.168.1.4:9443/RPC2 (ports are all default) and it's working with no username or password.

i also use nzb360 and for me it will not allow me to connect to rutorrent via rpc2 without authentication details (as in ruTorrent username and password), do you have authentication enabled for the web ui?

Share this post


Link to post
2 hours ago, binhex said:

i also use nzb360 and for me it will not allow me to connect to rutorrent via rpc2 without authentication details (as in ruTorrent username and password), do you have authentication enabled for the web ui?

Interesting. When I go to the :9443/ in a browser I get the default browser authentication popup and I log in with the username/password I created with the script inside the container. I can definitely verify that Sonarr/Radarr/NZB360 don't require authentication to the :9443/rpc2 endpoint currently.

 

Maybe I should delete my container/appdata and start from scratch?

Edited by BrttClne22

Share this post


Link to post

For reference... 

 

(And in NZB360, the upload/download speed update every 5 seconds so it's definitely making a full connection)

 

 

Screenshot_20190321-174717.png

Screenshot_20190321-174656.png

Share this post


Link to post
1 hour ago, BrttClne22 said:

Interesting. When I go to the :9443/ in a browser I get the default browser authentication popup and I log in with the username/password I created with the script inside the container. I can definitely verify that Sonarr/Radarr/NZB360 don't require authentication to the :9443/rpc2 endpoint currently.

 

Maybe I should delete my container/appdata and start from scratch?

ok i was getting tripped up by my reverse proxy blocking access to /RPC2 externally, tried it internally and you are correct, i can indeed access /RPC2 with credentials. so had a look at the nginx config and this is the fix:-

 

open file /config/nginx/config/nginx.conf and look for the following section (there will be two occurrences):-

        # include scgi for rtorent, specifying port 5000, important MUST use ip address
        location /RPC2 {
            include scgi_params;
            scgi_pass 127.0.0.1:5000;
        }
           

so change this to be:-

        # include scgi for rtorent, specifying port 5000, important MUST use ip address
        location /RPC2 {
            include scgi_params;
            scgi_pass 127.0.0.1:5000;
            auth_basic "Restricted Content";
            auth_basic_user_file /config/nginx/security/auth;
        }

once done save and restart the container, this for me then forces auth when connecting to /RPC2, give it a go if you have the same success as me then i will come up with some way of patching existing users config.

Edited by binhex

Share this post


Link to post
39 minutes ago, binhex said:

ok i was getting tripped up by my reverse proxy blocking access to /RPC2 externally, tried it internally and you are correct, i can indeed access /RPC2 with credentials. so had a look at the nginx config and this is the fix:-

 

open file /config/nginx/config/nginx.conf and look for the following section (there will be two occurrences):-


        # include scgi for rtorent, specifying port 5000, important MUST use ip address
        location /RPC2 {
            include scgi_params;
            scgi_pass 127.0.0.1:5000;
        }
           

so change this to be:-


        # include scgi for rtorent, specifying port 5000, important MUST use ip address
        location /RPC2 {
            include scgi_params;
            scgi_pass 127.0.0.1:5000;
            auth_basic "Restricted Content";
            auth_basic_user_file /config/nginx/security/auth;
        }

once done save and restart the container, this for me then forces auth when connecting to /RPC2, give it a go if you have the same success as me then i will come up with some way of patching existing users config.

I'll give this a shot when I get home.

 

Just out of curiosity, in your setup, did you disable auth in the container and just use auth on the proxy? That seems like a good blanket fix.

 

You're the man binhex! Thanks for looking into it so quickly. Beer will definitely be coming your way.

Share this post


Link to post
5 hours ago, binhex said:

ok i was getting tripped up by my reverse proxy blocking access to /RPC2 externally, tried it internally and you are correct, i can indeed access /RPC2 with credentials. so had a look at the nginx config and this is the fix:-

 

open file /config/nginx/config/nginx.conf and look for the following section (there will be two occurrences):-


        # include scgi for rtorent, specifying port 5000, important MUST use ip address
        location /RPC2 {
            include scgi_params;
            scgi_pass 127.0.0.1:5000;
        }
           

so change this to be:-


        # include scgi for rtorent, specifying port 5000, important MUST use ip address
        location /RPC2 {
            include scgi_params;
            scgi_pass 127.0.0.1:5000;
            auth_basic "Restricted Content";
            auth_basic_user_file /config/nginx/security/auth;
        }

once done save and restart the container, this for me then forces auth when connecting to /RPC2, give it a go if you have the same success as me then i will come up with some way of patching existing users config.

Hi @binhex, it works. However... Is that /RCP2 mount proxying 9080 and 9443 to 5000 over SCGI really necessary for rutorrent or flood to work over the internet?

 

As far as I can tell from config.ini, rutorrent is actually going straight to 127.0.0.1:5000:

 

    $scgi_port = 5000;

    $scgi_host = "127.0.0.1";

 

Flood can also connect directly to port 5000.

 

There are even a couple of plugins meant to replace SCGI altogether (see https://github.com/Novik/ruTorrent/wiki/PluginHTTPRPC for instance), it even promises to reduce bandwidth usage in exchange for extra CPU load.

 

Regardless of authentication. If WAN exposure to XML-RPC can be limited I think that it would be a great idea. There are several known exploits that target insecure RPC deployments. There are also bots looking for this kind of thing (you can thank years and years of insecure WordPress deployments for that).

 

If XML-RPC exposure over WAN is not strictly necessary I would vote to disable it by default. Maybe include an ENABLE_XMLRPC_OVER_SCGI flag for people that really need it. Basic authentication should certainly be enabled and I would really advice that people thinking about enabling such a flag first take the time to tighten security (or better yet, do not expose ports to WAN. Use a VPN instead).

 

Further reading

 

* Discussion about rtorrent and XML-RPC exploits: https://github.com/rakshasa/rtorrent/issues/696

* "Secure" setup with rtorrent + local / UNIX socket +  Nginx reverse proxy with basic authentication + rutorrent: 

 

* rTorrent - ruTorrent communication: http://forum.cheapseedboxes.com/threads/rtorrent-rutorrent-guide.1417/ - HTTPRPC sounds like a great alternative to XML-RPC over SCGI (unless you are running a potato PC).

 

Share this post


Link to post
5 hours ago, Cat_Seeder said:

Is that /RCP2 mount proxying 9080 and 9443 to 5000 over SCGI really necessary for rutorrent or flood to work over the internet?

for most apps probably not, but as you can see some applications are coded in such a way to only use the /RPC2 mount (nzb360 being one) and in the scenario where sonarr/radarr maybe installed at a remote location connected over the internet, i think its probably safer to expose RPC2 than it would be to port forward port 5000, unless im missing something here?.

 

i could look at adding in an env var to control whether you allow access to /RPC2 or not, its a bit of work so it may take a while before its in place (lots going on).

 

5 hours ago, Cat_Seeder said:

If XML-RPC exposure over WAN is not strictly necessary I would vote to disable it by default

whilst i agree that having it disabled by default is the way to go, i do not want to shut the door on existing users who currently may rely on this, so i will be setting the default to disabled for all new users and leaving it enabled for all existing, they can then decide whether they want to disable it or not via the new env var.

Share this post


Link to post
16 hours ago, binhex said:

ok i was getting tripped up by my reverse proxy blocking access to /RPC2 externally, tried it internally and you are correct, i can indeed access /RPC2 with credentials. so had a look at the nginx config and this is the fix:-

 

open file /config/nginx/config/nginx.conf and look for the following section (there will be two occurrences):-


        # include scgi for rtorent, specifying port 5000, important MUST use ip address
        location /RPC2 {
            include scgi_params;
            scgi_pass 127.0.0.1:5000;
        }
           

so change this to be:-


        # include scgi for rtorent, specifying port 5000, important MUST use ip address
        location /RPC2 {
            include scgi_params;
            scgi_pass 127.0.0.1:5000;
            auth_basic "Restricted Content";
            auth_basic_user_file /config/nginx/security/auth;
        }

once done save and restart the container, this for me then forces auth when connecting to /RPC2, give it a go if you have the same success as me then i will come up with some way of patching existing users config.

I can confirm this worked for me although I did end up doing a blanket auth on the proxy. Thanks again!

Share this post


Link to post
3 hours ago, binhex said:

for most apps probably not, but as you can see some applications are coded in such a way to only use the /RPC2 mount (nzb360 being one) and in the scenario where sonarr/radarr maybe installed at a remote location connected over the internet, i think its probably safer to expose RPC2 than it would be to port forward port 5000, unless im missing something here?.

Yes. Certainly proxing with auth is better than directly exposing port 5000 to the internet.

I don't know much about nzb360. I have however enabled HTTPRPC and tested Sonarr with it (plugins/httprtc/action.php endpoint). It is working well (for about 5 hours). Not really impacting my CPU usage very much (testing on a laptop with I7 CPU).

3 hours ago, binhex said:

i could look at adding in an env var to control whether you allow access to /RPC2 or not, its a bit of work so it may take a while before its in place (lots going on).

 

whilst i agree that having it disabled by default is the way to go, i do not want to shut the door on existing users who currently may rely on this, so i will be setting the default to disabled for all new users and leaving it enabled for all existing, they can then decide whether they want to disable it or not via the new env var.

I do understand and thank you for taking action. If possible, however, I would at least recommend pushing basic authentication in the /RPC2 mount to everyone ASAP (as per my understanding you are already planning to do it as soon as you get confirmation that it works). While it is not as effective as completely removing the attack vector by default; with basic authentication exposed containers are at least safer from scanning bots.

Share this post


Link to post
On 3/22/2019 at 2:50 PM, Cat_Seeder said:

however, I would at least recommend pushing basic authentication in the /RPC2 mount to everyone ASAP (as per my understanding you are already planning to do it as soon as you get confirmation that it works).

now complete, new image is built which should now alter an existing nginx.conf and add in the basic auth to the /rpc2 location, if its already secure it will skip this, new users will get this set by default.

Share this post


Link to post

Yo, I am here because android apps nzb360 and Transdroid won't connect anymore after the last update.

 

I saw what you changed and tried commenting out the two new lines. Everything works now except nzb360 still won't connect locally.

 

I am not sure if I am even in the scope of people that can benefit from what you changed (and I don't quite understand it), as my apps were set to connect to a subdomain reverse proxy with basic auth set in the Letsencrypt docker container by Linuxserver, and locally to the localip:9080 with /RPC2 endpoint and without authentication.

Share this post


Link to post
11 hours ago, JohanSF said:
Yo, I am here because android apps nzb360 and Transdroid won't connect anymore after the last update.
 
I saw what you changed and tried commenting out the two new lines. Everything works now except nzb360 still won't connect locally.
 
I am not sure if I am even in the scope of people that can benefit from what you changed (and I don't quite understand it), as my apps were set to connect to a subdomain reverse proxy with basic auth set in the Letsencrypt docker container by Linuxserver, and locally to the localip:9080 with /RPC2 endpoint and without authentication.

You won't be in scope for people who should have rpc2 secured, however there is obviously no way of me knowing up front whether you use a reverse proxy or not. and thus I have to assume you aren't and thus should be secured.

Commenting out the two additional lines should do it did you do this for both HTTP and HTTPS? also you will need to restart the container after this change.

edit - considering the idea of two env vars to control authentication for rpc2 and whether its enabled.

Sent from my EML-L29 using Tapatalk
 

Edited by binhex

Share this post


Link to post
4 hours ago, binhex said:

edit - considering the idea of two env vars to control authentication for rpc2 and whether its enabled.

this is now done, you can control it via two new env vars (yes you will need to create these if you are an existing user):-

key                  values
---                  ------
ENABLE_RPC2          yes|no            
if set to yes then rpc2 location will be added to nginx.conf (for http and https), if no then it wll be removed.

ENABLE_RPC2_AUTH     yes|no          
if set to yes then rpc2 location will be secured using basic auth (for http and https), if no  then it will be 
insecure (useful for people using reverse proxy for authentication).

if either of these env vars are not defined then the default is 'yes'.

Share this post


Link to post

I apologize if this is out of scope for this thread - but is there a way to queue files in rutorrent so they dont all run at once? I think I am missing the forrest for the trees here. Great docker btw, I really like it vs deluge. 

Edited by ice pube

Share this post


Link to post
1 hour ago, ice pube said:

I apologize if this is out of scope for this thread - but is there a way to queue files in rutorrent so they dont all run at once? I think I am missing the forrest for the trees here. Great docker btw, I really like it vs deluge. 

i believe that is controlled by the following line in the /config/rtorrent/config/rtorrent.rc file:-

#throttle.max_downloads.global.set = XXX

uncomment it and then set that to a decimal value, save the file and restart the container

Share this post


Link to post
3 hours ago, binhex said:

this is now done, you can control it via two new env vars (yes you will need to create these if you are an existing user):-


key                  values
---                  ------
ENABLE_RPC2          yes|no            
if set to yes then rpc2 location will be added to nginx.conf (for http and https), if no then it wll be removed.

ENABLE_RPC2_AUTH     yes|no          
if set to yes then rpc2 location will be secured using basic auth (for http and https), if no  then it will be 
insecure (useful for people using reverse proxy for authentication).

if either of these env vars are not defined then the default is 'yes'.

 

Tested. All working great! Thanks Binhex. More beer coming as soon as I receive my paycheck ;).

 

I know that I'm being annoying / paranoid, but I think that ENABLE_RPC2 should be "no" by default. RCP2 + default admin / password means that containers are still easily exploitable out of the box. A valid counterpoint is that most people that are not techie-savvy enough to change the default credentials will probably not be exposing ports to the internet... However, I guess that most users will not really care about / need XMLRPC over SCGI out of the box. Honestly, I think that it is safer to assume that most people will not need it and let everyone else enable it manually.

Edited by Cat_Seeder

Share this post


Link to post
13 minutes ago, Cat_Seeder said:

 but I think that ENABLE_RPC2 should be "no" by default. RCP2 + default admin / password means that containers are still easily exploitable out of the box.

taking this a step further though, if a user doesnt change the default username and password then even with rpc2 disabled they will be at risk via the web interface (keeping in mind the user does need to setup port forwarding). i think you have to draw a line and say the user is responsible for security to a certain degree.

14 minutes ago, Cat_Seeder said:

However, I guess that most users will not really care / need XMLRPC over SCGI out of the box.

i think you maybe underestimating the popularity of android/apple apps such as transdroid and nzb360, both of these rely soley on rpc being accessible, im not really comfortable with the fallout of setting this to no by default (for existing users), this is bound to increase the support issues. 

 

How about i meet you mid way and set ENABLE_RPC to 'no' by default in the template (will take affect for new users) and put in a nice big warning in the template saying something like 'enable at your risk, make sure you have changed username and/or password'.

Share this post


Link to post
5 minutes ago, binhex said:

i think you have to draw a line and say the user is responsible for security to a certain degree.

i think you maybe underestimating the popularity of android/apple apps such as transdroid and nzb360, both of these rely soley on rpc being accessible, im not really comfortable with the fallout of setting this to no by default (for existing users), this is bound to increase the support issues. 

Fair enough. Both valid points.

6 minutes ago, binhex said:

How about i meet you mid way and set ENABLE_RPC to 'no' by default in the template (will take affect for new users) and put in a nice big warning in the template saying something like 'enable at your risk, make sure you have changed username and/or password'.

That's a good compromise. New users will be safe by default, but it will not be a draconian imposition on old users. 
Good idea about the warning as well. Maybe something like:

 

ENABLE_RPC: This option exposes XMLRPC over SCGI (/RPC2 mount). Useful for mobile clients such as Transdroid and nzb360.
WARNING: Once enabled, authenticated users will be able to execute shell commands using http / https (including commands that write to shared volumes). Known exploits target insecure XMLRPC deployments (e.g., Monero exploit). Enable at your own risk, make sure you have changed username and password before doing that.

 

And something similar for ENABLE_RPC_AUTH.

 

WARNING: By disabling ENABLE_RPC_AUTH you are essentially allowing everyone with http / https to run arbitrary shell commands against your container. Disabling this option is not recommended.

 

In summary: What it does, why would anyone enable it, why it can be dangerous and how to properly protect the setup. (Sorry for my bad English BTW. I'm not a native speaker).

 

Honestly, I wouldn't set ENABLE_RPC_AUTH=no even in my own LAN. Perimetral security is great and all, however, to me XMLRPC is about the same as ssh access (None of my servers allow unauthenticated access). Keep it safe and let the reverse proxy pass-through auth headers.

 

Share this post


Link to post

Not really sure if this is a better solution, but it is an alternative.  

Leave the local basic auth as is, and in your reverse proxy add the line

proxy_set_header Authorization "Basic YWRtaW46cnV0b3JyZW50";

This will pass the default admin/rutorrent password along after you auth via the reverse proxy.

Definitely do not do this if you do not have basic auth setup in your reverse proxy.  If you are using a different username and password you'll need to convert your "user:password" to base 64.  https://www.opinionatedgeek.com/codecs/base64encoder

Share this post


Link to post

Transdroid has stopped working since the last update, any idea what setting I need to change?

Share this post


Link to post
On 3/31/2019 at 11:53 AM, Spies said:

Transdroid has stopped working since the last update, any idea what setting I need to change?

you now need to define the username and password for rutorrent in transdroid, if you are using a reverse proxy and that is doing the auth then you might need to disable authentication, see my post here for explanation on the new env vars:-

https://forums.unraid.net/topic/46127-support-binhex-rtorrentvpn/?do=findComment&comment=733209

 

Share this post


Link to post

Thanks.

 

Is there any way to configure rtorrent to bypass the privoxy for specific trackers?

Edited by Spies

Share this post


Link to post

@binhex Can you update the check_port plugin? Updating the plugin solved the check port issues stated before.

It was found by one of our staff members in Organizr discord. Github issue has been opened and can be accessed here

 

Screen Shot 2019-04-08 at 3.46.28 PM.png

Edited by jrdnlc

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.