| Ben Love on 26 Mar 2010 17:19:18 -0700 |
|
* JP Vossen wrote on [2010-03-26 18:43:46 -0400]: > > Date: Fri, 26 Mar 2010 17:40:16 -0400 > > From: Michael Lazin <microlaser@gmail.com> > > > We have a customer who had an entire table dropped from their MS SQL > > server database, they are running a customer built ASP site with > > database backend. They are blaming us but 2nd level support believes > > it to be the result of a SQL injection attack. I have been given the > > unfortunate duty of trying to find the hack, I do security on the > > Linux servers, but there is no one else here who knows enough about > > logs who could do any better. I am working under the assumption that > > the attack will show up with in the logs as a POST, and it will be a > > 200 (successful connection). There are 295 unique IPs that have > > passed post data that are 200s. I know this from grep and wc -l. > > Anyone know enough about MS logs to give me some hints that might > > help me find the hack with grep? > I know nothing about MS SQL, but I do know that there is at least one > MS SQL DBA on this list. I won't "out" him myself, but can step forward > if he chooses. :-) Perhaps if he wants to admit it (or can pretend he > "asked a friend") he might be able to provide some clues. So, I "asked a friend" how to do this. Unfortunately, MS SQL logs are entirely Binary. If you want, you can pay lots of money for programs that will examine your SQL logs. (It's Microsoft; all utilities are 3rd party and expensive. What did you think was going to happen?) Microsoft provides an undocumented command to examine the /current/ log: DBCC LOG (<dbname>) It provides some information, except not the timestamps. And its very verbose. If this is really important for you, the first you need to do is get those transaction logs saved off in case the DBA is auto-rotating or some such. I know "my friend's" logs only stick around for about 24 hours. Of course, that assumes you HAVE transaction logs/log backups. If the database recovery model is set to simple, the transaction log contains nearly nothing once the transaction has been committed to disk. Lots of MS SQL installations have 3rd party or homegrown auditing solutions to capture just this sort of schema change somewhere. Again, you pay lots of money for this. In short, without paying for software, you're out of luck: http://social.msdn.microsoft.com/Forums/en-US/sqldisasterrecovery/thread/624e0e74-f9e9-495f-8acc-8c3e9ef1ba41 Good luck. Ben -- Ben Love http://www.kylimar.com/ Attachment:
signature.asc ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|