SQL 2005 Log File Question - Brute force attack using sa

  • We have recently gone through migrating all our website databases up to SQL Server 2005 along with our hosting provider relocating their datacentre twice in the past 6 months (no interuption to service).

    Everything appears to be working fine and the databases also appear to be 100% secure, however recently we have noticed a massive amount of login attempts using the 'sa' account in the SQL Server Log File.

    I have a feeling they are attempting script logins using the SQL Server Port which means our service provider has failed to update our Firewall for IP restrictions? I'm guessing they missed something during the moving of the datacentre?

    Can anyone shed any light on these Brute Force attempts and how to Secure the server, ports, etc...?

    Is it simply a firewall update to block all IP's?

  • I'd suggest disabling the sa account

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Of course that is a very simple solution, however we need to keep it active for regular updates using 'sa' login.

    Plus we want to restict access entirely for any attempts except for our own the server on any login, not just 'sa'.

    Anyone else?

  • bkirk (11/19/2008)


    Of course that is a very simple solution, however we need to keep it active for regular updates using 'sa' login.

    Yes, it's simple but very effective and should be implemented. There are numerous discussions on this very subject spread across the SSC forums. Could you not use another account with sa equivalence to perform the updates? Why does it have to be the sa account? Do you actually need sa permissions to perform the updates?

    bkirk (11/19/2008)


    Is it simply a firewall update to block all IP's?

    You could as long your sure it won't 'break' anything else!

    1) Change the default port SQL Server's listening on from 1433

    2) Use Windows authentication

    3) Remove builtin\administrators group

    4) Ensure xp_cmdshell is disabled

    There are many more security features you could implement, a simple google search will enlighten you.

    Mark

  • bkirk (11/19/2008)


    Of course that is a very simple solution, however we need to keep it active for regular updates using 'sa' login.

    Why? Quite frankly, as far as I'm concerned, no one should be using the sa account. Set up another login (windows authent preferably), use that for sysadmin work, and disable sa.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Mark (11/20/2008)


    3) Remove builtin\administrators group

    Just make sure there's another sysadmin account before doing that.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Thanks to both of you. Thats exaclty the type of advice i was looking for.

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

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