Descripción general de la protección de denegación de servicio distribuida (DDoS) del plano de control
Un ataque de denegación de servicio (DoS) es cualquier intento de denegar a usuarios válidos el acceso a los recursos de red o del servidor utilizando todos los recursos del elemento de red o del servidor. Los ataques de denegación de servicio distribuido (DDoS) implican un ataque de múltiples fuentes, lo que permite que una cantidad mucho mayor de tráfico ataque la red. Los ataques suelen utilizar paquetes de control de protocolo de red para desencadenar un gran número de excepciones en el plano de control del dispositivo. Esto da como resultado una carga de procesamiento excesiva que interrumpe las operaciones normales de red.
Con un único punto de administración de protección DDoS, los administradores de red pueden personalizar los perfiles para su tráfico de control de red. En el caso de los enrutadores, la protección y el monitoreo persisten en los cambios agraciados del motor de enrutamiento (GRES) y en la actualización unificada del software en servicio (ISSU). La protección no disminuye a medida que aumenta el número de suscriptores.
Policías de tráfico vinculados al host para infracciones de DDoS
Para proteger el plano de control contra ataques DDoS, los dispositivos tienen aplicadores de políticas habilitados de forma predeterminada para el tráfico dirigido al host. Si es necesario, puede modificar muchos valores predeterminados del aplicador de políticas. El tráfico dirigido al host es el tráfico destinado al motor de enrutamiento, incluidos los paquetes de control de protocolo para protocolos de enrutamiento, como OSPF y BGP. El tráfico destinado a las direcciones IP del enrutador también se considera tráfico vinculado al host.
Los aplicadores especifican límites de velocidad para todo el tráfico de control para un protocolo determinado o, en algunos casos, para tipos de paquetes de control específicos para un protocolo. Puede supervisar las acciones del aplicador de políticas para tipos de paquetes y grupos de protocolos a nivel del dispositivo, el motor de enrutamiento y las tarjetas de línea. También puede controlar el registro de eventos de policía.
Los dispositivos pierden el tráfico de control cuando supera los valores predeterminados o configurados del analizador. Cuando se produce una infracción de DDoS, el dispositivo no dejará de procesar paquetes; solo limita su tasa. Cada violación genera inmediatamente una notificación para alertar a los operadores sobre un posible ataque. El dispositivo cuenta la infracción y anota la hora en que comienza la infracción y la hora de la última infracción observada. Cuando la tasa de tráfico cae por debajo del umbral de infracción de ancho de banda, un temporizador de recuperación determina cuándo se considera que el flujo de tráfico ha vuelto a la normalidad. Si no se produce ninguna otra infracción antes de que caduque el temporizador, el dispositivo borrará el estado de infracción y generará una notificación.
En los enrutadores PTX y conmutadores de la serie QFX, el temporizador se establece en 300 segundos y no se puede modificar.
La primera línea de protección es el aplicador de políticas en el motor de reenvío de paquetes (PFE). En dispositivos con varias tarjetas de línea, los estados de la policía y las estadísticas de cada tarjeta de línea se retransmiten al motor de enrutamiento y se agregan. Los estados policiales se mantienen durante un cambio. Aunque las estadísticas de la tarjeta de línea y los recuentos de infracciones se conservan durante un cambio, las estadísticas del aplicador de políticas del motor de enrutamiento no lo son. El tráfico de control que llega desde todos los puertos de la tarjeta de línea converge en el motor de reenvío de paquetes, donde se vigila, eliminando el exceso de paquetes antes de que lleguen al motor de enrutamiento y asegurando que el motor de enrutamiento reciba solo la cantidad de tráfico que puede procesar.
Los enrutadores de la serie ACX que admiten esta característica solo admiten políticas agregadas y no admiten vigilancia a nivel de tarjeta de línea. Puede cambiar los valores predeterminados del aplicador en el nivel del motor de enrutamiento globalmente o para grupos de protocolos específicos, lo que se propaga hasta el nivel del chipset PFE. Sin embargo, no puede aplicar parámetros de escala adicionales a nivel de tarjeta de línea como en otros dispositivos. Puede deshabilitar la vigilancia en el nivel del motor de enrutamiento globalmente o para grupos de protocolos específicos. Al deshabilitar la vigilancia policial a nivel mundial, se deshabilita de manera efectiva la protección DDoS del plano de control en el dispositivo.
Los conmutadores de la serie QFX10000 y los enrutadores de la serie PTX imponen límites de protección DDoS en tres niveles: en el chipset PFE, la tarjeta de línea y el motor de enrutamiento.
Además de proporcionar notificación de infracciones mediante el registro de eventos, la protección DDoS del plano de control le permite supervisar a los policías, obteniendo información como la configuración del policía, el número de infracciones encontradas, la fecha y hora de las infracciones, las tasas de llegada de paquetes y la cantidad de paquetes recibidos o descartados.
Los policías de protección DDoS del plano de control actúan en las colas de tráfico del sistema. Las líneas de conmutadores QFX5100 y QFX5200 administran el tráfico para más protocolos que el número de colas, por lo que el sistema a menudo debe asignar más de un protocolo a la misma cola. Cuando el tráfico de un protocolo comparte una cola con otros protocolos y viola los límites de la policía de protección DDoS, estos dispositivos informan de una infracción en esa cola para todos los protocolos asignados porque el sistema no distingue qué tráfico del protocolo causó específicamente la infracción. Puede usar lo que sabe sobre los tipos de tráfico que fluyen a través de su red para identificar cuál de los protocolos reportados realmente desencadenó la infracción.
Soporte de plataforma
En Junos OS versión 14.2 y versiones posteriores, la protección DDoS del plano de control se admite en plataformas específicas. En general, algunos modelos de las siguientes plataformas tienen habilitada la protección DDoS del plano de control de forma predeterminada y admiten opciones de configuración para cambiar los parámetros predeterminados del aplicador de aplicaciones:
Enrutadores de la serie ACX.
Conmutadores EX9200.
Enrutadores serie MX que solo tienen MPC instalados.
Enrutadores de la serie MX con MPC integrado.
Nota:Para simplificar, cuando el texto se refiere a tarjetas de línea o controladores de tarjetas de línea, para estos enrutadores eso significa el MPC incorporado.
Debido a que estos enrutadores no tienen ranuras FPC, la información mostrada en
FPClos campos porshowcomandos en realidad se refiere a TFEB.Los enrutadores serie PTX que solo tienen instalados FPC basados en PE (PTX3000, PTX5000, PTX1000 y PTX10000) admiten la protección DDoS del plano de control a partir de Junos OS versión 17.4R1.
PTX10002 enrutadores admiten la protección DDoS del plano de control a partir de Junos OS versión 18.2R1.
PTX10003 enrutadores admiten la protección DDoS del plano de control a partir de Junos OS Evolved versión 19.3R1.
PTX10004 enrutadores admiten la protección DDoS del plano de control a partir de Junos OS Evolved versión 20.3R1.
PTX10008 enrutadores admiten la protección DDoS del plano de control a partir de Junos OS Evolved versión 20.1R1.
Conmutadores de la serie QFX, incluidos la línea QFX5100, la línea QFX5200 y la línea de conmutadores QFX10000.
Los conmutadores QFX10002-60C admiten la protección DDoS del plano de control a partir de Junos OS versión 18.1R1.
Enrutadores T4000 que sólo tienen instalados FPC tipo 5.
En las plataformas Junos Evolved, debe configurar la familia de protocolos y/o
inet6eninetla interfaz lo0 del dispositivo para que la protección DDoS funcione con esas familias de protocolos, respectivamente.Es posible que algunos conmutadores de la serie EX tengan protección DDoS en el plano de control, pero no admiten las opciones de CLI para mostrar o cambiar los parámetros predeterminados del aplicador de policía.
Para las plataformas de enrutador que tienen otras tarjetas de línea además de MPC (serie MX), FPC tipo 5 (T4000) o FPC basadas en PE (PTX3000, PTX5000, PTX1000 y PTX10000), la CLI acepta la configuración, pero las otras tarjetas de línea no están protegidas, por lo que el enrutador no está protegido.
La compatibilidad con la protección DDoS del plano de control para la administración mejorada de suscriptores se agregó en la versión 17.3R1 de Junos OS en plataformas de enrutamiento.
Para cambiar los parámetros de protección DDoS del plano de control configurados por defecto para grupos de protocolos y tipos de paquetes compatibles, los enrutadores serie ACX, los enrutadores serie PTX y los conmutadores serie QFX compatibles tienen opciones de configuración CLI que difieren significativamente de las opciones disponibles para los enrutadores serie MX y T4000. Consulte las siguientes instrucciones de configuración para conocer las opciones de configuración disponibles en diferentes dispositivos:
Para dispositivos de enrutamiento, excepto enrutadores de la serie PTX, consulte protocolos (DDoS).
Para los enrutadores de la serie ACX, los enrutadores de la serie PTX y los conmutadores de la serie QFX, consulte protocolos (DDoS) (serie ACX, serie PTX y serie QFX).
Tipos de policía y prioridades de paquetes
La protección DDoS del plano de control incluye dos tipos de aplicadores:
Se aplica un aplicador de políticas agregadas al conjunto completo de tipos de paquetes que pertenecen a un grupo de protocolos. Por ejemplo, puede configurar un aplicador de políticas de agregado que se aplique a todos los tipos de paquetes de control PPPoE o a todos los tipos de paquetes de control DHCPv4. Puede especificar los límites de ancho de banda (paquetes por segundo [pps]) y ráfaga (paquetes en ráfaga), escalar los límites de ancho de banda y ráfaga, y establecer una prioridad de tráfico para los aplicadores de agregados. Todos los grupos de protocolos admiten un aplicador de políticas agregado.
Un controlador de policía individual, también conocido como controlador de tipo de paquete, se asigna para cada tipo de paquete de control dentro de un grupo de protocolos. Por ejemplo, puede configurar un aplicador de políticas para uno o varios tipos de paquetes de control PPPoE, paquetes de control RADIUS o paquetes de espionaje de multidifusión. Puede especificar valores límite de ancho de banda (pps) y ráfaga (paquetes), escalar los límites de ancho de banda y ráfaga, y establecer una prioridad de tráfico para los aplicadores de tipo paquete. Los policías individuales están disponibles para algunos grupos de protocolo.
La compatibilidad con grupos de protocolos y tipos de paquetes varía según las plataformas y las versiones de Junos OS, como se indica a continuación:
Para dispositivos de enrutamiento, excepto enrutadores de la serie PTX, consulte protocolos (DDoS).
Para los enrutadores serie ACX, enrutadores serie PTX y conmutadores serie QFX, consulte protocolos (DDoS) (serie ACX, serie PTX y serie QFX).
Un paquete de control es vigilado primero por su aplicador de control individual (si es compatible) y, a continuación, por su aplicador agregado. Un paquete lanzado por el policía individual nunca llega al policía agregado. Un paquete que pasa por el controlador de control individual puede ser descartado posteriormente por el controlador de datos agregado.
Los enrutadores serie ACX solo admiten el aplicador de políticas agregadas para cualquier grupo de protocolos compatible.
Los tipos de paquetes dentro de un grupo de protocolos tienen una prioridad predeterminada y configurable: baja, media o alta. Cada paquete de control compite con otros paquetes por el ancho de banda dentro del límite de velocidad de paquetes impuesto por su aplicador de políticas agregadas en función de la prioridad configurada para cada tipo de paquete del grupo de protocolos.
El mecanismo de prioridad es absoluto. El tráfico de alta prioridad obtiene ancho de banda con preferencia al tráfico de prioridad media y baja. El tráfico de prioridad media obtiene ancho de banda en lugar del tráfico de baja prioridad. El tráfico de baja prioridad solo puede usar el ancho de banda que deja el tráfico de prioridad alta y media. Si el tráfico de mayor prioridad ocupa todo el ancho de banda, se elimina todo el tráfico de menor prioridad.
En versiones anteriores a Junos OS versión 23.2R1, en dispositivos de la serie MX, el tipo de tarjeta de línea del dispositivo controla la prioridad de denegación de servicio distribuido (DDoS) de los protocolos entrantes. A partir de Junos OS versión 23.2R1, el dispositivo determina la prioridad DDoS de un protocolo en función de la tabla de parámetros DDoS. Esta mejora permite que el dispositivo trate todos los paquetes de un protocolo en particular de la misma manera de forma predeterminada, independientemente de la tarjeta de línea del dispositivo. Puede modificar la tabla de parámetros de DDoS mediante la CLI. Esta característica mejora la coherencia en la forma en que los dispositivos de la red priorizan los protocolos para protegerse contra ataques DDoS.
Ejemplo de comportamiento de prioridad de Policer
Por ejemplo, en un dispositivo que admita la protección DDoS del plano de control para el grupo de protocolos PPPoE, considere cómo puede configurar los tipos de paquetes dentro de este grupo de protocolos. Ignorando otros tipos de paquetes PPPoE para este ejemplo, supongamos que configura políticas individuales para paquetes PADI y PADD, así como un controlador de agregados PPPoE para todos esos paquetes. Priorizas los paquetes PADT sobre los paquetes PADI porque los paquetes PADT permiten que la aplicación PPPoE libere recursos para aceptar nuevas conexiones. Por lo tanto, asigna prioridad alta a los paquetes PADT y prioridad baja a los paquetes PADI.
El aplicador de políticas de agregado impone un límite de velocidad total de paquetes para el grupo de protocolos. Los paquetes PADT pasados por su aplicador individual tienen acceso a ese ancho de banda antes que los paquetes PADI pasados por su aplicador individual, porque los paquetes PADT tienen una prioridad más alta. Si se pasan tantos paquetes PADT que utilizan todo el ancho de banda disponible, entonces todos los paquetes PADI se descartan, porque no queda ancho de banda en el aplicador agregado.
Ejemplo de jerarquía de policía
Los aplicadores DDoS del plano de control están organizados para que coincidan con el flujo jerárquico del tráfico de control de protocolo. Controlar el tráfico que llega de todos los puertos de una tarjeta de línea converge en el motor de reenvío de paquetes. Controlar el tráfico de todas las tarjetas de línea del enrutador converge en el motor de enrutamiento. Del mismo modo, los controladores DDoS se colocan jerárquicamente a lo largo de las rutas de control para que el exceso de paquetes se deje caer lo antes posible en la ruta. Este diseño preserva los recursos del sistema mediante la eliminación del exceso de tráfico malicioso para que el motor de enrutamiento reciba solo la cantidad de tráfico que puede procesar.
Para implementar este diseño en enrutadores de la serie MX, por ejemplo, hay cinco políticas DDoS: una en el motor de reenvío de paquetes (el chipset), dos en la tarjeta de línea y dos en el motor de enrutamiento. Un aplicador de políticas agregadas también está presente en el motor de reenvío de paquetes para algunos grupos de protocolo, para un total de seis personas de aplicación; Para simplificar, el texto sigue el caso general. Por ejemplo, la figura 1 muestra el proceso de aplicación de políticas para el tráfico PPPoE. La figura 2 muestra el proceso de aplicación de políticas para el tráfico DHCPv4. (El mismo proceso se aplica al tráfico DHCPv6 también).
Recuerde que los enrutadores de la serie PTX y los conmutadores de la serie QFX tienen un diseño más simple con policías solo en el motor de reenvío de paquetes. Los enrutadores PTX10003 y PTX10008 imponen límites de protección DDoS del plano de control en tres niveles: dos en los niveles de chipset y tarjeta de línea del motor de reenvío de paquetes y uno en el nivel del motor de enrutamiento. Sin embargo, los aplicadores de tipo de paquete y agregados funcionan de manera similar en todas estas plataformas.
PPPoE
DHCPv4
Los paquetes de control llegan al motor de reenvío de paquetes para su procesamiento y reenvío. El primer policía (1) es un policía individual (Figura 1) o un policía agregado (Figura 2).
El primer policía es un policía individual para grupos de protocolo que apoyan a los policías individuales, con dos excepciones. Para el tráfico DHCPv4 y DHCPv6, el primer controlador es un controlador agregado.
El primer controlador de policía es un aplicador de agregado para grupos de protocolo que solo admiten aplicadores de agregado.
El tráfico que pasa por el primer policía es monitoreado por uno o ambos policías de tarjetas de línea. Si la tarjeta tiene más de un motor de reenvío de paquetes, el tráfico de todos los motores de reenvío de paquetes converge en los aplicadores de tarjetas de línea.
Cuando el tráfico pertenece a un grupo de protocolo que admite policías individuales, pasa a través del controlador individual de tarjeta de línea (2) y, a continuación, el controlador de agregado de tarjeta de línea (3). El tráfico que pasa por el controlador de policía individual puede ser eliminado por el controlador agregado. Aunque el tráfico DHCPv4 y DHCPv6 fue supervisado por un controlador de agregados en el motor de reenvío de paquetes, en la tarjeta de línea se maneja como otros protocolos que admiten aplicadores individuales.
Cuando el tráfico pertenece a un grupo de protocolos que solo admite controladores agregados, solo el controlador de agregado de tarjeta de línea supervisa el tráfico.
El tráfico que pasa por los aplicadores de tarjetas de línea es supervisado por uno o ambos aplicadores de política del motor de enrutamiento. El tráfico de todas las tarjetas de línea converge en los aplicadores del motor de enrutamiento.
Cuando el tráfico pertenece a un grupo de protocolos que admite aplicadores individuales, pasa a través del controlador individual del motor de enrutamiento (4) y, a continuación, del controlador de agregados del motor de enrutamiento (5). El tráfico que pasa por el controlador de policía individual puede ser eliminado por el controlador agregado. Al igual que en el nivel de tarjeta de línea, el tráfico DHCPv4 y DHCPv6 en el motor de enrutamiento se maneja como otros protocolos que admiten aplicadores individuales.
Cuando el tráfico pertenece a un grupo de protocolos que solo admite aplicadores de agregados, solo el controlador de agregado supervisa el tráfico.
Con este diseño, tres aplicadores de políticas evalúan el tráfico para grupos de protocolos que solo admiten políticas agregadas. Entre otros grupos, esto incluye tráfico ANCP, VLAN dinámica, FTP e IGMP. Los cinco policías evalúan el tráfico de los grupos de protocolo que admiten políticas agregadas e individuales. Entre otros grupos, esto incluye DHCPv4, MLP, PPP, PPPoE y tráfico de chasis virtual .
La figura 1 muestra cómo las políticas de protección DDoS del plano de control de los paquetes de control PPPoE:
Los paquetes PADR, por ejemplo, se evalúan en el primer controlador del motor de reenvío de paquetes para determinar si están dentro de los límites de velocidad de paquetes. Los paquetes PADR que excedan el límite se descartan.
Todos los paquetes PADR que pasan el aplicador de policía en todos los motores de reenvío de paquetes de la tarjeta de línea son evaluados a continuación por el controlador individual de tarjetas de línea. Los paquetes PADR que excedan el límite se descartan.
Todos los paquetes PADR que pasan por el aplicador individual de tarjeta de línea proceden al aplicador de agregado de tarjeta de línea. Los paquetes PADR que excedan el límite se descartan.
Todos los paquetes PADR que pasan los aplicadores agregados de tarjetas de línea en todas las tarjetas de línea del enrutador pasan al controlador individual del motor de enrutamiento. Los paquetes PADR que excedan el límite se descartan.
Por último, todos los paquetes PADR que pasa el aplicador de control individual del motor de enrutamiento pasan al aplicador de agregados del motor de enrutamiento. Los paquetes PADR que excedan el límite se descartan. Los paquetes PADR que no se dejan caer aquí se pasan como tráfico seguro y normal.
De forma predeterminada, los tres aplicadores de políticas individuales (motor de reenvío de paquetes, tarjeta de línea y motor de enrutamiento) tienen el mismo límite de velocidad de paquetes para un tipo de paquete determinado. Con este diseño, todo el tráfico de control de un motor de reenvío de paquetes y una tarjeta de línea puede llegar al motor de enrutamiento siempre que no haya tráfico competidor del mismo tipo de otros motores de reenvío de paquetes o tarjetas de línea. Cuando hay tráfico competidor, el exceso de paquetes se deja caer en los puntos de convergencia. Es decir, se colocan en la tarjeta de línea para todos los motores de reenvío de paquetes de la competencia y en el motor de enrutamiento para todas las tarjetas de línea de la competencia.
Ejemplo de comportamiento de Policer para limitar la velocidad de paquetes
Por ejemplo, supongamos que estableces la opción policer bandwidth para paquetes PADI en 1000 paquetes por segundo. Este valor se aplica a los policías PADI individuales en el motor de reenvío de paquetes, la tarjeta de línea y el motor de enrutamiento. Si solo la tarjeta en la ranura 5 está recibiendo paquetes PADI, entonces hasta 1000 pps PADI pueden llegar al motor de enrutamiento (si no se excede el aplicador de agregado PPPoE). Sin embargo, supongamos que la tarjeta en la ranura 9 también recibe paquetes PADI a 1000 pps y que no se excede su aplicador de control agregado PPPoE. El tráfico pasa los aplicadores individuales y agregados en ambas tarjetas de línea y pasa al motor de enrutamiento. En el motor de enrutamiento, la velocidad de paquetes combinados es de 2000 pps. Debido a que el policía PADI en el motor de enrutamiento permite que solo pasen 1000 pps PADI, deja caer el exceso de 1000 paquetes. Continúa eliminando el exceso de paquetes mientras se supere el límite de ancho de banda (pps).
Puede aplicar un factor de escala tanto para el límite de ancho de banda (pps) como para el límite de ráfaga (paquetes en ráfaga) en la tarjeta de línea para ajustar los límites de tráfico de cada ranura. Por ejemplo, supongamos que el aplicador individual establece la velocidad de paquetes PADI en 1000 pps y el tamaño de ráfaga en 50.000 paquetes. Puedes reducir el límite de tráfico para paquetes PADI en cualquier tarjeta de línea especificando el número de ranura y el factor de escala. Un factor de escala de ancho de banda de 20 para la ranura 5 reduce el tráfico en este ejemplo al 20 por ciento de 1000 pps, o 200 pps para la tarjeta de línea en esa ranura. Del mismo modo, un factor de escala de ráfaga de 50 para esa ranura reduce el tamaño de ráfaga en un 50 por ciento a 25.000 paquetes. De forma predeterminada, los factores de escala se establecen en 100, por lo que el tráfico puede pasar al 100 por ciento del límite de velocidad.
Protección DDoS del plano de control en comparación con el inicio de sesión del suscriptor Protección contra sobrecarga de paquetes
Además de la capacidad de protección DDoS del plano de control, los enrutadores de la serie MX también tienen un mecanismo integrado de protección contra sobrecarga de inicio de sesión del suscriptor. El mecanismo de protección contra sobrecarga de inicio de sesión (también llamado mecanismo de limitación de carga) supervisa los paquetes de inicio de sesión del suscriptor entrante y admite solo lo que el sistema es capaz de manejar de acuerdo con la carga prevaleciente en el sistema. Se descartan los paquetes que excedan lo que el sistema puede manejar. Al eliminar este exceso de carga, el sistema puede mantener un rendimiento óptimo y evitar cualquier degradación de la tasa de finalización de inicio de sesión en condiciones de sobrecarga. Este mecanismo utiliza recursos mínimos y está habilitado de forma predeterminada; No se requiere configuración de usuario.
La protección proporcionada por este mecanismo es secundaria a la que proporciona la protección DDoS del plano de control como primer nivel de defensa contra altas tasas de paquetes entrantes. La protección DDoS del plano de control funciona en el motor de reenvío de paquetes y protege contra todos los tipos de paquetes de todos los protocolos. Por el contrario, el mecanismo de protección contra sobrecarga de inicio de sesión se encuentra en el motor de enrutamiento y funciona específicamente solo en paquetes de iniciación de conexión entrantes, como DHCPv4, DHCPdiscover, DHCPv6 SOLICIT y paquetes PPPoE PADI.
Tabla de historial de cambios
La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.