RTBH Remote Triggered Black Role Hugo de Sousa Ricardo, Samuel Tabanes Menon Redes e Segurança de Sistemas Pontifícia Universidade Católica do Paraná Curitiba, novembro de 2010 Resumo Apresentamos aqui um estudo sobre a solução RTBH Remote Triggered Black Role, também referenciado como Real-Time Blackhole Routing ou Blackhole Filtering para segurança de redes contra ataques internos de um sistema autônomo (AS) através do uso de atributos do protocolo de roteamento dinâmico Border Gateway Protocol (BGP). O diferencial da solução estudada é combinar as técnicas tradicionais de Black Role à feature Unicast Reverse Path Forwarding (urpf) para realizar a mitigação e bloqueio de um tráfego malicioso baseado no endereço IP de origem S-RTBH (Source - Remote Triggered Black Role), ou seja, bloquear o atacante e não o alvo atacado, o que garante a disponibilidade do serviço do host atacado ao resto da rede e economiza processamento e a banda que o suposto tráfego malicioso poderia ocupar na rede. 1 RTBH A solução de segurança interna Remote Triggered Black Role descarta os pacotes destinados a um determinado IP ou range de IPs nos roteadores de borda de um sistema autônomo, o que reduz o processamento dos roteadores e garante a disponibilidade do serviço prestado pelo host alvo do ataque. Esta solução geralmente é implementada com base no endereço de destino, ou seja, toda a rede BGP é configurada de forma que quando um host da rede é vítima de ataque, o seu endereço é redirecionado para descarte (Null0) através de mecanismos de roteamento do próprio BGP e este host fica invisível para todos os usuários durante o período de ataque. Tal prática é eficaz, porém, pouco eficiente porque o serviço prestado pela vítima do ataque fica indisponível para toda a rede e o fluxo de tráfego malicioso pode ocupar banda e processamento da rede até o seu descarte. Realizar o bloqueio com base no endereço de origem não é uma tarefa fácil de ser executada em função dos mecanismos que o atacante dispõe para mascarar ou alterar seu endereço durante um ataque. Além disso, o fluxo de tráfego malicioso pode ocupar processamento e banda da rede até alcançar o host alvo do ataque, causando danos ao serviço prestado e ser descartado somente na resposta ao host atacante. O desenho a seguir mostra uma macro-topologia de uma rede com os principais elementos que são os roteadores Customer Edge (CE) que fica instalado no cliente de uma rede; os roteadores Provider Edge (PE) que são os roteadores de borda de uma rede e concentram os clientes da rede; e os roteadores Provider (P) que formam o core da rede.
Figura 1 Macro-topologia de rede O modo convencional para configuração do RTBH em qualquer plataforma de roteadores consiste em: a) Criar uma rota de descarte nos roteadores de borda PE. Convém utilizar endereços reservados, como a rede 192.0.2.0/24 conforme RFC 3330. Com esta instrução de roteamento, é criado um buraco negro nas bordas da rede e qualquer tráfego com interesse na rede reservada será descartado pelos roteadores de borda da rede. b) Utilizar atributos do protocolo de roteamento BGP para orientar como a rede deve se comportar em uma situação de ataque. Com esta instrução, todas as rotas marcadas para descarte serão manipuladas de forma seu endereço de destino será alterado para o endereço reservado. c) Configurar a rota gatilho para descarte quando um ataque for detectado. Os mecanismos de análise de rede e descoberta de ataque podem ser realizados com ferramentas de mercado e a configuração da rota gatilho na rede pode feita manual ou dinamicamente, dependendo da ferramenta de inspeção de rede que será utilizada. O quadro abaixo exibe o exemplo de um template de configuração de RTBH baseado em IOS de roteadores Cisco System, porém, não se trata de uma solução proprietária e o mesmo template pode ser traduzido na linguagem de outros fabricantes. Roteador_PE(config)# ip route 192.0.2.0 255.255.255.0 Null 0 ------- Roteador_P(config)# route-map RTBH Roteador_P(config-route-map)# match tag 666 Roteador_P(config-route-map)# set ip next-hop 192.0.2.1 Roteador_P(config-route-map)# set origin igp Roteador_P(config-route-map)# set community no-export Roteador_P(config)# roteador bgp 65100 Roteador_P(config-roteador)# redistribute static route-map RTBH Roteador_P(config)# ip route 172.16.10.100 255.255.255.255 Null0 tag 666 Figura 2 Template de Configuração RTBH em IOS Cisco System No quadro acima, devemos entender que a rede do AS de número 65100 está sendo atacada por um host com endereço 172.16.10.100 ou que tenha este IP como alvo do ataque. A solução de RTBH irá utilizar os atributos do BGP para substituir esse endereço por outro
reservado 192.0.2.1, de acordo com a RFC3330 e propagar para todos os roteadores de borda PE que possuem uma rota estática de descarte para o range reservado. Está criado o buraco negro e todos os pacotes endereçados originalmente para 172.16.10.100 serão descartados na rede. A figura 3 a seguir mostra uma rede sem a proteção RTBH. O ataque chega pelos roteadores de borda PE A, B, C, D e E em direção a um dos clientes da rede. O Centro de operações de Rede - NOC não percebe o ataque e o controle da rede é perdido. Figura 3 Exemplo de ataque a um Customer Edge CE Figura 4 Exemplo de ataque controlado pelo RTBH
A figura 4 exibe uma rede sob o mesmo tipo de ataque, porém, com a proteção do RTBH. Agora o NOC possui gerência da rede e quando percebe a tentativa de ataque irá utilizar a solução para inserir a rota de descarte no roteador G que irá propagar via BGP a rota para todos os roteadores de borda PE que deverão descartar o tráfego com destino a rede do cliente alvo quando baseado em destino ou bloquear os endereços que originaram o ataque quando baseado em origem e a rede fica protegida deste tráfego indesejado. 2 urpf O urpf (Unicast Reverse Path Forwarding) possui a função de ajudar a mitigar os problemas que são causados por pacotes mal formados (spoofed), em que se podem gerar pacotes novos diretamente de uma aplicação, colocando qualquer valor no campo do endereço de origem do IP sem o receptor saber que a fonte é falsa. Existem vários tipos de ataques do tipo DoS (Denial of Service), como por exemplo, Smurfs e TFN (Tribe Flood Network) em que alteram a o campo de origem dos pacotes para dificultar sua localização ou filtro pelas vitimas. O urpf é uma defesa desse tipo de ataque fazendo que somente pacotes com o campo de origem IP validos e consistentes com a tabela de roteamento sejam enviados aos seus destinos. O Unicast Reverse Path Forwarding, utilizado para evitar a falsificação de endereço de origem, utilizando de um recurso que permite ao roteador ver se algum pacote de IP recebido em uma interface do roteador aparece no melhor caminho de retorno (rota de retorno) para o endereço de origem do pacote. Se o pacote for recebido de uma das melhores rotas de caminho reverso, o pacote é encaminhado como normal. Se não houver rota de caminho reverso na mesma interface da qual o pacote foi recebido, o pacote é cancelado ou encaminhado, dependendo se uma lista de controle de acesso (ACL). Na solução RTBH, o urfp é configurado em todas as interfaces de entrada dos roteadores de borda PE, para que o tráfego indesejado seja descartado já na borda da rede de maneira a não consumir recurso como processamento e banda dos roteadores internos da rede. 2.1 Funcionamento do urpf Quando urpf está habilitado em uma interface, o roteador examinará todos os pacotes recebidos na entrada (input) da mesma para confirmar se o IP e interface de origem estão na tabela de roteamento, para assim confirmar que são pacotes válidos. O pacote é valido se for recebido de uma das melhores rotas de caminho reverso, isto é, rota de retorno até o endereço de origem do pacote é valida. Caso o pacote chegue à entrada da interface e seja confirmado como válido, então o pacote é encaminhado normalmente. Caso o pacote chegue à entrada da interface e seja confirmado como inválido, isto é, o IP ou interface de origem não estão na tabela de roteamento, então este pacote será descartado pelo mecanismo do urpf no roteador. 2.2 Modos de implementação de filtros de entrada De acordo com as RFCs 2827 e 3704, podemos citar 4 tipos diferentes de filtros para ataques mais utilizados: a) Ingress Access Lists (ACL) Uma ACL nada mais é que uma seqüência de instruções que permitem ou negam acesso a determinada rede ou recursos disponíveis em outras redes. Cada pacote recebido na interface de rede será verificado na seqüência de instruções que pode aceitar prefixos, descartarem pacotes
que não são estão permitidos nas regras da ACL. As ACL são criadas e atualizadas manualmente, cabendo ao administrador de rede a sua manutenção para permitir acessos legítimos e restringir os não legítimos a rede. b) Strict Reverse Path Forwarding (Strict RPF) Funciona de forma similar a uma ACL de entrada, mas de forma dinâmica diminuindo as chances de informações duplicadas da ACL. Cada pacote ao passar pela entrada da interface é verificado se endereço de origem se encontra na tabela FIB (Forwarding Information Base), se existir é encaminhado. Caso o a interface de origem não for o melhor caminho reverso para a origem o pacote ira falhar e ser descartado. c) Feasible Path Reverse Path Forwarding (Feasible RPF) É uma extensão do Strict RPF, onde o endereço de origem do pacote é verificado na FIB. Porem invés de inserir somente a melhor rota, também se insere as rotas alternativas que serão validas para consideração, assim a FIB mantém rotas alternativas para o endereço IP. Se a interface de entrada coincidir com uma das rotas associado com o endereço IP, então o pacote é encaminhado. Caso contrário o pacote é descartado. Este tipo é utilizado em redes assimétricas. d) Loose Reverse Path Forwarding Funciona de forma similar ao Strict RPF, porém a diferença que é que se checa somente se a existência da rota, não importando para o local aonde a rota aponta. Cada pacote ao passar pela entrada da interface é verificado se endereço de origem se encontra na tabela FIB (Forwarding Information Base), o pacote somente será descartado se o endereço de origem não puder ser alcançado por nenhuma interface do roteador, caso seja possível, o pacote será encaminhado. Os modos mais utilizados são Strict RPF e Loose RPF, o foco desse trabalho serão esses modos. Existem outros métodos, técnicas ou variações que não serão tratadas nesta pesquisa por não ser foco. 2.3 Strict Versus Loose modos de checagem O modo Strict de checagem verifica se a fonte do endereço IPv4 de um pacote existe na tabela de roteamento e se o endereço de origem desse pacote IPv4 é alcançável por algum caminho através da interface de entrada (a mesma interface por onde o pacote entrou no roteador), ideal para redes simétricas. O modo Loose de checagem verifica se o endereço de origem do pacote IPv4 existe na tabela de roteamento e se existe um caminho alcançável para o endereço de origem por qualquer interface existente na FIB (Forwarding Information Base), ideal para redes assimétricas. 2.4 Descrição do urpf no modo Strict detalhada Quando o URPF está habilitado em uma interface, o roteador examina todos os pacotes IPv4 recebidos na entrada da interface para garantir que o endereço de origem e interface de origem estão na tabela de roteamento e a interface que recebeu o pacote é a mesma. Em roteadores Cisco System, a habilidade de verificar o caminho reverso se encontra na CEF (Cisco express forwarding) que é uma tabela baseada no que os outros fabricantes utilizam, a FIB (Forwarding Information Base) para utilizar a feature urpf. O urpf strict verifica se qualquer pacote IPv4 recebido na interface possui a melhor rota para o seu retorno até a origem do pacote realizando uma busca reversa na tabela CEF ou FIB (reverse lookup).
Se o pacote é recebido de uma das melhores rotas reversas, o pacote é encaminhado normalmente. Se nenhuma rota reversa existe para a mesma interface que o roteador recebeu o pacote, significa que a origem do pacote IPv4 foi modificada. Se o urpf não encontrar uma rota reversa para o pacote, o pacote é descartado. Quando um pacote é recebido em uma interface na qual está configurado urpf no modo restrito (strict) as seguintes ações são realizadas: a) Verifica se o pacote recebido possui a melhor rota para a origem, o que é realizado fazendo uma busca reversa na tabela FIB. b) Realiza busca na tabela CEF/FIB para encaminhar o pacote. c) O pacote IPv4 é encaminhado. A figura 5 a seguir mostra como urpf no modo strict e a CEF em roteadores Cisco System funcionam em conjunto para validar a origem de um endereço IP com a verificação do caminho de retorno do pacote. No exemplo, o cliente envia um pacote com a origem 192.168.1.1 da interface FDDI 2/0/0. o urpf verifica se na FIB existe uma rota para o IP 192.168.1.1 e pelo caminho FDDI 2/0/0. Se encontrar um caminho, o pacote é encaminhado (enviado). Se não encontrar um caminho o pacote é descartado. Figura 5 Validação do endereço de origem IP pelo urpf A figura 6 a seguir mostra como o urpf no modo strict descarta pacotes que falham na validação. No exemplo o cliente envia um pacote com o endereço de origem 209.165.200.225 que é recebido na interface FDDI 2/0/0. O urpf verifica a FIB pelo IP 209.165.200.225 e se possui um caminho reverso pela interface FDDI 2/0/0. Se existir o caminho, o pacote é encaminhado. Mas nesse caso, não existe caminho reverso na tabela de roteamento para o destino
do cliente (origem IP 209.165.200.225) na interface FDDI 2/0/0, com isso o pacote deve ser descartado. Figura 6 Validação do endereço de origem IP pelo urpf 2.5 Proteção de endereço de origem IP Spoofing Pacotes podem ter o seu endereço IP de origem alterados (forjados) para na maioria das vezes serem utilizados para ataques a rede por meio de não permitir o rastreamento e contornar as listas de acesso. São chamados de ataques do tipo Denial-of-Service (DoS) que usam como vantagem a troca rápida dos IPs de origem enganar os esforços para localizar ou filtras ataques. Um endereço IP forjado também pode ser usado para ataque direto a um IP de origem forjado (conhecido como ataque refletido). A RFC 2827 define um filtro de entrada de tráfego que tem como requerimento o descarte de pacotes com IP de origem inválidos. Exemplos de endereços de IP inválidos: - Endereço IP de rede que não foi originado da rede. - Endereços IP alocados para redes privadas (intranets) ou alocados de blocos de rede específicos da RFC 1918. Deve-se habilitar o urpf no modo strict nos roteadores PE próximos a borda com os clientes. Os filtros de tráfego na entrada do PE minimizam o numero de blocos de IPs válidos e descarta os IPs inválidos mais perto possível de sua origem.
3 Prova de conceito Para realização da prova de conceito, utilizamos o cenário de rede simplificado conforme figura 7 sem considerar as melhore práticas de design de rede que prevê redundância de elementos. Utilizamos o software GNS3 para simular roteadores com templates baseados em IOS Cisco System com um ambiente baseado em redes MPLS-VPN4 que é a realidade da maioria das redes atuais no mercado e atesta o funcionamento da solução RTBH em redes complexas. Figura 7 Cenário de rede usado para prova de conceito O cenário de prova de conceito é composto pelos seguintes elementos: a) Roteador TRIGGER ou gatilho A função deste roteador é receber, manual ou dinamicamente, a informação de ataque e propagar a rota com marcação de descarte (tag) para a rede. Embora esta função possa ser executada por um roteador P da rede, de com as melhores práticas, este roteador deve ser exclusivo para a função de gatilho. b) Roteador P Este roteador irá desempenhar o papel de refletor de roteamento da rede BGP, também conhecido como Route-Reflector (RR) é o roteador que propaga as informações de roteamento para toda a rede via protocolo de roteamento dinâmico BGP. c) Roteador de borda PE Também conhecido como Provider Edge (PE) é o roteador que delimita a camada de distribuição da rede e que faz a transição entre o core e o acesso aos Customer Edge (CE), concentrando os enlaces com a rede de clientes. Nesta proposta, vamos utilizar a feature urpf nos roteadores de borda PE no modo loose, para permitir o roteamento assimétrico de forma que o urpf, durante o seu processo de validação, verifique se o pacote pode ser enviado de volta para a origem por qualquer uma de suas interfaces, caso contrário, o pacote é descartado no próprio roteador PE, evitando que o mesmo seja encaminhado para o servidor ou host alvo do ataque. As figuras a seguir, exibem o template de configuração utilizado, baseados em IOS Cisco System para GNS3, destacando que não se trata de uma solução proprietária e que na sua aplicação real, deve-se verificar compatibilidade de hardware e versão de software adequados à configuração que se deseja implementar.
ip vrf POC rd 65100:80 route-target export 65100:80 router bgp 65100 no synchronization bgp router-id 172.27.2.10 bgp log-neighbor-changes timers bgp 10 30 neighbor POC peer-group neighbor POC remote-as 65100 neighbor POC update-source Loopback0 neighbor 172.27.2.100 peer-group POC no auto-summary address-family vpnv4 neighbor POC activate neighbor POC send-community both neighbor POC route-map RTBH out neighbor 172.27.2.100 peer-group POC exit-address-family address-family ipv4 vrf POC no auto-summary no synchronization redistribute static route-map RTBH exit-address-family ip bgp-community new-format route-map RTBH permit 10 match tag 666 set local-preference 1000 set origin igp set community 65100:666 no-export route-map RTBH deny 20 end Figura 8 Template básico de configuração do roteador TRIGGER
ip cef interface Null0 no ip unreachables router bgp 65100 bgp router-id 172.27.2.100 no bgp default ipv4-unicast bgp log-neighbor-changes timers bgp 10 30 neighbor POC peer-group neighbor POC remote-as 65100 neighbor POC update-source Loopback0 neighbor POC route-map RTBH in neighbor 172.27.2.10 peer-group POC neighbor 172.27.2.20 peer-group POC neighbor 172.27.2.30 peer-group POC address-family ipv4 neighbor POC activate no auto-summary no synchronization exit-address-family address-family vpnv4 neighbor POC activate neighbor POC send-community both neighbor POC route-reflector-client neighbor 172.27.2.10 peer-group POC neighbor 172.27.2.20 peer-group POC neighbor 172.27.2.30 peer-group POC exit-address-family ip extcommunity-list 1 permit rt 65100:666 route-map RTBH permit 10 match extcommunity 1 set ip next-hop 192.0.2.1 route-map RTBH permit 20 ip route 192.0.2.0 255.255.255.0 Null0 tag 666 ip route vrf POC 192.0.2.0 255.255.255.0 Null0 tag 666 end Figura 9 Template básico de configuração do roteador P Router Reflector
ip cef interface Null0 no ip unreachables interface <tipo> <slot>/<porta> ip verify unicast source reachable-via any allow-default router bgp 65100 bgp router-id 172.27.2.20 no bgp default ipv4-unicast bgp log-neighbor-changes timers bgp 10 30 neighbor POC peer-group neighbor POC remote-as 65100 neighbor POC update-source Loopback0 neighbor POC route-map RTBH in neighbor 172.27.2.100 peer-group POC address-family ipv4 neighbor POC activate no auto-summary no synchronization exit-address-family address-family vpnv4 neighbor POC activate neighbor POC send-community both neighbor 172.27.2.100 peer-group POC exit-address-family ip extcommunity-list 1 permit rt 65100:666 route-map RTBH permit 10 match extcommunity 1 set ip next-hop 192.0.2.1 route-map RTBH permit 20 ip route 192.0.2.0 255.255.255.0 Null0 tag 666 ip route vrf POC 192.0.2.0 255.255.255.0 Null0 tag 666 end Figura 10 Template básico de configuração dos roteadores PE
A ativação da solução é engatilhada com a adição da rota estática com a marcação de descarte depois de detectado o ataque. Está configuração é executada no roteador TRIGGER, com um comando conforme mostrado na figura 11 a seguir baseado em IOS Cisco System: ip route vrf POC <IP host/rede origem> <subnet mask> Null0 tag 666 Figura 11 Comando de inserção da rota de descarte Para que o tráfego destinado a esta rede volte a funcionar corretamente, será necessário atuar manual ou dinamicamente no roteador TRIGGER, removendo a rota estática e aguardando a atualização de roteamento dinâmico BGP dos roteadores PE. A propagação da rota na rede é feita através do protocolo BGP. Ao inserir uma rota estática no roteador trigger, o BGP exporta essa rota com a informação do atributo community com valor igual a 65100:666. Para distinguir quais rotas devem ser encaminhadas com esse valor de community é utilizada uma TAG na rota estática. Ao receber essa informação de roteamento, o roteador de borda PE altera o valor de nexthop para 192.0.2.1, informando ao roteador que o tráfego será encaminhado à interface Null0 para descarte. Além disso, o BGP também adiciona a informação de community no-export, para que a rota não seja encaminhada para um vizinho ebgp. O funcionamento do RTBH no roteador de borda PE segue o seguinte fluxo: Figura 12 - Fluxo de funcionamento do RTBH no roteador PE
O funcionamento do RTBH no roteador TRIGGER segue o seguinte fluxo: Figura 13 - Fluxo de funcionamento do RTBH no roteador TRIGGER 3.1 Resultados obtidos na prova de conceito Validamos o funcionamento do protocolo de roteamento BGP para bloqueio de host malicioso. O teste consistiu em bloquear a tentativa de ataque bloqueando o acesso do host de endereço 1.1.1.1. Desta forma, inserimos manualmente uma rota estática conforme figura 14 a seguir no roteador TRIGGER: ip route vrf POC 1.1.1.1 255.255.255.255 Null0 tag 666 Figura 14 - Comando de inserção da rota de descarte Com esta configuração, o roteador TRIGGER executou as instruções indicadas nas routemaps a fim de agregar atributos alterando os valores de local-preference, origin e agregando a tag 666 para divulgar a rota para o roteador P que faz a função de Router-Reflector propagando a rota para os roteadores PE. A saída dos comandos baseados em IOS Cisco System do quadro 15 a seguir demonstram funcionamento da configuração.
Router_P#sh ip bgp vpnv4 all 1.1.1.1 BGP routing table entry for 65100:80:1.1.1.1/32, version 2 Paths: (1 available, best #1, no table, not advertised to EBGP peer) Flag: 0x820 Advertised to update-groups: 1 Local, (Received from a RR-client) 172.27.2.26 (metric 2) from 172.27.2.26 (172.27.2.26) Origin IGP, metric 0, localpref 1000, valid, internal, best Community: 65100:666 no-export mpls labels in/out nolabel/20 PE#sh ip bgp vpnv4 all 1.1.1.1 BGP routing table entry for 65100:80:1.1.1.1/32, version 10 Paths: (1 available, best #1, no table, not advertised to EBGP peer) Flag: 0x820 Not advertised to any peer Local 172.27.2.26 (metric 3) from 172.27.2.100 (172.27.2.100) Origin IGP, metric 0, localpref 1000, valid, internal, best Community: 65100:666 no-export Originator: 172.27.2.26, Cluster list: 0.0.0.11, BGP routing table entry for 65100:902010001:1.1.1.1/32, version 11 Paths: (1 available, best #1, table POC, not advertised to EBGP peer) Flag: 0x820 Not advertised to any peer Local, imported path from 65100:80:1.1.1.1/32 172.27.2.26 (metric 3) from 172.27.2.100 (172.27.2.100) Origin IGP, metric 0, localpref 1000, valid, internal, best Community: 65100:666 no-export Originator: 172.27.2.26, Cluster list: 0.0.0.11, Figura 15 Funcionamento do route-map RTBH Quando recebeu o anúncio via BGP com a tag 666 e melhor local-prefence, o roteador de PE, por sua vez, executou as instruções indicadas na route-map substituindo o next-hop original do host malicioso 1.1.1.1 para 192.0.2.1. Esta rede está reservada para descarte na rede e possui rota estaticamente configurada para Null0 em todos os roteadores PE. Desta maneira, temos a seguinte saída de roteamento comprovando o bloqueio do host malicioso no roteador PE. Router_PE#sh ip cef vrf POC Prefix Next Hop Interface 0.0.0.0/0 no route 0.0.0.0/32 receive 1.1.1.1/32 192.0.2.1 Null0 192.0.2.0/24 attached Null0 Router_PE#sh ip cef vrf POC 1.1.1.1 1.1.1.1/32, version 5, epoch 0 0 packets, 0 bytes tag information set, all rewrites owned local tag: VPN route head via 192.0.2.1, 0 dependencies, recursive next hop 192.0.2.1, Null0 via 192.0.2.0/24 (Default) valid null adjacency Figura 16 Funcionamento do route-map RTBH
Bibliografia [1] Cisco System Documents (www.cisco.com) [2] IETF Documents (http://tools.ietf.org) [3] PacketLife.net (http://packetlife.net) [4] Pierky s Blog (http://pierky.wordpress.com)