SP Security: Anti-DDoS utilizando BGP Flowspec
Não é errado afirmar que, nos dias de hoje, tudo precisa estar conectado. Estima-se que, ate 2025, existirão em torno de 34B de dispositivos conectados, por volta do dobro da quantidade de dispositivos que existem hoje. Além de apenas se conectar, a demanda por disponibilidade aumenta proporcionalmente, à medida que diversos sistemas passam a ser literalmente dependentes de algum tipo de conectividade.
Dito isto, a disponibilidade de um sistema é regularmente alvo de atividades criminosas, através do que conhecemos como DDoS Attacks, ou ataque de Negação de Serviço.
Qualquer dispositivo conectado à internet pode se tornar um vetor utilizado em ataques DDoS, independente do sistema operacional utilizado. Como a indisponibilidade custa caro, a demanda por prevenção e estratégias para mitigar tal tipo ataque cresce a cada dia.
O que é DDoS?
Um ataque DDoS consiste em sobrecarregar um sistema, a ponto em que o mesmo fica impossibilitado de receber e responder novas requisições — fazendo com que o mesmo seja considerado indisponível. Para gerar carga suficiente, o atacante necessita de uma quantidade significativa de recursos, fazendo uso de dispositivos infectados com botnets ou afins (também conhecidas como dispositivos “zumbi”).
Tais dispositivos, por sua vez, ao receberem o comando remoto para iniciar o ataque, começam a enviar requisições para o sistema especificado (um nome DNS, ou um IP).
Do ponto de vista de dispositivos de rede e segurança (routers, firewall, ID/PS, etc), cada zumbi é visto como um host legítimo: na maioria dos casos de DDoS se utilizam de requisições legítimas.
Por fim, diferenciar o tráfego legítimo de um ataque DDoS pode ser um desafio.
Tipos de DDoS
O alvo de um DDoS não e necessariamente a aplicação em si — o objetivo final de um DDoS pode ser afetar qualquer componente necessário para manter o sistema disponível, como por exemplo:
— Gerando volume e ocupando a banda (Ataques Volumétricos) — Layer 3
— Esgotando a quantidade de sockets do sistema operacional do alvo (“SYN Flood”) — Layer 4
— Tentar sobrecarregar a o software na camada de aplicação (“HTTP Flood”) — Layer 7
Como Reagir a um DDoS
Primeiramente, antecipe-se. Um princípio básico da SI (Segurança da informação): sempre assuma que você será/esta sendo alvo de um ataque.
Com isto, procure saber quais ferramentas e/ou features existentes na rede podem ser utilizadas para ajudar a mitigar um ataque DDoS. Isso inclui ACLs, rate limiters, CoPP e MPP, etc.
Possuir um plano de ação para reagir a tal incidente se torna de extrema importância — saber o que fazer é a diferença entre uma reação aceitável e
um incidente grave.
Após bolar um plano para reagir ao ataque, teremos um checklist mais ou menos parecido com a que a Netscout sugere:
Identificar:
Resume-se em saber se realmente se trata de um DDoS ou não. Para isto, é essencial que tenhamos um determinado nível de visibilidade do tráfego.
Com esta visibilidade, se torna possível estabelecer baselines — o que nos permite detectar anomalias caso algo saia do esperado, e muitas vezes, correlacionar com outros eventos (na Black Friday esperamos um aumento na quantidade de requisições em e-commerce), possibilitando que a detecção de um ataque seja quase imediata.
Classificar:
Ao se visualizar e identificar um ataque DDoS, como podemos classificá-lo? Cada tipo de ataque pode ser respondido de uma forma específica.
Estou sendo alvo de um DNS amplification, SMURF, SYN flood?
Se você fez um bom trabalho na fase anterior, Classificar o ataque vai ser moleza.
Traceback:
De onde vem o ataque? Muitas vezes, os endereços de origem são falsos (spoofing) e pontos de entrada variam (multi-homed). Para reagir com eficácia precisamos saber como tais pacotes entram na nossa rede; e como e o que está sendo afetado. Basicamente, trata-se de saber o volume, quem são os alvos, de onde vem, o que comem, onde vivem, etc.
Reação ou remediação:
Após passar pelas três fases anteriores, sabemos exatamente o que fazer. Neste ponto, podemos utilizar todas as informações adquiridas nos passos de identificação, classificação e traceback para mitigar o ataque.
Neste momento, já devemos ter as seguintes informações:
- Em qual(quais) pontos de entrada da rede o tráfego está chegando?
- Qual o alvo do ataque?
- Qual o volume do ataque?
- O que mais, além do alvo, pode estar sendo afetado?
- Qual o perfil do ataque? (Sport, Dport, Proto, Target)
Com isto, podemos fazer uso de diversas ferramentas para nos auxiliar na mitigação do DDoS. Estas ferramentas são diversas, bem como suas aplicações.
Post mortem:
Aprenda com o incidente. O que deu certo? O que deu errado? O plano foi seguido corretamente? Saiu tudo como o esperado? O que podemos fazer melhor na próxima vez?
Ok. Mas eu sou um ISP, e não possuo nenhuma aplicação publicada externamente (que possa ser alvo). Por que estou lendo isto?
Mesmo que não exista a necessidade de um service provider de proteger seus próprios recursos, um ataque DDoS pode facilmente congestionar links em um backbone — causando um efeito generalizado onde diversos clientes podem ser afetados. Além disso, uma oferta de proteção contra DDoS é muitas vezes requerida pela maioria dos clientes.
Devido a importância em se preparar para reagir a tal ataque, uma infinidade de ferramentas e soluções nos ajudam a ter um plano de reação contra este tipo de ataque.
Estas ferramentas e soluções, e etc estão fora do escopo deste post.
Agora que sabemos o que fazer ao lidar com um DDoS, irei seguir este post do ponto de vista de um ISP. Mais especificamente, iremos nos utilizar de um
recurso muito popular para reduzir os efeitos de um ataque DDoS em um Service Provider: BGP Flowspec.
BGP Flowspec
Especificado na RFC 5575, o BGP Flowspec nada mais é do que uma “nova” extensão do protocolo BGP (AFI 1/SAFI 133(IPv4) ou 134(VPNv4) — AFI 2/SAFI 133(IPv6) ou SAFI 134(VPNv6)). Abaixo podemos ver a Capability para a AFI/SAFI IPv4 Flowspec como exemplo:
Esta nova extensão define métodos de distribuição de NLRI correspondente não a prefixos e reachability, mas “flows” individuais. Neste contexto, flows são geralmente identificados por doze tipos de componentes:
Type 1 — Destination Prefix
Type 2 — Source Prefix
Type 3 — IP Protocol
Type 4 — Port
Type 5 — Destination port
Type 6 — Source port
Type 7 — ICMP type
Type 8 — ICMP code
Type 9 — TCP flags
Type 10 — Packet length
Type 11 — DSCP
Type 12 — FragmentJunto ao NLRI correspondente a um determinado “flow”, existe também a sinalização de qual ação deverá ser tomada para este flow em específico. A RFC também sugere que a implementação suporte pelo menos as seguintes ações:
traffic-rate
traffic-action
redirect
traffic-markingSe olharmos a mensagem de update, facilmente vemos cada uma destas informações do NLRI:
O identificador AFI/SAFI a qual este NLRI pertence (1/133), contendo os seguintes campos de Filter:
- Destination ip/prefix: Type 1, Value 99.99.99.99/32
- Protocol(Next Header): Type 3, Value 17 (UDP)
- Destination port: Type 5, Value 80
- Source port filter: Type 6, Value 123
Através da sinalização BGP contendo o flow + ação a ser tomada, temos flexibilidade o suficiente para implementar tais filtros de uma forma dinâmica. Outro beneficio é que, diferente do RTBH, iremos descartar apenas o flow especificado — mantendo o host disponível para requisições validas que não se enquadram no flow anunciado através do Flowspec.
Com esta sinalização, teremos dois tipos de “Flowspec speakers”: Client e Server (ou Controller). O client, sendo responsável por receber políticas e fazer o enforcement; e o server, sendo responsável por codificar estas políticas no formato NLRI e distribuir aos clientes via BGP. Tanto o Server quanto o Client podem implementar (fazer o enforcement) da policy localmente. Caso o Server seja um RR, ou não esteja in-line com o tráfego, podemos omitir a instalação da policy em hardware:
flowspec
address-family ipv4
no local-install interface-allO estilo de CLI utilizado para configurar tais policies no flowspec controller é similar ao MQC: Class-map -> Policy-map -> Service-policy. Ao instalar a policy no modo “flowspec”, esta informação é repassada ao BGP e anunciada aos peers.
Os passos para configurar e distribuir uma policy são:
-> Habilitar BGP address-family flowspec + peerings (Client e Controller);
-> Identificar o Flow a ser distribuído (class-map type traffic) (Controller apenas);
-> Definir uma service-policy ePBR, incluindo ação a se tomar (Controller apenas);
-> Associar policies ao BGP Flowspec (Controller apenas);Bem, com estas informações, já temos o que precisamos para implementar o nosso filtro.
Vamos utilizar a seguinte topologia para configurar e validar uma política simples de flowspec:
Neste cenário, nosso servidor (R9 — 99.99.99.99/32), está sendo atacado pelo host R6. O protocolo que usaremos como exemplo será algo similar a um NTP amplification — porem destinado à porta UDP/80.
Ao mesmo tempo, R6, um cliente legítimo, deve continuar acessando a aplicação normalmente (qualquer que seja a aplicação). Ou seja, R9 não poderá ficar completamente indisponível. Ao mesmo tempo, PE-2 (xrv2) agirá como o Controller, anunciando a policy para o PE-1 (xrv1) — fazendo com que PE-1 descarte o tráfego localmente e não utilize nenhum recurso no backbone.
Nota: neste exemplo, vou usar routers virtuais. Infelizmente, nem IOS ou IOS-XE suportam completamente a feature flowspec — pois existem dependências de programação em HW que não são suportadas em todas plataformas virtuais :(. Neste exemplo, apenas irei mencionar as configs, e validar a interação no control-plane.
1) Habilitando peering utilizando address-family flowspec:
router bgp 5678
!
address-family ipv4 flowspec
!
neighbor 22.22.22.22
remote-as 5678
update-source Loopback0
address-family ipv4 flowspec
!2) Identificando o tráfego:
RP/0/0/CPU0:PE-2(config)#show
Tue Jan 15 09:12:36.098 UTC
!
class-map type traffic match-all DDoS
match source-port 123
match destination-port 80
match protocol udp
match destination-address ipv4 99.99.99.99 255.255.255.255
end-class-map
!3) Criando a ePBR para tomarmos uma ação sobre o tráfego:
RP/0/0/CPU0:PE-2(config)#show
Tue Jan 15 09:16:39.051 UTC
!
policy-map type pbr FLOWSPEC
class type traffic DDoS
drop
!
class type traffic class-default
!
end-policy-map
!4) Associar a policy à configuração Flowspec:
!
flowspec
local-install interface-all
address-family ipv4
local-install interface-all
service-policy type pbr FLOWSPEC
!
!Apos a configuração no modo flowspec, podemos verificar se o anúncio da policy pelo Controller foi recebido e instalado pelo Cliente.
Verificando os flows na tabela local (Controller):
RP/0/0/CPU0:PE-2#sh bgp ipv4 flow
Tue Jan 15 09:23:39.193 UTC
BGP router identifier 222.222.222.222, local AS number 5678
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 3
BGP main routing table version 3
BGP NSR Initial initsync version 1 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secsStatus codes: s suppressed, d damped, h history, * valid, > best
i — internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i — IGP, e — EGP, ? — incomplete
Network Next Hop Metric LocPrf Weight Path
*> Dest:99.99.99.99/32,Proto:=17,DPort:=80,SPort:=123/120
0.0.0.0 0 iRP/0/0/CPU0:PE-1#sh bgp ipv4 flow Dest:99.99.99.99/32,Proto:=17,DPort:=80,SPor$
Tue Jan 15 09:23:47.792 UTC
BGP routing table entry for Dest:99.99.99.99/32,Proto:=17,DPort:=80,SPort:=123/120
Versions:
Process bRIB/RIB SendTblVer
Speaker 3 3
Last Modified: Jan 15 09:23:14.487 for 00:00:33
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
0.0.0.0 from 0.0.0.0 (222.222.222.222)
Origin IGP, localpref 100, valid, redistributed, best, group-best
Received Path ID 0, Local Path ID 1, version 3
Extended community: FLOWSPEC Traffic-rate:5678,0
Agora, vemos que o cliente também já recebeu a policy:
RP/0/0/CPU0:PE-1#sh bgp ipv4 flowspec
Tue Jan 15 09:26:00.609 UTC
BGP router identifier 111.111.111.111, local AS number 5678
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 2
BGP main routing table version 2
BGP NSR Initial initsync version 1 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secsStatus codes: s suppressed, d damped, h history, * valid, > best
i — internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i — IGP, e — EGP, ? — incomplete
Network Next Hop Metric LocPrf Weight Path
*>iDest:99.99.99.99/32,Proto:=17,DPort:=80,SPort:=123/120
0.0.0.0 100 0 iRP/0/0/CPU0:PE-2# sh bgp ipv4 flo Dest:99.99.99.99/32,Proto:=17,DPort:=80,SPor$
Tue Jan 15 09:26:26.767 UTC
BGP routing table entry for Dest:99.99.99.99/32,Proto:=17,DPort:=80,SPort:=123/120
Versions:
Process bRIB/RIB SendTblVer
Speaker 2 2
Last Modified: Jan 15 09:24:51.535 for 00:01:35
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
0.0.0.0 from 22.22.22.22 (222.222.222.222)
Origin IGP, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 2
Extended community: FLOWSPEC Traffic-rate:5678,0
Olhando o anúncio recebido pelo client, podemos notar o seguinte:
Next-hop 0.0.0.0 -> Como não estamos utilizando o “Action” redirect, o next-hop sera 0.0.0.0.Extended Community -> Flowspec action. Neste caso, drop = traffic-rate 0.
Cada action possui um código de Type distinto, conforme a tabela abaixo:
Type /Sub — Extended community — Policy-map action
0x8006 — — traffic-rate <rate> — — — Drop / Police
0x8008 — — — redirect-vrf — — — — — Redirect VRF
0x8009 — — — traffic-marking — — — — set dscp
0x0800 — — - Redirect IP NH — — — -redirect ipv4[6] next-hop <ipv4[6]>
Olhando a diretamente na mensagem de update, podemos encontrar o formato da extended-community para a ação que configuramos:
Sucesso! Agora que a nossa policy já está configurada e distribuída, concluímos o nosso exemplo.
O próximo passo agora seria gerar tráfego e validar que a policy é programada conforme especificado. No entanto, como mencionei anteriormente, plataformas virtuais (exceto as mais robustas como 9Kv) atualmente não suportam a instalação de policies em HW.
Conclusão
Neste tópico falamos brevemente de Ataques DDoS, tocando alguns conceitos básicos e brevemente mencionamos como é um processo geral de resposta
à este tipo de incidente. Posteriormente, vimos a aplicação da implementação de Flowspec em BGP para nos ajudar a responder a tal tipo de evento de uma forma centralizada e dinâmica; finalizando com uma breve demonstração de configuração e interação no plano de controle (control-plane) utilizando IOS-XR.
E ai, já esta pronto para mitigar ataques DDoS?
Se curtiu este post, por que não estender a leitura e dominar ainda mais o assunto?
https://iot-analytics.com/state-of-the-iot-update-q1-q2-2018-number-of-iot-devices-now-7b/
https://n0where.net/layer-7-dos-dissecting-application-layer-ddos-attacks
https://tools.ietf.org/html/rfc5575
https://www.digitalattackmap.com/understanding-ddos/
https://zeltser.com/ddos-incident-cheat-sheet/
https://www.cloudflare.com/pt-br/learning/ddos/what-is-a-ddos-attack/
Se gostou do conteúdo, peço para compartilhar com outros do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow aí embaixo :)
Sobre o autor:
Bernardo, CCIE #57862
Cloud Network Engineer
