Server is binding to all network interfaces

[Guest]

Hi, my emby server is set to use a specific Interface, via the <LocalNetworkAddresses> tag in the xml settings, yet it binds to all four of my network interfaces, not just the one its supposed to. It is also reachable from each interfaces IP Address on port 8096. Is there some other setting that needs to be changed to get the server to stop listening on all the interfaces?

Edited July 10, 2023 by lukeoslavia

[Luke 42078]

HI, the server binds once with the OS that allows it to listen on all addresses. There is no option to change this.

The local addresses option that you mention only changes what LAN address the server will report to Emby apps as the local network address.

[Guest]

Is there any plan in the future to change this? It seems a bit lax to allow it to use all adapters, I have fixed it manually for now, but would like an easy option setting if possible.

Also, while fixing this I noticed that even though I did not allow UPnP during installation and had remote access turned off, emby added a rule to the windows firewall to allow traffic on port 8920.

[pwhodges 2012]

Well, it needs to allow traffic to other local machines, right?

Paul

[Luke 42078]

1 hour ago, lukeoslavia said:

Is there any plan in the future to change this? It seems a bit lax to allow it to use all adapters, I have fixed it manually for now, but would like an easy option setting if possible.

Also, while fixing this I noticed that even though I did not allow UPnP during installation and had remote access turned off, emby added a rule to the windows firewall to allow traffic on port 8920.

the way it is now is the most practical because we can bind to one socket once and it will cover everything. To bind to individual addresses will require more socket management within emby server, including a separate one for localhost. it would take a bit of work. 

[Guest]

Agreed, but I wouldn't be upset if it happened!

[Guest]

57 minutes ago, pwhodges said:

Well, it needs to allow traffic to other local machines, right?

Paul

Yes, it does need to allow traffic to local machines.

[rbjtech 5284]

I understand the entire 'emby install' and security implications are being looked at ( @softworkz) - this is just one aspect of things that need 'correcting' because the install introduces a poor security model and executes administrive changes without the users knowledge (even if not selected).    The upnp/firewall is also a peeve of mine - infact I raised it not long ago as I was also alarmed to find things 'open' when I had expecitely not selected the 'remote' option ..

[softworkz 5066]

18 hours ago, Luke said:

the way it is now is the most practical because we can bind to one socket once and it will cover everything. To bind to individual addresses will require more socket management within emby server, including a separate one for localhost. it would take a bit of work. 

As long as you are not going to develop a software router (huge effort), this is a path driving you straight to hell. It would cost months of sweat and tears and it still wouldn't be working right. There are so many implications to such approach, multiply that with all the platforms Emby is targeting, then multiply by all the different network hardware that would be to deal with, after adding the software counterparts used for virtualization and containerization, then multiply by all the different ways (topology, addressing, routing...) networks can be set up and think about that number which indicates all the different cases where it needs to work. 
Even professional server applications usually don't work like that (besides specific cases where it makes sense).

There's a much easier solution: Using a single socket over all interfaces but rejecting incoming requests which are not addressed to one of the allowed local interfaces (or IP addresses)

[Guest]

2 minutes ago, softworkz said:

As long as you are not going to develop a software router (huge effort), this is a path driving you straight to hell. It would cost months of sweat and tears and it still wouldn't be working right. There are so many implications to such approach, multiply that with all the platforms Emby is targeting, then multiply by all the different network hardware that would be to deal with, after adding the software counterparts used for virtualization and containerization, then multiply by all the different ways (topology, addressing, routing...) networks can be set up and think about that number which indicates all the different cases where it needs to work. 
Even professional server applications usually don't work like that (besides specific cases where it makes sense).

There's a much easier solution: Using a single socket over all interfaces but rejecting incoming requests which are not addressed to one of the allowed local interfaces (or IP addresses)

While I don't entirely disagree with you, saying its difficult isn't a good reason not to do something, especially with software with a large paying user base, and it being a security related issue.

Also, when specifying a specific address in the settings, you are just reporting that address to apps, you are not rejecting traffic on the other interfaces as I can access emby on each interface.

The biggest concern to me though is the fact that unchecking UPnP doesn't do anything, emby still opens up ports 8096 and 8920 in the firewall. I only noticed this because I don't use the standard ports.

[Luke 42078]

Unchecking upnp does do something. It will not open ports after doing that. It just won’t close previously open registrations after turning it off. They are temporary though and should eventually expire in your router.

[Guest]

1 minute ago, Luke said:

