Con esta serie de dos artículos se pretende hacer una pequeña descripción sobre algunos comandos y registros de logs que deben analizarse cuando nos encontramos ante un análisis forense en un sistema Linux.
(Añadido 29.05, 16h)
Viendo que el post está causando confusiones a la hora de cómo y cuándo realizar las acciones descritas, comentar que cuando nos encontramos ante el análisis forense de cualquier sistema, se debe evitar trabajar sobre el propio sistema afectado, ya que cualquier modificación que hagamos en el equipo se verá reflejada y alterará la evidencia (incluyendo cualquier MAC time existente). Además, en el caso de tener que demostrarse en un juicio, se deberá poseer el sistema original sin haber sido modificado.
Para realizar esta serie de posts, se ha cargado la imagen del sistema afectado en una máquina virtual, por lo que ante cualquier modificación realizada, siempre se puede volver al sistema “original”.
El primer paso que debemos realizar en estas situaciones es obtener las principales características del sistema afectado. Para esto, los sistemas Linux disponen de un gran número de logs e instrucciones que nos permiten realizar estos pasos de una forma sencilla. A continuación se detallarán algunas de las funciones y registros que serán de “obligada” consulta para la correcta realización de nuestro análisis forense:
- Las instrucciones uname -a y lsb_release -a nos mostrarán las principales características del sistema, como pueden ser la versión de kernel y la distribución del sistema operativo.
- netstat nos permitirá obtener el listado de todas las conexiones existentes con la máquina, tanto aquellas de entrada como las de salida. Además, nos mostrará información de cada una de ellas, como por ejemplo los procesos que las están utilizando. Una buena combinación de opciones puede ser netstat -punta, la cual nos mostrará todas las conexiones TCP y UDP y el nombre del programa y PID que las utiliza o nestat -rn que nos mostrará las tablas de rutas existentes.
- Ver los procesos que están corriendo en el sistema es un factor muy importante, así que para ello utilizaremos ps auxww, con lo que obtendremos todos los procesos del sistema de todos los usuarios (la opción ww es para que no se corte el nombre del proceso si es más largo que el ancho de la pantalla).
- El comando mount nos permitirá conocer los sistemas de ficheros que utiliza el equipo en los diferentes discos. Una alternativa a mount podría ser fsstat /dev/sda1 donde /dev/sda1 es el disco a comprobar.
- Con fdisk -lu /dev/sda obtendremos las diferentes particiones existentes en el disco duro /dev/sda, así como los sectores de inicio y fin de cada una de ellas. Esto también nos servirá para comprobar el hash de las imágenes de cada partición en caso de ser necesario.
- Para poder ver la configuración de las todas las redes existentes en la máquina utilizaremos ifconfig -a.
- En el caso de trabajar sobre una máquina en caliente, podemos utilizar la instrucción who para conocer los usuarios que están actualmente logueados en el sistema uptime para saber cuanto tiempo lleva el sistema arrancado.
Una vez hemos obtenido las principales características del sistema, podremos proceder a realizar un análisis de los directorios más críticos del sistema. Para ello podemos utilizar ls con las opciones -lrta para visualizar de una manera fácil las características de cada fichero/directorio y la opción -R para analizar recursivamente los directorios, quedando la instrucción como ls -lrtaR.
Entre estos directorios encontramos:
- /etc: contiene los principales archivos de configuración del sistema como archivos de contraseñas, puntos de montaje, conexiones de red, etc.
- /dev: Almacena los dispositivos conectados al sistema como discos duros, lectoras, impresoras, etc.
- /bin: Almacena los comandos básicos para todos los usuarios del sistema.
- /sbin: Dispone de comandos esenciales reservados para el administrador (root) del sistema.
- /usr/bin: almacena el resto de comandos que pueden ser usados por los usuarios.
- /usr/sbin: contiene los binarios no vitales del sistema que son usados por el administrador.
Una alternativa al paso anterior sería utilizar alguna herramienta automatizada como Sleuthkit (disponible en el repositorio desde apt-get), que nos permite obtener todas las MAC times del sistema de una manera muy fácil y cómoda con el siguiente comando: fls -m / -r /dev/sdaX > mac_times.txt, donde /dev/sdaX será el disco a analizar y mac_times.txt el fichero donde se guardará la salida del comando.
Con esto damos por finalizada la primera parte del artículo, dejando para el siguiente aquellos logs del sistema que nos permitirán obtener información para poder averiguar qué es lo que ha podido pasar en el sistema y cómo.
Qué clase de análisis forense se hace sobre un sistema en vivo? Wait for it…
…ninguno!
Además de que esto modifica la evidencia, ya me dirás que vas a ver con todas estas acciones si está rootkiteado.
Hola vierito5,
gracias por el comentario, pero en ningún momento he dicho que todo esto se haga sobre un sistema en vivo. El único comentario que puede hacer pensar eso es el de las instrucciones “who” y “uptime”, pero digo “En el caso de trabajar sobre una máquina en caliente”, ya que puede llegar a suceder que en alguna ocasión no nos quede más remedio que hacer algunas comprobaciones de esta manera. Aunque lo más seguro y normal (aunque todo depende de la situación) para no modificar la videncia es hacer las correspondientes copias de los discos y analizarlos externamente, de ahí que también ponga “Esto también nos servirá para comprobar el hash de las imágenes de cada partición en caso de ser necesario”.
Respecto a lo de si existen rootkits, si se trabaja sobre imágenes de disco, ese problema no existe.
De todas formas, este post no intenta explicar paso a paso lo que hay que hacer en un análisis forense, sino simplemente dar una idea de que logs o registros podemos mirar a la hora de realizar uno, y en ningún momento creo haber dicho que todo esto se haga sobre la máquina original.
Saludos
fikih888
Está claro que no se puede meter todo en un post pero si el post pretende ser didáctico va a llevar a muchos equívocos.
No es solo who y uptime…
Nuevamente me reafirmo en lo que he dicho, eso está enfocado a ser ejecutado sobre un sistema en vivo:
– uname, lsb_release
– mount (ni si quiera habéis añadido el read only!)
– ifconfig
– who
– uptime
– ls (pasando todas las opciones posibles para tocar todos los ficheros)
Digamos que sólo se salva el fdisk y fls que se podrían hacer directamente sobre la imagen del disco (que por cierto no habéis nombrado no hacerlo sobre el original)
Parte se podría hacer desde un sistema montado en un chroot pero tampoco es la manera adecuada de hacerlo.
Lo siento, pero creo el asunto está muy mal enfocado.
Espero que el resto de la serie sea mejor :(
Mirándolo así quizás sí que puede ser un poco lioso, pero es que como he dicho, únicamente quería dar a conocer posibles registros que nos permitan obtener información de un sistema afectado.
Las imágenes todo depende de como las montes, si lo haces desde una máquina virtual, por ejemplo, que es lo que se ha utilizado en este caso, puedes trabajar con ellas directamente, haciendo una copia previa de todas las MAC times antes de realizar ninguna modificación en el sistema. Además, al disponer de una copia original, siempre puedes volver a ella sin miedo a modificar nada.
Como bien dices no se puede tratar todo en un post, ya que cada una de las situaciones existentes daría para bastante, y si me centro en un análisis paso a paso no se podría entrar tanto en detalle en algunas cosas, ya que a mi parecer, siempre depende del escenario encontrado.
Gracias una vez más por tus valoraciones, y se tendrá en cuenta en el siguiente, para no inducir a tantas confusiones.
Saludos
fikih888
A petición de Rafa se han añadido dos párrafos introductorios que esperamos que clarifiquen las dudas y confusiones planteadas.
A veces realizar análisis “en caliente” es la única opción.
Ejemplos con los que me he encontrado en vivo y en directo: equipos industriales en una cadena de montaje (que NO te dejan parar).
Y sumadle a eso que que eran equipos que corrían con Windows NT (sin soporte USB) :))
El hecho es que mientras DOCUMENTES de forma clara todas las acciones que has acometido y evidencias cuáles son tus modificaciones, puedes defender la adquisición de la evidencia.
Por otro lado, sí veo necesario incorporar un comentario en el artículo hablando de estrategias en caliente/en frío y los motivos de optar por unas u otras; para mí casi toda la información que puedes obtener en caliente la puedes obtener en frío, a partir de ficheros de swap etc, o mediante evidencias indirectas (pero todo son enfoques y formas de trabajo).
Muchas gracias por el comentario y muy bueno el aporte del caso real Román Ramírez :)
Como dices, en algunas ocasiones no nos queda más remedio que trabajar sobre el equipo en caliente, pero creo que siempre que sea posible se debe intentar evitar esto, ya que cualquier pequeña modificación/error que podamos cometer puede echar a perder todo el caso, y si trabajamos con copias siempre podemos volver al original sin problema.
El problema de tratar cada aspecto de un análisis forense en un post lo veo un poco complejo/extenso, ya que a mi parecer, cada caso es un mundo, y se tienen que tener en cuenta muchos aspectos para poder elegir cuál es la mejor vía en cada caso.
Cualquier comentario o sugerencia que se añada será bien recibida :)
Saludos
fikih888
Se nota que en la perspectiva del analisis forense prima el enfoque por el “caso defendible y demostrable” (lease “en frio”)
Sin embargo como bien han apuntado antes, existen muchos casos reales en los que la principal preocupación está en eliminar el riesgo y/o la intrusión sin que exista una interrupción del servicio y la demostración de las responsabilidades (incluyendo las judiciales, cadena de custodia, etc.) pasa a un segundo plano.
En esos casos las investigaciones e intervenciones “en vivo” son muchas veces la única opción.
Saludos
Creo que se le podria ver a esta entrada tambien como comandos utiles para monitorear nuestros PROPIOS sistemas, asi que no nos quedemos con que si es en caliente/frio el analisis. Lo importante es el contenido (talvez el titulo fue mal enfocado), pero desde mi punto de vista estos comandos nos sirve para monitorear (y los hemos usado VARIAS veces) nuestros propios equipos.
Saludos ;)