Análisis forense en sistemas Linux – Obteniendo información (Parte 2)

(Para evitar confusiones que pueda haber creado la anterior entrada, comentar que este post no trata de ser una guía paso a paso de un análisis forense, sino que consiste en proporcionar información que el auditor debe conocer a la hora de realizarlo e información que deberá utilizar según las necesidades del caso. Tanto vierito5 como Román Ramírez hacen apreciaciones muy interesantes en los comentarios de la primera parte de esta serie, que recomiendo encarecidamente leer.)

Después de haber obtenido todas las características principales del sistema a analizar, debemos averiguar qué ha podido pasar o qué acciones se han podido llevar a cabo. Para esto, Linux dispone de una serie de registros (logs) que nos facilitarán el obtener este tipo de información. Con la siguiente lista, se pretende hacer una breve introducción a algunos de los más importantes:

  • /var/log/boot.log: En este registro podremos encontrar información que se almacena durante el arranque del sistema.
  • /var/log/dmesg: Guarda los mensajes que lanza el kernel. Entre otros datos, almacena los mensajes sobre dispositivos hardware que el kernel detecta durante el arranque del sistema.
  • /var/log/cron: En este registro se guardarán las acciones realizadas por “cron” (automatizador de tareas en sistemas Unix). Aunque en algunos sistemas este log viene desactivado por defecto, podemos obtener la información del mismo de /var/log/syslog con la siguiente instrucción: zgrep -i cron /var/log/syslog”.
  • /var/log/apache2 (o /var/log/httpd): En este directorio encontraremos el registro de logs del servicio apache a través de los archivos access.log y error.log.
  • /var/log/lastlog y /var/log/wmtp: El primero muestra cuando fue el último acceso de cada usuario al sistema, y el segundo un registro de los accesos del usuario al sistema. Para poder visualizarlos es necesario hacerlo a través de los comandos lastlog (para el primero) y last (para el segundo), ya que no se tratan de archivos de texto ASCII.
  • /var/log/btmp: En este archivo podemos encontrar la lista de accesos fallidos al sistema. Como en el caso anterior, el archivo no se encuentra en ASCII, por lo que para visualizarlos utilizaremos el comando lastb.
  • /var/log/mail.log, /var/log/mail.err, /var/log/mail.warn y /var/log/mail.info: Contienen los registros del servidor de correo que haya en el sistema. Entre otros datos, podremos encontrar información sobre los e-mails enviados.
  • /var/log/messages: Este registro almacena los principales mensajes del sistema.
  • /var/log/auth.log: Guarda información sobre el sistema de autorización de usuarios y permisos del mismo.
  • /var/log/samba/: En este directorio se almacenan los logs relacionados con el servicio samba, el cual permite conectar equipos Windows con Linux.
  • .bash_history: El archivo lo podemos encontrar en el directorio home de cada usuario. En él encontraremos el historial de comandos realizados por el usuario en cuestión. Además de accediendo al propio fichero, también puede accederse a su contenido a través de la instrucción history.

Para concluir el artículo, comentar que existen muchos más logs que podrían ser de interés dependiendo de los hallazgos realizados o de las acciones realizadas por el atacante. Por este motivo es muy importante prestar atención a cada uno de ellos y saber hacía donde dirigir el análisis forense para obtener el mejor resultado posible a medida que éste se va realizando.

Comments

  1. Existe un parseador de colas de Log que utilizo llamado ccze para poder colorear y formatear los archivos log y por otro lado podemos utilizar multitail para ver varios log a la vez.

    Excelente los artículos que están publicando

  2. http://Rafael%20Páez says

    Muchas gracias por tu aporte danyx, le echaremos un vistazo a estas dos herramientas ;)

    Saludos
    fikih888

  3. http://Juan%20Luis%20fernandez says

    Interesante articulo, pero algunas cosas que indicar:

    Para una máquina normal lo que indicas podría ser un indicativo más o menos fiable, pero en entornos reales donde han realizado una escalada de privilegios, borrar/modificar esos logs es algo trivial con métodos como ” export HISTFILE=/dev/null” o similares, luego solo quedaría modificar lo que se quisiera y cuando salgas ahí no ha pasado nada.

    Para poder fiarse de esos logs, como mínimo seria interesante implantar sistemas como auditd y envío remoto de logs a otros sistemas con mayor seguridad.

    Esto solo son observaciones personales, para nada tiene que ser las más indicadas.

    Saludos

  4. Gracias por la info. Me ha sido muy útil. Gente como tú hace internet un mundo apasionante.

  5. De hace un par de días vengó leyendo la información del blog. 10 de 10 la verdad. Para esta serie de artículos sin querer ofender o sin querer no valorar el contenido, desde mi humilde opinión quizás lo que pasó es que el título genera muchas expectativas sobre lo que se va a encontrar dentro del texto y al leer quizás tiende a confundir y a esperar más de lo que leíste. Me pasó que sinceramente pensé que iba a leer algo mucho más avanzado y no fue así… Sabía la mayoría de las cosas que se tocaron y eso me hizo un poco de ruido. De nuevo, sin querer tirar para abajo el post, o sin querer alardear de que se más o algo así es lo que me pasó a mí. Igual con otro título le seguiría dando 8 de 10 y solamente para que vengan al menos 3 partes más :)