Re: recuperar lineas borradas del bash_history [ataque]
Gracias a tod@s por vuestro interés ! :)
Sin duda me habeis aportado información suficiente como para empezar a
trabajar de forma seria. Prometo enviar un reporte en cuanto haya
sacado algo de la autopsia :)
Saludos y gracias de nuevo!
Marc.
2008/9/9 Salvador Garcia Z. <meztlixictli@gmail.com>:
> nx escribió:
>>
>> Salvador Garcia Z. escribió:
>>>
>>> Marc Aymerich escribió:
>>>>
>>>> Muy buenas listeros,
>>>> este fin de semana entraron en mi servidor de pruevas (la seguridad
>>>> era de 'estar por casa'), presuntamente entraron para perpetar un
>>>> ataque contra otras maquinas, lo malo esque borraron las últimas
>>>> lineas del bash_history y no hay forma de saber que es lo que
>>>> estubieron haciendo. Por suerte, para dejarlo todo intacto, la maquina
>>>> Xen fue apagada con un Destroy, así que ahora hay la oportunidad de
>>>> hacer un analisis forense, lo que pasa esque no tengo ningun
>>>> conocimiento sobre el tema :( ¿Alguien podria orientarme en como
>>>> tratar de recuperar esas lineas borradas?
>>>>
>>>> saludos.
>>>> Marc
>>>>
>>>>
>>>
>>> Mira, ahí existen evidencias, eso es claro. Si pudieras dar un poco mas
>>> de detalles, seria perfecto.
>>>
>>> Mientras te puedo decir que hay dos herramientas para hacer un análisis
>>> forense y son las siguientes:
>>> 1.- Autopsy
>>> 2.- Libtsk1
>>> La primera te ofrece entorno gráfico y la segunda es basada en consola,
>>> las dos se encuentran en los repositorios oficiales de debian.
>>> El segundo corresponde a Sleuth Kit que es una herramienta exclusiva para
>>> sistemas UNIX y que es implementado en sistemas Linux, por lo cual es la que
>>> te recomiendo amplia-mente.
>>>
>>> Independiente a ello debes hacer la revisión de MD5 de lo que tienes
>>> instalado y verificar las fechas modificante, con ello saldrán algunos
>>> paquetes que brindaran alguna pista por donde y como entraron.
>>> Revisa /var/spool/(X). Ahi deben estar los registros adicionales aparte
>>> de /var/log.
>>> Revisa el correo interno del sistema en /var/mail/(x)
>>> Revisa los registros de cron en /etc/cron/ estos existen de diario,
>>> semana, etc.
>>>
>>> Por lo general un ataque a un sistema no se realiza de inmediato, al
>>> menos que sea totalmente vulnerable. Lo ideal es estudiar un poco la maquina
>>> para poder saber en que momento y por donde hacer eso, por lo tanto debieron
>>> explorar tus puertos, saber que servicios tenias funcionando y que sistema
>>> operativo tenias instalado ahí.
>>>
>>> Deverias realizar algunos estudios adicionales, por ejemplo: que puertos
>>> tienes abiertos, que capacidad de disco disponible y compararle de dos o
>>> tres maneras con métodos diferentes, revisar las cantidades de memoria que
>>> se están ejecutando en los procesos y si son las adecuadas a la carga de
>>> trabajo, también debes revisar la red de forma minuciosa para ver lo que
>>> esta sucediendo ahí (esta es una parte muy interesante).
>>>
>>> Espero con esto ayudar un poco y si nos das mas datos podríamos ir un
>>> poco mas a fondo sobre este tema, aun que en esta área nada esta escrito y
>>> no existe un método a seguir, es cuestión de ir acomodando el rompecabezas y
>>> estudiar.
>>>
>> Hola, por mi experiencia pienso que mas que borrar las últimas líneas del
>> .bash_history lo que han hecho habrá sido un unset $HISTFILE, es más rápido
>> y más limpio y no es posible su recuperación.
>> Si tienes el accounting activado prueba con el comando history, asi puedes
>> comprobar si efectivamente han hecho eso u otra cosa ...
>>
>> Suerte :)
>>
> Si deseas continuar es muy importante que realices una imagen del disco de
> forma inmediata.
>
> Lo ultimo es posible y el código mas común que se ejecuta por lo general es:
> unset HISTFILE
> export HISTFILE=/dev/null
>
> Si fue así el historial no existe en bash.
>
> Pero el bash no es la única parte a revisión. Normalmente cuando se entra
> una vez y todo fue bien, se deja una puerta tracera para continuar
> ingresando a esa maquina. Ocasionalmente se hacen cosas extrañas para que se
> den cuenta de que alguien estuvo ahí y después de una revisión se descarte
> que ingresen nuevamente.
>
> Si fue una persona inexperta debio cometer mas errores y el bash no fue lo
> unico que se toco en esa maquina, de eso estoy seguro.
> Si fue una persona con experiencia, las cosas son complicadas y lo mas
> seguro es que ya se realizo una cuenta para el de manera que no pueda ser
> monitoriada o que no le puedas descubrir facilmente.
>
> Se puede utilizar ( unset HISTFILE , unset HISTSAVE ) tambien para evitar
> que se guarde en los log del sistema y existe una herramienta que no digo
> nombre por no impulsar a alguien a hacer eso, pero que con el simple
> ./wipper te borra todo rastro de long.
>
> Con esto todo indica que no se podría continuar con un seguimiento de un
> intrusismo a una maquina, pero existen partes que son claves para poder
> determina eso. Por que no revisas fls.rm es un archivo grande pero que es de
> vital importancia para un estudio de este tipo, se puede utilizar
> # Mactime-b fls.rm.dev> timeline.dev
> para ver de manera detallada el sistema, aquí se registra cualquier cosa,
> incluyendo las ocultas por un rootkit.
>
> Tambien puedes utilizar esto así:
> # grep "\/\." fls.rm > fls.rm.dot
> # mactime -b fls.rm.dot > timeline.dot
> Esto es para verificar si se ejecuto algún script en tu sistema y en que
> fecha, si es un proceso normal del mismo o se cargo un proceso adicional.
>
> # ./netstat -na | ./nc -w 3 (dirección de la maquina) 9000
> Esto nos permite verificar que puertos están utilizando para su conexión,
> incluyendo los puertos ocultos y dirección de conexión.
>
> # Nmap-sS-p 1 - (dirección de la maquina)
> Este comando puede indicar que están ocultando puertos incluso para el mismo
> kernel, si le comparas con el comando anterior.
>
> #. / Lsof-n |. / Nc-w 3 (dirección de la maquina) 9000
> Esta salida te puede dar datos muy importantes para determinar que archivos
> se han movido por tu server y que puertos, así como direcciones.
>
>
> --
> To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>
Reply to: