RASTREAR UN DROP TABLE

Gracias por tu apoyo, vere que me den acceso al S.O.

saludos


"Rubén Garrigós" escribió en el mensaje
news:

Dependerá de la política de backups del log que se tenga. Se puede
examinar 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" wrote in message
news:%

a 24 horas del incidenete crees que aun este registrado algo??

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" escribió en el mensaje
news:

Hola Ivan,

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" wrote in message
news:

Bueno entonces en conclución, si no estaba preparado para esto no podré
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" escribió en el mensaje
news:

En principio esa información no se audita por defecto salvo que
tuvieras una 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" wrote in message
news:OdY$

Hola a todos,

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

He recordado que tu petición inicial era saber quien y cuando borró la
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" wrote in message
news:

Gracias por tu apoyo, vere que me den acceso al S.O.

saludos


"Rubén Garrigós" escribió en el mensaje
news:

Dependerá de la política de backups del log que se tenga. Se puede
examinar 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" wrote in message
news:%

a 24 horas del incidenete crees que aun este registrado algo??

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" escribió en el mensaje
news:

Hola Ivan,

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" wrote in message
news:

Bueno entonces en conclución, si no estaba preparado para esto no
podré 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" escribió en el mensaje
news:

En principio esa información no se audita por defecto salvo que
tuvieras una 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" wrote in message
news:OdY$

Hola a todos,

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

lo corri y no me arrojo ningun resultado, creo que el registro ya paso a mas
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" escribió en el mensaje
news:

He recordado que tu petición inicial era saber quien y cuando borró la
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" wrote in message
news:

Gracias por tu apoyo, vere que me den acceso al S.O.

saludos


"Rubén Garrigós" escribió en el mensaje
news:

Dependerá de la política de backups del log que se tenga. Se puede
examinar 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" wrote in message
news:%

a 24 horas del incidenete crees que aun este registrado algo??

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" escribió en el mensaje
news:

Hola Ivan,

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" wrote in message
news:

Bueno entonces en conclución, si no estaba preparado para esto no
podré 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" escribió en el mensaje
news:

En principio esa información no se audita por defecto salvo que
tuvieras una 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" wrote in message
news:OdY$

Hola a todos,

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