9

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

1
  • 1
    Hey. Mark it as answered so we can move on with our lives. :)
    – JohnThePro
    Jan 7, 2011 at 19:01

9 Answers 9

29

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.

2
  • 3
    Absolutely this. This is a classic case for using firewalls and minimising your attack surface.
    – Rob Moir
    Jan 6, 2011 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, 2012 at 5:14
5

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.

3

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.

2
  • 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, 2011 at 21:48
  • And also 1434, for the discovery service...
    – AviD
    Jan 9, 2011 at 7:08
3

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.

2

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.

2
  • 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 :)
2

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.

1

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

1
  • 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, 2012 at 2:44
0

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.

3
  • 1
    The account is already disabled, it can't get much more disabled.
    – mrdenny
    Jan 6, 2011 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. Jan 7, 2011 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, 2011 at 12:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .