Security with Roon ARC / Roon 2.0

[danny (Danny Dulai)]

@ipeverywhere

These are Google Cloud IPs. I don’t believe the way Roon is built inside Google Cloud they “own” any of their public IPs so expect these to change. However, they would change within Google Cloud public IP ranges within the region(s) Roon is deployed. This would need comment from Roon Labs if you wanted to narrow to this range.

You are 100% correct. The range can not be narrowed.

[contium]

Guess I won’t be using ARC. I have no port forwarding or upnp enabled. However, I can remotely access tons of devices at home. Thermostat, vacuum, security cameras, lights, garage door opener, vnc, etc. How do all these things get thru without open ports but Roon cannot?

[Georgethesixth]

Because your IoT device opens a connection to a server outside your local network and your client connects to the same server outside your local network.
Can you imagine the number of servers and the amount of bandwidth Roon would have to provision to tunnel all music through their infrastructure. Prices would have to go through the roof.

[Coltrane]

@contium

vacuum

Sorry but that is bizarre to me. I still have to put hands on my vacuum and get on my knees.

[Marian (I stand with Ukraine)]

I guess it’s a robotic vac.

[CrystalGipsy (Resisting the flow!)]

It works on the local network even over subnets so I imagine it will work via a vpn to.

[anonymouse]

@CrystalGipsy

It works on the local network even over subnets so I imagine it will work via a vpn to.

Others have confirmed ARC works over a VPN. But the way VPNs are usually configured on an iPhone, won’t that result in ALL streaming traffic going via your home network ie Tidal → home router → VPN tunnel → phone ? Not particularly efficient.

[Patrick_Conroy (Pat)]

I’m using ARC thorough tailscale, no need to open ports.

[Christophe_Hinard]

a DNS entry must be used
roon must be able to communicate it to us
I just want to limit incoming connections to the roon server and not to everyone

[anonymouse]

@danny and other security experts, thanks for your input to this thread ,

Before I open a port on the firewall, are there some other things I could do to harden security internally?

I’m running Roon core on a separate Linux box (ROCK). I’m thinking of the risk of a bug in Roon core (eg improperly handled buffer overflow etc) on the public port allowing an intruder to get control of the Linux box. Should I set up some other filters on my network, eg only allow that box to access the rest of the network through a specified list of protocols/ports, or only allow that box to access my audio and control equipmen/

I have not been previously been successful in running Roon in its own VLAN but could have another go. (I’m running a UniFi network.)

PS Also: I do think that Roon should have a red team and a bug bounty programme for security on the customer-side software, as others have suggested above.

[Sevenfeet (Rick Ewing)]

While I appreciate @danny 's remarks on this subject, I tend to be very risk averse these days, having worked in enterprise IT for three decades. Complicating my situation is that I’m running my Roon Core on a QNAP NAS and most of us are familiar with the fact that QNAP still hasn’t shaken their security issues with all the ransomware attacks in the last two years (and even the last few weeks!). I haven’t opened my routers to UPnP in over a decade and never will. Right now it’s a big no-no if you have a QNAP NAS. And I’m not that comfortable doing a tunnel through the router (Unifi UDM-SE) to service Roon ARC either.

Right now, the only thing that I’m going to continue doing is using a VPN to the Unifi and then run Roon ARC after that. This seems to work well (double encryption!) and if only I could configure an iOS VPN to connect automatically for a specific app, then that would be the best situation. But right now, I’m ok with doing a two step process to listen to Roon ARC on the go.

And while we’re all talking about this…everyone, back up your data! You can’t plug every hole but you can prepare yourself if the worst ever happens.

[nobbe1kenobi]

fwiw I’m unclear if suspicious activity would get logged to this open port, but it would help set my mind at ease. I feel like UPNP is a security risk I’ve disabled on my network, and a persistent port open would be something I’d want to monitor. Who knows what exploit could occur in the future that might enable remote code execution. Being paranoid, I think I’ll personally defer to VPN’ing vs. port forwarding. Alternatively, isolating a segment of my network might be a great compromise.

Is there any logging of suspicious activity that would close the port on the Core (let’s say after multiple failed login attempts) or generate some type of alert?

[TonyV]

If you are worried about UPNP then just do a manual port forward rule on your router. Worked for me just fine and no UPNP enabled. Works great and if you read the network implementation for ARC it’s reasonably secure.

[John_Kaster]

I’m skipping to the last entry here because I started as a Beta tester and would like you all to know I’ve experienced no security problems from opening a port for Roon ARC. Many early adopters with more experience with internet security than I wrote in and felt there is minimal downside and a great deal to be gained. Hope you enjoy ARC.

[phunge]

@danny

If Roon had access to a good cross-platform QUIC implementation, we’d skip the port forwarding completely. It’ll happen someday, and when that happens, we’ll be able to get through routers without any configuration, UPnP/NATPMP/PCP, or manual port forwarding. One less thing to configure or worry about, and an overall better experience.

Hi @danny,

First, thanks for releasing this functionality, despite the support burden this port forwarding requirement will no doubt create for you and your team. MUCH RESPECT !!! – I for one will enjoy our shiny new toy!

Regarding cross platform Quic, you’ve likely seen this already but there is: GitHub - microsoft/msquic: Cross-platform, C implementation of the IETF QUIC protocol
and the .net wrapper: GitHub - runtime/src/libraries/System.Net.Quic

Available on Windows & Linux, but not on MacOS yet…

.NET 6 does not include support for HTTP/3 on macOS, primarily because of a lack of a QUIC compatible TLS API. .NET uses SecureTransport on macOS for its TLS implementation, which does not yet include TLS APIs to support QUIC handshake. While we could use OpenSSL, we felt it better to not introduce an additional dependency which is not integrated with the cert management of the OS.

source: HTTP/3 support in .NET 6 - .NET Blog

hopefully apple will add the needed support in an upcoming release.

[Adam_Herbert]

Hey, how did you validate that your security position was unchanged with the installation of the ARC system?

[brian (Brian Luczkiewicz)]

@phunge

source: HTTP/3 support in .NET 6 - .NET Blog

hopefully apple will add the needed support in an upcoming release.

In addition to that, we need to see this resolved, or another mature QUIC solution to pop up there as the ARC app is built using dart/flutter.

It’ll get there, we have no doubt, but we weren’t willing to make all of our users wait for it to get this done. The great majority will be able to use port forwarding or VPN solutions with this, and delivering that sooner was the greater good.

[Adam_Herbert]

Home assistant - Nabu Casa - that is what I would do. Private certs, private creds, no ports or uPnP, open source, all connections initiated via known good domain, etc…

[Adam_Herbert]

Just a bit or unsolicited “advice”. If you are not a network/secops expert I would suggest, at a bare minimum, running this test from you local network before installing ARC to generate a baseline and fix any problems and then again after installing ARC to validate you haven’t broken anything:
https://www.grc.com - Select services and then Shields Up! and follow the instructions to do a scan of your firewall.