La importancia de los registros de sistema

Habitualmente, todos los profesionales que nos dedicamos en mayor o menor medida a la seguridad nos vemos en la necesidad de gestionar incidentes de seguridad; para ello, nuestra mayor fuente de información suelen ser los registros o logs de los sistemas implicados, tanto a nivel de comunicaciones (routers, cortafuegos, IDS, etc) como a nivel de sistema (Unix, Windows, Linux, etc.) y de aplicación (servidor web, servidor de correo, etc.). Desgraciadamente, es habitual que cuando el potencial cliente ha contactado con nosotros, su personal técnico, siempre con buena intención, haya realizado acciones que invalidan parcial o incluso totalmente los registros y con ello cualquier vía de investigación: formateo de servidores, borrado de logs, limpieza manual de entradas, etc. Como es natural, esto limita sensiblemente la información del incidente que se puede obtener, por lo que es imprescindible que no se lleven a cabo acciones que puedan modificar «la escena del crimen», casi de la misma manera que puede verse en una película policíaca. No obstante, dejemos eso para una entrada sobre análisis forense y pasemos al análisis de los registros.

A la hora de analizar estos logs nos encontramos principalmente dos problemas. El primero es su fiabilidad ya que ante un sistema comprometido, es inevitable preguntarse: ¿cómo de fiables son nuestros registros?, puesto que probablemente hayan sido alterados o borrados. El segundo problema tiene mucho que ver con la correlación temporal de la información contenida en los registros implicados en el incidente, generando preguntas del tipo: ¿las fechas de los diferentes sistemas se encuentran sincronizadas? ¿Qué sucedió antes y qué después? ¿De qué volumen de logs del incidente dispongo? ¿Hasta cuándo puedo retroceder?

Para el primero de los problemas la opción más habitual es contar con un sistema syslog que reciba los registros de los diferentes sistemas y dispositivos de red distribuidos por la organización, ubicado en un servidor que haya sido convenientemente securizado, limitando el número de servicios que ofrece y controles de acceso, entre otros. Esto permite tener la relativa seguridad de que la información que estamos manejando en la gestión de incidente es veraz. Además, tener los registros duplicados en el sistema de origen y en el servidor syslog permite a posteriori comparar ambos, y detectar así posibles modificaciones que proporcionen información sobre el atacante. Aunque este tipo de configuraciones son relativamente comunes en entornos donde hay mayoría de sistemas Unix/Linux, es raro encontrarlas en entornos Wintel, aunque las ventajas son similares.

En relación con la correlación de registros en el análisis del incidente, es vital que podamos determinar el orden de los acontecimientos, razón por la que el objetivo de control 10.10 Monitorización de la norma ISO 27001 requiere la existencia de un servidor NTP de sincronización que asegure que las fechas de los registros guardan un orden real; de lo contrario, en un entorno que los sistemas y dispositivos de red están no sincronizados en un rango de unos pocos minutos, la reconstrucción puede ser para volverse loco. También para este aspecto un sistema syslog es muy útil, ya que ordena de manera automática los mensajes recibidos de los distintos agentes.

Si no se dispone de un servidor syslog (o éste se limita a recibir la información de los dispositivos de red, dejando fuera los sistemas) y el volumen de información es reducido, la correlación de eventos se puede llevar a cabo de forma manual, aunque lo habitual es usar herramientas de correlacion de logs o alertas que nos permitan obtener información concreta en el menor tiempo posible, aspecto crítico en la gestión de incidentes. Esto no evitará que tengamos que revisar los logs con más detalle posteriormente, ya que aparte de obtener información adicional podría ser necesario presentar una denuncia antes las autorizades competentes, pero sí que facilita y acelera la puesta en marcha de las acciones necesarias para reducir el impacto del incidente en los primeros momentos. Con sistemas automatizados de detección, correlación y alerta, sería posible según los patrones configurados y por lo tanto, potencialmente detectables, anticiparnos al incidente; por ejemplo, pensemos en un ataque externo ocasionado por un nuevo gusano, cuyos patrones de conducta están reportados y de los que existen reglas para detectarlo o filtrarlo en nuestros sistemas (IDS/IPS).

Una visión global de estos aspectos es la que proporciona el proyecto Dshield junto con el Internet Storm Center de Sans Institute. A través de este proyecto, es posible enviar los logs de nuestros sistemas para detectar patrones globales de ataques futuros, formando de este modo un sistema de detección de intrusos distribuido a nivel global, que categoriza las amenazas en 4 niveles: verde, amarillo, naranja y rojo, dependiendo de su impacto potencial. Para evitar proporcionar información sensible al proyecto, como podrían ser las direcciones IP que están siendo atacadas, lo cual podría ocasionar posibles pérdidas para las empresas objetivos del ataque (daño a la imagen corporativa, desconfianza de clientes, etc), dependiendo del tipo de sistema, es posible enmascarar dichas direcciones, de forma que se puede ocultar total o parcialmente la dirección IP. El proyecto dispone de un gran listado de sistemas que soportan el envío de logs al sistema de correlación de forma más o menos automatizada, entre los cuales podemos encontrar dispositivos de grandes fabricantes como Cisco o CheckPoint. Una vez analizados y correlados los logs recibidos, es posible obtener las alertas generadas por el Storm Center, como por ejemplo un listado de direcciones IP potencialmente atacantes, para filtrarlas en nuestros sistemas.

Para finalizar, debemos tener en cuenta que ni el proyecto Dshield, ni el ISC de Sans, ni una correcta gestión de registros garantizan la protección de nuestra red, pero sí que constituyen mecanismos adicionales de reducción de riesgos. Y ya saben que todo suma.

(Entrada elaborada conjuntamente con Manuel Benet)

Comments

  1. Buena entrada, pero sobretodo muy bien explicado. No hay nada como un HIDS + NIDS combinado con un sistema de monitorización 8).