Unchecking upnp does do something. It will not open ports after doing that. It just won’t close previously open registrations after turning it off. They are temporary though and should eventually expire in your router.

This is not the case with the windows installation. I installed it on fresh windows server 22 installation after moving away from unraid last week and did not have any prior registrations on those ports. Perhaps it is meant to do something, but I have tested this on both my windows 11 pc since and the server to ensure it was actually opening the ports after unchecking upnp. 

[Luke 42078]

5 minutes ago, lukeoslavia said:

This is not the case with the windows installation. I installed it on fresh windows server 22 installation after moving away from unraid last week and did not have any prior registrations on those ports. Perhaps it is meant to do something, but I have tested this on both my windows 11 pc since and the server to ensure it was actually opening the ports after unchecking upnp. 

It probably was already created before you disabled it.

[Guest]

1 minute ago, Luke said:

It probably was already created before you disabled it.

What do you mean by this? Are you saying that my server opened up the two ports for something else before I installed emby and I didn't notice it until after I installed emby?

[Guest]

@LukeAs a sanity check, I just tested this again on my gaming pc.

• I verified that my defender firewall had neither of the standard emby ports opened in advance.
• I installed emby server via the installer on the website.
• I unchecked upnp in the first run wizard/walkthrough/whatever.
• When the windows popup came along to ask if I wanted to allow emby through the firewall, I selected cancel.
• I refreshed my windows defender and both ports are now opened and there are two rules allowing the emby server app through.

If you would like I could record this process and post it someplace for you.

Edited July 11, 2023 by lukeoslavia

[ebr 16181]

1 hour ago, lukeoslavia said:

I verified that my defender firewall had neither of the standard emby ports opened in advance

That's not UPNP.  UPNP communicates with your router for port forwarding - not the firewall.  The server cannot function without the ports open on the firewall.  There would be no point in installing it and not allowing that.

[Guest]

4 minutes ago, ebr said:

That's not UPNP.  UPNP communicates with your router for port forwarding - not the firewall.  The server cannot function without the ports open on the firewall.  There would be no point in installing it and not allowing that.

Could you explain how the server would cease to function without opening those ports? Because the first thing I did was to close them all and then configure the server to use the address and port I wanted.

[ebr 16181]

3 minutes ago, lukeoslavia said:

Could you explain how the server would cease to function without opening those ports? Because the first thing I did was to close them all and then configure the server to use the address and port I wanted.

It won't function without whatever ports being open on the fire wall.  The issue here is probably just that you don't have an opportunity to change the ports in the very initial setup (before it starts running and needing the ports).  Even the setup wizard has to communicate with the server API.

So, if you are going to change the ports (which only very advanced users do) then you also will need to clean up any other open ports - however, these rules should be scoped to port and server executable so the fact they are there when you aren't using those ports isn't really of much consequence I would think.

[Guest]

4 minutes ago, ebr said:

It won't function without whatever ports being open on the fire wall.  The issue here is probably just that you don't have an opportunity to change the ports in the very initial setup (before it starts running and needing the ports).  Even the setup wizard has to communicate with the server API.

So, if you are going to change the ports (which only very advanced users do) then you also will need to clean up any other open ports - however, these rules should be scoped to port and server executable so the fact they are there when you aren't using those ports isn't really of much consequence I would think.

It does seem odd that you would need to open ports in the firewall for your setup wizard to communicate with presumably your local api / api gateway , but perhaps your software works in a way I'm unfamiliar with.

This is primarily a concern to me now because I am no longer configuring the server to run in a docker container, where I was able to be more explicit about the setup than the windows installer allows. So I guess, to me, it would make more sense for your wizard to ask users what port and IP address they would like your software to use, instead of it making assumptions and configurations based on them.

[softworkz 5066]

You must not confuse the Windows Defender Firewall with a network edge firewall - I think that's the misunderstanding here.

On Windows it's more about which kind of network communication is allowed for specific applications. It's not that much about protecting what goes in and out.

Probably the best way would be to register embyserver.exe with ports "Any" like most (including Microsoft) applications do. This saves you from the hazzle of running behind these settings.

[Guest]

19 minutes ago, softworkz said:

You must not confuse the Windows Defender Firewall with a network edge firewall - I think that's the misunderstanding here.

On Windows it's more about which kind of network communication is allowed for specific applications. It's not that much about protecting what goes in and out.

Probably the best way would be to register embyserver.exe with ports "Any" like most (including Microsoft) applications do. This saves you from the hazzle of running behind these settings.

