DLNA should be clearer about exposing media publicly or alternatively not talk to clients classified as remote.

[hlinden]

I am currently in the process of evaluating how to lock down Jellyfin for use behind a public facing reverse proxy. That means, I have to see how I can prevent the unauthorized access using DLNA (that is desired behaviour locally, I know) from remote.

I have found, that the UUID in the description/control/etc endpoints from the SSDP broadcasts is ignored.

I had assumed the UUID in the endpoints announced via SSDP would be somewhat of a barrier against access from outside the local broadcast domain. However, something like...

curl 'http://192.168.100.2:8096/dlna/'$(uuidgen)'/contentdirectory/control' -X POST -H 'HOST: 192.168.100.2:8096' -H 'CONTENT-LENGTH: 440' -H 'Accept-Ranges: bytes' -H 'CONTENT-TYPE: text/xml; charset="utf-8"' -H 'SOAPACTION: "urn:schemas-upnp-org:service:ContentDirectory:1#Browse"' -H 'USER-AGENT: Linux/6.9.1-arch1-1, UPnP/1.0, Portable SDK for UPnP devices/17.1.10' --data-raw '<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:Browse xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1"><ObjectID>0</ObjectID><BrowseFlag>BrowseDirectChildren</BrowseFlag><Filter>*</Filter><StartingIndex>0</StartingIndex><RequestedCount>5000</RequestedCount><SortCriteria></SortCriteria></u:Browse></s:Body></s:Envelope>'

will return a valid answer any time.

A quick test against a bunch of random Jellyfin hosts exported from shodan shows that this is relevant in the field and exposes media publicly.

I see no downside in not answering DLNA requests from outside the local network by default. Therefore I suggest:

• not doing that. A good starting point to classify a client is probably IsInNetwork from https://api.jellyfin.org/#tag/System/operation/GetEndpointInfo.
• extending the reverse proxy cooking receipes at https://jellyfin.org/docs/general/networking/ so the resulting config will reject any attempt to access URLs below /dlna/ with a HTTP 403 Forbidden.

[crobibero]

The plugin is already supposed to only respond for LAN requests.

Are you using Jellyfin 10.9 and the plugin? Or 10.8?

[hlinden]

Are you using Jellyfin 10.9 and the plugin? Or 10.8?

You are right. After upgrading a few minutes ago due to two other reported bugs being fixed in 10.9.2, I am currently running 10.9.2 and DLNA plugin 1.0.0.0. The query mentioned above has stopped working from anywhere but the local prefixes, from anywhere else I now get < HTTP/1.1 401 Unauthorized.

To verify, I've quickly tested that again on some public instances and I've found versions between "10.7.5" and "10.8.0" responding successfully. So, I'd say this issue can be closed (although I still think, blocking /dlna/ in a public facing reverse proxy setup is a good idea and should maybe become part of the documentation).