March 15, 2005 at 10:48 am
Hey All,
Up until recently this was my method for handling password guess attacks.
1. Set up a SQL Server Agent alert to watch for failed logins using any of the following accounts: sa, root, admin, administrator. This alert sends me an email whenever it encounters this event - max one per 1/2 hour.
2. When I get this email, I then log into the server that sent the notice and run ethereal to gather a packet trace. From the packet trace I determine which IP is sourcing the attack and block that IP on our Firewall.
Notes:
These steps are repeated for each IP participating in the attack. 99% are broadcast to all IPs on our network so an attack on one server is actually an attack on all servers.
While this method has flaws - most notably a reliance on my intervention to block the offending IP(s) it has worked well up until yesterday. As of yesterday, my ethereal scans now yield no positive matches for the incoming attack. I can no longer find the failed password attempts anywhere.
So, my question is this. How are you guys handling attacks such as these?
What method do you use to identify and block bad IPs? How is it possible to hide the packet details from ethereal?
Note - server is using the default port. Public access is a business requirement. Windows 2000 / SQL 2000 - Latest patches, etc. etc.
Sincerely,
Dan B
March 15, 2005 at 12:39 pm
>>Public access is a business requirement<<
There is something that you are missing on that statement. Public access is to the DATA not to the Server
1. You should Firewall your server.
2. Allow traffic only from the App Server which at the same time should be Firewalled to the internet
I have no clue what is your set up but that's the scenario most people use!
* Noel
March 15, 2005 at 2:01 pm
Agree with Ten. I don't think there are too many people in your position.
If you don't mind my asking, why would the entire general public need access to your SQL server?
March 15, 2005 at 3:15 pm
I can understand the sentiment.
I have several dozen SQL servers hosting a few thousand databases. Each of the N databases has X users who connect from Y locations. Connections come in from remote Enterprise Manager and remote applications as well as from local applications.
So, at a minimum this would be thousands of firewall rules (N*X*Y) that would likely require daily updates. Aside from the additional administrative effort, this would cause great strain on our core firewalls. Even if I were to implement such a strategy, I would spend the rest of my life looking over my shoulder for our network admins who would most certainly be looking for me!
Therefore I secure the servers as best I can, block any unnecessary ports, defend against attacks as they come in and cross my fingers.
Note that some of the servers run on non-standard ports, but that only protects against generic, automated attacks. Anyone running nmap could discover the new port and change their attacks to match.
Sincerely,
Dan B.
March 15, 2005 at 3:32 pm
Seems to me that remote applications, EM, etc. would be from trusted networks (or should be). Are you saying that unknown locations 'Y' connect to your server? If not, creating simple IP access lists would be preferable than trying to block every attacker after the attack occurrs.
EX. permit tcp host X.X.X.X host X.X.X.X eq XXXX
Non-automated hacking won't wait for you to block the IP.
Otherwise, you need to password protect your firewall and force connections to authenticate at the firewall.
March 15, 2005 at 3:54 pm
Yes. Unknown locations Y.
Access lists are not currently an option.
March 15, 2005 at 3:59 pm
What about password protecting the firewall?
March 15, 2005 at 4:33 pm
That's not an option either.
March 16, 2005 at 6:57 am
Hello Dan,
You may try to run the SQL Profiler to monitor "Login Audit Failure" events. http://qa.sqlservercentral.com/columnists/bkelley/auditingwithsqlprofiler.asp
I am not sure whether it will display proper IP or Host Name for your failures.
Regards,
Andrey
Andrey
March 16, 2005 at 6:58 am
Put an IPS or an in-line IDS in place. Snort can do this sort of thing especially with some of the add-ons that allow Perl type regular expression matching. You can then set thresholds on the number of repeats of a pattern match and since the IPS or IDS is in-line, it simply sends back a TCP reset, severing the connection anytime it gets more attempts from an IP address that goes over the threshold.
As far as why you're not seeing them through ethereal, what has changed on the server? Are you seeing any traffic at all?
K. Brian Kelley
@kbriankelley
March 16, 2005 at 8:34 am
We are working on an IDS, but it is not in production yet.
In the meantime, I am learning a valuable lesson about assumptions. I am accustomed to the fact that profiler will not return source IP information, so I generally discount its use for this purpose. For remote connections there is generally not any data returned in HostName either. And, of course, I am used to these attacks coming from outside our network.
Out of desperation, I added hostname back to profiler while I watched the failed login attempts. Lo and behold, for all of the failed logins in question, the HostName column was returned. This led me to think this was a local machine, but I couldn't resolve the name to an IP so I asked around and found this machine was a relatively new addition to a new domain in our datacenter.
Anyway, this machine is well compromised and indeed running the password guess attacks against all of my sql machines. This server will most certainly require replacement.
Regarding ethereal: Now that I had the source IP I was able to locate the new packet signature. The data was there all along, but I had filtered out internal traffic and instead of looking for a generic PSH/ACK packet I should have been looking for tds.type == 0x10, or "TDS7/8 Login Packet".
Live and learn...
Thanks for all the help!
Sincerely,
Dan B
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply