IDS en MS-DPC

Configuración de la dirección de coincidencia para reglas IDS

Cada regla debe incluir una match-direction instrucción que especifique si la coincidencia se aplica en el lado de entrada o salida de la interfaz. Para configurar dónde se aplica la coincidencia, incluya la match-direction (input | input-output | output) instrucción en el nivel de [edit services ids rule rule-name] jerarquía:

Si configura match-direction input-output, la creación de reglas bidireccionales es .

La dirección de coincidencia se usa con respecto al flujo de tráfico a través del AS o la PIC multiservicios. Cuando se envía un paquete al PIC, la información de dirección se lleva junto con él.

Con un conjunto de servicios de interfaz, la dirección del paquete viene determinada por si un paquete entra o sale de la interfaz en la que se aplica el conjunto de servicios.

Con un conjunto de servicios del próximo salto, la dirección del paquete viene determinada por la interfaz usada para enrutar el paquete al AS o a la PIC multiservicio. Si se utiliza la interfaz interna para enrutar el paquete, se ingresará la dirección del paquete. Si se utiliza la interfaz externa para dirigir el paquete a la PIC, se generará la dirección del paquete. Para obtener más información sobre las interfaces internas y externas, consulte Configuración de conjuntos de servicios para aplicarlos a interfaces de servicios.

En el AS o en la PIC multiservicios, se realiza una búsqueda de flujo. Si no se encuentra ningún flujo, se realiza el procesamiento de reglas. Se tienen en cuenta todas las reglas del conjunto de servicios. Durante el procesamiento de reglas, la dirección del paquete se compara con las instrucciones de la regla. Solo se consideran las reglas con información de dirección que coincida con la dirección del paquete.

Configuración de condiciones de coincidencia en reglas IDS

Para configurar condiciones de coincidencia de IDS, incluya la from instrucción en el nivel de [edit services ids rule rule-name term term-name] jerarquía:

Si omite la from instrucción, el software acepta todos los eventos y los coloca en la caché IDS para su procesamiento.

La dirección de origen y la dirección de destino pueden ser IPv4 o IPv6. Puede usar la dirección de destino, un rango de direcciones de destino, una dirección de origen o un rango de direcciones de origen como condición de coincidencia, de la misma manera que configuraría un filtro de firewall; para obtener más información, consulte la Guía del usuario de directivas de enrutamiento, filtros de firewall y políticas de tráfico.

Como alternativa, puede especificar una lista de prefijos de origen o destino incluyendo la prefix-list instrucción en el [edit policy-options] nivel jerárquico y, a continuación, incluyendo la destination-prefix-list instrucción o source-prefix-list en la regla IDS. Para obtener un ejemplo, consulte Ejemplos: Configuración de reglas de firewall con estado.

También puede incluir definiciones de protocolo de aplicación que haya configurado en el nivel de jerarquía; para obtener más información, consulte Configuración de propiedades de la[edit applications] aplicación.

• Para aplicar una o más definiciones de protocolo de aplicación específicas, incluya la applications instrucción en el nivel de [edit services ids rule rule-name term term-name from] jerarquía.

• Para aplicar uno o varios conjuntos de definiciones de protocolo de aplicación que haya definido, incluya la application-sets instrucción en el nivel de [edit services ids rule rule-name term term-name from] jerarquía.

  Nota:

  Si incluye una de las instrucciones que especifica los protocolos de aplicación, el enrutador deriva información de puerto y protocolo de la configuración correspondiente en el [edit applications] nivel de jerarquía; no puede especificar estas propiedades como condiciones coincidentes.

Si se produce una coincidencia en una aplicación, el protocolo de aplicación se muestra por separado en la salida del show services ids comando. Para obtener más información, consulte el Explorador de CLI.

Configuración de acciones en reglas IDS

Para configurar acciones de IDS, incluya la then instrucción en el nivel de [edit services ids rule rule-name term term-name] jerarquía:

Puede configurar las siguientes acciones posibles:

