administrator shares

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

how to disable administrator shares?
i heard there is a registry key, that can be modified....
 
the article is not about :"how to disable administrator shares?"

i know how to configure shares, i don't know how to delete administrator
shares FOREVER, not untill the next reboot...
 
unfortunatly i don't have the following registry key, that should be changed
(???)

Hive: HKEY_LOCAL_MACHINE
Key: SYSTEM\CurrentControlSet\Services\LanManServer\Parameters
Name: AutoShareServer for servers
Name: AutoShareWks for workstations
Type: REG_DWORD
Value: 0
 
You have to add the key (which defaults to '1') set to '0' such that it will be disabled.

Dave



|
| unfortunatly i don't have the following registry key, that should be changed
| (???)
|
| Hive: HKEY_LOCAL_MACHINE
| Key: SYSTEM\CurrentControlSet\Services\LanManServer\Parameters
| Name: AutoShareServer for servers
| Name: AutoShareWks for workstations
| Type: REG_DWORD
| Value: 0
|
|
|
| "Mike Bright MSP" wrote:
|
| > Raitis,
| >
| > Have a look at the following page:
| >
| >
http://www.windowsnetworking.com/kb...WindowsNTW2KXPHiddenAdministrativeShares.html
| >
| > Regards
| >
| > Mike Bright MCP, MSP
| >
| > e:[email protected]
| >
| >
| >
 
Now that you do have info on the Lanmmanserver reg value to disable the
administrative shares, I have to ask why do you want to disable them ?

I have seen more people not being able to get back in because these were
not available after they had goofed and gotten locked out; but I have never
seen nor heard of any machine that was breached because of their being
present.
 
Roger:
For a MS MVP replying in a "security" related News Group, you don't study the actions of
Internet worms do you.

W32/Sdbot.worm.73728 -- http://vil.nai.com/vil/content/v_100748.htm
W32/Graps.worm -- http://vil.nai.com/vil/content/v_100467.htm
W32/Slanper.worm -- http://vil.nai.com/vil/content/v_100445.htm
W32/Lioten.worm -- http://vil.nai.com/vil/content/v_99897.htm
W32/Deborm.worm.q -- http://vil.nai.com/vil/content/v_100234.htm
W32/Sluter.worm -
http://vil.nai.com/vil/content/v_100443.htm
http://vil.nai.com/vil/content/v_100642.htm
BAT/Mumu.worm.c -- http://vil.nai.com/vil/content/v_100530.htm
W32/Gaobot.worm -
http://vil.nai.com/vil/content/v_125006.htm
http://vil.nai.com/vil/content/v_101447.htm
http://vil.nai.com/vil/content/v_100785.htm
IRC-Vup -- http://vil.nai.com/vil/content/v_100278.htm
IRC-Smev -- http://vil.nai.com/vil/content/v_99448.htm
IRC/Flood -
http://vil.nai.com/vil/content/v_100361.htm
http://vil.nai.com/vil/content/v_100427.htm
http://vil.nai.com/vil/content/v_100363.htm
Egghead -- http://vil.nai.com/vil/content/v_99378.htm


I think the above is a good representative list of infectors that deliberately attack
administrative shares such as...
c$ ~ Z$
admin$
print$
IPC$

MCSE - Microsoft Cant Secure Enough ;-)

Dave
BTW: Some of the above have "quite an extensive list" of known passwords to use against the
hidden shares. It's no wonder why AR-25-2 requires 10 digit passwords using; 2 Upper, 2
Lower, 2 Numbers and 2 Special chars.



| Now that you do have info on the Lanmmanserver reg value to disable the
| administrative shares, I have to ask why do you want to disable them ?
|
| I have seen more people not being able to get back in because these were
| not available after they had goofed and gotten locked out; but I have never
| seen nor heard of any machine that was breached because of their being
| present.
|
| --
| Roger Abell
| Microsoft MVP (Windows Server System: Security)
| MCDBA, MCSE W2k3+W2k+Nt4
| | > how to disable administrator shares?
| > i heard there is a registry key, that can be modified....
| > --
| > thanks,
| > Raitis
|
|
 
TRY THIS
Hive: HKEY_LOCAL_MACHINE
Key: SYSTEM\CurrentControlSet\Services\LanManServer\Parameters
Name: AutoShareServer for servers
Name: AutoShareWks for workstations
Type: REG_DWORD
Value: 0

Good luck.
 
Administrative shares require credentials of an admin to
be accessed.
The shares in and of themselves are not a security problem.
Giving away administrative access is a problem, and having
administrative shares present are not a major issue if one
has already given away administrative access/credentials.
 
Like I stated -- Some of the above have "quite an extensive list" of known passwords to use
against the hidden shares."

