Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««45678»»»

How to call a batch file to execute from an SP Expand / Collapse
Author
Message
Posted Monday, March 25, 2013 8:38 PM
SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Sunday, July 20, 2014 5:23 PM
Points: 4,576, Visits: 8,341
opc.three (3/25/2013)
What gave you that impression?

Lack of answers on direct questions from me and Jeff.
You have nothing to support your words.
Seriously, where are you going with it Sergiy? We have said what we're going to say and we disagree. Have a good evening, I'll see you around

And this, yes.
Having nothing to support your point you choose to just quit the conversation.
Very professional.
Good luck!
Post #1435236
Posted Monday, March 25, 2013 8:44 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Monday, July 21, 2014 4:52 PM
Points: 7,079, Visits: 12,569
Sergiy (3/25/2013)
opc.three (3/25/2013)
What gave you that impression?

Lack of answers on direct questions from me and Jeff.
You have nothing to support your words.
Seriously, where are you going with it Sergiy? We have said what we're going to say and we disagree. Have a good evening, I'll see you around

And this, yes.
Having nothing to support your point you choose to just quit the conversation.
Very professional.
Good luck!

Let it go Sergiy! You entered this thread late and it's clear you have not bothered to read all the previous posts in this thread...or maybe you have since earlier you said you "can clearly see the point" but now you're just try to rattle my cage. Either way, you're starting to bore me. If you see the point but do not agree, fine, that's your right. Either way, there is not much more to say, agree or disagree, I made my point, you see it, I disagree with you and you disagree with me, so that's it


__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Post #1435237
Posted Monday, March 25, 2013 9:09 PM
SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Sunday, July 20, 2014 5:23 PM
Points: 4,576, Visits: 8,341
Still no answer on professional questions.
No support for the point you made.

Pretty typical...
Post #1435242
Posted Monday, March 25, 2013 9:11 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Monday, July 21, 2014 4:52 PM
Points: 7,079, Visits: 12,569
*yawn*

__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Post #1435243
Posted Monday, March 25, 2013 11:15 PM
SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Sunday, July 20, 2014 5:23 PM
Points: 4,576, Visits: 8,341
OK, for everyone who have read to this point searching for a professional advice, the bottom line is:

Disabling xp_cmdshell is a stupid idea.
It only creates obstackles for developing solutions and adds a false impression of better security.

In fact it does not add any protection.
Users which are not in systemadmin role cannot execute xp_cmdshell anyway.
Users in sysadmin role who can execute xp_cmdshell can also enable it at any time by running following code:
sp_configure 'xp_cmdshell', 1
GO
RECONFIGURE WITH OVERRIDE
GO

sp_configure can be executed by any user who can execute xp_cmdshell.

If you want to prevent SQL Server users with SA privileges from accessing server/network resourses they are not supposed to access you need to make sure that Windows User Account which starts SQL Server has only those privileges within Windows domain which are required for performing productive tasks and no more.

That is it.
Case closed.
Post #1435259
Posted Tuesday, March 26, 2013 4:11 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Monday, July 21, 2014 4:52 PM
Points: 7,079, Visits: 12,569
Not only are you crass in your delivery but your advice is irresponsible and dangerous. Please keep the mischaracterizations to yourself. You're doing a disservice to the community and are putting data at risk by endorsing a tool that allows for the possibility of not only permission elevation, but also obfuscation that could impact auditing and detection of a wrongdoing. Inform people correctly so they can make up their own mind and stop polluting the well of information with your incorrect portrayal of what enabling xp_cmdshell means.

__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Post #1435364
Posted Tuesday, March 26, 2013 6:05 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 11:19 PM
Points: 36,724, Visits: 31,173
opc.three (3/26/2013)
Not only are you crass in your delivery but your advice is irresponsible and dangerous. Please keep the mischaracterizations to yourself. You're doing a disservice to the community and are putting data at risk by endorsing a tool that allows for the possibility of not only permission elevation, but also obfuscation that could impact auditing and detection of a wrongdoing. Inform people correctly so they can make up their own mind and stop polluting the well of information with your incorrect portrayal of what enabling xp_cmdshell means.


Not so oddly, I find that it's not much different than what you've been endorsing, Orlando.

For example... this is pretty rude and arrogant.

