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

Mon Jun 15 21:28:14 -03 2015

:(

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
>