Please take the time and READ the URLs I provided and you will see that the VX'ers have
certainly done their homework in writing their respective code to infect targeted platforms.

I also suggest you spend some time in the following News Groups --
microsoft.public.scripting.virus.discussion
microsoft.public.security.virus
alt.comp.virus
alt.comp.anti-virus

I haven't seen you there. ;-)

Dave




| Administrative shares require credentials of an admin to
| be accessed.
| The shares in and of themselves are not a security problem.
| Giving away administrative access is a problem, and having
| administrative shares present are not a major issue if one
| has already given away administrative access/credentials.
|
| --
| Roger Abell
| Microsoft MVP (Windows Server System: Security)
| MCDBA, MCSE W2k3+W2k+Nt4
| | > Roger:
| > For a MS MVP replying in a "security" related News Group, you don't study
| > the actions of
| > Internet worms do you.
| >
| > W32/Sdbot.worm.73728 -- http://vil.nai.com/vil/content/v_100748.htm
| > W32/Graps.worm -- http://vil.nai.com/vil/content/v_100467.htm
| > W32/Slanper.worm -- http://vil.nai.com/vil/content/v_100445.htm
| > W32/Lioten.worm -- http://vil.nai.com/vil/content/v_99897.htm
| > W32/Deborm.worm.q -- http://vil.nai.com/vil/content/v_100234.htm
| > W32/Sluter.worm -
| > http://vil.nai.com/vil/content/v_100443.htm
| > http://vil.nai.com/vil/content/v_100642.htm
| > BAT/Mumu.worm.c -- http://vil.nai.com/vil/content/v_100530.htm
| > W32/Gaobot.worm -
| > http://vil.nai.com/vil/content/v_125006.htm
| > http://vil.nai.com/vil/content/v_101447.htm
| > http://vil.nai.com/vil/content/v_100785.htm
| > IRC-Vup -- http://vil.nai.com/vil/content/v_100278.htm
| > IRC-Smev -- http://vil.nai.com/vil/content/v_99448.htm
| > IRC/Flood -
| > http://vil.nai.com/vil/content/v_100361.htm
| > http://vil.nai.com/vil/content/v_100427.htm
| > http://vil.nai.com/vil/content/v_100363.htm
| > Egghead -- http://vil.nai.com/vil/content/v_99378.htm
| >
| >
| > I think the above is a good representative list of infectors that
| > deliberately attack
| > administrative shares such as...
| > c$ ~ Z$
| > admin$
| > print$
| > IPC$
| >
| > MCSE - Microsoft Cant Secure Enough ;-)
| >
| > Dave
| > BTW: Some of the above have "quite an extensive list" of known passwords
| > to use against the
| > hidden shares. It's no wonder why AR-25-2 requires 10 digit passwords
| > using; 2 Upper, 2
| > Lower, 2 Numbers and 2 Special chars.
| >
| >
| >
| > | > | Now that you do have info on the Lanmmanserver reg value to disable the
| > | administrative shares, I have to ask why do you want to disable them ?
| > |
| > | I have seen more people not being able to get back in because these were
| > | not available after they had goofed and gotten locked out; but I have
| > never
| > | seen nor heard of any machine that was breached because of their being
| > | present.
| > |
| > | --
| > | Roger Abell
| > | Microsoft MVP (Windows Server System: Security)
| > | MCDBA, MCSE W2k3+W2k+Nt4
| > | | > | > how to disable administrator shares?
| > | > i heard there is a registry key, that can be modified....
| > | > --
| > | > thanks,
| > | > Raitis
| > |
| > |
| >
| >
|
|
 
By your reasoning, because the admin shares are used as an
attack vector, and I will state again as a vector that only works
in their favor AFTER they have admin credentials, we should
not use anything that may be used as part of an attack vector.
What I said is that the admin shares in and of themselves are
not the issue. That I do believe as I have thousands of machines
with them enabled and do not have a worm problem.
The issue is weak passwording of administrative accounts.
Without administrative credentials, the admin shares are of no
use whatsoever. Disabling admin shares does not remove IPC$
so one cannot say that disabling them removes the way where
one can test to find an admin uid/pwd combination.
By your reasoning, which seems to be, because these can be
used to propagate a worm they should be removed, then we
should remove all RPC, heck, even the NIC and net wire !

Please, think a bit more deeply and critically at what it is that I did
say. The machines are not breached because of the admin
shares but because of the failure to secure admin accounts
and then this make the admin shares of use. However, even
without the admin shares, the admin credentials would give away
the machine.

Nice try at making me aware of issue about which I do have an
awareness, but I just do not buy into your reasoning even if it is
the commonly held viewpoint today. Years ago I was paranoid
about the admin shares; today I recognize the real issue is
elsewhere.
 
