• Jeff Moden (4/7/2013)


    opc.three (4/7/2013)


    Jeff Moden (4/6/2013)


    If someone get's in as SA, it's not going to matter if you have xp_CmdShell turned off or not. 😉

    You keep throwing this one back into the conversation as if it's the only thing that matters. It's only one aspect of the case for or against using xp_cmdshell. No one has or is saying that by itself leaving xp_cmdshell disabled is going to secure a system but there is no arguing that enabling it and sanctioning its use lowers the bar for security and compromises ones ability to audit the actions taking place in the system. Repeating what you said over and over doesn't change the fact that having xp_cmdshell enabled is a security threat. If you choose not to see or consider other aspects of issue, and I do believe you have entrenched yourself in that choice regardless of how many points are made contrary to your position, then that's your prerogative, i.e. I think we have reached an impasse and am content with leaving the conversation here given that no new progress is being made.

    Some shops have the SQL Agent service disabled in their environment.

    What were they using to schedule their jobs, then?

    Windows Task Scheduler I already mentioned, and one place a few years back implemented an enterprise job scheduling tool from UC4. An enterprise job scheduling tool from Computer Associates is being looked at in the current shop.

    Shifting gears a bit, you've been stressing the auditing aspect of things. What type of system auditing do you currently have setup on your machines?

    I do not know. That is not my area of responsibility and I am not privy to what is being done from an auditing standpoint. I am pretty sure that is actually by design. It reduces the possibility that any one person can defeat the system if everyone is forced to operate on the network as themselves and there are distinct separations of responsibility. I think all of this points to the concept of layering security within an environment.

    Heh... and you keep repeating as much as I do. 😉 I don't believe it's a security problem and you do for the reasons that each of us has stated. I believe that overall security is the problem and that the tools used by trusted individuals are not.

    But, as you say, we've reached an impasse that's probably boring everyone to tears and I'll save our mutual disagreement for another time.

    The good part about all of this is that people have been given both sides of the story rather than the usual one sided story. They now have enough information to make a choice and might be a heck of a lot smarter about security than they otherwise may have been. So, my hat is off to you with sticking to this dicsussion for as long as you have. A lot of good stuff came to the surface as a result. Well done, Orlando.

    Sometimes the solution to a problem can found by looking at it in reverse. Let's assume that you're a SQL Server sysadmin and you lregitimately need xp_cmdshell to work for some critical process. What could go wrong?

    Based on a Bing search, there are reports of xp_cmdshell occasionally failing, even for sysadmin accounts, with an error related to xplog70.dll. So, perhaps the host server admin could block the SQL Server admin's usage of xp_cmdshell by deleting or denying access to this .dll at the file system level.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho