Re: Net Share IPC$ /Delete
- From: "Roger Abell [MVP]" <mvpNoSpam@xxxxxxx>
- Date: Thu, 3 Aug 2006 17:09:19 -0700
"Will" <westes-usc@xxxxxxxxxxxxxx> wrote in message
news:eGlUIlrtGHA.4336@xxxxxxxxxxxxxxxxxxxxxxx
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
.
- Follow-Ups:
- Re: Net Share IPC$ /Delete
- From: Will
- Re: Net Share IPC$ /Delete
- References:
- Net Share IPC$ /Delete
- From: Will
- Net Share IPC$ /Delete
- Prev by Date: Re: Can this be done without affecting current configuration
- Next by Date: Re: Can this be done without affecting current configuration
- Previous by thread: Net Share IPC$ /Delete
- Next by thread: Re: Net Share IPC$ /Delete
- Index(es):
Relevant Pages
|
Loading
