Gerenciamento e monitoramento de redes - parte III - SNMP

Neste terceiro artigo da série sobre gerenciamento e monitoramento de redes (os dois anteriores podem ser lidos aqui e aqui) quero falar sobre o protocolo SNMP - Simple Network Management Protocol. Esse é um protocolo muito popular, principalmente por ser simples, porém muitos profissionais ainda não entendem os seus detalhes (muitas vezes importantes).

O SNMP é realmente um protocolo amplo, que merece ele sozinho uma série de artigos (que pretendo escrever um dia), porém para os fins desta série pretendo focar nos aspectos básicos desse protocolo.

A História

Primeiro, um pouco de história sobre o SNMP. Ele foi criado pelo departamento de defesa do governo dos EUA (por isso em algumas partes desse protocolo se encontra referência à sigla DoD - Department of Defense).

O SNMP é um protocolo no qual um servidor (chamado NMS - Network Management System) faz uma pergunta ao equipamento monitorado e esse equipamento responde. Por exemplo o NMS pode perguntar quantos bytes passaram pela porta Ethernet 5 e o equipamento gerenciado responde com essa informação.


O DoD queria um protocolo que pudesse ser utilizado para monitorar todos os seus sistemas, independente do fabricante ou tipo de equipamento de rede. No entanto ele foi criado em uma época aonde os computadores tinhas memórias de 2Kbytes e assim precisava ser um protocolo bem simples. Isso tem grande impacto no protocolo até hoje.


A começar pelo protocolo de rede escolhido: UDP. Então não existe a etapa de conexão tipica do protocolo TCP e, também, isso significa que se um pacote for perdido, não existe retransmissão automática. Vamos supor que o NMS faça uma pergunta ao equipamento gerenciado, porém a resposta seja perdida (pacote descartado por um roteador, por exemplo), literalmente "fica por isso mesmo". O NMS nunca vai saber que o equipamento monitorado respondeu e o equipamento monitorado nunca vai saber que a resposta não chegou. Cabe o NMS (se quiser) fazer novamente a pergunta e torcer para desta vez chegar.

Outro ponto importante é que na época segurança na comunicação não era um fator crítico (não se considerava que houvessem hackers dentro do DoD), então não existe criptografia no protocolo original e o mecanismo de autenticação era fraco. Na verdade os profissionais de segurança brincam dizendo que SNMP na verdade significa "Security Not My Problem".

A forma básica de autenticação do SNMP é através das communities. Para nós que estamos acostumados a trabalhar com usuário e senha, o conceito de community pode ser um pouco estranho. Na verdade a versão original do SNMP (v1) só tinha essa "senha" que é a community. Ou seja, se você soubesse a community (senha) teria acesso ao gerenciamento do equipamento, simples assim. Além disso a informação de community era enviada aberta na rede, sem nenhum tipo de criptografia. Esses problemas foram resolvidas gradualmente nas versões subsequentes de SNMP, estando relativamente bem tratado na versão v3.

O SNMP, exatamente por ser um protocolo simples, tem uma maneira muito simples de se comunicar. O NMS envia ao equipamento gerenciado um número (por exemplo 1.3.6.1.4.1.2681.1.2.102) e cada número representa uma informação diferente. A forma de traduzir o OID em informações uteis e o significado de cada número possuem uma regra clara e bem definida, porém para não estender em demasia este texto, não vamos entrar em detalhes. Basta, neste momento, você entender que as MIBs são arquivos que informam quais OIDs um equipamento suporta (que informações ele pode fornecer via SNMP) e que o NMS precisa processar esses arquivos (chamado "compilar") para poder usa-los.

Get, Set e Trap

O SNMP é um protocolo de pooling, isso quer dizer que o servidor fica, de tempos em tempos, "cutucando" os equipamentos gerenciados, fazendo perguntas e verificando as informações. Essa verificação é chamada de GET e a lista de informações que um equipamento pode fornecer é definida nas MIBs fornecidas por cada fabricante.

