Security 101: Secure Connections

[notla49285 46]

The problem with TorGuard is that you really don't have any security except from your ISP.  You have a "tunnel" from your home to a server sitting in a data center and that's it.  It's not an end-to-end VPN solution.  You're only encrypted partially. 

 

Basically you've only moved the attack vector from your router to the VPN Server.

 

Does that make sense?

 

Excuse me for the probably basic question, if it was possible to run Emby behind a VPN as well as accessing via a domain (i.e. using SSL), would that make this better?

[Spaceboy 2493]

What I have done using my pfsense router is create a vpn direct from my client (eg iPhone) to the router, which runs the vpn server. So even remotely I appear to be on the Lan. Fully encrypted end to end

 

Pfsense is great for that and even easy for a novice like me accompanied by you tube walkthroughs

[Guest asrequested]

The problem with TorGuard is that you really don't have any security except from your ISP. You have a "tunnel" from your home to a server sitting in a data center and that's it. It's not an end-to-end VPN solution. You're only encrypted partially.

 

Basically you've only moved the attack vector from your router to the VPN Server.

 

Does that make sense?

Uuuuuummm....I pretty much already said this. I understand how it works. I really do know what I'm doing

 

For the noobs. Encryption doesn't block access. It just makes the data unreadable, which can prevent interaction. To use encryption as a 'security' measure, you'd want to put the decryption key on specific devices, so only those devices can read the data. Using a VPN all data is encrypted, but the difference is that it's decrypted on the VPN proxy, so it's a global function. But by the time it's decrypted, all unique and identifying information has been removed. No it doesn't prevent access, that's what your firewall is for. If someone gets your proxy IP, they can potentially gain access. But they won't get your ISP IP. So you can change the VPN IP as you wish. Just have a good password, and if you have a good firewall like pfsense, you can create rules that will block access to repeated failed attempts to access your server. This is what I have done. I think it's better than using a domain with an SSL.

Edited January 23, 2019 by Doofus

[pir8radio 1292]

.. the problem with 'learning on the job' is you inevitable make some rookie 'mistakes' and while 'it works', in the world of cyber security, opens you up to a world of pain and potential danger to your and others private life if not done correctly.

 

With the free SSL facilities from somebody like  'Lets Encrypt', my view is Emby should look into this as a service - as offering non-secured HTTP access with the click of a button is irresponsible imo.

 

Yea, they could probably make a paid plugin or raise the price for the "one click https" version I guess to cover those people.

[Fratopolis 62]

+1 for pfsense.

 

I started implementing it at my job. Thing is pretty nice once you learn it. But man, there was quite a bit to learn lol.

 

Thinking of just getting one of those little netgate ones they sell for home. VM not an option in case of power loss since my system shuts down after 5 min to conserve battery backup.

Edited January 24, 2019 by Fratopolis

[Carlo 4330]

Uuuuuummm....I pretty much already said this. I understand how it works. I really do know what I'm doing

 

For the noobs. Encryption doesn't block access. It just makes the data unreadable, which can prevent interaction. To use encryption as a 'security' measure, you'd want to put the decryption key on specific devices, so only those devices can read the data. Using a VPN all data is encrypted, but the difference is that it's decrypted on the VPN proxy, so it's a global function. But by the time it's decrypted, all unique and identifying information has been removed. No it doesn't prevent access, that's what your firewall is for. If someone gets your proxy IP, they can potentially gain access. But they won't get your ISP IP. So you can change the VPN IP as you wish. Just have a good password, and if you have a good firewall like pfsense, you can create rules that will block access to repeated failed attempts to access your server. This is what I have done. I think it's better than using a domain with an SSL.

But all you have effectively done is change your external IP using TorGuard and nothing more.  Nothinng wrong with that if you are intentionally trying to make your exit point a different location for accessing other services.  But for anyone accessing your server it's not doing anything at all what-so-ever.  If you server was not using SSL then all info sent/received from the client is still in the open going out over the internet.

 

