Post reply

sa user login attempts

  • June 3, 2010 at 8:21 am

    #235895

    I am running SQL 2008 on a Windows 2008 server that is located behind a Sonicwall Firewall.

    In my log files I have recently found that 2 or 3 times a day there are repeated attempts to login in as the 'sa' username that are unsuccessful because of an invalid password. These attempts last anywhere from 30 mins to 2 hours. I have looked up the ip addresses of these unsuccessful attempts and they appear to be coming out of China.

    I have no experience in dealing with securing my database against such attempts so if someone could give me some advice on where to start or point me to some documentation or a web site that could tell me how to deal with this I would appreciate it very much.

    Our network setup and maintenance is outsourced to a third party company and they have told me that they don't have any experience with dealing with SQL security so I am on my own.

    Thanks for any help you can give,

    Judy

  • June 3, 2010 at 8:37 am

    #1175993

    uggg....you have a SQL server exposed directly to the internet? At our shop, we have a web server that is exposed to the internet, and it connects to a SLQ Server inside a DMZ....nothing exposed directly like that; that's probably not good.

    you can use the sonic firewall to block all traffic to your SQL server except from allowed IP addresses or ranges...the bosses IP from HOME, other IP's that should be allowed to connect, etc.

    you could set up the firewall to block everything IP not from North America as well; there's a free IP database at MaxMind, and a few articles here on SSC on determining the location based on IP address.

    you can also change the listening port for your SQL server to somethign other than the default 1433,

    which is what that script from china is doing, i'm sure.

    I'd get the SQL serever un-exposed from the internet fiorst thing...might be a simple oversight, since it's really rare for a SQL server to be directly exposed; maybe you should add a VPN somewhere so the right people can get to the server?

    Lowell

    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • June 3, 2010 at 9:11 am

    #1176021

    Lowell,

    I guess since the server the sql database is on is behind the firewall I assumed that the database wasn't exposed directly to the internet, but you know what they say about assuming things. 🙂 I guess I don't know what other precautions I need to take. We have a handful of users that access the database through our VPN but all the rest are local network connections.

    Thanks for the idea about the North American ip addresses. I will look into that right away.

    I will also see about the listening port of 1433, I will need to contact my software vendor first to make sure that changing that listening port won't adversly affect my software.

    thanks,

  • June 3, 2010 at 9:14 am

    #1176023

    Does your sql server NEED to run in mixed authentication mode? If not, change it to Windows Authentication only.

    Wayne
    Microsoft Certified Master: SQL Server 2008
    Author - SQL Server T-SQL Recipes

    If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!
    Links:
    For better assistance in answering your questions
    Performance Problems
    Common date/time routines
    Understanding and Using APPLY Part 1 & Part 2

  • June 3, 2010 at 9:32 am

    #1176036

    A firewall is a wall with holes in it. The holes are there deliberately, left to open certain things up to pass through. For example, the firewall I have for one of my sites has port 80 and another port open for RDP (not 3389). That's it. So SQL isn't directly exposed, UNLESS I were allowing SQL Server to respond on port 80 to web service requests. In that case, it's open.

  • June 3, 2010 at 1:40 pm

    #1176159

    I spoke to my software vendor and they suggested blocking port 1433 on the firewall. They said that wouldn't interfere with the software being used by the local network.

    They also suggested we restrict the use of port 3389 that is used by terminal services for remote logins.

    I'll have to talk to our network guys to see what we can do there. We have other users that login to the VPN on that port I'm pretty sure. I know when I login with Remote Desktop that's what I use.

    Thanks for everyone's help. It helped me to ask the right questions and I do understand things better now.

    I'm thinking that dealing with these two ports will resolve this particular issue. I guess if it doesn't I'll be back. 🙂

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply