Jump to content

fc7

Recommended Posts

After using Emby for a while I'm so happy with it that I decided to publish it to the Internet so I can listen to my music when I'm away, without needing to VPN home.

 

I'm publishing Emby behind a Squid reverse proxy, using SSL termination. Meaning:

 

Internet Client -----HTTPS SSL connection-----> | Squid reverse-proxy -----PLAIN HTTP-----> Emby

                                                                                                |

                                       INTERNET                                   |                                   LAN

 

Now I have a couple of questions/features requests regarding publishing Emby to the "evil" Internet:

 

  • Is there any known issue/concern that I should be aware off that is not too relevant while Emby is only visible in the LAN but that can be dangerous if Emby is visible from the Internet?
  • I'm worried about brute force attacks. Is it possible to enable a captcha on the login screen so for example after 3 failed logins the user will need to validate the captcha to try to login again?
  • About the login screen: would it be posible to have a configuration parameter in Emby to "harden" the login form like for example disabling autocomplete on the username field?
  • Is it possible to enable a configuration parameter to hide all users from the login screen, server wide, instead of doing it on user basis only?
  • How does the "in-network sign-in" with the easy pin code works? How does Emby know that the user is logging in from the LAN or from the Internet? What happen if the user is in the Internet but Emby is behind a reverse-proxy in the LAN (all requests comes from the LAN IP of the proxy)? Would Emby check the X-Forwarded-For HTTP header if the reverse-proxy provides it?

I know these are a lot of questions and some things may not be even implemented right now, but if they are not, maybe they can be a good idea to implement in the near future since they can help us to protect our server for the "evil" Internet.

 

Cheers

Edited by fc7
  • Like 2
Link to comment
Share on other sites

deepseth

Dunno if Squid supports putting some kind of auth infront, that'll remove most of your concerns. I'm using apache2 with reverseproxy to expose mine, but with http basic auth infront of it. Combined with fail2ban, it protects against brute force too.

 

edit: note, i had problems getting basic auth to work, but i only threw it up this morning. rather than flap about trying to work out why, i permitted the remote ip that i'm connecting from at the moment in the apache config so it doesn't require any further auth. haven't looked into it any further yet. looking at other threads, it looks like emby uses that header as well, so a quick tcpdump should expose what emby sets in that header, and should be possible to work around without too much fuss

Edited by deepseth
Link to comment
Share on other sites

denethor

The only problem that i am aware of with the Reverse proxy is kodi add-on not working with it.

You can add your additional authentication measures with iis or apache reverse proxy. But this time all client apps will faill beside Web client.

 

Sent from my SM-G925F using Tapatalk

Link to comment
Share on other sites

deepseth

Yeah, something to the effect of:

 

RequestHeader set Authorization "MediaBrowser Client=\"Emby Web Client\", Device=\"Chrome 43\", DeviceId=\"xxx\", Version=\"3.0.5621.4\", UserId=\"yyy\""

Link to comment
Share on other sites

we can change to a custom attribute if it will help. it will take time to get the client apps changed but it's doable.

  • Like 1
Link to comment
Share on other sites

fc7

Dunno if Squid supports putting some kind of auth infront, that'll remove most of your concerns. I'm using apache2 with reverseproxy to expose mine, but with http basic auth infront of it. Combined with fail2ban, it protects against brute force too.

 

edit: note, i had problems getting basic auth to work, but i only threw it up this morning. rather than flap about trying to work out why, i permitted the remote ip that i'm connecting from at the moment in the apache config so it doesn't require any further auth. haven't looked into it any further yet. looking at other threads, it looks like emby uses that header as well, so a quick tcpdump should expose what emby sets in that header, and should be possible to work around without too much fuss

Thanks for the suggestions. Actually Squid supports basic auth and even LDAP integration so I may go that way.

 

On the other hand in case it's useful for anyone else out there I tried easypin authentication in Emby from the LAN and through the reverse proxy from the Internet. In the first case easy pin auth worked as expected and I was able to login. In the second one I was only able to login with my "long" password. And that's great. It seems that Emby somehow knows when he is behind a reverse proxy and then only allow users to login with long passwords instead of short pins. Not sure if this is in the code logic or just a coincidence tough.

 

@ developers: what do your think about my other suggestion like captcha after 3 failed logins or hide all users from login screen only for clients outside the LAN? Will these things be hard to implement? Do you think they may add some value from the security stand point?

 

Thanks!

 

 

 

 

Sent from my iPad using Tapatalk

