Changing the port is just adding security through obscurity.
On most linux system you can see usual port address space allocations:
tcpmux 1/tcp # TCP port service multiplexer
discard 9/tcp sink null
discard 9/udp sink null
systat 11/tcp users
qotd 17/tcp quote
. . .
Port 55000 currently has no RFC associated with it
One could conceivably put in a Content Based Access Control based on what traffic is flowing through it. That would require users to understand what I just said, which isn’t likely and Roon telling us what the packet looks like for inspection.
Again I put that in the not likely category.
There have been so many security flaws in the exact types of systems you’re opening ports for (ie. NAS, IP camera’s, …). I would seriously advise you to see if you can come up with another approach, such as connecting to your home network via VPN and consulting the services from there.
Roon authenticates your user credentials and uses an encrypted transport. No unintended users can access your Roon.
If Roon is not running, then no one listens on the port that is forwarded, so nothing external can access anything inside your network. It’s like a phone number that never answers.
If somehow you already had rogue/malicious software on your network, it could access your network freely and it doesn’t need to open ports at all. It can tunnel traffic from the outside to the inside freely. UPnP or not, it’s game over if you have malicious software inside the network.
Those claiming that the UPnP setting make your network insecure are clearly not familiar with how malicious software works. If some rogue software could configure your router to open ports, it can also do that by opening an outbound tunnel. In fact, it’s probably more reliable to open the tunnel than it is to mess around with the router variations and UPnP/NATPMP/PCP support. But forget about tunnels or ports, it can just do the nefarious actions itself. At that point, its all up to local OS security.
Danny good to know that you have it tied up and that was expected.
Many poor implications of UPNP have been the cause of attacks since it was introduced… Even recently some router manufacturers have left UPNP open on the WAN port, it was never meant to be available on the WAN.
There is also the sample code that Intel put out to the world that was never be used. That was copied and pasted as if it were a reference implementation including the lack of any checking that Intel pointed out in the documents.
UPNP is in theory great for non technical users, but I imagine most technical people will disable it and enable the port forwarding themselves.
My NAS reports that the only connection attempts have been from my user ID, it has never blocked any access attempts, which is is set to do as well as performing regular security checks for logon attempts , malware etc, all of the installed applications and the NAS have 2FA and I’ve never seen any logon requests other than mine.
Danny has confirmed the ARC security so at this point I don’t have any concerns.
Routers with bad/buggy/unfinished UPnP implementations are not really the same thing as UPnP port forwarding being insecure. If you run into that situation, I’d worry about what else that router is doing badly.
If you want to disable it and manually forward the ports, that’s fine too.
@danny thanks Danny. So UpNp can be turned off and as long as port forwarding is set up, ARC works. I just confirmed it.
So unless Roon gets hacked and all user information is compromised, the encrypted connection and authentication Roon uses to connect and authenticate to client Roon core make this a pretty safe configuration, open port or not…my understanding is correct.
Your password is more likely to attacked/guessed/compromised than our user information being compromised. Not that it’s impossible, but we’ve not been compromised in 7 years, but user passwords are compromised daily. Try to use a good password and never use the same password in two places. Most attacks happen because someone was comprised. We don’t store your password (we hold bcrypt hashes), but many other services do.
Even if a rogue outsider had broken through our authentication and encrypted connection, they would be limited to using your Roon.
Danny it was not a criticism of Roon’s implementation at all. I think that it’s great to try and make it easier for less technical users. It’s the only way something like this is likely to work across the expanded user base.
I also think that this early beta will be good to help debug the issues before a wider roll out and that is likely to be an important step to a smooth rollout.
In pretty much all scenarios the malicious software is already in the local network (most likely due to a user error). Then the damage is done already.
By disabling uPnP you just give the malicious software fewer escape routes and make the attack service a bit smaller.
Note that most professional network manufacturers do in fact recommend disabling uPnP, in part for the reason mentioned above. Pretty sure they are familiar with how malicious software behaves in networks
Gentleman, most of this thread’s technical details are bit hard to effectively utilize for this not-technically-inclined-Roon ARC-end user.
I’d never even considered any home network security risks after setting up my network to accommodate Roon ARC (glad I’m not using UPnP - if I’m following this).
Would it be prudent for Roon Labs to create a home-networking security configuration Pro/Con document summarizing main security items to consider, prior to opening ports, for laypeople-end users like myself? @connor@mike@jamie
I think it a good idea to read up on securing a home network with or without roon. Home Network Security | CISA
this is just a starting page. They have plenty of advice and you can even sign up to get 0-day exploit notifications via email when found. Super handy when you have thousands of instances needing updating.
This is exactly what I’m refuting. It is my opinion that disabling UPnP does not actually prevent any “escape” routes. It’s purely theatre and actually impacts no nefarious software in any meaningful manner.
You mean the same providers that introduced the buggy/exploitable code in the first place, or are there others with reasonable implementations that also recommend this? And if so, who and what is their reason for such a recommendation?
While I’m a fan for knowing more about how things work, it is completely unnecessary in this situation to achieve safe success. You’d have to work hard to create a security issue here. It’s not going to happen by accident. If someone believes otherwise, I’d like to hear in explicit exploitable detail how that might occur. I’m genuinely curious so we can update the docs and help-guides to help future users avoid such actions.
I agree with almost everything at a high level (I disagree about antivirus) in this guide. It’s a realistic guide to what you can do to reduce threats.