Anyone running a port scan on TorGuads's IPs will find your Emby server and can freely communicate with it.  The "Hacker" won't care that "half" of your link is running through a tunnel with encryption as his side is not.  To the hacker it's an open server.  So without SSL on the Emby server (not saying your not doing this) it's not encrypted in any meaningful way at all.

 

That's for Noobs who might think using a public VPN provider is helpful security wise.  As you said, to be secure the encryption has to be from the client to the server.

[Guest asrequested]

But all you have effectively done is change your external IP using TorGuard and nothing more.  Nothinng wrong with that if you are intentionally trying to make your exit point a different location for accessing other services.  But for anyone accessing your server it's not doing anything at all what-so-ever.  If you server was not using SSL then all info sent/received from the client is still in the open going out over the internet.

 

Anyone running a port scan on TorGuads's IPs will find your Emby server and can freely communicate with it.  The "Hacker" won't care that "half" of your link is running through a tunnel with encryption as his side is not.  To the hacker it's an open server.  So without SSL on the Emby server (not saying your not doing this) it's not encrypted in any meaningful way at all.

 

That's for Noobs who might think using a public VPN provider is helpful security wise.  As you said, to be secure the encryption has to be from the client to the server.

 

You seem to make a lot of wrong assumptions.....but ok, whatever floats your boat. I'm not going to compete.

[VaporTrail 66]

Not to derail, but isn't this a great business opportunity for Emby devs? By creating a separate company (brought to you by the trusted devs of Emby), they can offer an upsell service that asks a few simple questions in a conditional form, than automates you a PFX file.

 

You'd pay annually (no lifetime), which is great to continue generating revenue from lifetime customers. Isn't that what all smart SaaS vendors try to do with early lifetime offers? Offer upsell services? They could put in the TOS that they're not responsible for any lost data, and if ever sued, it's under a separate entity shielding Emby LLC.

 

Also, those who wish to use their own home-brewed solutions are free to do so, while also not over-taxing the Emby Connect service. Unlike Plex, it's very much a separate service and completely voluntary. Heck, they could offer a one-time discount for new users who purchase Premier, but also soft-market to exisiting users via email, forum, blog, etc. 

 

Am I wrong to think Emby should be walking customers up the value ladder? What better time to secure your investment of time/content, than after you've built your libraries in the free trial?

[revengineer 122]

What I have done using my pfsense router is create a vpn direct from my client (eg iPhone) to the router, which runs the vpn server. So even remotely I appear to be on the Lan. Fully encrypted end to end

 

Pfsense is great for that and even easy for a novice like me accompanied by you tube walkthroughs

^^^ THIS is the solution, short and sweet. Real security, not security by obscurity. The solution requires a single open port on the firewall for the OpenVPN server, and there is not need to do SSL encryption on the emby server (assuming that you trust others/family on your network).

[Tur0k 143]

@@notla49285, With regard to securing your publicly accessible web services (ie emby) one must look at each security technology and which attack vectors they address.

 

-VPN

So, it is important to note that VPNs can be applied in two separate ways:

 

1. VPN from your home to the public Internet helps you to:

A. obscure what you are doing online from prying eyes( ex: compromised equipment between you and the Internet, your ISP (internet service provider), etc).

B. It also allows you to obscure your home WAN IP address from potential DDoS (distributed denial of service) attacks from the public Internet(ex: in the event you are attacked you could turn off your connection to your VPN provider and your home WAN is no longer under attack).

 

NOTE: This assumes that the vpn you setup l is adequately hardened and the infrastructure/configuration is locked down, and that certs, keys, authentication, etc are kept private.

 

I secure some of my web traffic to the public Internet with a vpn provider and openvpn installed on my PFsense firewall. I also go further and only allow TOS encrypted DNS to Cloudflares DNS servers. I go one step further and send that traffic across my vpn to the public Internet. I do this in order to:

A. Prevent DNS leaks to my ISP and other prying eyes.

B. Further obscure my home location on the Internet. I do not use this to help secure my Emby service.

 

2. VPN from a device or network on the other side of the public Internet to your home network.

 

Allows you to Encrypt traffic between your client device (laptop, smartphone, etc) and your home network. Then you can send insecure traffic across secure vpn tunnel.

 

NOTE: This assumes that the vpn you setup l is adequately hardened and the infrastructure/configuration is locked down, and that certs, keys, authentication, etc are kept private.

 

I use this when I need to remotely administer my network. My family members are not this technical and wouldn’t do this.

 

- Public Domain and DDNS (Dynamic Domain Name Service)

 

You could purchase a public domain (ex:mydomain.com) and DDNS Client to keep your DHCP (Dynamic Host Configuration Protocol) WAN IP updated on a subdomain of your domain (ex: emby.mydomain.com)

 

This doesn’t, on its own, enhance security. It actually makes it easier to find your WAN connection.

 

I have a private domain and have a DDNS client setup on my firewall to keep things in synch.

 

- SSL Certificate

 

What a public domain can do for you is allow you to pickup an SSL certificate. Once you have:

1. Configured your Emby server for remote access using your new subdomain,

2. installed on your Emby server,

3. Configured your firewall to port forward port 8920 from your WAN to your Emby server,

you will then be able to encrypt traffic between your Emby server and remote clients on the other side of the Internet using publicly trusted SSL certificates.

 

NOTE: This assumes that the encryption type and ciphers are adequately complex, the infrastructure/configuration of the network/server is hardened, and that certs/authentication/etc are kept private.

 

I also have a reverse proxy that I use to proxy all my internal web services. I have rules that either allow or deny access from the Internet, or only allow access from my internal network and vpn connection to my home.

 

I use let’s Encrypt ssl certs. I SSL terminate my publicly and internally proxied sites there. I have an Acme client that keeps the certs up to date and in restarts and

 

- Public proxy service like Cloudflare

 

Cloudflare is a service that:

1. Obscures your home WAN IP

2. offers SSL protection end to end in two phases.

A. Your home to Cloudflare.

B. Cloudflare to the public Internet.

C. Offers protection from DDoS.

 

I really like their offering and would use it if I didn’t already know how to setup a reverse proxy and SSL certificate.

Note: You would still need to

I. Load their certificate for A: above to your Emby server.

II. Configure a public domain to point to Cloudflare.

III. DHCP reserve your Emby server’s internal LAN IP address.

IV. port forward from your WAN IP to your Emby server.

 

My only complaint about it would be that if you wanted SSL secured access both internal and external you would end up having to send your internal traffic out the Internet to Cloudflare to come back to your local Emby service.

 

- use best practices with accounts and permissions.

 

1. Limit administrative/delete permission access. Use a regular account for normal user behavior then log in with the admin account separately when you want to do admin work.

2. Don’t tie your Emby connect account to your admin account.

3. Don’t sign into your Emby account from an insecure site (non-HTTPS).

4. Limit login times.

5. Don’t allow usernames to be listed on the login screen.

 

- Geo IP blocking.

 

If you don’t travel abroad much you could develop a system that allows you to block all IP addresses from countries outside your home country. I would likely either limit the traffic to inbound connections to your Emby server, or do this on your Emby server instead.

 

I did this for a bit but noticed many public port scans, bad login attempts that were sourced from inside the US.

 

- Black-list ip blocking

 

Using a system that allows you to subscribe to well managed IP lists of malicious sources and then blocking all communication with those remote sources at your firewall.

 

I do this with PFBlockerNG in PFSense.

 

- Black listing public IPs for bad behavior.

 

Using a system that can track bad password attempts and their source IP address and then adding those source IP addresses to a locally managed IP black list on your firewall (see above) after say 6 bad password attempts and in 15 minute period of time could also limit the vulnerable surface area of your Emby server from a brute force attack.

 