Edited by fc7
Link to comment
Share on other sites

sixtysix

Ok, it will be in the next server release.

 

I think this is exactly what I'm looking for as well.

Link to comment
Share on other sites

  • 1 year later...
Untoten

Thanks for the suggestions. Actually Squid supports basic auth and even LDAP integration so I may go that way.

 

On the other hand in case it's useful for anyone else out there I tried easypin authentication in Emby from the LAN and through the reverse proxy from the Internet. In the first case easy pin auth worked as expected and I was able to login. In the second one I was only able to login with my "long" password. And that's great. It seems that Emby somehow knows when he is behind a reverse proxy and then only allow users to login with long passwords instead of short pins. Not sure if this is in the code logic or just a coincidence tough.

 

@ developers: what do your think about my other suggestion like captcha after 3 failed logins or hide all users from login screen only for clients outside the LAN? Will these things be hard to implement? Do you think they may add some value from the security stand point?

 

Thanks!

 

 

 

 

Sent from my iPad using Tapatalk

@@fc7 @@deepseth  Did either of you ever get custom auth using squid to auth emby working?  Does it work with the app?  I would love to figure out an SSO solution for Emby, it's holding back tons of projects of mine.

Link to comment
Share on other sites

Tur0k

we can change to a custom attribute if it will help. it will take time to get the client apps changed but it's doable.

Please define the feature and how it can be used.

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

Tur0k

After using Emby for a while I'm so happy with it that I decided to publish it to the Internet so I can listen to my music when I'm away, without needing to VPN home.

 

I'm publishing Emby behind a Squid reverse proxy, using SSL termination. Meaning:

 

Internet Client -----HTTPS SSL connection-----> | Squid reverse-proxy -----PLAIN HTTP-----> Emby

                                                                                                |

                                       INTERNET                                   |                                   LAN

 

Now I have a couple of questions/features requests regarding publishing Emby to the "evil" Internet:

 

  • Is there any known issue/concern that I should be aware off that is not too relevant while Emby is only visible in the LAN but that can be dangerous if Emby is visible from the Internet?
  • I'm worried about brute force attacks. Is it possible to enable a captcha on the login screen so for example after 3 failed logins the user will need to validate the captcha to try to login again?
  • About the login screen: would it be posible to have a configuration parameter in Emby to "harden" the login form like for example disabling autocomplete on the username field?
  • Is it possible to enable a configuration parameter to hide all users from the login screen, server wide, instead of doing it on user basis only?
  • How does the "in-network sign-in" with the easy pin code works? How does Emby know that the user is logging in from the LAN or from the Internet? What happen if the user is in the Internet but Emby is behind a reverse-proxy in the LAN (all requests comes from the LAN IP of the proxy)? Would Emby check the X-Forwarded-For HTTP header if the reverse-proxy provides it?

I know these are a lot of questions and some things may not be even implemented right now, but if they are not, maybe they can be a good idea to implement in the near future since they can help us to protect our server for the "evil" Internet.

 

Cheers

Points 1 and 2:

1.  Make sure that on your router/firewall, you are only passing the port required for HTTPS for public users. 

2.  run Emby on a separate service account that only has:

     A. run as a service

     B. Permissions to the Emby application directories in program files, Program files x86, program data, the SSL certificate folder, and the media folders that you want to be accessible to users. 

     C. see hardening guide here: https://social.technet.microsoft.com/wiki/contents/articles/13974.security-best-practices-to-protect-internet-facing-web-servers.aspx

3.  Harden Emby's running configuration and user accounts:

     A. I noticed now that there are two HTTPS ports.  I suspect that this has something to do with simple pin logins.  You may want to ensure that the two HTTPS ports are not the same.  <manage server - Advanced - Local https port number> and <manage server - Advanced -Public https port number)

     B. Disable seeing users on the main login screen <manage server - users - pick a user - check Hide this user from login screens>

 

Point 3: Disabling auto-complete is normally a configuration setting in the client browser or application. 

Point 4: Agreed, it might be something that could be tied to if the site is being rendered on public ports (manage server - Advanced -Public https port number). 

Point 5: all great questions and i would like to see them answered.  I suspec that you are correct, I know that in my HAProxy reverse proxy setup I have the front end configured to create an HTTP "X-Forwarded-For" header with the client's IP.  when I log in from my phone with no access to my internal network the log (server manager - Dashboard) shows my phone's public IP.  When I log in from my office computer I see the right internal subnet IP.

Link to comment
Share on other sites

  • 9 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...