[GTER] RES: RES: RES: RES: RES: Há alternativa livre ou barata ao ntop p/ relatório de NetFlow?

DMM Listas dmm.listas at gmail.com
Tue Jun 16 10:40:55 -03 2015


@Bruno.

Não seria feito através de community blackhole do BGP, mas sim do recurso
de URPF. Eu apontaria o IP do atacante para um destino diferente de onde
recebo o pacote, fazendo o URPF dropar ele.


2015-06-16 8:56 GMT-03:00 Caio Bussaca <caiobussaca at gmail.com>:

> O meu intuito na utilização do fastnetmon é gerar um alarme da ocorrência
> do ataque via SMS - através do pacote gsm-utils - adicionando um simples
> comando dentro do arquivo "notify_about_attack.sh" para realização desse
> disparo e, manualmente, adicionar o IP atacante à blackhole.
>
> Em 15 de junho de 2015 22:44, Rodrigo Baldasso <rodrigo at loophost.com.br>
> escreveu:
>
> > Só quem consegue colocar um IP na blackhole é a operadora que está
> > anunciando ele...
> >
> > Efetuar só o bloqueio dele também não resolve, o tráfego vai continuar
> > chegando na borda de alguém (na sua ou na operadora).
> >
> > Sent from my iPhone
> >
> > > On Jun 15, 2015, at 21:28, DMM Listas <dmm.listas at gmail.com> wrote:
> > >
> > > :(
> > >
> > > Eu queria identificar o ataque e colocar o IP do atacante em blackhole,
> > não
> > > o IP do servidor atacado.
> > > Pessoal lá do serviço que tá testando ele, não tenho acompanhado.
> Pensar
> > > que essa possibilidade existia havia me deixado bem animado.
> > >
> > > 2015-06-15 17:44 GMT-03:00 Vicente De Luca <vicente.luca at gmail.com>:
> > >
> > >> Eu to exportando com sampler-map random 1 out-of 10000
> > >> a detecção é bem rápida, e com fastnetmon não precisamos gerar gráfico
> > pra
> > >> avaliar thresholds :).
> > >> o processo todo entre detecção via fastnetmon e completa mitigação
> > >> (convergência roteamento via cloud scrubbing) levou com certeza menos
> > de 10
> > >> minutos nas duas oportunidades em que tive pra avaliar o funcionamento
> > >> prático.
> > >>
> > >> estamos avaliando outras soluções em paralelo, como a cloudhelix.com
> --
> > >> prometem ser o New Relic pra networks,
> > >> bem como criando um custom flow analytics algorithm para o Scrutinizer
> > >> 15.5.
> > >>
> > >> até agora o fastnetmon respondeu além das expectativas, pra uma
> > ferramenta
> > >> open source e relativamente imatura.
> > >> o cloudhelix traz essa função de detecção e trigger via http post, mas
> > >> traz uma gama de reports e integrações interessantes. Se voce nao
> tiver
> > >> problemas em exportar seus flows para uma empresa de SaaS, pode ser
> uma
> > boa
> > >> opção também.. e não é caro -- cobrado por device.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Diego Canton de Brito <mailto:diegocanton at ensite.com.br>
> > >>> June 15, 2015 at 9:26 PM
> > >>>
> > >>> Qual tem sido o tempo entre ocorrência e ação dele?
> > >>>
> > >>> Sei que o NFsen leva cerca de 5 minutos para alertar e 10 minutos
> para
> > >>> gerar gráfico, o que é bem alto.
> > >>> Seria muito bom se o tempo fosse menor :/
> > >>>
> > >>>
> > >>> -----Mensagem original-----
> > >>> De: gter [mailto:gter-bounces at eng.registro.br] Em nome de Vicente De
> > Luca
> > >>> Enviada em: segunda-feira, 15 de junho de 2015 17:05
> > >>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes
> > >>> Assunto: Re: [GTER] RES: RES: RES: RES: Há alternativa livre ou
> barata
> > ao
> > >>> ntop p/ relatório de NetFlow?
> > >>>
> > >>> Eu estou usando o fastnetmon aqui desde o primeiro dia do NANOG
> quando
> > >>> conheci o Pavel em San Francisco, e até agora ele me salvou duas
> vezes
> > >>> desde então.
> > >>>
> > >>> meu cenário é bem simples.
> > >>>
> > >>> a cada datacenter tenho dois edge routers ASR9k exportando flow pra
> uma
> > >>> virtual machine rodando fastnetmon.
> > >>>
> > >>> o software foi criado para detectar ataques (incoming/outgoing) de
> uma
> > >>> ambiente de cloud que vende VPS, portanto a configuração de
> thresholds
> > >>> ainda é limitada a essa perspectiva.
> > >>> Por exemplo: voce configura thresholds para bandwidth, pps ou flows.
> O
> > >>> trigger em um alarme (ou ban) ocorrerá caso um /32 da tua rede
> > (destino)
> > >>> ultrapassar algum desse limites.
> > >>> por enquanto voce nao consegue configurar diferentes thresholds para
> > >>> incoming/outgoing, ou maior granularidade como diferentes thresholds
> > por
> > >>> protocolos, portas, etc.
> > >>>
> > >>> mas ainda assim funciona muito bem ! no meu caso em que uso em uma
> > núvem
> > >>> privada onde somente nossos engineers botam o dedo lá, eu
> desabilitei o
> > >>> sentido outgoing no fastnetmon, uma vez que minha intenção é detectar
> > >>> ataques vindo da internet para nossa infra.
> > >>>
> > >>> quanto a mitigação do ataque, uso uma solução de scrubbing em nuvem
> > onde
> > >>> eu anuncio meus prefixos por essa empresa, eles filtra, o tráfego e
> me
> > >>> devolvem limpo por um canal via IXP. A solução com ExaBGP parece ser
> > >>> interessante, ainda não tive tempo de testar. mas pra alguns casos
> > pode ser
> > >>> overkill.
> > >>> eu ja tinha escrito no passado um script em ruby que conecta nos edge
> > >>> routers e faz o anuncio dos prefixos via NETCONF, com opção de
> > rollback.
> > >>>
> > >>> entao foi somente adicionar uma chamada a esse script no
> > >>> notify_about_attack.sh dentro das condições ban e unban.
> > >>>
> > >>> um dos issues que ainda existe é que o unban ocorre após um periodo
> de
> > >>> tempo configurável.
> > >>> Porém como voce esta recebendo somente o tráfego legitimo, o
> fastnetmon
> > >>> não teria como saber sobre o ataque pra verificar se ele ainda ocorre
> > antes
> > >>> de fazer o unban.
> > >>> entao pode acontecer de vc realizar o unban, o ataque ainda existir e
> > >>> causar uma indisponibilidade até que seja detectado novamente e o
> > processo
> > >>> de ban ocorra novamente.
> > >>>
> > >>> pra contornar isso desabilitamos o unban, e estamos tentando
> trabalhar
> > >>> com thresholds bem conservadores baseados em dados de ataques
> passados.
> > >>> quando um ataque eh detectado, a mitigação eh imediatamente acionada,
> > >>> além de um pager para o neteng de plantao, que vai acompanhar o
> > processo e
> > >>> tomar a ação humana de "desbanir" quando conveniente.
> > >>>
> > >>> ate agora é essa a nossa experiencia com o fastnetmon. muito
> positiva,
> > >>> mas com muito a melhorar ao mesmo tempo.
> > >>>
> > >>> abs,
> > >>>
> > >>> --vicente
> > >>>
> > >>> --
> > >>> Sent with Postbox <http://www.getpostbox.com>
> > >>> --
> > >>> gter list https://eng.registro.br/mailman/listinfo/gter
> > >>>
> > >>> --
> > >>> gter list https://eng.registro.br/mailman/listinfo/gter
> > >>> Vicente De Luca <mailto:vicente.luca at gmail.com>
> > >>> June 15, 2015 at 9:05 PM
> > >>>
> > >>> Eu estou usando o fastnetmon aqui desde o primeiro dia do NANOG
> quando
> > >>> conheci o Pavel em San Francisco, e até agora ele me salvou duas
> vezes
> > >>> desde então.
> > >>>
> > >>> meu cenário é bem simples.
> > >>>
> > >>> a cada datacenter tenho dois edge routers ASR9k exportando flow pra
> uma
> > >>> virtual machine rodando fastnetmon.
> > >>>
> > >>> o software foi criado para detectar ataques (incoming/outgoing) de
> uma
> > >>> ambiente de cloud que vende VPS, portanto a configuração de
> thresholds
> > >>> ainda é limitada a essa perspectiva.
> > >>> Por exemplo: voce configura thresholds para bandwidth, pps ou flows.
> O
> > >>> trigger em um alarme (ou ban) ocorrerá caso um /32 da tua rede
> > (destino)
> > >>> ultrapassar algum desse limites.
> > >>> por enquanto voce nao consegue configurar diferentes thresholds para
> > >>> incoming/outgoing, ou  maior granularidade como diferentes thresholds
> > por
> > >>> protocolos, portas, etc.
> > >>>
> > >>> mas ainda assim funciona muito bem ! no meu caso em que uso em uma
> > núvem
> > >>> privada onde somente nossos engineers botam o dedo lá, eu
> desabilitei o
> > >>> sentido outgoing no fastnetmon, uma vez que minha intenção é detectar
> > >>> ataques vindo da internet para nossa infra.
> > >>>
> > >>> quanto a mitigação do ataque, uso uma solução de scrubbing em nuvem
> > onde
> > >>> eu anuncio meus prefixos por essa empresa, eles filtra, o tráfego e
> me
> > >>> devolvem limpo por um canal via IXP. A solução com ExaBGP parece ser
> > >>> interessante, ainda não tive tempo de testar. mas pra alguns casos
> > pode ser
> > >>> overkill.
> > >>> eu ja tinha escrito no passado um script em ruby que conecta nos edge
> > >>> routers e faz o anuncio dos prefixos via NETCONF, com opção de
> > rollback.
> > >>>
> > >>> entao foi somente adicionar uma chamada a esse script no
> > >>> notify_about_attack.sh dentro das condições ban e unban.
> > >>>
> > >>> um dos issues que ainda existe é que o unban ocorre após um periodo
> de
> > >>> tempo configurável.
> > >>> Porém como voce esta recebendo somente o tráfego legitimo, o
> fastnetmon
> > >>> não teria como saber sobre o ataque pra verificar se ele ainda ocorre
> > antes
> > >>> de fazer o unban.
> > >>> entao pode acontecer de vc realizar o unban, o ataque ainda existir e
> > >>> causar uma indisponibilidade até que seja detectado novamente e o
> > processo
> > >>> de ban ocorra novamente.
> > >>>
> > >>> pra contornar isso desabilitamos o unban, e estamos tentando
> trabalhar
> > >>> com thresholds bem conservadores baseados em dados de ataques
> passados.
> > >>> quando um ataque eh detectado, a mitigação eh imediatamente acionada,
> > >>> além de um pager para o neteng de plantao, que vai acompanhar o
> > processo e
> > >>> tomar a ação humana de "desbanir" quando conveniente.
> > >>>
> > >>> ate agora é essa a nossa experiencia com o fastnetmon. muito
> positiva,
> > >>> mas com muito a melhorar ao mesmo tempo.
> > >>>
> > >>> abs,
> > >>>
> > >>> --vicente
> > >>>
> > >>> Caio Bussaca <mailto:caiobussaca at gmail.com>
> > >>> June 15, 2015 at 8:05 PM
> > >>> Honestamente, ainda estou desbravando a ferramenta e suas
> > funcionalidades,
> > >>> pois descobri sua existência na sexta-feira última.
> > >>> Também desconhecia este pacote ExaBGP, mas acredito que seja este o
> > >>> propósito.
> > >>> A julgar pelo desenho exposto na página de documentação, pode-se
> > aplicar
> > >>> diretamente em servidor de borda linux com quagga ou fazer um
> > espelhamento
> > >>> de tráfego no switch de core, aplicando a ferramenta sob um servidor
> > linux
> > >>> qualquer.
> > >>>
> > >>> Assim que obter os resultados e comportamentos da ferramenta eu volto
> > aqui
> > >>> pra postar.
> > >>> Seria interessante se mais pessoas desbravassem este fastnetmon e
> > >>> compartilhassem suas experiências.
> > >>>
> > >>> --
> > >>> gter list https://eng.registro.br/mailman/listinfo/gter
> > >>> DMM Listas <mailto:dmm.listas at gmail.com>
> > >>> June 15, 2015 at 5:03 PM
> > >>> @Caio.
> > >>>
> > >>> Pelo que entendi ela cria um anúncio de BGP para seu roteador fazer
> um
> > >>> "black role" usando URPF. É isso mesmo?
> > >>> Neste caso ela informa a origem do tráfego (atacante) para blackhole
> ou
> > >>> seu
> > >>> IP interno?
> > >>>
> > >>> Grato.
> > >>>
> > >>>
> > >>> --
> > >>> gter list https://eng.registro.br/mailman/listinfo/gter
> > >>> Caio Bussaca <mailto:caiobussaca at gmail.com>
> > >>> June 15, 2015 at 1:11 PM
> > >>> Basicamente, se estiver usando linux, você fará:
> > >>> # perl fastnetmon_install.pl
> > >>>
> > >>> A partir daí, será criado o arquivo /etc/fastnetmon.conf com as
> > >>> configurações da aplicação - ajuste segundo suas necessidades - e, em
> > >>> /opt/fastnetmon estarão os binários de execução da aplicação
> > (fastnetmon)
> > >>> e
> > >>> o client para análise de tráfego (fastnetmon_client) - execute-os em
> > >>> background.
> > >>>
> > >>> Crie o arquivo /etc/networks_list adicionando o ip/máscara do host
> que
> > >>> pretende monitorar...1 por linha. Exemplo:
> > >>> 192.168.0.1/32
> > >>> 192.168.0.4/30
> > >>>
> > >>> Crie o arquivo /etc/networks_whitelist para que algum IP dos prefixos
> > >>> diferentes de /32 NÃO sejam monitorados. Exemplo:
> > >>> 192.168.0.6/32
> > >>>
> > >>> Copie o script de notificação de ataque:
> > >>> # cp /usr/src/fastnetmon/src/notify_about_attack.sh
> > >>> /usr/local/bin/notify_about_attack.sh
> > >>> # chmod 755 /usr/local/bin/notify_about_attack.sh
> > >>>
> > >>> Abre este último arquivo e configure o e-mail que receberá o aviso,
> > campo
> > >>> 'email_notify'.
> > >>>
> > >>>
> > >>> Qualquer outra dúvida, dentro da pasta docs do pacote baixado, você
> vai
> > >>> encontrar mais informações.
> > >>>
> > >>> Em 13 de junho de 2015 11:47, Diego Canton de Brito <
> > >>> --
> > >>> gter list https://eng.registro.br/mailman/listinfo/gter
> > >>
> > >> --
> > >> Sent with Postbox <http://www.getpostbox.com>
> > >> --
> > >> 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
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



More information about the gter mailing list