Skip to content

Análisis forense en entornos UNIX y derivados

Publicado por Sergio Hernando el 2 febrero 2006

Tener una distribución Linux no es bajo ningún concepto garante total de que estamos blindados. Probablemente, la configuración por defecto nos defienda de muchos problemas presentes en sistemas tipo Windows, pero hay que romper con la idea de que Linux (quien dice Linux dice cualquier variante UNIX o *BSD) es inexpugnable, porque no lo es.

Aprovecho esta entrada para dar respuesta a múltiples peticiones que me habían llegado por correo y comentarios sobre análisis forense. Es información general, pero bueno, algo es algo :)

Disparos certeros y cañonazos

Para que nos hagamos una idea, me váis a permitir un símil "policíaco". Si en un tiroteo llevamos un antibalas, posiblemente tengamos muchas más probabilidades de sobrevivir en comparación a quien no lo lleva, pero si nos pegan un cañonazo, el antibalas nos va a servir de bien poco. Ídem si recibimos un disparo certero en un área vital no cubierto por el antibalas.

Comprometer un servidor Debian es un disparo muy certero. Y es posible. Y esto tiene una clara desventaja sobre sistemas Windows. Un sistema Windows normalmente es más conocido y su arquitectura permite sólamente unos pocos puntos de control. No podemos controlar la totalidad del sistema, ya que la arquitectura Windows como bien sabéis, diferencia entre procesos de usuario y procesos máquina propios, los cuales son, salvo excepciones, cajas negras donde sólo sabemos que entran y salen cosas, y donde para lo bueno y lo malo, no es habitual poder manipular nada.

Un sistema Linux es mucho más complejo, puesto que la arquitectura permite un control total del mismo. Y al tener más control, y al existir más complejidad, perpetrar un ataque sigiloso difícilmente detectable, es mucho más factible, sobre todo porque la complejidad y la poca práctica con los procesos de un kernel libre y sus radios hace que muchos administradores posean en estos entornos conocimientos menores a los que se tienen en un entorno Windows, mucho más popular, con muchas herramientas de control y de seguridad que se activan con dos golpes de ratón y con menos recovecos para, como decíamos al principio, pegar tiros certeros. Es posible pegarlos, pero quizás, o al menos es mi impresión, es más fácil detectar anomalías.

Aquí tenemos un ejemplo claro. El documento se llama SSH Password Guessing: Linux compromise and forensics, y pese a que no describe nada nuevo, es excelente documento en el que podemos ver un caso práctico de compromiso de servidor Linux desde una red local. La narración describe desde el momento en que la actividad de compromiso es detectada hasta el análisis forense del ataque, pasando cómo no, por las preceptivas respuestas ante incidentes.

Es un documento didáctico orientado a refrescar conceptos que más de uno ha olvidado y que debería recordar. Una lectura obligatoria si administras soluciones Linux, UNIX o derivado.

Metodología forense resumida

En entornos UNIX y derivados, una vez hay sospechas de actividad anómala, es frecuente proceder a la respuesta ante incidentes prototipo. Las señales de alarma normalmente las ofrecen los sistemas de detección de intrusos, que registran la actividad sospechosa. En todo el proceso es extremadamente importante no contaminar las evidencias, ya que serán utilizadas para propósitos judiciales y/o a nivel interno de la empresa, por lo que lo que se recolecte debe estar tal y como lo dejó el atacante.

Recolección de evidencias

Para la recolección de evidencias en la inspección forense, es muy habitual utilizar distribuciones live (no necesitan instalar, se ejecutan desde el CD o DVD) que al tirar de Ramdisk no utilizan el espacio de disco escenario del crimen. Tan sólo leen datos, garantizándose la asepsia en la recogida de pruebas. Los autores del paper han empleado Helix [HLX] bootable CD, basada en Knoppix. Yo pesonalmente empleo para estos menesteres FIRE y Penguin Sleuth. Eventualmente he utilizado además de Helix, una distro mini que llevo en tarjeta CD llamada PLAC. Otro proyecto a tener en cuenta es Necromantux, de origen español. También hay que tener en el portacds una copia de Auditor.

Sea como fuere, son todas bastante parecidas, y casi todas tienen las mismas herramientas: foremost, fatback, md5deep, TCT, sha15deep, PyFLAG, etc. En este proceso hay que tratar de evitar, para no violar las prescripciones ITIL ni las de cualquier otro código de buenas prácticas al respecto, que la máquina esté sin servicio más tiempo del estrictamente necesario. Es imperativo que el personal al cargo de la máquina esté informado de la interrupción del servicio y la duración de la interrupción con carácter previo a la actuación.

La recolección de pruebas se centrará en los servicios que sospechemos estén o hayan sido comprometidos. No está de más recoger pruebas genéricas y de servicios aparentemente no comprometidos, todo dependerá de la ventana de tiempo asignada para la recuperación de la máquina analizada. Para estos menesteres, las distribuciones forenses están repletas de herramientas libres de análisis.

Reanimación cautelar

Una vez detectadas las fuentes de problemas, se procede a subsanar y a reanimar los servicios. A veces es necesario reactivar la máquina antes de subsanar, por cuestiones de tiempo. Sea como fuere, el análisis de campo debe concluir con la puesta en servicio de la máquina comprometida habiéndose aplicado las medidas cautelares de prevención estimadas como necesarias para garantizar que la máquina puede entrar en operación de un modo seguro.

El trabajo de gabinete

Con los registros y las evidencias, pasamos al trabajo de gabinete, eso sí, mirando de reojo la máquina reactivada, para verificar que las medidas de prevención funcionan y para ver si la actividad sospechosa ha finalizado o no. El trabajo de despacho concluye con el informe o análisis forense, un documento que debe contener, al menos:

  1. Descripción detallada de las condiciones de contorno antemortem
  2. Descripción de la situación del sistema postmortem
  3. Descripción de los datos recolectados, metodologías y herramientas aplicadas
  4. Descripción de las medidas cautelares de recuperación y garantías obtenidas
  5. Informe final de incidencias, causas y medidas de corrección
  6. Análisis completo de servicios y estado de vulnerabilidad global
  7. Proposición de mejoras y conclusiones

Más información

Es un resumen rápido de las principales tareas cuando nos enfrentamos a un problema similar al descrito. Espero os sea de utilidad. De todos modos, a quienes os interese el tema forense y queraís ampliar en conceptos prácticos y procedimentales, os recomiendo un libro, de Dan Farmer y Wietse Venema (autores de Postfix, SATAN, The Coroner´s Toolkit, entre otros) titulado Forensic Discovery. También os invito a la lectura de un paper del que hablé aquí, First Responders Guide to Computer Forensics. Lo que tengáis que acreditar el trabajo ante un juzgado, haréis bien en leer Interrogatorios judiciales. Consejos para examinadores forenses, que aunque muy orientado al sistema americano de justicia, no está de más nunca.

Saludos.

Be Sociable, Share!

Categoría/s → Forensics, Seguridad, Software Libre

Sin comentarios

Escribir un comentario

Note: XHTML permitido. Tu email nunca será publicado.

Suscribirse a los comentarios via RSS