RTBH – Remote Triggered Black Role

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.
<ommited>
ip vrf POC
rd 65100:80
route-target export 65100:80
!
<ommited>
!
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
!
<ommited>
!
ip bgp-community new-format
!
<ommited>
!
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
<ommited>
end
Figura 8 – Template básico de configuração do roteador TRIGGER
<ommited>
!
ip cef
<ommited>
!
interface Null0
no ip unreachables
!
<ommited>
!
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
!
<ommited>
!
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
!
<ommited>
end
Figura 9 – Template básico de configuração do roteador P – Router Reflector
<ommited>
!
ip cef
<ommited>
!
interface Null0
no ip unreachables
!
interface <tipo> <slot>/<porta>
ip verify unicast source reachable-via any allow-default
!
<ommited>
!
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
!
<ommited>
!
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
!
<ommited>
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)