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

[DMM Listas]

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
>