I don’t remember being canvassed about this, would you care to refresh my memory?
If you have bad actors in your local LAN, then you have bigger problems than you ROCK shares IMO.
2 Likes
Try not to insult other Roon customers and your posts might not get flagged.
Is there actually an issue here and, if so, can someone summarize it concisely? I’ve read and re-read this thread and I can’t figure out if there’s actually something of concern being raised.
My local library sits on a Synology NAS on which the minimum SMB protocol is set to SMB2. I have a user account created for the ROCK. That account has read-only access to the Music share.
That works fine. Am I missing something about how ROCK behaves as an SMB client? It doesn’t require SMB1 and the strategy that I use seems straightforward.
There may be interesting security conversations to have about Roon but I’m struggling to see how this is one of them.
Roon doesn’t like us calling each other anything actually. Just talk about the Roon issues, not each other. It’s difficult sometimes.
1 Like
In some Windows clients, you need to specifically allow “Insecure Guest Authentication”, i.e., the Windows client must not be forbidden to connect to SMB shares that don’t require a password. Some Windows Pro versions now seem to not have this enabled by default, which makes sense in corporate networks.
Obviously, the SMB server might nevertheless require a password. This is just whether the Windows client is allowed to connect to such a share.
I.e., a non-issue in home networks, or as Microsoft says:
Insecure guest logons are used by file servers to allow unauthenticated access to shared folders. While uncommon in an enterprise environment, insecure guest logons are frequently used by consumer Network Attached Storage (NAS) appliances acting as file servers. Windows file servers require authentication and do not use insecure guest logons by default.
This is true, also Microsoft:
Important
Since insecure guest logons are unauthenticated, important security features such as SMB Signing and SMB Encryption are disabled. As a result, clients that allow insecure guest logons are vulnerable to a variety of man-in-the-middle attacks that can result in data loss, data corruption, and exposure to malware. Additionally, any data written to a file server using an insecure guest logon is potentially accessible to anyone on the network. Microsoft recommends disabling insecure guest logons and configuring file servers to require authenticated access.
If this is an issue in a home network, you have bigger problems.
And regarding the need to specifically allow this with a Registry Key on some Windows Pro versions, well they are Pro versions
2 Likes
I’d be happy with username:roon / password:rock. Even that would be a step up on “guest”.
2 Likes
At least you have to access to ROCK codec folder once for FLAC file playback ability even your library on NAS.
I’m a moderator on here, and I need to make it clear that your posts were not flagged, removed or moderated due to your views on Roon security, they were remove due to the tone you took replying to another member of the community.
I have reviewed the posts and I do not see this … it was pointed out your comment on SMB1 was incorrect … you interpreted the reply as an insult, got the hump and standards slipped.
Again I will reiterate, it was the attack on other members that was flagged and why posts were removed. In your later post, the on topic discussion was left intact only the snide comment against a user was removed.
Not at all, all your comments on this topic are still here.
This is very good advice; we have zero tolerance towards toxic behaviour on this site, and I invite you to read the forum guidelines.
https://community.roonlabs.com/faq
CC @Modfathers
4 Likes
Thanks, @Suedkiez. It’s a gift to have you in this forum - your always extremely knowledgeable, informed, articulate, and ready to help. I appreciate you being here.
I understand the issue now. Certainly sounds annoying for someone to have to dig around and enable unauthenticated client access, but it seems like a stretch to consider it a security risk. I’ve written and reviewed many, many threat models. I’m struggling to see any sort of threat here. If someone does enable this on their Windows client, the only threat they’ve enabled is that the specific Windows client might intentionally or unintentionally establish an SMB connection to a LAN-accessible SMB server which has unauthenticated shares exposed. If the bad actor got to the point at which they could do this from your client machine, then they almost certainly established a foothold from which all sort of nasty things (much worse) could happen.
It does seem annoying, though.
I don’t run Roon on my client, though, and part of that is security. I run Roon/ROCK on a NUC and control what network shares it can access by locking everything down. I also sometimes run it in a Docker container on a Synology NAS where it only has access to the directories which have been mapped into the container. Either of these sound like more secure approaches than running it on an IT-managed Windows client.
I’ll also add that, as others have noted, security theater is often worse than the alternatives. Security theater creates the impression of security when there is none. Default usernames and passwords are awful in this regard. User settable credentials aren’t always much better if there are no mechanisms in place to prevent hammering and to enable users to be alerted to hammering/spray attacks. I’m in the camp of actually appreciating that Roon doesn’t have any username or password on its share. If I were a novice user, this would make it easy for me to use and configure and the risk of me locking myself out because of a forgotten password wouldn’t exist. As a very non-novice user, I appreciate the fact that Roon essentially implies “I’m not secured. Don’t treat me like I am.” I can get my head around that and make informed choices.
Thanks again, @Suedkiez for clarifying!
2 Likes
Yes, but you’re not in the support section.
People will have different views and opinions on security. Unless you can demonstrate a vulnerability I believe Roon has listened to all the arguments and made their decision. Which is why we’re back to public opinion. No one knows what the roadmap is. I hope they let us create user / pass for the shares over an encrypted transport.
Like all hobbyist software, there are options including the option to not run the software. ROCK is not the only way to get a Core up and running. In fact, someone super concerned with security might very well want to not run ROCK because you have no access to do things like… oh, I don’t know, run Snort or OSSEC and inotify in their environments <shrug>. Or, even an on system firewall that would block SMB access all together. We have options. Would be good to utilize them.
Yes, ROCK “guest” SMB share is bad practice. Is your whole world going to burn to the ground because of it? Has not happened yet (knock on wood). I still run it this way. I consider myself to have an above average level of knowledge in this space. I still shrug my shoulders. I’ve got music to listen to. Let’s go spend more time doing that.
7 Likes
Hey folks,
We’ve had a strange outbreak on Community with folks who are taking it upon themselves to repost previously moderated content and argue with moderators. Please don’t assume that you have the authority to supersede moderator decisions regarding the removal of toxic or inappropriate comments.
We explicitly cover this in the forum rules and guidelines.
Please don’t do this unless your goal is to be suspended or permanently banned from our forum. Thanks 
4 Likes