[Support] binhex - rTorrentVPN


Recommended Posts

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?

Link to comment
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
Link to comment
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
Link to comment
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.

Link to comment
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).

 

Link to comment
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.

  • Like 1
Link to comment
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!

  • Like 2
Link to comment
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.

Link to comment
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.

  • Like 1
Link to comment

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.

Link to comment
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
Link to comment
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'.

  • Like 1
Link to comment

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
Link to comment
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

Link to comment
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
Link to comment
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'.

  • Like 1
Link to comment
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.

 

Link to comment

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

  • Like 1
Link to comment
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

 

Link to comment

Was looking through this thread but didnt find any answer, so i´ll give it a shot.

Was running delugevpn before and config through the webinterface worked fine, but when im trying to change the config in rtorrentvpn it reverts back in the web config when i cange something, thou it seems like its working, i changed the download folder and it downloads to that folder but in the web ui it reverts to default path.

Am i missing something or doesnt config through web work?

Link to comment
13 hours ago, jrdnlc said:

@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

luckily i see a new release for rutorrent has JUST been done, so i should pick this up shortly once the arch linux guys have picked it up and changed their code.

Link to comment
  • binhex locked this topic
Guest
This topic is now closed to further replies.