securing Local System, password expiration, occasionally connected MSDE
Numerous articles (e.g.,
http://www.microsoft.com/sql/techinfo/administration/2000/security/securingsqlserver.asp, even one that I wrote,
http://www.dbazine.com/sql/sql-articles/cook12) state that to secure SQL Server, the SQL Server services should not run as Local System. That advice is useful only if making the change is not overly disruptive or is even allowable. My two most recent clients have absolutely rigid password expiration policies that require all account passwords to be changed at regular intervals. Realistically, that makes a compelling case for running as Local System.
Even where password expiration policies aren't a factor, some existing legacy applications (think MSDE databases for standalone applications) will break if they don't run as Local System. Making Procrustean changes in the name of security that cause applications to stop working doesn't win friends in the profit centers of a company.
How does one secure a SQL Server running in the context of Local System? One of the first things I'd do is drop xp_cmdshell (but I'm sure that some legacy application exists that requires xp_cmdshell!). After that, liberal use of DENY would be appropriate.
For SQL Server 2005, switching from Local System to Local Service would provide some protection.
I will check to see if we have a list of recommendations for running as LocalSystem.
xp_cmdshell cannot be dropped in SQL Server 2005. But it is disabled by default and cannot be used. To be used, one would have to first enable it using the Surface Area Configuration tool and then it would only be accessible to users that have the CONTROL SERVER permission. To be used by lower privileged principals, more steps would be required: setting the credentials for the proxy account and granting execute permission on xp_cmdshell to those principals.
Thanks
Laurentiu
I talked with Girish and he should get back to you on this soon.
In the meantime, I just wanted to point out that for an alternative, Local Service may not be very useful, so you probably would prefer to use Network Service instead.
As a general principle, running as a lower privileged account would limit the damage that can be done should your system be compromised.
Thanks
Laurentiu
Hey John,
I am guessing this is on SQl 2000 and not on 2005?
That is unfortunate. First recommendation would be to move to 2005 asap since there are more options there. J
Running as a domain account does have this issue, I cannot argue with that. I’d typically provide network service as an option here but in this case I wont for SQL 2000.
I’d rather have them take on the management headache involved in running as a domain account…that is more secure.
If they absolutely don’t want to have the management headache or the downtime pain then I guess they are out of options…in which case they are accepting the risk of running as local system and relying on the additional protections below
Basically take a look at the recommendations in the best practices paper here: http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sp3sec00.mspx
Some key ones repeated here are:
Always secure all SQL logins with extremely strong passwords (this is if you must use sql logins…using windows auth only is better).
Turn on SSL encryption over the wire.
I cannot recommend dropping xp_cmdshell, since we don’t officially support it…but if they are willing to take on the testing of it I don’t think it would be an issue…but caveat is that we don’t test under that configuration.
The other XPs may be an issue since they may be used by our tools…so dropping them could impact our toolset and other features.
Turn off network access if you don’t need it. Use a firewall to block UDP1434 and any other port except the ones you need. If you do that use a static port for your instance and sync up the clients to use that port….so you wont need udp 1434.
Turn off the other protocols. Register an SPN on the server to take advantage or Kerberos.
We don’t test under the following configuration and it most certainly has implications on xp_cmdshell usage…but you might want to think about removing SE_TCB privilege from the service account…but they would have to test this config themselves.
In SQL 2005, with the work on surface area reduction, I can point to how certain ‘buckets’ of XPs can be disabled, how password policies can help, how automatic SSL generation makes things better etc etc. But many of these are not available on SQL 2000.Hope this helps a bit!
Girish.
