[Feature Request] Option for overrding presentationUrl in UPNP Device Service XML

[blindfish]

Hi,

with the release of MinimServer 2.2 more and more configuration options have been moved to the web interface, which is a great thing in my opinion.
However, this makes me want to close down and control access to the web interface better than is currently possible.
I run MinimServer as a docker container with a reverse proxy (traefik v2) in front of the web UI. This makes it possible for me to enable forward authentication using an identity provider of my choice, and also to access the web interface using a proper domain name like https://minim.local.example.com (without having to specify a port).
However, this is a problem for UPNP Device Service Discovery. The device XML file the path to which is published in SSDP NOTIFY messages contains the element presentationURL that always uses the container's (= hosts's for host networking) IP address and the webinterface's port.
Example:

Code:

<?xml version="1.0" encoding="UTF-8"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
    <specVersion>
        <major>1</major>
        <minor>0</minor>
    </specVersion>
    <device>
         ...
        <presentationURL>http://192.168.1.34:9790/</presentationURL>
    </device>
</root>

If a only want the webinterface accessible through a reverse proxy, DLNA will no longer work, because it does not publish the my domain name, but the plain IP address and port.

Ideally it would be possible to set a configuration option for overriding that presentation URL so it looks like this:

Code:

<?xml version="1.0" encoding="UTF-8"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
    <specVersion>
        <major>1</major>
        <minor>0</minor>
    </specVersion>
    <device>
         ...
        <presentationURL>http://minim.local.example.com/</presentationURL>
    </device>
</root>

Other applications that also use DLNA (e.g. JellyFin) offer similar configuration options to make working with reverse proxies possible, so I guess the idea is not completely dumb

Any chance of implementing such an option?

Kind Regards,
blindfish

[simoncn]

(16-07-2023 11:32)blindfish Wrote:  If a only want the webinterface accessible through a reverse proxy, DLNA will no longer work, because it does not publish the my domain name, but the plain IP address and port.

I am not sure why this means DLNA will not work. A UPnP/DLNA control point doesn't use the presentation URL but accesses the server using the base URL of the device.xml file. If a user wants to access the MinimServer configuration web page, they can put the address http://minim.local.example.com/ in their web browser.

[blindfish]

Ok, let me elaborate, might be more of an XY problem here.

Remember, my main goal is to funnel all access to the web interface through a reverse proxy.
If the container is running in host networking mode, there is no way from stopping anyone access the web interface bypassing the reverse proxy (and authentication).
So my first attempt was to add a macvlan to the container so that SSDP would still work, but the web interface would only be accessible on the docker internal bridge network. For that I was looking for a setting to bind the webserver to a specific interface (the internal bridge only). That did not exist.
So next I tried blocking access to 9790 when the requests was coming over the macvlan network using iptables. That for sure works beautifully, while still allowing access the web interface through the reverse proxy.
That was when I found out that content and the web interface are served on the same port and by blocking that port on the macvlan, but SSDP announcing the macvlan's address, I made the whole container non-functioning.

These attempts were made while still learning the ins and outs of the container, I realize the sound (and are!) hacky and not ideal.

So if you have any suggestions on how to achieve the goal of only allowing access to the webinterface through a reverse proxy, that'd be appreciated.
Also, I'm running multiple instances, so having a separate domain for each instance without having to specify a port is real nice.

The web interface and content being served on the same port is not a problem per se, since the reverse proxy would be able to distinguish between the two by inspecting the request URL, but that ofc only works if content is served using a domain name, not an IP address.

Kind Regards,
blindfish

[simoncn]

If I understand this correctly, the issue is not the value returned for presentationURL in the device XML but the use of port 9790 (or a different port configured using the http.port property) for serving audio files and other resources as well as for accessing the configuration web page.

Is this correct? If so, would a solution be for MinimServer to extend the http.port configuration property to allow two ports to be specified, one for serving resources and another for the web UI? The last paragraph of your post seems to suggest that this would not meet your requirement.

