Cómo configurar FlowSpec en los routers Juniper

Visión general:

BGP FlowSpec (Border Gateway Protocol Flow Specification) es una extensión del protocolo BGP que se utiliza para definir reglas de filtrado de tráfico en los routers o, más sencillamente, para generar reglas de cortafuegos en los routers a partir de un anuncio BGP. A diferencia del BGP convencional, que enruta basándose en IPv4/IPv6 e información de prefijos, BGP FlowSpec permite a los administradores de red especificar criterios más granulares para el reenvío de paquetes, incluida información de capa 4 (puertos TCP/UDP) e incluso patrones de paquetes.

Para obtener más información sobre BGP Flowspec, visite nuestro artículo sobre qué es BGP Flowspec a través de este enlace.

Operación:

BGP FlowSpec funciona añadiendo nuevos tipos de atributos a BGP, lo que permite a los administradores de red especificar reglas de filtrado detalladas. Estas normas pueden incluir criterios como:

• Direcciones de origen y destino IPv4/IPv6
• Puertos TCP/UDP
• Protocolos
• Máscaras de bits
• Valores de los campos del paquete

Se pueden realizar las siguientes acciones con BGP FlowSpec:

1. deny: Bloquea el tráfico correspondiente a la regla.
2. rate-limit: Limita la tasa de tráfico correspondiente a la regla.
3. redirect: Redirige el tráfico correspondiente a la regla.
4. muestra: Recoge una muestra del tráfico correspondiente a la regla.
5. mark: Marca los paquetes que coinciden con la regla con una marca específica.
6. redirect-to-ip: Redirige el tráfico correspondiente a la regla a una dirección IP específica.
7. traffic-rate: Limita la tasa de tráfico correspondiente a la regla a un valor específico.
8. traffic-action: Define la acción para el tráfico correspondiente, como aceptar, descartar o reenviar.
9. redirect-to-blackhole: Descarta silenciosamente todo el tráfico correspondiente a la regla.

Cuando estas reglas se propagan a través de la red BGP, los routers pueden utilizar esta información para filtrar o manipular el tráfico de acuerdo con las políticas definidas.

Funcionamiento – Más detalles:

En el contexto de BGP FlowSpec, las acciones se especifican como parte de las reglas de filtrado. Cada regla de filtrado contiene tres partes principales:

• Campos de coincidencia (Matching Fields): especifican los criterios de Campos de coincidencia:, como las direcciones IP de origen y destino, los puertos TCP/UDP, los protocolos, las máscaras de bits y los valores de los campos de paquetes.

• Campos de Acción (Action Fields): Especifique las acciones que se tomarán para el tráfico que corresponde a la regla.
• Campos de Protocolo (Protocol Fields): Especifique el protocolo que debe aplicar la regla de filtrado.

Las acciones en BGP FlowSpec se codifican utilizando comunidades BGP. Cada acción se asigna a una comunidad BGP específica:

• La acción‘deny’ puede ser representada por una comunidad BGP específica, como ‘65535:666’.
• La acción‘rate-limit‘ puede ser representada por otra comunidad BGP específica, como ‘65535:777’.
• La acción‘redirect‘ puede ser representada por una comunidad BGP diferente, como ‘65535:888’.

Cuando se crea una regla BGP FlowSpec, se especifican los campos coincidentes, la acción deseada y, opcionalmente, los campos de protocolo. A continuación, esta regla se codifica como una comunidad BGP y se incluye en un mensaje de actualización BGP que se envía a los routers vecinos. Los routers que reciben esta regla aplican las acciones especificadas a los paquetes que cumplen los criterios de coincidencia.

Tenga en cuenta que las comunidades BGP específicas para cada acción pueden variar en función de la implementación de BGP FlowSpec en su equipo de red. Le recomiendo que consulte la documentación de su equipo para obtener información detallada sobre las comunidades BGP asociadas a cada acción en BGP FlowSpec.

Casos prácticos:

1. **Mitigación de ataques DDoS:

BGP FlowSpec puede utilizarse para bloquear o redirigir tráfico malicioso durante ataques de denegación de servicio distribuidos (DDoS). Se pueden aplicar reglas precisas para filtrar el tráfico no deseado y mantener los servicios en línea.

2. **Políticas de calidad de servicio (QoS):

Los administradores de red pueden utilizar BGP FlowSpec para garantizar la calidad del servicio priorizando determinados tipos de tráfico en función de puertos o protocolos específicos.

3. **Aplicación de políticas de seguridad**:

BGP FlowSpec puede utilizarse para aplicar políticas de seguridad granulares, bloqueando el tráfico asociado a malware o actividades sospechosas.

Ejemplos de configuración:

La configuración de BGP FlowSpec puede variar en función del equipo de red utilizado.

Este ejemplo explora cómo diseñar una solución de mitigación DDoS en la que un proveedor de servicios permite a sus clientes anunciar rutas BGP FlowSpec para él.

También analiza algunas de las mejores prácticas que deben tenerse en cuenta antes de implementar este tipo de solución y, por último, algunos de los comandos de Junos disponibles para ayudarle a comprobar que su solución Flow-spec funciona correctamente.

Escenario topológico del ejemplo:

Empecemos por ver cómo se configurará nuestra solución:

Como podemos ver en la topología anterior, existe el BORDA, que es un dispositivo Juniper que actúa como enrutador BGP para la red, el Made4Flow que es el software que analizará los flujos y generará reglas para BGP FlowSpec dinámicamente y anunciarlo vía BGP al router BGP llamado BORDA.

En este escenario, el ejemplo de ataque es un ataque de amplificación DNS. Esto significa que la red está recibiendo un gran volumen de paquetes UDP puerto 53 que en realidad no necesita para que el ISP funcione con normalidad.

El ataque llena el circuito entre el ISP y los operadores y deja la red inoperativa.

Cuando el atacante decide lanzar el ataque, el ISP puede utilizar el Made4Flow para generar una ruta BGP FlowSpec sólo para paquetes UDP puerto 53 y anunciarla al Router BORDA BGP, que puede convertir esta ruta en un filtro firewall en sus interfaces de comunicación con los Operadores.

Y entonces esto bloquea los paquetes de amplificación DNS en el borde de la red del ISP y también en el operador (si el operador soporta sesiones FlowSpec), pero permite que el tráfico legítimo siga llegando.

En primer lugar, vamos a analizar la configuración de la sesión BGP FlowSpec en el router BGP BORDA con Made4Flow, suponiendo que el router ya está configurado para el enrutamiento unicast BGP normal (sesión BGP normal para anunciar rutas Blackhole o Mitigation/Scrubbing Center).

Para configurar una sesión BGP FlowSpec en dispositivos Juniper, utilizamos los siguientes comandos:

set routing-options flow term-order standard
set protocols bgp group MADE4FLOW type internal
set protocols bgp group MADE4FLOW local-address 10.70.0.67
set protocols bgp group MADE4FLOW family inet unicast
set protocols bgp group MADE4FLOW family inet flow no-validate FLOWSPEC_IMPORT
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 description IBGP_MADE4FLOW
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 local-adddress 10.70.0.67
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 import FLOWSPEC_IMPORT
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 family inet flow prefix-limit maximum 1000
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 family inet flow no-validate FLOWSPEC_IMPORT
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 family inet flow legacy-redirect-ip-action receive
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 export DENY-ALL
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 peer-as XXXXXX

Buenas prácticas:

Existen buenas prácticas para proteger esta solución. Tanto las rutas BGP FlowSpec como los filtros de cortafuegos resultantes que crean son recursos finitos en el router.

Por lo tanto, el enrutador BGP BORDA puede filtrar las rutas entrantes para asegurarse de que recibe demasiadas rutas inesperadas o erróneas.

Límite del prefijo:

Así que lo primero que hay que hacer es establecer un límite de prefijos para las rutas BGP FlowSpec.

Podría simplemente definir un límite de prefijo único para las rutas inet unicast e inet flujosin embargo, este ejemplo definirá un límite separado para las rutas flujo inet. Para que Made4Flow sólo pueda enviar diez rutas BGP Flowspec a la vez, fijemos el límite de prefijos en 10 (esta configuración debe ajustarse en función de cada escenario):

set protocols bgp group MADE4FLOW neighbor 10.70.0.68 family inet flow prefix-limit maximum 10

Política de rutas :

Lo siguiente que hay que hacer es aplicar una política de rutas entrantes. Esta política limitará el router a recibir prefijos que provengan del propio ISP con prefijos /24 a /32, que son los anunciados por Made4Flow.

Añadamos también una Comunidad 64496:86 para que pueda identificar las rutas como rutas BGP FlowSpec.

Para el resto de rutas, basta con filtrarlas en función de la asignación de rutas del cliente:

1. Cree la definición de la política:

set policy-options community COMM-FLOWSPEC members 64496:86
set policy-options policy-statement FLOWSPEC_IMPORT term 1 from rib inetflow.0
set policy-options policy-statement FLOWSPEC_IMPORT term 1 from route-filter 203.0.113.0/24 prefix-length-range /24-/32;
set policy-options policy-statement FLOWSPEC_IMPORT term 1 then community add COMM-FLOWSPEC
set policy-options policy-statement FLOWSPEC_IMPORT term 1 then accept 
set policy-options policy-statement FLOWSPEC_IMPORT term 999 then reject

2. Aplique la política como política de importación en la sesión BGP con Made4Flow:

set protocols bgp group MADE4FLOW family inet flow no-validate FLOWSPEC_IMPORT
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 import FLOWSPEC_IMPORT
set protocols bgp group MADE4FLOW neighbor 10.70.0.68 family inet flow no-validate FLOWSPEC_IMPORT

Prefijos máximos:

Lo último que hay que hacer es establecer un número máximo de prefijos BGP FlowSpec que se pueden instalar en la tabla de enrutamiento.

Este ejemplo establece un máximo de 10.000 rutas, pero también vamos a configurar el router para notificar al administrador a través de un syslog cuando se alcance el límite del 90 por ciento. Esta configuración debe aplicarse a todos los routers de la red del ISP de ejemplo:

set routing-options rib inetflow.0 maximum-prefixes 10000 threshold 90

Puede que no sea muy intuitivo de entender en la sintaxis anterior, pero el conf. umbral 90 es lo que le dice al router que quieres un syslog cuando se alcance el umbral del 90 por ciento.

Compruébalo:

Lo primero que hay que comprobar es que BGP FlowSpec está configurado correctamente. Veamos los NLRI activados en el peer BGP.

Comprobación del NLRI: Desde el modo operativo en el router BORDA, introduzca el comando Junos OS show bgp vecino 10.70.0.68 y busque el inet-flow en la salida:

lab@BORDA> show bgp neighbor 10.70.0.68
Peer: 10.70.0.68+45824 AS 64511 Local: 192.0.2.0+63720 AS 64496
 Type: External State: Established Flags: <Sync>
 Last State: OpenConfirm Last Event: RecvKeepAlive
 Last Error: None
 Import: [ CUST-IN ]
 Options: <Preference LocalAddress AddressFamily PeerAS PrefixLimit Refresh>
 Address families configured: inet-unicast inet-flow
 Local Address: 10.70.0.67 Holdtime: 90 Preference: 170
 Number of flaps: 0
 Peer ID: 10.70.0.68 Local ID: 10.70.0.67 Active Holdtime: 90
 Keepalive Interval: 30 Group index: 1 Peer index: 0
 BFD: disabled, down
 Local Interface: ge-0/0/3.0
 NLRI for restart configured on peer: inet-unicast inet-flow
 NLRI advertised by peer: inet-unicast inet-flow
 NLRI for this session: inet-unicast inet-flow
 Peer supports Refresh capability (2)
 Stale routes from peer are kept for: 300
 Peer does not support Restarter functionality
 NLRI that restart is negotiated for: inet-unicast inet-flow
 NLRI of received end-of-rib markers: inet-unicast inet-flow
 NLRI of all end-of-rib markers sent: inet-unicast inet-flow
 Peer supports 4 byte AS extension (peer-as 64511)
 Peer does not support Addpath
 Table inetflow.0 Bit: 10000
 RIB State: BGP restart is complete
 Send state: in sync
 Active prefixes: 1
 Received prefixes: 1
 Accepted prefixes: 1
 Suppressed due to damping: 0
 Advertised prefixes: 0
 Table inet.0 Bit: 20000
 RIB State: BGP restart is complete
 Send state: in sync
 Active prefixes: 1
 Received prefixes: 1
 Accepted prefixes: 1
 Suppressed due to damping: 0
 Advertised prefixes: 0
 Last traffic (seconds): Received 13 Sent 28 Checked 4
 Input messages: Total 392 Updates 4 Refreshes 0Octets 7552
 Output messages: Total 386 Updates 0 Refreshes 0Octets 7435
 Output Queue[0]: 0 (inetflow.0, inet-flow)
 Output Queue[1]: 0 (inet.0, inet-unicast)

Comprobación de rutas:

La siguiente cosa a mirar es la ruta de flujo que fue enviado por Made4Flow y recibido en el BORDA:

lab@BORDA> show route receive-protocol bgp 10.70.0.68 extensive table inetflow.0
inetflow.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
* 203.0.113.1,*,proto=17,dstport=53/term:1 (1 entry, 1 announced)
 Accepted
 Nexthop: Self
 AS path: 64511 I
 Communities: traffic-rate:0:0

Y aquí se está recibiendo la ruta desde Made4Flow. Tenga en cuenta que la única comunidad adjunta a la ruta es la que especifica que debe establecer una tasa de 0 para el tráfico.

Ahora echemos un vistazo a la ruta en la tabla de enrutamiento del router BGP BORDA:

lab@BORDA> show route table inetflow.0 extensive
inetflow.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
203.0.113.1,*,proto=17,dstport=53/term:1 (1 entry, 1 announced)
TSI:
KRT in dfwd;
Action(s): discard,count
Page 0 idx 1, (group ibgp type Internal) Type 1 val 0x966ef08 (adv_entry)
 Advertised metrics:
 Nexthop: Self
 Localpref: 100
 AS path: [64496] 64511 I
  Communities: 64496:86 traffic-rate:0:0
Page 0 idx 2, (group RR-CLIENT-FLOWSPEC type Internal) Type 1 val 0x966f11c (adv_
entry)
 Advertised metrics:
 Nexthop: Self
 Localpref: 100
 AS path: [64496] 64511 I
 Communities: 64496:86 traffic-rate:0:0
Path 203.0.113.1,*,proto=17,dstport=53 from 10.70.0.68 Vector len 4. Val: 1 2
 *BGP Preference: 170/-101
 Next hop type: Fictitious
 Address: 0x9358c04
 Next-hop reference count: 1
 State: <Active Ext>
 Local AS: 64496 Peer AS: 64511
 Age: 3:27:43
 Validation State: unverified
 Task: BGP_64511.10.70.0.68+45824
 Announcement bits (2): 0-Flow 1-BGP_RT_Background
 AS path: 64511 I
 Communities: 64496:86 traffic-rate:0:0
 Accepted
 Validation state: Accept, Originator: 10.70.0.68
 Via: 203.0.113.0/24, Active
 Localpref: 100
 Router ID: 10.70.0.68

La ruta se ha instalado en la tabla de rutas en BORDA y Comunidad 64496:86 que fue asignada fue añadida a la ruta.

Comprueba que el flujo se ha correspondido con la ruta unicast y se ha validado su coherencia.

Así que continuamos…

Comprobación de los filtros del cortafuegos:

Una vez validadas las rutas de flujo, se transforman en filtros cortafuegos.

Echemos un vistazo al filtro cortafuegos:

lab@BORDA> show firewall filter __flowspec_default_inet__
Filter: __flowspec_default_inet__
Counters:
Name Bytes Packets
203.0.113.1,*,proto=17,dstport=53 0 0

Todo bien.

Comprueba el registro del sistema:

EJEMPLO: Si ha seguido las mejores prácticas anteriores y ha establecido un límite de prefijos en la sesión BGP, verá un mensaje de registro cuando se alcance el máximo:

lab@BORDA> show log messages | match BGP_PREFIX
Sep 5 17:51:04 pe3 rpd[2812]: BGP_PREFIX_LIMIT_
EXCEEDED: 10.70.0.68 (External AS 64511): Configured maximum prefixlimit(1) exceeded for inet-flow nlri: 2 (instance master)

Resumen final del ejemplo:

Como vemos, configurar una solución BGP FlowSpec es sencillo.

Entre ISP puede resultar un poco más complicado, ya que requiere coordinación entre el cliente y el proveedor de servicios. Lamentablemente, no todos los operadores ofrecen sesiones FlowSpec.

Consulte con su operador sobre esta posibilidad, ya que es esencial tenerlo configurado antes de un ataque DDoS.

Obtenga más información sobre cómo optimizar el encaminamiento del tráfico con BGP FlowSpec y simplificar la gestión de la seguridad de la red. Explore Made4Flow, nuestra herramienta de análisis de flujos de red, y lleve su infraestructura de red al siguiente nivel.