I tried this in windows. I built powershell and a lite flat file parsing application. I then would would write the data to a small DB and add that back to PFBlockerNG in PFSense. It was not very reliable and required a lot of care and feeding.

 

Recently I moved my Emby server to ubuntu server and am going to try to get fail2ban up and running in a similar way.

 

- MFA (multi-factor authentication)

Implementing a good MFA could also be implemented to help reduce your surface area mitigate brute force attacks.

 

Google/M$ 2FA authentication could be used but the login support isn’t natively supported in Emby. I would love to be able to do this natively within Emby.

 

Another option is to implement client certificate authentication using a private CA (certificate authority) and a good reverse proxy. I have tested this with some success but would really need a better way to deploy and disseminate the config’s.

 

 

Sent from my iPhone using Tapatalk

Edited January 24, 2019 by Tur0k

[Carlo 4330]

But all you have effectively done is change your external IP using TorGuard and nothing more.  Nothinng wrong with that if you are intentionally trying to make your exit point a different location for accessing other services.  But for anyone accessing your server it's not doing anything at all what-so-ever.  If you server was not using SSL then all info sent/received from the client is still in the open going out over the internet.

 

Anyone running a port scan on TorGuads's IPs will find your Emby server and can freely communicate with it.  The "Hacker" won't care that "half" of your link is running through a tunnel with encryption as his side is not.  To the hacker it's an open server.  So without SSL on the Emby server (not saying your not doing this) it's not encrypted in any meaningful way at all.

 

That's for Noobs who might think using a public VPN provider is helpful security wise.  As you said, to be secure the encryption has to be from the client to the server.

 

 

You seem to make a lot of wrong assumptions.....but ok, whatever floats your boat. I'm not going to compete.

I'm not sure what you think I've got wrong.  You get a port to use from TorGuard VPN service to use for inbound connections correct?

You then set this up to match Emby correct so that outside clients can get to your Emby installation correct?

 

You could have a true external IP such as 125.5.5.60 assigned to your router (static or DHCP) but get a new external IP from your VPN provider such as 182.136.10.76.

 

All Emby traffic going out on the internet would then EXIT from 182.136.10.76.  All traffic on the tunnel is encrypted but once it leaves 182.136.10.76 it's normal unencypted traffic if not using SSL.  Therefore anyone on the Internet access your port on 182.136.10.76 is now communicating with your Emby server unencrypted (again if not using SSL via Emby).  So to the world all this has done is obfuscate your Emby/LAN IP but the Emby port since it's still available to access without any type of VPN or other encryption (unless SSL is setup in Emby).

 

Your router is still sitting on the Internet as normal even though VPN is running through it as well.  It too is still just as vulnerable as it always was.

 

The VPN in this case only keeps your upstream providers (to the point of the VPN exit node) from doing a "man in the middle" or spying on your Emby traffic.

[pir8radio 1292]

I think what a few have suggested for a secure setup is using a private vpn, where only the server and clients reside on that encrypted network.     

 

As I have said before https is not the end all to end-end security, man in the middle is still pretty easy..  its easy to trick the end users too..   

 

Check out this forum post...    https://emby.media/community/index.php?/topic/54586-security-101-secure-connections/?p=688979

Removed my HTTPS man in the middle demo.

 

 

After you view the forum post, take a look at the URL in your browser.   I can decrypt and re-encrypt and log all of the clear text.   If I didn't just tell you what I did, you might try to login to the forum again, clear text for me.  Now I have access to your emby connect, it's all about tricking the user..  the best security can be bypassed with a simple oops..  

 

I'll remove this link in a bit. FYI it is not being logged, just decrypting and re-encrypting for this example.

 

Everyone needs to understand that the majority of this stuff is just a speed bump to the hacker, its to make you feel warm, fuzzy and safe.  There is no "one click" I'm safe.....  You have to educate yourself.

Edited January 26, 2019 by pir8radio

