maciekish Posted July 31, 2018 Share Posted July 31, 2018 (edited) Hi, i am acessing the web ui via Caddy reverse proxy. It is transparent and passing websockets as well. When i update a docker or run a script from User Scripts and the white popover window supposed to minitor the status appears, it is empty but updates once the task finishes. If i access the server without the proxy it works and refreshes as docker images download. Edit: I am using the azure theme if that makes any difference. What can i do to fix this? Edited July 31, 2018 by maciekish Quote Link to comment
JonathanM Posted July 31, 2018 Share Posted July 31, 2018 47 minutes ago, maciekish said: What can i do to fix this? Access the GUI via VPN hosted on your router or unraid instead of using a reverse proxy. Quote Link to comment
maciekish Posted July 31, 2018 Author Share Posted July 31, 2018 (edited) 19 minutes ago, jonathanm said: Access the GUI via VPN hosted on your router or unraid instead of using a reverse proxy. Sorry but that doesn't really fix the problem. A VPN is not practical in my situation. Edited July 31, 2018 by maciekish Quote Link to comment
JonathanM Posted July 31, 2018 Share Posted July 31, 2018 1 hour ago, maciekish said: Sorry but that doesn't really fix the problem. A VPN is not practical in my situation. It's the most secure solution. Unraid's webGUI isn't meant to be publicly exposed. Quote Link to comment
maciekish Posted July 31, 2018 Author Share Posted July 31, 2018 (edited) 2 minutes ago, jonathanm said: It's the most secure solution. Unraid's webGUI isn't meant to be publicly exposed. I disagree. The most secure solution is to disable the webGUI. Can we focus on solving the issue instead of discussing this please? Edited July 31, 2018 by maciekish Quote Link to comment
JonathanM Posted July 31, 2018 Share Posted July 31, 2018 (edited) 1 minute ago, maciekish said: An encrypted and password protected reverse proxy isnt exactly publicly exposed now, is it? Yes. Anyone can attempt to login, including chinese and russian botnets. Edited July 31, 2018 by jonathanm Clarification Quote Link to comment
maciekish Posted July 31, 2018 Author Share Posted July 31, 2018 1 minute ago, jonathanm said: Yes. Anyone can attempt to login. The webGUI isnt exposed until you login. Anyone can attempt to login to your VPN as well. Quote Link to comment
JonathanM Posted July 31, 2018 Share Posted July 31, 2018 1 minute ago, maciekish said: The webGUI isnt exposed until you login. Anyone can attempt to login to your VPN as well. VPN's are much easier to keep secure than the login for the GUI. To crack the VPN would require the hacker to steal your private key file off of one of your other machines. Quote Link to comment
maciekish Posted July 31, 2018 Author Share Posted July 31, 2018 5 minutes ago, jonathanm said: Yes. Anyone can attempt to login, including chinese and russian botnets. You are not helping. I have reported these posts. 1 Quote Link to comment
JonathanM Posted July 31, 2018 Share Posted July 31, 2018 I'm doing my best to help you, but you don't want to hear the answer. Quote Link to comment
maciekish Posted July 31, 2018 Author Share Posted July 31, 2018 1 minute ago, jonathanm said: I'm doing my best to help you, but you don't want to hear the answer. I didnt ask what the most secure solution is. Please leave the security to me. I want to know why it doesnt work over a reverse proxy and how to fix it. Quote Link to comment
pwm Posted July 31, 2018 Share Posted July 31, 2018 A: I can't get my car to run faster than 300 km/h - it only does 220 km/h. B: Get a bigger motor and possibly update the gear ratio for the transmission. A: I don't want suggestions of a bigger motor - I want it to run faster than 300 km/h. Anyway - I think the first step is to look for Caddy support, since it would most probably be log files created by Caddy that might tell what isn't working as expected. Quote Link to comment
maciekish Posted July 31, 2018 Author Share Posted July 31, 2018 (edited) 24 minutes ago, pwm said: A: I can't get my car to run faster than 300 km/h - it only does 220 km/h. B: Get a bigger motor and possibly update the gear ratio for the transmission. A: I don't want suggestions of a bigger motor - I want it to run faster than 300 km/h. Anyway - I think the first step is to look for Caddy support, since it would most probably be log files created by Caddy that might tell what isn't working as expected. What is with the attitude on this forum? I asked a simple question which could even be a well known issue. I don't mind suggestions. I politely refused because it is not suitable for me, yet it was forced upon me in the next post, that is my problem with all this. Edited July 31, 2018 by maciekish Quote Link to comment
pwm Posted July 31, 2018 Share Posted July 31, 2018 3 minutes ago, maciekish said: What is with the attitude on this forum? I asked a simple question which could even be a well known issue. The pot calling the kettle black.... If people aren't running their unRAID through Caddy then people aren't keeping track of issues with that usage case. So looking into Caddy support is most probably the best route to start hunting for the problem. People are regularly running unRAID with VPN. So you have to accept that people suggests a VPN - since it not only provides good security but also allows access to the shares etc. Quote Link to comment
maciekish Posted July 31, 2018 Author Share Posted July 31, 2018 Admin, please delete/lock this thread. This conversation is absolutely useless. Quote Link to comment
CHBMB Posted July 31, 2018 Share Posted July 31, 2018 Unraid isn't designed to have an outward facing webui, it's not hardened for it and although it's possible (at least with nginx - I played around to see how to do it on a VM) it's very much not recommended. Whilst the advice you have received may not be what you hoped to hear and obviously hasn't been well received, it is pretty sound advice nonetheless. Got no experience with Caddy myself, so can't help you with your query, but I can only echo what others have said, which is that it isn't a great idea. If someone does get access to your Unraid webui they essentially have root access on a server on your LAN. Not a situation you'd want to find yourself in to be honest. Quote Link to comment
maciekish Posted July 31, 2018 Author Share Posted July 31, 2018 I don't understand this witch hunt on reverse proxies. They can be made to require client certificates as well just like a VPN has a private key or a certificate, encrypt their traffic like a VPN and don't pass anything through to unRAID until authentication has been satisified. And im not the only one to want this Quote Link to comment
JonathanM Posted July 31, 2018 Share Posted July 31, 2018 16 minutes ago, maciekish said: I don't understand this witch hunt on reverse proxies. They can be made to require client certificates as well just like a VPN has a private key or a certificate, encrypt their traffic like a VPN and don't pass anything through to unRAID until authentication has been satisified. And im not the only one to want this Correct, if a reverse proxy is done right and maintained correctly, it's just as secure as a VPN. To do it right is more work than just setting up the VPN, and has more chances of going wrong. There is no witch hunt on reverse proxies here. Most of us use them on a daily basis to access the web GUI's of the dockers we run, or other services in VM's. The entire issue here is that the unraid management GUI has yet to be hardened against attack, and the consequences of getting a reverse proxy wrong and allowing someone in is too much of a risk to recommend. If you can't run a VPN for whatever reason, there are other relatively secure methods to get access to the GUI remotely. I have a VM that's always running on my machine with a Teamviewer account that I can use if my VPN isn't available. But all this is already available and easily done with VPN, and you are asking for something that isn't currently working to be fixed instead of using what is readily available and known to work correctly. Limetech has taken great strides in security in the last 3 years, and I'm sure that eventually they plan to harden the GUI and even allow external access by SSL, the groundwork is already in place. But until Limetech supports it directly, nobody on the forums can recommend it in good conscience. Limetech knows people want external access, but they feel responsible to keep that access as secure as they know how. Quote Link to comment
maciekish Posted July 31, 2018 Author Share Posted July 31, 2018 (edited) 24 minutes ago, jonathanm said: Correct, if a reverse proxy is done right and maintained correctly, it's just as secure as a VPN. To do it right is more work than just setting up the VPN, and has more chances of going wrong. There is no witch hunt on reverse proxies here. Most of us use them on a daily basis to access the web GUI's of the dockers we run, or other services in VM's. I respectfully disagree. It is a arguably easier to set up a password-only PPTP VPN than a reverse proxy as this is built-into for example Windows-Server and provides a point-and-click UI to do it. Incorrectly configured VPN and reverse proxy will both be equally insecure. Correctly configured VPN and reverse proxy will both be equally secure. I was asking if anyone knows why a small part of the web ui doesn't work and instead i'm being lectured on security... Gee, thanks. Edited July 31, 2018 by maciekish 1 Quote Link to comment
pwm Posted July 31, 2018 Share Posted July 31, 2018 15 minutes ago, maciekish said: I respectfully disagree. It is a arguably easier to set up a password-only PPTP VPN than a reverse proxy as this is built-into for example Windows-Server and provides a point-and-click UI to do it. But when you run a ssh or web server that requires certificates, your logs will show one connect attempts from scanners and then they will go away when they get a request for the certificate. It's just not meaningful to attack a certificate-based installation unless it is incorrectly configured or too old to have all the required bug fixes and the algorithmic strengthening. When you run a ssh or web server that requires passwords, you will see a huge number of login attempts where password databases are used. Some scanners will try the 100 most common admin accounts with their default passwords. But some scanners will switch over to use very extensive password databases since bandwidth is so cheap and they have robot machines that performs the attack meaning the login attempts comes from many different IP and aren't consuming the bandwidth of the attacker. This is the reason why lots of commercial systems combines the password requirement with 2FA, where you have to supply a time-limited code. Password login are very scary - especially since the machine you login from might have a keyboard logger. 25 minutes ago, maciekish said: I was asking if anyone knows why a small part of the web ui doesn't work and instead i'm being lectured on security... Gee, thanks. You got the answer "No" to that question. And instead got workaround solutions. That made you angry - the attitude you blamed on others. Quote Link to comment
maciekish Posted July 31, 2018 Author Share Posted July 31, 2018 15 minutes ago, pwm said: You got the answer "No" to that question. And instead got workaround solutions. That made you angry - the attitude you blamed on others. As a matter of fact, i never got the answer "no". And even if you would said no, you cannot answer for everybody. Maybe someone else would be able to help. You made your suggestion and i wasn't interested. Why continue forcing it on me? Quote Link to comment
pwm Posted July 31, 2018 Share Posted July 31, 2018 Just now, maciekish said: And even if you would said no, you cannot answer for everybody. Exactly. But you, on the other hand, can't expect every single forum user to make individual posts "no". So you have to accept the fact that there isn't a well-known issue with unRAID and Caddy. It still boils down to what I did write earlier "If people aren't running their unRAID through Caddy then people aren't keeping track of issues with that usage case." 2 minutes ago, maciekish said: Why continue forcing it on me? I'm not forcing anything onto you. You may run with an unencrypted connection if you feel that is fine. Run Caddy if you want - just that you can't expect much help in a unRAID forum if people aren't much using Caddy. But you might get help in a Caddy forum, since people on a Caddy forum are quite likely to use it and/or have knowledge of how to turn on suitable logs to figure out what goes wrong. There is a Caddy Docker for unRAID. Below is the support thread for this Docker. The silence in the thread indicates that people are either not using it or are using it without having any issues. And you haven't mentioned Docker anywere so your problem is most probably not related to @cmer's docker. If you post that password-based solutions are secure, then I have a reason to note that they aren't as secure as certificate-based solutions. This may be "your" support thread, but all support threads are open and other people will read this thread too. So you can't demand that people mustn't recommend VPN. There are too many happy VPN users so if anyone finds this thread using a Google search it's best that they clearly see that the general recommendation is to use VPN. A reverse proxy is common when lots of users should reach a system - and the backend system is then often placed in a separate, firewalled, network. A VPN is much more common when there are a limited number of specific people that should have access but the security requirements are high. Quote Link to comment
maciekish Posted September 18, 2018 Author Share Posted September 18, 2018 (edited) For future reference the issue is due to "buffering" in gzip in Caddy. Workaround: gzip { not /plugins } Edited September 18, 2018 by maciekish 5 2 Quote Link to comment
kharntiitar Posted October 15, 2018 Share Posted October 15, 2018 Thanks @maciekish this has helped with a similar issue that I was having, glad you posted your solution! 1 Quote Link to comment
Indmenity83 Posted May 4, 2020 Share Posted May 4, 2020 On 9/18/2018 at 3:24 AM, maciekish said: For future reference the issue is due to "buffering" in gzip in Caddy. Workaround: gzip { not /plugins } I realize this is a serious necropost, but wanted to give @maciekish a huge thank you for sticking with this after the responses he got. I'm using a reverse proxy with Nginx and had the same problem and this lead me to the same solution. So for anybody getting here from Google you'll want to add the following to your Nginx config to get things working again. You could be clever and only apply it to the locations that are broken, but since my reverse proxy is not even exposed outside my network I just disabled gzip for the whole server definition: server { gzip off; ... } As an FYI to all the doubters above, if they still hold their positions. A reverse proxy is a very handy way to make it so you don't have to remember unique port numbers of all your internal services. http://unraid.home.local or http://sonarr.home.local are totally valid internal domains if your DNS is setup right and will hint the server to your password database tool of choice so you don't have it offering up 30 passwords because everything is on the same IP address of the server. 5 2 Quote Link to comment
Recommended Posts
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.