[GTER] Monitor ARP SNMP Agent

[Shine]

Entendi, Douglas. Achava que era mesmo, voltado para o IX.

Em 19 de abril de 2018 10:30, Douglas Fischer <fischerdouglas at gmail.com>
escreveu:

> Então, sem mistério, deixo claro que o objetivo primários é criar um
> mecanismo para ajudar a resolver o problema de ARP-Flood no IX-SP.
> Mas já enxerguei possibilidade de uso dessa ferramenta em outros ambientes:
>  - Outros IX
>  - Rede industriais(são sensíveis a broadcast).
>
Na verdade nem todo broadcast é ARP, mas é possível montar script para
isso, claro.


> "1) coletar pacotes ARP
> Não está claro se você quer um ARP table ou se você quer uma projeção de
> ARP broadcast.
> Se for o ARP table tudo bem, fácil de obter. Mas qual o sentido de ter um
> ARP table? Isso não muda tão significativamente.
> Agora se você quer um ARP broadcast counter, já muda de figura. Isso não é
> obtido trivialmente via SNMP."
> A ideia é na verdade criar multi-contador de pacotes, com base numa
> informação de sub-rede, e fazer com que esse contador seja acessível via
> SNMP.
>
Ahn... vc quer criar uma private-OID com o resultado.
Mas acho que o número em si não agrega valor, IMO ter uma matriz em
analytics faria mais sentido, vc não acha?


>    - ARP-Request Emitidos por esse IP Perguntando destinos Dentro da Faixa
> de rede especificada
>      - IP 1
>      - IP 2
>      - IP ..
>      - IP N
>    - ARP-Request Emitidos por esse IP Perguntando destinos FORA DA FAIXA de
> rede especificada
>      - IP 1
>      - IP 2
>      - IP ..
>      - IP N
>    - ARP-Gratuitos Emitidos por esse IP
>      - IP 1
>      - IP 2
>      - IP ..LS-K
>      - IP N
>    - ARP-Request Emitidos todos os IPS Perguntando por esse IP como destino
>      - IP 1
>      - IP 2
>      - IP ..
>      - IP N
>    - ARP-Request emitidos por IPs fora da faixa especifica
>      - Contador seco Global
>
Acho que melhor que SNMP é manter isso em DB em um analytics tipo
ES-LS-Kibana.


> Estou considerando um mecanismo de definição automática da faixa de
> sub-rede a ser trabalhada buscando diretamente na configuração da placa de
> rede, ou com a opção de forçar a faixa desejada no arquivo de configuração.
>
Então, em vez de criar filtros na coleta vc pega dado bruto e garimpa nele.
Talvez seja mais interessante para desenvolver depois algo mais específico.


> "2) formatar a informação
> De posse desses pacotes, o que vai ser exatamente monitorado? Quantidade
> absoluta? Top talkers?"
> Disponibilizando essa informação granularizada via SNMP, usando qualquer
> uma dessas ferramentas comuns de monitoramento(Nagios, Zabbix, Zennos,
> Observiun, Etc...) oque fazer com essa informação, o céu é o limite.
>
Bom, tem várias formas. Eu particularmente não vejo
Nagios/Zabbix/Zennos/Observium como ferramenta de análise, mas sim
monitoramento tipo front-panel.


> Meu sonho é a parte de Triggers e Reações ser implementada pelo IX
> (quarentena
> continuada).
> https://youtu.be/TgFlRXCxRX0?t=24m55s
> Com o Zabbix do IX.BR, isso ficaria mole-mole.
>
Falando no caso particular do IX, depende muito de escala. Teria que ter
primeiro uma análise do que acontece e daí traçar um caminho.
Uma coisa é ter 100 casos, outra é ter milhares de hosts conectados.


> Mas um dos objetivos é entregar a cada participante do IX a possibilidade
> de saber quem são os cara que estão causando problema.

Tendo a informação, faz o que achar melhor...
> Quem sabe cada participante automatizar em seu sistema de monitoramento um
> envio de e-mail para os participantes barulhentos?
>
Eu não conheço a rede do IX para dar um parecer, mas fico pensando se a
semântica do problema é simples assim.
As vezes um host é top talker não pq ele gera, mas por ser um host bastante
solicitado.
Mas precisa mesmo coletar cada ARP para isso? Não dá pra ser por amostragem
de flow (Netflow/Sflow/IPFIX)?
Fazendo amostragem de 20000:1 ARPs não daria uma boa base de quem seriam os
"vizinhos barulhentos" depois de algum tempo? Ou os vizinhos somem em um
curto espaço de "barulho"?