This past weekend I worked on automating our SQL installs and scripting security lockdowns. During that effort I found the new policy evaluation tool in SQL 2008. This built-in tool allows you to run specific checks against your SQL 2008 installation to report on best practices. During my evaluation everything passed with a green light except “Public not granted server permissions“. Since I had no clue what that meant, a little googling come up with this blog.
After implementing both fixes described in the blog, vCenter died and was unable to connect to my SQL instance. Security is great, but not when it kills your missions critical applications. After some experimentation, I was able to find a combination of the lockdown commands that added some security yet allowed vCenter to operate.
If you read the blog I linked to above, you will see that I was able to execute all of the commands except the one denying public connections over TCP. Since vCenter uses TCP to connect to SQL, it makes sense that I might need to allow public connections over TCP. I was surprised that I was able to deny public the view role to any database and vCenter worked fine, but preventing the TCP connection was bad juju.
DENY VIEW ANY DATABASE to PUBLIC
DENY CONNECT ON ENDPOINT::[TSQL Named Pipes] to public
DENY CONNECT ON ENDPOINT::[TSQL Local Machine] to public
DENY CONNECT ON ENDPOINT::[TSQL Default VIA] to public
Unfortunately even after these lockdowns the SQL policy evaluation tool still failed me on “Public not granted server permissions.” Only when I locked down everything including TCP did I get a green check. Now how much actual security these commands provides, I have no idea. But given that vCenter still works, I figure the less attack surface area the better.
I also found this great blog with lots of SQL scripts for really putting the screws on SQL and hardening it even further. From some quick testing I did with vCenter 4.0, you can safely execute the server wide scripts with one modification: Enable the SQL Agent XPs on line 61. The database lockdown ran fine as-is on my vCenter server database.
Don’t take my word for it that these lockdowns won’t adversely affect your vCenter. So test, test, test!!!
