1. Necesidad de mecanismos adicionales en la prevención y protección
1.1. Fases de Ataque de un Intruso
1.1.1. Fase de vigilancia.
1.1.1.1. el atacante intentará aprender todo lo que pueda sobre la red que quiere atacar. En especial, tratará de descubrir servicios vulnerables y errores de configuración.
1.1.2. Fase de explotación de servicio.
1.1.2.1. permitirá al atacante hacerse con privilegios de administrador (escala de privilegios) abusando de alguna de las deficiencias encontradas
1.1.3. Fase de ocultación de huellas.
1.1.3.1. se realizará toda aquella actividad ejecutada por el atacante (una vez ya producida la intrusión) para pasar desapercibido en el sistema.
1.1.4. Fase de extracción de información.
1.1.4.1. el atacante con privilegios de administrador tendrá acceso a los datos de los clientes mediante la base de datos de clientes.
2. Escáners de vulnerabilidades
2.1. Los escáners de vulnerabilidades son un conjunto de aplicaciones que nos permitirán realizar pruebas o tests de ataque para determinar si una red o un equipo tiene deficiencias de seguridad que pueden ser explotadas por un posible atacante o comunidad de atacantes.
2.2. El funcionamiento general de un escáner de vulnerabilidades se podría dividir en tres etapas:
2.2.1. Durante la primera etapa se realiza una extracción de muestras del conjunto de atributos del sistema, para poder almacenarlas posteriormente en un contenedor de datos seguro.
2.2.2. En la segunda etapa, estos resultandos son organizados y comparados con, al menos, un conjunto de referencia de datos. Este conjunto de referencia podría ser una plantilla con la configuración ideal generada manualmente, o bien ser una imagen del estado del sistema realizada con anterioridad.
2.2.3. Finalmente, se generará un informe con las diferencias entre ambos conjuntos de datos.
2.3. A la hora de clasificar este tipo de herramientas encontramos básicamente dos categorías principales
2.3.1. Escáners basados en máquina
2.3.1.1. Este tipo de herramientas fue el primero en utilizarse para la evaluación de vulnerabilidades. Se basa en la utilización de información de un sistema para la detección de vulnerabilidades como, por ejemplo, errores en permisos de ficheros, cuentas de usuario abiertas por defecto, entradas de usuario duplicadas o sospechosas, etc.
2.3.1.1.1. Uno de los primeros escáners de vulnerabilidades en sistemas Unix fue COPS, una herramienta que se encargaba de analizar el sistema a la búsqueda de problemas de configuración típicos
2.3.1.1.2. Otra herramienta similar es TIGER su objetivo principal era el de informar de las distintas formas en las que puede comprometerse el sistema.
2.3.2. Escáners basados en red
2.3.2.1. Obtienen la información necesaria a través de las conexiones de red que establecen con el objetivo que hay que analizar.
2.3.2.1.1. Nessus es una herramienta basada en un modelo cliente-servidor que cuenta con su propio protocolo de comunicación. De forma similar a otros escáners de vulnerabilidades existentes, el trabajo correspondiente para explorar y probar ataques contra objetivos es realizado por el servidor de Nessus (nessusd), mientras que las tareas de control, generación de informes y presentación de los datos son gestionadas por el cliente (nessus).
2.3.2.2. Dos de las técnicas más utilizadas para la evaluación de vulnerabilidades basadas en red son las siguientes:
2.3.2.2.1. Métodos de inferencia. El sistema no explota vulnerabilidades, sino que busca indicios que indiquen posibilidades de ataque, tratando de detectar posibles deficiencias de seguridad en el objetivo.
2.3.2.2.2. Prueba por explotación. Esta técnica consiste en lanzar ataques reales contra el objetivo. Estos ataques están programados normalmente mediante guiones de comandos. En lugar de aprovechar la vulnerabilidad para acceder al sistema, se devuelve un indicador que muestra si se ha tenido éxito o no.
3. Sistemas de decepción
3.1. Los sistemas de decepción, en vez de neutralizar las acciones de los atacantes, utilizan técnicas de monitorización para registrar y analizar estas acciones, tratando de aprender de los atacantes.
3.2. A continuación trataremos de resumir distintas estrategias que se pueden emplear para la construcción de este tipo de sistemas.
3.2.1. Los equipos de decepción, también conocidos como tarros de miel o honeypots, son equipos informáticos conectados en que tratan de atraer el tráfico de uno o más atacantes. De esta forma, sus administradores podrán ver intentos de ataques que tratan de realizar una intrusión en el sistema y analizar cómo se comportan los elementos de seguridad implementados en la red.
3.2.2. Celdas de aislamiento, Mediante el uso de un dispositivo intermedio (con capacidades de detección y encaminamiento) todo el tráfico etiquetado como malicioso será dirigido hacia un equipo de decepción (conocido en este caso como celda de aislamiento).
3.2.3. Redes de decepción es la construcción de todo un segmento de red compuesto únicamente por equipos de decepción, preparados todos ellos para engañar a los intrusos (permitiendo su acceso sin demasiada dificultad).
4. Prevención de intrusos
4.1. Los sistemas de prevención de intrusos* son el resultado de unir las capacidad de bloqueo de los mecanismos de prevención (encaminadores con filtrado de paquetes y pasarelas) con las capacidades de análisis y monitoritación de los sistemas de detección de intrusos.
4.2. Atendiendo a la fuente de datos que utilicen, los sistemas de prevención de intrusos se podrían clasificar en las dos categorías que la mayor parte de los elementos de detección que hemos visto hasta ahora:
4.2.1. los sistemas de prevención de intrusos basados en equipo (HIPS) suelen utilizar aplicaciones instaladas directamente en la máquina que hay que proteger. Estas aplicaciones suelen estar muy relacionadas con el sistema operativo del sistema y sus servicios.
4.2.2. sistemas de prevención de intrusos basados en red, suelen ser dispositivos de red con al menos dos interfaces (una de monitorización interna y otra de monitorización externa), integrando en el mismo producto las capacidades de filtrado de paquetes y motor de detección.
4.3. A continuación haremos un breve repaso sobre los modelos existentes más relevantes para construir un sistema de prevención tal como acabamos de definir.
4.3.1. Sistemas de detección en línea, La mayor parte de los productos y dispositivos existentes para la monitorización y detección de ataques en red se basan en la utilización de dos dispositivos de red diferenciados. Por una parte, uno de los dispositivos se encarga de interceptar el tráfico de su segmento de red, mientras que el otro se utiliza para efectuar tareas de gestión y administración.
4.3.2. Conmutadores de nivel siete, Estos dispositivos se suelen utilizar para realizar tareas de balanceo de carga de una aplicación entre varios servidores. Para ello, examinan la información a nivel de aplicación (por ejemplo HTTP, FTP, DNS, etc.) para tomar decisiones de encaminamiento. Adicionalmente, estos mismos dispositivos podrán proporcionar protección frente a ataques contra las redes que conmutan como, por ejemplo, descartar tráfico procedente de una denegación de servicio.
4.3.3. Sistemas cortafuegos a nivel de aplicación, estos dispositivos se pueden configurar para analizar eventos tales como la gestión de memoria, las llamadas al sistema o intentos de conexión del sistema donde han sido instalados.
4.3.4. Conmutadores híbridos, La combinación de un sistema cortafuegos a nivel de aplicación junto con un conmutador de nivel siete permite reducir problemas de seguridad asociados a una programación deficiente, así como la posibilidad de detectar ataques a nivel de aplicación.
5. Sistemas de detección de intrusos
5.1. Conceptos Básicos
5.1.1. Una intrusión es una secuencia de acciones realizadas por un usuario o proceso deshonesto, con el objetivo final de provocar un acceso no autorizado sobre un equipo o un sistema al completo.
5.1.2. Los mecanismos para la detección de ataques e intrusiones tratan de encontrar y reportar la actividad maliciosa en la red, pudiendo llegar a reaccionar adecuadamente ante un ataque.
5.1.3. La detección de intrusiones es el proceso de identificación y respuesta ante las actividades ilícitas observadas contra uno o varios recursos de una red.
5.2. Antecedentes de los sistemas de detección de intrusos
5.2.1. Los sistemas de detección de intrusos son una evolución directa de los primeros sistemas de auditorias. Estos sistemas tenían como finalidad medir el tiempo que dedicaban los operadores a usar los sistemas. Con esta finalidad, se monitorizaban con una precisión de milésimas de segundo y servían, entre otras cosas, para poder facturar el servidor.
5.2.1.1. objetivos principales de un mecanismo de auditoría
5.2.1.1.1. Permitir la revisión de patrones de acceso (por parte de un objeto o por parte de un usuario) y el uso de mecanismos de protección del sistema.
5.2.1.1.2. Permitir el descubrimiento tanto de intentos internos como externos de burlar los mecanismos de protección.
5.2.1.1.3. Permitir el descubrimiento de la transición de usuario cuando pasa de un nivel menor de privilegios a otro mayor (escalada de privilegios).
5.2.1.1.4. Permitir el bloqueo de los intentos de los usuarios de saltarse los mecanismos de protección del sistema.
5.2.1.1.5. Servir de garantía frente a los usuarios de que toda la información que se recoja sobre ataques e intrusiones será suficiente para controlar los posibles daños ocasionados en el sistema.
5.2.2. Los sistemas de confianza son aquellos sistemas que emplean suficientes recursos software y hardware para permitir el procesamiento simultáneo de una variedad de información confidencial o clasificada. En estos sistemas se incluían distintos tipos de información repartida en niveles, que correspondían a su grado de confidencialidad.
5.2.3. Primeros sistemas para la detección de ataques en tiempo real
5.2.3.1. IDES utilizaba perfiles para describir los sujetos del sistema (principalmente usuarios), y reglas de actividad para definir las acciones que tenían lugar (eventos de sistema o ciclos de CPU). Estos elementos permitían establecer mediante métodos estadísticos las pautas de comportamiento necesarias para detectar posibles anomalías.
5.2.3.2. Discovery, capaz de detectar e impedir problemas de seguridad en bases de datos. La novedad del sistema radicaba en la monitorización de aplicaciones en lugar de analizar un sistema operativo al completo. Mediante la utilización de métodos estadísticos desarrollados en COBOL, Discovery podía detectar posibles abusos.
5.2.3.3. MIDAS fue uno de los primeros sistemas de detección de intrusiones conectados a internet. Fue publicado en la red en 1989 y monitorizó el mainframe Dockmaster en 1990, contribuyendo a fortalecer los mecanismos de autentificación de usuarios.
5.2.4. Sistemas de detección de intrusos actuales
5.2.4.1. fusión de los sistemas de detección basados en la monitorización del sistema operativo (y aplicaciones del sistema operativo) junto con sistemas distribuidos de detección de redes, capaces de monitorizar en grupo ataques e intrusiones a través de redes conectadas a internet.
5.3. Arquitectura general de un sistema de detección de intrusiones
5.3.1. En todos estos estudios se han realizado diferentes propuestas y diseños con el objetivo de cumplir los siguientes requisitos:
5.3.1.1. Precisión. Un sistema de detección de intrusos no debe que confundir acciones legítimas con acciones deshonestas a la hora de realizar su detección.
5.3.1.2. Eficiencia. El detector de intrusos debe minimizar la tasa de actividad maliciosa no detectada (conocida como falsos negativos). Cuanto menor sea la tasa de falsos negativos, mayor sera la eficiencia del sistema de detección de intrusos.
5.3.1.3. Rendimiento. El rendimiento ofrecido por un sistema de detección de intrusos debe ser suficiente como para poder llegar a realizar una detección en tiempo real. La detección en tiempo real responde a la detección de la intrusión antes de que ésta llegue a provocar daños en el sistema. Según los expertos, este tiempo debería de ser inferior a un minuto.
5.3.1.4. Escalabilidad. A medida que la red vaya creciendo (tanto en medida como en velocidad), también aumentara el número de eventos que deberá tratar el sistema. El detector tiene que ser capaz de soportar este aumento en el número de eventos, sin que se produzca pérdida de información
5.3.1.5. Tolerancia en fallos. El sistema de detección de intrusiones debe ser capaz de continuar ofreciendo su servicio aunque sean atacados distintos elementos del sistema incluyendo la situación de que el propio sistema reciba un ataque o intrusión).
5.3.2. IDWG, construcción de un marco de desarrollo genérico y se marca los siguientes objetivos:
5.3.2.1. Definir la interacción entre el sistema de detección de intrusos frente a otros elementos de seguridad de la red, como pueden ser los sistemas de prevención (cortafuegos, listas de control de accesos, ...).
5.3.2.2. Especificar el contenido de los mensajes intercambiados (eventos, alertas, . . . ) entre los distintos elementos del sistema. Por esto, proponen el formato IDMEF y el protocolo de intercambio de mensajes IDXP.
5.3.3. elementos necesarios para la construcción de un sistema para la detección de intrusos
5.3.3.1. Recolectores de información.
5.3.3.2. Procesadores de eventos.
5.3.3.3. Unidades de respuesta.
5.3.3.4. Elementos de almacenamiento.
5.4. Recolectores de información
5.4.1. Un recolector de información, también conocido como sensor, es el responsable de la recolección de información de los equipos monitorizados por el sistema de detección.
5.4.2. Existen diferentes formas de clasificar las posibles implementaciones de este componente. Detallamos a continuación tres de las propuestas más utilizadas.
5.4.2.1. El primer tipo, conocido como sensores basados en equipo, se encarga de analizar y recoger información de eventos a nivel de sistema operativo (como por ejemplo, intentos de conexión y llamadas al sistema).
5.4.2.2. En el segundo tipo encontramos sensores que recogen información de eventos sucedidos a nivel de tráfico de red (por ejemplo, analizando las cabeceras IP de todos los datagramas que pasan por la interfaz de red). Este tipo de componentes se conoce como sensores basados en red.
5.4.2.3. El tercer tipo, conocido como sensores basados en aplicación, recibe la información de aplicaciones que se están ejecutando, y podrían ser considerados como un caso especial de los sensores basados en equipo.
5.4.3. Elección de sensores
5.4.3.1. Actualmente, la mayoría de los sistemas de detección tratan de unificar las tres opciones, ofreciendo una solución de sensores híbrida.
5.4.3.1.1. Sensores basados en equipo y en aplicación. Los sensores basados en equipo y en aplicación podrán recoger información de calidad, además de ser fácilmente configurables y de poder ofrecer información de gran precisión.
5.4.3.1.2. Sensores basados en red. La principal ventaja de los sensores basados en red, frente a las otras dos soluciones, es la posibilidad de trabajar de forma no intrusiva. Por lo tanto, la recogida de información no afecta a la forma de trabajar de los equipos o a la propia infraestructura. Al no residir forzosamente en los equipos que hay que analizar, son más resistentes a sufrir ataques.
5.5. Procesadores de eventos
5.5.1. Los procesadores de eventos, también conocidos como analizadores, conforman el núcleo central del sistema de detección. Tienen la responsabilidad de operar sobre la información recogida por los sensores para poder inferir posibles intrusiones.
5.5.2. los analizadores deberán implementar algún esquema de detección.
5.5.2.1. Esquema de detección basado en usos indebidos
5.5.2.1.1. La detección de intrusiones basada en el modelo de usos indebidos cuenta con el conocimiento a priori de secuencias y actividades deshonestas. Los procesadores de eventos que implementan este esquema analizan los eventos en busca de patrones de ataque conocidos o actividad que ataque vulnerabilidades típicas de los equipos.
5.5.2.2. Esquema de detección basado en anomalías
5.5.2.2.1. Un perfil sirve como métrica (medida de un conjunto de variables) de comportamientos normales. Cualquier desviación que supere un cierto umbral respecto al perfil almacenado será tratado como una evidencia de ataque o intrusión.
5.6. Unidades de respuesta
5.6.1. Las unidades de respuesta de un sistema de detección se encargaran de iniciar acciones de respuesta en el momento en que se detecte un ataque o intrusión. Estas acciones de respuesta pueden ser automáticas (respuesta activa) o requerir interacción humana (respuesta passiva).
5.6.1.1. Las respuestas activas tienen como objetivo actuar contra el ataque, intentando su neutralización, en el momento en el que es detectado (o mientras una intrusión todavía continúa en curso).
5.6.1.2. las respuestas pasivas se limitan a lanzar una alarma para informar y describir el ataque detectado en el administrador del sistema. La mayoría de los componentes de respuesta pasiva ofrecen distintas formas de hacer llegar esta información al administrador
5.6.2. las unidades de respuesta se podrían clasificar en distintas categorías según el punto de actuación.
5.6.2.1. Unidades de respuesta basadas en equipo. Se encargan de actuar a nivel de sistema operativo (como, por ejemplo, bloqueo de usuarios, finalización de procesos, etc).
5.6.2.2. Unidades de respuesta basadas basadas en red. Actúan a nivel de red cortando intentos de conexión, filtrando direcciones sospechosas, etc.
5.7. Elementos de almacenamiento
5.7.1. Una posibilidad es la clasificación de la información en términos de análisis a corto y largo plazo.
5.7.1.1. En el caso de análisis a corto plazo, la información será almacenada directamente en los propios sensores (en buffers internos) de forma que después de realizar un procesado previo de los datos, y su transformación a un formato de evento, éstos sean transmitidos a los elementos de análisis.
5.7.1.2. En el caso de información a medio plazo, los datos preprocesados serán almacenados en dispositivos secundarios (con el formato apropiado) en lugar de ser transmitidos a los analizadores del sistema.
5.7.1.3. la información a medio plazo podrá continuar almacenada durante largos períodos de tiempo (del orden de meses o incluso años) a la espera de que pueda ser consultada por procesos de detección a largo plazo.
6. Detección de ataques distribuidos
6.1. Un ejemplo de este tipo de ataques son las denegaciones de servicio basadas en modelos master-slave que hemos descrito en el primer módulo de estos materiales.
6.2. las distintas propuestas que existen para poder poner en correspondencia los eventos recogidos en distintos equipos de la red, a fin de implementar una detección de ataques e intrusiones distribuida.
6.2.1. Esquemas tradicionales(Centralizado), Las primeras propuestas para extender la detección de ataques desde un equipo aislado hacia un conjunto de equipos tratan de unificar la recogida de información utilizando esquemas y modelos centralizados. Así, estas propuestas plantean la instalación de sensores en cada uno de los equipos que se desea proteger, configurados para poder retransmitir toda la información hacia un punto central de análisis.
6.2.2. Análisis descentralizado, Dado que los diferentes fragmentos de información que podrían delatar un ataque distribuido se pueden encontrar en cualquier equipo de la red, es realmente complicado poder llegar a paralelizar este procesado de información.
6.2.2.1. Dos de las propuestas existentes para implementar procesos descentralizados de análisis de información son:
6.2.2.1.1. Las propuestas basadas en código móvil para realizar una detección de ataques distribuidos utilizan el paradigma de agentes software para mover los motores de detección por la red que hay que vigilar (en forma de agente móvil).
6.2.2.1.2. Análisis descentralizado mediante paso de mensajes, estos nuevos elementos son estáticos y tan sólo necesitan una infraestructura común de paso de mensajes para realizar su proceso de detección descentralizado.