[GTER] Firewall com Identificação de DoS Volumétrico e triggering de BlackHole

[Wilson R Lopes]

Pois é...implementar esse tipo de feature acredito ser simples...

Uma diferença e vantagem em soluções especificas para mitigação de DDoS é o
fato de ser stateless, tratar só trafego de entrada, e com isso a
capacidade esta  em pps e não em conexões, como em um firewall statefull.
Escala muito mais e por isso o mercado deste tipo de solução segue este
caminho.


Abs,
Wilson.

Em 27 de julho de 2016 22:35, Douglas Fischer <fischerdouglas at gmail.com>
escreveu:

> ​E aí que entram a​s questões de design de hardware(ou QoS de
> virtualização).
> Proteja sua Control Plane! -> BCP78 e RFC6192, confere?
>
>
> Além disso,
> O próprio CPU uso de CPU pode fazer parte da métrica treshold.
>
>
> Em 27 de julho de 2016 22:10, Wilson R Lopes <wilsonlopes00 at gmail.com>
> escreveu:
>
> > Implementar esse tipo de solucao em um firewall seria de certa forma
> > simples. A razão de não existir (que eu conheça) seria a efetividade -
> sob
> > ataque um firewall statefull com a tabela de sessões cheia, interfaces
> > saturadas e processamento comprometido, não seria efetivo ao papel de
> > sinalizar a tempo um hop acima, por exemplo, com o anuncio do ip atacado
> > para rota de descarte.
> >
> > Por isso soluções de análise de netflow, out-of-band, são usadas para
> este
> > papel.
> >
> >
> > Abs,
> > Wilson.
> >
> > Em 27 de julho de 2016 15:04, Bruno Cesar <brunohardhouse at gmail.com>
> > escreveu:
> >
> > > Douglas,
> > >
> > > Para soluções de mercado provavelmente você ficará restrito a
> > > tecnologias/serviços em equipamentos segmentados, Firewall/Anti-DDoS.
> > >
> > > Para soluções abertas recomendaria algo com PF + nfsen +
> nfsen-blackhole
> > > ou EXADOS em BSD.
> > >
> > > Abs.
> > >
> > > Bruno Teixeira.
> > >
> > >
> > > 2016-07-27 7:59 GMT-03:00 Douglas Fischer <fischerdouglas at gmail.com>:
> > >
> > > > Essa é a questão...
> > > > Eu não quero um Anti-DDoS!
> > > >
> > > > Esse ambiente não é de DataCenter e também não é de ISP.
> > > > Eu não quero mais um ponto de falha no circuito.
> > > >                     (Seja inline, Seja by-side.)
> > > > Eu não quero mais uma caixa para me incomodar.
> > > >
> > > >
> > > > A única coisa que eu quero é que a única caixa Statefull no meio do
> > > caminho
> > > > possa avisar alguém que algo de "ruim" está acontecendo.
> > > > Necessito que os gatilho desse aviso sejam simples(não preciso de
> > > > heurística, tão pouco computação quântica), e que esse "aviso" seja
> > feito
> > > > através de BGP.
> > > >
> > > >
> > > >
> > > >
> > > > Já consegui Scriptar com EEM em Cisco a divulgação de um prefixo BGP
> > /32
> > > > com 666 quando o número de conexões Half-Open para um determinado IP
> > > > interno.
> > > >
> > > > Mas sinceramente? Tenho muitas reticências quanto a essa abordagem.
> > > > - Toda vez que criei uma Aranha com Script,
> > > >   acabei criando um entrave para upgrades.
> > > >   "Será que vai funciona nessa nova versão?"
> > > >   E o fabricante não vai dar suporte ao seu script.
> > > > - Acho essas soluções baseada em script tão PORCAS
> > > >   quanto um bash que criei lá por 99 para acessar o
> > > >   site do Observatório nacional, ver a hora estampada
> > > >   via html, e ajustar o horário do meu
> > > >   super-server-faz-tudo-linux.
> > > > "Se existe a MELECA do protocolo,
> > > >        USE A MELECA do protocolo!"
> > > >
> > > > Quero algo que seja nativo da plataforma do fabricante.
> > > > Para eu poder xingar alguém quando der "M...".
> > > >
> > > >
> > > >
> > > >
> > > > Em 26 de julho de 2016 16:45, Evandro CFS <evandro.cfs7 at gmail.com>
> > > > escreveu:
> > > >
> > > > > On 25/07/2016 08:50, Douglas Fischer wrote:
> > > > >
> > > > >> Agradeço ao Diego, Geek, e Ricardo...
> > > > >> e também aos demais que me procuraram PVT.
> > > > >>
> > > > >> Mas justamente oque estamos tentando evitar é mais uma peça no
> > > conjunto.
> > > > >> Não queremos mais uma caixa, seja in-line ou seja by-side, no
> > cenário.
> > > > >>
> > > > >> Queremos que o próprio firewall(e não queremos open source) possa
> > > > >> identificar um possível alvo interno de DoS Volumétrico e
> > > > automaticamente
> > > > >> anuncie para o Borda a rota /32 ou /128 com community 666.
> > > > >>
> > > > >> Não vejo que isso seja complicado de se implementar a partir das
> > > > >> informações que o firewall já possui:
> > > > >>  - Banda passante com destino à um determinado IP Intermo
> > > > >>  - Numero de conexões abertas, half-open, etc...
> > > > >>
> > > > >>
> > > > >> Vamos procurar e ver o que vamos encontrar.
> > > > >>
> > > > >>
> > > > > Olá Diego,
> > > > >
> > > > >         A questão não é tão simples. Dependendo do tamanho do DDOS
> > que
> > > > > você tomar, seu firewall não vai conseguir tratar a quantidade de
> > > pacotes
> > > > > e não vai fazer o que você deseja, ou então você irá precisar de um
> > > > > firewall gigante, o que inviabiliza o projeto. Por isso é
> > > > > recomendado uma solução a parte.
> > > > >         Existem algumas soluções de mercado para isso: Arbor,
> Cisco,
> > > > Check
> > > > > Point, Fortinet, etc. Existem operadoras vendendo a solução de
> > > > > anti-DDOS também e vejo muita gente partindo para esse tipo de
> > solulção
> > > > > por questões de Custo/Benefícios.
> > > > >         Att,
> > > > >
> > > > > []'s
> > > > > Evandro CFS
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 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
> > >
> > --
> > 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
>