[Tur0k 143]

I think what a few have suggested for a secure setup is using a private vpn, where only the server and clients reside on that encrypted network.

 

As I have said before https is not the end all to end-end security, man in the middle is still pretty easy.. its easy to trick the end users too..

 

Check out this forum post... https://emby.media/community/index.php?/topic/54586-security-101-secure-connections/?p=688979

 

After you view the forum post, take a look at the URL in your browser. I can decrypt and re-encrypt and log all of the clear text. If I didn't just tell you what I did, you might try to login to the forum again, clear text for me. Now I have access to your emby connect, it's all about tricking the user.. the best security can be bypassed with a simple oops..

 

I'll remove this link in a bit. FYI it is not being logged, just decrypting and re-encrypting for this example.

 

Everyone needs to understand that the majority of this stuff is just a speed bump to the hacker, its to make you feel warm, fuzzy and safe. There is no "one click" I'm safe..... You have to educate yourself.

Nicely done. I would have to agree. A good hacker is just waiting for users to miss a little something.

 

Your site is SSL encrypted and is using a PKI trusted cert. The domain name is a good give away in your example. It would be the part I train my end users to look for. The problem is that there are even more refined MITM attacks that compromise the screen to hide the real URL. https://youtu.be/Y83JxhZ9aW0

 

 

This is my life at work most days...

 

 

Sent from my iPhone using Tapatalk

[pir8radio 1292]

Nicely done. I would have to agree. A good hacker is just waiting for users to miss a little something.

 

Your site is SSL encrypted and is using a PKI trusted cert. The domain name is a good give away in your example. It would be the part I train my end users to look for. The problem is that there are even more refined MITM attacks that compromise the screen to hide the real URL.

 

 

This is my life at work most days...

 

 

 

Sent from my iPhone using Tapatalk

 

Yea, I just threw that up.. lol but if i was trying to be malicious i would have bought the domain name eemby.media  or something to hide that..  And like you said there are much more refined attacks.       Point is you think you know what's safe when you are demanding features to be added to emby, when you can actually secure things much better on your own with a little education. 

Edited January 25, 2019 by pir8radio

[Carlo 4330]

Nicely done @@pir8radio, couldn't agree with you more.

[gnollo 16]

Not sure how I missed this thread previously but I just read through it to get caught up.

Doofus are you still doing it this way? What VPN service/software are you using?

 

I do a lot of work with fortune 50-500 companies and they all use multi-vendor hardware so that a single exploit can't expose them. Often several layers deep.

 

 

This is not the case. Each and every Plex server get's it's own cert. If you have Plex set to require secure transactions then the whole chain is encrypted just as you would think. Plex.tv is not in the middle unless it uses a relay connection. It's used sort of like a DDNS to find your server and also as the username/password authentication since Plex does not store passwords on the local server (which sucks). But once the authentication is done the client talks directly to the server.

 

Plex doesn't need to "man in the middle" because they already hold all the authentication username and passwords (terrible).

 

What we really want IMHO is something similar to Plex in that it helps you get a dedicated cert for your server but leaves all authentication up to the server itself without being involved in this AT ALL. It can act as the front man to find your server if you have a dynamic IP just as any other DDNS service can presently do. Do that and Emby will be much easier to use via SSL and only a button or two clicks away. Easier said then done of course.

 

Here's a decent blog entry that explain how Plex is doing it: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/

 

What Plex does is OK but since they ARE the authentication facility EVERYONE is always at their mercy and when they have an outage it messes EVERYTHING up. They have far to many outages that are caused by them or Internet routing glitches that get in the way. So in a nutshell their authentication method sucks but the SSL implementation itself is fine.

 

The SUPER SCARY part of the Plex implementation is that a single data breach (they had them before) can/has exposed all client records to the internet and made all servers vulnerable until all users changed their passwords (never happens). In Emby land if one server (yours or mine) was somehow exposed/breached it only affects a few users of that particular server and not EVERY Emby server on the planet. We as the admin of said server can force each user we share with to change passwords or even account names if needed as WE control authentication on our own servers (much better). Emby's approach in this regard is so much better!

 

