We are building a cloud-based application that relies on a login database as well as many individual client databases. Using rackspace we have setup a server (windows server 2012) with SQL Management Studio 2012 (Web) and are in the testing/QA procedures before launch.
Using the servers event viewer to look for some debug information, I noticed that a few IP's have been attempting to make a connection with our SQL database every minute or so. We are using the default 'sa' user as the super user.
My questions are:
-
Can we set a maximum number of requests for any individual IP before a 'ban' is placed on it somehow?
-
Will changing the user account name to something rather random be helpful?
-
Are there any other steps we can take to protect our database?
Best Answer
As others have mentioned your security structure is quite wrong... That being said here are some best practices to look at.... also see link to full article below. I would suggest rethinking your structure and security approach from the ground up.
http://www.serverwatch.com/tutorials/article.php/3554051/Lock-Down-IIS-and-SQL-Server.htm
Basic SQL Server Security Checklist
Set a password on your SA account and restrict its use. Also, change the password periodically to keep it from 'propagating' and being used by developers or too many administrators. Change the SA password if anyone who knows it leaves the company. Use eEye's tool to scan your network for SQL servers with no SA password.
Place your SQL Server behind a firewall, separate from your IIS or Web servers. Only allow connections to the SQL server from those designated web servers. Your SQL server should never be Internet-facing or publicly accessible.
Remove BUILTIN/Administrators from the sysadmin role and give sysadmin rights in SQL to specific domain accounts that need it.
Use Windows Authentication and Windows Only Mode if possible. This way, a potential hacker must authenticate to the domain first instead of just to SQL Server.
Do not run SQL Server on a Domain Controller.
Change the SQL Server service startup account to something besides LocalHost.
Enable the Failed Login option (Server Properties | Security tab) so you can look for failed logins to see if an unauthorized person is trying to access the server. Monitor the SQL logs and set up alerts in SQL using NETSEND or email, if possible.
Keep up to date on patches and service packs for the operating system and SQL. See Tools for Securing IIS for some options.
Protect any Extended Stored Procedures. Control all data access through stored procedures and grant access to those instead of giving blanket db_datareader and db_datawriter permissions to the data itself. See Part I of this article for more information.
Change the standard SQL Server port under the Server Network Configuration Utility and block the default port of 1433. Have your network administrator allow the new port instead.
Make sure the Everyone group doesn't have write access to SQL Server registry keys