Net Share IPC$ /Delete
Will
would like to harden a bit more than a typical computer. I want to
understand the implications of two actions:
1) Disabling network administrative shares. Apparently you can disable
the C$, D$, ADMIN$ shares by a registry key AutoShareServer = 0. What
applications will stop working as a result? I gather you won't be able to
use SMS or applications that outright modify a remote computer's files using
these shares. I'm okay with that, but I want to know what else would
break. I plan to disable these shares on both member servers and domain
controller.
2) Disabling IPC$. I gather that this hidden share is created by the
server service and used somehow with RPC. I guess you would have to keep
this running on a domain controller, otherwise many basic domain operations
would break?
On member servers that have no file shares enabled, what would break if you
disabled IPC$? I don't need to be able to open up event viewer remotely,
for example.
As far as how to disable the IPC$ share on member servers, I don't find any
way to stop its creation short of disabling the server service. Would it
be preferable to just run a script when the computer boots that issues a net
share ipc$ /delete command? What is the registry key or group policy
option that would allos this?
Disabling IPC$ on the member server won't stop the use of RPC client on the
member server, right?
--
Will
Roger Abell [MVP]
"Will" <weste...@noemail.nospam> wrote in message
news:eGlUIlrt...@TK2MSFTNGP06.phx.gbl...
>I have some Windows 2000 (and eventually 2003) computers in a DMZ that I
> would like to harden a bit more than a typical computer. I want to
> understand the implications of two actions:
>
> 1) Disabling network administrative shares. Apparently you can disable
> the C$, D$, ADMIN$ shares by a registry key AutoShareServer = 0. What
> applications will stop working as a result? I gather you won't be able
> to
> use SMS or applications that outright modify a remote computer's files
> using
> these shares. I'm okay with that, but I want to know what else would
> break. I plan to disable these shares on both member servers and domain
> controller.
About the only things that would break are some remote management
utilities. For example, MBSA in a remote scan for patches wants to
access this to verify binaries.
>
> 2) Disabling IPC$. I gather that this hidden share is created by the
> server service and used somehow with RPC. I guess you would have to
> keep
> this running on a domain controller, otherwise many basic domain
> operations
> would break?
>
> On member servers that have no file shares enabled, what would break if
> you
> disabled IPC$? I don't need to be able to open up event viewer remotely,
> for example.
>
> As far as how to disable the IPC$ share on member servers, I don't find
> any
> way to stop its creation short of disabling the server service. Would
> it
> be preferable to just run a script when the computer boots that issues a
> net
> share ipc$ /delete command? What is the registry key or group policy
> option that would allos this?
>
> Disabling IPC$ on the member server won't stop the use of RPC client on
> the
> member server, right?
>
I have not gone there, and frankly I do not see the advantage of it,
but I do see the hazard of it.
If the machine is latched down so that ports are only of use with the
defined IPs, or better the otherwise identified set of machines, then
attempting to close up everything, particularly if you do not know the
full implications, is likely to give you a fragile machine. And by fragile
I mean also one that might check out just fine initially for the defined
use cases, but one which crumbles miserably at the next patch or
service pack.
I feel this is the case with IPC$. MS would not be expecting this
to be non-functional (after all, it is not simple to shut off, right).
If you were to disable IPC$ then you would cripple all means for
communicating with the machine by anything that relies on mailslots
or named pipes. For a stand-alone that you intend to be isolated
that may be fine, but then, you can do the same with the firewall
or by use of IPsec filtering. For a domain member not being able
to participate in mailslot or named pipe communication would most
likely have highly undesireable effects.
> --
> Will
>
>
Will
news:eo9s8o1t...@TK2MSFTNGP05.phx.gbl...
> I have not gone there, and frankly I do not see the advantage of it,
> but I do see the hazard of it.
> For a stand-alone that you intend to be isolated
> that may be fine, but then, you can do the same with the firewall
> or by use of IPsec filtering. For a domain member not being able
> to participate in mailslot or named pipe communication would most
> likely have highly undesireable effects.
I like your idea of using IPsec filtering for doing this, and that is
probably the right strategy. I have to agree it looks like Microsoft
deliberately prevents you from disabling IPC$ in the registry, and that
probably does mean an unpleasant surprise somewhere down the road if I force
it to disable.
I have not really played with IPsec at all. I guess I will have to start
reading up on that.
--
Will
Rob Greene [MSFT]
Here is a knowledge base article that lists out some of the things that
break when Administrative Shares are missing:
842715 Overview of problems that may occur when administrative shares are
missing
http://support.microsoft.com/default.aspx?scid=kb;EN-US;842715
--
Rob Greene
Microsoft Enterprise Platforms Support
All postings on this newsgroup are provided "AS IS" with no warranties, and
confer no rights.
For more information please visit
http://www.microsoft.com/info/cpyright.mspx to find terms of use.
"Will" <weste...@noemail.nospam> wrote in message
news:eGlUIlrt...@TK2MSFTNGP06.phx.gbl...
Roger Abell [MVP]
Thanks for posting the link.
I find that KB poorly written, at best. It seems to be mixing up
what may happen when the shares are disabled on DCs vs non-DCs,
and what results from admin shares absence vs from the implanting
malicious software and its interference with these shares.
Now, granted that I do not run Mac support many places, but on
servers, both W2k and W2k3, within AD (non-DC) with the admin
shares disabled, I have never seen any of the indicated issues.
Since admin shares are quite commonly stopped, one would think
that what this KB describes would be reported quite often if these
were to happen just from setting the Autoshare entries to 0 on client
and member server systems.
As Will, the originator of this thread, indicated, stopping admin shares
does not get rid of IPC$. Some of what the KB describes seems to
be a likely result from IPC$ being unavailable, hence I wonder about
the extent to which the KB actually is describing malware impacts that
have also blocked this.
--
Roger
"Rob Greene [MSFT]" <rob...@online.microsoft.com> wrote in message
news:OfASGPKu...@TK2MSFTNGP03.phx.gbl...