My statements were in direct reply with your statement --
"...but I have never seen nor heard of any machine that was breached because of their being
present."

I merely provided the contrary.
In respect to your last reply, I can't disagree with it.

Dave





| By your reasoning, because the admin shares are used as an
| attack vector, and I will state again as a vector that only works
| in their favor AFTER they have admin credentials, we should
| not use anything that may be used as part of an attack vector.
| What I said is that the admin shares in and of themselves are
| not the issue. That I do believe as I have thousands of machines
| with them enabled and do not have a worm problem.
| The issue is weak passwording of administrative accounts.
| Without administrative credentials, the admin shares are of no
| use whatsoever. Disabling admin shares does not remove IPC$
| so one cannot say that disabling them removes the way where
| one can test to find an admin uid/pwd combination.
| By your reasoning, which seems to be, because these can be
| used to propagate a worm they should be removed, then we
| should remove all RPC, heck, even the NIC and net wire !
|
| Please, think a bit more deeply and critically at what it is that I did
| say. The machines are not breached because of the admin
| shares but because of the failure to secure admin accounts
| and then this make the admin shares of use. However, even
| without the admin shares, the admin credentials would give away
| the machine.
|
| Nice try at making me aware of issue about which I do have an
| awareness, but I just do not buy into your reasoning even if it is
| the commonly held viewpoint today. Years ago I was paranoid
| about the admin shares; today I recognize the real issue is
| elsewhere.
|
| --
| Roger Abell
| Microsoft MVP (Windows Server System: Security)
| MCDBA, MCSE W2k3+W2k+Nt4
| | > Like I stated -- Some of the above have "quite an extensive list" of known
| > passwords to use
| > against the hidden shares."
| >
| > Please take the time and READ the URLs I provided and you will see that
| > the VX'ers have
| > certainly done their homework in writing their respective code to infect
| > targeted platforms.
| >
| > I also suggest you spend some time in the following News Groups --
| > microsoft.public.scripting.virus.discussion
| > microsoft.public.security.virus
| > alt.comp.virus
| > alt.comp.anti-virus
| >
| > I haven't seen you there. ;-)
| >
| > Dave
| >
| >
| >
| >
| > | > | Administrative shares require credentials of an admin to
| > | be accessed.
| > | The shares in and of themselves are not a security problem.
| > | Giving away administrative access is a problem, and having
| > | administrative shares present are not a major issue if one
| > | has already given away administrative access/credentials.
| > |
| > | --
| > | Roger Abell
| > | Microsoft MVP (Windows Server System: Security)
| > | MCDBA, MCSE W2k3+W2k+Nt4
| > | | > | > Roger:
| > | > For a MS MVP replying in a "security" related News Group, you don't
| > study
| > | > the actions of
| > | > Internet worms do you.
| > | >
| > | > W32/Sdbot.worm.73728 -- http://vil.nai.com/vil/content/v_100748.htm
| > | > W32/Graps.worm -- http://vil.nai.com/vil/content/v_100467.htm
| > | > W32/Slanper.worm -- http://vil.nai.com/vil/content/v_100445.htm
| > | > W32/Lioten.worm -- http://vil.nai.com/vil/content/v_99897.htm
| > | > W32/Deborm.worm.q -- http://vil.nai.com/vil/content/v_100234.htm
| > | > W32/Sluter.worm -
| > | > http://vil.nai.com/vil/content/v_100443.htm
| > | > http://vil.nai.com/vil/content/v_100642.htm
| > | > BAT/Mumu.worm.c -- http://vil.nai.com/vil/content/v_100530.htm
| > | > W32/Gaobot.worm -
| > | > http://vil.nai.com/vil/content/v_125006.htm
| > | > http://vil.nai.com/vil/content/v_101447.htm
| > | > http://vil.nai.com/vil/content/v_100785.htm
| > | > IRC-Vup -- http://vil.nai.com/vil/content/v_100278.htm
| > | > IRC-Smev -- http://vil.nai.com/vil/content/v_99448.htm
| > | > IRC/Flood -
| > | > http://vil.nai.com/vil/content/v_100361.htm
| > | > http://vil.nai.com/vil/content/v_100427.htm
| > | > http://vil.nai.com/vil/content/v_100363.htm
| > | > Egghead -- http://vil.nai.com/vil/content/v_99378.htm
| > | >
| > | >
| > | > I think the above is a good representative list of infectors that
| > | > deliberately attack
| > | > administrative shares such as...
| > | > c$ ~ Z$
| > | > admin$
| > | > print$
| > | > IPC$
| > | >
| > | > MCSE - Microsoft Cant Secure Enough ;-)
| > | >
| > | > Dave
| > | > BTW: Some of the above have "quite an extensive list" of known
| > passwords
| > | > to use against the
| > | > hidden shares. It's no wonder why AR-25-2 requires 10 digit passwords
| > | > using; 2 Upper, 2
| > | > Lower, 2 Numbers and 2 Special chars.
| > | >
| > | >
| > | >
| > | > | > | > | Now that you do have info on the Lanmmanserver reg value to disable
| > the
| > | > | administrative shares, I have to ask why do you want to disable them
| > ?
| > | > |
| > | > | I have seen more people not being able to get back in because these
| > were
| > | > | not available after they had goofed and gotten locked out; but I
| > have
| > | > never
| > | > | seen nor heard of any machine that was breached because of their
| > being
| > | > | present.
| > | > |
| > | > | --
| > | > | Roger Abell
| > | > | Microsoft MVP (Windows Server System: Security)
| > | > | MCDBA, MCSE W2k3+W2k+Nt4
| > | > | | > | > | > how to disable administrator shares?
| > | > | > i heard there is a registry key, that can be modified....
| > | > | > --
| > | > | > thanks,
| > | > | > Raitis
| > | > |
| > | > |
| > | >
| > | >
| > |
| > |
| >
| >
|
|
 
