Ideas to secure network from network music player
-
Hi forum
I just bought a network music player (WiiM Mini, if that is of interest) and I am wondering if there are any measures I could take to reduce the risk that this device performs any unwanted actions in my network.
I need to access the player through mobile phones and my DLNA server.I guess there is not a lot or anything that can be done but I thought I give it a shot here and ask the community.
Marci
-
@Marci said in Ideas to secure network from network music player:
Hi forum
I just bought a network music player (WiiM Mini, if that is of interest) and I am wondering if there are any measures I could take to reduce the risk that this device performs any unwanted actions in my network.
I need to access the player through mobile phones and my DLNA server.I guess there is not a lot or anything that can be done but I thought I give it a shot here and ask the community.
Marci
Put it on a separate VLAN/subnet and block access to UDP ports 80, 443, 853, 5353. If you want to go even more hard core, install ntopng and perform some network spying on the device. See where it connects aside from known networks and block everything with pfblocker.
-
@nimrod Thank you very much for the feedback!
I have two quick questions, could you elaborate why these specific ports? And will I still be able to access the player from my LAN network if it is in a separate VLAN? -
One problem you will have when putting the device on its own separate VLAN or subnet is that devices on your regular LAN will most likely be unable to see the music player or connect with it.
DNLA and other similar multicast protocols generally do NOT cross subnets. That means unless the music server (source of the music files) and the music player (the consumer of the music files) are on the same subnet, they can't find each other. Ditto for trying to "cast" the music to a second device. Won't work across subnets generally.
So if this music player simply connects to a web-based or cloud service to pull content and is solely a player, then it will work fine. But if this is a server that provides music via streaming to other devices (such as Smartphones, Smart TVs, etc.) it will probably not work well unless placed on the same subnet as the devices that might need to communicate with it.
These types of devices often use a flavor of multicast DNS (mDNS) to "find" other devices on a network to share their streaming data. mDNS and similar multicast protocols do NOT work across different IP subnets without some type of proxy to rebroadcast the multicast traffic from one subnet to another.
-
@bmeeks Thanks for your comments.
Since I need to control the player with my or my wife's smartphone and it also needs to access my local DLNA server I probably cannot put it in a separate VLAN.
For other measures I guess I could check the DNS requests and block some if I feel they do not make sense. -
@bmeeks said in Ideas to secure network from network music player:
One problem you will have when putting the device on its own separate VLAN or subnet is that devices on your regular LAN will most likely be unable to see the music player or connect with it.
He could block the player's IP from accessing the Internet. Static map the IP, so it won't change.
-
@JKnott said in Ideas to secure network from network music player:
He could block the player's IP from accessing the Internet.
Yes, but my gut feeling is that the device is going to need to phone home in some manner or otherwise get to the web for its basic funcionality to work. If nothing else, maybe for firmware updates or some authentication mechanism.
It seems just about everything these days just automatically assumes it can see and communicate with the web at will. Heck, even pfSense itself can't operate smoothly without a ready Internet connection. Try running it in an air-gapped situation and you will immediately see how unpleasant that can be
. I would not be surprised for the OP's music device to be similarly inclined.I managed both air-gapped and data diode protected digital assets in nuclear power plants for a few years. It provides great cyber security, but man oh man is it a royal pain to do software updates, activate software licenses, and perform similar tasks. And more and more vendors these days just assume the Internet is there and a connection available, and they make their software dependent on that always-on connection. They look at you like you've lost your mind when you ask them how to do tasks with no Internet connection present.
-
@bmeeks said in Ideas to secure network from network music player:
@JKnott said in Ideas to secure network from network music player:
He could block the player's IP from accessing the Internet.
Yes, but my gut feeling is that the device is going to need to phone home in some manner or otherwise get to the web for its basic functionality to work.
I definitively need internet access on the device, besides general functionality I am listening to internet radio on it.
I will monitor DNS requests with Pi-hole, there is at least a chance to pick something up which might be not right.
-
You might be able to make it work across subnets using pimd but it can be very variable between devices, protocols etc.
-
If you would like to experiment with data diodes i created a beginners workshop.
There is a simple example streaming audio/video via rstp using vlc. From you you could create your own more advanced setup.
https://github.com/vrolijk/osdd -
@Rene-0 Thanks for the idea. I will take a look into that topic.
-
@stephenw10
I'm curious why the recommendation for pimd and not also avahi? -
Avahi does nothing for DLNA as far as I know. That's what most of these services are trying to use.
-
@stephenw10 yeah avahi per their own website
"Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite"
I wouldn't have any use for DLNA discovery.. Which would be SSDP on port 1900 pretty sure..
