[GTER] Aplicação para Source-Based Remotely Triggered Black Hole Filtering

[Douglas Fischer]

Eu lí:
"...trabalha em camada 2 entre os meus links e o meu roteador de borda..."

e minha mente interpretou:
"...ponto único de falha..."

P.S.: E aquele papinho de "relé de bypass" já me colocou numa furada...


Em 23 de junho de 2015 07:55, DMM Listas <dmm.listas at gmail.com> escreveu:

> Concordo, Douglas.
>
> Ainda tem um agravante: imaginemos que o atacante faça spoof de endereços
> que eu costumo utilizar na internet (Ex: DNS google, DNS root, etc.). Se
> essa ferramenta não conseguir identificar o spoof destes endereços, ela vai
> os colocar em black hole também. Aí a coisa fica mais complicada.
>
> Temos planos de comprar uma solução proprietária que já homologamos. Ela
> trabalha em camada 2 entre os meus links e o meu roteador de borda,
> inspecionando o tráfego e o bloqueando, quando necessário. Porém, até que
> os tramites para que essa compra sejam concluídos, ficamos vulneráveis.
>
>
>
> []'s.
>
>
> 2015-06-22 14:25 GMT-03:00 Douglas Fischer <fischerdouglas at gmail.com>:
>
> > Cara, muitos IPS snooping-based trabalham do jeito que você está falando.
> >
> > Ele fica olhando para tráfego e ao identificar um padrão de ataque ele
> > anuncia uma rota para:
> >  - "chamar" o trafego para ele
> >  - falar para o border enviar o tráfego para Black-Hole.
> >
> > Até aí não existe nada de muito novo e impossível.
> > Muitos equipamentos fazem isso...
> >
> >
> > O galho está na atuação em relação ao source. E por vários motivos:
> >
> > 1- Se tiver que bloquear pelo source, mesmo que seja uma outra caixa que
> vá
> > analisar o gatilho disso, o router que vai fazer esse bloqueio não vai
> > poder estar fazendo roteamento seco, olhando apenas para o destino.
> > Ele vai ter que olhar para a origem, e isso significa uma redução bem
> > significativa de performance em um border.
> >
> > 2- Com DDoS, isso torna-se inviável... Com as políticas de filtragem anti
> > spoofing cada vez mais furadas nessa nossa internet, em pouco tempo você
> > vai ter meia internet na tua lista de filtragem.
> >
> > 3- Nesse nível, você já não está mais falando de Roteador, e sim de
> > Firewall, e misturar as coisas não é nada aconselhável. Existem
> ferramentas
> > muito poderosas que podem inclusive interagir com a aplicação(Ex.: Falha
> de
> > Authenticação) para resolver isso para você. Mas aí você já não está mais
> > no roteamento, concorda?
> >
> > E por aí vai...
> >
> > Em 22 de junho de 2015 13:39, DMM Listas <dmm.listas at gmail.com>
> escreveu:
> >
> > > Olá,
> > >
> > >
> > > Algum dos colegas conhece uma aplicação open source (difícil, mas não
> > custa
> > > tentar) para identificação dinâmica de endereços atacantes e que possa
> > ser
> > > utilizado com o recurso *Source-Based* Remotely Triggered Black Hole
> > > Filtering?
> > >
> > > Achei um PDF da Cisco que fala sobre o uso deste recurso, o qual
> utiliza
> > a
> > > checagem de URPF para bloqueio de endereços de origem. PDF:
> > > http://www.cisco.com/web/about/security/intelligence/blackhole.pdf
> > >
> > > Pelo que entendi do PDF, o bloqueio é feito com a inserção manual de
> > rotas
> > > no Trigger Router. O que eu gostaria de fazer era identificação
> dinâmica
> > > desses endereços baseado em thresholds definidos e o envio deles via
> BGP
> > > para as caixas de borda de modo que o URPF possa atuar.
> > >
> > > A aplicação que consegui localizar que chega mais próximo do que eu
> > > pretendo é chamada FastNetMon, mas esta não faz a identificação por
> > origem,
> > > apenas por destino (
> > > https://github.com/FastVPSEestiOu/fastnetmon/issues/225)
> > > e utilizando anúncios BGP com community black-hole para o bloqueio. No
> > meu
> > > caso, isso não resolve o problema, haja visto que a aplicação atacada
> > > ficará indisponível.
> > >
> > > Já tenho proteção de ataque volumétrico na operadora. Preciso agora de
> > uma
> > > aplicação que possa atuar de forma mais granular.
> > >
> > > Desde já, agradeço.
> > >
> > > []'s.
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> >
> >
> >
> > --
> > Douglas Fernando Fischer
> > Engº de Controle e Automação
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter




-- 
Douglas Fernando Fischer
Engº de Controle e Automação