August 17, 2014 at 10:23 am
Hi,
It may be that I should post this in the newbie section. How can I assess how many resources my sql Server Express 2012 is using to deny sa login attempts? My log is show about 4 failed attempts a second. I do not see a counter in performance monitor and my initial google search to audit failed attempts seems to require resourses sql express does not have. i.e agent.
Perhaps the better question is. How concerned should I be and how can I stop this attack?
John
SQL 2012 Standard VPS Windows 2012 Server Standard
August 17, 2014 at 10:43 am
You should be concerned, and you should not expose you SQL Server instance on the internet. As long as it is, you should keep the sa account disabled. Renaming it, is also a good idea.
But again, don't expose your instance on the internet.
[font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]
August 17, 2014 at 10:49 am
So this is where I should be bumped over to newbie. This is not a dedicated SQL server and hosts web sites as well. Can I assume there in no way to isolate the instance if it's server is also hosting web traffic?
If an SQL Server is supporting a web site but on a different physical machine, does that necessarily mean it's exposed to the internet? (note again this is not my case.)
SQL 2012 Standard VPS Windows 2012 Server Standard
August 17, 2014 at 11:05 am
If SQL Server is only serving the web server, it's simple: make sure that only ports 80 and 443 are open in the firewall. And particularly, make sure that the ports related to SQL Server are closed. That is, the port which the instance is listening to (which you find in the SQL Server error log) and UDP port 1434, used by the Browser service.
You can even take it one step further and disable TCP and named pipes altogether on the instance.
In many cases, you want to be able to access the server instance from other machines in your own network. The common solution to this is to put the web server in what is called DMZ, which is outside your corporate firewall.
Also make sure that your web application is not prone to SQL injection.
[font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]
August 17, 2014 at 1:14 pm
Erikur's advice is all good.
In addition, if the SQL Server is used only by things running on the same machine (such as Web Server) it is usually a good idea to diable all SQL Server connection protocols except shared memory.
But even doing all that including, As Erikur pointed out, making sure the web app doesn't permit sql injection, and changing the name "sa" to something else (like "jqsw3456ajfyctsmken" or something equally crazy) and, preferably, disabling Sql logins and allowing only windows logins doesn't guarantee security: you need to be sure that no-one unwelcome can get connected to the server as a Windows system administrator.
Tom
August 17, 2014 at 1:18 pm
TomThomson (8/17/2014)
Erikur's advice is all good.
Erikur?
[font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]
August 17, 2014 at 3:29 pm
Erland Sommarskog (8/17/2014)
TomThomson (8/17/2014)
Erikur's advice is all good.Erikur?
Hi Erland, I think Tom is mixing up us two from way up north, even the confusion is misspelled;-)
My (Eirikur :-D) first question is where are the attempts coming from? Is it through the web application or directly?
Follow Erland's advice on the firewall settings, you really want to isolate the SQL Server from the open internet! Secondly, disable SQL Server logins and use only Windows authentication. Last but not least, do not use NTLM authentication (backward compatible windows authentication)!!!
😎
August 18, 2014 at 12:27 pm
To be honest, I'm not totally sure all the uses of this SQL instance. I'll have to find out (that's why its call work right) I'm actually volunteering...
Anyway. Is there a way to find out what port these attacks are coming in on?
SQL 2012 Standard VPS Windows 2012 Server Standard
August 18, 2014 at 3:22 pm
They are all coming on the port on which SQL Server is listening on. You can see this in the SQL Server Configuration Manager or in the beginning of the SQL Server errorlog.
[font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]
August 18, 2014 at 4:34 pm
Erland Sommarskog (8/17/2014)
TomThomson (8/17/2014)
Erikur's advice is all good.Erikur?
:blush:
The nearest I can get to an excuse for the error is that it's hard to recognise names in far northern languages, at least as hard as understanding this bizarre beurla Sasunnach I'm typing in.
Actually, I suspect I'd just read some comments by Erikur in a different thread and the name stuck in my mind somehow.
Tom
September 18, 2014 at 12:36 am
brut fource algo use for makinjg security..
http://www.tulipvioletgurgaon.co.in/
September 18, 2014 at 4:54 am
Thanks everyone for the help on this issue. I've been off for a few weeks. In the meantime the business, on my recommendation, has secured a dedicated VPS with a new SQL 2012 standard to replace the 2012 Express instance which shared VSP with the web server.
In my mind this moves the SQL instance back away from the internet/cloud. So the situation has changed hopefully for the better. I'm going to now isolate the connections to the database to three acceptable sources
Bog Application
Web Application
Quant Users
Data Loading Processes
DBA
My question. Given that noone should connect other than these processes, how do I remove the possibility of any other connection which might try a brute force attack?
John
SQL 2012 Standard VPS Windows 2012 Server Standard
September 23, 2014 at 5:18 am
Erand, (and others)
I am not seeing in the error log what port these attack are coming in on. I'm using windows server 2012 and SQL Server 2012 Standard. To be honest, I am lost in the logs as there is so much 'noise'. It's overwhelming. Can anyone suggest a, preferably, free tool to filter the logs? I used to use DBArtisan (not free) but it had a great filter for this.
John
SQL 2012 Standard VPS Windows 2012 Server Standard
September 23, 2014 at 12:58 pm
The attacks are coming on the port on which SQL Server is listening on. Which you can see in SQL Server Configuration Manager and also in the beginning of the errorlog.
The only time there could be confusion is if you have SQL Server listening on more than one port, but that is not very common.
I don't know how your network setup is, but as I said before you should not expose SQL Server on the internet; it should only be exposed inside your network.
[font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply