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

Mon Jun 15 22:53:13 -03 2015

Seria ótimo, porém precisamos lembrar que blackhole serve apenas para 
seu ASN.
Caso coloque um IP em BH de outro ASN, isso é formalmente um sequestro 
de IP.
As operadoras precisam melhorar seus filtros, pois existem várias que 
aceitam tudo que for colocado na community.

Atenciosamente,

   Eduardo Belotto
   Infradigital
   skype: ebelotto

"Executar o inexequível, atingir o inatingível e comunicar o incomunicável"

On 15/06/2015 21:28, DMM Listas 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