October 29, 2003 at 1:16 am
http://www.sqlsecurity.com/DesktopDefault.aspx?tabindex=4&tabid=12
Anyone tried http://www.sqlsecurity.com/DesktopDefault.aspx?tabindex=7&tabid=8 ??
Frank
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url]
October 29, 2003 at 4:36 am
It's not bad, nothing fancy. Wont hurt to try it.
Andy
October 29, 2003 at 7:44 am
I talked to my network security person here (lots of experience). He says that the attack isn't a Brute Force Attack. In a BFA, the attacker downloads the file that has the logins and passwords (SAM) and runs the BFA at their leisure. You also won't normally see logins being tried like you have, a BFA is usually against one specific login.
He believes you are getting hit by a dictionary type attack. Someone KNOWS you have SQL Server and is trying different 'normal' system admin logins and running a dictionary type attack against each of them.
Definitely get your security involved with this if you haven't already. Run a Profiler/trace to capture the Network/HOST/Computer information from the attempted logins.
-SQLBill
October 29, 2003 at 7:53 am
I think there's a confusion on nomenclature on his part because he may not be familiar with SQL Server's login security mechanisms (or relative lack thereof).
Dictionary Attack: Trying a defined list in the attempt to get a "hit" on a password. For instance, my list could be:
password
Password
PASSWORD
drowssap
etc.
Or it could be an actual dictionary, hence the name.
A brute force attack tries every possible combination of passwords. In other words, i start with a single character, go through all the options, go to two characters, go through all the options, etc.
Now with that said, a brute force attack typically doesn't work on a Windows system if account lockouts are set up. Reason being after X failed logins, the account locks. So in order to brute force Windows, you basically grab the SAM and then run a tool like lophtcrack or the like. Actually, dictionary attacks against a Windows OS tends to fail for the same reasons - account lockouts.
With SQL Server, however, there is no account lockout. That means you can continue to try and make a connection and try as many username/password combos as you want. The account won't get locked out.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
K. Brian Kelley
@kbriankelley
October 29, 2003 at 2:10 pm
I agree that it doesn't seem like a brute force type of attack. I'd think that in a brute force method, I'd see thousands of attempts per occurrence. I'm seeing less than 100.
Does profiler capture IP address info for the user?
October 29, 2003 at 6:28 pm
If you are seeing that few, you're probably right... what is likely is someone has coded a quick script with a few common passwords in order to try and see if they can get in... you'd be surprised at how many blank passwords or systems secured with "password" you'd still find.
As for Profiler and IPs, no. It's one of the limitations that proves most frustrating from a security perspective. A network trace would work. It's pretty easy to spot the attempt even with a sniffer that's not familiar with TDS.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
K. Brian Kelley
@kbriankelley
October 30, 2003 at 8:02 am
Have you gotten your network/computer SECURITY personnel involved????
If not, you should have done this already and need to do so now!!
Reasons: 1. The network has a hacker trying to get access. The Security person DEFINITELY needs to know this. If someone is doing this to your database server, what are they trying elsewhere on the network?
2. It could well be your security person checking vulnerabilities OR testing your ability to spot possible attacks. Where I work we have 'RED-TEAM' and Vulnerability Assessment teams that do this type of thing. And it you catch it and DON'T report it in a timely manner you get written up.
-SQLBill
October 31, 2003 at 12:16 pm
SQLBill makes a good point even if the attacks have "stopped." We do penetration testing on our internal systems but we tend to alert ahead of time. I'm sure we'll be asked soon to do so without the advanced notice. In any case, if you suspect an incident, it's always best to report. Most turn out to be false positives, but you can be liable for the ones that aren't you knew about and failed to report.
K. Brian Kelley
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
K. Brian Kelley
@kbriankelley
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply