Visão Geral: 

O BGP FlowSpec (Border Gateway Protocol Flow Specification) é uma extensão do protocolo BGP usado para definir regras de filtragem de tráfego em roteadores ou simplificando podendo gerar regras de firewall nos roteadores apartir de um anúncio BGP. Ao contrário do BGP convencional, que roteia com base em informações de IPv4/IPv6 e prefixo, o BGP FlowSpec permite que os administradores de rede especifiquem critérios mais granulares para o encaminhamento de pacotes, incluindo informações sobre camada 4 (portas TCP/UDP) e até mesmo padrões de pacotes.  

Para saber mais sobre o BGP Flowspec acesse nosso artigo falando sobre o que é BGP Flowspec atraves deste link. 

Funcionamento: 

O BGP FlowSpec funciona adicionando novos tipos de atributos ao BGP, permitindo aos administradores de rede especificarem regras de filtragem detalhadas. Essas regras podem incluir critérios como: 

  • Endereços IPv4/IPv6 de origem e destino 
  • Portas TCP/UDP 
  • Protocolos 
  • Máscaras de bits 
  • Valores de campo de pacotes 

As seguintes ações podem ser tomadas com o BGP FlowSpec: 

  1. deny: Bloqueia o tráfego correspondente à regra. 
  2. rate-limit: Limita a taxa de tráfego correspondente à regra. 
  3. redirect: Redireciona o tráfego correspondente à regra. 
  4. sample: Coleta uma amostra do tráfego correspondente à regra. 
  5. mark: Marca pacotes correspondentes à regra com uma marca específica. 
  6. redirect-to-ip: Redireciona o tráfego correspondente à regra para um endereço IP específico. 
  7. traffic-rate: Limita a taxa de tráfego correspondente à regra para um valor específico. 
  8. traffic-action: Define ação para o tráfego correspondente, como aceitar, descartar ou encaminhar. 
  9. redirect-to-blackhole: Descarta silenciosamente todo o tráfego correspondente à regra. 

Quando essas regras são propagadas através da rede BGP, os roteadores podem usar essas informações para filtrar ou manipular o tráfego de acordo com as políticas definidas. 

Funcionamento – Mais Detalhes: 

No contexto do BGP FlowSpec, as ações são especificadas como parte das regras de filtro. Cada regra de filtro contém três partes principais: 

  • Campos de Correspondência (Matching Fields): Especificam os critérios de correspondência, como endereços IP de origem e destino, portas TCP/UDP, protocolos, máscaras de bits e valores de campo de pacotes. 
  • Campos de Ação (Action Fields): Especificam as ações a serem tomadas para o tráfego que corresponde à regra. 
  • Campos de Protocolo (Protocol Fields): Especificam o protocolo que a regra de filtro deve aplicar. 

As ações no BGP FlowSpec são codificadas usando comunidades BGP. Cada ação é mapeada para uma comunidade BGP específica: 

  • A ação ‘deny‘ (bloquear) pode ser representada por uma comunidade BGP específica, como ‘65535:666’. 
  • A ação ‘rate-limit‘ (limitar taxa) pode ser representada por outra comunidade BGP específica, como ‘65535:777’. 
  • A ação ‘redirect‘ (redirecionar) pode ser representada por uma comunidade BGP diferente, como ‘65535:888’. 

Ao criar uma regra BGP FlowSpec, você especifica os campos de correspondência, a ação desejada e, opcionalmente, campos de protocolo. Esta regra é então codificada como uma comunidade BGP e incluída em uma mensagem de atualização BGP que é enviada para os roteadores vizinhos. Os roteadores que recebem essa regra aplicam as ações especificadas aos pacotes que correspondem aos critérios de correspondência. 

Por favor, note que as comunidades BGP específicas para cada ação podem variar de acordo com a implementação do BGP FlowSpec em seu equipamento de rede. Recomendo consultar a documentação do seu equipamento para obter informações detalhadas sobre as comunidades BGP associadas a cada ação no BGP FlowSpec. 

Casos de Uso: 

1. **Mitigação de Ataques DDoS**: 

O BGP FlowSpec pode ser utilizado para bloquear ou redirecionar tráfego malicioso durante ataques de negação de serviço distribuídos (DDoS). As regras precisas podem ser aplicadas para filtrar o tráfego indesejado e manter os serviços online. 

2. **Políticas de QoS (Qualidade de Serviço)**: 

Administradores de rede podem utilizar o BGP FlowSpec para garantir a qualidade de serviço, priorizando determinados tipos de tráfego com base em portas ou protocolos específicos. 

3. **Implementação de Políticas de Segurança**: 

O BGP FlowSpec pode ser usado para implementar políticas de segurança granulares, bloqueando tráfego associado a malware ou atividades suspeitas. 

Exemplos de Configuração: 

A configuração do BGP FlowSpec pode variar de acordo com o equipamento de rede utilizado.  

Este exemplo explora como projetar uma solução de mitigação de DDoS em que um provedor de serviços permite que seus clientes anunciem rotas BGP FlowSpec para ele. 

Também discute algumas das melhores práticas que devem ser consideradas antes de implementar este tipo de solução e, finalmente, alguns dos comandos do Junos disponíveis para o ajudar a verificar se a solução de Flow-spec está funcionando corretamente. 

Cenário de Topologia para o exemplo:  

Vamos começar dando uma olhada em como nossa solução será configurada: 

Conforme podemos ver na topologia acima, existe a BORDA que é um equipamento Juniper que tem a função de Roteador de BGP da rede, o Made4Flow que é o software que irá analisar os fluxos e gerar regras de BGP FlowSpec dinamicamente e anunciar via BGP para o Roteador BGP chamado BORDA.

