I believe my server has been the ongoing target of a brute-force attack on SQL Server 2005 (SQLExpress). My Event Viewer log is filled with "Failure Audit" messages for SQL Server. The attempts usually last for an hour or two, with 1-2 seconds between attempts.
Login failed for user 'sa' [CLIENT: 222.169.224.163]
Event ID: 18456. Based on matching entries in the SQL Server log, I have found that each login fails due to a mismatched password. I have also seen attempts for other users, including 'administrator' and 'administrador'. Each session comes from a different IP address, and are from countries like Italy and China.
What countermeasures can be taken? I do not want to lock out the user account, because then my site and applications will not have access to the server. Is there a way to throttle login attempts through SQL Server 2005? E.g. geometrically increase the 'wait period' between failed login attempts?
There isn't a way to throttle logon attempts to SQL server that I'm aware of. However, I'm kind of curious how internet users are able to get that far. Aren't you behind a firewall? That is some scary access and should be remedied ASAP.
My web servers are behind a firewall and the only ports allowed access are 80 and 443.
While this is not an answer to your question, exposing the database server to Internet was never a good practice. Provide web services to access the data in a safely manner, and hide the server behind firewall.
Consider blocking incoming connections on the SQL Server port (1433) using a firewall.
A quick fix is renaming sa account and modify the connection parameters on services that depend on this Sql Server.
ALTER LOGIN sa DISABLE;
ALTER LOGIN sa WITH NAME = [sys12-21admin];
(Of course, choose another name than the one suggested.)
For more details http://blogs.msdn.com/sqltips/archive/2005/08/27/457184.aspx
By increasing the 'wait period' between failed log in attempts you could deny proper access to Sql Server.
As far as I understand the applications are using the "sa" log in to do daily tasks adn this could get the account locked. Just in case this happens use http://www.windowsecurity.com/articles/Hacking_an_SQL_Server.html
This is another security concern of course reason for which you should try to stop access as soon as possible as sugested in earlier posts.
Related
How do I set up a database so that one does not have access to it? Even with installing SQL Server Management Studio on local machine.
In SQL Server with Windows user or sa can access all databases. How do you limit the access DB of the users?
For assuming that SQL Server is installed on the local machine, not on the server
You can try Single User Mode.
From the linked MSDN article:
Single-user mode specifies that only one user at a time can access the database and is generally used for maintenance actions.
Edit: You edited your question. Now it sounds more like you're asking about Security instead of how to limit the database to one user.
You can edit a user's security in SQL Server Management Studio by drilling down into Security > Logins. There you will see all logins to your instance. You can right click these entries and select Properties to made updates. The easiest way to completely bar a user from accessing any of the databases on the server is by selecting "Disabled" from the "Status" tab.
Well, if you really want to limit this to just one user, there is a simple way (but a bit risky).
Your Windows user is included in the group BuiltinAdministrators. If you really want to remove your Windows user, rerun the installation process and during the setup just change the users in those group.
But beware, you should provide another user, which has access to your database otherwise you end up with a database server without access to it.
Ater that, setup a database login and grant him access to the database you desire.
In the end, you can disable the sa login. This will prevent access with the sa account. But you should have a user which can manage logins and more. Otherwise you have no chance to recreate the password or any other administrative tasks.
Is it possible to pass-through Windows User logins from Datazen through to SQL Server?
Scenario:
I created a Dashboard which uses a SQL Query as a data source.
The data source is of type "SQL Server" and the flag Integrated Security is set to YES.
I've also configured the data source to be "Real Time," to avoid any issues with caching.
I'm expecting the data view to execute on SQL Server with the credentials of the user which is browsing the final dashboard, unfortunately this is not the case.
Problem:
In this scenario the authentication against SQL Server is now done with the Windows user account, under which the Service "Datazen Server Data Acquisition Service" is running. I would expect that the "Acquisition Service" will delegate the effective user. Is this possible? Or will the authentication always be done with the service account?
I know about the "personalize for each member" setting, which passes-through the username to a data view query, but this is not the same as my requirement (leverage existing MSSQL-DB-Security for effective windows-users).
Your observations are correct that by default, the service account will be recognized as being logged into SQL Server.
There's no way to get around that with settings, but you can use some T-SQL magic to switch users at runtime. You have to lead your queries with an EXECUTE AS statement, like so:
EXECUTE AS USER = 'DomainName\' + '{{ username }}'
SELECT TOP 1 login_name -- This is just a nice quick test to echo the username.
FROM sys.dm_exec_sessions -- You can swap it out for your real query.
WHERE session_id = ##SPID
This, of course, also requires the "Personalize for each Member" setting to be turned on, so that the username is passed through.
It's pretty self-explanatory what's going on here, but basically you have to explicitly impersonate the request via your service account, as SQL Server will be connected to via the database using that account. Once you run this EXECUTE AS statement, it will use that user account for the remainder of the session.
Note that your service account will need permission the IMPERSONATE permission set, or else this will fail. It will also fail, of course, for any users that exist in your Datazen Server but do not have permissions against your SQL Server, and vice-versa. That's definitely the desirable behavior, but it's worth keeping in mind if you ever add users to one, you'll also have to add them to the other.
Disclaimer: I'm a Microsoft Support professional, paid to support Datazen.
I just enabled remote connections on my SQL Server Express 2012 installation. Now I am a little bit worried about the server security because allowing connections to everybody sounds like a big security hole for me.
Is it possible to tell the SQL Server to disconnect if the user is trying to authenticate with a user which is not on my "allow" list? If so, I could add my monitoring user to this list and don't have to worry that my administration accounts are accessible.
First of all, this is probably a question that should be asked in the DBA site. Anyway, you can set up the security of the server so that only certain users are allowed to login.
When you set up the server, you add Logins to the Server Level and then Users at the database level. Only the users that are setup can, obviously, use a particular database. You can place users into roles, so, for example, they will have read-only access to a database. You can control, down to the object level, who has access to what.
There is a good article on what SQL Server security is about here
Having said that, sometimes, after, you have setup your security, you need to disallow certain users to not be allowed to Logon. Perhaps you are doing some major upgrade to the database. One option in this case is to create a Logon trigger.
A Logon Trigger will fire every time a user Logs in. You could create a table of "allowed" users and, in the trigger, if they are not in the table you ROLLBACK, effectively disallowing the Logon.
Here is information about creating a Logon trigger
You should be able to set up the db server to only accept connections from certain IP addresses, rather than to all of them. I'm unsure of the T-SQL syntax, but someone will surely chime in with the correct one.
If you really mean business, that being said, you'll want to authenticate clients using certificates that you give them. See this and the various articles it links to:
https://security.stackexchange.com/questions/14589/advantages-of-client-certificates-for-client-authentication
Being able to connect remotely to a SQL Server instance does not mean that they can Login to it. If they are not authorized properly, they should still get kicked-off by the SQL Server Login Authentication sequence.
This is silent/invisible for "Trusted Logins" (where the authorization comes from their Windows Login/Domain Account), but it still happens.
If you look under the "Security" folder of your Server (in SSMS), you will see the list of authorized Logins to you SQL Server. By adding or removing these you can control who can actually create a session on your SQL Server.
The title says it pretty well: I can access my SQL Server from the internet, and my users are configured with strong passwords to access only their respective DBs.
But I receive 10000+ login attacks by day with the user "sa".
I don't need "sa" remote access, how to disable it, and only it?
Thank you!
Security practices by Microsoft and industry state if use SQL authentication to rename the sa account and disable it. There is really no reason to use that account explicity for an application or admin account. Most companies require tracability when it comes to security and use of the sa account in SQL server does not allow for that.
Even if you disable or rename it you will still see attacks coming in for that account, it comes with the territory. The same thing occurs with the default login Oracle has in their product. Script kiddies and other hacking programs are just programmed to check for those type of accounts.
A better option might be to report where the attacks are coming from on the network side to your network team or ISP. They will be able to better handle that to block that traffic through the network layer. Just my opinion.
Perhaps this might help: in conjunction with this:
As far as i know SQL Server lets you diable single sql server logins, but that means the login is disabled in general, regardless of the machine the user is trying to connect from. So you either disable "sa" in general or you'll have give the login a really strong password. You might be able to emulate the desired behavior by using a logon trigger, that checks where the user connects from, if the user is "sa", but i think that's not a viable solution for you, since you seem to be wanting to get rid of the many connection attempts from attacks. In any case, you might want to remove "sa" from the server role "sysadmin" to guard against a potentially successful login attemt.
I recently started looking into the new Policy Management in SQL Server 2008 and when I checked for compliance with the "Public Not Granted Server Permission" policy, my server failed the check. The reason was, and I am pretty sure this is the default, public has TCP Endpoint permission so that users can connect to the server. If I were to remove this, I would have to assign users individually the right to connect.
This seems silly to me. I cannot figure out why Microsoft would recommend changing this. I have no guest account, so only specified users can access the server. The server is behind a firewall, and only one subnet in the company can even access it. Does anyone have any insight on this?
Security best practices start with locking EVERYTHING down, then only opening up pieces as necessary to the people that actually need to get to it.
By allowing the "public" access to even connect, regardless of the fact that they don't have rights to do anything, opens the door just a crack. Sometimes, that's enough to exploit a buffer overflow or another type of attack.
UPDATE
A Login and a User are two different things. A login is server level, a User is database specific. Every User should have a corresponding login; but not every login will have a database user account.
Let's say you are using Active Directory integrated security; and you've assigned a particular AD group to have access to the server. Now, only some of those within the group may actually have access to certain databases. Those are the people you want to allow access to connect. Whereas the other members of the group don't have regular database user accounts.
By definition this is a problem as some of the group members can connect and list databases on the server even though they don't have access to any of those databases. That's the "crack" in the door I'm talking about.
If you can stop those people from even being able to connect then you've gone a long way towards securing your server.
There are other server level permissions that the Public role grants to logins. If possible, you should turn it off just like you would a guest account.