Brute force attack on SQL Server

anything I don't mind · 11 Dec 2012 at 13:41

It looks like one of our clients that has a managed firewall with the ISP is under a brute force attack against the sql server. The application log has 1000s of login attempts for the SA login and origin ip address is in some cases Chinese.

This is some of the ips:

117.21.174.104
121.17.166.150
31.63.224.70
31.211.136.247
114.112.63.227

I have called the ISP and asked them to investigate because the sql server should not even be public facing.

There does not appear to be any active connections to external ips from any of the servers. Any ideas how best to investigate this? With it being a managed firewall, i don't have access to, I can't look on the firewall for connections etc.

anything I don't mind · 11 Dec 2012 at 14:41

Thanks, just speaking to ISP now.

anything I don't mind · 11 Dec 2012 at 15:52

I found the problem the firewall rules were all wrong. It is managed firewall but they don't manage it, if that makes sense, our company has to define the rules. Whoever defined the rules previously did a bad job.

no deny all rule could be found
ldap opened up to the internet and nat to the DC
sql opened up the internet and nat to sql.
old bes server still referenced.

*shakes head*

I will look in to disabling the sql auth.

anything I don't mind · 11 Dec 2012 at 17:52

Turns out the firewall is not "managed" per se but just a rented from the ISP and the ISP offers no insight in to the rules what so ever.

I sent over the revised rules and they said that i am not on the auth list so i can not change it and that i need to fill in a form to get the rules removed and that i can only remove rules between 9-5:30 pm.

I was never realy that keen on "managed" firewalls but this has realy made me think it is just a bad idea.

I would have thought that they would implement a basic set of firewall rules and just add the customer specific nat etc. I don't even think that it saves that much money.

anything I don't mind · 12 Dec 2012 at 12:19

You are correct, i was under the impression that it was managed to the extent that if a client requested a rule set that was not secure they would point it out. But it appears that they do not care about the ruleset. I blame my boss who has supported that site for a few years and is on the auth list. He should no better, realy poor to be honest.

I have removed the nat rule.

set policy id 41 from "Untrust" to "Trust" "Any" "externalip/32" "MS-SQL" nat dst ip 10.0.0.162 permit log

10.0.0.162 = internal sql ip.

This has resolved the problem.

I am not familar with the untrust and trust part of the rule, at the bottom of the ruleset there is ip ranges defined as trust and untrust. But looking at the rule i am wondering what relevance these have to the rule because the source address is set to any and this means any source address or the whole internet and i am not sure what relevance the trust and untrust has.

anything I don't mind · 12 Dec 2012 at 17:10

I think it is a Juniper. I thought the untrust would be external and the trust internal, but looking at how the trust and untrust was defined at the bottom of the ruleset it confused me a bit. I noticed all outgoing rules were defined with trust to untrust and all incoming were untrust to trust. Even though IP ranges in china (for example) were not explicitly defined as in being in the untrust zone, the "any" source option was allowing all traffic through any way.

anything I don't mind · 12 Dec 2012 at 17:45

Ok thanks, that makes sense.