6

I have to set up some shares on a windows server (2003), but I really don't like those default shares (C$, ADMIN$, IPC$).

I seem to remember that you shouldn't remove those shares, but when the sharing service is disabled they don't work anyway, so why should I leave them when the service is enabled? Can I remove them without risking a reboot?

I always thought of them as a liability, so please correct me if I'm wrong.

Eddie
  • 11,332
  • 8
  • 36
  • 48
Berzemus
  • 1,162
  • 3
  • 11
  • 19

7 Answers7

6

Per this article from the Microsoft Knowledge Base:

  • DriveLetter$: This is a shared root partition or volume. Shared root partitions and volumes are displayed as the drive letter name appended with the dollar sign ($). For example, when drive letters C and D are shared, they are displayed as C$ and D$.
  • ADMIN$: This is a resource that is used during remote administration of a computer.
  • IPC$: This is a resource that shares the named pipes that you must have for communication between programs. This resource cannot be deleted.
  • NETLOGON: This is a resource that is used on domain controllers.
  • SYSVOL: This is a resource that is used on domain controllers.
  • PRINT$: This is a resource that is used during the remote administration of printers.
  • FAX$: This is a shared folder on a server that is used by fax clients during fax transmission. Note NETLOGON and SYSVOL are not hidden shares. Instead, these are special administrative shares

You can remove these shares live as per Roy's answer.

Note: Windows will automatically create the admin shares after a reboot. To prevent this behavior, use regedit to find the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

Create the following 2 DWORD registry values:

AutoShareServer 0
AutoShareWks 0
Bork Blatt
  • 453
  • 2
  • 7
  • +1 for the list, but -1 because on a DC you should NOT delete the sysvol share (unless you want to break GPOs) or te netlogon share (unless you want to break legacy logon scripts). – Maximus Minimus Jun 10 '09 at 13:22
  • +1 for his -1 because you didn't suggest it was a good idea to delete the sysvol share, but instead showed what it was for. – MathewC Jun 10 '09 at 13:26
  • Yep, thought the list would explain what the shares are about. The only ones I disable immediately are the drive ones (C$ etc). – Bork Blatt Jun 10 '09 at 13:39
3

Look at this microsoft article:
How to create and delete hidden or administrative shares on client computers

To delete a hidden share, follow these steps:

In Control Panel, double-click Administrative Tools, and then double-click Computer Management.
Expand Shared Folders, and then click Shares.
In the Shared Folder column, right-click the share that you want to delete,
click Stop sharing, and then click OK.

Troubleshooting
Test the functionality of your programs and services after you disable the default administrative shares. Some Windows services depend on the existence of these shares.

EDIT: (Thanks Bork Blatt)
You need to edit registry to prevent shared drives from being re-created after you restart the computer.
wiki

Jindrich
  • 4,958
  • 8
  • 29
  • 42
  • 1
    +1 for this answer. However, be aware that Windows will simply recreate these shares after a reboot. To stop Windows from doing this you need to set a registry key. I'll post details below. – Bork Blatt Jun 10 '09 at 12:59
2

The only things I'm aware of it breaking are MS management software, like SMS and MOM. Even the howto KB above only gives a "microsoft recommends against", not terribly dire.

Kara Marfia
  • 7,892
  • 5
  • 32
  • 56
0

I suppose if you're hardcore they are a liability. I find them useful and use C$/D$ every day. Since you'd need to be an administrator to connect to them, I don't see a reason for removing them. Roy has already linked the MS article to get rid of them. I believe it requires a reboot. If you needed to stop people from connecting to all shares while you waited to reboot you could stop the "server" service.

MathewC
  • 6,877
  • 9
  • 38
  • 53
0

By default these shares can't be accessed anonymously, so a user needs to be already authenticated before they can potentially misuse them. And if the bad guy is already in your network, I think you've bigger things to be worrying about than the default admin shares.

Anyway, aside from even windows services that may depend on them, as an administrator they can be incredibly useful. e.g. if you need to access to the C drive of a machine without having to remote into it.

My instinct is to not mess with built-in functionality, as it may have ramifications far beyond what seems the obvious.

Maximus Minimus
  • 8,937
  • 1
  • 22
  • 36
0

I cannot comment yet but I wanted to expand Bork's post in regards to NETLOGON and SYSVOL shares.

Netlogon will be the default location AD pulls your login scripts from. Sysvol will hold group policies and your catalogs depending on the server role.

@MatthewC If you compromise a machine, add another account, give it Admin access. You can get full access to those network shares. I used to do it to my roommates comp...

It is SO easy to compromise a single machine its not funny.

XTZ
  • 183
  • 1
  • 1
  • 10
  • If you compromise a machine and give yourself admin access, it won't matter whether those shares are enabled or not. – KevinH Jun 10 '09 at 13:48
  • Good point, but it gives less opportunity if they are hard disabled, and means more time interacting with the system. Forcing a system to reboot/altering reg user credentials on a machine are an easy way to get busted doing pen testing though. – XTZ Jun 10 '09 at 14:32
0

It used to be recommended for these to be disabled, but too many products which we use to manage environments like SMS/SCCM use them. For instance, some patch-management products deploy using the admin shares. So we leave them on. The key is to ensure that only the valid people who should have administrative rights to the system have it. Because otherwise, someone could come in and re-activate them (yes, I'm aware that you can force the settings back down via GPO, but there are ways of preventing GPO from working or affecting those settings).

K. Brian Kelley
  • 9,004
  • 31
  • 33