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

Tue Jun 16 08:56:04 -03 2015

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
>