Criando um filtro de firewall JunOS com base nas propriedades de roteamento dinâmico


7

Um dos meus clientes de transporte público BGP me pediu uma solução para facilitar o tráfego de buracos na nossa rede quando ele está sofrendo ataques DDoS. Normalmente, o BGP blackholing é feito blackholing no alvo , no entanto, meu cliente está procurando uma solução para o blackhole com base no endereço de origem, para que o alvo do ataque não seja colocado offline.

Construir uma solução blackhole com base no endereço de destino não é tão difícil: basta que o cliente anuncie o destino como uma rota mais específica por meio de uma sessão separada do BGP ou faça com que ele o marque com uma comunidade específica e use uma política de roteamento para definir o caminho. próximo salto para alguma interface de descarte.

Construir uma solução blackhole onde as fontes do ataque (que não estão dentro do espaço IP do cliente) são destruídas parece um pouco mais difícil. Se eu usasse a mesma solução para filtrar destinos, meu problema é que só quero descartar o tráfego de fontes específicas para esse cliente específico, portanto, inserir rotas de descarte na minha tabela de roteamento não é mais aceitável, pois afetaria outros clientes como bem. Então, preciso de uma maneira de criar um filtro que se aplique apenas a esse cliente específico.

A primeira solução em que eu estava pensando era usar o BGPFlowspec. Infelizmente, isso não funcionará para esse cliente específico, pois o equipamento dele não é compatível.

Então, o que eu procurava é uma maneira de criar um filtro de firewall dinâmico com base em alguma propriedade de roteamento, provavelmente uma comunidade definida por nosso cliente ou por nós ao receber uma rota específica por meio de uma sessão dedicada do BGP blackhole. Esse filtro pode ser aplicado nas interfaces do cliente para bloquear o tráfego indesejado. Infelizmente, não encontrei uma maneira fácil de criar um filtro de firewall (ou lista de prefixos) dessa maneira.

Eu encontrei http://thomas.mangin.com/posts/bgp-firewall.html , que 'utiliza indevidamente' o SCU / DCU para alcançar mais ou menos o que estou procurando, mas soa como um hack .

Uma das outras soluções em que posso pensar é criar um filtro estático em nossas rotas e criar uma interface que permita ao cliente modificar a lista de prefixos usada por esse filtro. No entanto, enviar alterações de configuração nos meus roteadores toda vez que o cliente deseja adicionar um buraco negro não é realmente o que eu quero. Alguma solução usando BGP seria preferida.

Do nosso lado, o roteamento é feito no Juniper, para uma solução, eu preferiria ter algo que possa ser usado em uma variedade de plataformas; portanto, basicamente devemos usar o BGP por meio de uma sessão separada ou rotear rotas por uma comunidade específica. Dessa forma, também posso usá-lo para outros clientes.

Estou realmente interessado se alguém tiver uma boa solução para isso (além da SCU / DCU).


Você já descobriu isso, eu sei que isso é super antigo, achei que poderia valer a pena conferir? Qual plataforma você está usando?
Jordan Head

@ JordanHead infelizmente não, eu desisti mais ou menos disso. Nós rodamos uma plataforma de vários roteadores Juniper MX (principalmente em 5/80/104).
Teun Vink

Quantos endereços de origem estão atacando?
Jordan Chefe

Isso depende do cliente e deve ser dinâmico, mas pelo menos dezenas ou centenas devem ser possíveis. Estou procurando algo que permita ao meu cliente inserir fontes para as quais o tráfego não é entregue à sua rede via BGP. Talvez seja mais fácil oferecer acesso por meio de um portal a uma caixa dedicada que insere rotas de buraco negro (pecpec de fluxo).
Teun Vink

Veja o ExaBGP, escrito por Thomas Mangin (autor de hackers SCU / DCU) - daemon BGP totalmente programável, que suporta Flowspec. Colocar uma interface de portal sobre este para o seu cliente seria uma boa solução
Benjamin Dale

Respostas:


1

A GRNET (rede grega de pesquisa e educação) desenvolveu um aplicativo da Web para os clientes fazerem isso com a Flowspec. O portal da web possui um back-end BGP Flowspec que injeta o flowpec na sua rede. Altamente configurável e em uso no backbone pan-europeu GEANT de 500-1.000 Gbps: https://www.noc.grnet.gr/en/fod


1

Para (finalmente) responder minha própria pergunta:

Isso não é possível da maneira que eu quero implementar isso com as versões atualmente suportadas do JunOS. Sim, existem outras maneiras de atingir a meta, como mencionado na outra resposta e nos comentários, mas minha pergunta específica era ser capaz de sinalizar blackholing usando uma sessão do BGP.


1

A criação dinâmica de regras de firewall não é apenas para redirecionar o tráfego para um blachole, mas também para permitir que o tráfego entre datacenters, empresas e intranet distribuído geograficamente, tenha políticas de firewall definidas com abstração de IP, usando alguma rotulagem no roteamento dinâmico para preencher objetos de firewall e, em seguida, permitir o controle do tráfego. Procurei uma solução como essa há alguns anos com o Juniper, mas não tive nenhum feedback. Existem alguns scripts no Junos que podem ajudar no assunto, mas a população de objetos não foi completamente concluída em resposta ao roteamento de eventos de troca. Também não havia a possibilidade de marcar rotas diretas para classificá-las de acordo com as necessidades:

  • Se houvesse uma rede para back-end em um datacenter, isso poderia ser marcado usando uma "tag de back-end" diretamente na interface
  • No roteamento dinâmico, essa "tag de back-end" pode ser traduzida em uma comunidade (por exemplo, BGP SoO) e anunciada com essa
  • O datacenter remoto receberia a rede anunciada e preencheria um grupo de endereços de objetos que poderia acessar diretamente outros back-end.

O FlowSpec pode ser uma ajuda e um firewall que pode se conectar diretamente ao núcleo dos mpls, pois um PE também seria uma ajuda. Alguém sabe sobre essa solução?

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.