Roon remote security

Hi,

I don’t find anything about the permissions of a remote to connect to my Room server… EVERYONE who has a Roon Remote app in its mobile inside my network could connect to it?

I have to work with the firewall rules?

1 Like

That is correct, at present there is no security on Roon Remote connections.

A firewall could be used to only allow authorised devices to connect.

Use a guest network to isolate those that might disturb your roon setups

This is a bad thing:

  1. for the security of the computer itself (I imagine that port is open in INCOMING)

  2. because not everybody has a guest network enabled router

  3. because, I don’t say an authority feature but at least a common login method should be enabled in Roon

Hope you will do in the next future :slight_smile:

I find this pretty convenient, actually. Assuming you have an internal network at home of course.

I don’t let people I don’t trust to my home network anyway, so the ones I let in might as well be able to play music at my house. If people that I don’t trust access my home network, I have way worse problems than them playing music with Roon.

5 Likes

Even trivial freeware software of streaming has password protection for remote access. I can say vlc, foobar, kodi and many if not all the others.

I think it’s illogical that an important player like Roon is totally “open”’ to the network, even if it’s a home network.

Hope this will change.

The Roon app (running on a tablet is all I’ve tried) can walk through every directory and see every file’s name under directories, that the connected Roon server can see. That ability to see includes both local drives and network shares; this is true for Roon server under Windows and, for network shares, Roon server under ROCK (I haven’t tried to see what Roon server under ROCK might reveal of local drives, because ROCK probably limits the local directory structure). The ability is the result of the app being able to tell Roon server to monitor directories. Further, the Roon app can create new directories of any name under monitored directories. Do I have to spell out the implications of being able to create a new directories of any name?

Second, thinking control over admission to the local network as any sort of protection is naïve. Think about people with children: Can they say, Sorry, kid, you cannot use the local network because you might be running bad software? Think about people who have child-sitters, housesitters: Sorry, you cannot use the local network. Think about people who have devices that, for full function, need local network access. Sleep Number, for example, has a product called SleepIQ, which monitors a person’s sleep on an enabled mattress (the pump of which has a MAC address!), analyzes the data and reports summary information. A person can elect not to use SleepIQ, but how many people would recognize an exposure in a mattress app? In short, we are long past the time when control over local network access is a practical protection.

I suggest that Roon server 1) ensure authentication by a Roon app and 2) employ encrypted communication. (Please don’t think that the details of RAAT will be forever out of reach. It’s just a matter of time and effort, and the ability to read directory structure is an incentive to use Roon in a suite of hacking tools.)

So you’re comparing Roon to a desktops app running on your desktop computer. I assume that might be your use case, but it is not mine. I would compare it to streaming systems like Sonos, Bluesound, Linn, Naim, etc. but hey, that’s just me.

Again, I’m not against inconvenient “security” features as long as they are not mandatory and don’t get in the way of the normal operation.

It’s way to late for me to start addressing the “threats” James_Antognini mentioned, but maybe on a later date. I would however like to hear the implications of “being able to create new directories of any name under my music library” spelled out for me. I would also be interested in hearing how employing encryption to RAAT would benefit anyone. I can see the downsides, but what would be the benefits?

A simply thing to begin it’s only to add an “optional” password for the remote apps for connecting to the server.

Or if you prefer a way to authenticate the remotes, each time someone could allow or deny the list of remotes that connect to the server.

One of these two basic secure method will be welcome.

About creating directory names: Let’s suppose Roon has an active network share to a HDD or SSD on your laptop. Roon, via its monitoring capability, can be made to create a new directory under that mapped drive, with pretty much any name for the new directory. Let’s suppose further the name is chosen to be offensive or suggestive of illegality, deviance (however defined) or what you will. That is not what I’d like to have anyone discover on my laptop (or desktop or other network-mapped device).

Truthfully I don’t even know how to create directories in my network shares with the Roon remote. Nor do I care. I general I believe security is about your infrastructure, not having passwords in every software you use. But that’s just me.

If I was worried about someone using Roon to create directories under deviant names in my music library and scared that someone might find these empty directories while accessing my machine and going through my music library and not thinking I’m normal, then life might be kinda hard. I might try to solve it by making my library read only, but that’s just me.

I do however disagree strongly that control over admission to the local network as a form of protection would be in any way naive. I find the truth to be quite the opposite actually.

Yes some people have kids that they do not seem to trust. But your kids running bad software in your local network has nothing to do with passwords and encryption requirements in Roon.

As far as child-sitters and house sitters are concerned I would emphasize infrastructure. I mean if you don’t trust them, then let them access only a visitor network. This is a common feature in many routers and is easy to implement even if you have a crappy router with DMZ.