No confusion there, the firewall at my network edge disregards upnp anyway so its not a concern of it getting all the way out of the local network or anything like that. Its more a concern that ports are automatically configured in the windows firewall, and as far as I've seen not automatically cleaned up after they are changed. So like you said you end up with multiple rules for emby to listen to traffic on any port. Then, if you want to specify a port, multiple other rules that say to listen for traffic on X port from any IP.

This doesn't actually present a problem for me or my particular setup, just seems rather lax, in my opinion, which I understand most users would disagree with. 

In the end, better options during setup to specify an IP and port for emby to listen on would be welcomed. If not, I can do it manually.

Edited July 11, 2023 by lukeoslavia

[softworkz 5066]

Just to give you an example:

 

Neither FireFox nor Chrome nor HDHomeRun have ever asked me about making those entries. This is a standard procedure of app installation on Windows. 
The confusing point is rather that Emby uses explicit ports which creates a wrong impression admittedly. We should change to 'Any' like others do. This will reduce hazzle and confusion.

 

[Guest]

2 minutes ago, softworkz said:

Just to give you an example:

 

Neither FireFox nor Chrome nor HDHomeRun have ever asked me about making those entries. This is a standard procedure of app installation on Windows. 
The confusing point is rather that Emby uses explicit ports which creates a wrong impression admittedly. We should change to 'Any' like others do. This will reduce hazzle and confusion.

 

I get what you are saying, I also don't agree with hdhomerun or chrome / firefox or any app really making determinations for me. I also completely understand that I take a very paranoid approach to this where most could not care less.

[softworkz 5066]

32 minutes ago, lukeoslavia said:

I get what you are saying, I also don't agree with hdhomerun or chrome / firefox or any app really making determinations for me. I also completely understand that I take a very paranoid approach to this where most could not care less.

Being paranoic is sometimes a good thing, but in this case it's not justified.

The problem here is that when thinking about this, your mind quickly converges to logical patterns and relations of entities that we have learned from network firewall purposes and behaviors.

But this is something different. This is not drilling a hole into your computers security in any way, because those rules are scoped to the application - it's not about opening access to your system. During installation of applications on Windows, you usually need to confirm the UAE prompt, which in turn gives the setup full permission to do on your system whatever it needs (or wants) to do - to prepare it for running the application. That's why you (should) do this only when trust an application. 

Emby is a personal media server - there's no point in using it just locally, and so there is no point in questioning the user about whether they wants the firewall entries (futurely 'Any') to be made or not. Because the "Or Not" choice would mean to stop and cancel the Emby installation.
I think it's pretty clear to everybody that Emby Server needs to communicate on the network, so it would be really pointless to ask during installation whether user wants to cancel due to Emby Server requiring network access...

[Guest]

5 minutes ago, softworkz said:

Being paranoic is sometimes a good thing, but in this case it's not justified.

The problem here is that when thinking about this, your mind quickly converges to logical patterns and relations of entities that we have learned from network firewall purposes and behaviors.

But this is something different. This is not drilling a hole into your computers security in any way, because those rules are scoped to the application - it's not about opening access to your system. During installation of applications on Windows, you usually need to confirm the UAE prompt, which in turn gives the setup full permission to do on your system whatever it needs (or wants) to do - to prepare it for running the application. That's why you (should) do this only when trust an application. 

Emby is a personal media server - there's no point in using it just locally, and so there is no point in questioning the user about whether they wants the firewall entries (futurely 'Any') to be made or not. Because the "Or Not" choice would mean to stop and cancel the Emby installation.
I think it's pretty clear to everybody that Emby Server needs to communicate on the network, so it would be really pointless to ask during installation whether user wants to cancel due to Emby Server requiring network access...

I might not be clear enough here.

My issue isn't that emby would likely need to be accessed outside of the local machine, the issue is that it is opening ports to listen on any IP address, not just allowing traffic to emby, which isn't clear in the settings or during setup. Which you are in some way addressing in the future.

I don't think its fair to argue that "This is not drilling a hole into your computers security in any way". You are allowing traffic on those ports from any IP address on the local network, which isn't always okay.

I also am not saying to ask for network access in general, I'm asking to be able to set emby's IP address and Port to one of a users choosing during setup. The option can even be prefilled with the default port and a wildcard in the host/IP address section, in addition to that, if we change our port to something else in the future clean up the previous one, or potentially tell a user they should check into it.

I don't believe we will see eye to eye on this. I get the reasoning for what is happening, but it's a reason of convince imo.