Security with Roon ARC / Roon 2.0

I did the same thing – tested GRC with the specific port used by ARC – and got the following:

“Your system has achieved a perfect “TruStealth” rating. Not a single packet — solicited or otherwise — was received from your system as a result of our security probing tests. Your system ignored and refused to reply to repeated Pings (ICMP Echo Requests). From the standpoint of the passing probes of any hacker, this machine does not exist on the Internet. Some questionable personal security systems expose their users by attempting to “counter-probe the prober”, thus revealing themselves. But your system wisely remained silent in every way. Very nice.”

I’ve never set up Roon Core on a Mac, so I hesitate to give a set of instructions — involving lots of sudo commands — that I have not actually tested myself.

But the instructions that I gave above (for Linux) involved 3 steps

  1. Creating a new non-Admin user, “roon”.
  2. Making the Roon Core directories (/var/roon and /opt/RoonServer) owned by that new user, with appropriate permissions.
  3. Modifying the script that launches RoonServer to run it as the user roon, rather than as (the default) root.

Step (1) can be done either using the Users & Groups System PreferencePane, or at the commandline, using the dscl command (just Google creating a new user on a Mac).

Step (2) is essentially unchanged.

Step (3) involves editing a Launchd script in /Library/LaunchDaemons/ to add some lines that look like

    <key>UserName</key>
    <string>roon</string>
    <key>GroupName</key>
    <string>roon</string>

Again, I’m hesitant to publish detailed instructions that I haven’t actually tested myself. But that should be enough to get you going.

If you do get this running on a Mac, please publish a better set of instructions.

Thanks! I’ll tinker this weekend.

Are you certain you were accessing Shields Up from your actual IP and not through a relay of some kind? If I access the page through Safari with iCloud relay on then it shows up as stealth also because it is scanning the port on a different IP.

You also might need to check that you were checking the right port. Every install has a slightly different high level port that is assigned for Roon ARC. It also won’t show up if you don’t have UPnP enabled and have not manually forwarded the port (or forwarded to the wrong port).

If it is configured properly and you are scanning the right IP and port number, it should show up as an open port unless you have a firewall that is blocking the scan from Shields Up.

When there is a known exploit that can be targeted, yes, someone will go looking for them

post deleted by author. Sorry, I misread something in your post & so the comment I originally typed didn’t make sense.

A question about the open port for Roon ARC. Is Roon Core constantly listening on that port? If so, why not introduce a mechanism that will only open the listening port when there’s an actual incoming request from a Roon ARC client? Would this not reduce security risks significantly?
Another defence would be to offer some sort of identification of incoming requests from devices (a ‘white list’ of specific devices, which can be specified in the Roon Core web interface f.i.)… ?
Of course, I’m asking this with my limited knowledge about security / networking, so bare with me. :wink:

1 Like

How will this work if Roon isn’t already listening, because if it is not already listening then it can’t know without having Roon Core reaching out to Roon servers and constantly asking is anyone trying to play music. This would generate a lot of traffic.

Many of us had a lot of questions around the security of the solution and sensibility of using UPNP during the beta and there are a lot of replies from Danny, but I do not think they are open to non beta testers.

But given that we almost all set it up, the chosen solution over rode our need for a completely secure solution.

2 Likes

I believe Synology NAS has something like this in place (when accessing files from apps like DS File f.i, and with the use of QuickConnect as a ‘middle man’). But I’m not sure if something like that could work for Roon.

The easiest way to provide a little more security is probably a simple ‘manual’ switch to open or close that listening port, thus enabling / disabling Roon ARC clients from outside your home network.

The thing is… if you open an app like a Bittorrent client and you have a BT port forwarded, it will only listen on that port while the client is actually running. I’m only using Roon ARC from outside my home network occasionally.

You’re right by the way, it’s a trade-off between security and functionality. People will have to consider the up/downsides for themselves.

But as far as I am aware the actual vulnerability was a hardcoded password in the QNAP authentication stack… so the port made it accessible, but the attack was because of a fatally flawed system.

If one configures the device running the Roon Core software properly (i.e. disable built-in accounts and change all passwords to unique strings, configure a firewall) a single, dedicated port open for ARC should pose not great threat.

Chris that is a complete Cloud infrastructure (which is expensive) and uses the outbound connection to deliver inbound connections (which is definitely a different way to deliver services).

It would be almost certainly be way more e expensive for Roon to deliver this, and it is a question asked during the beta. Roon said they had no interest in delivering this solution. The current solution is more old school and relies on us providing the bandwidth not Roon.

I can see the option of a future Cloud Roon though where each person has their own cloud set-up and stream from that to the home. Though that seems like it would be a while off and will almost certainly split the user base down the middle in terms of screaming hissy fits in the forums :flushed:

1 Like

Can you point me to the instructions where it details how to do that for ROCK?

Since ROCK is closed you cant. But then that is a degree of security in and of itself.

I have the ARC port forwarded on my ROCK, no drama. Its behind a firewall and only the single port is forwarded, so any exploit would have to be specifically tailored for Roon. Im not going to lose sleep about that, life is too short. The only data there are my FLAC files which I have securely backed up in multiple places and air gapped.

EDIT: I am also not using the default ARC port. A minor point but a worthwhile change IMO.

2 Likes

What??? rock is closed so you have no way of knowing what is going on in the OS. Given roon’s strange design choices in the past (opengl, mDNS, no dns caching etc) I dread to think what is going on in there.

I can’t be arsed arguing security on this place anymore :man_running: :man_running: :man_running: :man_running: :man_running: :man_running:

Yeah not using the default completely befuddles those port scanners :rofl:

Dont use ROCK then, entirely your choice. But if you use a NAS be careful because those things are leaky as a sieve and well known to be by the bad actors!

Thats a relief, too many experts here as it is :laughing:

So they scan it, so what? They scan everything all the time.

Haha you are Michael Gove and I claim my £5 :roll_eyes:

Yeah that was sarcasm, but you missed it… to explain it for you; I was implying these experts are all just ‘self-proclaimed’ and not actually experts at all.

Some of the tosh spouted on this thread (and others) amounts to FUD for the average user, which helps no one and causes unnecessary anxiety.

1 Like

Oh, great. Now I have to not only become a network guru, I have to play competent sysop as well. I retired to get away from all that!

What can I say, this is price we pay for the latest toys man :man_shrugging:

Enabled firewall, unique password strings are (or should be) standard security practice on any platform, regardless of Roon Core running on that platform or not. Disabling built-in accounts just might be a bit more of a problem for some, but it usually doesn’t require a competent sysop. :wink: Maybe a google search.