Identificación del incidente: búsqueda y recopilación de evidencias:
Una de las primeras fases del análisis forense comprende el proceso de identificación del incidente, que lleva aparejado la búsqueda y recopilación de evidencias.
Si sospecha que sus sistemas han sido comprometidos lo primero que tiene que hacer es ¡NO PERDER LA CALMA!, piense que no es el primero y que menos aún va a ser el último al que le ocurre. Antes de comenzar una búsqueda desesperada de señales del incidente que lo único que conlleve sea una eliminación de “huellas”, actúe de forma metódica y profesional.
Asegúrese primero que no se trata de un problema de hardware o software de su red o servidor, no confunda un “apagón” en su router con un ataque DoS.
Descubrir las señales del ataque:
Para iniciar una primera inspección del equipo deberá tener en mente la premisa de que debe conservar la evidencia, por ello NO HAGA NADA QUE PUEDA MODIFICARLA. Deberá utilizar herramientas que no cambien los sellos de tiempo de acceso (timestamp), o provoquen modificaciones en los archivos, y por supuesto que no borren nada.
Un inciso importante es que si no hay certeza de que las aplicaciones y utilidades de seguridad que incorpora el Sistema Operativo, o las que se hayan instalado se mantienen intactas deberemos utilizar otras alternativas. Piense que en muchos casos los atacantes dispondrán de herramientas capaces de modificar la información que el administrador verá tras la ejecución de ciertos comandos. Por ejemplo podrán ocultarse procesos o puertos TCP/UDP en uso. Cuestione siempre la información que le proporcionen las aplicaciones instaladas en un sistema que crea comprometido.
No estría de más en este momento crear un CD o DVD como parte de sus herramientas para la respuesta a incidentes, y si trabaja en entornos mixtos UNIX/Linux y Windows, tendrá que preparar uno para cada plataforma. Aunque existen gran cantidad de utilidades a continuación propongo una relación de aquellas que considero debería incluir en su ToolKit, y que le permitan, al menos, realizar las siguientes tareas:
- Interpretar comandos en modo consola (cmd, bash)
- Enumerar puertos TCP y UDP abiertos y sus aplicaciones asociadas (fport, lsoft)
- Listar usuarios conectados local y remotamente al sistema
- Obtener fecha y hora del sistema (date, time)
- Enumerar procesos activos, recursos que utilizan, usuarios o aplicaciones que los lanzaron (ps, pslist).
- Enumerar las direcciones IP del sistema y mapear la asignación de direcciones físicas MAC con dichas IP (ipconfig, arp, netstat, net)
- Buscar ficheros ocultos o borrados (hfind, unrm, lazarus).
- Visualizar registros y logs del sistema (reg, dumpel)
- Visualizar la configuración de seguridad del sistema (auditpol)
- Generar funciones hash de ficheros (sah1sum, md5sum)
- Leer, copiar y escribir a través de la red (netcat, crypcat)
- Realizar copias bit-a-bit de discos duros y particiones (dd, safeback)
- Analizar el tráfico de red (tcpdump, windump)
Supongamos que ya dispone de su ToolKit, ahora se hará la siguiente pregunta ¿dónde
puedo buscar indicios de un ataque?. Evidentemente, uno de los primeros lugares donde comenzar la búsqueda de indicios es en los equipos que consideremos comprometidos pero no
se limite sólo a éstos, piense que sus atacantes han podido borrar algunos registros locales en
esos equipos, pero aún así, puede haber indicios en otras máquinas próximas tales como escaneado de puertos o tráfico inusual en cortafuegos y routers de la red.
Al iniciar la investigación nunca sabremos con qué nos vamos a topar, de hecho al
principio puede que no se aprecie, a simple vista ninguna huella o indicio del ataque especialmente si para realizarlo han empleado e instalado en sus equipos un rootkit.
Como primera opción de búsqueda podemos realizar una verificación de integridad de
los ficheros del sistema, utilidades como Tripwire o AIDE (Advance Intrusion Detection Enviroment) podrán arrojar algo de luz sobre sus sospechas. Otra opción es realizar una serie de
verificaciones sobre del equipo.
Primero sería interesante conocer los procesos que se están ejecutando actualmente en
el equipo, en busca de alguno que le resulte extraño, deberán llamarnos la atención aquellos
que consuman recursos en exceso, con ubicaciones poco frecuentes en el sistema de archivos,
que mantengan conexiones de red en puertos TCP o UDP no habituales, etc.
Este último punto nos llevará a realizar otra comprobación de interés, listar todos los
puertos TCP y UDP abiertos además de los procesos (PID), usuarios y aplicaciones que los
utilizan, siempre con la idea de identificar actividad no usual, recuerde la importancia de que
el administrador conozca muy bien los parámetros de actividad normal del sistema. La aparición en el listado de procesos sin nombre o que emplean puertos altos (por encima del 1024)
pueden ser indicios de la ejecución de un troyano o puerta trasera (backdoor) en el equipo.
Una buena opción sería buscar en Internet (especialmente en Google) alguna referencia sobre
el puerto o proceso que le resulta sospechoso.
Si tras estas consultas sus temores aumentan, pase ahora a editar los archidos de registro del sistema y logs en busca de entradas y avisos sobre fallos de instalación, accesos no
autorizados, conexiones erróneas o fallidas, etc. Dependiendo de la plataforma que emplee
encontrará estos archivos en distintas ubicaciones.
Microsoft Windows: Este sistema operativo le proporciona un entorno para realizar
estas pesquisas puede consultar, si considera que se trata aún de una aplicación segura,
dentro del menú Herramientas administrativas, el Visor de sucesos, el de Servicios o el de
la Directiva de seguridad local. Si no entiende bien la información que estos visores le aporten puede consultar la base de datos de ayuda de Microsoft. Otro lugar donde se
esconde gran cantidad información es el registro de Windows. La aplicación del sistema regedit.exe puede ayudarle en esta tarea, pero si no se fía de ella use las
herramientas de su CD tales como reg (permite hacer consultas al registro sin modificarlo), o regdmp (exporta el registro en formato de texto plano, .txt), para su posterior
consulta. En estos archivos tendrá que buscar “una aguja en un pajar”, debido a la ingente cantidad de información que almacena y que se mezcla. Un punto de partida
podría ser buscar en las claves del registro Run, RunOnce, RunOnceEx, RunServices,
RunServicesOnce, Winlogon, pues bajo estas claves se encuentran los servicios, programas y aplicaciones que se cargarán en el inicio del sistema. Si ve algo raro, acuda nuevamente a Google.
UNIX/Linux: En este tipo de sistemas se dispone de una serie de archivos de registro
(logs), que podremos encontrar habitualmente bajo el directorio /var/log, siendo
los más importantes los que se detallan a continuación:
Además los programas y aplicaciones crean normalmente sus propios archivos de registro, que podrá encontrar bajo el directorio /var. Todos estos archivos están en modo texto, por lo que podrá utilizar cualquier editor o visor de texto para buscar indicios
del ataque. Observe el siguiente fragmento de un archivo /var/log/messages, en
una máquina comprometida:
¿No aprecia nada raro?, fíjese en la 4ª y 5ª entradas del archivo, éste parece haber sido
modificado pues aparece un salto en la secuencia de fechas, con dos entradas fechadas
el 22 de agosto tras dos entradas con fecha 23 de agosto. Este tipo de detalles, aunque
no son determinantes, si pueden ser síntomas de que han estado “trasteando” en sus
sistemas.
Además de estos archivos de registro, también pueden contener indicios los archivos
de claves, usuarios y grupos, podrá encontrarlos en /etc/passwd, /etc/shadow, /etc/group. También pude encontrar indicios de actividad anómala al editar el archivo /root/.bash_history que contiene los comandos ejecutados por el usuario
roo el intérprete vas.
Para el propósito inicial de confirmación del ataque o compromiso de sus sistemas
estas primeras pesquisas serán suficientes, aunque tendrá que volver a utilizar de forma más
exhaustiva estos datos tal y como veremos en el apartado de análisis de evidencias.
Recopilación de evidencias:
Bien, ya está seguro de que sus sistemas informáticos han sido atacados. En este punto
deberá decidir cuál es su prioridad:
A.- Tener nuevamente operativos sus sistemas rápidamente.
B.- Realizar una investigación forense detallada.
Piense que la primera reacción de la mayoría de los administradores será la de intentar
devolver el sistema a su estado normal cuanto antes, pero esta actitud sólo hará que pierda
casi todas las evidencias que los atacantes hayan podido dejar en “la escena del crimen”, eliminando la posibilidad de realizar un análisis forense de lo sucedido que le permita contestar
a las preguntas de ¿qué?, ¿cómo?, ¿quién?, ¿de dónde? y ¿cuándo? se comprometió el sistema, e impidiendo incluso llevar a cabo acciones legales posteriores si se diese el caso. Esto
también puede que le lleve a volver a trabajar con un sistema vulnerable, exponiéndolo nuevamente a otro ataque.
Si no está seguro de lo que está haciendo, ¡NO HAGA NADA!, y póngase en contacto
con expertos en la materia.
Este es un buen momento para hacerse con un cuaderno donde comenzar a tomar
apuntes detallados de todas las operaciones que realice sobre los sistemas atacados, no se fíe
de su memoria, anote la fecha y hora de inicio y fin de cada uno de los pasos que dé, anote
también características como números de serie de cada equipo, de sus componentes, de su
S.O., etc. No escatime en la recopilación de datos incluso haga fotografías de los equipos y
del entorno, nunca se sabe si tendrá que vérselas con sus atacantes en un juicio, y cualquier
evidencia puede ser definitiva. También sería recomendable que le acompañase otra persona
durante el proceso de recopilación de evidencias, ésta actuaría como testigo de sus acciones,
así que si es alguien imparcial mejor, y si puede permitirse que le acompañe un Notario mejor
que mejor, recuerde los requisitos legales para que una evidencia pase a ser considerada como
prueba en un juicio. No sería la primera vez que un excelente análisis técnico de un incidente
es rechazado en un juicio por no guardar las debidas garantías procesales.
Ahora que ya está preparado para la recolección de evidencias tendrá que decidir si
comienza a tomar muestras sobre el sistema “vivo” o “muerto”. Tenga presente que en el sistema habrá pruebas ocultas con diferentes niveles de volatilidad, como los registros del procesador, estructuras de datos en la memoria RAM o memoria de tipo caché, conexiones de red
activas, usuarios y procesos actuales, sistema de archivos, etc. Será muy difícil reunir toda
esta información a la vez y gran parte de esta se perderá si decide apagar el equipo de la forma
habitual, ya que en este proceso se realizan una serie de pasos programados para cerrar el sistema de forma limpia, pero si además el atacante ha instalado las herramientas adecuadas éste
podría eliminar, modificar y sustituir ficheros a su antojo durante el apagado, y se “limpiarán”
también del equipo las huellas de su atacante. Además si el atacante sigue on-line, puede detectar su actividad y actuar con una acción evasiva o, peor aún, destructiva eliminando todo
tipo de información. Pero si por la severidad del ataque o por la importancia de los datos
comprometidos decide apagar el equipo, no lo dude ¡DESCONÉCTELO DIRECTAMENTE
DE LA RED ELÉCTRICA!, si ha leído bien, de esta forma perderá la información volátil de
la RAM, micro, etc. Pero conservará aún bastante información sobre el ataque.
Supongamos que puede mantener su equipo “vivo” un poco más, comience a recopilar
evidencias siguiendo el orden de mayor a menor volatilidad. Este proceso se describe muy
bien e el RFC 3227, .Estableceremos el siguiente orden de volatilidad y por tanto de recopilación de evidencias:
- Registros y contenidos de la caché.
- Contenidos de la memoria.
- Estado de las conexiones de red, tablas de rutas.
- Estado de los procesos en ejecución. 9 Contenido del sistema de archivos y de los discos duros. Contenido de otros dispositivos de almacenamiento.
Observe que los cuatro primeros puntos representan un tipo de datos, volátil, que se perderán o modificarán si apaga o reinicia el sistema, es por tanto muy fácil eliminar evidencias de
forma inadvertida.
Dentro de las evidencias volátiles será de interés recuperar los siguientes datos del sistema
en tiempo real:
- Fecha y hora.
- Procesos activos.
- Conexiones de red.
- Puertos TCP/UDP abiertos y aplicaciones asociadas “a la escucha”.
- Usuarios conectados remota y localmente.
Durante este proceso de recopilación de evidencias, tendrá que hacer uso de su ToolKit, pero como se indicó anteriormente, deberá tener precaución pues el atacante aún puede
estar fisgoneando por sus sistemas. Con un buen entrenamiento será capaz de recopilar toda
esta información con un número de comandos mínimo, haciendo su labor casi desapercibida,
incluso sería recomendable que tuviese preparado un script en Perl para sistemas UNIX/Linux
o un archivo de proceso por lotes para entornos Windows que realizase todas estas operaciones de forma automatizada y que, además, enviase la información a un lugar seguro.
Y ahora viene otra cuestión , a la hora de recopilar estas evidencias volátiles, ¿dónde
las almacenamos?, ¿dónde está ese lugar seguro?. Las salidas de algunos comandos pueden
ocupar poco espacio, pero otros pueden generar tal cantidad de información que sea necesario el uso de medios de almacenamiento con una capacidad considerable (desde cientos de Mbytes hasta decenas de Gbytes). Una Opción interesante sería usar discos externos USB, muy
económicos y que le permiten gran flexibilidad de manejo y transporte de grandes cantidades
de información. Otra opción es emplear herramientas de transmisión de datos por la red tipo
netcat, que le permitiría enviar toda la información recopilada a un sistema seguro, como
por ejemplo un equipo conectado en la misma red o un portátil conectado directamente al sistema afectado.
En cualquier caso tenga en cuenta el siguiente consejo, NUNCA almacene la información volátil en el equipo comprometido con la idea de recuperarla más tarde para su análisis...
¡puede que ya no esté ahí cuando vuelva a buscarla!.
Tan pronto como haya obtenido toda la información volátil del sistema tendremos que
recopilar la información contenida en los discos duros, teniendo en cuenta que estos dispositivos no sólo contienen las particiones, los archivos, directorios, etc. Sino que también contienen otro tipo de datos que hacen referencia a los propios archivos y a flujos de información,
son los metadatos que serán de gran importancia en el análisis forense.
En este punto cabe hacer una aclaración muy importante, cuando se realiza una copia
de seguridad de un disco o soporte en general se procede a copiar los archivos tal cual el sistema operativo los “ve”, perdiéndose gran cantidad de información oculta en el disco. Por el
contrario si realizamos una imagen del disco, creamos una copia bit-a-bit del disco original
preservando toda la información que contenga, incluyendo los bloques de los ficheros eliminados, espacio libre tras cada bloque, inodos (metadatos), etc.
Como norma general, obtendremos siempre imágenes de los discos duros para su posterior análisis y, siempre sobre medios de sólo lectura.
Una de las herramientas más empleadas en entornos UNIX/Linux es dd, ésta permite
crear imágenes de discos bit-a-bit, además de ofrecer otras opciones como obtención del hash
MD5 de la copia, etc. Si además la combinamos con la herramienta netcat, podríamos
transferir las imágenes completas a través de la red.
