4

In the past month I've noticed in my event viewer on a sql server a lot of failure audits. Seems like a brute force attack from an ip in china trying to log in to the sa account which i have disabled. I've blocked it on my network firewall but then a week later i'm getting the same attack from another ip also based in china. So far i've blocked 6 ips. Is there anything i can do to prevent this attack of do i just keep blocking ips?

This server does need to be facing the internet because i have outside developers accessing it. I will look into the firewall settings. I am using a cisco asa.

Mark Henderson
  • 68,823
  • 31
  • 180
  • 259
  • 2
    Agree with @Chris, best practice is to not have your SQL server publicly accessible. – Dustin Laine Oct 21 '10 at 20:05
  • What @Dustin says. The SQL server should not be publicly accessible, or block any connection from any IP except for authorized ones – Pekka Oct 21 '10 at 20:07
  • Hmmm... It wouldn't be too hard to modify my Windows SSHd block tool (http://opensource.wellbury.com/projects/windows_sshd_block/) to parse these events, assuming they've got the source IP address in them, and block the IP addresses locally after reaching a failed logon threshold. – Evan Anderson Oct 21 '10 at 21:26
  • 1
    @Romeo - if you associate your account here with your SO account, you'll gain ownership of the question. – Kara Marfia Oct 21 '10 at 23:19

9 Answers9

14

Unless you have good reason, don't put your SQL server on the edge of your network.

I see that you think you need SQL on the internet because developers need access. That isn't a good reason to make SQL available to the internet. You have a number of options for allowing your developers to access the server without making SQL server accessible. They could SSH to the server and run SQL commands via command line. They could use a VPN to connect to the server, and run any app. You could even lock down at the firewall to only allow access from your developers. Many options that are more secure are available to you.

Just for the record, my favourite would be SSH access using keys for authentication. That allows you more security options, and your developers can use SSH to tunnel to the server if necessary, with command line access when it isn't. You can secure the server against the developers using chroot, jail or just plain old permissions

dunxd
  • 9,632
  • 22
  • 81
  • 118
4

The answer is don't expose your SQL server to the Internet directly.

The other answer along these lines, which I upvoted said "Unless you have to" but I disagree with that part of that answer: If you think that you do have to put the SQL server on the web directly, then re-design your app until you no longer have to do so. As an absolute bare minimum, if say you only have one server and it runs everything, then firewall off the box concerned and don't expose the SQL server ports (or anything else you don't absolutely need) to the outside world.

This isn't just a SQL server thing, or a Microsoft thing, or a web application thing, it's basic security common sense; one of the first things you do to secure a system is minimise the "attack surface" that hackers can 'see'.

Rob Moir
  • 31,884
  • 6
  • 58
  • 89
2

You should not have something like SQL server directly accessible to the public network. If external users need access then still block the SQL server from the public network but give the developers access via some sort of VPN setup (for instance an OpenVPN setup or tunneling in via SSH) - that way you won't get bruit-force connection attempts from malicious people/code and you get the added advantage that all communication between them and your server are encrypted (and, with the right SSH or VPN options, compressed which could make a significant difference).

David Spillett
  • 22,754
  • 45
  • 67
1

It is most essential to not allow public access to the server. Keep it behind a firewall or NAT. I'm sure someone else could give you a more extensive answer but figured it was worth mentioning.

Belmin Fernandez
  • 10,799
  • 27
  • 84
  • 148
0

If you must make your SQL server visible, tell your firewall to block repeated failure attempts. I don't know what you're using, but any decent firewall package will allow you to configure something along those lines.

Paul McMillan
  • 1,219
  • 1
  • 8
  • 17
0

If you can't firewall it off, change the port from the default of 1433 to something else - most of these attempts will be automated bruteforce attempts and won't even consider trying different ports.

James L
  • 6,025
  • 1
  • 22
  • 26
0

I agree here, if the SQL box does not need to be external facing then disable it or add a secondary network interface, dual home it for sql services on back end network and limit access on front end internet facing adapter.

Nick O'Neil
  • 1,771
  • 11
  • 10
0

There are two authentication modes used in SQL Server: Windows authentication and mixed mode (enables both Windows authentication and SQL Server authentication) The first mode is less vulnerable to 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 Windows Authentication mode, should utilize the lockout policy feature, as it makes brute-force attacks impossible

When it comes to SQL Server authentication brute-force attack vulnerability, the situation is not so favorable. 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 the 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 attacks

In order to protect your SQL Server from brute-force attacks, you should consider the following:

• Don’t use SQL Server Authentication mode - force the attacker to hit the login lockout via Windows Authentication

• In case you need to use SQL Server Authentication mode, disable or remove the SA login – that way the attacker must guess and pair both the user name and password

Ivan Stankovic
  • 161
  • 2
  • 1
    Login lockout seems like a great way for an attacker to launch a denial of service attack. generally you should only allow connections to the SQL server from whitelisted IP addresses. Any other traffic on that port should be blocked. – Daniel Widrick Oct 01 '13 at 11:10
0

You can block the sql with a firewall, it does not need internet connection, it is communicating with apache witch has all the internet connection it needs, i suggest you install netlimiter, and you might want to back up your files and do a virus scan. pref with avast boot scan.

Good luck.

PS i dont recommend any build in OS firewall windows apple or linux.

user3790025
  • 1