• aggregation: el enrutador agrega tráfico etiquetado con los prefijos de origen o destino especificados antes de pasar los eventos al procesamiento IDS. Esto es útil si desea examinar todo el tráfico relacionado con un host de origen o destino en particular. Para recopilar tráfico con algún otro marcador, como una aplicación o puerto determinado, configure ese valor en las condiciones de coincidencia.

  Para configurar prefijos de agregación, incluya la aggregation instrucción en el nivel de [edit services ids rule rule-name term term-name then] jerarquía y especifique valores para source-prefix, destination-prefix source-prefix-ipv6, o destination-prefix-ipv6:

  El valor de source-prefix y destination-prefix debe ser un número entero entre 1 y 32. El valor de source-prefix-ipv6 y destination-prefix-ipv6 debe ser un número entero entre 1 y 128.

• (force-entry | ignore-entry)—force-entry proporciona un lugar permanente en las memorias caché de IDS para eventos posteriores después de registrar un evento. De forma predeterminada, el software IDS no registra información sobre paquetes "buenos" que no presenten comportamientos sospechosos. Puede utilizar la instrucción para registrar todo el tráfico de un host sospechoso, incluso el force-entry tráfico que de otro modo no se contaría.

  ignore-entry garantiza que se ignoren todos los eventos IDS. Puede utilizar esta instrucción para ignorar todo el tráfico de un host de confianza, incluidas las anomalías temporales que, de otro modo, IDS contarían como eventos.

  Para configurar un comportamiento de entrada distinto del predeterminado, incluya la force-entry instrucción o ignore-entry en el nivel de [edit services ids rule rule-name term term-name then] jerarquía:

• logging: el evento se registra en el archivo de registro del sistema.

  Para configurar el registro, incluya la logging instrucción en el nivel de [edit services ids rule rule-name term term-name then] jerarquía:

  Opcionalmente, puede incluir una tasa de umbral para activar la generación de mensajes de registro del sistema. La tasa de umbral se especifica en eventos por segundo. Los registros IDS se generan una vez cada 60 segundos para cada anomalía que se notifica. Los registros se generan mientras los eventos continúen.

• session-limit: el enrutador limita las sesiones abiertas cuando se alcanza el umbral especificado.

  Para configurar un umbral, incluya la session-limit instrucción en el nivel de [edit services ids rule rule-name term term-name then] jerarquía:

  Los umbrales para la limitación de flujo se configuran en función de la dirección del tráfico:

  • Para limitar el número de sesiones salientes desde un host o subred interna, configure la by-source instrucción.

  • Para limitar el número de sesiones entre un par de direcciones IP, subredes o aplicaciones, configure la by-pair instrucción.

  • Para limitar el número de sesiones entrantes a una subred o dirección IP pública externa, configure la by-destination instrucción.

  Para cada dirección, puede configurar los siguientes valores de umbral:

  • hold-time seconds: cuando la rate medición o packets alcance el valor umbral, detenga todos los flujos nuevos durante el número de segundos especificado. Una vez hold-time que está en vigor, el tráfico se bloquea durante el tiempo especificado, incluso si la tasa disminuye por debajo del límite especificado. De forma predeterminada, hold-time tiene un valor de 0; el intervalo es de 0 a 60 segundos.

  • maximum number: número máximo de sesiones abiertas por dirección IP o subred por aplicación. El rango es de 1 a 32,767.

  • packets number: número máximo de paquetes por segundo (pps) por dirección IP o subred por aplicación. El rango es de 4 a 2,147,483,647.

  • rate number: número máximo de sesiones por segundo por dirección IP o subred por aplicación. El rango es de 4 a 32,767.

    Si incluye más de una dirección de origen en las condiciones de coincidencia configuradas en el nivel de [edit services ids rule rule-name term term-name from] jerarquía, se aplican límites para cada dirección de origen de forma independiente. Por ejemplo, la siguiente configuración permite 20 conexiones desde cada dirección de origen (10.1.1.1 y 10.1.1.2), no 20 conexiones en total. La misma lógica se aplica a las applications condiciones de coincidencia destination-address .

    Nota:

    Los límites de IDS se aplican a los paquetes aceptados por reglas de firewall con estado. No se aplican a paquetes descartados o rechazados por reglas de firewall de estado. Por ejemplo, si el firewall de estado acepta el 75 % del tráfico entrante y el 25 por ciento restante se rechaza o descarta, el límite de IDS solo se aplica al 75 % del tráfico.

• syn-cookie—El router activa los mecanismos defensivos de SYN-cookie.

  Para configurar los valores de SYN-cookie, incluya la syn-cookie instrucción en el nivel de [edit services ids rule rule-name term term-name then] jerarquía:

  Si habilita las defensas de cookies SYN, debe incluir una tasa de umbral para activar la actividad de cookies SYN y un valor de tamaño de segmento máximo (MSS) del Protocolo de control de transmisión (TCP) para el enlace retardado TCP. La tasa de umbral se especifica en ataques SYN por segundo. De forma predeterminada, el valor TCP MSS es 1500; El rango es de 128 a 8192.

  Manejo de ataques de inundación SYN y protección de cookies SYN

  El objetivo principal de un ataque de inundación SYN es consumir todas las conexiones de red nuevas en un sitio y, por lo tanto, evitar que los usuarios autorizados y legítimos puedan conectarse a los recursos de red. El paquete SYN (número de secuencia de sincronización) es la primera solicitud de conexión enviada a un sistema. El paquete SYN contiene un identificador al que debe responder el receptor. Si el paquete contiene un ID no válido, el sistema receptor recibe una confirmación de conexión cuando responde al iniciador de conexión previsto. Eventualmente, esta conexión semiabierta agota el tiempo de espera y el canal entrante en el receptor vuelve a estar disponible para manejar normalmente otra solicitud. Un ataque de inundación SYN envía tantas solicitudes de este tipo que todas las conexiones entrantes están continuamente atadas a la espera de confirmaciones que nunca se reciben. Esta condición hace que el servidor no esté disponible para los usuarios legales (excepto en los casos en que se establece una sesión de usuario cuando es exactamente en el momento en que se agota el tiempo de espera de una de las conexiones vinculadas). Un ataque de inundación SYN es un ataque sin conexión. No requiere una dirección IP de origen real y, debido a que utiliza direcciones IP o de puerto de destino legítimo, es prácticamente imposible distinguirlo de los paquetes legítimos. Por lo tanto, es muy difícil prevenir este tipo de ataque utilizando solo filtros o reglas de firewall con estado. Básicamente, solo hay tres métodos para protegerse de este tipo de ataque:

  • Intercepción (enlace diferido): el firewall intercepta las solicitudes de sincronización TCP entrantes y establece una conexión con el cliente en nombre del servidor y con el servidor en nombre del cliente. Si ambas conexiones se realizan correctamente, el firewall combina las dos conexiones de forma transparente. El firewall suele tener tiempos de espera agresivos para evitar que sus propios recursos sean consumidos por un ataque SYN. Esta es la solución más intensiva en términos de requisitos de procesamiento y memoria.

  • Vigilancia (defensa SYN): el firewall observa pasivamente las conexiones entreabiertas y cierra activamente las conexiones en el servidor después de un período de tiempo configurable.

  • Cookie SYN: las cookies SYN son opciones particulares para el número de secuencia TCP inicial elegido por el servidor TCP. Un host que solicite una conexión debe responder con la cookie para conectarse a un socket TCP abierto mientras el IDS ha detectado una inundación SYN como en curso.

  Los enrutadores de Juniper Networks admiten la combinación de firewall con estado y mecanismos IDS para admitir los métodos SYN cookie and watch (defensa SYN). La clave del ataque de inundación SYN es llenar la cola SYN de la víctima o el elemento de red atacado. El método de defensa contra cookies SYN permite a la víctima seguir aceptando solicitudes de conexión cuando la cola SYN está llena o, en el caso del firewall o de las aplicaciones IDS, cuando se ha alcanzado un determinado umbral. Una vez alcanzado el umbral, se crea una cookie criptográfica (un número de 32 bits) a partir de la información del segmento SYN y se elimina el segmento SYN. La cookie se utiliza como número de secuencia inicial en el SYN-ACK enviado al cliente. La cookie (más una) se devuelve al firewall o a la aplicación IDS como el número de confirmación en el ACK de un cliente legítimo. La cookie devuelta se puede validar y las partes más importantes del segmento SYN se pueden reconstruir a partir de la cookie, lo que permite establecer una conexión. Debido a que los clientes falsificados de la inundación SYN nunca envían ACK, no se asignan recursos para ellos en ningún estado cuando las cookies SYN están en uso. Es preferible que utilice contramedidas de inundación SYN solo para hosts bajo ataque. La tabla de anomalías se puede usar para un reconocimiento confiable de ataques o se puede habilitar dentro del firewall de estado. Este tipo de configuración también ayuda a prevenir el agotamiento de los recursos del sistema (especialmente la tabla de flujo) en caso de ataques.

  Cuando se combinan varios servicios, la ruta general es un factor importante a tener en cuenta en las direcciones de avance e retroceso. Esto es especialmente cierto cuando se implementa NAT para determinar si se debe usar la dirección pre-NAT o post-NAT para que coincida con una regla. En la ruta de reenvío desde una interfaz LAN a una interfaz WAN, primero se realizan IDS y firewall con estado, luego NAT y, finalmente, IPSec. Esta secuencia de procesamiento de servicios denota que el firewall con estado debe coincidir en una dirección pre-NAT, mientras que el túnel IPSec coincide en la dirección post-NAT. En la ruta de retorno, primero se procesa el paquete IPSec, luego NAT y, por último, el firewall con estado. Este orden de procesamiento aún permite que IPSec coincida con una dirección pública y que el firewall con estado coincida con una dirección privada. Debe configurar por separado los servicios de firewall, NAT e IDS. El procesamiento de paquetes se vuelve mucho más complicado cuando IPSec sobre GRE se implementa en el enrutador con otros servicios activados. Este comportamiento se produce porque Junos OS trata los paquetes GRE de una manera única después de la encapsulación GRE. Después de encapsular un paquete en un paquete GRE, se marca con una interfaz de entrada como la interfaz de salida del siguiente salto. Este método de marcado hace que los paquetes GRE se bloqueen si hay filtros de entrada o servicios de entrada que no permiten este servicio.

  Los servicios de Junos OS admiten un conjunto limitado de reglas IDS para ayudar a detectar ataques como el escaneo de puertos y anomalías en los patrones de tráfico. También admite cierta prevención de ataques al limitar el número de flujos, sesiones y velocidades. Además, protege contra ataques SYN mediante la implementación de un mecanismo de cookies SYN. Dado que el servicio de detección y prevención de intrusiones (IDP) no admite firmas de aplicaciones de capa superior, un enfoque eficaz contra ataques es que se pueda configurar la protección contra un ataque SYN. La solución para los desplazados internos es en gran medida una herramienta de monitoreo y no una herramienta de prevención esencial. Para evitar un ataque SYN, el router funcionará como un tipo de "proxy" SYN y utiliza valores de cookie. Cuando esta función está activada, el enrutador responde al paquete SYN inicial con un paquete SYN-ACK que contiene un valor de cookie único en el campo de número de secuencia. Si el iniciador responde con la misma cookie en el campo de secuencia, se acepta el flujo TCP; Si el respondedor no responde o si responde con la cookie incorrecta, el flujo se interrumpe. Para activar esta defensa, debe configurar un umbral de cookies SYN. Para activar la defensa contra cookies SYN, una acción de regla IDS debe contener un umbral que indique cuándo debe habilitarse la función y un valor MSS para evitar que el router gestione fragmentos segmentados cuando actúe como proxy SYN: