Security 101: Secure Connections

[Guest asrequested]

I know Emby now has black/white listing of IP's (all but useless tbh unless your clients are using static IP's/ddns..) but I would have thought that a password lockout policy would be pretty easy for Emby to implement - does anybody know why this hasn't yet been done as for me, this is high on the 'security' list .. ? 3 attempts, then lockout the IP for 15 minutes, then 30, then 60, then 120 etc etc

You mean like its own implementation of fail2ban? Now that would be cool. pfsense' firewall has that option, but having a simple instruction like that in the Emby server would be awesome!

[rbjtech 4257]

You mean like its own implementation of fail2ban? Now that would be cool. pfsense' firewall has that option, but having a simple instruction like that in the Emby server would be awesome!

 

Yea - I have a Snort IPS in front of my host in a DMZ    but having the functionality within the program for those hosting on their 'internal' network is something I would like to see and should imo be standard on any internet facing service nowadays..  

 

Just looked on the feature request list - and yep, it's already on there ..

 

https://emby.media/community/index.php?/topic/63810-auto-ban-of-ips/?hl=fail2ban&do=findComment&comment=632824

Edited February 22, 2019 by rbjtech

[Guest asrequested]

Yeah, I have Snort running, too.

[kingbily 1]

Hello, all

Coming from the Plex world Secure Connections was easy to turn on (actually on by default).  I am trying to determine if Emby has that on by default or what steps I might have to perform or if it's a non-issue.  I am really hoping whatever is involved is pretty straight forward.  When I (or a friend) is accessing my Emby server remotely I'd like to be reasonably secure.  I liked that "no brainier" aspect to Plex.  When I looked in the "Hosting" area of Emby server I saw a check box for requiring HTTPS (the equivalent of secure connects... maybe?) but it then asked me about Certs and stuff and I got lost.  I'd rather not go to Plex for external access.  I really think Emby is a superior product in many ways.

 

Also, if there is a particular section of Emby (Guide/Site or etc) that really breaks down most of the security related data I'd appreciate.  I'd like to be more knowledgeabe.  What I've found in the forums is not really clear to me and seems to be spread all over the place.

Lucky Patcher 9Apps VidMate

Thank You

I think I have one of the simplest setups possible.

 

 

 

1. Purchased SSL cert for $5/year (Good for 3 years without renewal)

 

2. Purchased Google domain for $12/year

 

3. Generated CSR using openssl. Can use online tools if you trust them.

 

4. Verified domain by running a temporary webserver to host key (domain.com/.well-known/pki-validation/). Once verified webserver is no longer needed.

 

5. Use openssl to generate pfx from csr and pem file. Can use online tools if you trust them.

 

6. Enter your external domain and path to your pfx into Emby.

 

 

 

Now I have a pfx good for 3 years that can be used directly in Emby. No need for a reverse proxy or cloudflare but both could be used if wanted.

 

 

 

Emby could integrate some of the functions of openssl and hosting the domain verification to make things very simple but that might be outside the scope of the software.

Edited February 24, 2019 by kingbily

[AmericanCrisis 28]

Quick questions:

 

1. Focusing beyond encrypting the data coming in (https) for a moment. Does anybody have any solid recommendations for anti-virus, malware, bot, etc. detection, protection and removal?

 

The weirdest thing happened to me yesterday (which is why I read this entire thread last night) which has made me extremely paranoid. My Emby domain was pointed away from Emby and some spam like popup message appeared from Xfinity (see the link here ). Also, I use NO-IPs "DUC" on my server to point the IP address to NO-IP. That somehow was consequently turned off and the domain was hijacked until I recycled the DUC.

 

My question, if something entered through the opened port (a bot?) how would I know? How does this even happen since the server is literally just sitting there idle unless a client requests media from Emby server? The server box itself isn't used for anything else (checking email, web browsing, etc.). What strong software out there has the ability to find these vulnerabilities? I was thinking Spybot Search and Destroy. Or should I stick with Norton (which I haven't purchased in years).

 

2. I have some clients that have a manually created user account and some that have only Emby Connect. Which is the most secure option? 

 

3. For a strong Firewall at the network router level is something like a Unifi USG or Netgate pfSense Security Gateway Appliance a stronger "firewall" than something like a Netgear residential router? 