opc.three (3/25/2013)
*yawn*


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1435417
Posted Tuesday, March 26, 2013 6:21 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 11:19 PM
Points: 36,724, Visits: 31,173
opc.three (3/25/2013)
Jeff Moden (3/25/2013)
opc.three (3/24/2013)
You're still hung up on 'external attackers.' The point is, xp_cmdshell is a blunt tool that cannot be audited and allows people to run commands as someone else, possibly with more permissions than their own, without the possibility of being detected or tracked. That is not something to be taken lightly and is certainly something most people making decisions about the security of their environment and data would object too if it was fully explained.


You need to read the question I posed again. I said nothing about 'external attackers'. In fact, I specifically stated that "None of those 'individuals' are actually externally outside SQL server". Here's my post, again.

Fine. Support your words as I have supported mine. If only few (let's say, 2 DBAs) very trusted individuals have "SA" privs and none of those "individuals" are actually externally outside SQL Server) facing apps (an important point that you've left out that I've emphasized time and again), what kind of problems is having xp_CmdShell turned on going to cause and what kind of problems will be avoided by having it turned off?



So tell us all, "what kind of problems is having xp_CmdShell turned on going to cause and what kind of problems will be avoided by having it turned off"? If the answer is only "logging", please drive through because an "SA" can do just about anything without it being logged and where it is logged, (s)he can actually delete.

Maybe so, but all of that leaves an audit trail, and holes in the audit trail are an audit trail of their own, and can be grounds for termination. I do not need to make my point any clearer. Like I said to Sergiy, if you want to be in denial about the risks and exposure that leaving xp_cmdshell enabled creates that's your prerogative. But peddling it on these forums as if it is "as safe as a SELECT statement" is simply irresponsible, and I won't let it stand if I run into it.


Ok. I'll be more specific and simplify my question. You are the DBA for a company. Being a good DBA, you've given no one and no thing "SA" privs except yourself and maintenance tasks in the form of jobs running on SQL Server. You've ensured that the "SA" login password is very long and you don't use it in your daily duties. You only login as yourself.

xp_CmdShell is turned on because you have stored procedures that have been enabled to use it for your maintenance tasks.

Whether it be an internal or external user, name all of the users that can use xp_CmdShell.

Now explain how having xp_CmdShell turned on causes a security hole.

It doesn't.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1435426
Posted Tuesday, March 26, 2013 6:56 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: 2 days ago @ 8:20 PM
Points: 909, Visits: 2,842
Wow. I started a war.

Do all of you realize that you are saying the same things, but in different contexts?
Security is not something simple, and to do it correctly requires a lot of work and preparation. There are different steps required to secure SQL from internal attacks as opposed to external attacks.

Specifically to xp_cmdshell, I say disable it. The analogy is that locking a door keeps honest people honest. That being said, it's not the only thing that needs to be done to secure your system.

I also said in my original post that T-SQL and batch files are different beasts. By disabling xp_cmdshell, people (developrs!!!) are less inclined to come up with really great ideas.

No, this is not a complete solution. But it at least makes internal people stop and think.

And if DBA's are misled into thinking that disabling this completly secures their systems, then they need a lot more education.



Michael L John
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
Post #1435450
Posted Tuesday, March 26, 2013 7:51 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 11:19 PM
Points: 36,724, Visits: 31,173
Michael L John (3/26/2013)
Wow. I started a war.

Do all of you realize that you are saying the same things, but in different contexts?
Security is not something simple, and to do it correctly requires a lot of work and preparation. There are different steps required to secure SQL from internal attacks as opposed to external attacks.

Specifically to xp_cmdshell, I say disable it. The analogy is that locking a door keeps honest people honest. That being said, it's not the only thing that needs to be done to secure your system.

I also said in my original post that T-SQL and batch files are different beasts. By disabling xp_cmdshell, people (developrs!!!) are less inclined to come up with really great ideas.

No, this is not a complete solution. But it at least makes internal people stop and think.

And if DBA's are misled into thinking that disabling this completly secures their systems, then they need a lot more education.



That's the whole thing. Disabling it does nothing for security even if security is bad. A lot of people who say "disable it" just aren't understanding that.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1435488
« Prev Topic | Next Topic »

Add to briefcase «««45678»»»

Permissions Expand / Collapse