IDS en MS-CPC
Descripción de la protección de cookies SYN en un MS-CPC
La cookie SYN es un mecanismo de proxy SYN sin estado que puede usar junto con otras defensas contra un ataque de inundación SYN. La cookie SYN es compatible con la tarjeta multiservicios MS-CPC.
Al igual que con el proxy SYN tradicional, la cookie SYN se activa cuando se supera el umbral de ataque de inundación SYN. Sin embargo, dado que la cookie SYN no tiene estado, no configura una sesión ni una política ni búsquedas de ruta al recibir un segmento SYN, y no mantiene colas de solicitud de conexión. Esto reduce drásticamente el uso de CPU y memoria y es la principal ventaja de usar la cookie SYN sobre el mecanismo tradicional de proxy SYN.
Cuando la cookie SYN está habilitada en Junos OS y se convierte en el proxy de negociación TCP para el servidor de destino, responde a cada segmento SYN entrante con un SYN/ACK que contiene una cookie cifrada como su número de secuencia inicial (ISN). La cookie es un hash MD5 de la dirección de origen original y el número de puerto, la dirección de destino y el número de puerto, y el ISN del paquete SYN original. Después de enviar la cookie, Junos OS descarta el paquete SYN original y elimina la cookie calculada de la memoria. Si no hay respuesta al paquete que contiene la cookie, el ataque se anota como un ataque SYN activo y se detiene efectivamente.
Si el host iniciador responde con un paquete TCP que contiene la cookie +1 en el campo ACK TCP, Junos OS extrae la cookie, resta 1 del valor y vuelve a calcular la cookie para validar que es una ACK legítima. Si es legítimo, Junos OS inicia el proceso de proxy TCP configurando una sesión y enviando un SYN al servidor que contiene la información de origen del SYN original. Cuando Junos OS recibe un SYN/ACK del servidor, envía ACK al servidor y al host de iniciación. En este punto, se establece la conexión y el host y el servidor pueden comunicarse directamente.
El uso de la cookie SYN o del proxy SYN permite que el dispositivo del enrutador proteja los servidores TCP detrás de él de ataques de inundación SYN en flujos IPv6.
La figura 1 muestra cómo se establece una conexión entre un host iniciador y un servidor cuando la cookie SYN está activa en Junos OS.
Configuración de reglas de IDS en un MS-CPC
Las reglas de IDS configuradas con un MS-CPC identifican el tráfico para el que desea que el software del enrutador cuente eventos. Dado que IDS se basa en propiedades de firewall con estado, debe configurar al menos una regla de firewall con estado e incluirla en el conjunto de servicios con las reglas de IDS; Para obtener más información, consulte Configurar reglas de firewall de inspección de estado.
Para configurar la protección contra ataques de red con una MS-MPC, consulte Configurar la protección contra ataques de red en una MS-MPC.
Para configurar una regla de IDS, incluya la rule rule-name instrucción en el nivel de [edit services ids] jerarquía:
[edit services ids] rule rule-name { match-direction (input | output | input-output); term term-name { from { application-sets set-name; applications [ application-names ]; destination-address (address | any-unicast) <except>; destination-address-range low minimum-value high maximum-value <except>; destination-prefix-list list-name <except>; source-address (address | any-unicast) <except>; source-address-range low minimum-value high maximum-value <except>; source-prefix-list list-name <except>; } then { aggregation (IDS) { destination-prefix prefix-value | destination-prefix-ipv6 prefix-value; source-prefix prefix-value | source-prefix-ipv6 prefix-value; } (force-entry | ignore-entry); logging { syslog; threshold rate; } session-limit { by-destination (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-pair (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-source (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } } syn-cookie { mss value; threshold rate; } } } }
Cada regla de IDS consta de un conjunto de términos, similar a un filtro configurado en el [edit firewall] nivel de jerarquía. Un término consiste en lo siguiente:
frominstrucción: especifica las condiciones de coincidencia y las aplicaciones que se incluyen y excluyen.theninstrucción: especifica las acciones y los modificadores de acción que debe realizar el software del enrutador.
En las siguientes secciones se describe el contenido de la regla de IDS con más detalle:
- Configuración de la dirección de coincidencia para las reglas de IDS
- Configuración de condiciones de coincidencia en reglas de IDS
- Configuración de acciones en reglas de IDS
Configuración de la dirección de coincidencia para las reglas de IDS
Cada regla debe incluir una match-direction instrucción que especifique si la coincidencia se aplica en el lado de entrada o de 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:
[edit services ids rule rule-name] match-direction (input | output | input-output);
Si configura match-direction input-output, la creación de reglas bidireccionales es .
La dirección de coincidencia se utiliza con respecto al flujo de tráfico a través del AS o la PIC de multiservicios. Cuando se envía un paquete a la PIC, la información de dirección se transporta 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 servicio de salto siguiente, la dirección del paquete viene determinada por la interfaz usada para enrutar el paquete al AS o a la PIC de multiservicios. Si se usa la interfaz interna para enrutar el paquete, se ingresa la dirección del paquete. Si se utiliza la interfaz externa para dirigir el paquete a la PIC, se emite la dirección del paquete. Para obtener más información sobre las interfaces internas y externas, consulte Configuración de conjuntos de servicios que se aplicarán a interfaces de servicios.
En el AS o en la PIC de multiservicios, se realiza una búsqueda de flujo. Si no se encuentra ningún flujo, se procesa la regla. 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 direcciones de las reglas. Solo se tienen en cuenta las reglas con información de dirección que coincida con la dirección del paquete.
Configuración de condiciones de coincidencia en reglas de 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:
[edit services ids rule rule-name term term-name] from { application-sets set-name; applications [ application-names ]; destination-address (address | any-unicast) <except>; destination-address-range low minimum-value high maximum-value <except>; destination-prefix-list list-name <except>; source-address (address | any-unicast) <except>; source-address-range low minimum-value high maximum-value <except>; source-prefix-list list-name <except>; }
Si omite la from instrucción, el software acepta todos los eventos y los coloca en la caché de IDS para su procesamiento.
La dirección de origen y la dirección de destino pueden ser IPv4 o IPv6. Puede utilizar 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 políticas de enrutamiento, filtros de firewall y agentes de policía 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 de jerarquía y, luego, incluyendo la destination-prefix-list instrucción or source-prefix-list en la regla de IDS. Para obtener un ejemplo, consulte Ejemplos: configuración de reglas de firewall de inspección de 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 Configurar propiedades de la[edit applications] aplicación.
Para aplicar una o varias definiciones de protocolo de aplicación específicas, incluya la
applicationsinstrucció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-setsinstrucció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 jerárquico; no puede especificar estas propiedades como condiciones de coincidencia.
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 de 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:
[edit services ids rule rule-name term term-name] then { aggregation (IDS) { destination-prefix prefix-value | destination-prefix-ipv6 prefix-value; source-prefix prefix-value | source-prefix-ipv6 prefix-value; } (force-entry | ignore-entry); logging { syslog; threshold rate; } session-limit { by-destination (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-pair (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-source (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } } syn-cookie { mss value; threshold rate; } }
Puede configurar las siguientes acciones posibles:
aggregation: el enrutador agrega el tráfico etiquetado con los prefijos de origen o destino especificados antes de pasar los eventos al procesamiento de IDS. Esto resulta útil si desea examinar todo el tráfico conectado con un host de origen o destino determinado. Para recopilar tráfico con algún otro marcador, como una aplicación o un puerto determinados, configure ese valor en las condiciones de coincidencia.Para configurar prefijos de agregación, incluya la
aggregationinstrucción en el nivel de[edit services ids rule rule-name term term-name then]jerarquía y especifique valores parasource-prefix,destination-prefix source-prefix-ipv6odestination-prefix-ipv6:[edit services ids rule rule-name term term-name then] aggregation (IDS) { destination-prefix prefix-value | destination-prefix-ipv6 prefix-value; source-prefix prefix-value | source-prefix-ipv6 prefix-value; }
El valor de
source-prefixydestination-prefixdebe ser un número entero entre 1 y 32. El valor desource-prefix-ipv6ydestination-prefix-ipv6debe ser un número entero entre 1 y 128.(force-entry | ignore-entry):force-entryproporciona un lugar permanente en las cachés de IDS para eventos posteriores después de que se registre un evento. De forma predeterminada, el software IDS no registra información sobre paquetes "buenos" que no muestren un comportamiento sospechoso. Puede utilizar la instrucción para registrar todo el tráfico de un host sospechoso, incluso elforce-entrytráfico que de otro modo no se contaría.ignore-entrygarantiza que se ignoren todos los eventos de 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ía como eventos.Para configurar un comportamiento de entrada diferente del predeterminado, incluya la
force-entryinstrucción orignore-entryen el nivel de[edit services ids rule rule-name term term-name then]jerarquía:[edit services ids rule rule-name term term-name then] (force-entry | ignore-entry);
logging: el evento se registra en el archivo de registro del sistema.Para configurar el registro, incluya la
logginginstrucción en el nivel de[edit services ids rule rule-name term term-name then]jerarquía:[edit services ids rule rule-name term term-name then] logging { syslog; threshold rate; }
Opcionalmente, puede incluir una tasa de umbral para activar la generación de mensajes de registro del sistema. La velocidad umbral se especifica en eventos por segundo. Los registros de IDS se generan una vez cada 60 segundos por 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-limitinstrucción en el nivel de[edit services ids rule rule-name term term-name then]jerarquía:[edit services ids rule rule-name term term-name then] session-limit { by-destination (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-pair (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } by-source (IDS MS-DPC) { hold-time seconds; maximum number; packets number; rate number; } }
Puede configurar los umbrales para la limitación de flujo 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-sourceinstrucción.Para limitar el número de sesiones entre un par de direcciones IP, subredes o aplicaciones, configure la
by-pairinstrucción.Para limitar el número de sesiones entrantes a una dirección IP pública externa o a una subred, configure la
by-destinationinstrucción.
Para cada dirección, puede configurar los siguientes valores de umbral:
hold-time seconds: cuando laratemedición opacketsalcance el valor umbral, detenga todos los flujos nuevos durante el número de segundos especificado. Una vezhold-timeque está en vigor, el tráfico se bloquea durante el tiempo especificado, incluso si la velocidad disminuye por debajo del límite especificado. De forma predeterminada,hold-timetiene un valor de 0; el intervalo va 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.1y10.1.1.2), no 20 conexiones en total. La misma lógica se aplica a las condiciones yapplicationsdestination-addresscoincidir.[edit services ids rule rule-name term term-name] from { source-address 10.1.1.1; source-address 10.1.1.2; } then { session-limit by-source { maximum 20; } }Nota:Los límites de IDS se aplican a los paquetes aceptados por las reglas de firewall con estado. No se aplican a los paquetes descartados o rechazados por reglas de firewall con estado. Por ejemplo, si el firewall con estado acepta el 75 % del tráfico entrante y el 25 % restante se rechaza o descarta, el límite de IDS se aplica solo al 75 % del tráfico.
syn-cookie: el enrutador activa los mecanismos defensivos de las cookies SYN.Para configurar los valores de SYN-cookie, incluya la
syn-cookieinstrucción en el nivel de[edit services ids rule rule-name term term-name then]jerarquía:[edit services ids rule rule-name term term-name then] syn-cookie { mss value; threshold rate; }
Si habilita las defensas de cookies SYN, debe incluir una velocidad de umbral para activar la actividad de cookies SYN y un valor de tamaño máximo de segmento (MSS) del Protocolo de control de transmisión (TCP) para el enlace retardado de TCP. La velocidad 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 de SYN y protección de cookies de 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 (sincronizar número de secuencia) es la primera solicitud de conexión enviada a un sistema. El paquete SYN contiene un ID al que el receptor debe responder. 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. Finalmente, se agota el tiempo de espera de esta conexión semiabierta 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 bloqueadas esperando 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, dado que utiliza direcciones IP o de puerto de destino legítimas, es prácticamente imposible distinguirlos de los paquetes legítimos. Por lo tanto, es muy difícil prevenir este tipo de ataque utilizando únicamente filtros o reglas de firewall con estado. Básicamente, solo hay tres métodos para protegerse de este tipo de ataque:
Intercepción (enlace retardado): 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 fusiona las dos conexiones de forma transparente. Por lo general, el firewall tiene 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 de forma pasiva las conexiones entreabiertas y las cierra activamente 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 solicita una conexión debe responder con la cookie para conectarse a un socket TCP abierto mientras el IDS detecta 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 de cookie y vigilancia SYN (defensa SYN). La clave del ataque de inundación SYN es llenar la cola SYN de la víctima o del elemento de red atacado. El método de defensa de cookies SYN permite a la víctima continuar aceptando solicitudes de conexión cuando la cola SYN está llena o, en el caso de las aplicaciones de firewall o IDS, cuando se ha alcanzado un cierto 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 el 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. Dado que los clientes falsificados de la inundación SYN nunca envían ACK, no se les asignan recursos en ningún estado cuando se utilizan cookies SYN. Es preferible que use 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 pueden 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, el trayecto general es un factor importante que debe tenerse en cuenta en las direcciones directa e inversa. Esto es especialmente cierto cuando TDR se implementa para determinar si se debe usar la dirección pre-TDR o post-TDR para hacer coincidir una regla. En la ruta de avance de una interfaz LAN a una interfaz WAN, primero se realizan IDS y firewall con estado, luego TDR y finalmente IPSec. Esta secuencia de procesamiento de servicios indica que el firewall con estado debe coincidir en una dirección pre-TDR, mientras que el túnel IPSec coincide en la dirección post-TDR. En la ruta de retorno, primero se procesa el paquete IPSec, luego el TDR y, por último, el firewall de estado. Este orden de procesamiento sigue permitiendo 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, TDR e IDS. El procesamiento de paquetes se vuelve mucho más complicado cuando IPSec a través de 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 de 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 la cantidad 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 (DPI) no admite firmas de aplicación de capa superior, un enfoque eficaz contra los ataques es que se pueda configurar la protección contra un ataque SYN. La solución DPI es en gran medida una herramienta de monitoreo y no una herramienta de prevención esencial. Para evitar un ataque SYN, el enrutador funcionará como un tipo de "proxy" SYN y utilizará valores de cookies. 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 una cookie incorrecta, se elimina el flujo. Para activar esta defensa, debe configurar un umbral de cookie SYN. Para habilitar la defensa de cookies SYN, una acción de regla de IDS debe contener un umbral que indique cuándo se debe habilitar la función y un valor MSS para evitar que el enrutador administre fragmentos segmentados cuando actúa como proxy SYN:
[edit] user@host# set services ids rule simple-ids term 1 then syn-cookie
Configuración de conjuntos de reglas de IDS en un MS-CPC
Puede utilizar rule-set una instrucción para definir una colección de reglas de IDS que determinan qué acciones realiza el software del enrutador en los paquetes del flujo de datos. Esto es compatible con la tarjeta multiservicios MS-CPC. (Para configurar la protección contra ataques contra ataques de red con una MS-MPC, consulte Configurar la protección contra ataques de red en una MS-MPC.)
Para definir cada regla, se especifica un nombre de regla y se configuran términos. A continuación, especifique el orden de las reglas incluyendo la rule-set instrucción en el [edit services ids] nivel de jerarquía con una rule instrucción para cada regla:
[edit services ids] rule-set rule-set-name { rule rule-name; }
El software del enrutador procesa las reglas en el orden en que se especifican en la configuración. Si un término de una regla coincide con el paquete, el enrutador realiza la acción correspondiente y el procesamiento de la regla se detiene. Si ningún término de una regla coincide con el paquete, el procesamiento continúa con la siguiente regla del conjunto de reglas. Si ninguna de las reglas coincide con el paquete, este se descarta de forma predeterminada.
Ejemplos: Configuración de reglas de IDS en un MS-CPC
La siguiente configuración agrega una entrada permanente a la tabla de anomalías de IDS cuando encuentra un flujo con la dirección de destino 10.410.6.2. Este ejemplo es compatible con la tarjeta multiservicios MS-CPC. (Para configurar la protección contra ataques contra ataques de red con una MS-MPC, consulte Configurar la protección contra ataques de red en una MS-MPC.)
[edit services ids]
rule simple_ids {
term 1 {
from {
destination-address 10.410.6.2/32;
}
then {
force-entry;
logging {
threshold 1;
syslog;
}
}
}
term default {
then {
aggregation {
source-prefix 24;
}
}
}
match-direction input;
}
La configuración de IDS funciona junto con el mecanismo de firewall con estado y depende en gran medida de las anomalías notificadas por el firewall con estado. En el siguiente ejemplo de configuración se muestra esta relación:
[edit services ids]
rule simple_ids {
term 1 {
from {
source-address 10.30.20.2/32;
destination-address {
10.30.10.2/32;
10.30.1.2/32 except;
}
applications appl-ftp;
}
then {
force-entry;
logging {
threshold 5;
syslog;
}
syn-cookie {
threshold 10;
}
}
}
match-direction input;
}
[edit services stateful-firewall]
rule my-firewall-rule {
match-direction input-output;
term term1 {
from {
source-address 10.30.20.2/32;
applications appl-ftp ;
destination-address {
10.30.10.2/32;
10.30.1.2/32 except;
}
}
then {
accept;
syslog;
}
}
}
El firewall con estado o servicio TDR se utiliza para generar los datos de entrada para la aplicación IDS. Cuando habilite y configure un servicio IDS, también debe habilitar el firewall con estado con al menos una regla (aceptar o descartar todo el tráfico). Cuando el sistema está bajo un ataque, el firewall con estado envía la lista correcta y completa de eventos de ataque al sistema IDS. En su entorno de red, puede asegurarse de que el sistema está totalmente protegido contra una amplia gama de ataques para que el sistema IDS informe de todos esos ataques. Debe tener cuidado al configurar el sistema para que esté protegido de todos los ataques y escenarios de acceso no autenticados, de modo que el ancho de banda de tráfico que maneja el sistema no se vea sobrecargado. También es importante verificar la correlación entre los mensajes syslog del firewall correspondientes a las tablas de ataques e IDS. Las tablas IDS deben tener el mismo número de anomalías o errores o ligeramente menor en comparación con los mensajes syslog basados en firewall. Puede utilizar los comandos show adecuados para mostrar las tablas IDS.
Una regla de firewall con estado predeterminada puede ser tan simple como permitir el inicio de la conexión solo desde la interfaz interna a la externa y descartar todos los demás paquetes. Sin embargo, en un entorno de red real, las reglas son generalmente más complejas, como configurar solo una determinada unidad tributaria que deben abrirse puertos, usar puertas de enlace de capa de aplicación (ALG) para protocolos complicados y usar TDR tanto para conexiones salientes como para hosts internos, como servidores HTTP. Por lo tanto, también es necesario configurar el sistema según sea necesario para interactuar con reglas simples y complicadas. Por ejemplo, si un ataque SYN se dirige hacia una dirección interna que simplemente se descarta, no es necesario informar de ninguna anomalía al sistema IDS. Pero si el ataque SYN se dirige hacia el servidor HTTP real, se deben informar las anomalías. El sistema IDS puede mitigar los ataques SYN mediante el uso de la capacidad de defensa de cookies TCP SYN. Puede habilitar la metodología de protección de cookies SYN estableciendo un umbral para SYN por segundo para un host determinado y también un tamaño máximo de segmento (MSS). Dado que el sistema IDS utiliza el firewall con estado, se debe definir una regla de firewall en el conjunto de servicios. Si no configura la from instrucción en un firewall con estado (condición de coincidencia de términos de regla) en el [edit services service-set service-set-name stateful-firewall-rules rule-name term term-name] nivel de jerarquía, significa que todos los eventos se colocan en la caché de IDS.
En el siguiente ejemplo, se muestra la configuración de los límites de flujo:
[edit services ids]
rule ids-all {
match-direction input;
term t1 {
from {
application-sets alg-set;
}
then {
aggregation {
destination-prefix 30; /* IDS action aggregation */
}
logging {
threshold 10;
}
session-limit {
by-destination {
hold-time 0;
maximum 10;
packets 200;
rate 100;
}
by-pair {
hold-time 0;
maximum 10;
packets 200;
rate 100;
}
by-source {
hold-time 5;
maximum 10;
packets 200;
rate 100;
}
}
}
}
}