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.”
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.
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.
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.
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
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.
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
Yeah not using the default completely befuddles those port scanners
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. Maybe a google search.