Gents, I only get the below “Security Threats” (blocked by the Security suite I have installed on my network) in my Router UI, when I have the port-forwarding turned on in my Router for Roon ARC. Need I be concerned about the below? I’ve never had a security threat on my Network before turning on ARC’s port forwarding.
Port-forwarding details:
Router: Askey SAX1V1K (Spectrum Internet Wifi 6 Router; also referred to as Sagecom at times)
Let me know if further data points/config. info is necessary for an opinion. Thanks! @Rugby@ged_hickman1
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
174
All that means is that it’s not in the table of standard port to protocol mappings, I think. No surprise, not ominous.
2 Likes
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
175
Open ports will be probed, of course. But these connections may in fact have been from the ARC client itself. Your security scanner doesn’t know that, so it advises you on the “better safe than sorry” principle. I wouldn’t worry too much about it.
But this list goes back to Sept 17, before Roon 2.0 was released. So what was going on then?
There are other services on my network that forward ports for outside devices to connect to. Xbox for example has several ports forwarded to handle incoming requests to support various services. Somehow those ports do not respond and appear open to a random passerby probing my network, and yet can still be connected by Microsoft services pushing an install or other players trying to connect to voice chat and multiplayer games.
Roon on the other hand makes it very easy for anyone from the outside to find out what port it is running on so they know there is an open port worth putting effort into targeting. If it weren’t for Roon my network would look like a device that is powered off or otherwise inaccessible when being probed, because nothing else will respond to random connection attempts.
If services on Xbox with forwarded ports can hide their presence to a random passerby looking for something to exploit then Roon could be designed to do the same. It seems like it would be much safer in a home environment if it did behave that way.
I didn’t mean to imply anything unexpected or sinister given we already determined that Roon doesn’t stealth the port to unexpected traffic. I was just trying to give accurate feedback by quoting exactly the GRC Shields Up report on its port probe.
If there’s a daemon listening on a port, then that port will be seen as “open”. If there’s no listener running, then there’s no functional difference whether that port is fowarded or not; packets sent to it will be silently dropped.
In that, at least, there’s no difference between Roon, XBox or anything else.
YMMV, but when I clicked on the ARC tab, I saw that it was configured for a random high-numbered port. Finding that port requires scanning the entire 1024–65535 port range (waiting for each request sent to time out). Not “hard”, but not worth the trouble.
I’ve been looking to see whether anyone has hit that port yet; while it’s only been a day, no one has.
Not exactly. Even when actively in use the Xbox does not respond to a random port scan on any of the forwarded ports. In that regard they do not behave the same.
My concern with the current implementation of Roon ARC is that when an exploit is found a bot can be used to scan the internet and find machines running Roon, and then quickly target the exploit. And let’s be honest, it isn’t a matter of if an exploit will be found, but when and how bad.
Roon ARC already knows what port to connect to. I don’t want it to be so easy for everyone else to find the port Roon is running on, or whether it is even running at all. Then a bot would not be able to find machines to try and exploit with just a port scan and would have to actively try to use the exploit on every port of every machine, which would take much longer.
Great findings. I am very curious about the actual implementation of the API.
I am genuinely surprised that somebody thought enabling UPnP and opening more ports for more services were a good idea. UPnP and port forwarding by themselves are fine since they were reviewed and tested millions of times. But all the services behind the ports can be very much flawed. They are NOT bulletproof.
I had never seen anyone in home lab community said UPnP was OK. Most people would recommend open as less port as possible. If you really need to access something inside your firewall, either open port for just VPN (personally would recommend wireguard) or setting up some proxies with Cloudflare. Reducing the attack vectors is very important.
Run your Roon Core on a separate machine, with its own music storage, no access privileges to any other machines on your LAN
Use explicit port forwarding for that machine only, no UPnP
Use a well-configured router/firewall with threat analysis
Beyond that, it’s tinfoil hat territory. If the Grand Poobah of Ruritania wants to hack you, they’ll spend a few doubloons on zero-days and all your bits are belong to them.
I found this is harder than said. I believe Roon Core relies on some cast to make itself discoverable for Room Remote, so we cannot just completely block the machine and need to configure it accordingly. It also need to access to all the audio devices. Also need to make sure AirPlay and Chromecast’s multicast/traffic configured properly if you use them.
I wrote “no access privileges,” not “no access.” What I mean is that you don’t want to have the Roon Core machine have credentials for logging onto other LAN devices, especially for logging in to admin/root accounts. My Roon Core sits there, with a copy of my local music library, but no of access credentials for the other machines on the LAN. Fixed IP so that it’s the only port forwarding target.
Good thoughts BUT, you must segment your home network anyway, do not think for a moment that ■■■■ that should stay outside is held there with a firewall. Every device moving between different public networks and then connecting to the inside of your home network is the real pain point. Anyway, is the ROON traffic that important it need to be encrypted? Any hacker will anyway port scan and attack the open TCP port without the traffic info. Sure, they can find interest in the traffic behaviour of roon and use that hmmm. Anyway - you should always use a VPN connecting to your home network from outside - this goes with Roon too to be more secure.
Segment and monitor internal network, and if there is a breach, it will stay on that computer. This is anyway necessary in all internal networks as you always have external devices connecting to the inside all day long spreading ■■■■ without any firewalling if not segmented properly. I will not use a VPN at this time, but will monitor the segmented ROON core very closely, logs and notices if the ROON port is used when I am not using it etc. The ROON core should only answer external IP addresses in your known range (my 4G operator).
Great initiative for sure, but until you resolve the serious security issues with UPNP or port forwarding its a no go for people concerned about security. You should advise people so they can decide their own risk/return benefit.
Sadly that is not how things get compromised most of the time. A more likely scenario is that Roon despite good intentions fall vicim to a supply chain flaw where they use some third party library as part of the service that runs on 55000. Whenever such exploits are found the bad guys scan the bulk of the internet using Shodan.io or similar service and then target all the vulnerable systems.
Sadly it is not about someone targeting you specifically. This is why it is critical to always make sure your internet connected devices are up to date with all available patches and that you understand exactly what is exposed to the internet.
While phishing is by far the most exploited attack vector, bad patch management and exploiting poorly patched and maintained systems is also high on the list.
The Grand Poobah of Ruritania, if they could afford it, could certainly buy an exploit from the likes of Zerodium but that is not a likely event for most of us to worry about.
If ARC can initiate requests to the core, regardless through what mechanism, attackers have a point of entry. There’s no way around it. So if you want remote access, you can only mitigate the risk, not remove it completely.
Yes, Thanks. That is why Roon Labs should advise people that there is a risk, so that those that have no understanding of computing can make an assessment of their personal risk tolerance.
Again, if it’s a supply-chain attack, then the malware-infected Roon Core could just as easily open an outbound connection to a C&C server. It would not matter a whit whether it allows inbound connections on Port 55000.
(And, for what it’s worth, the listening port doesn’t have to be 55000. That’s totally configurable. Mine came up as some other randomly-selected high-numbered port.)
