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

Douglas Fischer fischerdouglas at gmail.com
Wed Jul 27 22:35:25 -03 2016


​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



More information about the gter mailing list