Três salvaguardas que impedem um BGP gateway de cliente de deixar fugir rotas

Um gateway dedicado por cliente, que nós construímos e operamos, com peering interno para o nosso policy gateway sobre números de AS privados, é o desenho certo: isolamento, uma política que lhes pertence, e routing que se adapta sozinho. O BGP é interno à nossa plataforma, não uma sessão que o cliente opera. Mas significa também que passa a operar muitos pequenos BGP speakers, e uma única definição descuidada em qualquer um deles pode anunciar rotas que nunca devia anunciar. Este artigo explica como isso acontece e as três salvaguardas que colocamos em todos os gateways de cliente para que não possa acontecer.

Porque é que os gateways por cliente falam BGP

Um VPN concentrator partilhado com rotas estáticas parece mais simples, até ser preciso acrescentar uma subnet, mover um cliente entre firewalls, ou sobreviver a uma falha de gateway. Com um gateway dedicado por cliente, cada um a correr um AS privado dentro da nossa plataforma e em peering com um policy gateway central, acrescentar uma rede é um anúncio, e perder um caminho é uma retirada que converge sozinha. A política do cliente fica no edge do cliente, e a política de trânsito fica central.

O preço é que cada gateway passa a poder influenciar o routing de todos. Por isso precisa de salvaguardas que não dependam de alguém ser cuidadoso.

Como acontecem realmente as fugas

Na maioria dos post-mortems publicados, a causa de uma fuga de rotas a partir de um dispositivo de edge raramente é um bug exótico do BGP. É a redistribution. Alguém ativa «redistribute connected» ou «redistribute static» para poupar escrita, e o gateway começa a anunciar o seu próprio WAN link, o pool do seu túnel VPN, uma subnet de gestão, ou uma rota que aprendeu noutro lado. Numa firewall open source com um routing daemon, essa opção está muitas vezes à distância de uma caixa de verificação.

Assim que uma rota fugida é aceite a montante, o tráfego para esse prefixo pode ser puxado para o gateway errado, ou a rede de um cliente pode tornar-se alcançável a partir de sítios de onde não devia. Nada se despenha. O tráfego simplesmente vai parar a um sítio inesperado.

Salvaguarda um: anunciar com network statements explícitos

Um gateway deve anunciar exatamente os prefixos que pertencem ao cliente, listados um a um, e nada mais. Em FRR, que está por baixo de muitos routing plugins de firewalls, isso tem este aspeto:

router bgp 64601
 bgp router-id 10.0.0.2
 neighbor 10.0.0.1 remote-as 64600
 address-family ipv4 unicast
  network 198.51.100.0/27
  neighbor 10.0.0.1 prefix-list CUSTOMER-OUT out
 exit-address-family

O statement network só anuncia um prefixo que está realmente presente na tabela de routing, pelo que uma gralha não anuncia nada em vez de anunciar algo errado.

Salvaguarda dois: uma outbound prefix list que corresponda

Cinto e suspensórios. Mesmo com network statements explícitos, uma outbound prefix list permite apenas os prefixos do próprio cliente e nega tudo o resto:

ip prefix-list CUSTOMER-OUT seq 10 permit 198.51.100.0/27
ip prefix-list CUSTOMER-OUT seq 100 deny any

Se alguma coisa tentar alguma vez anunciar mais, esta lista deita-o fora à saída. Espelhe-a também do lado recetor: o gateway central aceita de cada cliente apenas os prefixos atribuídos a esse cliente.

Salvaguarda três: nenhuma redistribution, e verificar que assim fica

A redistribution está desativada, e faz parte da configuração que verifica, não de uma suposição. Em FRR pode verificar numa linha:

vtysh -c 'show running-config' | grep -i redistribute

Um resultado vazio é o único resultado aceitável. Como algumas interfaces de firewall expõem a redistribution como uma caixa de verificação conveniente, esta verificação pertence à validação da sua construção, não apenas ao desenho original.

Compare com um gateway sabidamente bom antes da entrega

Três salvaguardas impedem fugas. Não impedem a outra falha comum dos gateways por cliente: uma definição que difere dos gateways que funcionam, causando uma VPN que «não liga» ou que liga sem chegar a lado nenhum. Uma regra pass em falta para a porta da VPN na interface WAN, um outbound NAT deixado em modo automático, uma regra de interface mais restritiva do que o pretendido, uma opção de autenticação subtilmente diferente: cada uma delas escapa facilmente a olho.

A cura é mecânica. Configure cada gateway através da sua API, nunca à mão, depois extraia as mesmas definições de um gateway de referência comprovado e do novo e compare-as campo a campo:

• Definições da instância VPN: protocolo, porta, ciphers, modo de autenticação, rotas e DNS enviados.
• Regras de firewall no WAN para a porta da VPN e os diagnósticos.
• Regras na própria interface da VPN.
• Modo e regras do outbound NAT.
• Configuração BGP, incluindo o campo da redistribution.

Qualquer diferença que não seja explicitamente esperada para este cliente bloqueia a entrega. Nenhuma credencial sai do edifício até a comparação estar limpa. Demora segundos e substitui uma tarde de resolução remota de problemas com um utilizador que só quer trabalhar.

Acesso por pessoa, bem feito

Um certificado de cliente por pessoa, assinado por uma autoridade de certificação que pertence ao cliente, mais uma credencial, significa que um portátil perdido é um certificado revogado e mais ninguém é afetado. Um endereço de túnel fixo por pessoa permite que a política de firewall siga um indivíduo de dispositivo em dispositivo.

Lista de verificação para os seus próprios gateways

• Todos os prefixos de cliente são anunciados por um network statement explícito?
• Existe uma outbound prefix list em cada sessão de cliente, e uma inbound correspondente ao centro?
• Um grep por redistribute devolve vazio em todos os gateways?
• Os gateways são configurados através de uma API, com o resultado comparado com uma referência sabidamente boa antes da entrega?
• O acesso remoto é por pessoa, com certificados que pode revogar individualmente?

Todos os gateways de cliente que construímos têm estas salvaguardas, no seu próprio segmento e na sua própria firewall. Se quer acesso privado à sua plataforma construído desta forma, teremos todo o gosto em ajudar.

Fale com um engenheiro

Relacionados: Conectividade privada: VPN gateways e linhas dedicadas · Managed firewalls de perímetro · Backbone encriptado multi-site: a mesh DMVPN