Guest account from Chromebook showing up in Connections under Logs on ReadyNAS

[Kwilk6]

Hi All,

Have an issue where a Chromebook is showing up on my ReadyNAS's using a Guest account even though there is no  guest account and the IP address of the Chromebook is not among the list of whitelisted Hosts for the Shares.  An example of this is shown in the attached screen shot.

Any ideas as to why this is happening?  All the ReadyNAS's are running 6.10.3.

[StephenB]

The NAS does have a built-in guest account (not something you can remove).

If you have anonymous access enabled for a share, then the NAS accept guest connections.  So if this is concerning, you should disable anonymous access for all your shares.

[Kwilk6]

Thank you for the fast reply!  Anonymous access is turned off for all the RadyNAS's shares.  An example from one of the NAS's is shown in the attached screen shot.

[StephenB]

Is the chromebook actually able to access anything?

[Kwilk6]

In testing from the Chromebook, access is not allowed without authentication for the Admin account due to the host restrictions setup under the SMB protocol under Network Access in the Shares settings.  Also attempted to login using the Guest account using a variety of possible passwords and this failed as well.  Is there a default password used by Guest or Anonymous accounts?

Also tested from a Windows 10 box just for comparison sake with the same results.  The difference is that the Chromebook IP address still shows up in the connections list, whereas the PC's on the network do not.

The concern in this case is that the Chromebook is a loaner from my sons school for remote learning purposes and, besides the fact that the ReadyNAS's were somehow automatically added to the Chromebooks list of File Shares, it continues to show up in the list of Connections whereas the Windows 10 PC's do not.  If there is a default password for Guest accounts it seems feasible to me that it could be used to gain access to the NAS's since it is an identified account.

We deleted the File Shares that were initially created on the Chromebook and that is why the screenshot shows a new File Share being added.

[StephenB]

---

@Kwilk6 wrote:

 Is there a default password used by Guest or Anonymous accounts?

No, and if there were a password needed than they wouldn't work as intended.

However, the guest account on the NAS is configured so that you can't log into the NAS itself (with ssh) using it.  It's used only for other file protocols, and even there it requires that the network permissions be set up to allow anonymous access.  In your case, you've already confirmed that they aren't set up that way.

However, the share list can be seen with guest credentials, even if the shares themselves can't be accessed.  So it is possible that the chromebook is simply searching for network shares on the network.

Also, you might try rebooting the chromebook, and see if the connection disappears.

FWIW, we also are dealing with a chromebook loaner - I haven't had to do much with it, but there definitely is a learnng curve.  But I am not seeing a guest connection from it on my NAS.

[Kwilk6]

Thanks for the additional info and info on your Chromebook.  It looks like it will be necessary to Wireshark the connection between the Chromebook and one of the NAS to see what is actually going on.  That should be fun.  I suspect there is some sort of remote monitoring going on with that device, which is fine since it is a learning device, and I hope I don't find out that there is an overzealous admin searching home networks simply because they can.

Still a bit nervous about that account showing up in the connections listing, especially when there are no File Shares currently defined on the Chromebook.  I recall there being some security issues as well with those devices, but that was a lifetime ago and I really hoped to never see another one of them. 🙂 

[schumaku]

The discovery and enumeration of shared folders does often happen without any authentication - unless it's disabled. That's why the non-authenticated (misleadingly named guest) does pop-up in the "access" list. Nothing wrong...