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

Mon Jun 15 17:44:28 -03 2015

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>