[Guest asrequested]

Quick questions:

 

1. Focusing beyond encrypting the data coming in (https) for a moment. Does anybody have any solid recommendations for anti-virus, malware, bot, etc. detection, protection and removal?

 

The weirdest thing happened to me yesterday (which is why I read this entire thread last night) which has made me extremely paranoid. My Emby domain was pointed away from Emby and some spam like popup message appeared from Xfinity (see the link here ). Also, I use NO-IPs "DUC" on my server to point the IP address to NO-IP. That somehow was consequently turned off and the domain was hijacked until I recycled the DUC.

 

My question, if something entered through the opened port (a bot?) how would I know? How does this even happen since the server is literally just sitting there idle unless a client requests media from Emby server? The server box itself isn't used for anything else (checking email, web browsing, etc.). What strong software out there has the ability to find these vulnerabilities? I was thinking Spybot Search and Destroy. Or should I stick with Norton (which I haven't purchased in years).

 

2. I have some clients that have a manually created user account and some that have only Emby Connect. Which is the most secure option? 

 

3. For a strong Firewall at the network router level is something like a Unifi USG or Netgate pfSense Security Gateway Appliance a stronger "firewall" than something like a Netgear residential router? 

 

1. Sophos Home

 

2. Connect is better. Don't give them your IP

 

3. I have a USG Pro 4 running behind pfsense. Each has their own pros. But you can build pfsense on better hardware, and you can run Snort or pfblocker IPS to filter IPs. To know what's happening, you can check their logs. Both have that.

[Carlo 4330]

Encryption doesn't have anything to do with data coming in, data can come into the port regardless of its encrypted or not.  I think he's saying having a single port open that Emby is listening on isn't a very large vulnerability in itself.  Unless they can exploit Emby through some currently unknown vulnerability to modify files or run arbitrary code they shouldn't be able to do anything beyond continually guess your password. 

 

The encryption is to prevent the authentication from being intercepted in transit by a third party because a malicious authenticated user could do some damage.  

 

-Edited for clarity

Exactly what I was saying.

 

I know all of that. My questions were rhetorical. I was trying to make a point that emby encryption has nothing to do with securing an open port on your firewall. And that open port is a vulnerability for the entire network.

I'd still say not really from a practical standpoint.  Put another way, it's not really anymore dangerous then having the internet connection itself.  Remember ports get opened/closed all day long by all kinds of programs running on computers/devices on your network.  Your router allows ports to be opened allowing incoming data from the simple fact that something INTERNAL opened a communication out.  This is far more "worry some" to most networks then a pre-defined ip/port opening that you know is secured.  This is how most breaches take place by "tricking" the computer to open the ports for you.

 

I know Emby now has black/white listing of IP's (all but useless tbh unless your clients are using static IP's/ddns..) but I would have thought that a password lockout policy would be pretty easy for Emby to implement - does anybody know why this hasn't yet been done as for me, this is high on the 'security' list .. ?  3 attempts, then lockout the IP for 15 minutes, then 30, then 60, then 120 etc etc 

 

Now this I 100% agree with and have asked for previously.  This to me is a missing piece that would help to secure Emby better.  Any bad connection attempt (not just username/password) should kick off a counter and after X attempts is locked out for Y minutes.

 

Emby should also do reverse lookups of country as well so we can only allow specific country IPs to connect.  Sure a hacker could use a VPN but if you ever look at connection attempts to your network you will see tons of connection attempts from places you know are not valid clients.  I for example have NO CLIENTS from any country other then USA so I don't need to allow connections from any other place.  Thus if Emby could block all connections not originating from the USA then dynamically blocks bad attempts as just mentioned it just became MUCH, MUCH harder to breach.

 

SSL helps to encrypt tokens, usernames, password and things of that nature but in itself doesn't stop brute force attempts.  That's where Geo Location/Country IP and dynamic blocking come in and really help.

[Carlo 4330]

This thread is about security 101 which to me means "basics" not super advanced topics which much of this thread is about!

[Guest asrequested]

 

I'd still say not really from a practical standpoint.  Put another way, it's not really anymore dangerous then having the internet connection itself.  Remember ports get opened/closed all day long by all kinds of programs running on computers/devices on your network.  Your router allows ports to be opened allowing incoming data from the simple fact that something INTERNAL opened a communication out.  This is far more "worry some" to most networks then a pre-defined ip/port opening that you know is secured.  This is how most breaches take place by "tricking" the computer to open the ports for you.

 

 

Right, but we are keeping that port open, 24/7. There's a welcome mat, no 'tricking' needed.

[KMBanana 84]

Right, but we are keeping that port open, 24/7. There's a welcome mat, no 'tricking' needed.

It's a welcome mat for Emby.  To make your server available remotely over the internet is going to expose it to more risk thank keeping it safe inside your LAN, there isn't a way around that.  But having the port open isn't the risk.  The risk is if a vulnerability in Emby is discovered it is reachable by potentially malicious attackers through that port.  

 

The issue with exposing ports isn't the ports themselves, it's exposing the services behind those ports to the open internet.  In the Windows 95 days before the Windows firewall was introduced and people tended to plug their single PC directly into their modem with no NAT router this was a huge problem as every single application that used a port was exposed to the internet basically by default.  Malicious attackers used exposed telnet, smtp, netbios, and other unsecured ports/services that should not have been publicly available to cause quite a lot of problems.  These days though basically everything is behind a NAT router where users have to manually expose ports to allow incoming traffic and the windows firewall is on by default makes this a much rarer issue.  

[Guest asrequested]

I guess what we're talking about is risk assessment. That vulnerability in the service is more likely the way you'd be hacked, as opposed to direct access through the open port. But the open port is still a vulnerability. SSL doesn't stop that, correct?

[Tur0k 143]

Quick questions:

 

1. Focusing beyond encrypting the data coming in (https) for a moment. Does anybody have any solid recommendations for anti-virus, malware, bot, etc. detection, protection and removal?

 

The weirdest thing happened to me yesterday (which is why I read this entire thread last night) which has made me extremely paranoid. My Emby domain was pointed away from Emby and some spam like popup message appeared from Xfinity (see the link here ). Also, I use NO-IPs "DUC" on my server to point the IP address to NO-IP. That somehow was consequently turned off and the domain was hijacked until I recycled the DUC.

 

My question, if something entered through the opened port (a bot?) how would I know? How does this even happen since the server is literally just sitting there idle unless a client requests media from Emby server? The server box itself isn't used for anything else (checking email, web browsing, etc.). What strong software out there has the ability to find these vulnerabilities? I was thinking Spybot Search and Destroy. Or should I stick with Norton (which I haven't purchased in years).

 

2. I have some clients that have a manually created user account and some that have only Emby Connect. Which is the most secure option?

 

3. For a strong Firewall at the network router level is something like a Unifi USG or Netgate pfSense Security Gateway Appliance a stronger "firewall" than something like a Netgear residential router?

So, I view endpoint protection as kind of the last line of defense. Here, I use webroot antivirus. I don’t recommend any third party protection software with a software firewall bundled in. Personally, I prefer my network to take care of those connections. Here, I can stand up a separate VLAN in under 10 minutes. Software antivirus is mostly able to detect infected files, malicious code, and remove it. You still likely want to lock down your BIOS and hard disable BIOS flashing from the OS. In my eyes, this should have been addressed before the packet got to your network by leveraging, DNS black lists, IP black lists, active IDS, web proxying with AV built in, and a few basic authentication practices.

 

It sounds like your DHCP public IP changed, you were likely assigned a new one who’s previous owner was maxed on total data used, and it took some time for Comcast’s proxy in browser notification redirection to figure it out.

 

Here, I block all outbound port 53 requests to the public Internet. Then I setup my network’s dns resolver (hosted on PFsense) to use TLS encrypted Cloudflare DNS. This allows me to secure my public DNS requests across the public Internet. Additionally, this allows me to ensure that I am not being fed incorrect dns responses by my ISP.

 

I further secure some of my traffic with a VPN browser to further secure my internet activity in the event I want to be further protected from sniffing and proxying.

 

An open port is just that an open port. You really only want to open ports that are needed for a service you want. It becomes a risk when it is:

 

1. Not fully secured (ex: SSL encrypted) at login and during activity, to an untrusted network (IE: the Internet).

