Results 1 to 10 of 10
  1. #1
    Join Date
    Aug 2011
    Posts
    3

    Unanswered: SQL Server Attack - Login failed for user "SA"...

    I have two servers being attacked with many thousands of attempts every day. The message: Login failed for used 'sa' goes on and on...
    I would like to remove all database access rights to the user sa and change the password for something very easy so the hacker program can successfully have access and after nothing is found worth steeling, hopefully will leave me alone...is that a good plan?


  2. #2
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,800
    Provided Answers: 11
    Probably not.

    Unless this is SQL 2000, you should also be getting the IP address of the machine that is doing the attack. If the machine is inside your network, go to the cube of the offender with a large mallet. Disable their machine (or user) with the mallet, and the login failures will then go away.

    If the machine is not within your firewall, you should be able to add a rule to drop traffic from the outside accessing the SQL Server.

  3. #3
    Join Date
    Aug 2011
    Posts
    3

    SQL Server Attack - Login failed for user "SA"...

    I love the "mallet" idea. This is a SQL Server 2003 and you’re right I am getting the source IPs which are all in good old China, so the “mallet” won’t work. I have, in one of the locations, added the offending IPs to the firewall (today actually) and am waiting to see if it works. In the other location the router’s firewall is not good and won’t give me the option of blocking IPs, so I was thinking about the mentioned option…

  4. #4
    Join Date
    Mar 2007
    Location
    Holmestrand, Norway
    Posts
    332
    I'ld say you don't have a SQL Server issue, the real issue here (as MCrowley stated), is that you seems to allow external traffic to your SQL Server. You should treat the root cause, not the symptoms.
    Ole Kristian Velstadbråten Bangås - Virinco - MSSQL.no - Facebook - Twitter

  5. #5
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Explain exactly why you allow any SQL Server traffic through your firewall. This is a HUGE security violation.

    As a last resort, consider putting a decent router directly in front of your SQL Server, and doing the filtering there. This is uglier than sin and will infuriate your networking people. It should serve as a stopgap and will almost certainly get your networking people actively involved in fixing the problem with their router/firewall!

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  6. #6
    Join Date
    Aug 2011
    Posts
    3
    Uuuhh, but I am not sure how my application can access the SQL server otherwise, I have many outside clients accessing the SQL data from everywhere in the US and some abroad…

    Thanks for your reply….and don’t go anywhere 

  7. #7
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,800
    Provided Answers: 11
    It is hardly a best practice, but to remediate the situation, you can disable the SQL Browser service, set the SQL Server to only listen on TCP (and shared memory, of course), and set the port that SQL Server listens on to a non-default port. You will have to have all of your clients add aliases to their machines, so they can connect to the SQL Server on the new port, but that will be part of the price of data (and server*) security.

    Now for the downside of this approach. This is generally called "security by obscurity", and will be defeated by a simple port scan.

    At a minimum to prevent actual compromise of the box, I would immediately disable the SA login. No application should be connecting with that login, anyway. You can set up another administrator account for your own use, if necessary. If you have the luxury of a domain, your windows account should be in the sysadmin server role of SQL Server.

    * Who ever said the attacker was after the data? Some folks just want more spam-bots, and proxy servers.

  8. #8
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Long term, you need a better fix than this, but in my opinion this is a RIGHT NOW kind of problem. I would STRONGLY recommend that you firewall off the SQL Server with a small whitelist of known good TCP/IP addresses. Refuse any connection at all from any unknown TCP/IP address. I would make this a top priority, as in "don't go home until this is done" kind of priority.

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  9. #9
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    Quote Originally Posted by Fleury View Post
    I have two servers being attacked with many thousands of attempts every day. The message: Login failed for used 'sa' goes on and on...
    Oops. That was me. Sorry, thought you were someone else. My bad.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  10. #10
    Join Date
    Sep 2013
    Posts
    1
    There are two authentication modes used in SQL Server: the Windows Authentication and mixed mode (enables both Windows Authentication and SQL Server Authentication)

    The first mode is a way less vulnerable to the brute-force attacks as the attacker is likely to run into a login lockout (the Account Lockout Policy feature) after a finite number of attack attempts. Every production environment, if using the Windows Authentication mode, should utilize the lockout policy feature, as it practically excludes the brute-force attack success

    When it comes to SQL Server authentication brute-force attack vulnerability, the situation is not so bright. In fact, the SQL Server Authentication has no features that allow detecting when the system is under a brute-force attack. Moreover, SQL Server is very responsive when it comes to validating SQL Server authentication credentials. It can easily handle repeated, aggressive, brute-force login attempts without negative overall performance that might indicate such attacks. This means that the SQL Server Authentication is a perfect target for password cracking via brute-force

    In order to protect your SQL Server from a brute-force attack, you should consider the following:
    • Don’t use the SQL Server Authentication mode - force the attacker to hit the login lockout via the Windows Authentication
    • In case you need to use the SQL Server Authentication mode, disable or remove the SA login – that way a number of potential brute-force attack attempts will increase exponentially, because the attacker must guess and pair both the user name and password

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •