Attempted Brute Force Password Attacks?

[gcparris]

Hi there, I'm fairly new to the VPS world. We've got a couple of our websites and databases up and running on our Windows VPS server.

On logging in today I thought I'd check the application event log out of curiosity and I was quite surprised to see over 15,000 failed login attempts to SQL server trying with usernames such as: sa, root and admin.

I also noticed in the Security log that there were over 33,000 failed attempts to login as Administrator to the server.

I presume that these are all brute force password type attacks taking place.

I've ensured that I am not using the standard usernames any longer and my passwords are very strong.

My question is are other people seeing this on their servers, is this normal?

Are there any tips for minimising security risk on the VPS servers?

Thanks,
Gareth

[Rock]

Hi there, I'm fairly new to the VPS world. We've got a couple of our websites and databases up and running on our Windows VPS server.

On logging in today I thought I'd check the application event log out of curiosity and I was quite surprised to see over 15,000 failed login attempts to SQL server trying with usernames such as: sa, root and admin.

I also noticed in the Security log that there were over 33,000 failed attempts to login as Administrator to the server.

I presume that these are all brute force password type attacks taking place.

I've ensured that I am not using the standard usernames any longer and my passwords are very strong.

My question is are other people seeing this on their servers, is this normal?

Are there any tips for minimising security risk on the VPS servers?

Thanks,
Gareth

Hi Gareth,

I'd recommend you to contact our support staff & have the VPS secured against such attacks. They'd do all the necessary hardening of your VPS

[gcparris]

Hi Rock, so I took your advice and contacted the live support guys. They were helpful and blocked several IP addresses. Unforuntately as with the nature of these things as soon as you block them more appear on different IP addresses.

I asked support to show me how to use secpol.msc to do this myself which was fine. But its a endless and tedious process.

Is there not a better, more automated way of doing this?

How does everyone else manage this, or do people just ignore it and accept it is a fact of life?

Thanks,
Gareth

[jc8654]

One trick which really helps stop things is run things on non-standard ports. We do this for our SSH connections (granted that's for linux) but I also do it for Remote Desktop etc.

For SQL, unless you need remote access, I'd lock it down to localhost connections only. And even if you need remote access, it should be from specific servers so only allow access from those machines.

[gcparris]

One trick which really helps stop things is run things on non-standard ports. We do this for our SSH connections (granted that's for linux) but I also do it for Remote Desktop etc.

For SQL, unless you need remote access, I'd lock it down to localhost connections only. And even if you need remote access, it should be from specific servers so only allow access from those machines.

That's useful advice, thank you. I tend to occassionaly do remote administration to the SQL server from my desktop but more often than not I RDP into the box to do it. Making the connection local only would definitely help as there are multiple password attempts on the 'sa' account. To combat this I disabled the 'sa' login anyway.

Thanks again!

[jc8654]

The quick and dirty way to do that - just firewall the SQL port (I think 3389 but don't quote me on that...). The other (and more proper way) to do it is to change the setting in SQL to only allow localhost connections. I tend to do both... Lol.

[Rock]

Hi Rock, so I took your advice and contacted the live support guys. They were helpful and blocked several IP addresses. Unforuntately as with the nature of these things as soon as you block them more appear on different IP addresses.

I asked support to show me how to use secpol.msc to do this myself which was fine. But its a endless and tedious process.

Is there not a better, more automated way of doing this?

How does everyone else manage this, or do people just ignore it and accept it is a fact of life?

Thanks,
Gareth

I'd strongly recommend to switch off the remote SQL connections, this can be done easily from the SQL configuration editor. Or if you intend to connect to the SQL server remotely & have a static IP on you local side, tie up the local IP & the server's SQL port, such that only your IP would be able to access SQL remotely & all others would be denied permission to connect to it

One trick which really helps stop things is run things on non-standard ports. We do this for our SSH connections (granted that's for linux) but I also do it for Remote Desktop etc.

For SQL, unless you need remote access, I'd lock it down to localhost connections only. And even if you need remote access, it should be from specific servers so only allow access from those machines.

Exactly, I second that..

That's useful advice, thank you. I tend to occassionaly do remote administration to the SQL server from my desktop but more often than not I RDP into the box to do it. Making the connection local only would definitely help as there are multiple password attempts on the 'sa' account. To combat this I disabled the 'sa' login anyway.

Thanks again!

Disabling SA user is also a good option, but these failed logins do affect the server's performance, I've seen blocking remote connections speed up the server. No CPU or network would be wasted at all, these invalid user or password failed attempts eat up a good chunk of hardware resources..

The quick and dirty way to do that - just firewall the SQL port (I think 3389 but don't quote me on that...). The other (and more proper way) to do it is to change the setting in SQL to only allow localhost connections. I tend to do both... Lol.

SQL port = 1433 (can be changed to any other), port 3389 = RDP

Thanks again JC for your inputs...