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

Wilson R Lopes wilsonlopes00 at gmail.com
Wed Jul 27 22:10:32 -03 2016


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
>



More information about the gter mailing list