If login is unencrypted then authentication is passed open text. So, it isn’t really that difficult to get the credentials if there is compromised piece of network equipment (there are way more of these compromised devices out there than you think...) between your server and the public Internet.

 

2. Insufficient security.

A. Insufficient encryption/cipher combinations.

B. No/insufficient authentication requirements.

I. In the case of Emby, User accounts listed at login (this is half the authentication process)

II. Simple/no password.

III. Unlimited authentication attempts. This allows unlimited brute force attacks.

Setup fail2ban.

IV. MFA.

V. Use of simple gimme account names (root, admin, administrator, enable, etc.). Alternately, don’t connect dots for an attacker (ex: usernames and your domain (ex username “John” and domain “John.doe.com”.)

 

3. Insufficient authorization configuration.

A. There needs to be appropriate measures to control administrative access.

 

There is a rule in IT that states that permissions should be granted from the perspective of “minimum permissions necessary”. This means that users should only get what they need.

 

B. Limit login sources. Limit the users that are allowed to login from the public Internet. Limit administrative accounts to only be able to login from the local network.

 

Additionally, I don’t tie my Emby connect authentication to my Emby server’s admin account. This is a personal preference. IMHO, Emby connect has lower restrictions on authentication because it is aimed as a service for users whom are novices, which is fine, I just want some added obscurity for my system’s administrative access.

 

4. Leaving an vulnerability un-patched on a publicly or local network facing system.

Keep systems fully patched.

 

Here, I use PFSense as my firewall. I also have a Unifi wireless AP, and a Unifi Poe managed L2 switch. My network works like a champ. The only thing I don’t get is the router bubble in the unifi controller. PFsense has a plethora of features and capabilities.

Routing functions.

VLAN termination.

DNS resolver.

DNS blacklist.

DNS over TLS.

Well developed firewall ACL configuration.

IPV4/6 Black lists.

Reverse proxy.

let’s Encrypt ACME to manage certificates.

IDS.

Web proxy with AV.

VPN lan to lan.

VPN end point to LAN.

VPN to private VPN browsing service.

 

Edited for accuracy

 

Sent from my iPhone using Tapatalk

Edited February 24, 2019 by Tur0k

[KMBanana 84]

Best practices is to close ports whenever possible, but if you want to host something on the internet you need a port open.  I don't think having a port open should be considered a vulnerability, just a function of the risk of having your server exposed to the internet in the first place.  I could spin up a VPS with digital ocean and expose 50,000 ports to the internet with no antivirus or firewall or anything and the server would be fine so long as I kept it up to date and didn't expose the ports for dangerous running services like SSH, Telnet, SMB, RDP, etc.  

 

Going to write up a more in depth post on some of the security methods and post it in a bit.  

[KMBanana 84]

Security methods with Emby

 

Local only

A very simple way to keep your server protected is to not expose it on the internet at all.  Don't open a port in your router and outside connections to your server will not be possible.  If you don't need remote access to Emby, don't enable it.  

 

Expose HTTP port (8096 by default)

DON'T DO THIS.  I see a lot of people start this way to get their server online, but it's extremely risky.  Emby is now reachable over the public internet with no protections.  Bots are constantly scanning all publicly reachable IP and port ranges looking for servers so your server being attacked isn't a matter of someone targeting your server intentionally, but something that is guaranteed to happen.  With http exposed to the internet any legitimate logins are being sent with their credentials in plain text which means they can be easily intercepted and used to login to your server.  What is being watched on the server or any other activity can be trivially identified by your ISP or anyone able to read or intercept the data in transit.  It puts your users at risk from a man in the middle modifying the content on its way from your server to them.  

 

Expose HTTPs port (8920 by default)

Your server is still exposed to the internet but now via encrypted connections.  Malicious attackers will still be able to see the server exposed on the internet and attempt random logins, but are unlikely to accomplish much.  Some security mitigations are posted below.  If your putting your server on the internet this is the MINIMUM level of security you should implement.  Admittedly it can be a little annoying to get a proper cert set up which just about all Emby apps require but it's absolutely worth it.  

 

Reverse Proxy (Nginx, caddy, Apache, Nginx Proxy Manager)
Rather than expose Emby directly, you put it behind a reverse proxy.  The reverse proxy listens on a single port (443 for encrypted connections) and redirects incoming traffic to local ports that aren't directly exposed to the internet.  This lets you host multiple services with just a single port open.  A lot of reverse proxies will also handle https and acquiring/renewing the cert for them and may include other security benefits like fail2ban or basic auth.  Your emby server will still be publicly reachable via its domain name, but not via IP:port which will cut down on the random and automated scanning and attacks your Emby server faces.  Your server is at risk of any potential vulnerabilities in the reverse proxy application, but most of these like Nginx and Apache get a lot more scrutiny than Emby does.  Make sure you keep any reverse proxy software up to date.  If port 80 is open it should only be to redirect to 443.  

 

VPN

With a VPN you keep your server off the public internet like with local only, but you setup a VPN that users can connect to to effectively access your local network from outside.  You'll still have publicly reachable server, either on the emby server directly or an external server both you and the remote users connect to.  VPN services are going to be much more reviewed for security than Emby is though.  Like with a reverse proxy make sure to keep your VPN software up to date.  

 

Keeping an Emby server behind a proxy

I haven't done this and not too sure about it.  Presumably your proxy provider might do some firewall filtering on their end before sending the traffic to you and will also provide some basic obfuscation of your home IP and location.  How effective either benefit is I can't say.  Cloudflare provides this for free with their DNS service but you need your own domain.  Can be used in conjunction with a reverse proxy. 

 

Specific security remediations: 

• Fail2Ban:  Watches logs and bans IPs after things like repeated invalid login attempts or probing for your server for potential IPs.  I don't think there's a way to set this up with Windows at the moment but it's worth doing for other platforms.  As other have mentioned it would be great if Emby implemented a feature like this internally.
• Blocking countries: Typically done in your router or firewall, you can prevent a lot of the automated scanning, probing and attacks on your server by banning the IP ranges of countries like China, Russia, Saudi Arabia.  Assuming you have no legitimate users in those countries obviously.  Also a feature it would be nice to do from within Emby, but may be more suited technically for your router/firewall.  
• Hide all users from login screens: Recommend doing this if your server is exposed to the internet.  If a user uses the same User/Pass here on another site or service that is hacked they could use the exposed credentials to then login to your server.  An Emby option checkbox to hide all users rather than it being a per-user option would be nice.  Also should probably be default for remote connections.  
• Make 100% sure all users have a password: Self explanatory, should probably be a default in Emby to be honest.  
• Check your Emby dashboard periodically: Can see failed login attempts or if a single user has logged in from multiple IPs.  
• Secure passwords: Make sure your users aren't using passwords like monkey123

Edited February 23, 2019 by KMBanana

[Spaceboy 2493]

Security methods with Emby

 

Local only

A very simple way to keep your server protected is to not expose it on the internet at all. Don't open a port in your router and outside connections to your server will not be possible. If you don't need remote access to Emby, don't enable it.

 

Expose HTTP port (8096 by default)

DON'T DO THIS. I see a lot of people start this way to get their server online, but it's extremely risky. Emby is now reachable over the public internet with no protections. Bots are constantly scanning all publicly reachable IP and port ranges looking for servers so your server being attacked isn't a matter of someone targeting your server intentionally, but something that is guaranteed to happen. With http exposed to the internet any legitimate logins are being sent with their credentials in plain text which means they can be easily intercepted and used to login to your server. What is being watched on the server or any other activity can be trivially identified by your ISP or anyone able to read or intercept the data in transit. It puts your users at risk from a man in the middle modifying the content on its way from your server to them.

 

Expose HTTPs port (8920 by default)

Your server is still exposed to the internet but now via encrypted connections. Malicious attackers will still be able to see the server exposed on the internet and attempt random logins, but are unlikely to accomplish much. Some security mitigations are posted below. If your putting your server on the internet this is the MINIMUM level of security you should implement. Admittedly it can be a little annoying to get a proper cert set up which just about all Emby apps require but it's absolutely worth it.

 

Reverse Proxy (Nginx, caddy, Apache, Nginx Proxy Manager)

Rather than expose Emby directly, you put it behind a reverse proxy. The reverse proxy listens on a single port (443 for encrypted connections) and redirects incoming traffic to local ports that aren't directly exposed to the internet. This lets you host multiple services with just a single port open. A lot of reverse proxies will also handle https and acquiring/renewing the cert for them and may include other security benefits like fail2ban or basic auth. Your emby server will still be publicly reachable via its domain name, but not via IP:port which will cut down on the random and automated scanning and attacks your Emby server faces. Your server is at risk of any potential vulnerabilities in the reverse proxy application, but most of these like Nginx and Apache get a lot more scrutiny than Emby does. Make sure you keep any reverse proxy software up to date. If port 80 is open it should only be to redirect to 443.

 

VPN

With a VPN you keep your server off the public internet like with local only, but you setup a VPN that users can connect to to effectively access your local network from outside. You'll still have publicly reachable server, either on the emby server directly or an external server both you and the remote users connect to. VPN services are going to be much more reviewed for security than Emby is though. Like with a reverse proxy make sure to keep your VPN software up to date.

 

Keeping an Emby server behind a proxy

I haven't done this and not too sure about it. Presumably your proxy provider might do some firewall filtering on their end before sending the traffic to you and will also provide some basic obfuscation of your home IP and location. How effective either benefit is I can't say. Cloudflare provides this for free with their DNS service but you need your own domain. Can be used in conjunction with a reverse proxy.

 

Specific security remediations:

• Fail2Ban: Watches logs and bans IPs after things like repeated invalid login attempts or probing for your server for potential IPs. I don't think there's a way to set this up with Windows at the moment but it's worth doing for other platforms. As other have mentioned it would be great if Emby implemented a feature like this internally.
• Blocking countries: Typically done in your router or firewall, you can prevent a lot of the automated scanning, probing and attacks on your server by banning the IP ranges of countries like China, Russia, Saudi Arabia. Assuming you have no legitimate users in those countries obviously. Also a feature it would be nice to do from within Emby, but may be more suited technically for your router/firewall.
• Hide all users from login screens: Recommend doing this if your server is exposed to the internet. If a user uses the same User/Pass here on another site or service that is hacked they could use the exposed credentials to then login to your server. An Emby option checkbox to hide all users rather than it being a per-user option would be nice. Also should probably be default for remote connections.
• Make 100% sure all users have a password: Self explanatory, should probably be a default in Emby to be honest.
• Check your Emby dashboard periodically: Can see failed login attempts or if a single user has logged in from multiple IPs.
• Secure passwords: Make sure your users aren't using passwords like monkey123

great write up. I do all of this. Rather than use fail2ban I use a script, that a very helpful person wrote, that updates my nginx blacklist with ips from failed logins

[AmericanCrisis 28]

1. Sophos Home

 

2. Connect is better. Don't give them your IP

 

3. I have a USG Pro 4 running behind pfsense. Each has their own pros. But you can build pfsense on better hardware, and you can run Snort or pfblocker IPS to filter IPs. To know what's happening, you can check their logs. Both have that.

 

Thanks for the response!

 

I'll take a look at Sophos Home, as well as Webroot. Any reason why this is recommended? 

 

Why is connect better? Does it obscure the public IP address somehow? Or is it simply because the user won't know the domain name?

 

I'm familiar with Unifi hardware, but I'm still confused how Unifi hardware runs "behind" pfSense. @@Tur0k mentioned he has this config as well. How do you load a Unifi router with pfSense?

[AmericanCrisis 28]

So, I view endpoint protection as kind of the last line of defense. Here, I use webroot antivirus.

 

Great post! 

 

You mentioned disable BIOS flashing at the OS. Is this simply by just not having the bundled motherboard utility installed? Or is there a BIOS setting?

 

I'm assuming blocking outbound port 53 requests are done at the router level and not server level? Again, can you explain how you are using pfSense and a Unifi router? Which model router and how do I integrate pfSense? I would like to get the router ordered tonight.

[Guest asrequested]

Thanks for the response!

 

I'll take a look at Sophos Home, as well as Webroot. Any reason why this is recommended? 

 

Why is connect better? Does it obscure the public IP address somehow? Or is it simply because the user won't know the domain name?

 

I'm familiar with Unifi hardware, but I'm still confused how Unifi hardware runs "behind" pfSense. @@Tur0k mentioned he has this config as well. How do you load a Unifi router with pfSense?

 

I have pfsense as my router (i.e. connects directly to the modem). On that, I run a VPN interface and Snort IPS. This is my first line of defense (technically, the VPN service is). The USG is connected to pfsense, as a gateway, and pfsense assigns an IP as though it were just another device. I then use a different subnet, and I use the USG to manage the rest of the network. I didn't actually set out to do this, but ended up with this hardware and figured I'd put it to use. I don't want to use a domain, certs and reverse proxies, just for emby. I'd prefer to fortify the entire network. It isn't impregnable by any stretch, but it'll give attackers a few more obstacles. I mean really, it's just movies 

[Tur0k 143]

Great post!

 

You mentioned disable BIOS flashing at the OS. Is this simply by just not having the bundled motherboard utility installed? Or is there a BIOS setting?

 

I'm assuming blocking outbound port 53 requests are done at the router level and not server level? Again, can you explain how you are using pfSense and a Unifi router? Which model router and how do I integrate pfSense? I would like to get the router ordered tonight.

It is a setting in BIOS.

 

Yes probably best to do this at the firewall in order to globally affect all users on your LAN.

 

I don’t have 2 firewalls. I only have a PFSense firewall. I don’t run a Unifi USG (firewall). I have played with them and the EdgeRouters before. They do the job, but I prefer the feature set in PFSense.

 

I do have a Unifi POE switch and unifi wireless access point.

 

 

Sent from my iPhone using Tapatalk

[rbjtech 4257]

B. Limit login sources. I would love to be able to restrict public Internet login. I would definitely limit my administrative accounts to only be able to login locally. That isn’t currently possible in Emby.

 

 

Yes it is - and what I do.  The ONLY 'manager' of my system cannot login remotely as I have unticked the option to do so 

 

 

 

And going best practice, your admin account should never be used as a 'user' anyway - so it shouldn't be a hardship to have a separate account for this ...

 

all my other accounts (assuming they have remote access) are set the opposite ..

 

Edited February 24, 2019 by rbjtech

[Tur0k 143]

Yes it is - and what I do. The ONLY 'manager' of my system cannot login remotely as I have unticked the option to do so

 

And going best practice, your admin account should never be used as a 'user' anyway - so it should be a hardship to have a separate account for this ...

Good looking out. I do see it in the user settings!!!

 

 

Sent from my iPhone using Tapatalk

[PrincessClevage 173]

I have raise a ticket with the smart chaps at firewalla (a new security product) as they can already monitor failed security attempts to some protocols if they could possibly integrate with Emby and possibly provide a built in service similar to fail2ban

Product can be found here:

https://firewalla.com

Will be interesting to see if they come up with anything.

P.s they mentioned that they would possibly have to read Emby logs for failed attempts

[phi303 11]

 

I think I have one of the simplest setups possible.

 

 

 

1. Purchased SSL cert for $5/year (Good for 3 years without renewal)

 

2. Purchased Google domain for $12/year

 

3. Generated CSR using openssl. Can use online tools if you trust them.

 

4. Verified domain by running a temporary webserver to host key (domain.com/.well-known/pki-validation/). Once verified webserver is no longer needed.

 

5. Use openssl to generate pfx from csr and pem file. Can use online tools if you trust them.

 

6. Enter your external domain and path to your pfx into Emby.

 

 

 

Now I have a pfx good for 3 years that can be used directly in Emby. No need for a reverse proxy or cloudflare but both could be used if wanted.

 

 

 

Emby could integrate some of the functions of openssl and hosting the domain verification to make things very simple but that might be outside the scope of the software.

 

 

 

can i ask where purchased your sSL?

[fizzyade 124]

There's a custom script plugin I saw mentioned on here the other day, that could potentially be used with acme.sh to automatically generate letsencrypt certificates very easily for free.

 

I guess somebody could write a plugin that calls acme.sh as well.

[Swynol 375]

There's a custom script plugin I saw mentioned on here the other day, that could potentially be used with acme.sh to automatically generate letsencrypt certificates very easily for free.

 

I guess somebody could write a plugin that calls acme.sh as well.

It depends what verification method you use. You cant really automate DNS verification with let's encrypt.

 

Sent from my ELE-L29 using Tapatalk