Neste cenário, o ataque exemplo é um ataque de amplificação de DNS. Isto significa que a rede está recebendo um grande volume de pacotes UDP porta 53 de que na realidade não necessitaria para o funcionamento normal do ISP.

O ataque enche o circuito entre o ISP e as operadoras e, efetivamente, deixa a rede inoperante.

Quando o atacante decide lançar o ataque, o ISP pode utilizar o Made4Flow para gerar uma rota BGP FlowSpec apenas para pacotes UDP porta 53 e anunciá-la para o Roteador de BGP BORDA, que pode transformar essa rota em um filtro de firewall em suas interfaces de comunicação com as Operadoras.

E então isso bloqueia os pacotes de amplificação de DNS na borda da rede do ISP e também na operadora (se a operadora suportar sessões FlowSpec), mas permite que o tráfego legítimo continue a chegar.

Primeiramente vamos analisar as configurações da sessão BGP FlowSpec no Roteador de BGP BORDA com o Made4Flow, assumindo que o Roteador já está configurado para o encaminhamento unicast BGP normal (Sessão BGP normal para anúncio de Rotas de Blackhole ou Mitigação/Scrubbing Center).

Para realizar a configuração de uma sessão BGP FlowSpec em equipamentos Juniper, utilizamos os seguintes 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

Boas Práticas:                                                                           

Existem melhores práticas para proteger esta solução. Tanto as rotas BGP FlowSpec como os filtros de firewall resultantes que criam são recursos finitos no router.

Sendo assim, o Roteador de BGP BORDA pode efetuar a filtragem de rotas de entrada para garantir que receba rotas demais fora do esperado ou rotas erradas.

Prefix Limit:

Assim, a primeira coisa a fazer é definir um limite de prefixo para as rotas BGP FlowSpec.

Poderia simplesmente definir um único limite de prefixo para as rotas inet unicast e inet flow, no entanto, este exemplo vai definir um limite separado para as rotas inet flow. Para que o Made4Flow apenas possa enviar dez rotas de BGP Flowspec de cada vez, vamos definir o limite de prefixos para 10 (esta configuração deve ser ajustada de acordo com cada cenário):

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

Route Policy :

A próxima coisa a fazer é aplicar uma política de rota de entrada. Essa política limitará o roteador a receber prefixos que são do próprio ISP com prefixos /24 até /32, que são os anunciados pelo Made4Flow.

Vamos também adicionar uma Community 64496:86 para que possa identificar as rotas como sendo rotas BGP FlowSpec.

Para todas as outras rotas, pode simplesmente filtrá-las com base na atribuição de rotas do cliente:

1. Crie a definição da policy:

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 a política como uma política de importação na sessão BGP com 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

Máximo de prefixos:

A última coisa a fazer é definir uma quantidade máxima de prefixos BGP FlowSpec que podem ser instalados na tabela de encaminhamento.

Este exemplo define um máximo de 10.000 rotas, mas vamos também configurar o router para notificar o administrador através de uma mensagem syslog quando for atingido um limite de 90%. Esta definição deve ser aplicada em todos os routers da rede do ISP do exemplo:

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

Pode não ser muito intuitivo entender na sintaxe acima, mas a conf. threshold 90 é o que diz ao router que deseja que seja gerada uma mensagem syslog quando o limiar de 90% for atingido.

Verificação:

A primeira coisa a verificar é que o BGP FlowSpec está configurado corretamente. Vejamos as NLRIs que estão ativadas no peer BGP.

Verificando o NLRI: A partir do modo operacional no router BORDA, introduza o comando Junos OS show bgp neighbor 10.70.0.68 e procure a capacidade inet-flow na saída:

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)

Verificando Rotas:

A próxima coisa a ser observada é a rota de fluxo que foi enviada pelo Made4Flow e recebida na 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

E aqui a rota está a ser recebida do Made4Flow. Observe que a única comunidade anexada à rota é a que especifica que você deve definir uma taxa de 0 para o tráfego.

Agora vamos dar uma olhada na rota na tabela de roteamento do Roteador 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

A rota foi instalada na tabela de rotas na BORDA e a Community 64496:86 que foi atribuída foi adicionada à rota.

Veja que o fluxo foi correspondido à rota unicast e validado quanto à consistência.

Sendo assim, continuamos…

Verificando os filtros de firewall:

Agora que as rotas de fluxo foram validadas, elas são transformadas em filtros de firewall.

Vamos dar uma olhada no filtro de firewall:

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

Tudo OK.

Verificar o registo do sistema (System Log):

EXEMPLO: Se tiver seguido as melhores práticas ditas acima e definido um limite de prefixos na sessão BGP, verá uma mensagem de log quando o máximo for atingido:

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)

Resumo final do exemplo:

Como podemos ver, a configuração de uma solução BGP FlowSpec é simples.

Entre ISP’s pode se tornar um pouco mais complicado, pois requer coordenação entre o cliente e a operadora de serviços. Infelizmente nem todas as operadoras fornecem sessões FlowSpec.

Consulte a sua operadora e verifique sobre essa possibilidade, pois é fundamental ter isso previamente configurada antes de um ataque DDoS.

Descubra mais sobre como otimizar o encaminhamento de tráfego com o BGP FlowSpec e simplificar a gestão de segurança de rede! Explore o Made4Flow, nossa ferramenta de análise de netflow, e leve sua infraestrutura de rede para o próximo nível.

Conheça o Made4Flow