Plex can also expose a server on the Internet if it hasn't been "claimed" (admin hasn't linked it to their plex.tv account) and this essentially gives the world admin rights to the server. What would be helpful from a security standpoint in Emby is to NOT ALLOW a server to be exposed to the Internet if all user accounts don't have passwords set. No password, no remote access, period type thing.

Hi cayars, thinking of using Cloudflare to connect to Emby like per this guide here

 

https://blog.awelswynol.co.uk/2018/01/setting-up-cloudflare-with-emby

 

Is it a more secure solution than using the plex.ts middleman?

 

Sent from my SM-A520F using Tapatalk

[Spaceboy 2493]

I use cloud flare in front of my nginx reverse proxy. It was incredibly easy to set up and works brilliantly in that my real ip is obscured by them

[mark235 5]

After reading through this thread, I'm a bit confused what the best "low effort / high yield" measures would be to increase my Emby Server security. This doesn't neccesarily have to be Emby security perse, any Windows Server or Router advice is also welcome. If that derails this topic too much, then we can stick to Emby specific advice. I'm only asking the broader questions cause there's a lot on security in general I don't know. Internet facing solutions on my Home server are Emby only at this point, with no immediate plans for others. 

 

Some things I have done to increase security:

- Router: changed the admin password, disabled UPNP, removed port forwards I didn't need anymore (only Emby and Windows Remote Desktop ports are forwarded now). Remote Management is not available on this router, so no need to disable that

- Windows Server 2012 R2: run Windows Update regularly

- Emby: removed admin user from logon screen, renamed admin user and set strong password, restricted media deletion to admin user only, enabled Emby connect and strong passwords for all other users (password is only required when remote connecting with these accounts)

 

Some things that probably should be addressed? The question mark is intentional, I have no idea how big of a risk these things are

- Router: ?

- Windows Server 2012 R2: I login to the server using the built in admin account, which is secured with a strong password. I read that this is a big no no in big domain corporate networks, but how bad is it for one independant home server?

- Emby: using unsecured http connection.

- Other stuff I haven't thought of??

 

Again, I'm preferably looking for quick wins here, a bit like the tickbox Emby security solution that @ has described previously in this thread. I'll consider more elaborate setups, as long as they are one-time only, and I don't have to re-visit them every few months. As a last note, I'd prefer not to go the VPN route, the ones I tried so far have always had a big negative bandwidth impact (my connection is 200mbit down, 20mbit up), plus it will give my external users hassle when they connect to my server. 

[lorac 100]

From my perspective the easiest solution is to have your own domain setup through CloudFlare.

 

Sent from my ONEPLUS A6003 using Tapatalk

[Tur0k 143]

After reading through this thread, I'm a bit confused what the best "low effort / high yield" measures would be to increase my Emby Server security. This doesn't neccesarily have to be Emby security perse, any Windows Server or Router advice is also welcome. If that derails this topic too much, then we can stick to Emby specific advice. I'm only asking the broader questions cause there's a lot on security in general I don't know. Internet facing solutions on my Home server are Emby only at this point, with no immediate plans for others.

 

Some things I have done to increase security:

- Router: changed the admin password, disabled UPNP, removed port forwards I didn't need anymore (only Emby and Windows Remote Desktop ports are forwarded now). Remote Management is not available on this router, so no need to disable that

- Windows Server 2012 R2: run Windows Update regularly

- Emby: removed admin user from logon screen, renamed admin user and set strong password, restricted media deletion to admin user only, enabled Emby connect and strong passwords for all other users (password is only required when remote connecting with these accounts)

 

Some things that probably should be addressed? The question mark is intentional, I have no idea how big of a risk these things are

- Router: ?

