Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Looks like someone or something is trying a brute force attempt at logging into our production SQL Server instance with the 'sa' account. They haven't been successful because our 'sa' account is disabled, but what steps should I take to make sure things are secure?

login attempts

share|improve this question
1  
Hey. Mark it as answered so we can move on with our lives. :) –  JohnThePro Jan 7 '11 at 19:01
add comment

9 Answers

up vote 27 down vote accepted

Does your SQL server need to be publicy available to the Internet? This is usually not the case. If it absolutely has to be this way, you could restrict access by IP address or maybe set up a VPN. Obviously, make the sa password unguessable or see about restricting sa login locations from only your LAN ip addresses. Please provide more details so others can assist you with better solutions.

share|improve this answer
2  
Absolutely this. This is a classic case for using firewalls and minimising your attack surface. –  RobM Jan 6 '11 at 21:55
    
Plus it is not someone. It is pretty much a worm out there, not a human. SQL Server on internet + not changing default port = utterly ignoring reality (internet not a nice place). –  TomTom Apr 28 '12 at 5:14
add comment

The first thing you could do is start by blacklisting that IP address, and outright denying ANY traffic from their IP at your firewall. Of course, they may just change IPs, but at the least it'll stop them from bombarding your server with traffic and logs.

share|improve this answer
add comment

Disable that port (MySQL is 3306; don't recall SQL Server's port, maybe 118?) through the firewall. Then no one can access it.
If outside access to SQL is needed, remap it to a high-numbered port, like 53535. If anyone figures out that port is open, it will be hard to guess its significance.

share|improve this answer
    
1433; if it has to be open to the outside, change it to just about anything else; that will involve changing connection strings on clients however. –  SqlACID Jan 7 '11 at 21:48
    
And also 1434, for the discovery service... –  AviD Jan 9 '11 at 7:08
add comment

The login attempts to involve attempts to inject some malicious code. I recommend blocking this activity with a permanent blacklist using either the server's firewall software or a third party external firewall.

Also, reduce the number of allowed login failures as this will automatically block the intruder's IP address.

Above will minimise this.

share|improve this answer
add comment

It's probably just some script kiddie running a scanner and not worth your time pursuing. I would look at not having your database accessible from the Internet.

share|improve this answer
add comment
  • If you can, disable all SQL account access, not just sa - i.e. enable Windows Authentication only, without SQL Authentication.
  • Restrict network access - either via firewall, or at least IP restrictions on box - to those servers that require access only. Public users don't need direct access, right?
  • Take into account that he will probably try bruteforcing the local Administrator user, next. Though you can't really remove the admin's permissions, you can drop it into a specific role and explicitly block access.
  • If you can, disable the SQL Server Browser service. No reason to make it easier...
  • Perform a complete analysis of users, permissions, and passwords on the database - they'll probably try other users next.
  • Try asking this again on ITSecurity.SE for more info :)
share|improve this answer
add comment

If your SQL Server must be accessible outside of your netowrk, you can Whiteliste the outside IP addresses needing access. VPNs are a better solution, (but not always available), and best solution is no outside access.

Whitelisting requires more management, but it removes this silliness. If someone needs access and they have a frequently changing IP, then they can login to a different system via RDP and connect to the SQL Server from there.

Rename the sa account, create a bogus sa account, and disable it.

Audit permissions and trigger a password update for all SQL Server User Accounts; maybe increase password strength requirements.

Renumber the SQL Server IP listening port. This means updating client configurations or application configuration files.

I agree with other posters regarding probable next attack vectors and this is probably someone running a script.

share|improve this answer
add comment

You ought to restrict login attempts, so if the same user tries to log in more than 5 times, they are blocked from any further attempts for a few hours or a day. At least then they cannot brute force a login after a million attempts.

And like others have said, don't allow public access if it's not necessary. You can restrict access to a set of known IPs if some people need outside access.

share|improve this answer
1  
The account is already disabled, it can't get much more disabled. –  mrdenny Jan 6 '11 at 18:36
    
@mrdenny: I was thinking more about the non-disabled accounts for the first paragraph. If someone is brute forcing 'sa' they could easily start with another account. After 5 attempts on a disabled account, just block them entirely. –  DisgruntledGoat Jan 7 '11 at 11:23
    
Script kitties will usually only attack the sa account as they already know the username. Otherwise they have to brute force the username as well, which takes twice as long and they have no way of knowing if the username exists or not. –  mrdenny Jan 7 '11 at 12:21
add comment

For anyone looking for an program that will create the IPSEC policy, filters, etc and automatically scan the event log and add IP's to the block list, I've written a small program that does just that.

I had this problem too where my event log would be filled with thousands of entries for hackers attempting to login to my MSSQL instance with the 'sa' login. After much searching, I decided to write my own program, have it create the neccessary IPSEC items, and then scan the event log every 60 seconds for attacks from new IP addresses. It then adds the IP address to the IPSEC filter, and blocks all traffic to and from the IP. I have only tested this on Windows Server 2008, but believe it will work on other versions as well.

Feel free to download the program using the link below. Donations are always appreciated using the link in the right-click menu of the taskmanager icon.

http://www.cgdesign.net/programs/AutoBlockIp.zip

Please note that this only works for SQL login attempts using the 'sa' login, but I could modify it to work for other log events as well. Also, you can view the IP's that have been blocked, but you will continue to see some items in the event log since the program only runs every 60 seconds. This is due to not being able to delete a single event log entry, and I didn't think deleting the entire log would be a good idea.

DISCLAIMER - By downloading and installing the above-mentioned program, you agree to hold me harmless for any damage, loss of data, corruption, or any other functionality issues resulting from the use of said software. I have tested the program to the best of my ability and currently have it running on 2 servers, but you have been warned to use at your own risk.

Any questions or comments, please feel free to get in touch with me using the contact form on my website at www.cgdesign.net

-Chris

share|improve this answer
    
You do a good job of disclosing your affiliation with the product. Be careful, we do not generally appreciate sales sessions. –  Scott Pack Nov 30 '12 at 2:44
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.