Então cabe ao administrador indicar ao NMS, entre todas aquelas disponíveis nas MIBs, quais informações ele deve coletar, de quais equipamento e de quanto em quanto tempo. A função básica do NMS é consultar de tempos em tempos os equipamentos (fazer o GET) e armazenar essas informações.

Obviamente que os NMSs modernos vão além da simples coleta de dados e podem, por exemplo, gerar gráficos (como os software open source MRTG e Cacti além de diversas opções de softwares comerciais). Esses gráficos podem servir posteriormente para análises de tendencia (por exemplo, identificar o crescimento da ocupação de um link para prever quando será necessário amplia-lo) como para resolução de problemas (comparar os gráficos da rede em dois momentos diferentes e identificar o que mudou a ponto de causar um problema).

Os NMSs também podem gerar alarmes, alertando o operador, enviando e-mail, SMS, etc. Tudo depende dos recursos do NMS, por isso é importante verificar quais recursos serão necessários para escolher o NMS correto.

Vale lembrar que os equipamentos podem ser gerenciados por mais de um NMS. Assim, se for o caso, podemos ter os recursos de vários softwares NMS de forma a se aproveitar o melhor de cada um.

O problema do GET é que ele é feito em intervalos de tempos regulares, porém fixos. E se algo acontecer entre um GET e outro? Por exemplo, um link cair? Se colocarmos um tempo curto entre os GETs, iremos gerar uma grande quantidade de tráfego. Se colocarmos um tempo longo (por exemplo 5 minutos) irá demorar para detectarmos um problema. Para resolver essa questão o SNMP criou o conceito de TRAP.

O TRAP funciona no sentido inverso: quando algo grave ocorre, o equipamento gerenciado envia ao servidor de SNMP (mesmo sem ser perguntado) uma aviso. Isso permite com que um operador seja informando do problema imediatamente quando ele ocorre. Vale lembrar que cada fabricante define qual tipo de evento gera TRAP, sendo assim é uma informação importante a se considerar na escolha de um equipamento, principalmente se ele for utilizado em uma posição crítica na rede.

Por último temos o SET, que é quando o NMS tem condições de modificar a configuração do equipamento gerenciado. Novamente, os parâmetros que um equipamento permite que sejam modificados via SET variam de fabricante para fabricante. Alguns equipamentos simplesmente não permitem a configuração via SNMP, outro permitem apenas alguns poucos parâmetros.

Normalmente os equipamentos que suportam SNMP tem dois tipos de communities: read-only e read-write. As read-only são as senhas que permitem apenas operações de GET e as communities read-write permitem tanto GET como SET.

Versões de SNMP

O SNMP vem evoluindo, principalmente em termos de segurança e confiabilidade. Existe hoje as versões v1, v2 e v3 (com algumas sub-variações como v2c) e, como era de se esperar, a v3 é considerada a mais segura. No entanto essa versão ainda não está disponível em todos os equipamentos de rede.

Sendo assim, ainda hoje a versão v2c tende a ser a mais utilizada, por ser mais simples de se configurar e por ser suportada na maior quantidade de equipamentos.

Resumo

O SNMP é um protocolo que vem se desenvolvendo, porém é o padrão de fato hoje no gerenciamento de redes. É muito difícil encontrar um equipamento que não suporte SNMP então é importante para qualquer administrador ter em sua rede um sistema de NMS. Através desse sistema ele poderá monitorar e gerenciar praticamente todos os elementos da sua rede, desde roteadores e switchs até telefones IP.

O único detalhe importante é na questão da segurança, que precisa ser vista com cuidado para que as deficiências do SNMP não se tornem uma ameaça.

Se você quiser ser avisado quando forem publicados os próximos artigos, por favor me siga no Twitter: http://www.twitter.com/mlrodrig

Comentários