Dave,

We go in circles. The machine was breached when
the admin credentials were obtained. Use of the admin
shares was a subsequent action.
 
David H. Lipman said:
My statements were in direct reply with your statement --
"...but I have never seen nor heard of any machine that was breached
because of their being
present."

I merely provided the contrary.
In respect to your last reply, I can't disagree with it.

Dave
Click to expand...

I might add, I do believe in defense in layers, and as a part of
that, disabling things that are unused, as the admin shares may
be for many, certainly the Home user with one machine may be
a valid action. However, there seems to be lower hanging fruit
in terms of getting a Home user to have a safer system and
usage of it.

What I do find hazardous is people (and I do not mean yourself)
that misinterpret what the exposure from admins shares actually
is, and perhaps go off believing that by disabling them they have
actually cured something, as it is just not so. If the admins shares
are a problem, it is _only_ due to another problem in the machine's
configuration or use pattern.

I see this as analogous to the cancer patient with prescription for
morphine thinking that their disease is gone because they do not
feel it. Perpetuating the belief that the admin shares _cause_
the problem, rather than act as a piece of it after the fact, is not
all that helpful; we should be pointing people's noses at the root
problem - how they secure (or fail to) and overuse their privileged
accounts.

I can see how your interpretation of my statement
"...but I have never seen nor heard of any machine that was
breached because of their being present."
is a reasonable reading. I hope at this point you see how it
was meant. Their presence is not the root cause, and as such
I do not consider the breach because of them, and without them
the breach of administrative access would just have expressed
itself in another vector.
 
I sure do see "...at this point you see how it was meant." But, I don't think we are going
in circles. Not when an Administrator or one with administrative rights is infected and the
worm propagates via port 445 or NetBIOS to infect poorly secured hidden shares.

Good discussion however ;-)

Dave




| | > My statements were in direct reply with your statement --
| > "...but I have never seen nor heard of any machine that was breached
| > because of their being
| > present."
| >
| > I merely provided the contrary.
| > In respect to your last reply, I can't disagree with it.
| >
| > Dave
| >
|
| I might add, I do believe in defense in layers, and as a part of
| that, disabling things that are unused, as the admin shares may
| be for many, certainly the Home user with one machine may be
| a valid action. However, there seems to be lower hanging fruit
| in terms of getting a Home user to have a safer system and
| usage of it.
|
| What I do find hazardous is people (and I do not mean yourself)
| that misinterpret what the exposure from admins shares actually
| is, and perhaps go off believing that by disabling them they have
| actually cured something, as it is just not so. If the admins shares
| are a problem, it is _only_ due to another problem in the machine's
| configuration or use pattern.
|
| I see this as analogous to the cancer patient with prescription for
| morphine thinking that their disease is gone because they do not
| feel it. Perpetuating the belief that the admin shares _cause_
| the problem, rather than act as a piece of it after the fact, is not
| all that helpful; we should be pointing people's noses at the root
| problem - how they secure (or fail to) and overuse their privileged
| accounts.
|
| I can see how your interpretation of my statement
| "...but I have never seen nor heard of any machine that was
| breached because of their being present."
| is a reasonable reading. I hope at this point you see how it
| was meant. Their presence is not the root cause, and as such
| I do not consider the breach because of them, and without them
| the breach of administrative access would just have expressed
| itself in another vector.
|
| --
| Roger
|
|
 
Back
Top