But can kinda relate with people, who can trust a sitter to take care of their house and their children with a full access to the local network, but are not quite ready to let them see their music collection or, god forbid, play some music while doing the sitting. I mean, gotta protect the things that are important.

And yes, many of the IoT devices and such also require internet access. Some of them might even need to be in the local network instead of the visitor network. For some reason I doubt that they would be used in an attack against Roon to plant empty directories with deviant names in my music library. But of course you never know.

So the deviant directory names and the fact that everyone should be allowed in your home network was the reason we should make it harder to start using Roon remote, but what was the reason we should encrypt RAAT?

And while I think that, without WAN access, Roon remote does not need any additional “security” features, I do have security concerns about Roon. Not with the remote though.

I find it worrying that Roon core is run as root by default under Linux. And that possibly packaged version of Roon core would continue to do so as well. That is bad practice.

I have solved this in my environment by setting up a dedicated user to run Roon, with some limited access to tools Roon needs, but it required some tweaking not everyone is ready for.

I suppose some sort of a container (docker maybe?) to run Roon in would also be kind of a solution, but that does not mean the default should be kinda questionable.

Personally I dont care about the raat encryption but about a password protected server Just think if live with other collegues in the same home and just you dont want someone else just installing a remote in its mobile and see and control your Roon server. When I tried Roon for the first time I cought myself immediately searching for the security options I also was sure that I needed to authorize the clients remote… I was a little surpriced that options were missing and still I am reading stuff like “your network must be secure anyway or beware your router settings…” and remain surpriced even more.

Password protected server for Room is mandatory to add to a software of this kind (and price).

Authorize the remotes is not so essential but it will be a good thing too.

About “inconvenient” security features: In the case of having to supply a password in the Roon app, that would have to be an option, since slamming the requirement in place would disrupt all kinds of things.

About a guest network: A device connected as a guest and running the Roon app has just as much power as a device connected to the “main” network. I just tried it.

Obviously, a guest network is easy to disable, but whilst the guest network is up, the Roon app is just as powerful.

But maybe there’s a way to restrict a guest in some guest networks. I just don’t know about that.

I mentioned RAAT encryption because that would lessen the chance of any rogue software listening or interfering. We have to expect that, more and more, a WAN will have devices/apps that are a potential risk. (And even if a risk is detected by a particular manufacturer – my SleepIQ mattress, for example – how would an update be pushed out?) Put differently, access to the WAN is in no way a security barrier in any way, shape or form. Those days are long past.

It’s not just “bad” directory names. Roon can be used to see the name of every directory and file in the Roon server machine (Windows at least) and in any established network share.

Why should the Roon app be able to see so much, without being verified (eg, password)?

I see in the raat encryption a good thing to enable for the future (as the portrait mode view for my ios ipad pro 10) but I think th guys here should start to enable a password for the remotes as first step to achieve in order of importance.

Guest network is a separate network with access only to the internet and not the local network. A device connected to the guest network would not see Roon server running in the local network. It would not see the local network. That is kind of the point of the guest network.

Because I like a neat filesystem, all my audio files are in dedicated directories and I don’t necessarily care if someone want’s to see how my library is laid out on the disc. I would be a different thing if I was to scan the root directory, but that would be just insane. Anyways that is the same layout the guy that goes browsing your library to see the deviant directory names would see.

But obviously we need to encrypt everything, because we have to let every random person sniffing in our home network. I mean what is the point of password protection if it’s not enforced. We need to encrypt the music that moves from the core to the bridge, because we don’t want anyone seeing the audio bytes that move between the core and the bridge. They may hear them from the speakers, but they can’t be allowed to seen the music move in the network. Oh no, in the name of security RAAT need to be encrypted. I mean why wouldn’t we add more hardware requirements to playing music. In addition to transcoding and DSP we want the core to encrypt. And so that we could make the bridge do unnecessary processing and not just try to play the music the best it can, it should totally do decryption. Because why not.

I mean if controlling the Roon is at any point possible from the WAN, I’m all for encryption and authentication, but even then only between the control point and core. This is of course unless the music stream can also be directed to the WAN and for some reason would contain some confidential information. At least now I can’t imagine why it would.

I wasn’t aware that one might use a guest network that had no WAN (local) access. But looking at NetGear Genie on my network, the option to allow/disallow WAN access is greyed out. I am reasonably sure I could figure out how to make that option available, but the point we should be taking is that securely administering a local network takes expertise. Why should Roon be set up to make that expertise needed? I mean, (almost) everybody gets the point of requiring passwords/authentication between an app and a server. Requiring network administration expertise is not a good idea.