Respondemos ao vandalismo por cabo rapidamente, em qualquer lugar e sem armadilhas físicas

Oi

Há um desejo de compartilhar com a comunidade uma idéia que é implementada na empresa fornecedora para responder rapidamente a danos ao cabo de cobre. É sobre par trançado e Ethernet. Claro que não pretendo ser soluções elegantes, mas o serviço mostrou bons resultados.



Para quem tem preguiça de ler. Como funciona: monitore a queda das sessões no raio, agrupe por interruptores, teste a linha, notificação do capacete.

Não posso fornecer o código inteiro do projeto por motivos corporativos, mas removerei o que está embaixo dos spoilers para os interessados. Sim, e a implementação para cada provedor variará. Em vez disso, o objetivo é compartilhar uma ideia que possa ajudar alguém.

O equipamento da empresa é 99% D-link, portanto, os SNMP MIBs são listados para esse fornecedor. Alguns deles são RFCs e devem ser adequados para outros fabricantes.

Um pouco de história sobre como tudo saiu.

Tudo começou na primavera de 2018. A carga no grupo de suporte técnico (TP) aumentou. Além de processar chamadas de assinante, a TP também coordenou os instaladores ao conectar novos assinantes, bem como ao sair para a restauração e depuração de clientes existentes. Foi necessário descarregar um pouco o TP e fornecer algumas ferramentas aos instaladores. Foi decidido compor um mensageiro "bot" que aceitaria o login / contrato do assinante e o instalador poderia fazer a depuração mínima diretamente nos campos.

Eu não queria incorporar todas as funcionalidades em um aplicativo, porque de fato, essa funcionalidade seria útil também no navegador no mesmo CRM ao processar uma chamada, por isso foi decidido colocar os mecanismos de interação com o equipamento de rede, cobrança, raio em um serviço separado, transformá-lo em uma API e conectar o bot e o CRM via API. tanto faz.

Agora, um pouco de código e vá para a essência do post.

E assim, o que um instalador pode precisar nos campos:

1. Teste de cabo, é claro
2. Exibir erros de porta
3. Exibir status da porta
4. Veja se há endereços MAC na porta. (de repente, o assinante conectou o cabo à porta LAN em vez da WAN)
5. Assinatura IPTV
6. Exibir logs de autorização
7. Status do saldo

Vamos interagir com os switches via SNMP e, em alguns lugares, via telnet.

Eu usei o Bottle como uma estrutura da web.

E assim


Adicionamos uma planilha com chaves de API e decoradores para verificação, mas não forneceremos dados para todos em uma linha).


Bem, na verdade algumas funções para interagir com o equipamento.


Dentro do snmp, temos um dicionário com a interpretação dos status SNMP retornados do par na porta.


Preparação do dicionário para o resultado da medição da porta. Vamos copiá-lo, para não fazer um novo sempre.


Função


função retornará


Mais tarde, ele adicionou outra função semelhante, exclusivamente para o script, que recebe uma lista de portas como entrada, e não uma, e não verifica o status da porta antes do teste; isso não é necessário com uma queda maciça nos links.

Foi assim que o bot começou a se parecer



Agora, para a essência do post.

Antes da implementação da depuração do servidor, era usada uma tecnologia semelhante à descrita na publicação habr.com/post/188730 . Loop na porta com a escada SNMP ativada. Quando o "avião" caiu no porto, uma mensagem sobre isso caiu no monitoramento.

Antes de tudo, eu estraguei o script para que, quando o link de rastreamento caísse, o servidor de depuração fosse para o comutador, verifiquei se a porta estava realmente mentindo e não apenas piscou, e os pares estavam abertos ou em curto e enviei uma mensagem aos operadores.

No entanto, apenas cerca de 10% dos comutadores tinham essas armadilhas físicas, e isso acabou por não ser suficiente.

Mais tarde surgiu com um raio de monitor. E isso permitiu aumentar o percentual de cobertura de monitoramento em até 100%. E aqui tudo já difere da infraestrutura do provedor.

Periodicamente, analisamos quantas sessões de clientes caíram de uma opção específica. Isso é fácil se o circuit_id estiver ativado nos comutadores, que tem o formato

D4: CA: 6D: 0A: 66: C9 :: 192.168.20.86 :: 20

Aqui temos o MAC do assinante, o comutador IP, o número da porta do assinante. I.e. tudo que você precisa para depurar.
Agrupamos sessões concluídas por comutador IP, se houver mais do que algumas dessas sessões (temos um gatilho definido como 2 sessões por minuto), o script entra em contato com o servidor de depuração e testa as portas das sessões descartadas. Se as portas ainda estiverem e os pares de cabos estiverem abertos ou em curto, e o comprimento de pelo menos duas portas for o mesmo (+ - 2 metros), que é exatamente o que o corte de cabo se parece com os olhos do comutador, consideraremos a situação suspeita e enviaremos uma mensagem ao operador.

É claro que haverá falsos positivos quando a luz da casa piscar, ou apenas coincide que os assinantes desliguem o cabo ao mesmo tempo e o comprimento seja o mesmo, mas é o caso, como costumam dizer, quando é melhor exagerar. Além disso, você pode limitar o comprimento (responder apenas a comprimentos curtos), o número de descargas simultâneas etc.

Aqui está o relatório real de um evento suspeito.



E os resultados do processamento de tais mensagens



Houve um caso em que o script enviou uma mensagem semelhante e, após alguns segundos, o comutador ficou offline, porque óptica danificada e, se não fosse a velocidade do software, a situação teria sido confundida com um blecaute típico na casa.

Em outra ocasião, a empresa de administração começou a consertar o telhado sem aviso prévio, e o VOKhR com metralhadoras voou até eles, repentino estresse para os serralheiros.

Portanto, o script começou a mostrar bons resultados e, após 4 meses de trabalho, a VOKhR, a polícia e os funcionários do fornecedor concluíram com êxito mais de 10 casos de vandalismo. Por isso, decidi compartilhar o conceito desse monitoramento.

Agora, o script monitora cerca de 15.000 comutadores sem nenhuma "armadilha" física e armadilha SNMP.

Boa sorte a todos no ano novo!