HIDS: IDS de nodo
Los IDS de nodo, HIDS, monitorizan la actividad del sistema al que tratan de proteger. Son aplicaciones instaladas en cada uno de los nodos que desean proteger. Pueden estar ejecutándose continuamente en segundo plano, ejecutarse periódicamente, o bajo demanda.
La monitorización supone una o varias tareas complementarias: detectar cambios en el sistema de ficheros, análisis de registros y detección de rootkits y software malicioso en general.
Detección de cambios en sistemas de ficheros
La detección de cambios en el sistema de ficheros sigue un proceso con los siguientes pasos:
- Creación de la base de datos de referencia. Durante la instalación o configuración inicial se crea una base de datos que recoge una instantánea del sistema de ficheros en la que se incluye el listado de ficheros y directorios, información sobre sus atributos (permisos, tamaño, fechas de acceso, modificación y cambio...), y uno o varios resúmenes criptográficos (hashes) de su contenido.
- Detección de cambios. Se recorre de nuevo el sistema de ficheros y se compara la situación en ese momento con lo almacenado en la base de datos, generando un informe que recoje todos los cambios detectados. Nótese que este mecanismo no crea una traza de actividades, por lo que un fichero que es creado depués de crear la base de datos de referencia y borrado antes de la detección de cambios no aparecerá en el informe. No obstante, tanto la creación como la eliminación de objetos en un directorio supone la modificación de dicho directorio, y esta modificación sí aparecerá reflejada.
- Actualización de la base de datos de referencia. Es un proceso en el que se crea una nueva base de datos de referencia y se compara con la anterior, generando un informe con todas las diferencias entre ellas. Los cambios deben ser revisados cuidadosamente y, una vez confirmado que son todos lícitos se procede a usar como referencia la nueva base de datos. La finalidad de este proceso es dar por buenos ciertos cambios realizados intencionadamente. Un buen ejemplo sería la actualización del sistema tras realizar cambios en la configuración o haber instalado actualizaciones de seguridad. Si no se actualiza la base de datos de referencia, en cada informe aparecerán todos estos cambios una y otra vez, con el peligro de que los cambios que indican actividad maliciosa pasen desapercibidos. Lógicamente, el punto crítico de la actualización es la comprobación de los cambios antes de dar por buena la nueva base de datos de referencia.
Un buen ejemplo de herramientas especializadas en la detección de cambios en el sistema de ficheros son Aide y Tripwire.
Análisis de registros
El análisis de registros consiste en el procesamiento automático de los registros del sistema y de las aplicaciones, descartando los mensajes inocuos y alertando de aquellas entradas relevantes para la seguridad.
Los registros del sistema suelen incluir actividad propia del sistema operativo, como conexiones y desconexiones de usuarios, cambios de usuario, ejecución de programas, arranque y parada de la máquina... Pero también suelen aglutinar mensajes de otros componentes como filtrado de paquetes, sistemas de ficheros distribuidos como NFS, servicios de acceso remoto como SSH... Por todo ello, es posible detectar actividades significativas para la seguridad de los sistemas como las siguientes: conexión (local o remota) del administrador, de la conexión de un usuario usando la consola del sistema (indica acceso físico, y puede ser significativo en el caso de servidores en un centro de datos, o cuando no es el usuario habitual de un ordenador portátil o de sobremesa), de la instalación de paquetes, de conexiones de red desde otros sistemas o hacia otros sistemas y, por supuesto, de intentos fallidos de todo lo anterior.
Aunque muchas aplicaciones envían su información al registro del sistema, otras generan y mantienen sus propios registros. Un ejemplo sería el servidor web Apache, que genera sus propios registros. En este caso la información lógicamente es específica de la aplicación, incluyendo, en el caso de un servidor web, información sobre páginas descargadas y errores al descargar. El HIDS puede estar diseñado para procesar este tipo de información (aplicación por aplicación) y, por tanto, ser capaz de alertar cuando se producen muchos intentos fallidos desde la misma IP o cuando se solicitan páginas que pueden indicar intentos de intrusión (por ejemplo, que intenten obtener acceso al fichero con la tabla de usuarios del sistema, "/etc/passwd").
Detección de rootkits
Los HIDS pueden incluir la capacidad de detectar las huellas que quedan tras un ataque con éxito. Habitualmente, el atacante trata de ocultar estas huellas y, al mismo tiempo, mantener su capacidad de acceso a la máquina. Para ello, lo habitual es que modifique el sistema realizando algunas de las siguientes acciones:
- Eliminar las entradas sospechosas de los registros del sistema, para dificultar la detección.
- Instalar versiones modificadas de ciertas herramientas del sistema, en particular las que listan componentes como procesos, conexiones de red, o ficheros y directorios. De esta forma, al inspeccionar el sistema no aparecerían elementos sospechosos, ya que estas versiones modificadas suelen ocultar solamente la actividad del atacante, por lo que los listados parecen correctos.
- Instalar algún tipo de puerta trasera que permita el acceso al sistema independientemente de su configuración. Por ejemplo, un servidor SSH que acepte el acceso como administrador usando una determinada contraseña establecida por el atacante (independientemente de la contraseña real del administrador del sistema).
- Modificar el núcleo del sistema operativo, normalmente añadiendo módulos que modifican el comportamiento de ciertas llamadas al sistema para ocultar la presencia del intruso. En este caso no es necesario modificar las herramientas del sistema, ya que éstas obtienen su información del núcleo del sistema.
Estos kits que ocultan las huellas y permiten mantener el acceso al sistema se denominan genéricamente rootkits. Lógicamente, la capacidad de detección dependerá del tipo de rootkit, ya que una vez modificado el núcleo del sistema operativo sería necesario arrancar de un sistema no infectado como, por ejemplo, un CD-ROM o un disco externo que tengan un sistema operativo de confianza.
Francisco Javier Cervigon Ruckauer
No hay comentarios:
Publicar un comentario