5

I just checked the eventlog on my vps and found that someone is brute forcing both my sql server sa password and windows administrator password. (I have changed the account name from Administrator to something else but they are using the correct account name!)

Is there anything that I can do to prevent them from doing it? My OS is Windows Server 2008 R2 and SQL Server 2008 R2 Express.

Edit: It seems that the attack IP address keeps changing. So blocking them would take a lot effort.

JYelton
  • 226
  • 4
  • 16
StarCub
  • 237
  • 2
  • 4
  • 8

6 Answers6

17

Unfortunately for any server exposed to the public internet, this is pretty much a fact of life. There will always be some moron trying to hack in. My private server sees several thousand invalid login attempts every day.

You could put a firewall in front, and do port forwarding from an obscure port to the RDP port. This isn't going to protect anything, but at least some of the traffic will go away.

You could report the most frequent IP addresses in the log to the relevant service provider (use whois to find out the service provider for a given IP address. The whois response will also give you an email address for abuse and spam). I have had some success with this in the past.

On a linux machine I always recommend a package called fail2ban, which monitors the ssh logs and then creates temporary firewall rules to block any ssh traffic from these addresses. That usually stops the attacks dead in their tracks. I am not aware of any equivalent packages for a Windows Server, sorry.

wolfgangsz
  • 8,767
  • 3
  • 29
  • 34
  • [Possibly related question](http://serverfault.com/questions/43360/cygwin-sshd-autoblock-failed-logins/43900#43900) – kojiro Jun 21 '11 at 22:35
10

Practically, make it longer (eg 30 character pass phrase) and change it regularly.

Why is your SQL Server exposed to the internet too?

gbn
  • 6,009
  • 1
  • 17
  • 21
6

The solution to brute force attacks (outside of preventing access addressed in other answers) is to make it less likely they'll succeed.

  • Complex passwords (no common words, special characters, mix of upper/lower case, toss some numbers in ... at LEAST 8 characters long ... mine are 15 or more.)
  • A timer on login attempts. An automatic attack can't spam login attempts if you only allow one every 15 seconds or 3 attempts/minute or however you're able to limit it.
  • A lockout policy ... 3 failed attempts and it locks out for a set time i.e. a half hour. This can be troublesome if it's an admin account, naturally.
Daniel B.
  • 725
  • 7
  • 16
  • 3 failed attempts is way too low a number, as you could easily fail three times if you fat-finger it once or twice and (e.g.) you forget that you just changed the password yesterday. If you're in an emergency situation where you ***need*** to access the server to solve a production problem, you'll be cursing the person who set the number at 3. 10 attempts before lockout is much safer, and isn't really appreciably different in the security it offers against automated brute force attacks. – iconoclast Sep 06 '13 at 13:39
  • I say three because it's standard on networks I've run, I have no data to suggest that 10 would be any worse, but it could certainly make administrative overhead less, especially since password requirements are getting progressively more aggressive (and easily forgotten) pretty much everywhere. Related: https://xkcd.com/936/ – Daniel B. Sep 06 '13 at 22:55
1

I am typically just blocking IPs. For distributed attacks, temporary blocks of IP segments depending on the geographic origin.

ocsid80
  • 159
  • 1
  • 1
  • Fair bit of warning to the OP: Blocking by IP segment will make your service completely inaccessible by other people in that range. IP segment blocking is more of a shotgun approach than anything else. – TheLQ Jun 25 '11 at 02:14
0

There is quite recent utility in these insecure times which is primarily acting as fail2ban for Windows RDP: https://github.com/devnulli/EvlWatcher

But it has a flexible xml config, and I think if attacks are logged in the event log, then you most probably will be able to make config for this also!

If you do, please share config here as additional answer or comment.

Arunas Bartisius
  • 669
  • 1
  • 6
  • 13
0

Why are you making your database server accessible to just ANYONE in the first place? Instead of trying to block selectively, you should permit selectively. In your firewall rules, whitelist your LAN (obviously), any IP ranges owned by the company (for other locations, for instance), and the IP address block used by your home ISP (if, for instance, you sometimes need to do maintenance or emergency troubleshooting from home; if not, then ignore the next paragraph).

If you feel whitelisting your whole ISP seems a little too permissive, then lobby your company to pay for business-class service at your home with a static IP address, OR just take your chances that your DHCP-assigned IP address won't change very often and whitelist your current IP address. (And then check periodically to see if it has changed, and update your whitelist accordingly.) Obviously the solution with the static IP address is safest and most reliable. (If you explain to management the frequency of the attacks, and the risk involved, they might realize that $50/month is much cheaper

This precaution can be used along with other measures, such as:

  • using an obscure port
  • using fail2ban or syspeace
  • a long and complex password
  • a delay between login attempts
iconoclast
  • 1,688
  • 2
  • 18
  • 30