[blindfish]

Hi,

thank you so much for bearing with me, highly appreciated!

So let me elaborate even a little bit more, since multiple roads lead to Rome, but some might be shorter and more comfortable to travel on
   

This is how the network setup for the reverse proxy and the MinimServer container look like.
I rely on MinimServer's eth1 for SSDP onto the main network, but I don't want the web interface to be accessible on eth1, only on eth0 over the reverse proxy.

So different solutions come to mind:

• Modifying the presentationURL to use a domain name, which gets routed through the reverse proxy, while using a firewall inside the MinimServer container to block access to the web interface's port from eth1
• Your proposal, separating ports for the web interface and content serving, while still using a firewall inside the MinimServer container to block access to the web interface's port from eth1
• Or maybe the most elegant solution: Separating the web interface and content-serving ports, while also allowing to specify the bind address for the web interface. Like this, no firewall is needed and the web interface could bind only to eth0
  

All solutions that require a firewall are a bit hacky because it requires me to build my own Docker image with iptables added, as well as the NET_ADMIN capability for the container. So if at all possible, I'd like to avoid that.

Frankly, I like the last option the most.
Since the web interface and content seems to be served by the same webserver, I did not dare proposing a solution requiring to split these up, as I deemed that more complicated than overriding the presentation URL. But I'll let you be the judge of that

So to answer your question: Your proposal to allow specifying two ports for web interface and content serving would satisfy my requirement, if adding a property allowing to specify which address the web interface will bind is also possible, that would be ideal.

Kind Regards,
blindfish

[simoncn]

I don't understand why in any of these scenarios you think it is important to override the presentationURL value in the device XML. This URL can easily be bypassed by a user if it is possible to access the MinimServer web UI with a different URL.

[blindfish]

At the moment I'm blocking access to port 9790 on eth1 of the MinimServer container, to prevent access to the web UI without going through the reverse proxy.
But the presentationURL points exactly to the IP address (and port 9790) of eth1, so all requests for actually serving content are blocked as well. That's my current problem.

By letting presentationURL pointing to the domain name, content is served through the reverse proxy, allowing access control to the web UI or unauthenticated access for serving content, depending on the requested URL.

Edit: Unless I misunderstand what the presentationURL actually does...

[simoncn]

I think you have misunderstood what presentationURL does. It does nothing except appear in the device.xml document. It doesn't make any difference to how files are served.

Also, there are many ways to change MinimServer properties in addition to using the web UI. They can be changed from MinimWatch, by using the web API (see this section) or by using the mscript command (see this section). My suggestion of having separate ports for serving resources and the web API will not prevent properties from being changed in these ways.

What is your deployment scenario for MinimServer? Is it on a network that untrusted users can access? Do you want these untrusted users to be able to access MinimServer for streaming music but not able to change configuration properties? Or are these untrusted users doing other things on the network that don't involve MinimServer?

UPnP is by its nature an insecure protocol. When I have been asked about this previously, I have suggested using a separate VLAN or subnet for MinimServer. I think this is the only way to make MinimServer secure from untrusted users on the network. Would this be a possible solution in your situation?

[blindfish]

Thanks for clearing up my misconception about the presentationURL and pointing out the other possibilities to change MinimServer's configuration.

(18-07-2023 09:56)simoncn Wrote:  Is it on a network that untrusted users can access? Do you want these untrusted users to be able to access MinimServer for streaming music but not able to change configuration properties?

Exactly that is my scenario, which is why putting MinimServer in a separate subnet or VLAN won't work.
If there was a way to make all configuration options only accessible from a different subnet or VLAN, then I'd be a happy camper

[simoncn]

I don't have a solution for this at the moment. There are a number of moving parts interacting with each other in various ways, none of which were designed with secure access in mind. If I have any more thoughts, I will post back here.