Security with Roon ARC / Roon 2.0

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.

I find that one of the things we who are experienced in these matters don’t realize is how hard it is for a layman to understand what they find via a Google search.

2 Likes

I use it with Wireguard on a 4G connection, on an iPhone, and it works fine. Arc correctly detects the connection type and scales to CD quality (what I have defined in the settings).
Not sure what the problem on you side could be.

Probably just my area then. I’ll see how it goes

Or it might be some iptables config, need to check. I was using udp_proxy_2020 from Aaron (search for another thread in this forum). I configured something in the network for that.
However, if it works with an external Wi-Fi network, I cannot imagine a reason in your network why it should not work on 4g…

The same kind of pattern of daily, every other day security events, with the same type of security alerts on the core machine and another machine on my network (Mac Mini that is running my head/remote; the alerts on the mini actually list a domain; the current case is some kind of ad URL from nbcnews.com; so I’m not concerned) @Bill_Janssen.

I’ve been getting these alerts for months during all builds of the ARC beta, when I turn off the port forwarding, which I’ve done twice for 7 days each time, they completely stop (of course I then cannot use ARC, lol) They drop off of the Router security report after 7 days, which is why you don’t see the full history. There have been, say 50+ of them at least.

Thanks for your time in response, Bill!

EDIT - One other thing, the two intial ones, actually required me to run a Scan with Windows Defender anti-virus and quarantine and delete the two items (they are the only two that have shown up on my Windows core machine; I’ve been running full scans periodically, just to make sure; no repeat offenders have progressed to the Windows core machine, since)

1 Like

Some say we never should have left the trees. I for one, say it was a mistake to leave the oceans.

4 Likes

What if, actually, we were never in either? :rofl:

4 posts were split to a new topic: Is there a way to get ARC working over VPN?

3 posts were merged into an existing topic: Is there a way to get ARC working over VPN?

You are still misunderstanding. My suggestion is to have Roon Core on a separate machine that does not have privileged access to anything else. I’ve seen plenty of situations where for “convenience” people set all of their local machines to be able to connect in with privileges to all the others. Very bad idea. Roon does not need anything more than read-only access to music files, local read-write access to its own library database and other working data (such as logs), and RAAT or ARC TCP/IP streams to other devices.

If you don’t mind, how does one know if their core machine has access privileges to other devices on the local network? My knowledge of these things is little to nil.

I have a Salkstream III (running Linux Arch) where Roon core (Roonserver?) and my music files reside. Roon remotes are iPad, iPhone, and desktop PC (Windows 10). I use the PC to rip CDs and transfer music files to the Salkstream. On the PC, I can see and access the music files on the Salkstream. Does this mean the Salkstream also has “privileges” to access my PC?

Any clarification you can provide for this novice is appreciated. :grinning:

It’s difficult to say without detailed knowledge of how everything is set up. However, what you describe seems benign: the PC can manipulate files on the Salkstream, presumably because you gave the PC access to SMB service running on the Salkstream, but that should not open the PC to the Salkstream.

1 Like

No, it is you misunderstanding me this time.

You should do that even without ARC.

You keep saying file access and separate machines and privileged access, but you never address the network issue.

Are you going to put Roon Core under the same VLAN with your Roon devices or Roon remote? Because it sounds you’re. If Roon Core get compromised through the public-facing port, the hackers can gain access to your network and talk to other devises in your network even without privileged access. Of course they cannot use the official way to log in, but there are a lot of internal-facing ports that aren’t that secure and can be easily exploited (i.e. your PC’s family sharing feature, or the streaming port of network player).

Thanks for the information. :+1:

Are you going to put Roon Core under the same VLAN with your Roon devices or Roon remote?
Of course, Roon won’t work otherwise.

Maybe on your network there are…

It’s unfortunate that Roon (not the only ones) need you to use UPnP or setup a DNAT for their service to work. Not what modern SaaS services should be doing. I was pretty shocked when I went to setup, it failed and I had to setup a DNAT (https://help.roonlabs.com/portal/en/kb/articles/arc-port-forwarding#Still_having_issues)

Roon please manage the connection, use a well known port - something like TCP 443 (SSL) outbound. Users turns on ARC from Roon core, connection to ARC service is setup outbound over SSL. Clients auth to the ARC SaaS service and then gets connected back over the active connection opened by the Roon Core ARC service. You can offload the connection so it’s not tunneling though your SaaS service.

No open ports/FW rules, UPnP to setup/manage. No concerns about port scanning, random port scans, etc.) even if they cannot auth/connect to your service.

yes, we have to trust that the Roon Service won’t be hacked (they should be managing this as part of the service - are you?), but right now you have to as well as having open ports back to your Roon Core.

By now this is becoming well traveled territory. UPnP is not necessary to enable the Roon ARC functionality. Manually creating a port forwarding rule is fairly trivial on most consumer grade routers. The open port doesn’t seem to respond to port scans in my brief testing, so that may not be a concern. To my understanding, connections to the Core are only allowed after authentication takes place. My Core has nothing on it but Roon Core and there are no unauthenticated network connections to any other device on my network. I’m not as terribly outraged by the perceived security concerns as some are. If you are uncomfortable with then don’t use it. For me having mobile access to my Roon playlists and library of music that IS NOT available on streaming services is just dandy. Kudos to the Roon staff for making this happen.

6 Likes