March 25, 2013 at 8:03 pm
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.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
March 25, 2013 at 8:17 pm
When one does not want to admit of being wrong he's resotring to personal attacks.
I can clearly see the point. And I spent most of my working time in environments with badly managed security restrictions.
And I used this back door not once.
I just do not see how having xp_cmdshell will stop me from doing exactly what you are trying to prevent - reading from folders which I cannot read and SQL Server can.
The only thing I need to do to overcome your "barrier". or "layer" is to run sp_configure command+reconfigure.
As Jeff pointed it will take less than 3 ms to complete.
If you wish, I could disable it back, to prevent raising an alarm by somebody who's checking the system settings.
So, what do you achive with disabling xp_cmdshell?
Except, of course, false sense of security.
_____________
Code for TallyGenerator
March 25, 2013 at 8:19 pm
Sergiy (3/25/2013)
When one does not want to admit of being wrong he's resotring to personal attacks.
😛 You just made my point for me. I think we're done here 🙂
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
March 25, 2013 at 8:31 pm
opc.three (3/25/2013)
Sergiy (3/25/2013)
When one does not want to admit of being wrong he's resotring to personal attacks.😛 You just made my point for me. I think we're done here 🙂
So, you agree that disabling xp_cmdshell does not have any point.
Do I understand you right?
_____________
Code for TallyGenerator
March 25, 2013 at 8:34 pm
Sergiy (3/25/2013)
opc.three (3/25/2013)
Sergiy (3/25/2013)
When one does not want to admit of being wrong he's resotring to personal attacks.😛 You just made my point for me. I think we're done here 🙂
So, you agree that disabling xp_cmdshell does not have any point.
Do I understand you right?
What gave you that impression? 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 🙂
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
March 25, 2013 at 8:38 pm
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!
_____________
Code for TallyGenerator
March 25, 2013 at 8:44 pm
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!
:w00t: 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
March 25, 2013 at 9:09 pm
Still no answer on professional questions.
No support for the point you made.
Pretty typical...
_____________
Code for TallyGenerator
March 25, 2013 at 9:11 pm
*yawn*
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
March 25, 2013 at 11:15 pm
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.
_____________
Code for TallyGenerator
March 26, 2013 at 4:11 am
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
March 26, 2013 at 6:05 am
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
Change is inevitable... Change for the better is not.
March 26, 2013 at 6:21 am
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
Change is inevitable... Change for the better is not.
March 26, 2013 at 6:56 am
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
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
March 26, 2013 at 7:51 am
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
Change is inevitable... Change for the better is not.
Viewing 15 posts - 46 through 60 (of 96 total)
You must be logged in to reply to this topic. Login to reply