- Windows Server 2012 R2: I login to the server using the built in admin account, which is secured with a strong password. I read that this is a big no no in big domain corporate networks, but how bad is it for one independant home server?

- Emby: using unsecured http connection.

- Other stuff I haven't thought of??

 

Again, I'm preferably looking for quick wins here, a bit like the tickbox Emby security solution that @ has described previously in this thread. I'll consider more elaborate setups, as long as they are one-time only, and I don't have to re-visit them every few months. As a last note, I'd prefer not to go the VPN route, the ones I tried so far have always had a big negative bandwidth impact (my connection is 200mbit down, 20mbit up), plus it will give my external users hassle when they connect to my server.

I will address this via difficulty level and attack vector.

 

I. The minimum in my opinion is:

 

1. PROTECT YOUR ADMIN ACCOUNT

A. Don’t connect your Emby connect account to your local Emby system as the admin account.

B. Use strong passwords for your accounts.

C. I don’t recommend having user account names listed by default on the login screen in Emby.

 

2. SECURE AUTHENTICATION

A. Some people use SSL encryption by Pickup a public domain and provision secured (HTTPS) access to your web accessible content either locally or through a public proxy.

B. Others choose external encryption using a vpn tunnel between

I. two trusted networks (yours and someone else’s),

II. Your network a remote user on the public Internet.

 

Either way:

* Use best practices in encryption and protocol cipher suite support.

** ensure that you have some type of encryption from your Emby server to the remote client and back.

*** if you are not running an RDGATEWAY in front of your RDP host I would look into hosting an ssh tunnel in front of your RDP host server.

 

II. Easy-ish improvements beyond that:

1. DDOS PROTECTION,

I agree with Lorac, set up your domain with Cloudflare. Cloudflare will obscure your home WAN public IP from attacks.

 

III. More complex improvements.

1. BRUTE FORCE ATTACKS.

Look into software that you can integrate and develop a process to capture bad password attempts from the public Internet and block them from further access to your Emby front end and RDP. Look into wail2ban (there are limitations to it, and I am not sure how well supported it is.

2. Limit public Internet access logon hours or source regions.

3. MFA integration

A. Client certificate authentication.

B. Integrate with third party MFA providers like duo or google auth.

 

 

 

Sent from my iPhone using Tapatalk

Edited February 4, 2019 by Tur0k

[Fratopolis 62]

Question! For those who are suggesting VPN what you you doing for family members using firetvs.

 

Mom has her own emby server at her house but switches to mine ocassionally.

 

Right now all I'm doing is https with letsencrypt.

 

Really not sure how much I'm worried about being hacked though.

[Guest asrequested]

Question! For those who are suggesting VPN what you you doing for family members using firetvs.

 

Mom has her own emby server at her house but switches to mine ocassionally.

 

Right now all I'm doing is https with letsencrypt.

 

Really not sure how much I'm worried about being hacked though.

 

I don't do anything. Everything works. I have someone with a firetv stick in another country, and it works just fine. Nothing to do, just log in and play.

 

But again, a VPN isn't hackproofing. It just stops all you're private data reaching the internet. And if someone does get your IP, you just pick a new one. 

 

I don't see the point in encrypting your emby server. Don't think it can't be decrypted, because it can if they really wanted to. And you have to open a port through your firewall, anyway. So it's like "hey, I've got a big hole in my security, come on in. You can look at anything you like, but you can't watch my movies". Kinda pointless. 

 

I run my VPN on my router, and I've increased the firewall security, to help filter the big hole I put in it. If you really want decent security, you'll want a reverse proxy.

Edited February 4, 2019 by Doofus

[Fratopolis 62]

Are you leaving VPN connected at all times on the fire stick?

[Guest asrequested]

Are you leaving VPN connected at all times on the fire stick?

 

The VPN is running 24/7

[Fratopolis 62]

Hmm. Might think about that.

 

Though I can change my IP and my domain name within a couple minutes including sslcert in case of ddos.

 

Thanks for the info