RASTREAR UN DROP TABLE
Ivan Rico
Tengo un problema urgente, me encontraba tranquilamente leyendo mi correo
cuando recibo un reporte de que el sistema no funciona, cuando reviso los SP
del SQL SERVER 2005, me doy cuenta que fallan al hacer consultas a una tabla
que ya no existe reviso un respaldo del día anterior y la tabla ahi esta,
por lo que alguien la ha borrado, he buscado información de como poder saber
quién y cuando hizo esto pero no he encontrado nada.
alguien sabe si hay alguna bitacora que registre moviemientos como DROP
TABLE??
agradezco su pronta respuesta pues me urge.
saludos
Rubén Garrigós
traza configurada para ello. Muy probablemente dicha operación aún se
encuentre en el log de transacciones (salvo que lo truncaras y desecharas) y
de ahi podrías recuperar dicha información aunque no de forma sencilla.
Puedes probar con alguno de estos entre otros:
Apex SQL Log, Log Explorer, SQL Log Rescue.
En todo caso y dado que imagino que lo primero es volver a tener en marcha
el sistema te recomendaría que tiraras de backup (quizás en otra máquina y
restauraras la tabla únicamente o bien restauraras toda la base de datos.
Estos problemas pueden venir por ejemplo de un ataque de SQL injection si no
teneis finas las aplicaciones, por código dinámico, etc. También por algún
usuario que tenga permisos de más. ¿Debería tener algún usuario permisos
para hacer drop de tablas aparte del administrador? Sería buena idea también
que añadieras una traza con más información para futuras incidencias
poderlas tracear más fácilmente.
Rubén Garrigós
Solid Quality Mentors
"Ivan Rico" <ir...@iplace.net> wrote in message
news:OdY$yD5mJH...@TK2MSFTNGP03.phx.gbl...
Ivan Rico
saber quien causo que la tabla desapareciera, en realidad es lo unico que me
interesa saber, puesto que los datos los tengo todos en el respaldo.
He vuelto a crear la tabla y ya tengo el sistema en línea, pero me quedo con
la duda de saber que paso.
si hay algunas otras ideas para rastrear, son bienvenidas.
saludos
---------------
Ivan Rico
"Rubén Garrigós" <rgar...@solidq.com> escribió en el mensaje
news:875BD911-4A90-4A63...@microsoft.com...
Rubén Garrigós
Bueno, los DROP TABLE no es algo que ocurra digamos... habitualmente.
Utilizando alguna herramienta de las que te comenté de análisis del log de
transacciones podrás sacar probablemente el usuario y la fecha en que se
lanzó a partir del log de transacciones. Por otra parte yo creo que no
dormiría muy tranquilo sin pasar una auditoría de seguridad al sistema. Al
menos analizar que usuarios han podido hacer el DROP, si ha sido fruto de un
ataque a partir de un website, un error humano, etc. y tomar medidas
correctivas al respecto. Esta vez ha sido un DROP TABLE pero la siguiente
puede ser un borrado de todas las bases de datos.. o incluso de todo el
servidor... o si se dan las circunstancias de inseguridad apropiadas es
sencillo ejecutar cualquier cosa, saltando incluso a otras máquinas, etc.
Muchos ataques tienen también intereses comerciales como el robo de listas
de clientes, información fiscal, tarjetas de crédito, etc.
Rubén Garrigós
Solid Quality Mentors
"Ivan Rico" <ir...@iplace.net> wrote in message
news:ebNpMi5m...@TK2MSFTNGP05.phx.gbl...
Ivan Rico
lo malo de aqui esque no tengo el control del sistema operativo solo tengo
acceso a la base de datos usando el enterprise.
"Rubén Garrigós" <rgar...@solidq.com> escribió en el mensaje
news:A2C47F62-1DBE-43BA...@microsoft.com...
Rubén Garrigós
el log mientras no hagas backups de dicho log y esté en modo de recuperación
completa. No hay una limitación de tiempo a priori. En todo caso si estás
limitado a utilizar el enterprise manager únicamente lo tienes complicado.
Rubén Garrigós
Solid Quality Mentors
"Ivan Rico" <ir...@iplace.net> wrote in message
news:%23DFIXYB...@TK2MSFTNGP02.phx.gbl...
Ivan Rico
saludos
"Rubén Garrigós" <rgar...@solidq.com> escribió en el mensaje
news:ORaYXkFn...@TK2MSFTNGP04.phx.gbl...
Rubén Garrigós
tabla. Desconozco si utilizais borrados habitualmente en esa base de datos
pero si la respuesta es no, podrías probar de sacar con TSQL del log de
transacciones las operaciones de borrado para saber el "cuando". Es decir,
si hay un único registro de tipo borrado, la hora corresponderá con el
borrado. El "quien" está más complicado pues lo que está accesible es el
SPID de la conexión que hizo el borrado, no el usuario. Puede que ese mismo
SPID se encuentre aún conectado, es decir, que sea una conexión que se
mantenga abierta. Esto lo puedes sacar sin tener acceso físico a los
ficheros ejecutando esto en la base de datos donde se produjo el borrado:
select [begin time],spid from ::fn_dblog(null,null) where [Transaction
name]='DROPOBJ'
Lo dicho, si necesitas más información realmente lo mejor será que recurras
a alguna de las herramientas específicas para leer del log como ya te
comenté.
Rubén Garrigós
Solid Quality Mentors
"Ivan Rico" <ir...@iplace.net> wrote in message
news:OLcWICGn...@TK2MSFTNGP04.phx.gbl...
Ivan Rico
alla de la historia y nunca podre saber que paso :(
en fin, lo bueno de todo esto esque no causo destrozos graves pero estare
preparado para la otra, ya que uno de los sistemas que me recmendaste puede
recuperar tablas borradas y pienso seriamente en instalarlo (en cuanto me
den el pass de adminsitrador del windows) y seguire leyendo mas info sobre
esto ya que al menos ya se por donde empezar a leer.
saludos y gracias por todo
"Rubén Garrigós" <rgar...@solidq.com> escribió en el mensaje
news:D1E9ED5F-6EBB-4F20...@microsoft.com...