Autenticação de rota BGP
Entendendo a autenticação do roteador para BGP
O uso de autenticação de roteadores e rotas e integridade de rotas reduz consideravelmente o risco de ser atacado por uma máquina ou roteador que foi configurado para compartilhar informações incorretas de roteamento com outro roteador. Nesse tipo de ataque, o roteador atacado pode ser enganado para criar um loop de roteamento, ou a tabela de roteamento do roteador atacado pode ser muito aumentada, afetando o desempenho, ou as informações de roteamento podem ser redirecionadas para um lugar na rede para que o invasor a analise. Anúncios de rota falsos podem ser enviados em um segmento. Essas atualizações podem ser aceitas nas tabelas de roteamento de roteadores vizinhos, a menos que um mecanismo de autenticação esteja em vigor para verificar a origem das rotas.
A autenticação de roteadores e rotas permite que os roteadores compartilhem informações apenas se eles podem verificar se estão conversando com uma fonte confiável, com base em uma senha (chave). Neste método, uma chave hashed é enviada junto com a rota que está sendo enviada para outro roteador. O roteador receptor compara a chave enviada com sua própria chave configurada. Se eles são os mesmos, ele aceita a rota. Ao usar um algoritmo de hashing, a chave não é enviada pelo fio em texto simples. Em vez disso, um hash é calculado usando a chave configurada. A atualização de roteamento é usada como texto de entrada, juntamente com a chave, para a função de hashing. Este hash é enviado junto com a atualização de rota para o roteador receptor. O roteador receptor compara o hash recebido com um hash que ele gera na atualização de rota usando a chave pré-compartilhada configurada nele. Se os dois hashes forem os mesmos, a rota é assumida como sendo de uma fonte confiável. A chave é conhecida apenas pelos roteadores de envio e recebimento.
Para fortalecer ainda mais a segurança, você pode configurar uma série de chaves de autenticação (um chaveiro). Cada chave tem um tempo de início único dentro do chaveiro. A autenticação de keychain permite que você altere as informações de senha periodicamente sem reduzir as sessões de peering. Este método de autenticação de keychain é chamado de "hitless" porque as chaves rolam de um para o outro sem redefinir nenhuma sessão de peering ou interromper o protocolo de roteamento.
O ponto de envio usa as seguintes regras para identificar a chave de autenticação ativa:
O tempo de início é menor ou igual ao tempo atual (ou seja, não no futuro).
O tempo de início é maior do que o de todas as outras chaves da cadeia, cujo tempo de início é menor do que o tempo atual (em outras palavras, mais próximo do tempo atual).
O peer receptor determina a chave com a qual autentica com base no identificador de chave de entrada.
O peer de envio identifica a chave de autenticação atual com base em um tempo de início configurado e depois gera um valor de hash usando a chave atual. Em seguida, o peer de envio insere um objeto de opção de autenticação aprimorado por TCP na mensagem de atualização do BGP. O objeto contém uma ID do objeto (atribuído pela IANA), o comprimento do objeto, a chave atual e um valor de hash.
O peer receptor examina a opção de autenticação aprimorada por TCP de entrada, analisa a chave de autenticação recebida e determina se a chave é aceitável com base no tempo de início, no tempo do sistema e no parâmetro de tolerância. Se a chave for aceita, o peer receptor calcula um hash e autentica a mensagem de atualização.
A aplicação inicial de um chaveiro em uma sessão de TCP faz com que a sessão seja reiniciada. No entanto, uma vez que o keychain é aplicado, a adição ou remoção de uma senha do chaveiro não faz com que a sessão de TCP seja reiniciada. Além disso, a sessão de TCP não é redefinida quando o keychain muda de um algoritmo de autenticação para outro.
Consulte também
Autenticação de TCP
Normalmente, você configura a autenticação de TCP nos seguintes níveis de hierarquia:
-
[edit protocols bgp] -
[edit protocols bgp group group-name] -
[edit protocols bgp group group-name neighbor address]
Sub-redes de autenticação e prefixo do TCP
Os dispositivos Junos oferecem suporte à autenticação de TCP aos pares BGP que são descobertos por meio de sub-redes de prefixo permitidas configuradas em um grupo BGP.
Para configurar a autenticação baseada em prefixo para TCP-AO ou TCP MD5 para sessões BGP, você pode configurar a declaração nas seguintes hierarquias:allow (all | prefix-list)
-
[edit protocols bgp group group-name] -
[edit protocols bgp group group-name dynamic-neighbor dyn-name]
Para obter mais informações sobre a autenticação do TCP, consulte TCP.Configure TCP Options
Exemplo: Configuração da autenticação do roteador para BGP
Todas as trocas de protocolo BGP podem ser autenticadas para garantir que apenas dispositivos de roteamento confiáveis participem de atualizações de roteamento autônomas de sistema (AS). Por padrão, a autenticação é desativada.
Requisitos
Antes de começar:
Configure as interfaces do roteador.
Configure um protocolo de gateway interior (IGP).
Visão geral
Ao configurar a autenticação, o algoritmo cria um checksum codificado que está incluído no pacote transmitido. O dispositivo de roteamento receptor usa uma chave de autenticação (senha) para verificar o checksum do pacote.
Este exemplo inclui as seguintes declarações para configurar e aplicar o chaveiro:
key— Um chaveiro pode ter várias chaves. Cada chave dentro de um chaveiro deve ser identificada por um valor único de inteiro. A faixa de valores de identificador válidos é de 0 a 63.A chave pode ter até 126 caracteres de comprimento. Os caracteres podem incluir quaisquer strings ASCII. Se você incluir espaços, inclua todos os caracteres entre aspas (" ").
tolerance— (Opcional) Para cada chaveiro, você pode configurar um valor de tolerância com desvio de clock em segundos. A tolerância a desvios de relógio é aplicável ao receptor que aceita chaves para atualizações BGP. A faixa configurável é de 0 a 999.999.999 segundos. Durante o período de tolerância, a senha atual ou anterior é aceitável.key-chain— Para cada chaveiro, você deve especificar um nome. Este exemplo define um chaveiro:bgp-auth. Você pode ter várias poltronas em um dispositivo de roteamento. Por exemplo, você pode ter um chaveiro para BGP, um chaveiro para OSPF e um chaveiro para LDP.secret— Para cada chave no chaveiro, você deve definir uma senha secreta. Essa senha pode ser inserida em formato de texto criptografado ou simples na declaração.secretEle é sempre exibido em formato criptografado.start-time— Cada chave deve especificar um horário de início no formato UTC. O controle é passado de uma chave para outra. Quando um horário de início configurado chega (com base no relógio do dispositivo de roteamento), a chave com esse tempo de início fica ativa. Os horários de início são especificados no fuso horário local para um dispositivo de roteamento e devem ser exclusivos dentro do chaveiro.authentication-key-chain— permite que você aplique uma chaveiro no nível BGP global para todos os pares, para um grupo ou para um vizinho. Este exemplo aplica a chaveiro aos pares definidos no grupo BGP externo (EBGP) chamado .extauthentication-algorithm— Para cada chaveiro, você pode especificar um algoritmo de hashing. O algoritmo pode ser AES-128, MD5 ou SHA-1.Você associa um chaveiro e um algoritmo de autenticação a uma sessão vizinha de BGP.
Este exemplo configura um chaveiro chamado .bgp-auth A chave 0 será enviada e aceita a partir de 2011-6-23.20:19:33 -0700, e deixará de ser enviada e aceita quando a próxima chave na chave (chave 1) ficar ativa. A Chave 1 fica ativa um ano depois, em 2012-6-23.20:19:33 -0700, e não deixará de ser enviada e aceita a menos que outra chave seja configurada com um tempo de início mais tarde do que o horário de início da chave 1. Uma tolerância de desvio de relógio de 30 segundos se aplica ao receptor que aceita as chaves. Durante o período de tolerância, a chave atual ou anterior é aceitável. As chaves são senhas secretas compartilhadas. Isso significa que os vizinhos que recebem as atualizações de roteamento autenticadas devem ter a mesma configuração de chaveiro de autenticação, incluindo as mesmas chaves (senhas). Assim, o Roteador R0 e o Roteador R1 devem ter a mesma configuração de cadeia de autenticação-chave se estiverem configurados como pares. Este exemplo mostra a configuração em apenas um dos dispositivos de roteamento.
Diagrama de topologia
Figura 1 mostra a topologia usada neste exemplo.
Configuração
Configuração rápida da CLI
Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere os detalhes necessários para combinar com a configuração da sua rede e, em seguida, copie e cole os comandos no CLI no nível de hierarquia.[edit]
set protocols bgp group ext type external set protocols bgp group ext peer-as 65530 set protocols bgp group ext neighbor 172.16.2.1 set routing-options autonomous-system 65533 set protocols bgp group ext authentication-key-chain bgp-auth set protocols bgp group ext authentication-algorithm md5 set security authentication-key-chains key-chain bgp-auth tolerance 30 set security authentication-key-chains key-chain bgp-auth key 0 secret this-is-the-secret-password set security authentication-key-chains key-chain bgp-auth key 0 start-time 2011-6-23.20:19:33-0700 set security authentication-key-chains key-chain bgp-auth key 1 secret this-is-another-secret-password set security authentication-key-chains key-chain bgp-auth key 1 start-time 2012-6-23.20:19:33-0700
Procedimento
Procedimento passo a passo
O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.Use o editor de CLI no modo de configuraçãohttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
Para configurar o Roteador R1 para aceitar filtros de rota do dispositivo CE1 e realizar filtragem de rota de saída usando os filtros recebidos:
Configure o sistema autônomo local.
[edit routing-options] user@R1# set autonomous-system 65533
Configure um ou mais grupos BGP.
[edit protocols bgp group ext] user@R1# set type external user@R1# set peer-as 65530 user@R1# set neighbor 172.16.2.1
Configure a autenticação com várias chaves.
[edit security authentication-key-chains key-chain bgp-auth] user@R1# set key 0 secret this-is-the-secret-password user@R1# set key 0 start-time 2011-6-23.20:19:33-0700 user@R1# set key 1 secret this-is-another-secret-password user@R1# set key 1 start-time 2012-6-23.20:19:33-0700
O tempo de início de cada chave deve ser único dentro do chaveiro.
Aplique o keychain de autenticação no BGP e defina o algoritmo de hashing.
[edit protocols bgp group ext] user@R1# set authentication-key-chain bgp-auth user@R1# set authentication-algorithm md5
(Opcional) Aplique um valor de tolerância com desvio de relógio em segundos.
[edit security authentication-key-chains key-chain bgp-auth] user@R1# set tolerance 30
Resultados
A partir do modo de configuração, confirme sua configuração entrando no , e comandos.show protocolsshow routing-optionsshow security Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
user@R1# show protocols
bgp {
group ext {
type external;
peer-as 65530;
neighbor 172.16.2.1;
authentication-key-chain bgp-auth;
authentication-algorithm md5;
}
}
user@R1# show routing-options autonomous-system 65533;
user@R1# show security
authentication-key-chains {
key-chain bgp-auth {
tolerance 30;
key 0 {
secret $ABC123$ABC123
start-time “2011-6-23.20:19:33 -0700”;
}
key 1 {
secret $ABC123$ABC123
start-time “2012-6-23.20:19:33 -0700”;
}
}
}
Se você terminar de configurar o dispositivo, entre no modo de configuração.commit
Repita o procedimento para todos os dispositivos habilitados para BGP na rede, usando os nomes e endereços de interface apropriados para cada dispositivo habilitado para BGP.
Verificação
Confirme se a configuração está funcionando corretamente.
- Verificando a autenticação para o vizinho
- Verificando se as mensagens de autorização são enviadas
- Verificando erros de autenticação
- Verificando a operação do chaveiro
Verificando a autenticação para o vizinho
Propósito
Certifique-se de que a opção aparece na saída do comando.AutheKeyChainshow bgp neighbor
Ação
A partir do modo operacional, entre no comando.show bgp neighbor
user@R1> show bgp neighbor
Peer: 172.16.2.1+179 AS 65530 Local: 172.16.2.2+1222 AS 65533
Type: External State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ direct-lo0 ]
Options: <Preference PeerAS Refresh>
Options: <AutheKeyChain>
Authentication key is configured
Authentication key chain: jni
Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 172.16.2.1 Local ID: 10.255.124.35 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
Local Interface: fe-0/0/1.0
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 2
Received prefixes: 2
Suppressed due to damping: 0
Advertised prefixes: 1
Last traffic (seconds): Received 2 Sent 2 Checked 2
Input messages: Total 21 Updates 2 Refreshes 0 Octets 477
Output messages: Total 22 Updates 1 Refreshes 0 Octets 471
Output Queue[0]: 0Verificando se as mensagens de autorização são enviadas
Propósito
Confirme que o BGP tem a opção de autorização aprimorada.
Ação
A partir do modo operacional, entre no comando.monitor traffic interface fe-0/0/1
user@R1> monitor traffic interface fe-0/0/1 verbose output suppressed, use <detail> or <extensive> for full protocol decode Listening on fe-0/0/1, capture size 96 bytes 13:08:00.618402 In arp who-has 172.16.2.66 tell 172.16.2.69 13:08:02.408249 Out IP 172.16.2.2.1122 > 172.16.2.1.646: P 1889289217:1889289235(18) ack 2215740969 win 58486 <nop,nop,timestamp 167557 1465469,nop,Enhanced Auth keyid 0 diglen 12 digest: fe3366001f45767165f17037>: 13:08:02.418396 In IP 172.16.2.1.646 > 172.16.2.2.1122: P 1:19(18) ack 18 win 57100 <nop,nop,timestamp 1466460 167557,nop,Enhanced Auth keyid 0 diglen 12 digest: a18c31eda1b14b2900921675>: 13:08:02.518146 Out IP 172.16.2.2.1122 > 172.16.2.1.646: . ack 19 win 58468 <nop,nop,timestamp 167568 1466460,nop,Enhanced Auth keyid 0 diglen 12 digest: c3b6422eb6bd3fd9cf79742b> 13:08:28.199557 Out IP 172.16.2.2.nerv > 172.16.2.1.bgp: P 286842489:286842508(19) ack 931203976 win 57200 <nop,Enhanced Auth keyid 0 diglen 12 digest: fc0e42900a73736bcc07c1a4>: BGP, length: 19 13:08:28.209661 In IP 172.16.2.1.bgp > 172.16.2.2.nerv: P 1:20(19) ack 19 win 56835 <nop,Enhanced Auth keyid 0 diglen 12 digest: 0fc8578c489fabce63aeb2c3>: BGP, length: 19 13:08:28.309525 Out IP 172.16.2.2.nerv > 172.16.2.1.bgp: . ack 20 win 57181 <nop,Enhanced Auth keyid 0 diglen 12 digest: ef03f282fb2ece0039491df8> 13:08:32.439708 Out IP 172.16.2.2.1122 > 172.16.2.1.646: P 54:72(18) ack 55 win 58432 <nop,nop,timestamp 170560 1468472,nop,Enhanced Auth keyid 0 diglen 12 digest: 76e0cf926f348b726c631944>: 13:08:32.449795 In IP 172.16.2.1.646 > 172.16.2.2.1122: P 55:73(18) ack 72 win 57046 <nop,nop,timestamp 1469463 170560,nop,Enhanced Auth keyid 0 diglen 12 digest: dae3eec390d18a114431f4d8>: 13:08:32.549726 Out IP 172.16.2.2.1122 > 172.16.2.1.646: . ack 73 win 58414 <nop,nop,timestamp 170571 1469463,nop,Enhanced Auth keyid 0 diglen 12 digest: 851df771aee2ea7a43a0c46c> 13:08:33.719880 In arp who-has 172.16.2.66 tell 172.16.2.69 ^C 35 packets received by filter 0 packets dropped by kernel
Verificando erros de autenticação
Propósito
Verifique o número de pacotes perdidos pelo TCP devido a erros de autenticação.
Ação
A partir do modo operacional, entre no comando.show system statistics tcp | match auth
user@R1> show system statistics tcp | match auth
0 send packets dropped by TCP due to auth errors
58 rcv packets dropped by TCP due to auth errorsVerificando a operação do chaveiro
Propósito
Verifique o número de pacotes perdidos pelo TCP devido a erros de autenticação.
Ação
A partir do modo operacional, entre no comando.show security keychain detail
user@R1> show security keychain detail
keychain Active-ID Next-ID Transition Tolerance
Send Receive Send Receive
bgp-auth 3 3 1 1 1d 23:58 30
Id 3, Algorithm hmac-md5, State send-receive, Option basic
Start-time Wed Aug 11 16:28:00 2010, Mode send-receive
Id 1, Algorithm hmac-md5, State inactive, Option basic
Start-time Fri Aug 20 11:30:57 2010, Mode send-receive
Tabela de histórico de alterações
A compatibillidadde com o recurso dependerá da platadorma e versão utilizada. Use o Feature Explorer para saber se o recurso é compatível com sua plataforma.