how to prevent access to \\127.0.0.1\c$ or \\localhost\c$
For security purposes, we want to prevent our users from accessing the C drive on their computers and on the terminal servers. These users are not local admins on either their workstations or the servers.
We have implemented the following Group Policy settings:
- Remove Run Menu from Start Menu
- Hide these specified drives in My Computer - Restrict C drive only -Prevent access to drives from My Computer - Restrict C drive only
This does prevent the users from accessing the C drive from Windows Explorer.
However, if they enter \127.0.0.1\c$ or \localhost\c$ they can access the C drive from any of these ways:
Internet Explorer / Edge
Chrome
A link in Microsoft Word
How can I prevent this? I repeat - they are not admins in any form, and yet they can access the C drive via the administrative share. (I am also not the only person reporting this problem).
I would be happy to block access to any UNC paths (as long as I can still map drives for them), or to prevent or misdirect 127.0.0.1/localhost. But nothing I have tried works, and I really need to prevent this.
Any ideas? It's most important for me to find a way to block this on Windows 10 Enterprise, but it seems to be an issue in various Workstation and Server operating systems.
Thanks,
David
Solution 1:
This was my initial answer:
This really is not default behaviour, so you have something odd going on. Either the default permissions have been changed (which IIRC isn't easy with conventional weaponry) or they are members of administrators (I know you said they are not but this might be an indirect membership), power users, or backup operators. Possibly also Print Operators.
I appreciate that isn't what you want to hear given how well you've emphasised that users aren't admins, but I've looked into this kind of thing dozens for times for people and it always turns out to be something like "Oh, I guess my colleague added 'all_staff' to the 'administrators' group one day because the CEO was screaming at him about not being able to RDP into the server from home".
And it's very wrong, but it deserves to stay as an illustration of a long-held belief not being tested often enough. I believe this is a change in behaviour from earlier versions of Windows, but I'm not sure when the change would have happened.
I've tested with Windows 10 Pro and Enterprise just in case they have different default settings, and Users can browse the local administrative shares and your options for controlling this seem rather limited I'm afraid. You can turn off Administrative shares as mdpc suggests (see https://support.microsoft.com/en-gb/help/954422/how-to-remove-administrative-shares-in-windows-server-2008) for a Microsoft source for this) but it may interfere with how various admin tools work on these computers (e.g. might prevent auto-deploying agents from deploying/updating) so I really would recommend against it.
Hiding the drive in the way you describe via GPO is nothing to do with permissions to the drive or share, by the way. This simply triggers a flag in Windows to hide certain drive letters. It's not reliable or robust and I've seen lots of admins in education, for example, go crazy trying to look this down against anything students can do but it is futile.
However... While users can access their local administrative share, they cannot access shares on other PCs, and their access via the share still only grants them the same access they would 'normally' have. Therefore, users cannot 'hack' the system this way; they cannot change things they don't already have the permissions to change.
You can and should lock down the root of the c:\ drive however. Here's some instructions for doing that:
- Go to your DC, Open ADUC, create a security group ('Lock down c drive' say) for users who will not be able to save files to root drive.
- Open GPMC, create a GPO which links to your target machines.
- Edit the policy and open [Computer Configuration | Policies | Windows Settings | Security Settings | File System ] Right click "File System", choose "Add File..." and select the "C:" drive, enter.
- In the security page, click "Advanced" button. Add the security group 'Lock down c drive'.
- With that group highlighted, click Advanced. In the Advanced Security Settings window, ensure that the correct group is still selected and click Edit.
- Change Type to 'Deny' and Applies To to 'This folder only'.
- Click the 'Show Basic permissions' / 'Show Advanced Permissions' toggle so you can see advanced permissions.
- Tick the Deny permission for the following items ONLY: 'Create files /Write data' and 'Create folders / Append data'.
- Click OK to exit the permissions editor, then click Ok again.
- In the warning window for Deny permissions, click Yes.
- Set the security policy setting to 'Configure this file or folder then', and choose 'Propagate inheritable permissions to all subfolders and files' (this is where you double-check that you got step 6 absolutely right before going live with this setting).
Give the GPO time to replicate and apply (gpupdate /force
can help here if you're in a hurry) and you should now find that users can't create files in the root of the c drive. They should only really have permission to their own folder inside \users at this point.
Solution 2:
I found a solution to the problem in the registry fix mentioned here:
https://social.technet.microsoft.com/Forums/office/en-US/b168408e-a540-4e3a-92cc-3121486ceb78/admin-shares-available-to-nonadministrative-users-over-loopback-address?forum=winserversecurity
I tested it and it works. I deployed the change via Group Policy, and the computers received the change.
That post also discusses how this was a change that occurred in the move from Windows 2003 to Windows 2008:
"This behavior occurs because the administrative share's default share permission was changed in Windows Server 2008, which allows the active logon account to access the administrative shares.
The administrative share's default share permission is controlled by the registry value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\DefaultSecurity\SrvsvcShareAdminConnect.
To configure Windows Server 2008 to behave the same as Windows Server 2003, we can export the registry value above from Window Server 2003, and import it to Windows Server 2008. Please Note: We need to restart the server for the change to take effect."