SQL 2k - xp_cmdshell

[goldenbear]

How do I disable xp_cmdshell?

[camel]

You can readily deny access to non sysadmin in the standard way, i.e. you can just cut off master access to non admin users and you can grant\deny on the extended SP itself. If you are having trouble with users calling cmdshell who have no business doing so that is a matter for tightening up security e.g remote access if you are worried about hacking. In 2005 you can just disable it full stop but there will likely always be legitimate need for cmdshell for sysadmins.

[goldenbear]

You can readily deny access to non sysadmin in the standard way, i.e. you can just cut off master access to non admin users and you can grant\deny on the extended SP itself. If you are having trouble with users calling cmdshell who have no business doing so that is a matter for tightening up security e.g remote access if you are worried about hacking. In 2005 you can just disable it full stop but there will likely always be legitimate need for cmdshell for sysadmins.

I think we were hacked but don't know exactly how. I suspect they may have gotten sysadmin access because there was key loging going on and the system32 OS directory accessed, so I thought to disable it system admin and all as well. So if I deleted or disable it, how to do that and undo if needs be?Thanks

[camel]

Casting my mind back to SQL2K, when you right click on the extended SP in master db named xp_cmdshell it should tell you the name of the DLL behind it, you can then move it to another location.

This will cause any calling process that tries to execute xpcmdshell to break. I would not recommend this, for you are potentially taking a chance that legit routines you may be unaware of everything relying on xpcmdshell, i.e., MS procedures you are using may under the hood rely on xpcmdshell too.

The scenario is much, much improved in SQL2005 so if you are planning an upgrade any time soon hold on for that and tighten your external firewall, rather than risking the integrity of the SQL2K install would be my advice but up to you

[goldenbear]

Casting my mind back to SQL2K, when you right click on the extended SP in master db named xp_cmdshell it should tell you the name of the DLL behind it, you can then move it to another location.

This will cause any calling process that tries to execute xpcmdshell to break. I would not recommend this, for you are potentially taking a chance that legit routines you may be unaware of everything relying on xpcmdshell, i.e., MS procedures you are using may under the hood rely on xpcmdshell too.

The scenario is much, much improved in SQL2005 so if you are planning an upgrade any time soon hold on for that and tighten your external firewall, rather than risking the integrity of the SQL2K install would be my advice but up to you

Thanks..I used [EXEC sp_dropextended proc 'xp_cmdshell'] on master to remove it and so far seems to have no effect on other sp's.