Filtrar antes de preferir. Uma política de BGP no edge que falha em segurança

Ser multi-homed não é o mesmo que ser resiliente. Dois carriers de trânsito e uma porta num exchange dão opções. A política de encaminhamento decide se essas opções tornam a rede mais rápida e mais segura, ou se apenas dão a uma rota má mais formas de entrar. É assim que pensamos uma política de edge, pela ordem em que uma rota realmente a encontra.

O problema que toda a rede multi-homed tem

A partir do momento em que recebe tabelas completas de mais do que um carrier, o router está a escolher entre caminhos o dia inteiro, todos os dias, e escolhe pelas regras que foram escritas. Se não foi escrita nenhuma, recorre aos critérios de desempate por omissão do BGP: o AS path mais curto e depois uma cascata de detalhes que nada têm a ver com latência, custo ou os seus clientes.

O atalho habitual é colar primeiro a preferência às sessões («preferir o carrier A, é mais barato») e acrescentar a filtragem mais tarde, se chegar a acontecer. Essa ordem está invertida. A preferência é uma decisão sobre rotas boas. Se o lixo não tiver sido removido antes de essa decisão ser tomada, está-se a ordenar lixo com todo o cuidado.

Fase um: higiene, antes de qualquer decisão

Cada sessão de entrada, de trânsito ou de peer, passa pela mesma política de higiene antes de qualquer outra coisa tocar na rota. A lista é curta e aborrecida, e é precisamente essa a intenção:

• Bogons. Espaço privado, reservado, de documentação e não atribuído não tem nada que chegar vindo da internet.
• Os seus próprios prefixos. Uma rota para o seu próprio espaço aprendida do exterior é um loop ou um hijack. Rejeite-a.
• A rota por omissão. A menos que tenha pedido uma default a um carrier, não quer que uma apareça porque alguém a montante se enganou.
• Demasiado específicas. Tudo o que for mais longo do que um /24 em IPv4 (e um /48 em IPv6) não é globalmente encaminhável por convenção. Aceitá-lo é convidar hijacks more-specific.
• AS paths absurdos. Paths com ASN privados lá dentro, ou paths muito mais longos do que qualquer rota real precisa.

Em termos genéricos de route-policy do Cisco IOS-XR, o esqueleto é este:

route-policy TRANSIT-IN
  if destination in BOGONS-V4 or destination in OUR-PREFIXES then
    drop
  endif
  if destination in (0.0.0.0/0) then
    drop
  endif
  if destination in (0.0.0.0/0 ge 25) then
    drop
  endif
  if as-path in PRIVATE-ASNS then
    drop
  endif
  apply SET-PREFERENCE
end-policy

Repare que a lógica de preferência é aplicada mesmo no fim, como política separada. A higiene é idêntica em todas as sessões. A preferência varia por sessão. Mantê-las separadas significa que uma alteração ao direcionamento do tráfego nunca pode enfraquecer a filtragem por acidente.

Fase dois: preferência por níveis

Quando só restam rotas sensatas, decide-se qual o caminho que ganha. Usamos níveis de local preference em vez de um número por carrier, porque os níveis descrevem intenção:

1. O peering direto ganha. Uma rota aprendida da própria rede, num exchange ou numa sessão bilateral, é o caminho mais curto que se pode ter.
2. Os clientes do próprio carrier vêm a seguir. Se um carrier de trânsito marcar com uma community as rotas que aprende dos seus próprios clientes, essas rotas ficam na rede desse carrier de ponta a ponta.
3. Tudo o resto segue pelo trânsito que mede melhor para o grosso do tráfego.

Um segundo carrier mantém-se «quente» como reserva: tabela completa aceite, preferência mais baixa, pronto no instante em que o primeiro retira as rotas.

Mais uma regra que se paga discretamente: nunca usar um carrier de trânsito para chegar aos clientes de outro carrier quando o segundo carrier está ligado diretamente à sua rede. Fazer match no AS vizinho dentro do path e baixar a preferência impede o tráfego de fazer um desvio caro por um terceiro.

Fase três: disciplina de saída

O lado da saída é mais simples e mais importante. Anuncie exatamente os prefixos que origina, e nada mais:

prefix-set OUR-PREFIXES-V4
  192.0.2.0/24,
  198.51.100.0/24
end-set

route-policy TRANSIT-OUT
  if destination in OUR-PREFIXES-V4 then
    pass
  else
    drop
  endif
end-policy

Uma allow list de saída explícita significa que um erro noutro ponto da sua rede (uma estática redistribuída, uma rota de cliente que devia ter ficado interna) não pode transformá-la em caminho de trânsito para o tráfego de outrem. A modelação do caminho de retorno, como o AS-path prepending para um carrier que quer usar menos na entrada, acontece dentro desta política, nunca em vez dela.

Fase quatro: não originar tráfego falsificado

A política de encaminhamento controla aquilo em que acredita. O anti-spoofing controla aquilo que envia. O BCP38 diz que uma rede não deve reencaminhar pacotes cujo endereço de origem não possa legitimamente vir de trás da interface em que chegaram. Nas interfaces viradas para a internet e para clientes, isso significa unicast reverse path forwarding em modo strict onde a topologia o permite, ou filtros explícitos de endereço de origem onde não permite. É um dos poucos controlos que protege o resto da internet da sua rede, e é a diferença entre um servidor comprometido na sua rede ser um problema seu e ser um problema de todos.

Verificar o seu próprio edge

Se opera o seu próprio edge, ou quer fazer ao seu fornecedor as perguntas certas, aqui fica uma lista de verificação curta:

• A higiene é aplicada de forma idêntica em todas as sessões de entrada, incluindo os route servers dos exchanges e os peers «de confiança»?
• Consegue mostrar que um /25, ou o seu próprio prefixo, enviado por um vizinho é rejeitado? Teste-o em laboratório, ou leia a política linha a linha.
• A sua política de saída é uma allow list explícita, ou «tudo exceto»?
• Sabe por que carrier sai o seu tráfego para os dez principais destinos, e porquê? Um traceroute a partir do edge mais show bgp <prefix> responde a isso em minutos.
• A filtragem BCP38 está aplicada em todas as interfaces viradas para a internet, e existe um teste que o prova?
• Mede a sua rede a partir de fora? Uma plataforma independente como o RIPE Atlas mostra como a internet realmente chega até si, o que muitas vezes não coincide com o que o seu router julga.

Porque nos damos a este trabalho

Cada um destes passos é invisível num dia bom. No dia em que um carrier deixa fugir uma tabela, desliga um circuito para manutenção, ou um vizinho anuncia algo que não devia, são eles que decidem se o seu tráfego dá por isso. Operamos os nossos próprios sistemas autónomos com esta estrutura em routers Cisco ASR 9000 e Juniper MX, medidos continuamente a partir de fora, porque é a única forma que conhecemos de fazer uma rede multi-homed comportar-se de forma previsível.

Se quiser um segundo par de olhos sobre a sua própria política de edge, ou uma plataforma que assenta atrás de uma construída desta forma, teremos todo o gosto em conversar.

Fale com um engenheiro

Related

Relacionados: Rede própria: dois ASN, vários carriers, peering · Monitorização de rede e evidências · IPv6, nativo e dual-stack